Copyright © 2007 Markus Krötzsch and Denny Vrandecic
This work is licensed under a Creative
Commons Attribution License This copyright applies to the SWIVT Ontology Specification and
accompanying documentation and does not apply to SWIVT data formats, vocabulary terms, or technology. Regarding underlying technology, SWIVT relies on W3C's OWL technology, an open Web standard that can be freely used by anyone.
This document is produced as part of the Semantic MediaWiki project (SMW), to provide authoritative documentation of the contents, status, and purpose of the OWL vocabulary elements used in the OWL/RDF export of Semantic MediaWiki sites.
An a-z index of SWIVT terms, by class (categories or types), by property, and by instance.
Classes: | BuiltinType | Container | ConversionFactor | CustomType | NAryType | Subject | Type | UnitType | Wikipage |
Properties: | allowedValue | baseProperty | conversionFactor | creationDate | displayUnit | factor | mainUnit | modifier | object | page | sourceSite | type | unit | value | wikiNamespace | wikiPageModificationDate |
Instances: | EmailType | GeoType | NumberType | PageType | StringType | TemperatureType | TextType | TimeType | URIType |
This document describes the elements of the Semantic Wiki Vocabulary and Terminology (SWIVT), which provides a basis for interpreting the semantic data exported by Semantic MediaWiki (SMW). This ontology therefore incorporates various elements that are closely related to SMW's metadata model. Yet its most basic concepts, such as Wikipage or Subject, are generic enough to apply to many semantic wikis, and thus to allow simple reuse or mapping between different systems.
The SWIVT ontology is based on the W3C format OWL, and more specifically for its variety OWL DL. See the OWL Primer for an overview and introduction. This exchange language has been chosen for SWIVT because it is supported by a significant number of available tools. This is especially true since OWL DL documents can be processed not only by dedicated OWL-processors, but also by all RDF-tools (though possibly with some fewer semantic insights, since specific OWL-constructs are ignored).
Since the OWL 2 revision of OWL, it is possible to treat elements as individuals and as schema level entities (classes, properties) at the same time without loosing compatibility with OWL DL tools. The underlying light-weight semantics is also known as punning. SWIVT therefore uses normal object and datatype properties to attach information to schema level entities.
TODO: describe the type and property model used by SWIVT.
SWIVT introduces the following classes, properties, and individuals.
| Status: | stable |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
Elements of the class swivt:BuiltinType are special instances of swivt:Type which are special predefined datatypes of the wiki. These datatypes convey pragmatic information of how the values of a property should be presented to humans.
The built-in types that SWIVT currently provides are swivt:EmailType, swivt:GeoType, swivt:NumberType, swivt:PageType, swivt:StringType, swivt:TemperatureType, swivt:TextType, swivt:TimeType, swivt:URIType.
| Status: | stable |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
The usage of the class swivt:Container is similar to the class rdfs:Container, but no relationship to the RDF(S) specification is presupposed. Yet, container elements still play the role of auxilliary elements used to encode lists and sets of other elements.
Container elements usually are subject to property statements of the subproperties of swivt:object and swivt:value.
| Status: | stable |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
Elements of the class swivt:ConversionFactor specify one linear conversion factor with a swivt:UnitType. Each such conversion factor has one swivt:factor, one swivt:mainUnit, and possibly multiple additional values for swivt:unit.
Properties of swivt:type swivt:UnitType (or with a swivt:baseProperty of that type) are usually annotated with a swivt:modifier that is to be interpreted as the unit label related to that value. That unit label can be compared to the swivt:mainUnit and swivt:unit of the swivt:ConversionFactor elements of the given type. If ab according unit label is found, the conversion factors can be used to transform a property value into any other unit.
All units associated to one swivt:ConversionFactor can be considered synonymous when used with properties for the given type. To convert a value between two different conversion factors, the value is to be divided by its own conversion factor's swivt:factor, and then multiplied by that of the target conversion factor.
For example, one swivt:ConversionFactor might have a swivt:mainUnit km, another swivt:unit kilometre, and a swivt:factor of 0.001. Another swivt:ConversionFactor might have a swivt:mainUnit m, and a swivt:factor of 1. Now assume that an according type is used by a property with swivt:modifier kilometre. Then any (numerical) value of that property is to be interpreted as a value in the unit kilometre. To convert it to metres, one would first divide it by 0.001, then multiply it by 1.
| Status: | testing |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
Elements of the class swivt:CustomType are special instances of swivt:Type which are not specified by a predefined type element of SWIVT. This class is disjoint with swivt:BuiltinType
| Status: | testing |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
Elements of the class swivt:NAryType are special instances of swivt:CustomType which can be described as finite lists of other datatypes. A value of an n-ary datatype then is composed of an ordered list of n values, where each value should either be of the datatype specified for this list position, or be undefined.
Values of properties with n-ary datatypes are normally encoded by using an auxilliary element of the class swivt:Container that is subject to at most n different property statements using sub-properties of swivt:object and swivt:value.
| Status: | stable |
|---|---|
| in-range-of: | foaf:maker foaf:member |
| in-domain-of: | TODO |
The swivt:Subject class is the class of all things that might be described by wiki pages. This comprises essentially all things that anyone may ever want to talk about, provided that these things are represented by some element in owl:Thing (i.e. OWL properties and other structural elements of OWL are not included).
SWIVT uses swivt:Subject to distinguish individual element that represent the subject of a wiki page from those that are used as auxilliary elements for structural purposes (see, e.g., swivt:Container), and from those that represent elements that are not necessarily mentioned in the wiki (see, e.g., swivt:Type). In contrast to those, members of swivt:Subject should always have an associated wiki page, specified by swivt:page.
| Status: | stable |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
The class swivt:Type comprises elements that are used to describe datatypes as used in the wiki. Datatypes are assigned to properties with the annotation swivt:type, and informally specify details about the pragmatic use of some property. Type information thus can be used to improve the presentation of property annotations.
SWIVT provides a number of built-in types (swivt:BuiltinType), as well as means of describing various forms of custom types (swivt:CustomType). The latter further allows specific types for properties with unit conversion (swivt:UnitType) and for properties that allow lists of values of diverse types (swivt:NAryType).
| Status: | stable |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
Elements of the class swivt:UnitType are special instances of swivt:CustomType which are very similar to swivt:NumberType but provide additional information for converting between units of measurement. All such unit conversions must be defined by simple linear factors associated with the string labels of a given unit.
Elements of this class are further specified by conversion statements of the property swivt:conversionFactor.
| Status: | stable |
|---|---|
| in-range-of: | TODO |
| in-domain-of: | TODO |
The class swivt:Wikipage comprises all electronic documents that are pages in a wiki. This class especially forms the range of the property swivt:page that associates (abstract) subjects with concrete wikipages.
| Status: | unstable |
|---|---|
| type: | owl:DatatypeProperty |
| range (informal): | xsd:string |
| domain (informal): | any property defined by the wiki |
The property swivt:allowedValue provides informal sontraints on the values that are admissible for a given property. This means that users should choose one of the specified values (in case of multiple annotations with swivt:allowedValue) whenever assigning a value to that property.
This information might be relevant for applications that allow users to modify values of a given property. However, the actual values of swivt:allowedValue specify an admissible user input, not an admissible OWL-compatible datavalue. This means that these values can normally not be used for checking the validity of the given values, unless an application implements the mapping between the lexical space of the given swivt:type and the lexical space of property objects/values that are used in the SWIVT serialisation. Moreover, no claim is amde that the given allowed values are exhaustive or that all actual values correspond to one such value. Thus swivt:allowedValue is usually an informative maintenance annotation that is relevant to the wiki only.
| Status: | testing |
|---|---|
| type: | owl:ObjectProperty |
| range (informal): | any property defined by the wiki |
| domain (informal): | any property defined by the wiki |
The property swivt:baseProperty establishes the link between two properties defined in the wiki. The motivation is that some kinds of properties are not just given a value, but also a modifier that specifies how to interpret this value, e.g. a unit of measurement. SWIVT offers a way of encoding this special situation by creating a new property for each occurring modifier, specifying the modifier via swivt:modifier, and relating the new property to the original one via swivt:baseProperty.
Multiple different properties thus may be linked via a common base property, while it is assumed that there are no chains of base property annotations. Moreover, properties with the same base should normally have the same swivt:type, and the swivt:type of teh base property can be assumed if none is given. Applications may choose to present values of non-base properties like values of the base property which have an additional modifier given by swivt:modifier.
swivt:UnitType with a swivt:ConversionFactor.| Status: | testing |
|---|---|
| type: | owl:ObjectProperty |
| range: | swivt:ConversionFactor |
| domain: | swivt:UnitType |
The property swivt:conversionFactor specifies a swivt:ConversionFactor for a given swivt:UnitType. Each type may have many different relationships of this kind. Applications may use this information to provide some support for conversions between units of measurement.
| Status: | testing |
|---|---|
| type: | owl:AnnotationProperty |
| range (informal): | xsd:dateTime |
| domain (informal): | owl:Ontology |
The property swivt:creationDate can be used to annotate ontologies with the time of their creation. The contents of the ontology should reflect the semantic contents of the wiki at that time. The according wiki can be specified by swivt:sourceSite.
SWIVT does currently not specify whether the server's local time or some internationally standardised time should be used. It is thus not guaranteed that the given time is useful for comparing the recency of ontologies stemming from different wikis, or for comparing an ontologies creation time with the local time. However, all services of the wiki that retrieve semantic data based on an input time point (e.g. by retrieving only data which was changed since that time) should be fully compatible with the timestamps provided by that wiki in swivt:creationDate.
| Status: | stable |
|---|---|
| type: | owl:DatatypeProperty |
| range (informal): | swivt:Container |
| domain (informal): | any property defined by the wiki |
Any swivt:UnitType might specify conversions for many different unit labels, but some properties which have that swivt:type may not be interested in all these units. Therefore, the annotation swivt:displayUnit may specify a list of units that are practically relevant to the given property, where all list items are specified by sub-properties of swivt:value with objects of type xsd:string.
For example, a property that specifies the length of rivers might choose the units km and miles, but neither nm and light years. In general, this annotation can be interpreted for any builtin or custom datatype that has a notion of unit of measurement (e.g. also for swivt:TemperatureType).
Applications that support conversions between units may use this information to present values of properties in appropriate units. The order of the list of units is significant, and the first unit should usually be considered the main representation for values of the given property.
swivt:ConversionFactor.| Status: | testing |
|---|---|
| type: | owl:DatatypeProperty |
| range: | xsd:decimal |
| domain: | swivt:ConversionFactor |
The property swivt:factor specifies a numerical factor for a swivt:ConversionFactor associated with some swivt:UnitType. See swivt:ConversionFactor for details.
swivt:ConversionFactor.| Status: | testing |
|---|---|
| type: | owl:DatatypeProperty |
| range: | xsd:string |
| domain: | swivt:ConversionFactor |
The property swivt:mainUnit specifies the primary unit label for a swivt:ConversionFactor associated with some swivt:UnitType. See swivt:ConversionFactor for details.
| Status: | testing |
|---|---|
| type: | owl:DatatypeProperty |
| range (informal): | xsd:string |
| domain (informal): | any property defined by the wiki |
As explained in the documentation for swivt:baseProperty, SWIVT allows wiki properties to be derived from one common base property. The annotation swivt:modifier can be used to specify in which way the value of a certain non-base property is to be interpreted. Common modifier strings are units of measurement. For example, a property #length_(m) might have a swivt:modifier m and a swivt:baseProperty #length.
swivt:Container with some contained object.| Status: | testing |
|---|---|
| type: | owl:ObjectProperty |
| range: | owl:Thing |
| domain: | swivt:Container |
The property swivt:object specifies an object that belongs to a swivt:Container. For specifying containers that are ordered lists, swivt:object has sub-properties swivt:object1, swivt:object2, swivt:object3, etc. Thus the encoding of lists is similar to that used for rdfs:Container. For OWL compatibility, SWIVT distinguishes object and datatype properties, and the latter are specified via swivt:value.
Note: currently the SWIVT OWL specification declares only the properties swivt:object1 to swivt:object9. The explicit declaration required in OWL does not permit lists of arbitrary length to be encoded at the moment. Applications may directly declare further subproperties of swivt:object to specify more list elements.
swivt:Subject with the according swivt:Wikipage.| Status: | stable |
|---|---|
| type: | owl:ObjectProperty |
| range: | swivt:Wikipage |
| domain: | swivt:Subject |
The property swivt:page establishes the link between an abstract swivt:Subject and a concrete swivt:Wikipage describing that subject. Usually the given page URL also enables users to modify the semantic information about the given subject.
| Status: | stable |
|---|---|
| type: | owl:AnnotationProperty |
| range (informal): | URLs |
| domain (informal): | owl:Ontology |
The property swivt:sourceSite can be used to annotate ontologies that were created from wiki contents, thus specifying the wiki site that the ontology was created from.
swivt:Type that informally describes its datatype.| Status: | unstable |
|---|---|
| type: | owl:ObjectProperty |
| range (informal): | swivt:Type |
| domain (informal): | any property defined by the wiki |
The property swivt:type establishes the link between a property defined in the wiki and an element of swivt:Type that describes an informal datatype element that may give additional information about how to handle values of this property.
Applications can use this information to provide more adequate presentations for certain property annotations. However, the annotation swivt:type does not guarantee that all actual values of the given property must adhere to this type, or even admit a meaningful interpretation for this type. The property type does specify, however, how users intended the property to be used, and unsuitable values can be considered modelling errors.
swivt:ConversionFactor.| Status: | testing |
|---|---|
| type: | owl:DatatypeProperty |
| range: | xsd:string |
| domain: | swivt:ConversionFactor |
The property swivt:unit specifies a unit label for a swivt:ConversionFactor associated with some swivt:UnitType. Many synonymous labels might be associated with one element. See swivt:ConversionFactor for details.
swivt:Container with some contained value.| Status: | testing |
|---|---|
| type: | owl:ObjectProperty |
| range: | owl:Thing |
| domain: | swivt:Container |
The property swivt:value specifies a value that belongs to a swivt:Container. For specifying containers that are ordered lists, swivt:value has sub-properties swivt:value1, swivt:value2, swivt:value3, etc. Thus the encoding of lists is similar to that used for rdfs:Container. For OWL compatibility, SWIVT distinguishes object and datatype properties, and the fortmer are specified via swivt:object.
Note: currently the SWIVT OWL specification declares only the properties swivt:value1 to swivt:value9. The explicit declaration required in OWL does not permit lists of arbitrary length to be encoded at the moment. Applications may directly declare further subproperties of swivt:value to specify more list elements.
| Status: | stable |
|---|---|
| type: | owl:DatatypeProperty |
| range: | xsd:integer |
| domain: | swivt:Subject |
MediaWiki uses Namespaces to organise pages, and each wiki page thus belongs to one namespace. Namespaces have names (and possibly aliases) that are used by end users, but internally they are simply addressed by numerical ids. This property allows wikis to export such an id for the page of a given subject.
| Status: | stable |
|---|---|
| type: | owl:DatatypeProperty |
| range: | xsd:dateTime |
| domain: | swivt:Subject |
This property allows wikis to export the time at which the page that is underlying some subject has last been modified. While this is not a property of the actual (abstract) subject but of the wiki page, it is a useful property for ranking query results. Hence this property is provided to allow its use in wiki export data.
swivt:BuiltinType for object properties relate to URIs that describe emails. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:EmailType is used for (object) properties that relate to URIs that are valid emails. Such URIs always start with mailto:.
swivt:BuiltinType for datatype properties that have geographic coordinates as values. | Status: | unstable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:GeoType is used for properties that encode geographic locations. At the moment, this information is encoded as a plain string of lattitude and longitude. In the future, a more structured encoding, possibly using the geo vocabulary, is intended.
swivt:BuiltinType for datatype properties that have numbers as values. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:NumberType is used for properties that have values of type xsd:double, xsd:float, xsd:decimal or xsd:integer. Semantic wikis may choose the any of the above types as considered suitable to encode some numerical value, and different XSD types might be used for diefferent values of the same property.
swivt:BuiltinType for object properties that relate to the swivt:Subject of a wiki page. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:PageType is used for properties that encode the swivt:Subject of a wiki page. Values of such properties should normally be instances of the class swivt:Subject.
swivt:BuiltinType for datatype properties that have simple strings as values. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:StringType is used for properties that have simple xsd:strings as their values. In contrast to swivt:TextType, these strings can be assumed to be at most 255 characters in length.
swivt:BuiltinType for datatype properties that have arbitrary strings as values. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:TextType is used for properties that have arbitrary xsd:strings as their values. In contrast to swivt:StringType, these strings can be of any length.
swivt:BuiltinType for datatype properties that have temperatures as values. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:TemperatureType is used for properties that describe numerical quantities that are temperatures. Technically, these values are encoded like arbitrary values of swivt:NumberType, but it can be assumed that the represent temperatures measured in degrees Kelvin. Applications may convert them into any other common unit for measuring temperatures, especially if such a unit is specified via swivt:displayUnit.
swivt:BuiltinType for datatype properties that have times as values. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:TimeType is used for properties that have values of type xsd:dateTime, xsd:date or xsd:gYear. The chosen type may reflect a certain amount of imprecission that applications may want to take into account.
swivt:BuiltinType for object properties that relate to arbitrary URIs. | Status: | stable |
|---|---|
| type: | swivt:BuiltinType |
The built-in type swivt:URIType is used for (object) properties that relate to arbitrary URIs. Semantic wikis normally ensure that those URIs do not violate OWL DL compatibility.
The style, organisation, and layout of this document is based on the FOAF specification by Dan Brickley and Libby Miller (released as CC-By-1.0).
This work has been supported by Institute AIFB of Karlsruhe Institute of Technology.
We wish to thank all contributors and users of Semantic MediaWiki for providing us with useful feedback that has also influenced the OWL/RDF serialisation from which SWIVT eventually was extracted. A current list of contributors can be found in SMW's README.