Administrator manual

Jump to: navigation, search

This "book" is the Semantic MediaWiki User's Guide at formatted for print. Note that some there are also PDF versions of some manuals of SMW.


User manual

Navigating the user manual content

Semantic MediaWiki (or SMW for short) is an extension to the well-known MediaWiki software. The purpose of SMW is to allow users to improve the structure and organization of the knowledge in a wiki by adding simple, machine-processable information to wiki articles. With this additional information, you can greatly improve searching, browsing, and sharing the wiki's knowledge; both within the wiki's pages and from external computer programs.

This is the user manual of SMW that focusses on information for users of an SMW-enabled wiki. If you are new to SMW, then the introduction to Semantic MediaWiki is a good starting point. Information for site administrators and for SMW developers (including information on the spinoff extensions of SMW) can be found on the main page.

The main sections of this handbook explain the most important aspects of using SMW:

These sections are relevant to different user groups, and need not be read in sequence. Detailed navigation is provided by the table of contents on the right. Other relevant parts of this handbook include:

There are other resources that you might find useful:

See also

Introduction to Semantic MediaWiki

Warning: Display title "Introduction to Semantic MediaWiki" overrides earlier display title "User manual".

Semantic MediaWiki (SMW) is an extension of MediaWiki – the wiki application best known for powering Wikipedia – that helps to search, organise, tag, browse, evaluate, and share the wiki's content. While traditional wikis contain only text which computers can neither understand nor evaluate, SMW adds semantic annotations that allow a wiki to function as a collaborative database. Semantic MediaWiki was first released in 2005, and currently has over ten developers, and is in use on hundreds of sites. In addition, a large number of related extensions have been created that extend the ability to edit, display and browse through the data stored by SMW: the term "Semantic MediaWiki" is sometimes used to refer to this entire family of extensions.

Why Semantic MediaWiki?

Wikis are a great tool for collecting and sharing knowledge in communities and organizations. This knowledge is mostly contained within texts and multimedia files, and is thus easily accessible for human readers. But though wikis are very good for storing and retrieving individual facts, they are less useful for getting queried or aggregated information. As a simple example, let's say you use a wiki that stores information about projects related to your organization. You have the following simple question:

"What are the active projects that were started in 2012?"

This should be an easy question to answer, but in fact it's not - you would have to read through all of the pages about projects every time you wanted to answer the question. Text searches won't necessarily help. Categories could help to some extent, although they're not an ideal tool and maintaining them can become complex (see below). And there doesn't exist an artificial intelligence tool that could help with this task either.

Semantic MediaWiki enables wikis to make their knowledge computer-processable, so that you can find and display the answer to this question - and to many more.

Where SMW can help

Semantic MediaWiki introduces some additional markup into the wiki-text which allows users to add "semantic annotations" to the wiki. While this at first appears to make things more complex, it can also greatly simplify the structure of the wiki, help users to find more information in less time, and improve the overall quality and consistency of the wiki. Here are some of the benefits of using SMW:

  • Automatically-generated lists. Lists and tables are a natural way to view information at a glance. In some cases, non-semantic wikis contain human-generated lists; Wikipedia itself has thousands, like "List of metropolitan areas in Spain by population". These lists are prone to errors, since they have to be updated manually. Furthermore, the number of potentially interesting lists is huge, and it is impossible to provide all of them in acceptable quality. In SMW, lists are generated automatically like this. They are always up-to-date and can easily be customised to obtain further information.
  • Visual display of information. The various display formats defined by additional extensions, such as Semantic Result Formats and Maps (formerly Semantic Maps), allow for displaying of information in calendars, timelines, graphs and maps, among others, providing a much richer view of the data than simple lists and tables would.
  • Improved data structure. MediaWiki wikis tend to make heavy use of categories for structuring data. While these are generally helpful, consider the category on Wikipedia called "1620s births"; if the information in these pages were stored using SMW, these categories could be replaced by simple semantic values, reducing the need for a complex classification system. In addition, if semantic markup within the wiki is stored within templates, otherwise known as semantic templates, a wiki can easily gain a solid data structure. And the Page Forms (formerly Semantic Forms) extension lets administrators create forms for adding and editing the data within semantic templates, thus making the addition of semantic information even easier and more straightforward than using regular wiki text.
  • External reuse. Data, once it is created in an SMW wiki, does not have to remain within the wiki; it can easily be exported via formats like CSV and JSON. This enables an SMW wiki to serve as a data source for other applications, or, in the case of enterprise usages, to take over the role that a relational database would normally play. Through the use of the External Data extension, SPARQL, and other tools, one SMW-based wiki can even use the data from another, eliminating the need for redundancy between wikis. You can also query SMW's data from outside the wiki, via the API or an RDF triplestore.
  • Integrate and mash-up data. Data contained in an SMW installation does not have to be an isolated store of information. Extensions such as Data Transfer and External Data empower you to integrate external data (coming e.g. from legacy systems, web services or linked data sources) and interrelate it with existing semantic data in the wiki. Thus, an SMW-powered wiki can serve as a central information hub in an IT landscape.

Who is using Semantic MediaWiki?

Semantic MediaWiki has grown a long way from its roots as an academic research project. It is currently in active use in hundreds of sites, in many languages, around the world, including Fortune 500 companies, biomedical projects, government agencies and consumer directories. The Wikipedia article on Semantic MediaWiki contains a section listing some of its notable users. You can also see a more comprehensive list of sites that use SMW here. It should be noted that both lists focus on public sites, although perhaps half or more of the sites that use Semantic MediaWiki are private, for internal use by companies and organizations.

There are a growing number of consulting companies that implement SMW as part of their solutions, with some stating their use of MediaWiki and SMW explicitly and others keeping it as a hidden implementation detail. (You can see a listing of people and companies that can be hired to do SMW-based work at the "professional support" page.)

Websites that currently offer hosting services for Semantic MediaWiki and some of its extensions are listed in wiki farm provider.

You can read about positive experiences using SMW among companies, organizations and individuals at the testimonials page.

More information

This site has much more information about setting up and running a Semantic MediaWiki installation. The administrator manual holds information on downloading, installing and troubleshooting SMW; and also has information on the various extensions that can be installed to work together with SMW. The user manual holds information on defining properties, running queries, browsing data and the like. And the FAQ has answers to frequently-asked questions on both technical and non-technical issues.

Contact and user support

For contacting the SMW Project, see the contact page. For comments and questions, there is an active user mailing list that you can join, as well as an IRC Channel, #semantic-mediawiki. See Help:Getting support for further information about support for SMW.

Bugs and feature requests for SMW can also be filed at GitHub; see the documentation on reporting bugs.

This documentation page applies to all SMW versions from 0.1 to the most current version.
      Other languages: deesfrjanlruukzh-hans

Help:Introduction to Semantic MediaWiki en 0.1

Browsing interfaces

Warning: Display title "Browsing interfaces" overrides earlier display title "Introduction to Semantic MediaWiki".

Semantic MediaWiki provides various simple interfaces for browsing the data contained in the wiki. In addition, there are two other ways to browse through a wiki's data: using one or more additional extensions that offer browsing of SMW data; and using an external tool that gets populated with the wiki's data via RDF.

The factbox

The factbox is a box at the bottom of wiki pages which summarises the semantic data that was entered into a page. This also helps editors to check whether Semantic MediaWiki actually «understood» the supplied information as intended. Users can ... (read more).

Semantic browsing

The Special:Browse page offers a simple browsing interface for the computer-readable data of Semantic MediaWiki. By default, the sidebar for every page, within the "toolbox" links, contains a "Browse properties" link that leads to the Special:Browse page for that page. Users can also go to Special:Browse, directly, then enter the name of a specific page they want to browse. Special:Browse displays all semantic properties of a page (similar to the content of the factbox), as well as all semantic links that point to that page. By clicking on the icon Browse icon.png, the user can browse to another article. For a more detailed description and some configuration settings, see here.

Simple search interfaces

Semantic MediaWiki provides a number of very simple search forms that allow users to find specific information. These search features are accessed in various special pages:

  • Special:SearchByProperty has a simple search form for finding semantic backlinks i.e. pages by properties or property value combinations. See the respective help page for further information.
  • Special:PageProperty displays all values some page has for some property. Users enter a page and a property name. The search displays a list of all values of the property on that page. If factboxes are enabled in the wiki, the same information can also be read off the factbox of the page. Since SMW 1.4.3, it is also possible to retrieve all values that a property has been given throughout the wiki, simply by leaving the subject input empty.

Viewing all properties, types, values and concepts

Each property has an own page in the Property namespace, similar to the category pages in MediaWiki's Category namespace. These property pages show all pages using the property together with the property's value(s) on that page, possibly with service links

Besides the links in the factbox and the normal MediaWiki search, there are also special ways of finding properties of a wiki:

  • Special:Properties lists properties that appear in annotations in alphabetical order and indicate the frequency of their usage.
  • Special:UnusedProperties lists property pages that are not in any annotations. This may indicate that a property was abandonded and should be deleted.
  • Special:WantedProperties lists properties that are used but do not have a descriptive page. This is not desirable, since users then cannot find any documentation on such properties, so that confusion may arise regarding their proper use.
  • Special:Concepts lists the concepts ("dynamic categories") created on the wiki.
  • Special:Types lists the available datatypes for properties. See Help:Editing for an introduction into datatypes and their relevance in SMW.

These special pages are particularly useful for wiki gardeners and editors, since they give some overview of how properties are used in the wiki.

These approaches all search for semantic properties of pages. To simply view existing pages about properties, categories, and types, even if unused or garbled, use MediaWiki's Special:Allpages to display all pages within these namespaces.

Additional extensions for browsing and searching

Other Semantic MediaWiki-based extensions exist to allow for browsing and searching through a wiki's data. The Semantic Drilldown extension, most notably, was developed to provide a drilldown-based approach for viewing a wiki's data; while Semantic Forms, Halo and others also provide interfaces for searching through data. See the help page on extensions for more information related to them.

External tool support

Semantic MediaWiki makes semantic knowledge available to external tools via its OWL/RDF export, and it therefore is possible to write external tools that implement further advanced browsing and searching functionality. Currently, many tools that work on RDF output are not very user-friendly yet, but the supplied data format RDF is easy to process and could be integrated in much more elaborate web or desktop applications. For more information, there is a list of tools that have been tested with Semantic MediaWiki so far. Feel free to add your own tool there as well.

#scite can not be used on a namespace that is not enabled for Semantic MediaWiki

This documentation page applies to all SMW versions from 1.3.0 to the most current version.
Other versions: 1.0 – 1.2.2       Other languages: defrjaruukzh-hans

Help:Browsing interfaces en 1.3.0

Semantic search

Warning: Display title "Semantic search" overrides earlier display title "Browsing interfaces".
Simplified example to explain the difference between condition and printout result

Semantic MediaWiki includes an easy-to-use query language which enables users to access the wiki's knowledge. The syntax of this query language is similar to the syntax of annotations in Semantic MediaWiki. This query language can be used on the special page Special:Ask, in concepts, and in inline queries. This page provides a short introduction to semantic search in general. More detailed explanations are found on other pages of this manual:

  • Help:Selecting pages: explains the basic way to describe what pages should appear in a query result. This is the core of SMW's query language.
  • Help:Displaying information: introduces printout statements as a way of showing additional information in queries, such as property values or category assignments.
  • Help:Concepts: shows how queries can be saved in concepts, which are a kind of «dynamic categories» offered by SMW.
  • Help:Inline queries: explains ways of including query results into wiki pages, and shows how to format the query results for display. This is the purpose of the SMW parser functions #ask and #show.
  • Help:Inferencing: explains how one can specify general schematic knowledge in SMW (and what this is in the first place). This feature is used by SMW to smartly deduce facts that were not directly entered into the wiki.

Naturally, answering queries requires additional resources, and the administrators of some sites can decide to switch off or restrict query features in order to ensure that even high-traffic sites can handle the additional load.


Semantic queries specify two things:

  1. Which pages to select
  2. What information to display about those pages

All queries must state some conditions that describe what is asked for. You can select pages by name, namespace, category, and most importantly by property values. For example, the query

[[Located in::Germany]]

is a query for all pages with the "Located in" property with a value of "Germany". If you enter this in Special:Ask and click "Find results", SMW executes the query and displays results as a simple table of all matching page titles. If there are many results, they can be browsed via the navigation links at the top and bottom of the query results, for example a query for all persons on

The second point is important to display more information. In the example above, one might be interested in the population of the things located in Germany. To display that on Special:Ask, one just enters the following into the printout box on the right:


and SMW displays the same page titles and the values of the Population property on those pages, if any. Printout statements may have some additional settings to further control how the property is displayed.

Selecting pages

Warning: Display title "Selecting pages" overrides earlier display title "Semantic search".
Simplified example to explain the difference between condition and printout result

The most important part of the Semantic search features in Semantic MediaWiki is a simple format for describing which pages should be displayed as the search result. Queries select wiki pages based on the information that has been specified for them using Categories, Properties, and maybe some other MediaWiki features such as a page's namespace. The following paragraphs introduce the main query features in SMW.


In the introductory example, we gave the single condition [[Located in::Germany]] to describe which pages we were interested in. The markup text is exactly what you would otherwise write to assert that some page has this property and value. Putting it in a semantic query makes SMW return all such pages. This is a general scheme: The syntax for asking for pages that satisfy some condition is exactly the syntax for explicitly asserting that this condition holds.

The following queries show what this means:

  1. [[Category:Actor]] gives all pages directly or indirectly (through a sub-, subsub-, etc. category) in the category.
  2. [[born in::Boston]] gives all pages annotated as being about someone born in Boston.
  3. [[height::180cm]] gives all pages annotated as being about someone having a height of 180cm.

By using other categories or properties than above, we can already ask for pages which have certain annotations. Next let us combine those requirements:

[[Category:Actor]] [[born in::Boston]] [[height::180cm]] 

asks for everybody who is an actor and was born in Boston and is 180cm tall. In other words: when many conditions are written into one query, the result is narrowed down to those pages that meet all the requirements. Thus we have a logical AND. By the way: queries can also include line breaks in order to make them more readable. So we could as well write:

  [[born in::Boston]] 

to get the same result as above. Note that queries only return the articles that are positively known to satisfy the required properties: if there is no property for the height of some actor, that actor will not be selected.

When specifying property values, SMW will usually ignore any initial and trailing whitespace, so the two conditions [[height::180cm]] and [[height:: 180cm ]] have the same meaning. Datatypes such as datatype number may have additional features such as ignoring commas that might be used to separate the thousands. SMW will also treat synonymous page names the same, just like MediaWiki would usually consider Semantic wiki, Semantic_wiki, and semantic wiki to refer to the same page.

If you are using certain condition patterns frequently, you might create a Concept as a shorthand. Concepts form some kind of virtual category and can thus be used similar to category conditions.

Search features

Sorting results

It is often helpful to present query results in a suitable order, for example to present a list of cities ordered by population.

 |?Located in=Country
 |?Average rainy days
 |sort=Located in,Average rainy days

Special page "Ask" has a simple interface to add one or more sorting conditions to a query ... read more.

Linking to results

Links to semantic query results on Special:Ask can be created by means of the inline query feature in SMW as explained in its documentation. It is not recommended to create links directly, since they are very lengthy and use a specific encoding. Developers who create extensions that link to Special:Ask should also use SMW's internal functions for building links. Understanding the details of SMW's encoding of queries in links is therefore not required for using SMW.

Limitations and caveats

Subqueries for properties

It is not possible to use a subquery to obtain a list of properties that is then used in a query. One can, however, use a query that returns a list of properties, and copy and paste the result into another query. Alternatively, one can use the template results format to pass properties directly to another query.

Querying for the absence of a property

It is not possible to query for the absence of a property. (talk)

Queries with special properties

SMW currently does not support queries for the values of any of SMW's built-in special properties such as "Has type", "Allows value" or "Equivalent URI".

Filtering Categories and Concepts

It is not possible to ask for all pages of a query that are not in a specific category or concept. For example, the query {{#ask: [[Category:!City]] }} will query every page in category "!City" instead of every page that is not in category "City". (talk)

See also

#scite can not be used on a namespace that is not enabled for Semantic MediaWiki
#scite can not be used on a namespace that is not enabled for Semantic MediaWiki
#scite can not be used on a namespace that is not enabled for Semantic MediaWiki
#scite can not be used on a namespace that is not enabled for Semantic MediaWiki

Displaying information

Warning: Display title "Displaying information" overrides earlier display title "Selecting pages".

Queries in Semantic MediaWiki return lists of pages. The default result simply lists the page titles. Additional information, such as a page's property values or categories, can be included into a query result by using additional printout statements.

There are different kinds of printout statements, but all of them can be recognized by the question mark ? that they start with in the query. The important difference between printout statements and query descriptions is that the former do not restrict the result set in any way, even if some printout has no values for a given page, an empty field will be printed, but the page is still part of the result.

Note, all the printout statements below are used within queries.

Printing property values

The most common form of printout statements are property printouts that display all the values assigned to a certain property. These are written simply as a question mark followed by the property name, e.g.


This prints all the values for the «population» property of the query results.

It is possible to change the label for a printout:

?population = Number of inhabitants

This still prints the values for the «population» property, but with the modified label.

As mentioned above, some properties may not be defined on some pages, e.g. if something does not have any population. Property conditions with wildcards can be used to ensure that all elements in a query result have some value for a given property, if this is desired.

Printing categories

There are two ways to print category information: either SMW prints all categories assigned to some page, or SMW checks for one particular category. The first case is achieved by the printout


where «Category» is the name of the Category namespace in the local language. This printout will show all categories that are directly used on a result page. The other option is to ask for one particular category, such as


The result then will contain a column «Actor» that contains X for all pages that directly belong to that category, and is empty otherwise. Again, one can change the label using equality:

?Category:Actor = A

will merely display an «A» as the header of the result column which might be more sensible given that the entries in that column are very short. It is also possible to change the way in which this kind of category queries are formatted, as described below.

The main result column

All queries by default display the main list of result pages in the first column. In some cases, it can be useful to move that to another position. This is not relevant for Special:Ask, but can be quite useful in inline queries. A special printout statement is available for this purpose:


This single question mark addresses the «unlabelled result column» that shows the main result list. As before, different labels can be assigned with the equality symbol, e.g.

? = Results

If you like to omit the main result column, you may use the parameter mainlabel=- (see also here).

Display format

Many printout statements can be further customized by giving a printout format which can be given after a property name, separated by the symbol #. The available formats depend on the type of the printout and involved property.

Plain (unformatted) printouts

A general format that is supported by most types of printouts is the plain format (or empty format), available since SMW 1.4.3. Printouts with this format will avoid all forms of beautification or linking in their presentation, and return a plain value instead. This is particularly useful when results are further processed in templates or parser functions. To select the plain output format, a hyphen ("-") or simply nothing is used as a printout string, as in the following examples:

?population# -
?capital #

Both printouts select the plain format. For numerical properties like the population number, the plain format is a simple number string without commas to separate digits. For properties of type page, the plain output is simply the name of the page without any link.

Note that plain printouts for properties with units (see below) will still include the unit as part of the result (A value that is a (physical) dimension consists of a number multiplied by a quantity (unit), so leaving out the unit would change the value). For this reason, two special printout formats have been added (available since 1.5.1):

Given a value of "12,345.6 km":

?my value # - gives "12345.6 km" (as expected)
?my value # -n gives "12345.6" (just the number part of the value)
?my value # -u gives "km" (just the unit part of the value)

Formats for specific printout types

Custom units

For properties that support units, queries can thus determine which unit should be used for the output. To print the height in cm, e.g., one would use the following:


this assumes that the property height is aware of the unit «cm».

The unit can be omitted all together, returning just a number (#-n), or queried on its own, returning just the unit (#-u):


Display precision

For properties that support units, queries can thus determine which display precision should be used for the output. This is possible since Semantic MediaWiki

|?Has number#-p2

Display precision can also be combined with Custom units, e.g.

|?Has number#-n-p2

See the page on <> for further examples.


For properties of type "Date", four additional output formats are available:

  1. "ISO" is available to obtain results in a technical format that conforms to the ISO 8601 standard.
    ?Has birthday#ISO
  2. "MEDIAWIKI" is available to use the MediaWiki's i18n methods for time and date formatting for the date range, typically between 1901-12-14 and 2038-01-19.
    ?Has birthday#MEDIAWIKI
  3. "LOCL" is available to use predefined value formats for time and date formatting for the date range, typically between 1901-12-14 and 2038-01-19.
    ?Has birthday#LOCL
  4. "F" is available to use freely definable value formats for time and date formatting for the date range, typically between 1901-12-14 and 2038-01-19.
    ?Has birthday#-F[F j, Y]


For properties of type "Boolean", one additional output format is available:

  1. "LOCL" is available to use localised language strings.
    ?Is cool#LOCL

Also the localised language string of a certain language may be enforced:

?Is cool#LOCL@de


For properties of type URL, one additional output format is available:

  • "nowiki" is available that escapes the URL string will to prevent MediaWiki from making a link of it. Thus it appears as a plain string in HTML and Wikitext alike.
    ?Has URL#nowiki


Other datatypes may have different printout formats. See the types documentation for details.

For printouts of the form ?Category:Actor, the display format can be used to modify what SMW will display for cases where a page is (or is not) in the category. The following is an example:

?Category:Actor#an actor, not an actor

This will show the text «an actor» for all pages that are actors, and the text «not an actor» otherwise. This can, for example, also be used in combination with small images to display icons for certain categories.

Customizing printout labels

It is also possible to style labels using basic HTML and CSS. Example:

?population = <span class="label-highlight">Number of inhabitants</span>

NoteNote:  A custom class as shown in the above example needs to be defined in the wiki's CSS, too.

Besides, one can also add tooltips to the labels by using the parser function #info. Example:

?population = Number of inhabitants {{#info:Text to be shown in a bubble.}}

Property chains and paths

The property chains and paths allows selecting pages with help of subqueries and property chain conditions. This is possible since Semantic MediaWiki

Inverse properties in printout statements

Starting with Semantic MediaWiki 2.4.0 it is possible to use inverse properties in printout statements.3. The sandbox wiki provides an example demonstrating this.4

Full-text search highlighting

Starting with Semantic MediaWiki 2.5.0 it is possible to highlight the search strings within the search results.5.

This documentation page applies to all SMW versions from 1.8.0 to the most current version.
Other versions: 1.7.0 – – – 1.5.0[…]       Other languages: deru

Help:Displaying information en 1.8.0


Warning: Display title "Concepts" overrides earlier display title "Displaying information".

It is possible to store queries in Semantic MediaWiki on dedicated pages, called concepts. These pages can be viewed as "dynamic categories", i.e. as collections of pages that are not created manually, but that are computed by SMW from the description given by a query. An example could be the concept of European cities. In traditional MediaWiki installations, one may have a category called European cities that holds all such cities. In SMW, one would instead define the concept "European cities" by saying that it contains all cities that are located in Europe. No city page needs to be changed, and yet one can create many concepts about cities (such as "capital", "Italian city", or "large coastal city located at a river").

Creating a concept

A concept is a page in the Concept: namespace that is always described by a semantic query, as explained in Help:Semantic search. For example, a concept called "Concept:Semantic Web events 2008" describes certain events in 2008. Its concept page contains the following text to do that:

 [[Start date::> Jan 1 2008]]
 [[Start date::< Dec 31 2008]] 
 |Events in the year 2008 that have been announced on 
  To add more events, go to the page "Events" on

The parser function #concept is used to define concepts. Its first parameter is a concept definition. Its second parameter is a short text that describes the concept. This description is optional and can also be left away. It is exploited in some uses of concepts in SMW to have a concise short description of the concept (e.g. as a default description in RSS feeds). The complete concept page will then show this data, and give a preview of the results.

It is possible to have other content on the concept page as well. Any normal wiki text can go before and after the use of #concept but it will not have any effect on the definition of the concept. The #concept parser function can only be used on pages in the Concept: namespace, and it can only be used once on each such page.

Using a concept

Concept pages as such can be browsed to view the contents of some concept, similar to category pages. But they can also be used in other semantic queries just like categories. For example, the following query would show all pages in the above concept of events which are also located in Germany:

 [[Concept:Semantic Web events 2008]]
 [[located in::Germany]]

Note that this would look almost the same if we would have a category called "Semantic Web events 2008". Therefore, concepts are also like stored queries that can be reused as a kind of variable in other queries if desired.

SMW's inline queries may also use concepts, and in some cases even the concept definition is used to beautify an output. Concept definitions are also included in SMW's RDF export in form of OWL class descriptions, so that other Semantic Web tools can download and reuse the concept descriptions.

Using concepts with Semantic Forms

Concepts are also a useful feature in conjunction with the Semantic Forms extension:

  1. they can be used to define the set of values suggested through autocompletion. See this help page
  2. they can also be used as a "human-readable" argument in a query form. See this help page

Concepts within concepts

Since Semantic MediaWiki 2.1.0 it is possible to use concepts within concepts,6 i.e. if one creates concept "Events in 2014" with

 |Events that happened in 2014

and concept "Events in Germany" with

 |Events that happened in Germany

these can be combined in concept "Events in Germany in 2014"

 [[Concept::Events in 2014]]
 [[Concept::Events in Germany]]
 |Events that happened in 2014 in Germany

Caching a concept

To improve performance it is advised to implement concept caching on the wiki. See this help page on how to administer this as a site administrator.

#scite can not be used on a namespace that is not enabled for Semantic MediaWiki

This documentation page applies to all SMW versions from 2.1 to the most current version.

Help:Concepts en 2.1

Inline queries

Warning: Display title "Inline queries" overrides earlier display title "Concepts".

Semantic MediaWiki includes a simple query language for semantic search, so that users can directly request certain information from the wiki. Readers who do not wish to learn the query syntax can still profit from this feature: inline queries dynamically include query results into pages. So queries created by a few editors can be consumed by many readers.

Inline queries are similar to other semantic search features, and can also be restricted on a site in order to ensure sufficient performance. Since inline queries exploit the existing caching mechanisms of MediaWiki, most requests for a page with such dynamic contents can be served without any performance impact whatsoever.

Parser function #ask

The basic way of writing an inline query is to use the parser function #ask. The query string (See selecting pages for syntax) and any printout statements are directly given as parameter, like in the following example:

 [[Located in::Germany]] 
 |?Area#km² = Size in km²

Here we query for all cities located in Germany, and two additional printout statements are used (a simple one and one with some extra settings). This displays the following result on a page:

 PopulationSize in km²
Berlin3,520,061891.85 km²
344.343 sqmi
Frankfurt679,664248.31 km²
95.872 sqmi
Munich1,353,186310.43 km²
119.857 sqmi
Stuttgart606,588207.36 km²
80.062 sqmi

It is common to put the query as the first parameter behind #ask:. All other parameters are separated by |, just like for other parser functions. The exact formatting of the inline query is not essential, but it is good to use line breaks to make it more readable to other editors. As with all templates, one line per parameter, starting with the | is most accepted in practice.

Note that all the arguments to the #ask: function are ignored by the page parsing, hence the above example does not add a category or a «located in» property annotation to this page. A few more things to note are:

  • The pipe '|' symbol is used to separate the conditions from the property to display.
  • The conditions for display are a single argument to the #ask function, so there are no '|' symbols between them.
  • White space and line breaks can be used within the #ask function, SMW is fairly flexible there.
  • The format of the results display changes when you request display of additional properties. SMW picks an appropriate default format for query results, but you also have detailed control of the appearance of query results.

Knowing the basics of query string and printout statements therefore is enough to write many kinds of queries. But there are many cases where the standard table output of a query may not be the best choice, or where further settings are desired (like the maximum number of results that should be displayed). For this purpose, inline queries have a number of other possible parameters that one can use to control their appearance in detail. The general syntax for #ask therefore is the following:

{{#ask: argument 1 | argument 2 | … }}

Most of this page explains the various arguments one may use in inline queries.

Parser function #show

A common usage of queries is to display only a single property value for a single page. For example, one could insert the population of Berlin into some article, and use a query instead of manual copying to achieve this. SMW provides a special shortcut to make such queries simpler. For example, one can write

{{#show: Berlin | ?population }}

to display the population of Berlin (Result: "3,520,061"). The function otherwise works like an inline query, and all parameters available for inline queries can also be used on #show: if desired.

The above query written with #ask looks as follows:

{{#ask: [[Berlin]] | ?population= | mainlabel=- }}
Here the "=" added to the queried property "?population" removes the display of the property label and parameter "mainlabel=" followed by the "-" symbol removes the first result column and the label of the column (Result: "3,520,061"). Without this, the result would display a table with two columns and rows:

Thus the advantage of using #show compared to #ask for querying single property values becomes visible.

Standard parameters for inline queries

In general, an inline query is a request to find a number of pages that satisfy certain requirements. The query must answer three questions:

  1. Which pages are requested? (See Selecting pages)
  2. What information should be displayed about those pages? (See Printout statements)
  3. How should the results be formatted within the page? (See Results formats)

The first two points are explained in their respective manual pages. The third point is important to smoothly include query results in pages, yet is largely independent of the first two. Without further settings, queries often produce tables like above or simple lists (if no additional printouts are used). An example of another possible format are bulleted lists, which one can create with the parameter format=ul:

 [[Located in::Germany]] 

This will produce the following output:

SMW implements a wide variety of output formats for inline queries, and allows you to further control results display using a MediaWiki template. The parameter format is one of the most important parameters for selecting the appearance of query results. See Results formats.

The following table gives an overview of common parameters that can be used in basically all queries:

Parameter Possible values Description
format a format name selected output format; some formats allow further parameters (see Help:Result formats)
limit non-negative number maximal number of pages selected (in the case of a table: rows)
offset number where to start
sort property name or a list of property names separated by , name of properties to use for sorting queries, a blank as a value stands for the main result column (see Help:Selecting pages)
order ascending/asc, descending/desc/reverse, random/rand
or a list of those if more than one property is used for sorting
defines how results should be ordered, ascending is the default, without using parameter "sort" the sort order of the main result column is set (see Help:Selecting pages)
headers show, plain, hide Show headers (with links), show headers (just text) or hide them. show is default
mainlabel plain text title of the first column (the one with the page titles in it), default is no title; set to - to suppress printing the page titles
index number defines which value within a record should be displayed, only applicable for properties of type Record
link none, subject, all defines which article names in the result are hyperlinked, all normally is the default. See also the examples page.

NoteNote:  linking can also be controlled for individual printouts using the plain output format as described in Displaying information.

default plain text if, for any reason, the query returns no results, this will be printed instead
intro plain text initial text that prepends the output, if at least some results exist
outro plain text text that is appended to the output, if at least some results exist
searchlabel plain text text for continuing the search (default is «… further results»)

In addition to the above, some formats have their own parameters that control special aspects of the format. These special settings are described in the documentation of each format.

Result limits and links to further results

You can set the parameter limit to restrict the maximum number of results that are returned. For example, the query

 [[Located in::Germany]]

displays at most 3 cities in Germany. Even if you do not specify a value for limit, SMW always applies some limit to the results a query returns. Depending on a site's settings, it might be possible to increase the number of displayed results by specifying a higher value for limit. However, there is usually a maximum limit that cannot be exceeded, set by the wiki administrator based on performance considerations. For details, see Help:Configuration.

Running the above query produces: Berlin, Cologne, Frankfurt... further results

This shows that whenever a query does not display all results due to a limit, it will normally show a link to «further results». The text of this link can be modified by setting the parameter searchlabel. If the value of searchlabel is empty, then no link to further results appears. Some output formats (see below) never display the search link, or display it only if a searchlabel was specified.

An interesting application of limit and searchlabel is to display only a link to the results of a search, without showing any result inline. You achieve this by specifying a limit of «0» or «-1». For instance, the query

{{#ask: [[Category:City]] | limit=0 | searchlabel=Click to browse a list of cities }}

displays: Click to browse a list of cities. this link will only appear if there are any results at all. In other words, SMW will still compute the query to check if there are any results. If this is not needed, or if a link should be shown in any case, one can use the limit «-1». SMW will then only print a link to further results, even if no results exist at all. This also saves some computation time on the server.

The query

{{#ask: [[Category:City]] | limit=10 | searchlabel= }}

in contrast will show a list of up to ten cities, but no link to further results, even if there are any.

Styling of further results link

Since SMW 1.9.0 it is possible to assign individual CSS styling to each result format's pending "further results" link. See the help page on styling further results for further information on this.

Introduction and default text

If no articles satisfy the conditions of a query, nothing is shown. This is sometimes a useful behavior, but often certain texts should be shown or not shown depending on whether the query has results or not. For example, one may want the query to show an output of the following form:

Upcoming conferences: SMWCon Spring 2013, SMWCon Fall 2013, …

where the list of conferences is generated by a suitable query. If the query (for whatever reason) would not return any results, the page would look as follows

Upcoming conferences:

which is not desirable. Two parameters exist to prevent this.

  • default: this parameter can be set to a default text that should be returned when no results are obtained. In the above example, one would probably write something like
Upcoming conferences: {{#ask: ... | default=none}}
so that, if no result is obtained, the article will display
Upcoming conferences: none
  • intro: this parameter specifies a text that should be prepended to the output of a query, but only if one or more results exist. In the above example, one could write
{{#ask: ... | intro=Upcoming conferences:&nbsp;}}
so that, if no result is obtained, nothing will be printed at all. Note that we use "&nbsp;" to encode the final space ("&#32;" would have worked as well), because regular whitespace is trimmed off the beginning and end of parser-function parameters.

Both of the above solutions will show the intended output if results are found. It is also possible to combine both parameters if desired. The parameters can also include MediaWiki markup, such as links or templates, as long as this does not confuse MediaWiki in recognizing the #ask function.

Also note that if the set of pages selected in a query is empty, no header row or blank line, not even any blank space, is produced. This can also be useful to «hide» queries that are not applicable. However, it is not recommended to insert great amounts of queries into every page, based on the assumption that this can do no harm since no output is generated. Indeed, answering queries requires much computational resources and should not be done without a purpose.

Using default texts for queries is also a good habit in general, since it may happen that a query will no longer have any results in some future, e.g. due to changes in the way the wiki organizes its data. Such queries that once worked properly may be forgotten so that nobody notices the query on a page laboring to display nothing.

Note that in cases you want to display only a single property value for a single page (see #show), the parameter default does not work since you are actually not querying for pages.

Sorting results

It has been explained in Help:Selecting pages that query results can be ordered by one or more properties. As explained there, Special:Ask has additional input fields to specify sort properties and ordering. In inline queries, sort properties are defined with the parameter sort, and the order can be set with the parameter order. The value of order should be «ascending», «descending» or «reverse», or one of the short forms «asc» and «desc». You can also set the value to «random» (or «rand») for ordering results in an essentially random way (this feature can be disabled by the site administrator, see Configuration). An example is the following query for the three largest cities in Germany:

 [[Located in::Germany]]

As explained in Help:Selecting pages, sorting conditions may impose restrictions on the set of query results. In the above case, only German cities that have a value for population are considered. If more than one property is used for sorting, the parameters sort and order can be set to lists of property names and orders, respectively, separated by commas. The following is an example:

 [[Located in::Germany]]

This query would return all German cities for which a state and population was specified. These results will be ordered by the name of the state they are located in (ordered alphabetically). Cities that are located in the same state will be ordered by their population, largest first («descending»).

It is also possible to explicitly define the main result column to be used for the sorting when more than one sorting condition should be used. This is done by either prepending or appending a comma to an empty statement. Example:

 [[Located in::Germany]]

This query would return all German cities for which a state was specified. These results will be ordered by the name of the state they are located in (ordered alphabetically). Cities that are located in the same state will be ordered alphabetically (descending) by their name.

Configuring labels/table headers

Queries that return more than just the selected articles (e.g. the population in the above example) will display labels that describe the various output fields. By default, the label just displays the name of the requested property, or the text «Category» if categories are displayed. Labels for properties normally display as a link to the respective pages in the Property: namespace.

In the table format, the labels appear as column headers. In other formats, the labels might appear right before the output fields. The texts used for these labels can be controlled as explained in Help:Displaying information, using the equality symbol after printouts. Example:

 |?Area#km²=Size in km²
 |?Category=Category memberships
 |default=nothing found in Category:City

This query will produce:

  Size in km²Category memberships
Amsterdam783,364219 km²
84.556 sqmi
Sample pages
Belleville43,76560 km²
23.166 sqmi
Sample pages
Berlin3,520,061891.85 km²
344.343 sqmi
Sample pages
Frankfurt679,664248.31 km²
95.872 sqmi
Sample pages
Karlsruhe294,761173.46 km²
66.973 sqmi
Sample pages
London7,825,2001,706.8 km²
658.995 sqmi
Sample pages
Munich1,353,186310.43 km²
119.857 sqmi
Sample pages
Paris2,234,105105.4 km²
40.695 sqmi
Sample pages
Porto237.58441.66 km²
16.085 sqmi
Sample pages
Rome2,761,4771,285.31 km²
496.258 sqmi
Sample pages
San Diego1,307,402963.6 km²
372.046 sqmi
Sample pages
Stuttgart606,588207.36 km²
80.062 sqmi
Sample pages
Sydney4,575,5322,058 km²
794.594 sqmi
Sample pages
Warsaw1,720,398516.9 km²
199.575 sqmi
Sample pages

It is possible to use empty printout labels or to have no label for a result column at all. In tables, however, the table header will still be shown even if all printouts use empty labels. To remove the header of a table completely, the parameter headers can be used. Three values are possible:

  • show: display labels (default)
  • plain: show labels and headers, but a plain text without links (available since SMW 1.4.3)
  • hide: hide all labels and table headers

This setting works for tables as well as for other outputs. In the latter case, the value hide will hide all printout labels, even if they have a non-empty label set in the query.

Changing the first result column

Most queries by default display the actual result pages in the first result position, e.g. as the first column in a table. The header of this column is usually blank. To change the label, or to hide the whole first column, the parameter mainlabel can be used. Normally, the text given to that parameter will simply be used as a header for the first column, for example in the query

 [[Located in::Germany]]
 |?Population=Number of inhabitants

This will produce the table:

CityNumber of inhabitants
... further results

The parameter mainlabel can also be used to completely hide the first column. This happens if the value of this parameter is set to «-» (minus symbol). To insert the list of main results at another position, the printout statement «?», i.e. the question mark without any additions, can be used. For example, modifying the example above to display the city name after Population,

 [[Located in::Germany]]
 |?Population=Number of inhabitants

This results in the table:

Number of inhabitantsCity
... further results

Result formats

The parameter format determines how the results of a query are displayed in the article. For more info, see the Result formats page.

Exporting query results

Some SMW's result formats (csv, csv, dsv, dsv, feed, json, json, rdf, rdf) enable data export from the wiki. In addition, other formats defined by the Semantic Result Formats extension (bibtex, excel, icalendar, vcard) also enable data export. These formats differ from other formats in two ways:

  1. Instead of displaying data on the page, they produce only a link to Special:Ask, which in turn outputs the data in a downloadable form. (This link is similar to the normal «further results» link, though it uses different default text, like «RSS»; it is possible to change the link text with the parameter searchlabel.)
  2. They use fixed standard formats for exporting (non-fixed, free-form) wiki content. Hence, for formats other than CSV and DSV, it must be explained which wiki properties belong to which part of the data export format.

The second point makes it necessary to relate printout statements (properties) to the data fields available in the export format. For example, vCard is a data format that can encode many kinds of contact data about a person, but it cannot represent arbitrary properties. To specify which wiki properties belong to which of the available data fields, the label of the property printout is used. For example, vCard supports (among many others) the data fields «firstname», «lastname» and «homepage». A query could thus be

 |?Url = homepage

Here the wiki would have properties called «firstname» and «lastname», but the homepage of a person is stored in a property called «url». The label «homepage» is given to the latter so that vCard recognizes the special meaning of this property. With this method, wikis can use arbitrary property names (in any language) and still export to standard formats. See the pages of the above formats for details on the data fields they support.

Updating of inline queries

Avoid Self-Referencing

See Help:Self-Referencing for information about how using an inline query for a property set on the same page can cause unexpected behavior.

Related tips

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

Help:Inline queries en 1.7.0


Warning: Display title "Inferencing" overrides earlier display title "Inline queries".

Semantic search can be used to find pages based on the information that users have entered about them into the wiki. This simplifies many tasks, but it still requires that semantic information is entered manually in the first place. In some cases, one would expect the wiki to be «smarter» and to deduce some facts even if they were not entered directly. In some cases, SMW can draw such inferences automatically, as described in this article.


MediaWiki supports a hierarchy of categories that helps to simplify the category statements needed on each page. As an example, assume that a wiki uses categories «Person», «Woman», and «Man». It is obvious to a human that every page that belongs to the category «Woman» should also belong to the category «Person». But «Woman» is clearly more specific, and many wikis (including Wikipedia) have a policy to use only the most specific categories on some page — otherwise the page would often have to contain dozens of categories that are hard to maintain. To indicate that one category is more specific than another, MediaWiki supports a category hierarchy where users can state that one category is a subcategory of another, simply by putting a category on the subcategory's page, e.g. the page Category:Woman could contain the text


For details, see the MediaWiki handbook.

By default, SMW uses this subcategory information in semantic queries: when asking for all pages that belong to a category, it will also find all pages that belong to any subcategory of that category. In the above example, the query [[Category:Person]] would also return the pages in categories «Man» and «Woman». In other words, the actual query corresponds to

[[Category:Person]] OR [[Category:Woman]] OR [[Category:Man]]

If the category hierarchy is deeper, then SMW will also include further subcategories. For example, one may have a category «Mother» of all women that have children, and this again would be a subcategory of «Woman». Then the above query would retrieve all pages in category «Mother» as well.

SMW's mechanism of subcategory inferencing can be restricted or disabled by the site administrator. Normally, it supports only a certain maximal depth of category hierarchies, so it may not return all results if there are very long chains of subcategories involved. Using a manually created query with OR as above is a work-around in this case, but it does of course not take into account any changes in the category hierarchy.

In some cases, wikis use categories and category hierarchies that are not suitable for being treated in the above way. For example, Wikipedia uses a category called «Cities» not for collecting all cities but for all articles that are related in some ways to cities. Even the category «Cities in Canada» is used to collect all pages that have some relationship with that topic. This is not an actual problem of categories or category hierarchies: the semantic query [[Category:Cities]] still returns all pages related to that topic, it just does not return actual cities only. So one might argue that the name of the category is confusing in some sense, but this is merely a matter of how to organise a wiki. If a wiki has no category for actual cities as such, then no semantic query can produce all cities directly.

A more serious problem in large wikis might be what is called «semantic drift». This occurs if the exact intention of some category is not really specified, e.g. because it lacks a detailed description on its page. Different users then may have slightly different readings of the categories meaning, and this may influence how they use sub-category statements. For example, some editors may reasonably say that «Priest» is a subcategory of «Religious office» (referring to the job category), while others may deem «Female priest» to be a subcategory of «Priest» (referring to the class of people having that job) – but this would imply that all pages in «Female priest» are also implicitly categorised in «Religious office», thus confusing people and job occupations. It is therefore important to always clearly describe on a category page what should go into a category and what shouldn't, and also to point to alternative categories that may be suitable.

Since Semantic MediaWiki 3.0.0Released on an unknown date and compatible with MW 1.27.0 - 1.30.x. it is possible to limit the resolving of hierarchies for individual queries using the query condition |+depth=.


Just like categories, also properties can be more specific than one another. For example, a wiki may have the property «capital of» to relate cities to countries, and a property «located in» that generally describes that some city is located in some country. Now it happens to be the case that every capital city also must be located in the country that it is capital of. In other words, «capital of» is a subproperty of «located in». Whenever a user states that a page is a capital of some country, SMW should then also conclude that the page has an (implicit) «located in» relation to that country as well. To say that in the wiki, the following can be entered on the page Property:Capital of:

[[subproperty of::Property:located in]]

Once this has been stated, a query [[located in::Germany]] will also return the capital Berlin even if no «located in» property is given on that page. Similar considerations as in the case of categories apply, and detailed descriptions on property pages are a good method for avoiding semantic drift.

Since Semantic MediaWiki 3.0.0Released on an unknown date and compatible with MW 1.27.0 - 1.30.x. it is possible to limit the resolving of hierarchies for individual queries using the query condition |+depth=.

Equality of pages: redirects

It often happens that a thing can be referred to by different names, such as in the case of "Semantic MediaWiki", which is synonymous with "Semantic MediaWiki". In MediaWiki, this is solved by redirects that forward readers from one page to another. But synonyms may be even more important in a semantic wiki, where one wishes to organise content and make it more accessible. If different editors use different page names in annotations, then it is hard to create queries which will still display a unified view on the wiki content.

SMW therefore treats all redirects between pages as synonyms. This means that it does not matter at all whether a redirect page or the actual target page is used in a query or annotation. SMW internally uses only redirect targets to work with, and all functions will take the redirect structure into account. This mechanism works only for immediate redirects: redirects that point to other redirect pages are not supported and should be resolved (this is also the case in MediaWiki anyway).

Since SMW 1.2, it is also possible to use redirect on properties and categories with the same effect, so multiple synonyms for properties can be created. It is not suggested to use that feature for the case of categories, though, simply because MediaWiki's category functions will still ignore category redirects such that some wiki features will not work as expected. Redirects between two different namespaces, such as redirects from normal pages to properties, properties to categories, etc. are not supported in a special semantic way. They still create normal MediaWiki redirect pages but nothing else.

Inferencing and printout statements

Printout statements do generally not perform any inferencing, i.e. they will only return the statements that are explicitly made for some page. This is desired in some situations, and it may be a limitation in others. A work-around can be to use a template for annotation, and to give two property values explicitly in that template, essentially by writing something like

[[capital of::located in::Germany]]

which is the same as writing [[capital of::Germany]] and [[located in::Germany]], but it will show only one link to Germany.

Inferencing features that are not supported

It sometimes happens that ambitious contributors in a wiki will create properties that also suggest a specific meaning for automated deduction. It should therefore be noted that SMW does not support any of the following features:

  • Transitivity
  • Domain and range restrictions
  • Number restrictions and functional properties

Even if properties that sound like the above are introduced, and even if these are linked to well-known properties in ontology languages such as OWL, RDFS, SKOS, etc., SMW will not use these annotations to perform smarter queries. To prevent confusion, it is suggested to not use names that resemble established notions in existing ontology languages, or at least to clearly document this limitation on the property pages.

To some extent, one may be able to craft queries to achieve a similar effect. The sample pages Germany and California show examples of queries for inverse relationships; the sample page Germany shows an example of a subquery that approximates a transitive relationship to some extent.

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

Help:Inferencing en 1.5.0


Warning: Display title "Editing" overrides earlier display title "Inferencing".

This section explains how to edit pages in Semantic MediaWiki. As explained in the introduction, SMW introduces special markup elements which allow editors to provide «hints» to computer programs on how to interpret some piece of information given in the wiki. Such hints are called semantic annotations and they are created with a special markup of SMW. Besides this, editing in SMW is just the same as in MediaWiki. Users who are not familiar with basic editing yet, should first read about how to edit pages in MediaWiki. Editors may or may not provide annotations on wiki pages as they like – it is an added feature that is completely voluntary.

Classification and semantic annotations

Some annotations being edited using the wikiEditor

Annotations in Semantic MediaWiki can be viewed as an extension of the existing category system in MediaWiki. Categories are a means to classify articles according to certain criteria. For example, by adding [[Category:Cities]] to an article, the page is tagged as describing a city. MediaWiki can use this information to generate a list of all cities in a wiki, and thus help users to browse the information.


Semantic MediaWiki provides a further means of structuring the wiki. Wiki pages have links and text values in them, but only a human reader knows what the link or text represents. For example, «is the capital of Germany with a population of 3,396,990» means something very different from «plays football for Germany and earns 3,396,990 dollars a year». SMW allows you to annotate any link or text on the page to describe the meaning of the hyperlink or text. This turns links and text into explicit properties of an article. The property capital of is different from on national football team of, just as the property population is different from annual income.

This addition enables users to go beyond mere categorisation of articles. Usage and possible problems with using these features are similar to the existing category system. Since categories and properties merely emphasize a particular part of an article's content, they are often called (semantic) annotations. Information that was provided in an article anyway, e.g. that Berlin is the capital of Germany, is now provided in a formal way accessible to software tools.

The user manual explains basic annotations with properties, the creation of custom units for numerical properties, and the use of MediaWiki templates to simplify annotation.

Besides annotations, SMW also allows editors to embed semantic queries into articles. Thereby, readers of the wiki can view ready-made query results without having to learn the SMW query language. This feature is explained in the section on inline queries.


Categories are an editing feature of MediaWiki, and the main reference for their use is the MediaWiki documentation on categories. Categories are used as universal "tags" for articles, describing that the article belongs to a certain group of articles. To add an article to a category Example category, just write

[[Category:Example category]]

anywhere in the article. The name of the category (here, "Example category") is arbitrary but, of course, you should try to use categories that already exist instead of creating new ones. Every page can be assigned to a category by writing [[Category:Example category]] anywhere in the source text of the page. The category's article can be empty, but it is strongly recommended to add a description that explains which articles should go into the category.

On wikis like Wikipedia, categories are used for many different purposes. For example, the Cities category contains both individual cities, related subcategories like "City nicknames" and abstract concepts like "Digital city".

In Semantic MediaWiki-using sites, categories tend to be used much more sparingly, since inline queries make many categories superfluous. For example, a subcategory like Large cities could be replaced by a query for articles with Category:Cities with an area larger than 10 km², or a population larger than 1,000,000. In addition, categories tend to be used more exactly: a page like "Digital city" might end up in a category like "City-related terms" instead of "Cities", so that it wouldn't show up in a query on the "Cities" category.

See also

Properties and types

Warning: Display title "Properties and types" overrides earlier display title "Editing".

Properties and types (datatypes) 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.

List of topics

Related topics

Custom units

Warning: Display title "Custom units" overrides earlier display title "Properties and types".

This page explains ways that pages can have more control over the display and conversion of units, in particular for properties of datatype Quantity. This feature makes annotation more flexible: everybody can view and enter data in his or her preferred unit without restricting mutual understanding. For example, some people might prefer a distance given in "miles" over one given in "km". In other cases, it might not be suitable to display a distance in "km" if "microns" are more appropriate.

Datatypes and properties with unit conversions

SMW has built-in support for some types that can handle units (e.g. Temperature). Types that support units can accept, convert, and display values in several different units. You can see this in the factbox of articles like "Berlin", where the area is given in multiple units.

In order to support such features, SMW needs to know how to convert values from one unit into another. This is rather easy in many cases, but can also involve more complex computation in other situations. We distinguish two cases:

  1. Conversion between the desired units is proportional, i.e. you just have to multiply one value with a fixed conversion factor to get the value in another unit. For example, this is the case for converting between kilometres and miles.
  2. Conversion between units is not proportional and more complex computations are needed. For example, this occurs for temperatures, since you need to add and multiply in order to get from °C to °F.

For all unit conversions of the first kind, the datatype Quantity can be used to define units and conversion factors for properties in the wiki. For the second situation, we discuss some possibilities below.

Converting between proportional units

SMW provides the datatype Quantity for declaring properties whose values consist of a number together with a unit of measurement. A "unit" can be any text label that does not start with a number, such as "miles", "km²", or "m/s". To make a unit (or an alternative writing of a unit) available, it must first be declared on the page of the property as explained below. Only declared units can be used, all others will be rejected as input errors. Therefore a property of type Quantity is of little use until at least one unit has been declared. The advantage of this strict system is that SMW can compare property values among each other, even if different units have been used to write them. Every input value clearly specifies a "quantity" (like an amount of time or a distance) that is understood even if written in a variety of ways. The property value is really such a quantity (and this is what is stored), not the particular text that has been used to write it on some wiki page (this text or its original unit is not stored). We already have seen a similar behavior for other datatypes, for example SMW does not store whether a number was written as "2" or "2.0" but always treat it as the same number.

To use the unit conversion in SMW, you first need to create a suitable property. As usual, you may first want to use the wiki search and Special:Properties to check if there already is a property that serves your purpose. If not, create a new article in the property namespace. For example, suppose that we want to introduce a Property:Power to measure the physical quantity of power. In the new article, you should first write some sentences on the purpose and use of this new property. In our case this would say that we mean the physical quantity that is usually measured in Watt. This also helps others to find and reuse your type when searching for keywords. To specify the datatype, you can add the annotation

[[has type::quantity]]

somewhere on the page (ideally in a sentence). To declare the supported units, you use a special property corresponds to. For example, to specify the main unit of the new datatype for power, we add

[[Corresponds to::1 W]]

The value "1 W" states two things: (1) the type understands the unit "W" and (2) the unit "W" is its main unit (that is what the "1" is for). The main unit is the default choice for displaying values of this datatype, and it is assumed whenever the user enters a plain number without giving any unit. It is easy to specify further units, e.g.

[[Corresponds to::0.001 kW]]
[[Corresponds to::0.0013410220 hp]].

This says that the type also understands the units "kW" and "hp". Now reading the annotations makes more sense: 1 W corresponds to 0.001 kW which in turn corresponds to 0.0013410220 hp. In this way, you can support arbitrary units, so long as their relationship to the main unit can be described in this easy manner.

In many cases, there are multiple ways of referring to one unit. For instance we would like to allow users to write "W" as well as "Watt" and maybe even "Watts". A short way of doing this is to separate additional units with "," instead of making multiple "corresponds to" statements with the same factor. For example we would write:

[[Corresponds to::1 W, Watt, Watts]]
[[Corresponds to::0.0013410220 hp,bhp,horsepower]]

In this case, the main unit is the very first unit in the "corresponds to" statement for 1, in our example "W". The property will understand all the units defined in "corresponds to" statements, and will show conversions between them (without duplicates, i.e. SMW does not display "W" and "Watt").

Internally, the values will all be converted to the main unit, and the RDF export will only show the value in this unit. Inputs that do not include a unit at all are always understood as values in the main unit. From this viewpoint, unit conversion is simply a kind of pre-processing (of user inputs) and post-processing (for display) that makes it easier for users to deal with units. The display of units within the wiki is highly customizable and need not involve the main unit, see below.

Hint: If many properties use the same unit declarations (e.g. "Property:Width" and "Property:Height") then it is a good idea to put the unit declarations into a template that can be included on all property pages. In this way it can be ensured that properties that measure the same quantity do always support the same units.

Note: Units must always be written after the number in a property value. Prefix units like in "$100" are not supported.

Unit conversions that are not proportional

With the datatype Quantity you can only specify a proportional conversion factor, a multiplier. So you cannot have different bases for different units, logarithmic scale conversions, etc. For example, you cannot define a custom conversion for properties that should convert temperatures from degrees Celsius to Fahrenheit (a conversion that involves not only multiplication but also addition). However, in the case of temperature, SMW already supplies a built-in datatype Temperature that handles this conversion, but this might not be true in other cases.

SMW does not allow specifying customized non-proportional units in the wiki. One workaround for this is to use datatype Number and to omit the unit in the annotation and only write it in the wiki text. This removes the convenient pre- and post-processing features of unit support but offers the same power in terms of most other features (queries, export, etc.). One could also use a template with parser functions to implement certain unit conversions, but this usually leads to complicated wiki text and less efficient processing.

A better solution if a new unit is really needed is to write a small PHP script that implements the required conversion. It is not difficult to extend SMW in this fashion, and one could simply copy and adjust the code for Type:Temperature (which is only a little longer than 100 lines, including comments). Upon implementing such a custom type, existing properties of Type:Number can be changed to the new type without any negative effects on existing articles. When confronted with unsupported units, custom types will still behave like simple number datatypes.

Customizing the display of units

A single property can support a broad range of units. For example, a single length property can easily support both light years and nanometers. Even if only some of these units are needed in a particular property, it still might be useful to declare all relevant units in a template as described above. However, if someone uses a property "Elevation" to specify the height of a mountain, then it would hardly be useful to display this value in light years or nanometers.

SMW therefore allows you to specify which units a property should display from all the units that it supports. If no preferences on display are given, a property will display all of its units, with the main unit (the one with conversion factor 1) first.

To specify custom display units, add the special property display units to the property's page, mentioning each unit you want displayed separated by commas. For example, the article Property:Height could contain the statements:

[[display units::km,ft,miles]]

This results in the factbox displaying only those three units for values of the property Height, even though it might support a dozen of other units. Similarly, the tooltip for each such value will show those conversions. This customization works for all properties that use types with unit support.

If you change the first display unit, consider displaying the main unit to users as one of the other display units, since SMW still converts values to the main unit when storing them.

Unit labels

The use of spaces within unit labels has been addressed in #1718.

Custom units in earlier versions of SMW

Up to SMW 1.5.6, datatypes had their own wiki pages and custom units were declared on a datatype page, not on the property page. Additionally it was possible to define custom datatypes. The datatype Quantity did not exist and the both the datatype Number and all custom unit conversion types would accept unknown units as inputs. This has been changed to the current system for simplifying the whole process (one namespace less, less pages, less special cases). To re-use unit declarations on many property pages like in the old system, unit declarations can simply be put into templates that are included on many property pages.

See Help:Custom units 1.5 for a documentation of the old system.

This documentation page applies to all SMW versions from 1.6.0 to the most current version.
Other versions: 1.0 – 1.5.6       Other languages: deukzh-hans

Help:Custom units en 1.6.0

Semantic templates

Warning: Display title "Semantic templates" overrides earlier display title "Custom units".

Semantic templates are a method of including the markup that Semantic MediaWiki introduces through MediaWiki templates. This has several advantages:

  • users can specify annotations without learning any new syntax
  • annotations are used consistently, i.e. users do not have to look for the right properties or categories when editing a page
  • infobox-style templates provide data structure, by defining which values belong in which pages
  • infobox-style templates also often provide a nice display for the data

For these reasons, semantic templates are a very popular way of handling semantic annotations. In most wikis, semantic data is stored only via templates - in fact, we would estimate that 99% of all SMW data that currently exists is stored via a template. Even SMW-based extensions meant to make free-form SMW annotations easier, like Halo, do it within the context of a system in which data is also stored using templates.

Infobox-style semantic templates

Many MediaWiki sites, SMW-based and otherwise, make use of infobox-style templates to present standard information. For example, Wikipedia articles on cities and villages use a standard template in which editors specify common items of information, such as this (from the article "San Diego, California"):

{{Infobox Settlement
|image_skyline        = Sandiego_skyline_at_night.JPG?
|imagesize            = 
|image_caption        = San Diego Skyline | March 31, 2007
|official_name        = City of San Diego
|settlement_type      = [[City]]
|nickname             = America's Finest City
|motto                = Semper Vigilans ([[Latin]]: Ever Vigilant)
|image_flag           = Flag of San Diego, California.svg

Usually the template (in this case, Infobox Settlement) displays this information in a nicely-formatted table. Such regular templatized items of information are ideal to be mapped into properties in Semantic MediaWiki, with each field being stored using a separate property.

The sample page California shows a simple "infobox" display template that includes semantic annotations.

Inline semantic templates

You can also use semantic templates anywhere within a page's text, for special cases. For example, when giving the value for surface area of an astronomical object in a wiki page, you might want it to display as

6.088 × 1018 m²

which you can achieve by writing

 6.088 × 10<sup>18</sup> m²

This is cumbersome to write, so you might develop a "Template:Surface area" for areas so that editors can simply write

 {{Surface area|6.088|18}}

and the template expands to your desired markup.

To achieve this, template "Surface area" is coded as follows:

 [[Surface area::{{{1}}}e{{{2}}} m²|{{{1}}} × 10<sup>{{{2}}}</sup> m²]]

This template handles both storing the value semantically (via the "Surface area" property tag), and displaying it a nicely-formatted way on the screen (via everything that comes after the "|" in the tag).

See the sample page Sol and view its source to see this template in use.

Using semantic templates correctly

While the above pattern allows you to create all kinds of semantic templates of arbitrary complexity, there are some issues to consider.

Automatic annotation requires strict formats

You can annotate template fields automatically, but in this case the supplied values must adhere to the expected format. For example, it makes sense to store the population of a city with a property of type Number. Still, the value that users enter might not be a number - it could be a piece of text like "Around 1 million". Wikipedia notably has many such exceptions: in the main infobox template at France, for instance, the entry supplied for population is not a single number, or even a set of numbers! Instead, there are multiple numbers and textual explanations of their meaning. Such special cases should be kept in mind when designing semantic templates.

Optional entries and conditionals

In the normal course of operating a wiki, most pages will probably not have their infoboxes completely filled, and you might not want to show empty rows in such cases. To remove rows with blank values, you can add conditionals into the template code, which include a row (and its annotation) only if a non-empty value was provided.

This can be achieved with the help of the #if parser function, defined in the MediaWiki ParserFunctions extension. Wikipedia contains many examples of parser functions in templates, as for instance in template "Taxobox". Using parser functions typically results in difficult-to-read template code, but the simplification for users can be substantial.

Queries in templates

Inline queries are sometimes added to templates as well, and they almost always contain the {{PAGENAME}} variable; see e.g. template "Ask". Such queries are usuallly used to aggregate a set of pages that have some property pointing to the page in question, such as the template for a country page using a query to show a list of each country's cities.

Annotating a template

You can also add annotations directly to templates, i.e. assign them semantic properties directly. Though this is not recommended, since templates don't represent a real-world entity, it can be done, if the site administrator enables it.

Editing template calls

A popular extension, Page Forms (formally known as Semantic Forms), lets users add and edit calls to infobox-style templates using forms. See also the list of extensions to SMW.

This documentation page applies to all SMW versions from 1.0 to the most current version.
      Other languages: defrjanlruukzh-hans

Help:Semantic templates en 1.0

Service links

Warning: Display title "Service links" overrides earlier display title "Semantic templates".

Semantic MediaWiki can provide links to online services when printing certain data in the factbox, on special page Browse and on property pages.

For example, when an article contains a geographic coordinate, it is useful to provide links to online mapping services so that users can retrieve a map of that location with one click. Another example is to provide a link to an online currency converter for financial amounts. This page explains how you can add such features to a semantic wiki.

Service links for properties

The information for additional links to online services in the factbox and on special page Browse is associated with the property used. For example, this wiki's Property:Has coordinates will show various links to online maps in the factbox and on special page Browse, if it is used on a wikipage, whereas other properties that also use datatype Geographic coordinate might not show this. This is crucial in many applications, since the datatype alone usually does not say much about the type of link. For example a property "IMDb number" of datatype Number might be used for a movie's id number at IMDb, but not every property of datatype Number should display a link to IMDb.

To make a property display service links, add the special property provides service on its page. For example, the page Property:Has coordinates might include the annotation

[[provides service::online maps]]

Here, "online maps" is the name of a set of service links provided by the wiki. The next section explains how you specify these service links.

After you specify that a property provides service links, its property values in the factbox, on special page Browse and on the property's own page will show an icon (icon for service links) that displays the service links when clicked. NoteNote:  As of Semantic MediaWiki 2.1 service links will no longer be shown within the factbox since the labelling of the link was user unfriendly (broken).

Providing service links

In a nutshell, a wiki administrator puts the text specifying the appearance of service links in a system message article in the "MediaWiki" namespace.

Normally only users that have sysop (administrator) privileges in the wiki can add or edit pages in the MediaWiki namespace, hence only they can modify service links. This is a reasonable restriction for most wikis: since service links may appear in thousands of factboxes, they need to be trusted. Adding or modifying services should usually be discussed among many users before an administrator puts the change into practice.

All users, however, are free to associate properties with available services as described above.

Name of the system message

The format for the system message is MediaWiki:Smw service service name. The part "MediaWiki:Smw service" always remains unchanged while the service name changes with every system message providing a service link.

Continuing our example for Has coordinates, the text for [[Provides service::online maps]] is in the message name MediaWiki:Smw service online maps.

Content of the system message

If you look at MediaWiki:Smw service online maps, though the message might be hard to read due to the long lines, its format essentially is as follows:

 label text1|
 label text2|

Every line contains one service link. The label is the text that users will see in the service link pop-up. After the pipe symbol '|' is the URL that the link will lead to. For better comprehension, please click on "View source" at the top of the page to see the raw text of the page.

Placeholders in the system message

In most cases, you want to provide information from the property value in the link. For example, a link to an online map service has to include the coordinates to display, and a link to a movie web site will have to include the ID of the movie. Since the exact data values are not known in advance, you use placeholders of the form $1, $2, $3, etc., in the URL. For example, the message text for a service link to IMDb could be:


When SMW displays the service links for a property value, it substitutes the property value's information for these placeholders. In this IMDB example, a movie ID of Type:Number will replace $1 with the numeric value, and voilà, the service link for a movie links to its information on IMDB, e.g. "0019254" to!

Information passed for each placeholder

The number and contents of the parameters that replace $1, $2, $3, … depend on the datatype of the property. For instance, a simple property of datatype number replaces $1 with its value, whereas a geographic coordinate provides parameters for latitude, longitude, direction, and much more. In most cases, $1 is the most relevant parameter that just provides a URL-safe string version of the property value. The datatypes listed below support service links. All other datatypes do not support service links.

Help:Type Page
$1: URL-encoded article name (no namespace), with underscores replaced by spaces
Help:Type Number
$1: numerical value in English punctuation
$2: integer version of value, in English punctuation
$3: From SMW version 1.1 onwards unit, if any.
Help:Type String (but not Help:Type Text)
$1: URL-encoded string
Help:Type URL, Help:Type Annotation URI
$1: URL-encoded value of the URL
Help:Type Email
$1: URL-encoded value of the URL including mailto:
Help:Type Geographic coordinate
Note: You need Maps (formerly Semantic Maps) 0.6.5 and SMW 1.5.1 or later for this.
$1: The location in non-directional float notation.
$2: The location in directional DMS notation.
$3: The latitude in non-directional float notation.
$4: The longitude in non-directional float notation.

Since geographic coordinates are complex, a sample content for the default message MediaWiki:Smw service online maps is provided on this wiki.

Extended example

To illustrate the whole process of creating and using a new service, we provide an extended example, also implemented on Articles about Semantic Web vocabularies such as FOAF contain information about the vocabulary's "namespace" and the online service Swoogle allows users to search for background information on such namespaces. Our goal thus is to add a new "Swoogle service" to the Property:Namespace that is used on the vocabularies articles.

As a first step, we edit the page Property:Namespace and add the line
As an additional service, this property provides a [[provides service::Swoogle lookup]] of the entered namespace.
After saving, the factbox shows a link to the (still non-existing) service Swoogle lookup. Clicking this link, an administrator gets a new edit field, into which she enters
Swoogle lookup|$1

The link was retrieved by using Swoogle and replacing the search string (at the end of the link) with the parameter "$1".

After those changes are saved, the new service is fully functional, and each page that uses Property:Namespace will show a suitable link to Swoogle. Some articles will still show the old version, if they are retrieved from cache, but after the next edit or purge, all articles will display the links as expected.

This documentation page applies to all SMW versions from 1.0 to the most current version.
      Other languages: defrukzh-hans

Help:Service links en 1.0

Annotation naming guideline

Wiki todo: Expand this page!

Semantic Web

Warning: Display title "Semantic Web" overrides earlier display title "Service links".

Although Semantic MediaWiki is designed to be used without additional technical background knowledge, it is closely related to well-known Semantic Web technologies. These technologies enable the wiki to share its knowledge with external applications by encoding it into the standard OWL/RDF format. Below is an overview of some related resources. These should be instructive for those who are familiar with semantic technologies or who wish to implement tools that use Semantic MediaWiki's RDF export. Normal users should go to the user manual to find help on using the wiki.

RDF export

The explicit semantic content of Semantic MediaWiki is formally interpreted in the OWL DL ontology language, and is made available in OWL/RDF format. For further details on the exported format, see Help:RDF export.

Reusing vocabulary from external ontologies

Normally, all statements in the wiki refer to concepts and properties defined in the wiki, but it is also possible to directly use vocabulary from other sources. E.g. this wiki imports a number of semweb:FOAF elements for use within the wiki. A detailed description of how to use this feature is given in the article on vocabulary import.

SPARQL query service

The site can be configured to provide a SPARQL endpoint that enables expressive querying against the wiki's content. The wiki is primarily used for authoring "ABox" statements (i.e. simple facts concerning given individuals in contrast to complex schema information).

External reuse

Tools that can process OWL/RDF in a meaningful way (including many RDF tools), can also be used with Semantic MediaWiki. Help:Reuse lists a number of applications that have been tested with the wiki's output on one site or the other.

This documentation page applies to all SMW versions from 1.0 to the most current version.
      Other languages: defrruukzh-hans

Help:Semantic Web en 1.0

RDF export

Warning: Display title "RDF export" overrides earlier display title "Semantic Web". Based on the user's semantic annotations of articles, Semantic MediaWiki generates machine-readable documents in OWL/RDF format, that can be accessed via Special:ExportRDF. Moreover, there is a maintenance script for automatically generating complete exports of all semantic data. This article explains how annotations are formally interpreted in the OWL ontology language, and how a suitable RDF serialisation is generated.

Using the export functionality

Users can easily access the generated RDF via the page Special:ExportRDF by entering a list of articles into the input field. The export will contain one OWL/RDF specification with various description blocks for exported elements. In addition to the requested articles, the export will also contain basic declarations for any further elements (such as mentioned instances, properties, and classes). There are two settings that further influence the set of exported articles:

  • Recursive export
    Every article usually has relations to various other articles. Normally, those other articles are just declared briefly such that tools can find further RDF specifications for them if desired. By enabling recursive export, all information about the encountered objects will be exported right away. Since this process is continued for all further objects, this option can lead to large results.
  • Backlinks
    The RDF data model is based on directed graphs. When exporting an article, one usually exports only the statements within which the corresponding element occurs as a subject, and the exported document does not include incoming links. This restricts RDF browsers, since they cannot access all elements that have some relationship to something without retrieving the whole RDF first. For this reason, one can enable the export of backlinks. All articles that have relations to any of the exported articles then will also be exported.

The server administrator can restrict the availability of the above options, and can set default values cases where no parameters can be given (see below). The reason is that the above options, especially in combination, can easily lead to the export of major parts of the wiki in RDF, which might overly impair the performance of large sites.

In addition to the form at Special:ExportRDF, one can also retrieve RDF by calling appropriate URLs directly. This is suitable for linking to RDF specifications directly. In its basic form, this is achieved by appending a (URL encoded version of an) article name to the URL of the export service. For instance, one can link to

to get this RDF directly. Alternatively, the article name can also be specified as a GET parameter "page" within the URL, e.g.
Additional GET parameters

In addition to title and page, ExportRDF has additional GET (query string) parameters:

  • Recursive export can be enabled or disabled by setting "recursive" to 1 or 0.
  • Backlinks can be enabled or disabled by setting "backlinks" to 1 or 0, respectively.


Both settings will be ignored if disabled by the administrator. If no settings are given, site-wide default values apply ($smwgAllowRecursiveExport = false and $smwgExportBacklinks = true). For example, the wiki always exports RDF with backlinks.

The default Content-Type of ExportRDF's output is application/xml (with charset=UTF-8). Content-Type application/rdf+xml can be set by adding the "xmlmime=rdf" GET parameter; some processing tools require this RDF mimetype to process the output, e.g.

Exporting all data

In addition to the wiki's Special:ExportRDF function, there is also a maintenance script that allows you to export all of the wiki's semantic data at once. The script is called dumpRDF.php. The script dumpRDF.php can generate full exports, or it can be restricted to certain elements of the schema, e.g. to export only the category hierarchy or only the attributes with their types.

The script can easily be run automatically as a cronjob to generate RDF dumps on a regular basis.

The exported data in detail

Mapping wiki-pages to ontology elements

The export distinguishes the page in the wiki and the "thing" that the page discusses. ... TODO

It is possible to import an external vocabulary (such as foaf or Dublin Core) into Semantic MediaWiki and associate attributes and relations in SMW with the external vocabulary, so that in RDF export the SMW attributes and relations export as properties in the external vocabulary (such as foaf:knows or skos:concept).


MediaWiki category relations are exported using existing RDF/RDFS properties. In brief:

  • A category assignment in a regular article is exported as rdf:type which states "is an instance of a class". So use of MediaWiki categories is a good match for "is a" in the sense of "San Diego is an instance of the class Cities".
  • A category assignment in a Category article is exported as rdfs:subClassOf which states "all the instances of one class are instances of another". So use of MediaWiki categories within categories is a good match for "is a" in the sense of "all instances of Divided cities are Cities".

There are many usages of MediaWiki categories that conflict with these semantics. For example, the article Urban decay might be in category Cities, but it is not a city. And Category:City museums might be in category Cities, but city museums are not cities.

Restrictions for OWL DL

... TODO

This documentation page applies to all SMW versions from 1.0 to the most current version.
      Other languages: dezh-hans

Help:RDF export en 1.0


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

Importing vocabulary

SMW admin manual
Table of Contents

A number of Semantic Web tools can immediately be used with the RDF export of Semantic MediaWiki. This page lists various tools that have been tested with SMW and explains what features they offer.

  • The Geocoding Tools for Python provide a simple toolkit for obtaining the geographic coordinates of places in the real world. For example, you can find out the location of some building you are at by providing the buildings name. The name is looked up in various sources, including Semantic MediaWikis, and the location is returned. Further located in statements are used to infer the location of sub-locations.
  • Tabulator is an online browser for RDF documents available at Using it on external resources such as requires a change in security settings of the browser, since JavaScript must be enabled to access external sites. After this is done, RDF of can be loaded conveniently by loading the URL of some RDF export, e.g. ESWC2006. The interface is still somewhat crude, but the tool shows that dynamic interfaces for browsing RDF and RDF-enabled sites are feasible. Tabulator takes advantage of Semantic MediaWiki's feature of creating browsable RDF which includes "backlinks" in RDF triples as well.
  • Longwell is a Java-based facetted browser for RDF. It includes features for browsing, querying and query refinement, Timeline support and graphical presentation of RDF graphs. It works very well with the RDF generated by Semantic MediaWiki and its faceted browsing capabilities provide some real added value for the semantic data. It is available online via
  • Piggy Bank is a browser extension for Firefox available at Semantic MediaWiki refers to a page's RDF specification within its HTML header so that Piggy Bank can find it. In effect, Piggy Bank will collect RDF of all visited articles during browsing. Of course, the further use of this RDF, as in all applications of Piggy Bank, is left to the user.
  • KAON2 is a reasoner and ontology management API for OWL DL and SWRL. It can be used to check the validity of the exported OWL specifications. In conjunction with OWL tools, you can also transform the exported RDF into LaTeX sources that show the according DL statements (which tend to be more readable for humans, or at least for DL-aware humans).

The information on this page is OUTDATED!
This documentation page applies to all SMW versions from 1.0 to the most current version.
      Other languages: zh-hans

Help:Reuse en 1.0

Import vocabulary

Warning: Display title "Importing vocabulary" overrides earlier display title "RDF export".

Import vocabulary
Describes the import and reuse of external vocabularies
Image / Video collection
import vocabulary · foaf · RDF
Table of Contents

In Semantic MediaWiki it is possible to import and reuse vocabulary that belongs to existing Semantic Web documents or standards by associating the vocabulary's elements with wiki terms.

  • A shared vocabulary can help clarify that the same word can mean a different concept or a different word (phrase) can refer to the same concept 7:92
  • A shared vocabulary can help the dissemination of data and avoids information to remain isolated (because of an incapability to process information when it is distributed) 7:92 and :392

General Concepts

Normally, concepts that can be described (and be used for description) in the wiki are defined by the wiki and thus are local. So the URI that RDF export uses to denote a concept is usually from a specific namespace that should be used only by the wiki. Even if you create a property that seems to come from a well-known vocabulary because you name it foaf:knows, it would still be exported with the URI


which is the XML-compatible URI derived from the article URL (see Help:RDF export for details). Semantic MediaWiki's mechanism for importing vocabularies solves this problem by allowing the reuse of external vocabulary in a controlled way.

Importing and specifying vocabularies

Selected list of imported vocabularies

  • foaf Friend Of A Friend
  • rdfs RDF Schema
  • owl Web Ontology Language (OWL)
  • dc Dublin Core Metadata
  • dcterms DCMI Metadata Terms
  • bibo Bibliographic Ontology
  • frbr Functional Requirements for Bibliographic Records

NoteNote: The content in above listed vocabularies may or may not be completed (please amend if entries are missing).

See also

#scite can not be used on a namespace that is not enabled for Semantic MediaWiki
The combination "en":"Help:Import vocabulary" already exists for page "Help:Import vocabulary" therefore no additional interlanguage annotation was created.

This documentation page applies to all SMW versions from 1.5.3 to the most current version.
      Other languages: ruzh-hans

Help:Import vocabulary en 1.5.3

Ontology import

This page contains outdated information and is thus OBSOLETE!
This documentation page applies to all SMW versions from 0.1 to 0.7.

Help:Ontology import en 0.1 0.7

Semantic MediaWiki has a feature (still in beta, and disabled in version 1.0) to import ontologies into a Semantic MediaWiki installation. The ontologies have to follow certain formats, in order to be useful. Further down you will find a description of an alternative way of importing data from ontologies (or, actually, other formats as well).

Ontology format

The ontology elements -- i.e. classes, properties and individuals -- should all have labels. The labels will be used to name the relations, the categories, and the article pages, and also to create the appropriate annotations -- i.e. typed links or categorization links -- on the article pages. The mapping of the import naturally follows the mapping of the export, so it looks like this:

OWL Construct Semantic MediaWiki
Class Category
Datatype property Property
Object property Property also (??)
Class instantiation Page categorization (e.g. [[Category:X]])
Subclass of Category subcategorization (e.g. [[Category:X]] on a category page)
Individual Article (in Main namespace)
Instantiated datatype property Attribute annotation (e.g. [[X::Y]])
Instantiated object property Typed link (e.g. [[X::Y]])

Note that the ontology needs to be in OWL DL in RDF-serialization, not just general RDF or RDFS, and that all properties and classes have to be defined as such in order to be recognized. Only explicit statements get imported, i.e. no reasoning occurs. So even if you can infer from the ontology that Adam is a man, he will not be put into the Category:Man unless such a triple is in the ontology, and Man is defined as an OWLClass. If you want to import implicit statements, you have to make them explicit first. You can use any reasoner that allows you to materialize such statements.

Note also that all further constructs from OWL DL, like inverse relations, complement classes, class union, etc., will not be imported into the ontology. If you want to use more complex ontologies with the Semantic MediaWiki, check out the publication ow:Reusing Ontological Background Knowledge in Semantic Wikis.

How it works

On the page Special:Import ontology you can upload the ontology file. The special page is only available to users with admin privileges. After you have chosen the ontology file the system parses it (using RAP, thanks!), you will be presented with a list of all importable statements, i.e. especially statements that are not within the wiki already (though this display is a bit buggy, sorry for that). Here you can choose every statement to import, and you can enter a small text to be imported alongside the import (for example a template that will resolve to a message telling the user that this information was imported from a particular ontology).

After you have chosen the appropriate statements and set all other options, click on the import button at the far end of the page, and wait. A few moments later, the statements should have been imported (check Recent changes).

Note that this part is still somewhat buggy. You may want to try smaller portions of the ontology first, or even single statements, to see if it works as you want it to.

Alternative import

As an alternative to this experimental feature, you can use pre-processing tools to annotate wiki pages with the wiki text for SMW properties, then import those pages using MediaWiki import tool(s).

A more robust way to import ontologies, is to use a framework like the Python Wikipedia Bot. It should work with other wikis as well, not just with Wikipedia, but you will have to create a new family file in order to get access to your wiki. In this case you are not constrained to using OWL DL compliant ontologies.

For example, on the Ontoworld wiki we imported the delegates list from the ow:ESWC2006 ontology. We sketch the program in the following. It uses the rdflib library for the RDF parsing, and it uses the Wikipedia Bot framework to work with Wikipedia. It creates a template out of the RDF. It could also create sentences with typed links inside (see towards the end of the code for an example), or check the output of the page first if the triple to be added is already included (and thus may be skipped).

from rdflib import Graph, URIRef, Literal, Namespace, RDF
import wikipedia, login, category

family = "ontoworld" # note that you need to setup the appropriate family file

i = Graph()

i.bind("foaf", "")
RDF = Namespace("")
RDFS = Namespace("")
FOAF = Namespace("")

ow = wikipedia.Site('en')
login.LoginManager('password', False, ow)

unchanged = list()   # in order to safe those that already have a page

# iterates through everything that has the type Person
# (note, only explicit assertions -- rdflib does not do reasoning here!)
for s in i.subjects(RDF["type"], FOAF["Person"]):
        for n in i.objects(s, FOAF["name"]):  # reads the name
            p = wikipedia.Page(ow,n)          # gets the page with that name
            if p.exists():
            else: # create the instantiated template
                h = '{{Person|'   '\n'
                h  = ' Name='   n
                for hp in i.objects(s, FOAF["workplaceHomepage"]):
                    h  = '|'   '\n'
                    hp = hp[7:]
                    h  = ' Homepage='   hp
                    if len(hp)>23: # if the name of the page is too long,
                        h  = '|'   '\n'
                        if hp.find("/"): # make something shorter
                            hp = hp[0:hp.find("/")]
                        h  = ' Homepage label= at '   hp

                for hp in i.objects(s, RDFS["seeAlso"]):
                    h  = '|'   '\n'
                    h  = ' FOAF='   hp
                h  = '\n'   '}}' # end Person template

                # write a sentence
                h  = '\n'   "'''"   n   "''' attended the [[delegate at::ESWC2006]]."

                # add a category
                h  = '\n'   '\n'   '[[Category:Person]]'
                print n   ' changed'
                p.put(h, 'Added from ontology')

print unchanged

As you have the full power of Python available, you can basically parse any machine-readable document and process it any way you like. As of 2006, and as long as the ontology import is still not perfect, this is the recommended way to import data into the ontology (especially since it allows you much more freedom in stating the facts and reusing templates than the ontology import ever will).

There is an alternative description for importing data with a script.

Administrator manual

Warning: Display title "Administrator manual" overrides earlier display title "Importing vocabulary".

The following pages describe how to download, install, and configure Semantic MediaWiki (SMW) as a site administrator. If you want to learn about using SMW as a wiki user (with or without administrator rights in the wiki), then the user manual is the right place for you. But basic installation and maintenance of SMW does not necessarily require to be familiar with its usage.

Since SMW is an extension to MediaWiki, a current release of MediaWiki is needed first. This can be obtained in various ways as described on the MediaWiki homepage. Please install this software and make sure that it works as expected before installing SMW. As an extension to MediaWiki, SMW usually requires only very little modifications of the basic system to run. Adjustments might be useful for customising its behaviour, or for tweaking its performance.

The main sections of this handbook explain the most important aspects of administrating SMW:

Detailed navigation is provided by the table of contents on the right. Other relevant parts of this handbook include: