Jemand muss das halt warten. Ein normaler Bahnmapper wird vielleicht noch einen operator eintragen mit oder ohne GmbH dahinter, aber dann muss eben doch wieder jemand hinterher räumen und einen operator:wikidata eintragen, der auf das richtige zeigt. Das passiert ja nicht automatisch.
Leider sehen das andere aber anders, und so wird in Wikidata eine Logik aufgebaut (im konkreten Fall, dass es genau eine “Marke” namens Aldi gebe, deren Märkte aber von verschiedenen Betreibern, “Aldi Nord” und “Aldi Süd”, unterhalten werden), die dann wieder auf unsere Tags zurückfärbt.
Ich würd sagen, wir handhaben das wie immer. Wenn man zu dem Aldi-Markt hingeht und da steht dran “dieser Markt wird betrieben von Wikidata:Q12345”, dann taggen wir das auch so. Wenn nicht, dann sehe ich nicht ein, wieso wir fremde IDs in unserer Datenbank haben sollen.
m.E. ist Überfüllung nicht das einzige, was unsere Datenbank unbenutzbar machen kann. Eine zu enge Verzahnung mit Wikidata und damit einhergehend (1) die zunehmende Unselbständigkeit unserer Daten und (2) die zunehmende automatische Veränderei jedesmal, wenn jemand in Wikidata was umdreht, können auch Probleme machen. Plus (3) der Abschreckungsfaktor, wenn der Newbie den operator an einem Gleis ändern will und nicht weiss, was er denn jetzt mit operator:wikidata machen soll (“das geht doch dann kaputt, hm vielleicht lass ich es lieber”). Dass unsere Tags menschenles-, -versteh-, und -änderbar sind, hat m.E. viel zu unserem Erfolg beigetragen.
Das war ein Punkt, der mich störte, aber nicht der einzige.
Dem stimme ich zu - mein Beispiel war in diesem Sinne ein übertriebener Grenzfall.
Mit Überfüllung meine ich übrigens nicht nur die schiere Größe der DB, sondern auch die Anzahl der Tags pro Objekt oder die Zugehörigkeit zu Relationen, die dann seitenlanges Scrollen erfordern. Das ist natürlich ein schleichender Prozess.
Somit ist wikidata per se nicht erfassbar, zumindest ist mir noch kein Reales Objekt unterkommen, an dem die Wikidata ID angebracht war?! Analog natürlich dann in Konsequenz auch wikipedia…
Bei aller berechtigter Kritik an den Wikidata-Importen in letzter Zeit finde ich ein generelles Infragestellen von *:wikidata-Tags eine Überreaktion. Diese sind immer dort hilfreich, wo das Objekt selbst nicht für Links zu Wikidata/Wikipedia in Frage kommt, aber ein übergeordneter Begriff schon (wie z.B. der Betreiber einer Supermarktkette, die Person der eine Statue gewidmet ist …).
Es gäbe sicherlich Lösungen, Wikidata-Links mappingfreundlicher zu machen. Beispielsweise könnte man überlegen, auf den Wikidata-Link dort zu verzichten, wo es ohnehin einen Wikipedia-Artikel gibt, der mit Wikidata verknüpft ist. Genauso kann ich nachvollziehen, dass die nicht menschenlesbaren IDs unschön sind, auch wenn das durch die bereits vorhandene Editorunterstützung bereits zu großen Teilen gelöst sein dürfte.
Ein Komplettverzicht auf Links zu anderen Datenbanken wie Wikidata ist aber nicht hilfreich, und unter dem Gesichtspunkt der “zu vollen Datenbank” sogar kontraproduktiv: Entweder tragen wir immer mehr Details in OSM selbst ein (was zu Recht zu Kritik führt, dass OSM immer schwerer zu warten wird) oder wir überlassen das Sammeln dieser Informationen ohne direkten Geo-Bezug anderen, auf die wir dann eben nur verlinken. Ich finde letzteres die deutlich bessere Lösung: Statt dutzenden Informationen wie Supermarktlogo oder Werbeslogans (dazu gab es kürzlich eine Mailinglistendiskussion, in der dank Wikidata darauf verzichtet wurde, diese Informationen in OSM einzutragen) braucht es dann nur einen Link auf Wikidata.
Und noch konkret zum Beispiel: Ein Link sollte dort eigentlich reichen. Dass mehrere Links (brand vs. operator) eingetragen wurden, liegt letztlich daran, dass wir diese subtile Unterscheidung überhaupt treffen – was ich auch ganz unabhängig von Wikidata schon länger etwas übertrieben finde.
Please think of Wikidata as a permanent link to a Wikipedia article. Wikipedia titles are often renamed. Wikidata ID is designed to stay the same forever. So when there is a Wikidata ID, it is simply a more permanent form of a Wikipedia title. Volunteers have spent months of their time cleaning up the mess that Wikipedia tiles create when they get renamed. Many thousands have already been fixed. Many more are still there. Wikidata IDs help to clean it up, and to not have this problem again.
Wikidata has some extra data statements. They are helpful with data processing, and data consumers love it.
Neither wikipedia tag, nor wikidata tag are readable by a human. While wikipedia tag may look like it is readable, you do not know what that page is about until you go to that site. So both are external references. (Update: just like website, url, ref:bag, osak, and many other tags, which are also references, and are usually received from internet, not in person on the ground)
Genau. Da kann man gleich noch Dutzende andere Tags zur Diskussion stellen. Das Wikipedia-Relevanz-Kasperle-Theater können wir sicher um mehrere Ebenen toppen, ich spar mir mal die Beispiele.
Natürlich haben die meisten Orte kein name:ar -Tag, aber über den Weg wikidata-id werden dann die entsprechenden Übersetzungen aus Wikipedia gezogen. Woher die Beschriftung letztlich auf der Karte herkommt, sieht man natürlich nicht mehr, ohne jetzt sowohl die OSM-Tags als auch den Wikidata/Wikipedia Eintrag zu prüfen.
So und jetzt dreht sich die Diskussion dank eines weiteren “prominenten” OSM Aktiven eher darum, warum es nicht wikidata:brand heißt … es bleibt also spannend, aber ich würde mal sagen die brand-wikidata-brand-Daten bleiben wohl erstmal in der Datenbank…
Also wenn ich z.b. im Ausland einen Supermarkt einer mir unbekannten Kette sehe, und mir die Karte direkt einen Link zu dieser Kette auf Wikidata zeigt, finde ich das nicht verkehrt. Oder ich den Wikidata-Link zum Architekten eines Baudenkmals bekomme. Finde ich allemal nützlicher als das meiner Meinung nach auch bzgl. Privatsphäre bedenkliche Mappen von Schwimmbädern oder Bäumen in Privatgärten.
Weiß ich nicht. Für Big-Data-Auswertungen könnte das ganz interessant sein. Die Frage ist doch viel mehr, hat sowas Chancen sich global in OSM durchzusetzen, oder ist das ein Privatprojekt eines Mappers und wird nichtmal im nächsten Landkreis genutzt.
Ich befürchte halt, dass uns der Spaß irgendwann auffrisst.
Schritt 1: Wir tun Wikipedia-Verweise an einige große Orte und Touristenattraktionen.
Schritt 2: Wir ergänzen das mit Wikidata-Links
Schritt 3: Ach, super, Wikidata-Links gibt es ja für alles, also können wir an die katholische St.Thomas-Kirche, die vom Architekten X im Jahre Y erbaut wurde, auch noch die Wikidata-Links für katholisch, St. Thomas, X und Y dranpappen… schadet ja nichts!
Schritt 4: Ach super, die Editoren und die Webseite zeigen mir ja dank Wikidata-API-Request jetzt ein “patron_saint:wikidata=Q12345” direkt als “St. Thomas” an, da brauche ich “patron_saint” ja gar nicht mehr getrennt zu erfassen
Schritt 5: Wieso tagge ich eigentlich noch amenity=place_of_worship, wenn es doch dafür eine Wikidata-Klasse gibt, besser mach ich gleich amenity:wikidata=Q9876…
In dieser Reihenfolge entwickelt sich OSM langsam weg vom eigenständigen Projekt, hin zu etwas, was ich “die PostGIS-Extension zu Wikidata” nennen würde - nicht mehr allein lebensfähig…
Und hier wird es ab 4 kritisch, meinetwegen schon ab Schritt 3 unübersichtlich, wenn exzessiv ausgeübt, aber an der Sinnhaltigkeit von Schritt 1 und 2 ändert das nichts, abgesehen davon, dass es ein Wegbereiter dafür sein kann.