wikipedia- (und wikidata)-Verweise in OSM-Datenbank behalten?

  • 1.000.000 (in Worten: 1 Million).

Muss man jetzt wirklich daran erinnern, dass sehr viele Dinge „vor Ort nicht auffindbar/nachprüfbar“ werden, wenn wir den Begriff so eng auslegen? :roll_eyes: Grenzen etc. dürften wir dann sowieso nicht in der Datenbank haben, das ist klar. Aber wenn ich mich derart unflexibel anstelle, dann frage ich mich auch, ob ich dann einen Bäcker noch mit shop=bakery taggen darf; es steht ja nicht „shop=bakery“ dran … ja, oft nicht mal „Bäcker“, sondern (hier vor Ort z.B.) einfach nur „Kern“ oder „Betz“. Damit wäre das *name=-Tag zwar gegeben. Festzustellen, dass es sich um einen Bäcker handelt, erfordert dagegen größere geistige Anstrengungen, die mMn noch deutlich über das Verifizieren von *wikipedia=-Tags hinausgehen. Also werde ich, wenn wir „vor Ort nicht auffindbar/nachprüfbar“ so streng auslegen wollen, in Zukunft einen Bäcker nur noch dann als Bäcker taggen, wenn „shop=bakery“ oder wenigstens „Bäckerei“ dransteht. Und das gilt dann natürlich auch für alle anderen POIs. Da gibt es doch diese Dinger, wo „Shell“ oder „Aral“ dransteht. Irgendjemand taggt die immer als amenity=fuel, aber das ist zweifellos reine Spekulation und „vor Ort nicht auffindbar/nachprüfbar“. Alles, was nicht dransteht, muss raus aus der Datenbank. Supi!!! Ich sehe güldene Zeiten auf OSM zukommen … :stuck_out_tongue:

Ja, bei allen Dingen, die nicht vor Ort überprüfbar sind, sollten wir uns ganz kritisch fragen, ob deren Wichtigkeit die potentiell aus fehlender Nachprüfbarkeit resultierende Streiterei aufwiegt. Für aktuelle Verwaltungsgrenzen dürften wir uns da weitgehend einig sein. Bei historischen Verwaltungsgrenzen der jüngeren Geschichte vielleicht schon nicht mehr so… das ganze ist keine binäre Sache, wo man sagen kann “einmal irgendwo was nicht nachprüfbares gemappt, also geht alles”.

Entschuldige, aber das ist ein Scheinargument, das der Sache nicht dienlich ist. Frage eine zufällig vorbeikommende Person “ist dies ein Bäcker”, und die Person wird entweder “ja” sagen oder Dich besorgt anschauen und davonrennen. Frage eine zufällig vorbeikommende Person “hat dieses Geschäft bei Wikidata die ID Q1234”…

Der Wikidata-Link benötigt zur Überprüfung (1) technisches Gerät und Wissen auf Deiner Seite, (2) eine funktionierende Internet-Verbindung, (3) einen funktionierenden Wikidata-Server. Du magst Dich gern auf den Standpunkt stellen, dass das für Dich kein Problem sei, aber einfacher, als einen Laden als Bäckerei zu identifizieren, ist es gewiss nicht.

Dadurch, dass Du ein völlig vernünftiges Argument - nämlich dass unsere Informationen vor Ort überprüfbar sein sollen - zu “alles muss vor Ort angeschrieben sein” verdrehst und das dann ins Lächerliche ziehst, wird das ursprüngliche Argument nicht widerlegt.

Natürlich steht an einem Baum auch nicht “Baum” dran und wir mappen das trotzdem. Du wirst Philosophen finden, mit denen Du ausgezeichnet darüber diskutieren kannst, ob das ein Baum ist oder ob der Baum nur in Deinem Kopf existiert, aber so genau nehmen wir das bei OSM nicht, uns reicht das, wenn es ungefähr aussieht wie ein Baum und man sich den Kopf dran anhauen kann.

Die vor-Ort-Überprüfbarkeit ist für OSM von zentraler Wichtigkeit und das einzige, was uns vor Edit-Wars um Nuancen und Auslegungen schützt, vor ewigen Diskussionen und politischer Fakten-Auslegerei. Wenn zwei sich streiten: Trefft Euch vor Ort und schaut nach, dann ist die Sache eindeutig. Alles, ws vor Ort nicht eindeutig ist, birgt das Potential für Ärger. Natürlich haben wir davon auch genug (trunk oder primary? river oder stream? town oder city?), aber im großen und ganzen funktioniert es.

Nun gibt es natürlcih Dinge, die sind vor Ort nicht überprüfbar, aber trotzdem eindeutig, wenn man die Überprüfungs-Hürden überwindet. Zum Beispiel ein Springbrunnen, der 1878 (und nicht 1877 oder 1879) erbaut wurde, an dem kein Schild dransteht, aber man kann auf dem Rathaus in den Unterlagen nachsehen und da steht es genau drin. Diese Sachen sind also “theoretisch” überprüfbar, nur eben schwieriger. Wenn sich da zwei streiten, muss man schon sagen: Trefft Euch am Rathaus, wenn das gerade offen hat. Noch schwieriger wird es, wenn Dinge getaggt werden, die zwar überprüfbar sind, aber spezielle Messgeräte erfordern oder ganz spezielles Fachwissen. Und Wikipedia/Wikidata-Links liegen auch irgendwo auf dieser Skala. Sie sind garantiert nicht so leicht zu prüfen wie “hier steht ein Baum” oder “das ist ein Bäcker”.

Ich stelle mir gerade vor, irgendjemand taggt “patron_saint:wikidata=Q1234” und ich darf dann rausfinden, ob der heilige St. Thomas, auf den Q1234 zeigt, auch wirklich derjenige ist, nach dem die Kirche benannt ist, oder ob die Kirche vielleicht doch nach dem St. Thomas mit der ID Q4321 benannt ist, und natürlich ist klar, was ich tun würde: Achselzucken und mir denken “wird sich schon jemand was bei gedacht haben”. Während ich umgekehrt einen Baum, der als Eiche getaggt ist, in der Realität aber doch ein Ahorn ist, durchaus noch reparieren kann.

Also langer Rede kurzer Sinn, bitte hier keinen argumentativen Unsinn verzapfen wie das mit der Bäckerei, das bringt nicht weiter. Vor-Ort-Überprüfbarkeit ist keine ja/nein-Frage, sondern ein Spektrum, und wir täten gut daran, an dem Ende des Spektrums zu bleiben, wo wir noch sehr viele Mapper an Bord haben. Sonst geht unsere Qualität nämlich den Bach runter.

Bye
Frederik

Hallo,
Was Chrysopras schrieb war sehr emotional geladen, trotzdem denke ich versteht jeder, was er meint.
Es ist nicht schlimm, wenn ein zweitrangiges key/value in der Datenbank über kurz oder lang falsch ist.
Das wächst mit der Zeit raus…
Deshalb brauchen wir keine Verbote bestimmte key/value nicht in die Datenbank zu nehmen (es sei denn, die sie spiegeln sexistische, rassistische oder faschistische Meinungen wieder).

grüße von Lutz

Ich denke hier geht dein Argument fehl - es könnte durchaus leichter sein, ersteres zu überprüfen (wenn an der Kirche ein Schild hängt, auf dem steht, sie sei nach dem Hl. Thomas von Foo benannt und ID Q1234 aber der Hl. Thomas von Bar ist), während ein Nicht(hobby)botaniker vielleicht Schwierigkeiten hat, Eiche und Ahorn (oder was ähnlicheres…) auseinanderzuhalten. Das Problem ist wohl eher, dass ich, wenn ich den Baum als Ahorn identifiziert habe, ich sehe, dass der Eintrag mit der Eiche falsch ist, aber wenn ich die Kirche als nach Thomas von Foo benannt identifiziert habe, ich erst noch auf die Idee kommen müsste, den Wikidata-Tag nachzuverfolgen. Aber das wiederum ist eher eine Sache der Darstellung, denn meist wird man ja nicht mit dem Tag selbst interagieren, sondern eine Karte haben, die einem zum Objekt die Informationen aus dem Wikidata-Eintrag anzeigt - und dann sehe ich den Fehler wieder direkt.

Du hast natürlich recht. Ich entschuldige mich also für meinen überzogenen Unsinn aus #14! Worauf ich satirisch aufmerksam machen wollte, war, dass wir ein Tag nicht einfach deshalb ablehnen sollten, weil sein Wert nicht am realen Objekt im Klartext aufgedruckt ist – so habe ich nämlich #12 verstanden, wo es wörtlich heißt:

Wohlgemerkt, hier war noch nicht von Wikidata-IDs die Rede (deren Tagging gewiss Recherche erfordert), sondern von einfachen „wikipedia-Web-Verweis[en]“ – und diese sind in einem Fall wie dem angeführten Englischen Garten mMn auch nicht sooo viel schwerer abzuleiten als das Tag shop=bakery. (Spätestens bei den exotischeren Werten für shop=* muss ich immer wieder mal in unser Wiki schauen, und das ist dann wirklich auch nicht weniger aufwändig als das Heraussuchen eines Wikipedia-Links.) Das Unsinns-Argument “alles muss vor Ort angeschrieben sein” habe ich mir also nicht völlig frei ausgedacht bzw. etwas dazu verdreht, ich habe es aus dem oben zitierten Argument von #12 („ist vermutlich der wikipedia-Web-Verweis [3] nicht aufgedruckt“) entnommen und nur durch die Übertragung auf das Tag shop=bakery deutlicher machen wollen, warum ich diese Auffassung für falsch halte.

Aber das nur zur Erklärung. Ich stimme ja allem 1:1 zu, was Du (woodpeck) in #15 schreibst – ich wurde nur polemisch, weil mir die Auslegung des on-the-ground-Prinzips in #12 doch sehr überzogen vorkam. Mein Eindruck war, dass hier jemand unbedingt gegen die Tags wikipedia=* und wikidata=* angehen möchte und dazu das on-the-ground-Prinzip in … eigenwilliger Weise auslegt, in so überspitzer Weise nämlich, dass dies auch viele andere Tags betreffen und unsere Arbeit insgesamt sehr erschweren würde. Das wollte ich satirisch zeigen. Wenn das zu Missverständnissen verführt, entschuldige ich mich dafür gerne.

Es lebe das on-the-ground-Prinzip – aber immer in maßvoller und vernünftiger Auslegung, also genau so, wie Du (woodpeck) das in #15 beschreibst:

Genau das meinte und meine ich auch.

Edit/Ergänzung: Und dazu, also an dasjenige „Ende des Spektrums […], wo wir noch sehr viele Mapper an Bord haben“, gehören mMn eben auch einfache *wikipedia=-Tags wie wikipedia=de:Englischer Garten (München). Denn während wir über *wikidata=-Tags und v.a. über die zahllosen Varianten und wuchernden Variationen dazu à la *brand:wikidata=, operator:wikidata= etc. gut diskutieren können (dazu gibt es ja den anderen Thread), ist das simple *wikipedia=*-Tag für ein OSM-Objekt wie ein Gebäude, einen Park oder einen Ort nun wirklich kein Hexenwerk.

Da ich das andere Diskussionsthema:
https://forum.openstreetmap.org/viewtopic.php?id=63818 (Was ist die Essenz von OSM?)
nicht mit eher OT befüllen möchte, gehe ich in diesem ggf. etwas passenderen Diskussionsthema mal auf eine dortige Nachricht ein.

Bezüglich Mitteilung:
https://forum.openstreetmap.org/viewtopic.php?pid=716829#p716829

Ja

Danke für den google Tipp :wink: und auch für den Tipp nach Vorträgen und Videos zu schauen. Meinst Du etwa z.B. dieses Vortragsvideo:
https://www.youtube.com/watch?v=Zcv_7t7RcNM (2016 - Michael Maier: OpenStreetMap und Wikidata)

Oder hast Du zufällig Direktverweise zu anderen Vorträgen/Videos parat?

Die Benutzer, die deutschlandweit über 10 wikidata= Tags gelöscht haben. Als gelöscht zählt ein Wikidata Tag in dieser Auflistung nur, wenn er in dem DE Extrakt auch bei keinem anderen Objekt mehr vorhanden ist.
Es finden sich viele nachvollziehbare Löschungen darunter.


nyuriks , 3512
woodpeck_repair , 2282
Reclus , 62
floscher , 29
amilen , 27
richtkreiser , 25
Mateusz Konieczny , 25
Nakaner , 25
nvrandow , 23
elsaxo , 18

Die komplette Liste findet sich hier
https://www.codegeo.de/stats/deleted_tags.txt

Das hast Du grossartig gemacht - im Ernst, ich finde Deine Auswertungen und Statistiken immer sehr interessant.

Bitte erstelle mir, bzw. der Gemeide eine zweite Auswertung von Benutzern, die (sagen wir mal) mehr als 1000 wikidata=* Einträge deutschlandweit hinzugefügt haben.


nyuriks 		27582
4rch 			7636
LogicalViolinist 	4312
archINFORM 		3639
hofoen 			2521
-WI- 			2071
rurseekatze 		1757
MrKrisKrisu  		1756
calli3756  		1589
kjon 			1582
CKorsmeier  		1280
nikkinikki 		1128
AlexanderF 		1065
Nadjita  		1004 

Ich frage hier mal nach wikidata. Was ist der hier z.B. falsch:

wikidata=Q16833157
wikipedia=de:Liste von Brunnen und Wasserspielen in Freital

Wird als “Fehler” in JOSM bemängelt - wie manche anderen wikidata=* auch. Ich habe mir beholfen das wikidata=* zu löschen und neu abzurufen über Daten → Wikidata-Kennung abrufen. Doch funktioniert das auch nicht. Hier wurden viele wikipedia=: mit wikidata ergänzt, wo es als “Warnung” in JOSM kommt.

(Vielleicht sollte ich auch so etwas einfach “ingnorieren”.)

Ein Link zum Objekt würde es uns einfacher machen.

Gruss
walter

In der Regel sollte ein wikipedia/wikidata-Verweis auf das spezielle Objekt verweisen und nicht auf eine Liste/Sammlung von Objekten. In dem Fall also vielleicht auf einen eigenen Eintrag für einen der Brunnen/Wasserspiele in Freital und nicht auf eine Liste ebend dieser. Kommt aber auf das OSM-Objekt an.

Links auf Listen einfach alle streichen und für das Objekt ein dann ein richtiges Datenobjekt anlegen. Und wenn es keinen Artikel gibt, dann auch keinen verlinken, die Liste enthält die gleichen Informationen wie das Wikidata-Item, das ja verlinkt ist.

https://www.openstreetmap.org/node/3988199141

EDIT

https://www.wikidata.org/wiki/Q16833157 verweist ja auf die https://de.wikipedia.org/wiki/Liste_von_Brunnen_und_Wasserspielen_in_Freital

wikipedia=* funktioniert und holt sich auch die richtige wikidata=*

Ist das doch ein “Fehler des Validators” zum ingnorieren?

Wieso löschen? Es gibt einen Artikel und es gibt eine wikidata-Nummer - beides führt mich zum Ziel.

Es führt dich zu einem Übersichtsartikel über 10 verschiedene Brunnen in Freital, nicht zu einem Artikel über genau diesen Brunnen. So lange dieser Brunnen nicht einen eigenen Artikel und/oder ein eigenes Datenobjekt hat, würde ich die Verweise auch löschen. Man verweist ja auch nicht von der Elbe auf einen Wikipedia-Artikel “Gewässer in Deutschland”.

Edit:
Mit deinem Beispiel habe ich das nachvollzogen (nachdem ich das WP-Plugin geladen habe): Der Valdiator beschwert sich genau deswegen:
Q16833157 (Q16833157) is an instance of list (Q12139612) (or any subclass thereof)
Q16833157 (Q16833157) is an instance of web page (Q36774) (or any subclass thereof)

Wie ist das eigentlich, wenn ein Objekt mehrfach auf OSM zu finden ist. Ich hatte z.b. Letztens den Fall, dass eine Stadtbibliothek einen eigenen Wikipedia-Artikel hatte, diese aber drei oder vier Filialen innerhalb der Stadt hatte. Sollte man dann jede Filiale mit Wikidata-Link versehen?

Da zum Beispiel Naturschutzgebiete in der de.Wikipedia regelmäßig in Listen erfasst sind, verlinke ich von OSM-NSGs regelmäßig in Wikipedia-Listen, ganz ohne wikidata, das ist unproblematisch und ein wikidata-Datenobjekt ist für einen nutzerhilfreichen-Wikipedia-Link schlicht und einfach überhaupt nicht nötig.
Was man strukturell nicht machen darf: Das wikidata-Objekt der LISTE für für NUR EIN OSM-Objekt aus der Liste verwenden.
Wenn ich einen wikidata-Bezug zwischen der Wikipedia-Liste und einer OSM-Objektgruppe herstellen möchte, dann muss ich diese Objekte zusammenfassen, z.B. per Relation type=site, diese Relation ist dann das OSM-Äquivalent der Wikipedia-Liste.

@Maturi0n, das ist genaugenommen kein mehrfaches Objekt, sondern ein verteiltes Objekt, wenn man dies bündeln möchte → Relation type=site


Weil mir Verlinkungen in wikimedia-Projekte am Herzen liegen, meine Erfahrungen und Gedanken zusammengefasst:

Bei Verknüpfungen zwischen OSM und Wikidata-Datenobjekten sollte immer eine eineindeutige (mit zweimal “ein”, umkehrbar-eindeutige) Verbindung bestehen:
OSM-Objekt ↔ Wikidata-Objekt
Beispiel: Bei einem OSM-Brunnen-Node ist die Verbindung zum Wikidata-Objekt einer Wikipedia-Brunnen-Liste zwar eindeutig, aber eben nicht eineindeutig.

Grundsätzlich gilt diese anzustrebende Eineindeutigkeit auch für wikipedia und wikimedia_commons=Category:xyz
aber da reicht auch mal pragmatische Eindeutigkeit, wenn der Mapper dort Nutzen sieht:
OSM-Node → Wikipedia(-Liste)

Will man unbedingt eine eineindeutige Verknüpfung, muss man ggf. die OSM-Strukturen anpassen:
OSM-Relation ↔ Wikipedia(-Liste)

Auf Listen würde ich sehr ungern linken, eben wegen der fehlenden Eineindeutigkeit. Auf einen Eintrag einer Liste linken fände ich da schon besser, also z.B. de:Liste der Naturschutzgebiete in Kassel#Dönche oder im Ausgangsbeispiel de:Liste von Brunnen und Wasserspielen in Freital#Storchenbrunnen.

Wikipedia- und Wikidata-Links sollten m.E. nur gesetzt werden, wenn es einen Artikel/Datenobjekt (oder im Fall von Wikipedia zumindest einen verlinkbaren Anker) für dieses konkrete Objekt gibt. Oft ist das nicht der Fall, weil es z.B. nur einen Artikel über “Lidl” gibt, aber keinen über die spezielle Filiale. Dein Beispiel finde ich da prinzipiell vergleichbar.

Evtl. käme einer der Doppelpunkt-Wikidata-Tags wie operator:wikidata in Frage? Bin mir nicht ganz sicher ob es passt.

Naja, nicht immer. Ein Wikilink zu einer Sehenswürdigkeit in Bangkok zum entsprechen Artikel in der thailändischen Wikipedia bringt jemandem, der die Sprache nicht kennt, erstmal nichts. Klar, sofern vorhanden, kommt man dann auch zum Artikel in der eigenen Sprache. Grundsätzlich wäre da aber Wikidata schon zu bevorzugen.