Machine-readable Map Feature list/OWL Semantic Wiki and more

OWL lingo and OSM map features

In the machine-readable map feature list we distinguish between four concepts: tag-def, value-def, category (which is somewhat confusing here, because the term Category is also widely used in Mediawiki and in Semantic Mediawiki, perhaps we should call it feature-category) and preset.

OWL stands for "Web Ontology Language" in this context, however within OSM we're now using "OWL" to mean other things. OWL Web Ontology Language distinguishes between classes and individuals. According to the spec "Classes provide an abstraction mechanism for grouping resources with similar characteristics". In our context we would typically have four classes representing the four OSM map feature concepts mentioned in the previous paragraph, say the classes OSMTagDef, OSMValueDef, OSMFeatureCategory and OSMPreset (for clarity, I always included the prefix OSM in the name).

OWL classes can be related to each other using class axioms. We don't use them here because neither wan't to express that one of our concepts is a subclass of another, nor that it is equivalent with another, nor that it is disjoint with an other. Altough there is no immediate need we could introduce a general superclass for our four concepts, say OSMFeature (I'd not simply call it OSM because this sounds way to general to me). If we introduced such a superclass our four concepts would become their subclasses and we would end up with a subclassing hiearchy like

 OSMFeature
    |
    +--- OSMTagDef
    +--- OSMValueDef
    +--- OSMFeatureCategory
    +--- OSMPreset

individuals are instances of these classes (also called facts). In our context

• the tag definition with key highway is an indiviual. It's class is OSMTagDef
• the value definition with key highway and value primary is an indiviual. It's class is OSMValueDef.

We can define a set of properties for each class. Properties which hold data values are called datatype properties, those who link to other individuals (i.e. other instances of classes) are called object properties.

For example, our class OSMTagDef would have the datatype properties:

• key of type xsd:string
• onNode of type xsd:boolean
• onWay of type xsd:boolean

If we wanted to be more specific about the kind of strings which are allowed for a key (see discussion about hierarchical names in the archive) we could define our own data types. For instance, a datatype OSMKeyType could define that keys consist of [a..zA..Z0..9-_.] only and that . is used to separate name components in a hiearchical name. Our property key of OSMTagDef would then become

• key of type OSMKeyType

Back to object properties. Some of our individuals can link to other individuals. For instance, an instance of Preset can imply 0 or more OSMValueDef. For this purpose we define object properties on our classes. For instance

• implies is an object property of Preset.

We would restrict implies to only refer to instances of OSMValueDef. In OWL this looks like

 <owl:Restriction>
   <owl:onProperty rdf:resource="#implies" /> 
   <owl:someValuesFrom rdf:resource="#OSMValueDef" />      
 </owl:Restriction>

When our classes and data types are in place we can start to define individuals (or facts).

Here's an example definition of a value definition:

  <OSMValueDef rdf:ID="highway/primary">
    <key rdf:datatype="xsd:string">highway</key>
    <value rdf:datatype="xsd:string">primary</key>
    <onNode rdf:datatype="xsd:boolean">true</key>
    <onWay rdf:datatype="xsd:boolean">true</key>
    <state rdf:datatype="xsd:string">accepted</key>
  </OSMValueDef>

An here's an (incomplete) example definition of a preset:

  <Preset rdf:ID="primary highway">
    <requires rdf:resource="#highway/primary"/>
    <implies rdf:resource="#motorcar/yes"/>
  </Preset>

How does this map to Semantic MediaWiki ?

In Semantic MediaWiki there is only one relevant class: Page. individuals in OWL terminology are individual pages in the Wiki.

Semantic MediaWiki mimics the concept of classes using MediaWikis Categories. Our classes OSMFeature and OSMTagDef would become Categories in MediaWiki. We would have to define two pages in the namespace Category::

• Category:OSMFeature - represents the class OSMFeature
• Category:OSMTagDef - represents the class OSMTagDef

The page Category:OSMTagDef would then "subclass" from Category:OSMFeature by including

  [[Category:OSMFeature]]

in its source.

Semantic MediaWiki supports multiple data types, however. When Semantic MediaWiki talks about types at its defining pages in the namespace Type: then it means data types in OWL terminology, not classes. Semantic MediaWiki comes with a set of predefined types and editors can define new types.

Semantic MediaWiki does not distinguish between object properties and datatype properties: from the the point of view of Semantic MediaWiki they are just properties.

Properties in Semantic MediaWiki have a type. The default type is Page (remember, the only class Semantic MediaWiki). Editors can assign a property another type, which is always a data type.

Instead of definining a datatype as we did in the preceding section, in Semantic MediaWiki one has to create a page in the namespace Type:. So, if we wanted a datatype OSMKeyType, then we would have to create a page Type:OSMKeyType.

Instead of defining a "fact" with an axiom as in the preceding section

  <OSMValueDef rdf:ID="highway/primary">
    <key rdf:datatype="xsd:string">highway</key>
    <value rdf:datatype="xsd:string">primary</key>
    <onNode rdf:datatype="xsd:boolean">true</key>
  </OSMValueDef>

we just define the wiki page with title "highway/primary" and declare the properties of Semantic MediaWiki in the wiki source:

  

  <!-- page highway/primary -->
  [[key::highway]]
  [[value::primary]]
  [[onNode::true]]

Consequences for OSM map features ?

Properties of any individual must be declared in exactly one article. For instance, we can't define a german display name for highway in one article and the english one in another. If we have two articles describing the same individual then we have actually two individuals. They will show up as two individuals in an RDF export.

Multiplie individuals in the RDF export are less of a problem to us because we have to transform it into our target format for the machine-readable map feature list anyway.

It's more of a problem for maintaning instantiated object properties. If we want to declare that a specific map feature implies another map feature, what individual (or page) should the respective property in Semantic MediaWiki point to?

Assume highway/primary implies motorcar/yes. How would you express this in the english article of highway/primary?

• using [[implies::motorcar/yes]]?
• using [[implies::en/motorcar/yes]]?

And what about the german article ?

• using [[implies::motorcar/yes]]?
• using [[implies::de/motorcar/yes]]?

Note, that motorcar/yes is not an article on its own. It is most likely a redirect to en/motorcar/yes.

We will probably have to accept, that we maintain a network of "facts" about map features for each supported language and that these networks should be identical in structure but they should not overlapp. This will have to be ensured by editors in the same way they today ensure that a wiki link from a english article doesn't point to the german translation of another article, but to its english translation.

Regarding country specific information there is probably another solution. Semantic MediaWiki supports so called "many-valued" properties. The name is misleading because this has nothing to do with cardinality of a property. In fact, a "many-valued" property is a n-ary relation whereas ordinary properties are always binary.

We could use this feature as follows:

• define a property displayName by creating a page Property:DisplayName

• include the type declaration

  [[has type::String;String]]

A display name is acording to this declaration a pair of strings. The first element is considered to be the country, the second the name.

• in the map feature page de/highway include the following property declarations

  [[displayName::DE;Hauptstraße]]
 [[displayName::CH;Hauptstrasse]]
 [[displayName::AT;Bundesstrasse]]

or just

[[displayName::?;Bundesstrasse]]

if the country doesn't matter

Please note that the language context is given by the title of the current article. In the english translation the german display names will disappear, but different english names for UK, CA, etc. could appear.