User talk:Ck3d/Ontology Proposal

From OpenStreetMap Wiki
Jump to navigation Jump to search



OSM Element












Removed from proposal

Ontology (old)

This proposal uses special values. These values are masked with a beginning "(" and an ending ")". Special values of this proposal are:

value meaning
* any
blank empty

Basic Object (old)

OSM defines basic object types (nodes, ways, areas, and relations). Each object needs its own page because the features refer to it.

Issue Not necessarily, in my opinion, but possible. Consequently, our ontology would have a class Element or (OSMElement, or whatever name we agree on). What are semantic properties of this class which could be interesting in our context? Except an obvious name property I don't see any. We would know four individuals for this class: node, way, relation and area. It is unlikely that the number of individualsfor this class is going to change in the future. No wiki editor will come up with an idea for another interesting individual for Element and document it in a page. I think that Element is closer to a data type than to a class, in particular to a data type String which is restricted to exactly four values: node, way, area and relation (kind of enumeration).
Gubaer 17:18, 2 January 2009 (UTC)
Yes we don't need it, because a way is not a individual of a basic object. Further we need the classes (OWL) node, way, area, and relations. The tags have to refer to this classes. -- ck3d 20:36, 2 January 2009 (UTC)
Basic Object

Name type string; automatic assignment from Title
name of the basic object

Tag (old)

A tag is the combination of a key and a value. Tags are assigned to basic objects. We have to distinguish between indeterminate tags (Key:..., only key specified) and determinate tags (Tag:...; key and value specified).

Actual OSM used templates are:

Tags need the prefix "Tag:" to be distinguishable from roles.

[Namespace/]Tag:Key/(*) indeterminate
[Namespace/]Tag:Key/Value determinate
Agree (except "roles", see later) Gubaer 17:21, 2 January 2009 (UTC)

Key type string; automatic assignment from Title
key of a tag

Applicable to↗ type page → Basic Object; required one or more
a tag should be used only in combination with basic objects
Issue could live with the fact, that it replaces the properties onNode, onWay, etc. I formerly proposed. But I suggest to use another name which indicates that this tag is applicable to a specific Element - what about Applicable To Gubaer 17:38, 2 January 2009 (UTC)
agreed, changed property from "Refer to" -> "Applicable to" -- ck3d 20:17, 2 January 2009 (UTC)

Has Namespace↗ type page → Namespace; automatic assignment from Title
a tag is significant only in a namespace (e.g. the tags restriction and except)
Issuewhat do you mean with "Namespace" in this context? I don't see that the two examples you mention, restriction and except are only significant in specifc "Namespaces". You're probably not talking about wiki namespaces, are you? Gubaer 17:38, 2 January 2009 (UTC)
Rectriction and except are tags which only be used for the relation restriction, so we have to put these tags in a namespace like Tag:Type/Restriction/Tag:Restriction/(*) -- ck3d 20:17, 2 January 2009 (UTC)

Implies↗ type page → Tag; optional one or more
a tag has implications on other tags
Agree Gubaer 17:38, 2 January 2009 (UTC)

Requires↗ type page → Tag; optinal one or more
a tag has requirements from other tags
Agree Gubaer 17:38, 2 January 2009 (UTC)

Suggests↗ type page → Tag; optinal one or more
a tag has suggestions to other tags
Agree Gubaer 17:38, 2 January 2009 (UTC)

Photo↗ type page → Image; optinal one
photo of a tag
Issue what are indented values for this property? The kind of photos as we have them today in the Map Feature table, last column?
Yes -- ck3d 20:21, 2 January 2009 (UTC)

Name type string; automatic assignment from Title
correct name of a complete tag, key and value; MediaWiki doesn't allow page titles with a beginning lower case character and replaces underlines by blanks; the slash between key and value will be replaced by a equals sign
Issue don't see the difference between Name and Key below Gubaer 17:38, 2 January 2009 (UTC)
Agreed, this property is redundant -- ck3d 20:29, 2 January 2009 (UTC)

"Name of Key" type "variable", automatic assignment from Title
Disagree Above, there already is Name and Key, I don't understand why we need this one.
value will also be assigned to a property that has the same name as the key (Property:Maxspeed, Property:Height, Property:Ele,...)
the property can define the type (Number, Enumeration, Date, URL, ...more types) and the units (m, m², km/h) and the conversions (km/h -> miles, m -> feet); see also custom units
Disagree This is the wrong level of abstraction. If we had a wiki page Property:Maxspeed, we would declare that the property maxspeed can be used as semantic property in the wiki. Property:Maxspeed prepares the wiki such that editors can enter [[maxspeed::50]] on individuals maintained in the wiki. However, maxspeed is not to be used as property in the wiki because we don't maintain instances of elements there. That's what JOSM or other editors are used for.
I'd like to see more precisely defined types for specific tags, granted that mappers still be free to use whatever value they want to. But using SMW to define this type system is not the right approach.
Gubaer 17:57, 2 January 2009 (UTC)
Agree, I will remove it. -- ck3d 20:23, 2 January 2009 (UTC)

Rendering↗ type page → Image; optinal one
a rendering example of a tag

Grouptype string; required ones
category of a tag; physical, non physical,... see TOC Map features or groups
Issue I can live with the name Group, it's probably better to call it that way, not Category or FeatureCategory as I did before. Category is just to confusing in the context of wiki categories. But: I still go for Group as class, similar to Tag. In your notation, the type would become
type page → Group; *
Gubaer 17:57, 2 January 2009 (UTC)
The group definitions are actual not consistent. Therefore we can only provide a property Group which have the type string. -- ck3d 19:27, 2 January 2009 (UTC)
There is no need for grouping tags. The description define the language specific group. -- ck3d 12:44, 3 January 2009 (UTC)

For determinate tags only:

Value type string, automatic assignment from Title
value of a tag
Agree Gubaer 17:57, 2 January 2009 (UTC)

Role (old)

Disagree I don't see the need for this class. I'm afraid that I probably don't understand it. Can you give some examples? I didn't find any in sample individuals below. Gubaer 17:59, 2 January 2009 (UTC)

example "Tag:type=boundary/Role:" -- ck3d 19:01, 3 January 2009 (UTC)

Description (old)


Disagree I don't see why we need a class Description and I don't understand some of the properties proposed below, for instance Group (why refering to a group from a description) or Summary (isn't the description intended to be a summary already?) Gubaer 18:04, 2 January 2009 (UTC)

We don't need the whole description of a feature in a semantic property, only the summary of a description. The property group should hold the translated group name of the referred page, see examples. -- ck3d 20:44, 2 January 2009 (UTC)