[OSM-talk] OSM relation ID property in Wikidata

Tue May 7 07:04:24 UTC 2013

Hi.

Do you have any idea how this permanent ID could look like?
You dislike the overpass-approach (and yes, it's far from perfect).
What is your idea how a stable permanent ID to an object may be achieved?

Let's use a shop as an example (and wikidata as the foreign database as
an example, too).

1st stage: it's not mapped at all - okay, nothing to link to.
2nd stage: someone maps a shop - and only that shop, without name or
anything like that. Wikidata could of course link to the osm id, even if
it only contains a coordinate and "shop=supermarket", but if they want
to do that, they have more information they could add to osm easily,
like name and usually at least parts of the address.
3rd stage: someone (e.g. the wikidata people) adds these details - the
overpass-api get's slightly more stable (I know, not completely stable
of course).
4th stage: someone replaces the node by a polygon mapping the
supermarkets building as a whole. Now the osm id has changed, so your
approach to use that as a link key fails here.
5th stage: someone refines that polygon to include the hole in the
middle, so it get's a multipolygon relation. again the internal osm id
changes, the overpass-api (when designed usefully) is kept.

6th stage: the name of the shop changes (small change due to corporates
decision, nothing really useful): The osm id is stable here, overpass is
likely to fail now (but knows about this failure as it's possible to
acknowledge the dead link).

7th stage: the shop moves to another address, therefore the tags are
moved to another building, let's say, 3 streets away. The OSM id looks
like it's still stable, but links to the wrong object. The overpass-id
is either still valid or is automatically known to be a dead link.

I agree, that the overpass-api isn't perfect and it's still possible to
produce links that are either (or may get) ambiguous or that may break
due to any edit in future. But the internal OSM ID has even more
drawbacks: while the overpass-permanent-id includes semantics for the
link, the osm id is a pure technical link.

I'm keen to get a better idea how that could be achieved, or why you
really think that the osm id is really better than overpass with respect
to stability and maintainability.

regards
Peter

Am 07.05.2013 00:31, schrieb Stefan Keller:
> Hi,
> 
> I also think that linking from an OSM object to a growing no. of
> external databases (incl. Wikipedia/Wikidata) is not a good idea. And
> I respect the wish of the OSM maintainers to change the OSM id in the
> future. But the overpass-permanent-osm-id is no solution neither,
> primo because a set of key-values is a clumsy id, and secondo because
> there exist many OSM objects which have no identifying tags (or none
> at all).
> 
> As this issue pops up from in increasingly frequent intervals I think
> it's time to think about a good mid term solution (short term is
> sticking to the OSM id).
> 
> I'm proposing a solution alongside one of the following two directions:
> * either to implement a Linked Data API/service which maps from
> permanent ids to OSM objects (and which is what I like about overpass
> - being a service) -
> * or to add a permanent id as an additional XML tag to every OSM
> object! And if somebody thinks that's a waste of space we can easily
> drop the XML tag "user" which is completely redundant to "uid" (which
> in turn needs another simple API to find out the current users display
> name).
> 
> Yours, Stefan
> 
> 
> 
> 2013/5/6 Peter Wendorff <wendorff at uni-paderborn.de>:
>> 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
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk
> 