From Wiki@OntoWorld

Jump to: navigation, search

A more comprehensive documentation of Semantic MediaWiki is found at Help:Semantics.

This user guide is still a stub. It will be developed along with the implementation. As in many places in this wiki, it also contains some proposals for future extensions and appropriate usage, which are still under discussion or even un-reviewed by any developer yet. So please take the information below with a grain of salt and refer to official publications for details about the development plan.


Relations between articles "::"

With this extension installed MediaWiki offers a new feature, it allows you to give links a type. Instead of merely linking from the article San Diego to California, you can now — if you like — additionally state the kind of relation between San Diego and California. We can probably agree that San Diego is located in California. You can state this fact by writing in the San Diego page

this fine city is in [[is located in::California]] ... 

Before the linked article name, you give the type of the relationship, separated by two colons.

You can use any string for the relation type, but it would be great to use the same strings as other people, much like categories. Consistent relations let users make smarter searches of Wikipedia; instead of every article that links to California, they can, for example, search for every article that is located in California.

The Special:Relations page lists every relation. Each relation type may have its own page in the Relation: namespace that describes it, for example Relation:Is located in. For a list of the relations that have such pages, use the all articles query page to display articles in the Relation namespace.


  • If you want to define a relation which is not visible in the Text, simply rename it to a space:
[[located in::California| ]]
  • Feel free to check out the Bugs Page to report problems
  • Relations can be chained. Therefore instead of:
[[is a::fruit]] [[use as::fruit]]
you can say:
[[is a::use as::fruit]]
  • Take a look at existing schemas like WikiOnt, GeoURL, Dublin Core, FOAF and SKOS to compare them with the proposed implementation in this wiki.
  • If you want to Model in different times (past/present/future) you maybe need to create new Attributes.


has capital | is capital of
had capital | was capital of

Note: Maybe this issue can be solved better by a powerful dictionary containing a definition for will have, has and had and deriving them from future, past and present. But the syntax gets more strict (Attributes need contain one of "has", "is", or similar), and it must be extensible also for other Languages (ie. French uses 7 kinds of times, which results in multiple inheritance). This makes it very complex to implement such a thing in software.

Attributes ":=" are relations to values

Relationships to things that are not articles can be stated by using attributes. If you know that the population of San Diego is 1,305,736, you can state this fact by writing in the San Diego page:

the 2005 census estimated its population as [[population:=1,305,736]]

You put the value inside [[ ]], and before it you give the type of the attribute, separated by :=

The Special:Attributes page lists every attribute. You can also use the all articles query page to display articles in the Attribute namespace.

You can search on attributes, such as population.

Attributes can be chained to set two attributes to the same value, e.g.:

 the bases of the towers were squares [[length:=width:=208 feet]] on a side

Attribute and Relation are analogous to literal and URI reference respectively in RDF.

see also: Attribute:true title, dct:Box, GeoURL


Wikipedia needs to know the type of an attribute. This is especially true of attributes whose values have dimensions and units, such as area.

So you must create an page in the Attribute: namespace for an attribute, and in this specify its datatype using the Relation:Has_type. For example, Attribute:Area has

[[has Type::Type:Geographic area]]

The Special:Types page lists the datatypes implemented in Semantic MediaWiki. We are working to extend this to all physical types (speed, density, energy, etc.). There is a lot of discussion about this in Built in Types. While waiting for a particular datatype to be implemented with the physical dimensions you need, you can use Type:Float and provide units (that won't be recognized), or use Type:String.

Each datatype may have a page in the Type: namespace, for example Type:Geographic area. These type pages are just for documentation, e.g. to tell users which syntax is accepted and which units will work. Conversely, creating a new Type: page does certainly not create a new datatype!

Future Work

This Wiki is still in development and meant to be subject of ongoing research and dicussion. The following is a Overview of special Syntax which is currently not implemented and open for discussion.


Infoboxes might add semantic Information to an article in an transparent way. Let's define a City-Infobox with the following simple code:

!rowspan="2"|[[is a::City]]
| Name       || {{{0}}}
| Location   || [[located in::{{{1}}}]]
| Population || [[population:={{{2}}}]]

Now we can use this Infobox like in the following Example:

{{City|San Diego|California|1,305,736}}

Note: this approach can handle only simple Datatypes. If it would need to handle more than one Value for the located in Attribute, we need either Arrays or can't use this example.

Built in Types

To make the use of types easier, we can introduce built-in types. This matches the current implementation best which doesn't care about Type-Definitions and should make the live of Wikipedians easier who want to define a new Attribute and don't want to care about things like Datatypes. Also this technique will be easier to implement and therefore leading to a release-date without the need to take care at things like user-side Type definitions. Also by making it possible to user fixed data-structures it will be easier to implement seach based on this types. Built-in-Types are recognized by a parser which tries to get the meaning from the structure of the string. We define the following examples:

  • Strings
  • Numbers
  • Dimension (Numbers + Units)
  • Electron-Configuration of Atoms
  • (semantic) Links (optional)
  • others if needed


[[String:="This is a String"]]
[[Number:=3,678.5 * 10^3]]
[[Dimension:=385.56 miles s^(-2)/J]]
[[Electron Configuration:=3d6 4s2]]

see also: Built in Types

Vectors and Matrices

[[has Vector:={1}{2}{3}{4}]]
[[has Matrix:=

see also: Vector


Proposal for definition of Enumerations:


Another Example can be found at owl:oneOf, showing a similar Technique using OWL and Autolinking.


Proposal for use of Regex-Patterns:

 [[has Type::Pattern("[a-zA-Z0-9]{5}")

This can be usefull ie. for defining Currency.

Note: Currency have to get implemented per-language.
Note: Flags could get implemented as an Enumeration of Boolean Values.


  • Good
    1. Attributes can be bound to Datatypes.
    2. Enumeration types
    3. Nested types
    4. Regex patterns based types
  • Negative
    1. Regex-Patterns possibly need special coding to get interpreted right.
    2. Requires Implementation of Namespaces
    3. Can get complex to implement

see also: Dublin Core#Types, dct:Box, WikiOnt


see also: Units


A range is defined when a value is double-defined as the distance between minimum and maximum.

[[was capital in:=1530]]
[[was capital in:=1905]]

this means that the city was a capital from 1530 till 1905. This technique can also get in use when defining Polygons:


Another possibility would be to create complex Types:

[[{from date:=1993}{to date:=2001}{was president of::USA}]]

see also: Attribute:born, Attribute:color, and Attribute:from.

Escape Sequences

Articles may contain the characters ']]' or ':' within title. So we need a kind of Escape-Sequence.

[[is a::really unlikely]]character sequence]]

We could use a C-like escape sequence:

[[is a::really unlikely/]]character sequence]]

When you now want to write a '/' character, you can double it or use an '@' character:

[[is a::http:////]]
[[is a::@]]
[[true title:=/@Work]]
  • Good
    1. Solves the Problem of Escape Sequences
    2. Syntax related to common Programming Languages like C#
  • Negative
    1. More complex Syntax


Namespaces are very important in RDF for including existing Schemas from the Web. Namespaces may defined as special Articles (ie. named Namespace:dc) and derived from an Namespace:

[[is same as::@]]

A similar techique could also replace Interwiki links. Take the Article Apple and insert:


While Namespace:de is defined as:

[[is same as::@]]

see also: Namespace:xsd, InterSchema

Implicit Derivation

Implicit Derivation means that special Kind of articles can automatically derived from a special Type.

This can apply to the following:

  • Special Pages
  • Help
  • Users
  • Attributes
  • Types
  • Namespaces
  • Image, Audio, and Video Content

And all articles derive at least from Article, which itself is a wiki:Text, which is a Object.


Improved Semantic Search.


Relations can be a two way thing. When we use the Syntax
[[is same as::…]]
this applies to both, the current article and the target. Also some Relations have counterparts like
[[is capital of]]
[[has capital]]
. This counterpart could automatically created. But we need a syntax to describing this. Examples are in owl:inverseOf and OWL#Special Properties.

Automatic simplifying of Categories

Take a User that defines that he comes from::Germany and he comes from::Europe.
We also define a relationship Germany lies in::Europe and the relationship that Relation:comes from is a stronger binding than lies in (weaker than::lies in). A semantic reasoner should now be able to decide that the statement from::Europe is obvious and can remove it.

Note: A simple but dirty approach (Hack) would be to use Relation:is same as which has the same effect, even the meaning is a bit different.

Note: Because this functionality will need a lot of computing Resources - but doesn't need to run in realtime – it should run as separate thread with lower Priority. see also: owl:equivalentProperty


To solve the Problem of Ambiguity, we could introduce the Relation:context of in combination with Attribute:true title. This will make it possible to search for the Word "Mars" and we will get a Search-Result like:

The God Mars in roman mythology
The Planet Mars in solar system

So, we have implicit disambiguation in the search-result.

External Links

It might also be possible to make Relations to external Links, which might get handled ie. as URIs within the semantic datastore.

[[is a:: Article]]

This System might require some changes in the current Link-Engine. In the current Engine external Links (http://, mailto:, etc.) are fenced with a single [ and ], while internal Links are fenced with [[ and ]]. This behavior might need to be more consistent in use, but will effect most of the existing pages in Wikipedia.


see also: User talk:GerardM# Semantic Wikipedia not localisable

See also

@Wiki-Sig: we need to flesh out this page. Then we see, when we make a concept too complicated quickly.

Personal tools