User:Roland.olbricht/Data Items as Relations
These are thoughts how to transfer the content of OpenStreetMap's data items for tagging into the OpenStreetMap database itself. The basic idea is to have per key and per documented value of a key one describing relation. The three advantages are that this has zero maintenance overhead because data structures already exist. And the visibility is improved a lot because many generic tools are flexible enough to be useful to show or edit the data already right now. Think of JOSM and Level0. Finally, all the processes of updates and looking at the history are immediate well-defined because they take over from the rules for relations.
The downside is that this creates another class of relations, after disguised areas, turn restrictions, routes, and a couple of less prominent use cases. This turns into an advantage if we keep the strategy to turn these settled types of relations into proper data structures over the next couple of years - once we know what data structures we really need.
Data Model for Data Items
The headlines correspond to those on the data items page.
Tag keys
A relation that describes the key of a tag shall have the following tags:
| key | value | corresponds to | comment |
|---|---|---|---|
| type | key | n/a | marker for this type of relation |
| key | key | various labels | the key that the relation describes |
| desc | text | description | Description in the default language, usually (always?) British English. We are glad to have "Must be less than 250 symbols." for the data items. |
| desc:X | text in language X | description | Description translated to language X. |
| nodes | yes/no | applies to nodes (P33) | Suggestion, neither now nor in the future enforced. |
| ways | yes/no | applies to ways (P34) | Suggestion, neither now nor in the future enforced. |
| areas | yes/no | applies to areas (P35) | Suggestion, neither now nor in the future enforced. |
| relations | yes/no | applies to relations (P36) | Suggestion, neither now nor in the future enforced. |
| image | URL | image (P28) | @OWG: check whether we want to use Mediawiki for this or not before definitive advice where to link to. |
| status | de_facto/approved/rejected | status (P6) | Plus some more unusual states. Anyway not enforced. |
| validation_regex | UTF8 string | value validation regex (P13) | Accommodate what exists in the data items today. Unclear if used and the quality of the data. |
A couple of other properties are best represented as members:
| role | target type | corresponds to | comment |
|---|---|---|---|
| value | relation with type=value | key type (P9) | One member per fixed documented value. If validation_regex is used then apparently free-form values are acceptable to or only. |
| requires | relation with type=key or type=value | required key or tag (P22) | Accommodate what exists in the data items today. Unclear if used and the quality of the data. Apparently overlap with presets. |
| implies | relation with type=value | implies (P45) | Accommodate what exists in the data items today. Unclear if used and the quality of the data. |
| combination | relation with type=key or type=value | combination (P46) | -
Apparently overlap with presets. |
| differs_from | relation with type=key or type=value | different from (P18) | Accommodate what exists in the data items today. Unclear if used and the quality of the data. |
The remaining properties of data items for keys seem to be redundant. E.g. OpenStreetMap relations intrinsically have an id. I'm happy to change to scheme if I have overlooked something.
A potential improvement over the existing data items could be for example to add a regional scope as a link to an existing boundary. However, this is not relevant to organize the data transfer right now, because no spatial scoping exists today.
Tag values
A relation that describes the value of a tag shall have the following tags:
| key | value | corresponds to | comment |
|---|---|---|---|
| type | value | n/a | marker for this type of relation |
| value | value | various labels | the value that the relation describes |
| desc | text | description | Description in the default language, usually (always?) British English. We are glad to have "Must be less than 250 symbols." for the data items. |
| desc:X | text in language X | description | Description translated to language X. |
| nodes | yes/no | applies to nodes (P33) | Suggestion, neither now nor in the future enforced. Not mentioned on the data items page for values. |
| ways | yes/no | applies to ways (P34) | Suggestion, neither now nor in the future enforced. Not mentioned on the data items page for values. |
| areas | yes/no | applies to areas (P35) | Suggestion, neither now nor in the future enforced. Not mentioned on the data items page for values. |
| relations | yes/no | applies to relations (P36) | Suggestion, neither now nor in the future enforced. Not mentioned on the data items page for values. |
| image | URL | image (P28) | @OWG: check whether we want to use Mediawiki for this or not before definitive advice where to link to. |
| status | de_facto/approved/rejected | status (P6) | Plus some more unusual states. Anyway not enforced. |
None of the existing properties need to be modeled by membership.
Relations
It looks like the content is completely redundant. The actual information is the link to the relation:.. page, and that link can always be auto-generated from knowing that relation is an admissible type for the respective value of the key type.
Relation roles
Should be a member of the relation type for which it is admissible.
| key | value | corresponds to | comment |
|---|---|---|---|
| type | role | n/a | marker for this type of relation |
| role | role | various labels | the role that the relation describes |
| desc | text | description | Description in the default language, usually (always?) British English. We are glad to have "Must be less than 250 symbols." for the data items. |
| desc:X | text in language X | description | Description translated to language X. |
| image | URL | image (P28) | @OWG: check whether we want to use Mediawiki for this or not before definitive advice where to link to. |
| status | de_facto/approved/rejected | status (P6) | Plus some more unusual states. Anyway not enforced. |
| validation_regex | UTF8 string | value validation regex (P13) | Accommodate what exists in the data items today. Unclear if used and the quality of the data. |
The remaining properties of data items for keys seem to be redundant.
How to edit
These are edit flows that works right now. It should be possible to have much smoother edit flows once the approach gets traction.
By JOSM
You first need to turn on Expert mode: Tick the box under View > Expert Mode.
Edit an Existing Relation
Use File > Download Data > Download from Overpass API to get the needed relations.
For key describing relations without their value children:
rel[type=key][key=$KEY];
out meta;
For key describing relations with their value and role children:
( rel[type=key][key=$KEY]; rel(r:"value")->.val; rel(r:"role"); );
out meta;
For value describing relations:
( rel[type=key][key=$KEY]; rel(r)[value=$VALUE]; );
out meta;
Go then to Windows > Relations and select the relation you want to edit.
Add a New Relation
Ensure that the relation does not exist already.
Go then to Windows > Relations and use the plus button to create a new relation. Set the necessary tags from the list above.
Finally ensure that the relation is a member of the relations that it belongs to, i.e. a value relation is a member of the key relation.
By Level0
.. TODO ..