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. > >> - 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. 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). regards Peter _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
