61

I believe there’s quite a number of challenges with such an approach. Obviously Mapbox is running such a merging process inhouse for their multilingual maps, though they don’t provide the raw merged data to the outside world anymore. Even this scenario might cause some issues for map users, as they have no idea, where and how to fix potential issues. (and asking Mapbox to fix issues seems a bit difficult these days (see link)).

Let’s take a look at the general process. Other data consumers don’t only rely on Planet dumps, but also apply minutely diffs to keep their distributed databases up to date (you’ve been through this already…). Mappers also use such distributed mirror databases to download parts of the OSM data, hopefully do some improvements to the data and then upload it again to OSM.

If we were to inject some data from wikidata (say the population, or an elevation tag, or maybe some tag which no longer is kept around in OSM) at some point in this process, it very quickly becomes quite messy: Once the replicated data hits such a database mirror, you have no idea where the data originates from anymore. On the other hand, people expect those tags (e,g, population / elevation) to be in OSM, so you won’t have much fun running a “pure OSM” version.

Bottom line: Keeping that clear cut distinction between “OSM only” and “augmented version” is something I consider not feasible in real life day to day usage of the data. And those are only the technical issues…

Population is an interesting topic. First of all, I noticed that your query somehow gives random results when multiple population tags at different points in time are available. Somehow this should be restricted to those valid at the current date. Apart from that it’s probably worthwhile looking into more details:

I noticed several cities in Australia, where population figure were copied to Wikidata from a more recent government source, while OSM still has data that is about 5 years older. However, on closer inspection it looks like the OSM value is still somewhere around 20000 inhabitants, while Wikidata had only 19. Unlikely that a population sees such a sharp decline in Western Australia in such a short timeframe.

For sure this requires further manual checking, and it’s even possible that the government figures are currently completely off due to some error in their process. Cross checking OSM vs. Wikidata could reveal such very strange discrepancies.

Other issues I noticed were caused by different definitions and interpretations of respective city boundaries (I know this sounds pretty weird). Again, a query to identify such cases adds a lot of value. Fixing issues requires further manual work. After all, both OSM and Wikidata might be wrong, and you cannot tell just by looking at the number itself.

62

@mmd, thanks, could you give me an example of a place with multiple population values that produces strange results? I used wdt:P1082 - the “t” in “wdt” stands for “truthy” - should (in theory) use the latest value, but I need to double check.

Minute data could also be generated with wikidata extra fields.

For augmented data, we could standardize on some magical key value, e.g. *wikidata:population=NNN, to indicate that it came from an external database.

Re Mapbox - I am much more hopeful towards the OpenMapTiles project, and will try to invest some time there :slight_smile:

Re general population - thanks for looking into it, yes, it should be a manual process, luckly we can run some analysis now and try to figure it out. Once we solve many other issues that we found, especially now that I think the OSM+Wikidata service hanging issue has been solved.

Thanks!

63

Hallo,

ich habe die Wikidata-Diskussion bislang eher von außen betrachtet und eher die Verstöße gegen die Richtlinie für mechanische Bearbeitungen bekämpft (kleinere mechanische Edits von nyuriks revertiert).

Das täte mich auch interessieren. Wenn Wikidata eines Tages Verwaltungseinheiten und Siedlungsknoten aufteilt, wird dann die ID gelöscht und zwei neue angelegt? Oder haben wir dann dasselbe Problem, das wir jetzt schon mit wikipedia=*-Tags haben, welche plötzlich auf etwas anderes zeigen können, weil Artikel umbenannt oder umgeschrieben (aufgeteilt) werden?

Das Problem der fehlenden Trennung zwischen zwei Objektklassen, für die bei OSM getrennte Objekte existieren, bei Wikidata aber nicht, gibt es nicht nur bei kreisfreien Städten, sondern auch bei Städten und Gemeinden, die bei Gemeindereformen durch Aufnahme neuer Ortsteile gewachsen sind, aber den Namen des Hauptorts tragen.

Ich denke, dass man das Ergänzen von Wikidata-Tags in OSM kritisch hinterfragen sollte, wenn das zu verlinkende Wikidata-Objekt anders definiert ist als das OSM-Objekt und nicht klar ist, was sich auf was bezieht. Bezieht sich die Einwohnerzahl am Place-Node auf den Hauptort oder die Gesamtgemeinde? Bezieht sich die Einwohnerzahl in Wikidata auf die Gesamtgemeinde oder den Hauptort? Wenn wir Wikidata-Tags ergänzen, laden wir Datennutzer dazu ein, OSM-Informationen durch Wikidata-Informationen in ihrer abgeleiteten Datenbank zu ersetzen, weil sie annehmen, dass beide Projekte dasselbe meinen.

Noch meine persönliche Meinung zum Thema :wikidata= bzw. wikidata:=:

Wenn irgendeine Firma/Organisation herkommt und vorschlägt, eine externe Referenz in OSM zu erfassen, fragen wir auch kritisch nach. Während Haltestellennummern der eindeutigen Identifikation dienen, dienen Wikidata-IDs der Verknüpfung mit externen Datenbanken. Wenn jemand vorschlagen würde, an POIs die Referenznummern einer proprietären Datenbank zu taggen, würde man ihm den Vorschlag um die Ohren schlagen. Diese Reaktion würde erfolgen, weil die Drittdatenbank unfrei ist. Folglicherweise ist die Lizenz der Drittdatenbank für die Entscheidung mit ausschlaggebend.

Die Wikimedia Foundation behauptet, Wikidata sei unter der CC-0, da sie selbst behauptet, dass Fakten frei seien. Das ist leider nicht in der EU hundertprozentig der Fall. Wie schon von anderen Leuten in diversen Wikidata-Diskussionen in den letzten Tagen und Wochen aufgezeigt, wimmelt es in Wikidata an Informationen aus nicht CC-0-Datenbanken. Durch das Ergänzen von Wikidata-Tags laden wir einerseits unsere eigenen Mitwirkenden zur Übernahme von Daten aus einem Projekt ein, das unseren eigenen rechtlichen Ansprüchen nicht genügt. Andererseits geben wir eine rechtlich nicht bedeutsame, aber symbolisch relevante Aussage über die rechtliche Nutzbarkeit der Drittdatenbank ab.

Links zu Wikimedia Commons sind ein Beispiel für Links zu einer freien Sammlung. Und ja, auch Links zu Mapillary sind frei, da die Bilder frei sind. In beiden Fällen garantiert die Freiheit der Werke jedoch nicht den unbegrenzten Zugriff, API-Nutzungsbedingungen limitieren ihn.

Ich war in den letzten drei Jahren ein Befürworter von operator:wikidata=* an allem aus dem Bereich des öffentlichen Verkehrs, weil es eine aufgeheizte Diskussion über die Schreibweise und Abkürzung von Namen in OSM vermeidet, an der ich leidenschaftlich beteiligt war/bin. Mittlerweile bin ich anderer Meinung. Je mehr Fremdschlüssel wir in OSM einführen, desto schwieriger sind unsere Daten für Gelegenheitsmapper zu bearbeiten. Ich würde es daher begrüßen, wenn das Wikidata-Projekt seine eigenen Geodaten pflegen würde und Datennutzer nach eigenen Kriterien [4] OSM-Objekte mit Wikidata-Objekten verknüpfen könnten. Da Wikidata gewisse Relevanzkriterien hat, erwarte ich nicht, dass dort jedes einzelne Gebäude, jeder einzelne Weg und jeder POI erfasst werden wird. Eine parallele Führung zweier Geodatenbanken erwarte ich nicht.

name:etymology:wikidata=* scheint ja ein Anwendungsfeld zu sein, das von einigen Wikidata-Anhängern vorangetrieben wird. Wenn die Namensherkunft jedoch ziemlich eindeutig ist (z.B. Kurt-Georg-Kiesinger-Straße), sollte das Ergänzen in OSM unterbleiben, da die Herleitung dann auch automatisch erfolgen kann. Bei mehrdeutigen Namen [1] kann ich mit der Erfassung der Namensherkunft an den OSM-Objekten leben, wenn die Namensherkunft vor Ort auch so angegeben ist [2]. Wenn der Namen mehrdeutig ist und die Herkunft vor Ort nicht angegeben ist, ist die Herkunft nicht eindeutig belegt [3] und die Voraussetzungen für eine Erfassung in OSM sind nicht gegeben.

Die Frage, ob Architekten/Künstler/Bauherrn als Wikidata-ID erfasst werden sollten, beantworte ich mit Nein. Das Führen mehrere externer Schlüssel ein und derselben Drittdatenbank an einem OSM-Objekt sollte unterbleiben. Stattdessen sollte in der Drittdatenbank für das Objekt ein Objekt angelegt werden und maximal eine externe Referenz in OSM geführt werden.

Viele Grüße

Michael

[1] Der Entwurf dieses Beitrags wollte “Helmut-Kohl-Straße” als Beispiel verwenden, aber für den Namen gibt es zwei Wikipedia-Artikel – einen Bundeskanzler und einen Schiedsrichter.
[2] z.B. als kleines Schildchen unter dem Straßenschild, das Geburts- und Sterbedaten der Person sowie ihre Rolle in der Gesellschaft nennt (“1930–2017, Ministerpräsident von Rheinland-Pfalz und Bundeskanzler”)
[3] Belege sind bei OSM ortsfest und vor Ort überprüfbar.
[4] oder sie kaufen den gematchten Datensatz einfach bei einem Dienstleister, der für sie denkt und entscheidet

64

Sure: http://tinyurl.com/y92mvstm

https://www.wikidata.org/wiki/Q223177 → Population “40” refers to the value which was valid in 1880. OSM has 52089, which is quite close to 55316 (of 2010) in Wikidata.

osmnode:151700975 edit wd:Q223177 52089 40

Edit: in fact we get all the values for each valid from date (see http://tinyurl.com/y8wngrod)), but we don’t know which one is which.

65
  • Q2843 will never be deleted - that’s against the whole idea of Wikidata. It could be converted into a redirect to another ID.
  • Q2843 represents all of the Wikipedia, Wikivoyage, and Wikisource pages about the city, not a more specific city or admin, so as long as we want to link to the Wikipedia pages, we should use it for wikidata. Or we can set wikipedia=Q2843 and set wikidata=Qxxx to the more specific value? Changing the meaning of the wikipedia tag is kinda bad, but at least we will be explicit that its a link to Wikipedia, not Wikidata. Just an idea.
  • Q2843 could have multiple P31 (instance of) values. So this object could be both a city AND an administrative boundary.
  • In theory, we could create two more specific Wikidata values, one for each sub-concept, and have some links from Q2843 to them. I’m sure the Wikidata community has been actively discussing such issues. Organizing and classifying information is always a process, so these corner cases will keep changing how Wikidata represents the data about the world. We should help with our local knowledge.
66

Hallo,

In einer anderen Diskussion hast du als Argument für die Ergänzung von wikipedia=-Tags um ihr “äquivalentes” wikidata=-Tags, dass damit das Problem der Weiterleitungen behoben sei. Damit holen wir uns doch bloß neue Probleme in’s Haus?

Der Verweis von OSM zur Wikipedia hat nicht das Ziel, weitere maschinenlesbare Datenquellen zu erschließen. Die Wikipedia-Autoren sind sicherlich im Stande, in ihren Werken den Leser erkennen zu lassen, was sich worauf bezieht, wenn ein W*-Objekt mehreren OSM-Objekten entspricht.

Wenn Wikidata noch so jung und dynamisch ist, wäre es IMHO eine gute Idee, noch ein bis zwei Jahre zu warten und währenddessen nicht automatisiert, halbautomatisch oder organisiert Wikidata-Verweise in OSM zu erfassen, oder?

Viele Grüße

Michael

67

@mmd, apparently this was a problem with Q223177 – one value should have been set to “prefered” rank. See this diff.

update: I filed a bot task at Wikidata to fix the “preferred” status. Apparently there are over 10,000 items that haven’t been set.

68

Prinzipiell kann jeder angemeldete Benutzer bei Wikidata mit einem klick ein neues Item erstellen, dem er in diesem Fall den deutschsprachigen Namen “Chez Elisabeth” und die deutsche Beschreibung “lokale Kneipen-Kette” hinzufügen kann. Damit wäre nur erst mal wenig gewonnen. Ohne entsprechende Statements ist das Item wenig wert und ob es so bestehen bleiben wird, wag ich zu bezweifeln.

Was die Kriterien für ein Item angeht, so gibt es auf Wikidata verschiedene Projekte zu einzelnen Themengebieten, die jeweils Regeln ausarbeiten was ein Item aus dem Bereich (hier wohl Organisation) für Statements haben kann und sollte. In dem fall z.B. “ist eine Gemeinschaft mit beschränkter Haftung” siehe auch https://www.wikidata.org/wiki/Wikidata:WikiProject_Companies/de. Letztendlich sollte Statements aber auch belegt werden können, was in diesem Fall wohl schwierig würde womit wir zum dritten Aspekt der Relevanz kommen.

Relevanz wird in Wikidata nicht so streng wie in der Wikipedia aber es gibt auch Kriterien. In diesem Fall https://www.wikidata.org/wiki/Wikidata:Notability/de
Spätestens hier würde es mit “Chez Elisabeth” wohl scheitern, da die “Minikette” weder für sich genommen relevant ist, noch einen Eintrag in einem Wikimedia-Projekt hat noch für eine geschlossene Systematik benötig wind.

Meines Erachtens kann es nicht Sinn der Sache sein, nur für einen OSM-Verweis ein neues Wikidata Item anzulegen wenn der gegenstand selber keine Relevanz besitzt. Ich glaube aber auch nicht dass das jemand momentan so handhaben möchte.

Vermutlich nicht. Das Beispiel war in 5 Sekunden selber zusammengesucht und offenbar schlecht gewählt.

Ich denke es würde dann ein neues Item geben. Was aber “brand” oder “operator” konzeptionell ist, ist erst mal Sache von OSM. Wikidata kennt diese Tags nicht.Hier könnte man höchstens ein Mapping definieren, aber wozu ist das nötig?

Das stimmt nicht. Gerade diese Diskussionen gibt es auch in der deutschsprachigen Wikipedia und sogar zum teil deutlich heftiger als hier. Gerade so Fragen wie “Ist es ok, Daten automatisch aus Wikidata zu übernehmen”, “Sollen dafür lokale Daten entfernt werden” beschäftigen die Leute da auch sehr. Gerade für Alt-Wikipedianer ist Wikidata neu und fremd. Da gibt es auch einen große Gruppe von Leuten die dem sehr skeptisch bis ablehnend gegenüber stehen, wobei gerade die deutschsprachige Wikipedia da sehr konservativ ist im Gegensatz z.B. zu der englischsprachigen.

Ich glaube da hatte nyuriks schon einiges gesagt hier nur noch das: Was ein Item bekommt und wo diese aufgespaltet werden müssen, entscheiden wohl Prinzipiell die zuständigen Projekte anhand der erarbeiteten Regeln. Im Komkreten Fall macht dann jemand dass, was er für richtig hält und jemand andere sagt dann vieleicht “Ist so nicht ok ich mache das rückgängig” oder auch nicht. Ähnlich wie in OSM oder der Wikipedia

Ich plädiere dafür, da Wikidata so etwas wie eine Meta-Datenbank ist die andere Datenbanken verknüpft und zu anderen universell ist und natürlich frei. Was gibt es vergleichbares. Wit dem Wikidata-Item hat man direkt auch alle anderen Datenbank IDs wie z.B. "Gemeinsame Normdatei, “Welterbe-Referenznummer” usw. die Wikidata-ID ist damit der minimale “Einsprungpunkt” in die Welt der verknüpften, strukturierten Daten. Das leistet keine andere Datenbank und es gibt auch keine, die dieses Ziel verfolgen würde.

Zweites Argument ist, das wir mit der Wikipedia-Tag schon einen Funktionierende Verknüpfung zur Wikipedia haben die vielfach und mit großem Nutzen verwendet wird (zumindest von Seiten der Wikipedia). Die Wikidata-Links könnte man also als verbesserte Wikipedia-Links sehen, die sprachunabhängig und stabiler sind.

69

Damit ist denke ich klar bewiesen, dass brand=* nicht funktional gleichwertig ist mit brand:wikidata=. Allein die Tatsache, dass zur Verwendung von brand:wikidata= für etwas, wo es keinen Eintrag in Wikidata für gibt, eine Anmeldung und Vertrautheit mit Wikidata notwendig ist, ganz zu schweigen von einer vermutlichen Zustimmung zu Contributor terms, ist meiner Meinung nach eine inakzeptable Hürde. Aber selbst wenn man das nicht so sieht, bricht die Notability der Sache ganz eindeutig das Genick.

Und wie soll ein Mapper jetzt überprüfen, ob ein bestimmter Wert von brand:wikidata=* oder operator:wikidata=* richtig oder falsch ist? Q154950 scheint ja jetzt definitiv kein zulässiger Wert für brand:wikidata zu sein, aber was macht eine Wikidata-ID zu einem richtigen Wert dafür?

Tut mir leid falls das für Wikipedianer offensichtlich ist, aber was sind “die zuständigen Projekte” und “[die] erarbeiteten Regeln”? Aber grundsätzlich geht es mir hier mehr um die formelle Verfahrensweise mit den IDs - also nochmal meine (bis jetzt noch nicht wirklich beantwortete) Frage:

Das mit der Umleitung hab ich verstanden (ist aber zum ersten Mal, dass ich höre, dass es in Wikidata für die IDs Umleitungen gibt und damit die IDs nicht mehr unbedingt eindeutig sind - es also ggf. mehrere gültige IDs für das selbe Objekt gibt). Aber Wie wird entschieden, ob Q2843 dann auf die administrative Einheit oder die Siedlung umleitet? Ist das dann die freie Entscheidung von demjenigen, der die Änderung vornimmt oder gibt es da Regeln?

Aber ich habe doch gerade oben demonstriert, dass genau dies im Moment nicht der Fall ist, denn das Notability-Prinzip definiert, was enthalten sein kann und was nicht. Und es schließt einen Großteil der in OSM gemappten Dinge damit eindeutig aus. Wikidata ist also nicht als Meta-Datenbank geeignet, um OSM und alle darin enthaltenen Daten mit anderen Datenbanken zu verknüpfen. Schlimmer sogar: Die Auswahl, was in Wikidata eine ID bekommen kann und was nicht basiert primär auf der Existenz von Sekundärquellen und widerspricht damit dem Kernprinzip von OSM, der Überprüfbarkeit vor Ort.

Offene Geo-Datenbanken, die einen Teil der Objekte in OSM auch in irgendeiner Form repräsentieren und somit mit OSM verknüpft werden könnten, gibt es in großer Zahl. Und bei vielen von diesen erfolgt die Auswahl der Objekte, die enthalten sind, nach deutlich klareren und besser nachvollziehbaren Kriterien als bei Wikidata. Die Frage, was Wikidata besonders qualifiziert, dass seine IDs in OSM gespeichert werden sollen, ist also denke ich nach wie vor nicht zufriedenstellend beantwortet.

70

@Trockennasenaffe
“Die Wikidata-Links könnte man also als verbesserte Wikipedia-Links sehen, die sprachunabhängig und stabiler sind.”

Naja, aus meinem aktuellen Projekt:
wikipedia: https://de.wikipedia.org/wiki/Fuldaaue_(Kassel)
wikidata: https://www.wikidata.org/wiki/Q1473482
Das wikidata-Item behauptet, die Fuldaaue sei ein Naturschutzgebiet,
tatsächlich ist nur ein kleiner Teilbereich NSG - steht alles so auch korrekt im Wikipedia-Artikel.
Derartiges dürfte kein Einzelfall sein, wenn versucht wird Fließtext und komplexe Zusammenhänge auf Datenbank-Stichworte einzudampfen.

Der Vorteil eines Wikipedia-Links - aus OSM heraus - liegt für mich gerade darin,
dieses Datenbank-Stichwort-Korsett zu verlassen,
und komplexe Zusammenhänge auch adäquat darstellen bzw. dem Interessierten anbieten zu können.
Was wikidata da leisten soll kann sich mir bisher nicht wirklich erschließen,
und das sage ich als jemand der viel von OSM aus in Wikimedia-Projekte (Wikipedia + Commons) verlinkt.

71

Ja, zu glauben man könnte alle existierenden brand-Tags damit ersetzen ist klar falsch, aber wer tut den das? Es geht doch wenn überhaupt nur um die redundante Doppelauszeichnung, aber selbst da wäre ich nicht dafür, bestehende brand-tags zu löschen.

Ich verstehe das Problem nicht. Zulässig ist was richtig ist, wie jetzt auch. Als Mapper, der den Wert hinzufügt, weiß ich doch was ich damit ausdrücken möchte. Nehmen wir mal an es geht um eine Bushaltestelle in Aachen, weil das ein Thema ist mit dem ich mich besser auskenne. Im OSM Wiki lese ich dann, das hier der als Operator das Verkehrsunternehmen, das die Haltestelle betreibt. In dem Fall sehe oder Weiß ich, das es die ASEAG ist. In OSM wird es jetzt schwierig. Schreibe ich operator=ASEAG oder operator=Aachener Straßenbahn und Energieversorgungs-AG oder was auch immer? In der Praxis gibt es alle Varianten, was die Daten wenig brauchbar macht. Will ich jetzt wikidata:operator befüllen suche ich in Wikidata nach ASEAG. Hier kommen mehrere Treffer, aber man sieht schnell an hand des Beschreibungstextes und der Aussagen, dass Q300755 die gemeinte Aachener Straßenbahn und Energieversorgungs-AG ist und fertig. Daran wird sich mit hoher Wahrscheinlichkeit auch nichts ändern.

Hast du dir den Link angesehen den ich dir dazu geschickt habe? Letztendlich ist es wie bei OSM. Leute die sich für ein Thema interessieren und befähigt fühlen diskutieren miteinander und schreiben Wikiseiten mit Regeln, Empfehlungen und “Best-Praktice”-Sammlungen. Ich denke du stellst dir das viel formalisierter vor als es ist. Was ist denn bei OSM die formelle Verfahrensweise, wenn jemand einen POI-Doppelt angelegt hat, wäre eine ähnlich wenig zielführende Frage. Ich kann aber deine konkrete Frage gerne mal dort im Forum stellen und schauen ob da eine Antwort kommt.

Dazu erst mal: Nein, eine Umleitungen gerade keine gültige ID, sondern ungültig und verweist nur auf die gültige ID. Natürlich kann apriori nicht verhindert werden, das zwei IDs angelegt werden von denen sich eine als redundant heraus stellt. Dann wird eben eine gelöscht. Dazu habe ich diese Seite gefunden: https://www.wikidata.org/wiki/Help:Merge/de. Zum Aufteilen habe ich auf die schnelle nichts gefunden, aber bezweifle, dass es da allgemein gültige Regeln gibt.

72

Was du du beschreibst ist ein völlig anderes Problem. Bei diesem Argument für die Verklinkung geht es ja nicht um die Daten die mit dem Wikidata-Objekt verknüpft sind, sondern den Link zur Wikipedia. Letztendlich will ja jeder die Wikipediaseite in seiner Sprache lesen und die beinhaltet der Wikidata-Eintrag ja. Man kommt zwar über den deutschen Wikipedia-Artikel auch auf die anderssprachigen, aber das geht dann auch indirekt über Wikdata, da kann man meineserachtens besser gleich das Wikidata-Item verkinken und sich davon die gewünschte Wikipedia-Sprachversion holen.

73

Das reicht aber in OSM nicht aus, die Daten müssen überprüfbar sein - siehe https://wiki.openstreetmap.org/wiki/DE:%C3%9Cberpr%C3%BCfbarkeit. Deswegen meine Frage wie der Mapper erkennen kann, ob ein bestimmter Wert richtig oder falsch ist.

Ich habe keinen Link dazu gesehen.

Und ich versuche gerade, nicht mit vorgefassten Meinungen an die Sache heranzugehen, sondern unvoreingenommen herauszufinden, wie Wikidata funktioniert. Es ist völlig in Ordnung, wenn irgendwas nicht klar geregelt ist und sich jederzeit ändern kann. Aber man sollte sich dessen natürlich bewusst sein.

Ganz einfach, der Node mit den präziseren Koordinaten wird behalten, das andere gelöscht, nachdem man ggf. die dort fehlenden Tags auf das andere übertragen hat. Das ist vermutlich nirgendwo dokumentiert, aber es gibt in JOSM eine Funktion, die genau das tut.

Die Begriffe verwirren mich hier ein wenig, auf der einen Seite “Dann wird eben eine gelöscht”, auf der anderen Seite “Q2843 will never be deleted”. Wie auch immer - das bedeutet am Ende, dass eine Wikidata-ID nicht unbedingt stabil ist und ein ehemals korrektes wikidata-Tag auf diesem Wege ohne dass sich in OSM was ändert fehlerhaft werden kann - entweder dadurch, dass die Verwendung einer solchen ungültigen ID in einem wikidata=*-Tag als Fehler angesehen wird oder dadurch, dass bei der Aufteilung die Umleitung dann auf das falsche Wikidata-Objekt zeigt.

74

For minutely diffs, you need to keep in mind, that there’s not only an OSM object lifecycle, but obviously a Wikidata object lifecycle as well. Every time, one of the two sources changes, you need to create a new object “version” and distribute that via minutely diffs. Just sticking to OSM diffs and enriching them will miss all those Wikidata changes that happen in the meantime.

Now, once you start creating artificial object versions as a superset of OSM + Wikidata changes, there’s absolutely no sane way to ever feed this information back into OSM (like in the mirror db scenario I mentioned). Version checks are strict, and skipping versions is not an option.

Also, by having separate tags (one for the OSM data, and for the Wiki data), you could of course make the origin clear. However, data consumers need to be adapted to do something meaningful with those two tags, choose one of them based on some clever criteria.

This is all very tricky and really only meaningful if you want to provide something to pure end consumers who will never contribute anything back to OSM based on that augmented/enriched data.

75

Diese beiden Beobachtungen stehen für mich etwas im Widerspruch. Es wird öfters Fälle geben, wo ein Architekt oder Namensgeber für Wikidata relevant ist, das Gebäude oder die Straße jedoch nicht. Schlüssel wie architect:wikidata sind dann eine Lösung.

Technisch möglich, klar, aber deswegen nicht unbedingt auch sinnvoll. Über Sprachgrenzen hinweg ist es ein sehr schwieriges Unterfangen, solche Ableitungen zuverlässig automatisch zu treffen. Und du gibst ja selbst in deiner Fußnote zu, dass viele Namen nicht so unverwechselbar sind, wie man meinen möchte.

Aber wo wir gerade dabei sind: Wir könnten doch eigentlich auch amenity=cafe weglassen, wenn sich aus dem Namen schon ergibt, dass es sich um ein Café handelt (“name=Café del Mar” oder so). :wink:

76

mmd, I don’t think we need to add versions for additional tags. They will simply be “whatever the value at that time”. It is not as clean as with versions for everything, but it solves the problem when users do not want to merge data themselves. If they need versions, they could merge it themselves.

77

Yes, right. As an example, place nodes don’t get changed very frequently. In some cases that might be even as much as 5 years. During that time, no updates from Wikidata will be picked up, and data might become stale. So, the update frequency in OSM would then be the only trigger to have updated data from Wikidata merged into the augmented data. Technically this would work, at the odds of having potentially outdated information around - and people wondering, why more recent data in Wikidata won’t show up in the augmented database. :slight_smile:

78

Ah, yes, that’s true. We could track Wikidata items, and re-publish OSM objects with unchanged version - I wonder if that would break anything…