User talk:Ck3d/Ontology Proposal
< User talk:Ck3d(Redirected from User talk:Ck3d/Sandbox)
Jump to navigation
Jump to search
Ontology
OSM Element
Key
Value
Tag
Role
Member
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)
- Title
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:
- indeterminate tags Template:KeyDescription
- determinate tags Template:ValueDescription
Tags need the prefix "Tag:" to be distinguishable from roles.
- Title
[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)
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)