Undo changes by 216.49.181.128 - I still prefer the old way. Happy to discuss on talk page
← Older revision
Revision as of 15:07, 7 June 2016
Line 3:
Line 3:
==MediaWiki issues==
==MediaWiki issues==
−
===
Edit
Links
on
Sections
===
+
* If a template contains section headings (like "
=
=Section 1
==
"),
when
the template is displayed
on
a
page each section heading will have its own "Edit" link. Such links are not desirable, since they will take the user to editing the template, rather than the actual page in question. The easiest way to avoid this problem is to place the string <nowiki>"__NOEDITSECTION__"</nowiki> anywhere within that template; this will remove all section-edit links from any page that contains that template. Another option, though not a recommended, is to use <nowiki>"<h2>", "<h3>", etc.</nowiki> tags instead of "
==
", "
=
==" etc.
−
If a template contains section headings (like <code>==Section 1==</code>), when the template is displayed on a page each section heading will have its own "Edit" link. Such links are not desirable, since they will take the user to editing the template, rather than the actual page in question.
−
−
The easiest way to avoid this problem is to place the string <code><nowiki>__NOEDITSECTION__</nowiki></code> anywhere within that template; this will remove all section-edit links from any page that contains that template.
−
−
Another option, though not a recommended, is to use <code><nowiki><h2></nowiki></code>, <code><nowiki><h3></nowiki></code>, etc. tags instead of <code>==</code>, <code>===</code> etc.
==Semantic Forms issues==
==Semantic Forms issues==
Line 40:
Line 40:
You can also see other tips and hints for using Semantic Forms in the [http://smw.referata.com/wiki/Special:BrowseData/Tips?Extension=Semantic_Forms tips section] of the SMW Community Wiki.
You can also see other tips and hints for using Semantic Forms in the [http://smw.referata.com/wiki/Special:BrowseData/Tips?Extension=Semantic_Forms tips section] of the SMW Community Wiki.
−
==
Data design issues
==
+
==Data design issues==
−
===
Using
Categories
===
+
*
One
common
issue is how to use categories. The [[w:en:Main_Page|Wikipedia]] approach is to have many categories on each page, to identify all aspects of that page's subject. Semantic MediaWiki was created in part to eliminate the need for categories, by allowing for semantic properties to represent this data. The general Semantic Forms approach is to only have one category per page, and have this category be set by the main template in the page: in other words, it is recommended that users not enter category declarations directly. The one exception to this rule is when there's a need for "hierarchical tagging", i.e. being able to add a page within different levels of a category tree. For this purpose, the 'category' and 'categories' input types exist.
−
One common issue is how to use categories. The [[w:en:Main_Page|Wikipedia]] approach is to have many categories on each page, to identify all aspects of that page's subject.
−
−
Semantic MediaWiki was created in part to eliminate the need for categories, by allowing for semantic properties to represent this data. The general Semantic Forms approach is to have ''only one category per page'', and have this category be set by the main template in the page. In other words, it is recommended that users not enter category declarations directly.
−
−
The one exception to this rule is when there's a need for "hierarchical tagging", i.e. being able to add a page within different levels of a category tree. For this purpose, the 'category' and 'categories' input types exist.
−
−
=== Directionality of Properties ===
−
When creating a semantic property connecting any two "classes" (or pages represented by different categories) you may be unsure about which way to point the property. Usually such relationships will be of the one-to-many variety — also known as parent-child relationships — in which each page of type A has a relationship to any number of pages of type B, while each page of type B always has a relationship to exactly one page of type A.
−
−
An example is countries and cities: a country can have many cities, but a city always belongs to exactly one country. In such a case, you may not know whether it should be country pages that have a "<tt>Has city</tt>" property, or city pages that have a "<tt>Belongs to country</tt>" property, or even whether both properties should exist.
−
−
In this situation, it is recommended that you ''specify the relationship only from the child to the parent'', i.e. use a "<tt>Belongs to country</tt>" property for cities and not the other way around. This is for two reasons:
−
* first, it lets you guarantee the rule that every child has exactly one parent, by setting this property through a field within the child's main template; and
−
* second, it makes page-name autocompletion more reliable, since parent pages are usually created before their children's pages are.
−
−
=== Forms for Related Page Types ===
−
You may not be sure about whether to create one form or many for a set of related page types.
−
−
For instance, in a wiki about restaurants, should you have a separate form/template/category set for regular restaurants, fast-food restaurants, diners etc., or a single form called "Restaurant", with a corresponding single template and category, that just uses a field to indicate the type of restaurant it is?
−
−
A good rule of thumb is to look at the set of data that you want to be entered and displayed for each type of page.
−
* If it's the same across all the types, then you could probably use a single form/template/category set for all of them.
−
* If there are only a few differences, then you might be able to use the "show on select" feature to handle the different cases within a single form.
−
* However, if there are significant enough difference in the set of fields being displayed, then it probably makes sense to give such a page type its own form, template and category.
−
===
Namespaces
for
Different
Page
Types
===
+
*
When creating a semantic property connecting any two "classes", or pages represented by different categories, you may be unsure about which way to point the property. Usually such relationships will be of the one-to-many variety, also known as parent-child relationships, in which each page of type A has a relationship to any number of pages of type B, while each page of type B always has a relationship to exactly one page of type A. An example is countries and cities: a country can have many cities, but a city always belongs to exactly one country. In such a case, you may not know whether it should be country pages that have a "Has city" property, or city pages that have a "Belongs to country" property, or even whether both properties should exist. In this situation, it is recommended that you specify the relationship only from the child to the parent, i.e. use a "Belongs to country" property
for
cities and not the other way around. This is for two reasons: first, it lets you guarantee the rule that every child has exactly one parent, by setting this property through a field within the child's main template; and second, it makes page-name autocompletion more reliable, since parent pages are usually created before their
children's
pages
are.
−
It is possible to create a different namespace for each page type. Wikisource does this with an [[s:en:Author:Benjamin_Franklin|"Author:" namespace]], for instance, and several SMW-based wikis have one or more namespaces for different page types. Whether you do this on your wiki is up to you, but it is not recommended that you do it unless there is a real possibility of naming ambiguity otherwise.
−
A
massive
wiki
like
Wikipedia
will
have a
great
deal
of
pages
that
require
disambiguation
,
but
most
small
wikis
will
barely
have
any
, and
so
having
separate
namespaces
will
probably be a
needless
complication
.
+
*
You may not be sure about whether to create one form or many for a set of related page types. For instance, in a
wiki
about
restaurants,
should you
have a
separate
form/template/category
set
for
regular
restaurants,
fast-food restaurants
,
diners
etc.,
or
a
single
form
called
"Restaurant"
,
with a corresponding single template
and
category,
that
just
uses
a field to indicate the type of restaurant it is? A good rule of thumb is to look at the set of data that you want to be entered and displayed for each type of page. If it's the same across all the types, then you could
probably
use a single form/template/category set for all of them. If there are only a few differences, then you might
be
able to use the "show on select" feature to handle the different cases within
a
single
form
.
However, if there are significant enough difference in the set of fields being displayed, then it probably makes sense to give such a page type its own form, template and category.
−
Currently the only common examples of ambiguity in SMW wikis are caused by having pages for both cities and states in the United States: "New York" and "Washington" both fit into either category. There are various solutions to this problem, but the simplest may be to have all states referred to by their two-letter abbreviation, e.g. "NY" and "WA".
+
* It is possible to create a different namespace for each page type. Wikisource does this with an [[s:en:Author:Benjamin_Franklin|"Author:" namespace]], for instance, and several SMW-based wikis have one or more namespaces for different page types. Whether you do this on your wiki is up to you, but it is not recommended that you do it unless there is a real possibility of naming ambiguity otherwise. A massive wiki like Wikipedia will have a great deal of pages that require disambiguation, but most small wikis will barely have any, and so having separate namespaces will probably be a needless complication. (
Currently the only common examples of ambiguity in SMW wikis are caused by having pages for both cities and states in the United States: "New York" and "Washington" both fit into either category. There are various solutions to this problem, but the simplest may be to have all states referred to by their two-letter abbreviation, e.g. "NY" and "WA".
)