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

[Andy Mabbett]

"On 29 May 2015 at 09:58, Martin Koppenhoefer <dieterdreist at gmail.com> wrote:
>
> 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.

It proves nothing of the kind, Does OSM still have work needing to be
done? Is OSM "not sufficiently mature to replace" other mapping
services?

> 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,

How long does it take a new mapper to understand how to make such edits in OSM?

> and the fact that not all tags are shown to me

Try logging in and enabling the "Labels list" gadget; or alternatively
https://www.wikidata.org/wiki/Q1?withJS=MediaWiki:Gadget-labelLister.js
for the Q value of your choice (I did say I would provide an update
about this in an earlier post)

> (e.g. only 4
> out of all language labels, after I have explicitly clicked on "in more
> languages")) doesn't help.

Did you use the "configure" link alongside that?

> 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?

There is no Italian Wikipedia article about the steps. So what?

>> > 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.

There would be no such resistance.

> 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.

It's trivially easy. You just said atht you haven't yet learned to do
so, that is all.

>> > 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.

We have another set of problems: Disagreement over when to include
names; insufficient volunteer-hours, etc.

> 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,

Why would they? I say that claim is bogus.

> 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,

For those who wish to do so, this is not onerous.

> 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).

Not if, as others have suggested, data is cached.

In any case, WIkdiata's relaibality, like other WMF projets, is
commendably high.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk