User:Gubaer/Sandbox

* [http://de.wikipedia.org/wiki/Hilfe:Vorlagenprogrammierung Vorlagenprogrammierung] * [http://de.wikipedia.org/wiki/Hilfe:Vorlagen Vorlagen] * [[:Template:Gubaer/OsmTagGroupBegin]] * [[:Template:Gubaer/OsmTagGroupEnd]] * [[:Template:Gubaer/OsmTagDeclaration]] {{Gubaer/OsmTagGroupBegin|grouptitle=highway|groupdescription=a description}} {{Gubaer/OsmTagDeclaration |key=highway |value=residential |description=The common default name. (Note: For disputed areas, please use the name as displayed on e.g. street signs for the name tag. Put all alternatives into either localized name tags (e.g. name:tr/name:el) or the variants (e.g. loc_name/old_name/alt_name) |imagename_rendering=Rendering-highway residential.png |imagename_photo=Residential.jpg |onnode=yes |onarea=yes |onway=yes }} {{Gubaer/OsmTagDeclaration |key=name |type=string |rendered_value=User Defined |description=Roads accessing or around residential areas but which are not a classified or unclassified highway. |onnode=yes |onarea=yes |onway=yes |onrelation=yes }}  {{Gubaer/OsmTagDeclaration |key=access |value=no |description=should not be displayed |onnode=yes |onarea=yes |onway=yes |onrelation=yes |dorender=no }}  {{Gubaer/OsmTagDeclaration |key=access |rendered_value=no/yes/designated/permissive/destination |description=should be displayed |onnode=yes |onarea=yes |onway=yes |onrelation=yes |dorender=yes }} {{Gubaer/OsmTagGroupEnd}} === OWL lingo and OSM map features === In the machine-readable map feature list we distinguish between four concepts: <tt>tag-def</tt>, <tt>value-def</tt>, <tt>category</tt> (which is somewhat confusing here, because the term Category is also widely used in Mediawiki and in Semantic Mediawiki, perhaps we should call it <tt>feature-category</tt>) and <tt>preset</tt>. OWL distinguish 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 <tt>OSMTagDef</tt>, <tt>OSMValueDef</tt>, <tt>OSMFeatureCategory</tt> and <tt>OSMPreset</tt> (for clarity, I always included the prefix <tt>OSM</tt> 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 <tt>OSMFeature</tt> (I'd not simply call it <tt>OSM</tt> 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 <tt>highway</tt> is an ''indiviual''. It's class is <tt>OSMTagDef</tt> * the value definition with key <tt>highway</tt> and value <tt>primary</tt> is an ''indiviual''. It's class is <tt>OSMValueDef</tt>. 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 <tt>OSMTagDef</tt> would have the ''datatype properties'': * <tt>key</tt> of type <tt>xsd:string</tt> * <tt>onNode</tt> of type <tt>xsd:boolean</tt> * <tt>onWay</tt> of type <tt>xsd:boolean</tt> 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 <tt>OSMKeyType</tt> could define that keys consist of <nowiki>[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::highway/primary]]?
using [[implies::en/highway/primary]]?

And what about the german article ?

using [[implies::highway/primary]]?
using [[implies::de/highway/primary]]?

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

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 therefore a pair of srings. The first element is onsidered 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 different german display names will disappear, but different english names for UK, CA, etc. could appear.

temp

I think I understand what you mean, but I think, that we don't separate human date from osm data in you proposal. Furthermore, I still believe that the naming schema highway/trunk/UK/en is not suitable because it is ambiguous.

Here's where I agree and where I suggest slight modifications:

there would be a language a country independent article, say Feature/highyway/primary (don't worry about the leading Feature, I come to that later), which respresents the individual and declares its language and country independent semantic properties. Except for this this declarations, the article will be empty. In this sense it only includes semantic content.

there would always be at least one language specific page, today usually Feature_en/highway/primary, which describes the map feature to human readers and declares language specific semantic properties. Here semantic content and human readable content is mixed. Optionally there are other language specific articles for the same map feature, i.e. Feature_en/highway/primary

there can be a country specific, language independent article Feature_GB/highway/primary which includes the declarations of country specific but language independent semantic properties.

there can be a country specific, language dependent article Feature_GB_en/highway/primary which includes the description of country specific properties in a specific language to humans. It also declares language and country specific semantic information. Example (for Switzerland which uses four languages):
- Feature_CH_de/highway/primary would include the german display name for highway/primary used in Switzerland
- Feature_CH_fr/highway/primary would include the french display name for highway/primary used in Switzerland
- Feature_CH_it/highway/primary would include the italian display name for highway/primary used in Switzerland

back to this prefix Feature..... Rather than appending language and country specific information to a map feature title I suggest to prepend it. Here's the idea:

Titles of map feature articles always start with either

Feature/.... - the language and country independent article, just semantic properties, no content. Example: Feature/highway/primary
Feature_lang/.... - the language dependent, country independent article, semantic properties and content . Example: Feature_en/highway/primary
Feature_COUNTRY/.... - the language independent, country dependent article, just semantic properties, no content . Example: Feature_UK/highway/primary
Feature_COUNTRY_lang/.... - the language and country dependent article, semantic properties and content . Example: Feature_CH_de/highway/primary

The main advantage of this approach is, that the naming schema does not lead to ambiguities. If we had a map feature country with values UK and CH, then country and language specific articles would be names:

Feature/country/UK
Feature_UK/country/UK or Feature_DE/country/UK
Feature_en/country/UK or Feature_de/country/UK
Feature_UK_en/country/UK or Feature_CH_fr/country/UK

</nowiki>

User:Gubaer/Sandbox

How does this map to Semantic MediaWiki ?

Consequences for OSM map features ?

temp

Navigation menu

Search