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 <wendo...@uni-paderborn.de>: > Am 06.05.2013 23:07, schrieb andrzej zaborowski: >> Hi, >> >> On 6 May 2013 21:20, Peter Wendorff <wendo...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
