Hi Janko,
something like that was proposed on the wikidata side already if I
remember right.
The idea was to store some kind of query on wikidata, e.g. the
Overpass-Permanent-ID [1], which would be used exactly as you say:
it can fetch the arbitrary object(s) that match and should match;
independent of changing OSM object ids, splits or other stuff like that.

I don't find the right page where that happend, probably my memory is
corrupted ;)

regards
Peter

[1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Am 31.08.2014 um 16:46 schrieb Janko Mihelić:
> Hi Frederik, great post.
> 
> I always thought wikidata tags would be a first step to a new database that
> OSM needs, and which would be something like Wikidata is to Wikipedia. A
> database that classifies and categorizes elements in OSM. In my opinion a
> slightly modified version of Wikibase could be enough. It would have
> combinations of tags and areas where that category applies.
> 
> If we had a database item in our potential OSM-wikibase that said "all
> primary highways with ref 55 in the UK" and then offload the proprietary
> identifiers there, I think no one would mind.
> 
> Another problem this potential database solves is the often quoted
> "relations aren't categories". We could make an item "HSBC ATM machines"
> and add a few tags that define an element as a HSBC ATM machine
> (amenity=atm + operator=HSBC, or amenity=atm + ref:HSBC=34 or whatever)
> 
> Even wikidata tags that we are discussing could be deprecated if we had
> such a database. We would have our own identifiers (O3489 instead of
> Q23489) and those identifiers would link to wikidata as well as to other
> databases.
> 
> If we don't make our own database that categorizes our tags and elements,
> someone else will do it. In this case, it's Wikidata, which is better then
> the rest because it is crowdsourced, it has an open license for it's data,
> and it has opensource software for it's database and user interface. So if
> I'm not mistaken, we could fork their project if that was needed. But if I
> could choose, we would have our own.
> 
> Janko Mihelić
> 
> 2014-08-30 23:40 GMT+02:00 Frederik Ramm <frede...@remote.org>:
> 
>> Hi,
>>
>> On 08/29/2014 08:10 PM, Rob Nickerson wrote:
>>> Lets just step back and reflect on this for a minute.
>>
>> My overarching concern is that if this import is done, future imports
>> will use the "but we also have Wikidata links" argument for justification.
>>
>> What we have here is a third-party database whose object identifiers we
>> add to OSM as tags in order to make linking things easier.
>>
>> This is something that has often been requested by people but never been
>> granted on a large scale because we always said that it would be an
>> abuse of our database and our mapper's patience to offload everyone's
>> and their dog's linking requirements onto us.
>>
>> Imagine every single stretch of road being tagged with three different
>> proprietary (or at least competing) identifiers of traffic information
>> providers, or similar payload tacked onto OSM.
>>
>> I'm not saying no to a Wikidata import but I would like the proponents
>> to state clearly what makes this import special - why this and not, for
>> example, Ordnance Survey TOIDs or IDs of Mapillary photos?
>>
>> I would like to define high hurdles for such an import. The import costs
>> us a lot (in terms of mappers having to spend time to understand the
>> tags and know how to handle them when they edit an object, more quality
>> checks, etc.), and it must be proven - or at least expected - to offset
>> that cost by making itself useful. It's ok of this particular import
>> clears the hurdles but at least I can then use the hurdles if the next
>> guy in line comes along and wants to import his keys too.
>>
>> Also, I note that Rob wrote:
>>
>> "We have our own restrictions (verifiable on the ground, not changing to
>> frequently) in OSM. A link to wikidata allows us to continue with these
>> restrictions but still allow people to get at interesting non-geographic
>> data."
>>
>> And Andrew said:
>>
>> "A few more points: This isn’t a deletionists’ charter and we shouldn’t
>> rush to unload any tagging onto Wikidata without discussing the removal
>> very carefully."
>>
>> I am personally very much in favour of "unloading" non-geo-database
>> tagging elsewhere. We started with marking restaurants (useful) and
>> recording their names (also useful), classing them into fast-food or
>> "proper" restaurants, then tagging what cuisine they have and how to
>> contact them for booking a table, and meanwhile we're recording whether
>> they have vegan food and what their opening times are and whetehr you
>> can pay with bitcoin. We don't currently have anywhere to "offload" that
>> information which is all useful for certain use cases, but once we have
>> a working integration, I should very much hope that stuff like the menu
>> and the opening times will be recorded either in OSM or in Wikidata but
>> not both.
>>
>> Allow me one question in that matter as a Wikidata ignorant though: Are
>> there any notability rules in Wikidata? For example, if we should one
>> day decide that restaurant opening times should not be recorded in OSM
>> but on Wikidata, can it then happen that someone records a restaurant's
>> opening times on Wikidata only to have that information kicked out by
>> someone else again for lack of relevance?
>>
>> Because if that were the case, then Wikidata would be relatively useless
>> as a general offloading point for non-geodata.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> _______________________________________________
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> 
> 
> 
> _______________________________________________
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Reply via email to