[Tagging] Issues relating to URIs and tagging

Dan S danstowell+osm at gmail.com
Tue Apr 1 16:31:01 UTC 2014

Hi Andy,

2014-04-01 16:29 GMT+01:00 Andy Mabbett <andy at pigsonthewing.org.uk>:
> Hello everyone,
> This is my first post to the list, which I've just joined, but I've
> been a mapper for a few years and some of you might remember me as
> compere at last year's State of the Map.

And well done indeed!

> Yesterday, I met with the W3Cs'  "data on the web best practice"
> working group. At their request, I gave a talk on the use of URIs
> (particularly linked data URIs) and related tags,  in OSM.
> I described, and we then discussed, how we tag entities in OSM, using
> UIDs but not necessarily URLs, and issues facing data users who need
> to resolve those UIDs back to URLs; for example:
>     openplaques_plaque = 1536
> to:
>    http://openplaques.org/plaques/1536
> To that end, I've just modified [[Template:KeyDescription]] by adding
> two parameters:
>    https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:historic%3Dmemorial&diff=prev&oldid=1010411
> for "website" and "url_pattern"

That URL doesn't seem right. I think you mean

> see:
>    https://wiki.openstreetmap.org/wiki/Key:openplaques_plaque
> of an example of how they're intended to be used (the label display
> needs tweaking).

Tell me if I've misunderstood you, but you're proposing that the
url_pattern given in the wiki "infobox" KeyDescription is intended to
be machine-readable, in the sense that a third-party data consumer can
plug url_pattern together with the actual key-values found in OSM and
automatically find the URL for something? If so, the idea is
intriguing and I think it's a nice lightweight thing we can do.

I have a small quibble which is please change it from "URL" to "URI",
since I think the latter is the more appropriate concept. We're aiming
to interlink _identities_ of items really, for the machines.

> The model used there fails with Wikipedia links,
> expressed as "en:Example", because the equivalent URL is
> <https://en.wikipedia.org/wiki/Example>. Any suggestions for dealing
> with that?

I don't see a plausible way of dealing with this that wouldn't be a
crazy hack. So I'd recommend that data re-users will simply need to
treat this as a special case if it's important to them. (I've always
thought the wikipedia tag would have worked better as
"wikipedia:en=Example" -- in that case, your template approach would
have worked fine.)

> They were very impressed with the inclusion of Wikidata IDs
>    <https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wikidata>
> The sooner we move that from "Talk:Proposed_features/" to "Key:", the better.

Wikidata proposal looks good to me.

> Other issues which are unhelpful to data re-users include keys with
> missing documentation; redundant keys ("Key:openplaques_plaque" vs
> "Key:openplaques_id");

I have never seen these tags, but there are very few uses - this
example is probably really easy to consolidate into one tag.

The harder cases will - as discussed in recent threads on this list -
will remain in a state of productive controversy for a long time to
come! Sorry, data re-users, but that's wiki-life for you.

> ambiguous keys ("ref=1234" - ref in whose database?)

That's an interesting question. "ref" is widely used, and generally
used quite coherently, _but_ its meaning is contextual on other tags.
For example, "amenity=post_box" & "operator=Royal Mail" tells you
where to expect the ref to point. I wonder if "operator" sets the
context in many other cases? (I accept, of course, that many objects
aren't tagged with operator.)

> and the perennial problem of the lack of stable URIs for entities in OSM. I have yet to solve that one...

OSM objects are not stable, same as Wikipedia articles. For Wikipedia
they provide partial stability through long-term historical "oldid"
links and redirects. I don't think tagging (i.e. this list) can solve
the permalink problem. It needs osm.org to provide a URL scheme that
allows people to link to a specific historical _version_ of an osm
object. We already provide direct links to changesets and to object
histories, so the data is all there.


More information about the Tagging mailing list