DEMO: Storing tag metadata in OSM Wiki using Wikibase

nyuriks · 2018-08-21T01:44:49.000Z

Over the last weekend I set up a prototype of the OSM Wiki with Wikibase - the engine that runs Wikidata. Adding it to OSM Wiki will allow Key:* and Tag:* pages to store some of the data in the machine-readable, multilingual format. This feature has been proposed and received a lot of attention by both the community and the tool developers (e.g. taginfo and iD), and would greatly help with the tag management.

Details and links to the demo site: []](https://wiki.openstreetmap.org/wiki/OpenStreetMap)

Your feedback is greatly appreciated! The biggest open question is what type of metadata we would want to store, and how it should be structured. Thanks!

mmd · 2018-08-21T09:41:30.000Z

Cool. Another use case could be to assign respective symbols to a key=value: https://github.com/gravitystorm/openstreetmap-carto/tree/master/symbols

Although the actual symbols are probably project specific, having some means to store this relationship would be useful. This way, https://github.com/openstreetmap/openstreetmap-website/blob/master/app/assets/stylesheets/browse.scss could be generated by some script instead.

Tordanik · 2018-08-25T10:05:33.000Z

Amazing to see progress with this project!

Reading the types of items in the Implementation section, I have one request: The OSM wiki is not just for tagging documentation, and I feel the OSM Wikibase installation should likewise not be just for tagging documentation. I previously mentioned the potential usefulness of item types such as User group and Software, to make the data that’s currently in the infoxboxes machine readable. Very similar benefits (external tools are currently forced to parse wikitext, we could eventually generate tables on the wiki instead of maintaining them by hand) would apply here.

Some brainstorming regarding tag and key items: It would probably make sense to get inspiration for properties from the existing KeyDescription and ValueDescription templates. Properties such as “requires” and “implies” would seem straightforward, as would a Wikidata link. The status and statuslink field could likewise be modeled as properties. Additionally, it would be interesting to store default units and other established units as properties of a key item.

nyuriks · 2018-08-25T21:14:22.000Z

Tordanik:

Amazing to see progress with this project!

Reading the types of items in the Implementation section, I have one request: The OSM wiki is not just for tagging documentation, and I feel the OSM Wikibase installation should likewise not be just for tagging documentation. I previously mentioned the potential usefulness of item types such as User group and Software, to make the data that’s currently in the infoxboxes machine readable. Very similar benefits (external tools are currently forced to parse wikitext, we could eventually generate tables on the wiki instead of maintaining them by hand) would apply here.

Some brainstorming regarding tag and key items: It would probably make sense to get inspiration for properties from the existing KeyDescription and ValueDescription templates. Properties such as “requires” and “implies” would seem straightforward, as would a Wikidata link. The status and statuslink field could likewise be modeled as properties. Additionally, it would be interesting to store default units and other established units as properties of a key item.

Of course, the types of items can be anything - it’s just a matter of creating a new item to describe a new type, and using it as a value of the instance-of for the other items.

I’m still on the fence about the status of a key - e.g. stable/experimental/… – we could either create a property with several values (a more straightforward approach), or we could use “badges” functionality – in Wikipedia, they are used to indicate high quality articles, and they show up as little icons next to the sitelink (in our case - in the upper right corner, next to the Key: link). Badges are not as straightforward to set (you need to use a special page for that), they must be set up in code, and they have a different storage semantics, but their benefit is that they are very prominently displayed as an icon. The reason WP has them as they do is because it is not a “per-wikidata item property”, it’s a “per-sitelink property” (Wikidata item “dog” could have an excellent article in French, but badly written article in English).

Feel free to update the wiki page with your ideas, e.g. the types of values we may want to store.

Thanks!!

nyuriks · 2018-09-28T06:13:34.000Z

Here’s a demo of the KeyDescription template that no longer needs any parameters.

Tigerfell · 2018-09-29T13:59:45.000Z

Please explain how you infer the language if you do not use a template parameter.
I could not really extract that from the source code…
Thanks.

nyuriks · 2018-09-29T18:24:22.000Z

Tigerfell:

Please explain how you infer the language if you do not use a template parameter.
I could not really extract that from the source code…
Thanks.

I didn’t write it clearly, sorry For now, the language is taken from the lang parameter. I tried to infer it from the {{int:lang}} but that doesn’t work. I can fairly easily add language detection based on the current page title, e.g. if the page title matches ^[1]+:(tag|key):, then use the first part as the language code. Should be an easy change.

-a-z_ ↩︎

nyuriks · 2018-09-30T02:08:41.000Z

UPDATE: I made a new module OsmPageTitleParser, so now the description templates work automagically on any page, including talk pages, even if no lang/key/value parameters are given.