Help:Properties and types 1.4.3

Jump to: navigation, search

This page contains outdated information and is thus OBSOLETE!
This documentation page applies to all SMW versions from 1.0 to 1.4.3.
Other versions: ≥ – 1.5.6       Other languages: frnl

Help:Properties and types en 1.0 1.4.3

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::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.

Existing links can be directly augmented with such property information, while other types of data (such as numbers or calendar dates) need an additional editing step.

Turning links into properties

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:

[[capital of::Germany]]

In the article, this text still is displayed as a simple hyperlink to «Germany». The additional text 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.

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 "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:


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 "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 "population" property; see the next section for more information.

Data types for properties

Semantic MediaWiki has several built-in data types that we can choose for properties. For our previous population example, the appropriate type is called Number; the prefix "Type:" is again a separate namespace that distinguishes descriptive articles about types from normal pages. We want to give property "population" a special property that specifies it has "type:number". To support this Semantic MediaWiki has a built-in special property called Property:Has type. We use the same syntax for this special property as for any other property, so in the Property:Population article, we write:

[[has type::number]]

(You don't need to specify the Type: namespace here.)

Semantic MediaWiki knows a number of special properties like Property:has type. Regardless of whether these properties have their own articles in the wiki, they have a special built-in meaning and are not evaluated like other properties.

Data types are very important for evaluating properties. Firstly, the data type determines how tools should handle the given values, e.g. for displaying values and sorting values in search results. Secondly, the data type is required to understand which values have the same meaning, e.g. the values "1532", "1,532", and "1.532e3" all encode the same number. Finally, some data types have special behavior, as will be described below. For these reasons, every property used should be defined with a data type.

The reason we didn't have to specify a data type for the "capital of" property above is that the default data type is Page, which displays as a link. Even though Type:Page is the default, you should explicitly specify a datatype for every property, just to prevent confusion or later redefinition with an unintended type.

The same mark-up for properties that are links to pages also works for properties of other datatypes. Here are some more examples.

What it does What you type
Assign the value 1,234,567 to the property "example".
This page has a value for "example" of [[example::1,234,567]]."
Assign a numeric value, but showing different text in the article.
This page has a value for "example" of [[example::999,331|about a million]].
Specifying the type in a property's article, e.g.
This property is a number.
This property is a [[has type::number]].
Combining MediaWiki markup with property values, e.g.
John's username is john
This is not recommended; you should use a template instead.
John's username is [[username::john|[ john]]].

List of data types

Using different types, properties can be used to describe very different kinds of values. A complete list of available types is available from Special:Types. The available types are:

  • Help:Type Page - links to pages (the default)
  • Help:Type String - text strings
  • Help:Type Number - integer and decimal numbers with optional exponent
  • Help:Type Boolean - restricts the value of a property to true/false (also 1/0 and yes/no)
  • Help:Type Date - specifies particular points in time
  • Help:Type Geographic coordinate - describes geographic locations. It recognizes different forms of geographic coordinates.
  • Help:Type Text - like Type:String but can have unlimited length; the tradeoff is values of this type cannot be selection or sort criteria in queries..
  • Help:Type Code - like Type:Text but displays its value in a HTML pre-formatted box. The value displays as regular text everywhere else (query results, factbox, "Pages using the property", etc.).
  • Help:Type Temperature - can't be user-defined since converting temperature units is more complicated than multiplying by a conversion factor.

For specifying URLs and emails, there are some special variations of the string data type:

  • Help:Type URL - displays an external link to its URL object.
  • Help:Type Annotation URI: properties of this type are interpreted as relations to external objects, denoted by the URI. They are special since they are interpreted as annotation properties on export. See the type's page for documentation.
  • Help:Type Email - displays an e-mail address as a link (with mailto:).

Enumerations and "Allows value"

SMW does not have an "enumerated" data type, i.e. a type that has a limited set of allowed values; instead, for any property, you can limit its possible values by using the special property Property:Allows value to enumerate its permitted values. This works for every data type.


Type:Number allows a unit after the numeric value to distinguish values (e.g. "30.3 mpg" versus "47 km/liter"), but does not know how to convert between them. To support automatic conversion and multiple unit formats, you can define your own datatype with custom units. These automatically convert values to and from standard representations, so that users are free to use their preferred unit in each article yet still query and compare with property values in other articles.

Properties with multiple types

In human language it is easy to introduce multiple facts at once. For example, "John F. Kennedy was the 35th president of the U.S.A., serving from 1961 until his assassination in 1963." This is information about John F. Kennedy that belongs in his wiki page, but it shifts to information about his presidency. You could simply have a property "Presidency_details" of Type:String and put the text in it. But it will only be meaningful to humans, you can't query on it or sort it to produce a list of presidents.

You can't nest semantic annotations, so you cannot have a string property that contains additional annotations.

Often the best way to represent this is to create an article for the object of the property, so this can be annotated with the additional information. So the property "Has_presidency" would be of Type:Page, and then the article "Presidency of JFK" would have the properties "Of country::U.S.A.", "Count::35", "Start date::1961-01-20", :End date:1963-11-22", etc. Wikipedia frowns on so-called "stub" articles, but in a semantic wiki they are appropriate as they provide information for semantic queries and browsing.

It is also possible to create a property in Semantic MediaWiki that takes multiple values; these are sometimes called "n-ary relations". So you could create a property "Has presidency" that would have Type:Page; Type:Number; Type:Date; Type:Date, where the four values represent the country, the count of the presidency, the start date, and the end date. See Help:Many-valued properties for more information.

Special properties

We mentioned the special property Property:Has type that you use to define the data type of a property. SMW has other predefined special properties that have special meaning (even if you do not create property pages for them in your wiki). You cannot use these names for your own properties, but since SMW 1.4.0 you can use them in browsing and querying interfaces just like all other properties. For more information, see Category:Special property and the individual property pages.

Silent annotations 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:


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

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:

{{#set_recurring_event:property=Has date|start=January 4, 2010|end=June 8, 2011|unit=week|period=1|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

In earlier 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, strings, 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 see ow:Help:Annotation (SMW0.7) for documentation of Annotations in version 0.7.