[OSM-talk] OSM relation ID property in Wikidata

[andrzej zaborowski]

Hi,

On 6 May 2013 21:20, Peter Wendorff <wendorff en 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.
If on the other hand you want to add that hospital and that kontor,
then in the historical mapping schema I believe you'd add them as
separate objects with their own start_date and end_date tags so that's
what would link to wikidata (if you wanted to).

>
>>
>>> - the merchant's person page (his office)
>>
>> Wikidata would link to their internal building item instead. Not our job
>> imo.
>>
>>> - the museum's page
>>
>> Can be linked using the wikidata key at the museum POI.
>>
>>> - 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.

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

> We don't have distinct objects in OSM in every case. Without the
> restaurant, the museum and the building are the same, identical object;
> but may be divided later perhaps into two objects (where one changes
> it's semantics)
>>
>>> - the architect's page
>>
>> Can be linked using the architect:wikidata key at the building.
>
> Now you introduce a different approach to my overall question, and start
> to use namespaces for wikidata-tags.
> So why not in general use namespaces for all (even the cases above):
>
> restaurant:wikidata
> museum:wikidata
> architect:wikidata
> fire1934:wikidata
> merchant:wikidata
>
> I think, that get's very verbose once wikidata lifts off, and I don't
> think it's a good idea.
>
>> It could be argued that we should leave that to Wikidata, though - they
>> have an "architect" property for buildings themselves.
> +1
>
>>
>>> - the page of the person where the name of the building comes from
>>
>> Can be linked using the name:etymology:wikidata key at the building.
>> Again, we theoretically could omit this and instead rely on Wikidata's
>> "named after" property.
>
> To sum up your arguments:
> well... let's use foreign keys, but only somewhere.
> What's the rule you propose for this? when to use the wikidata-tag and
> when not?
> Is it possible to describe a rule for this? (even if we don't want to
> enforce that rule, somehow what you propose should be documented and
> therefore has to be documentable in a reasonable form).
>>
>>> 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.

Cheers