Help:Properties and types

Jump to: navigation, search
SMW user manual
Properties and types
Special properties
Inverse properties
Custom units

Semantic templates

Service links

Browsing interfaces
Semantic search
Selecting pages
Strict comparators
Displaying information
Result formats
Inline queries
Querying for queries
Using the API
Semantic Web
RDF export

External tools

Importing vocabulary

SMW admin manual

Properties and types are the basic way of entering semantic data in Semantic MediaWiki. Properties can be viewed as «categories for values in wiki pages». They are used by a simple mark-up, similar to the syntax of links in MediaWiki:

[[Property name::property value]]

This statement defines a value for the property of the given property name. The page where this is used will just show the text for value and not the property assignment.

Creating properties

Figure 1: Semantic MediaWiki statement (property-value pair)

Consider the Wikipedia article on Berlin. This article contains many links to other articles, such as «Germany», «European Union», and «United States». However, the link to «Germany» has a special meaning: it was put there since Berlin is the capital of Germany. To make this knowledge available to computer programs, one would like to «tag» the link


in the article text, identifying it as a link that describes a «capital property». With Semantic MediaWiki, this is done by putting a property name and :: in front of the link inside the brackets, thus:

[[Is capital of::Germany]]

In the article, this text still is displayed as a simple hyperlink to «Germany». The additional text Is capital of is the name of the property that classifies the link to Germany. As in the case of categories, the name of the property is arbitrary, but users should try to re-use properties that already appear elsewhere.

To simplify this re-use, every property has its own article in the wiki, just as every category has an article. You can see all the properties in use in the wiki with the Special:Properties page. Just as category articles are prefixed with Category:, all property articles are prefixed with Property: to distinguish them from other articles. So you can also also use MediaWiki's Special:Search page to find existing properties. As with categories, a property's article can be empty, but it is strongly recommended to add a description that explains the intent of the property and its proper usage.

In-text annotations and property declarations are case-sensitive and therefore adhere certain environmental MediaWiki settings (e.g $wgCapitalLinks) and if changed arbitrarily may cause content to be rendered invalid or unavailable during query execution.

Turning links into properties

There are various ways of adding properties to pages:

What it does What you type
Classify a link with the property "example property."
 Classify a [[Example property::link]] with the property "example property."
Make alternate text appear in place of the link.
Make [[Example property::link|alternate text]] appear in place of the link.
To hide the property from appearing at all, use a space as the alternate text.
To hide the property [[Example property::link| ]] from appearing at all
use a space as the alternate text.

Note: The space after | is necessary. If left away, the MediaWiki pipe trick applies, but rarely with desirable effects. Even if a space is given, SMW will not print anything, which should be the desired result in most cases (to make a space appear in the text, use   as a space symbol).

To make an ordinary link with :: without creating a property, escape the markup with a colon in front, e.g.
The C++ :: operator.
The [[:C++ :: operator]].
To assign one value to multiple properties, add :: between each name,
e.g. link.
e.g. [[Property1::Property2::link]]. 

Turning values in text into properties

There is other useful information in wiki articles besides links to other articles. For example, there is a number in the Berlin article giving its population. To make this knowledge available to computer programs, one would like to "tag" the text


in the article, identifying it as a value for the "Has population" property. With Semantic MediaWiki, this is done by putting the property name and :: in front of the text and surrounding it with [[ ]] brackets, thus:

[[Has population::3,396,990]].

This works fine. However, it creates a link to a 3,396,990 page, and having an article for every population value probably does not make sense. Furthermore, if you wanted to create a list of all German cities ordered by population, numeric order is different from the alphabetical order that you would expect for article names. For example, in alphabetical order, "1,000,000" comes before "345". We want to be able to tell Semantic MediaWiki that "Has population" is a number, not a link to a page in the wiki. The way to do this is to specify a type for the "Has population" property; see the section on datatypes for more information.

Naming of properties

Use a verb phrase (recommended)

The naming of properties is more important than one would probably expect at first. Property names should avoid ambiguity and confusion. Thus, it is good practice to create Property names as a verb phrase. Here's an example that uses Berlin and makes this practice more comprehensible:

Germany's capital is Berlin. ↔ Berlin is the capital of Germany.

In both cases one could assign a property named "Capital", but this does not convey exactly the intended meaning. The first sentences says that Germany has a capital called Berlin. Therefore the better name for the property is "Has capital". The second sentence states that Berlin is the capital of Germany. Hence the better name for the property is "Is capital" in this case. So the annotation avoiding ambiguity is as follows:

Germany's capital is [[Has capital::Berlin]]. ↔ [[Is capital::Berlin]] is the capital of Germany.

Avoid using the name of a datatype

For technical reasons a property name should not be the same as the name of one of the datatypes. So an annotation like e.g. [[Code::Qsdr-5t7Z-b99N]] will not serve the intended purpose, since the assigned datatype will always be "Code" and cannot be changed to "Text". (However, to name the property "Is registration code" or something alike is the better alternative for this in the first place anyway.)

Avoid using certain kinds of punctuation

Certain kinds of punctuation are to be avoided in property names, because they are also used as special syntax in semantic queries or they may cause problems for other reasons. Examples:

  • :: (two subsequent colons) - a single colon should not cause any trouble
  • - (hyphen) in initial position - for reasons to do with inverse properties
  • . (dot) - operator used to link properties in concatenation
  • | (pipe)
  • # (number sign) - for datatype "Page" since it is interpreded as part of a subobject delcaration.[1]

Silent annotations using #set

See Help:Setting values for more detailed information about using #set

Instead of using the standard double-brackets markup, you can also define semantic data using the #set parser function. This function takes in pairs of property names and values and stores them semantically; but it does not print anything to the screen. An example call would be:

{{#set:Has population=3,396,990|Has country=Germany}}

The #set call is specifically helpful when trying to save a Text value that contains square brackets, such as wiki-links; such brackets often don't work with conventional SMW markup.

Extra colons in an annotation can cause unexpected pattern matching therefore it is suggested to use #set. For example,

  • Has text::fc00:123:8000::/%6 can be expressed by
  • {{#set:Has text=fc00:123:8000::/%6|template=BySetTemplateSimpleValueOutput}} to output
  • fc00:123:8000::/%6

See also

  1. See also issue 1087 for more information on this.

Property declaration and datatypes

Inverse properties

Since SMW 1.5.0, it is possible to invert the direction of a property with datatype Page. See the respective help page for detailed information.

Defining recurring events

Another type of complex data is recurring events, which are events that have multiple dates, defined according to a preset rule (such as a weekly meeting). You can define the date values for these using the #set_recurring_event parser function, which, like #set, is "silent" and does not print anything. An example call would be:

 property=Has date
 |start=January 4, 2010
 |end=June 8, 2011
 |include=March 16, 2010;March 23, 2010
 |exclude=March 15, 2010;March 22, 2010

You can see Help:Recurring events for more information.

Handling in earlier versions

Up to SMW 1.5.6, datatypes had individual wiki pages in their own namespace called "Type". This was abolished to reduce the number of extra namespaces. You may still find expressions like "Type:Number" in places in this wiki. Both writings are accepted for assigning a datatype to a property.

In very early versions of SMW, properties with datatype Page were known as relations and only those used double colons (::) as the separator between property name and link text. All other properties (numbers, text, etc.) were known as attributes and had to use colon equals (:=) as the separator.

See Upgrading from SMW 0.7 to SMW 1.0 for other changes in SMW 1.0; if you're still using the older version of SMW, see semweb:Help:Annotation (SMW0.7) for documentation of Annotations in version 0.7.

This documentation page applies to all SMW versions from 1.6.0 to the most current version.
Other versions: 1.5.0 – – 1.4.3       Other languages: frruukzh-hans

Help:Properties and types en 1.6.0