Wikidata-Links

Hallo,

eben hab ich mich über dieses Wikidata-Wunderland hier aufgeregt:

https://www.openstreetmap.org/changeset/52424928

Die normalen “wikidata”-Links für Städte oder so sind ja ok, aber “brand:wikidata”, “operator:wikidata” und was noch alles find ich jetzt übertrieben - besonders dann, wenn man sich nicht mal mehr die Mühe macht, einen menschenlesbaren Wert in “brand” bzw. “operator” zu schreiben, nach dem Motto, ist ja eh alles nur für die Query-Engine und nicht für Menschen gedacht.

(Hinzu kommt, dass Wikidata hier einen Ortsfremden beflügelt, irgendwelche Annahmen über Aldi-Supermärkte zu treffen, die m.E. so gar nicht stimmen.)

Wenn’s nach mir geht, fliegt der Mist raus - normale Wikidata-Links meinetwegen, aber *:wikidata (am Ende haben wir dann gar kein shop=supermarket mehr, weil es reicht ja shop:wikidata=Q1234545) empfinde ich als übertrieben, und ich sehe hier sogar eine gewisse Besitzergreifung durch Wikidata, als ob wir nur noch die GIS-Extension sind zu dem, was Wikidata hat. Wenn wir am Ende an einem Artikel 5 Wikidata-IDs dran haben, wer von uns soll das denn noch warten.

Bye
Frederik

Bitte ganz schnell raus damit, das ist ja grausig.

Ich verstehe ehrlich gesagt das Problem nicht.

Hier wurden und werden bei der Umsetzung Fehler gemacht, aber den Ansatz finde ich zukunftsweisend.

Nebenbei: Fahrlässig finde ich, wenn der ID Editor beim setzen von Wikipedia-Links automatisch Wikidata-Links setzt. Für die entstehenden Fehler werden dann die Mapper verantwortlich gemacht, die sich mit Wikidata nicht auskennen und den Link so nicht gesetzt hätten.

Wikidata löst auch Probleme: Wenn der Name eines Architekten variiert, lässt er sich über wikidata:architect=* eindeutig adressieren und über das Tag auch in OSM ermitteln. Nun werden auch neue Anwendungen möglich, weil sich aus Wikidata weitere Daten abfragen lassen.

In Archivalia habe ich dazu etwas geschrieben:

http://archivalia.hypotheses.org/67371

Also ich begrüße die wikidata Initiative, da so vieles an Informationen in OSM gelangt, die sonst direkt in der Datenbank gespeichert werden müsste. Aber das wir jetzt für jedes Tag ein :wikidata brauchen glaube ich genauso wenig wie Frederik, den damit wird der Informationsgehalt nicht größer, der ganze Inhalt steht nämlich schon auf https://www.wikidata.org/wiki/Q125054. Hätte der Mapper mitgedacht, hätte er also das wikidata Tag direkt auf Aldi verlinkt und nicht jeden Mist extra.

Wenn ich wissen will, was Aldi ist, dann verwend ich die Suchmaschine meiner Wahl, da brauch ich keine für Menschen schwer lesbare wikidata-Abfrage.

Ich sehe durchaus einen Nutzen in Tags wie operator:wikidata=*, wenn man Objekte bestimmter Betreiber abfragen will, was gerade im ÖPNV- und Bahnbereich häufiger vorkommt, z.B. “Streckennetz der Privatbahn XY” oder “alle Routenrelationen der Stadtbus XY GmbH”. Bei solchen Abfragen steht man vor dem Problem, dass es keine einheitlichen Schreibweisen im operator-Tag gibt, hauptsächlich dadurch begründet, dass es in der Community keine Einigkeit darüber gibt, ob 1. Unternehmensformen angegeben werden sollen und 2. Abkürzungen ausgeschrieben werden sollen. Daraus resultieren viele verschiedene Schreibweisen des gleichen Betreibers, z.B. “DB”, “Deutsche Bahn”, “Deutsche Bahn AG”, “DB Netz”, “DB Netz AG”, “Deutsche Bahn Netz AG”. Und selbst wenn man sich die Mühe machen sollte, die Werte auf ein in der Community vereinbartes Schema zu bringen, kommt dann wieder ein Newbie und taggt es wieder um (selbst schon öfters erlebt).

Für die Auswertung ist es einfach extrem unpraktisch, wenn man für jeden Betreiber erst überlegen muss, in welchen Schreibweisen er in den Daten auftreten könnte. Das ist einfach ein grundsätzliches Problem des Datenmodells von OSM, weil man dem User ein Freitextfeld anbietet, obwohl man eigentlich nur bestimmte Werte zulassen will. Daher sehe ich die Wikidata-IDs als gute Lösung an, um diese Problematik zu umgehen. Wobei es mir bei den Wikidata-IDs gar nicht um die Verknüpfung mit Wikidata geht. Ich sehe den Nutzen vor allem darin, dass es sozusagen eine zentrale Instanz gibt, die eine eindeutige ID für jeden Betreiber definiert. Wenn man sowas in irgendeiner Form auch in OSM umsetzen könnte, könnte ich damit auch gut leben. Denkbar wäre irgendeine Datensammlung in einem maschinenlesbaren Format, wo man einen Value für operator=* definiert und eine Reihe von Aliasen angibt. Die Editoren würden dann nur die dort definierten Values in der GUI anbieten und dem User bei Eingabe eines Aliases vorschlagen.

Da stellt sich wieder so eine grundsätzliche Frage bei OSM: Wer entscheidet sowas? Welche Instanz darf sagen, welches Tag in die Daten darf und welches nicht? Gibt es dann eine Abstimmung und die Mehrheitsmeinung entscheidet? Wer setzt die Entscheidung dann um und wie stellt man sicher, dass das Tag nicht erneut ergänzt wird und daraus eventuell ein Editwar entsteht?

Daher sehe ich solche Tag-Aufräumaktionen kritisch, auch wenn mir selbst auch spontan eine ganze Reihe von Sachen einfallen würde, die ich als unnötig oder kontraproduktiv ansehe. Aber weil wir eben keine Instanz haben, die Relevanzkriterien aufstellt und bindende Entscheidungen trifft, sehe ich die Gefahr, dass dann einzelne Mapper oder Interessensgruppen sich dazu berufen fühlen, die Datenbank mal nach ihrer Auffassung aufzuräumen.

Gruß
Alex

Solange die OSM-DB nicht wegen Überfüllung unbenutzbar zu werden droht, wäre ich auch sehr zurückhaltend beim Löschen von Informationen. Es kostet viel weniger Aufwand, eine Information zu löschen als sie wieder herzustellen.

Ich hatte den Beitrag eigentlich so aufgefasst, dass ein Tag ersatzlos durch einen Wikidata-Tag ersetzt wird. Da sollte wegen der Lesbarkeit der Originaltag (z.B. operator) samt value erhalten bleiben. Das ist zwar ein gewisse Redundanz, aber ich wollte mich ungern von einer anderen Datenbank abhängig machen. Wenn Wikidata (hypothetisch) für alle Einträge ein anderes Nummerierungs-Schema einführen würde, liefen alle wikidata:xxx-Links ins Leere.

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.

Bye
Frederik

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.

Bye
Frederik

Dem kann ich nur zustimmen.

Gruiss
walter

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…

+1 (Wikidata ID & wikipedia) darf meinetwegen raus

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.

Hi everyone, I would like to clarify:

  • 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)

Thanks!

Einfach nur ein weiterer Grund die “vor Ort Überprüfbarkeit” in Frage zu stellen…

Grüße von Lutz

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.

Weil das relativ abstrakt klingt, hier mal ein Beispiel.

Mapbox erzeugt damit z.B. Vektor-Kacheln in Arabisch: https://www.mapbox.com/bites/00345/ar.html#6/50.586/8.857 (Artikel dazu).

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.