[OSM-talk] Can wikidata links help fight name inflation?

Martin Koppenhoefer dieterdreist at gmail.com
Fri May 29 08:58:38 UTC 2015


2015-05-28 23:00 GMT+02:00 Andy Mabbett <andy at pigsonthewing.org.uk>:

> On 28 May 2015 at 09:50, Martin Koppenhoefer <dieterdreist at gmail.com>
> wrote:
>
> > e.g. the "en:Spanish Steps" / "de:Spanische Treppe" are
> > called "Scalinata di Trinità dei Monti" in the local language (it is
> located
> > at "piazza di Spagna", that's where the foreign name comes from, while in
> > Italian it is called after to church it leads to). Naturally, OSM has the
> > original name of this world famous monument, but Wikidata hasn't.
>
> It does now.
>


OK, this is one point for you, but it also proves my point: wikidata at the
moment is not sufficiently mature (IMHO) to replace name tags in different
languages in OSM. Of course you can fix wikidata issues (if you understand
how it is done, I haven't had enough time yet to understand how to make
edits like this, and the fact that not all tags are shown to me (e.g. only
4 out of all language labels, after I have explicitly clicked on "in more
languages")) doesn't help.

// sidenote:

Now I could link the wikidata object of the spanish steps to the OSM object
and get an Italian name. But I will not have an Italian wikipedia article
about it, because it is covered in the spanish square (piazza di spagna)
article in Italian. How would I ideally procede now?

a) in wikidata link the article of the piazza di spagna (in italian) to the
wikidata object about the spanish steps?

a2) like a) but link to an anchor: Piazza_di_Spagna#La_scalinata ?

b) in wikipedia split the italian wikipedia article in 2, one for the
square and one for the steps?

c) in osm add an additional tag like
wikipedia:it=Piazza_di_Spagna#La_scalinata to the steps object?

d) something different...

//sidenote off



> > If we were to massively use wikidata _instead of duplicating some details
> > from there also in our db_ we would have to improve wikidata as well,
>
> You'd be welcome to do so.  ...


> > and impose our entity structure on them,
>
> Really? Good luck with that.
>


what I meant, and what you do confirm below: if for instance there is an
object in wikidata which is an administrative entity and a geographic place
at the same time, but for OSM we'd need 2 distinct objects, we will have to
split the wikidata object. This could be done only if there wasn't
resistance from other wikidata users who might want to keep the current
unmodified object because it links better to wikipedia articles. We might
introduce another object that linked the split objects onto one, which
could serve for wikipedia articles, etc. but this is a much more
complicated procedure than changing tags in OSM alone.

We've always said that we wanted editing to be simple, so that we can
maximize the amount of available editors, but with the tight integration of
another dynamic dataset (for one of the core competences we are dealing
with: toponyms)



>
> > or it won't work in some cases (and if it doesn't work in some case, it
> doesn't work at all).
>
> That is, of course, nonsense.
>


OK, let's say it is nonesense, because you can accept that a solution works
for most of the cases and try work around those that don't work. Currently
(all names in OSM) we don't have these problems though.



>
> > Another issue I see with wikidata is that it contains information and
> > details about spatial objects, but it doesn't contain the geometry it
> refers
> > to.
>
> The geometry is in OSM, is it not? Why would Wikidata want to replicate
> that?
>


IMHO you have to understand to which geometry you are referring when you
make edits, or you might break stuff without noticing it. Wikidata editors
would have to look at OSM geometries to ensure that their edit maintains
consistency, and OSM users would have to check wikidata to see if editing
something in a certain way (e.g. merges or splits, adding tags, changing
geometry) is OK or whether they have to split the wikidata object and
update the wikidata link. It is not impossible, but it is an enormous
amount of complexity added, and it also augments the risk of
non-availability of the backend by 100% (because now we depend on 2
services and not on one).


I want

> > to point out is that there seem to be different criteria defined for
> > different languages:
>
> These descriptions aid users; they are not proscriptive. There are
> also local and cultural variations. Just like "city" in OSM.



Maybe these are descriptions to aid in some regional wiki projects and
proscriptive rules in others like Germany, where rules rule? Just like in
OSM ;-)
It would rather confuse than aid me if the descriptions in some language
says something is foo and in another language they tell me it is not foo.




TL;DR; wikidata is a gorgeous project, combining their knowledge with ours
is very promising. Still, in my opinion, for the current state of where
they are (and where the tools to combine both are), I would _not remove
tags_ from OSM just because the same information might be available in
wikidata.

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20150529/e12098c8/attachment.html>


More information about the talk mailing list