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
