[OSM-talk] OSM relation ID property in Wikidata

[Peter Wendorff]

Am 06.05.2013 23:07, schrieb andrzej zaborowski:
> Hi,
> 
> On 6 May 2013 21:20, Peter Wendorff <wendorff at uni-paderborn.de> wrote:
>> Am 06.05.2013 20:26, schrieb Tobias Knerr:
>>> On 06.05.2013 18:54, Peter Wendorff wrote:
>>>
>>> [...]
>>>> Let's see this example: A building that was a merchants kontor a few
>>>> hundret years ago, and now contains a museum and a restaurant, while in
>>>> between it was - let's say - a hospital).
>>>
>>> That's historical mapping. The problems would be the same for e.g. the
>>> name. But as for the parts of the example that are not directly "historic":
>>
>> No, it's not. I did not speak about mapping the hospital and the
>> merchants kontor, but about wikidata entries ahout the hospital and the
>> merchants kontor - and wikidata in fact includes historical entities
>> like that, too.
> 
> If you're not adding those historical entities to OSM (or a similar
> database like that historical osm once discussed) then there's no
> issue with linking to Wikidata because there's nothing to be linked.

Why not?
The building is the same, and it's not of interest, that the tag
amenity=museum is not (any more) existent in osm.

If that's an argument any wikidata entity that's not tagged as complete
as the wikidata entity itself would be "nothing to be linked".

Your cross-reference (only add a reference osm pointing to wikidata to
the building, but link all other entities of wikidata to the building)
argument may be valid, but it's complex (that's my question below); but
especially historical entities are of interest to be linked, as they are
not directly findable by going out and watch.


> [...] 
>>>> - the restaurant's page
>>>
>>> Can be linked using the wikidata key at the restaurant POI.
>> You assume here that osm has distinct objects for building, restaurant
>> and museum, but often that's not the case.
>> Let's say the building mainly "is"/hosts the museum, and the restaurant
>> is a small part of it, covering a part of the building only (may be part
>> of the museum, too.
> 
> If it doesn't occupy the entire building then you can probably add the
> museum tag on the building geometry but later once you want to add a
> wikidata tag you'd probably split it out like you'd split a street
> object when you want to add an attribute that applies to a part of the
> attribute.  If you're into indoor mapping then you'd draw the museum
> outline separately anyway.
so you propose to split it up because of an external ID you propose to
add...
While I in general agree that objects of osm are split when they get
mapped in more detail (like in this example), I'm not happy to do that
for the reason to enable matching to external references.

> Or you could do namespaces, basically using the same criteria as with
> different attributes.  For example opening_hours which may be
> different for the museum and the building.  The mechanism can be the
> same for wikidata=* as for e.g. opening_hours=* and oneway=*.
and it's not working for opening_hours either afaik; usually we split
the pois in these cases.

>>>[...]
>>>> Perhaps look into the overpass-permanent-ID solution for that.
>>>
>>> In my opinion that's not really a good solution here. Manually creating
>>> Overpass API queries is too hard.
>> That's true, but what you propose is (yet) hard, too:
>> To decide where to link to wikidata and where to rely on wikidatas
>> internal links requires deep knowledge about the wikidata system, which
>> is IMHO not acceptable as a general precondition for mappers (whose
>> majority will have to deal with that in future to keep these links
>> reasonably up to date).
> 
> Again mappers are already dealing with this problem when they add
> phone= or website= tags.  There's no clear criteria but it's not a a
> problem specific to wikidata links.
Of course not, but even the external id problem is not specific to
wikidata links.

Wikipedia links are for a long time relatively stable, and as wikipedia
I think is often used as one reference for osm, too, it's widely
accepted to be of benefit for both sides.

Wikidata is not yet proven that stable nor that useful, and -
especially: it's a data project. It would be a great task and solution
to design e.g. an overpass-permanent-osm-id-editor that defines the link
in a useful gui (e.g. derived from wikidata attributes like country,
county, city, postcode, location/coordinate, address, ... which might be
part of wikidata, I think.

Wikidata links are harder to maintain, nearly impossible to check
(without opening the page), while wikipedia links have meaningful names.

Wikidata links currently are mostly duplicates of wikipedia article's
entities (as that's the big imported stuff from the beginning).

Therefore I personally oppose currently to reference wikidata entities
from osm objects; at least where no good rules exist where and when to
link which types of objects, and which not.

regards
Peter