[Tagging] Wikidata tag

Peter Wendorff wendorff at uni-paderborn.de
Wed Feb 27 15:04:48 UTC 2013

You "call for editor support" for a new external ID that's not controllable.
You want it to be a replacement (well, you agree to keep the old tags, 
but your argumentation is that the old tags are not necessary any more 
with the existence of Wikidata.

This contains several preconditions you assume to be fulfilled:

1) wikidata will not go away or change it's IDs before osm is dead.
Maybe you're right; I think, for wikidata there is in fact a chance for 
this to happen.

2) wikidata will not change the meaning of the content of what there is 
behind any ID.
I'm not sure here. As we refine an object by different new objects again 
and again the same might happen to wikidata, changing the meaning of 
e.g. Qxxxx (let's say McDonald's) from the brand of the many burger 
shops to the holding itself, while introducing Qxxxxy for the brand 
McDonalds, or refining Qxxxxx to be the holding itself, without 
containing McDonald's Germany and the other country-specific 
sub-companies. Sure: Users might again be able to follow the wikidata 
information network down to all country-specific sub-companies and pull 
all restaurants out of it, but that's not automatically again, I guess.

Adding this might be acceptable for most mappers, but replacing our own 
data is a problem as it relies on wikidata to be correct and stay stable 
up to the meaning of entries, which is not guaranteed as far as I know 
(and I have now idea how this COULD be guaranteed AND kept up to date on 
the same time).

3) let's take another example, the "Eckmänneken", an old house in 
Warburg, Germany [1]. It's the oldest "Fachwerk" house in Germany and 
contains a greek restaurant. Both might be a valid reason to add it to 
wikidata, the restaurant business as well as the building itself.
In OSM nevertheless both could be tagged on the same object (it is not, 
but it could be, and often that is the case). If you add a wikidata ID 
to it - would it be one to the restaurant or to the building? Or to both 
- how?

IMHO it's okay to link to wikidata, but it doesn't help: Neither it does 
make live easier for mappers nor it reduces errors in the data. With 
tool support (as you propose) it might work, but without - and that's 
now the case - it's useless.

I would suggest you to write the corresponding tool support first, 
supporting the wikidata id, show what's possible with that, and then 
spread the word about the tag itself; but the wikidata id as the id 
alone is useless and worse than not adding it in many cases.


[1] https://de.wikipedia.org/wiki/Eckm%C3%A4nneken

Am 27.02.2013 14:19, schrieb Simone Saviolo:
> 2013/2/27 Pieren <pieren3 at gmail.com <mailto:pieren3 at gmail.com>>
>     On Wed, Feb 27, 2013 at 2:06 PM, Simone Saviolo
>     <simone.saviolo at gmail.com <mailto:simone.saviolo at gmail.com>> wrote:
>     >> Because it might create inconsistencies.
>     > Does not, as I pointed above. You don't use two tags at the same
>     time for a
>     > single piece of information. At most, you use a second fallback
>     one _in case
>     > the first is not available_.
>     To be clear, you will never find a consensus for replacing our
>     existing tags by a wikidata "Qxxxx" number. This has been already
>     proposed several times in the past (not by the wikidata id but some
>     other similar abstraction). As Steve said earlier in this thread, it
>     might be tolerated only as an additional tag. Therefore the
>     duplication.
> I'm talking consumers, in case you didn't get it. Do you "tolerate" 
> it? Ok. If there's a consumer that uses it, it works for them, it 
> works for us.
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130227/17d7e030/attachment.html>

More information about the Tagging mailing list