Help fixing newly discovered Disambiguation Wikipedia links

Tool its too difficult for me.
You don't want to generate your own list like in last time?

MKnight wrote:

Tool its too difficult for me.
You don't want to generate your own list like in last time?

MKnight, try this view - it should simply show you the map with all the dots. Zoom in and click on any of the dots - any you will see the object ID and some more information. Also, if you want, in the bottom right corner, there is a drop down to switch map into a table - similar to a list as before. Let me know if its easier. Thanks!

P.S. The old list had to be refreshed by hand. This tool's data is updated every minute, and has many more capabilities.

Vielleicht sollten wir einfach nur noch auf Wikidata verlinken? Diese Verweise sollten sehr stabil sein...

nyuriks wrote:

MKnight wrote:

Tool its too difficult for me.
You don't want to generate your own list like in last time?

MKnight, try this view

Ok, that works, thx.

Yokr wrote:

Vielleicht sollten wir einfach nur noch auf Wikidata verlinken? Diese Verweise sollten sehr stabil sein...

Yes. Eventually. 🙂

MKnight wrote:

Tool its too difficult for me.
You don't want to generate your own list like in last time?

MKnight, very sorry, I posted the wrong link above (fixed). The old query was for missing wikidata tags (also needs fixing). The disambig query is this one

nyuriks wrote:

Yokr wrote:

Vielleicht sollten wir einfach nur noch auf Wikidata verlinken? Diese Verweise sollten sehr stabil sein...

Yes. Eventually. 🙂

Nicht bevor das hier gelöst wurde: https://lists.openstreetmap.org/piperma … 78728.html

Zum ganzen Wikidata Thema läuft übrigens gerade auf der talk-ml eine heftige Diskussion: https://lists.openstreetmap.org/piperma … 78903.html

mmd wrote:

Zum ganzen Wikidata Thema läuft übrigens gerade auf der talk-ml eine heftige Diskussion:

Yes, the discussion is heated. On one hand, there are "data purists" - a conservative group of people who do not want changes. On the other, there are "progressives" - people who want to improve the system because they see benefit in innovation. The third group has not spoken yet - the data consumers. Data consumers have already expressed huge interest in Wikidata, but I think they feel they are not part of the community, and don't want to speak up. Heh, it is getting a bit political 😄

nyuriks wrote:

On one hand, there are "data purists" - a conservative group of people who do not want changes. On the other, there are "progressives" - people who want to improve the system because they see benefit in innovation.

Not sure if this is an adequate summary of the discussion so far. Even folks who you call "conservative" haven't expressed outright opposition to adding Wikidata tags, but object that large style kind of "(half-)automated dumping of wikidata tags into OSM" approach.

Data consumers have already expressed huge interest in Wikidata, but I think they feel they are not part of the community, and don't want to speak up.

Yes right, it totally makes sense from a Wikimedia pov. It's not at all clear if OSM benefits in a similar way by adding Wikidata (as an example see the points raised by Simon). The main reason, why I find OSM very interesting is because of all the geospatial data, less so, because there's a wikidata link. I guess you really need to make your data consumers speak up, and present some of their compelling use cases. So far, really none of those I've seen made me think "wow, that's pure awesome".

Man sollte erwähnen, dass die Seite von nyuriks ziemlich nützlich ist, wenn man falsche Wikipedia-Tags entdecken und korrigieren möchte. Das kann man machen, ohne sich Gedanken darüber zu machen, ob wir wikipedia=* oder wikidata=* in unserer Datenbank haben wollen oder beides.

Wenn unser Node Georgenstein zur Wikipedia-Begriffserklärung Georgenstein verweist, dann ist das einfach falsch. Mit ein bisschen Wissen oder Recherche ist das aber schnell zum richtigen Georgenstein (Isar) und dem passenden Wikidata-Eintrag (sieht man links in der Spalte bei Wikipedia-Einträgen) umgebogen.

Wer das macht hat auf jeden Fall die Datenbank verbessert, ganz unabhängig von der Frage, ob wir die Tags überhaupt brauchen. Eines der beiden Tags kann man dann später immer noch löschen, wenn man das unbedingt will. Falsch waren vorher beide, danach sind beide richtig.

Grüße
Max

@mmd, hehe, agree, "conservative" is over-simplified definition 🙂 I was simply referring to a general trend in all communities - you have those that want change, the faster the better, and there are those who want to slow down changes or possibly even reverse to the good old times. And often the same person can be on the different sides for different issues.

As for Wikimedia - to be honest, i have no clue how Wikimedia would benefit in a direct way from any of this. I know for a fact that at least two very well known OSM data consumers are using Wikidata to augment OSM data. Their primary interest is in multilingual labels, as that is the simplest thing to extract. (disclosure: while I was formally employed by WMF, I no longer am, and I do not support a lot of things they are going)

Mal ne Frage, die sich mir beim Thema stellt, es gibt POis, wo mir nicht ganz klar ist, ob die (wikipedia)disambiguish-page sinnvoller ist, als gar keine Seite.
An 'nem Beispiel: https://de.wikipedia.org/wiki/Jamel
Hier gibt es mehrere Optionen:

• So lassen wie's ist
  
• wikipedia:de=Jamel (Banzkow) (nicht existierende Wikiseite)
  
• wikipedia:de=Banzkow
  
• wikipedia ganz weg
  
• irgendwas anderes
  

Bis auf den letzten gefällt mir keiner der Punkte, irgendwelche Ideen dazu?

Edit: Noch was:
https://www.openstreetmap.org/node/496533938 bezieht sich (eigentlich) auf https://de.wikipedia.org/wiki/Cap_Arcon … f,_1927%29
Verlinkt ist die Übersicht (disambiuish).
Was macht man denn in solchem Falle?

I would suggest "something else" -- e.g. "related:wikipedia" tag. I think that whenever wikipedia doesn't have a good entry, but there is some other page related to it, use the related:wikipedia & related:wikidata tags. Related wikipedia page may have a section about the object. Or it could be a list, or a disambig.

Schade, dass ausser Juri (thx!) sich keiner geäussert hat. Moment, keiner? Die Wochennotiz hat was:

Um die 40.000 Wikidata-Tags, die nicht zu den Wikipedia-URLs passen, anzugleichen, schlägt Yuri Astrakhan vor, das Problem mit einem Skript zu beheben. Auf der Mailingliste werden Osmose und Maproulette als Alternativen genannt, die die Community mit einbeziehen.

Durch Yuri Astrakhan wurde durch eine zweite Email erneut eine längere Diskussion darüber angestoßen, ob noch fehlende Wikidata-Tags automatisch hinzugefügt werden sollen. Auch einige problematische Beispiele hielten ihn aber schließlich nicht von einem schlecht durchgeführten mechanischen Edit ab.

Hierzu möchte ich verschiedene Dinge feststellen:

• Ich hab die Diskussion nicht gelesen, da mein Englisch nicht sonderlich gut ist. Aber ich verstehe im Groben worum es geht;
  
• ja, das mechanical Edit ist suboptimal, da es Unmengen an Fehlern in OSM hereinbringt [1]
  
• nein, das mechanical Edit ist nicht suboptimal, da es Unmengen an "Fehlern" in OSM durch diesen Holzhammer überhaupt erst sichtbar UND korrigierbar macht.
  
• es gibt eine parrallele Diskussion zum Thema, die ich mal wieder überhaupt nicht verstehe: https://forum.openstreetmap.org/viewtopic.php?id=59910 hier geht es wie in zig ähnlichen unsäglichen Diskussionen darum, irgendwelche Tags (hier wikidata) als überflüssig bis unnütz zu brandmarken. Ich halte diese wie auch ähnliche Diskussionen für zeit-und kraft-bindend. Der typische Wikipedia-Relevanz-scheiss. Jeder (Pro-)Aktivist bringt seine persönlichen Hassvorlieben ein und am Ende wurde viel diskutiert ohne Ergebnis und ohne Relevanz (oder im schlimmsten Fall mit einem "Konsens" zum Löschen unbeliebter Tags). Das brauchen wir in OSM unbedingt auch noch!!11eins
  

[1] das halte ich allerdings für legitim, da es die Korrekturen einfacher macht. Versions/History-aufblähdingsi etc.halte ich für mimimi. Juri hat sich in der Vergangenheit immer um Öffentlichkeit und Mitstreiter bemüht, so dass Probleme der Art innerhalb kürzester Zeit behoben wurden. Klar kann man das vielleicht mit den 3 Hanseln bei Maproulette etc. auch erledigen, aber nicht in der Qualität und Quantität.

MKnight wrote:

• ja, das mechanical Edit ist suboptimal, da es Unmengen an Fehlern in OSM hereinbringt [1]
  
• nein, das mechanical Edit ist nicht suboptimal, da es Unmengen an "Fehlern" in OSM durch diesen Holzhammer überhaupt erst sichtbar UND korrigierbar macht.
  

Dein Fähnchen dreht sich auch irgendwie im Wind so wie es dir gerade passt.
Ich erinnere mich an eine Aussage, dass man einzelne Fehler nur beheben darf, wenn man das gesamte im Blick hat und alle Fehler eines Objekts erkennt. Es wäre als Mapper unsere zentrale Aufgabe.
Weder Import nach nachgehende "Korrektur" können hier den Anspruch halten.
Mein Argument damals war, dass etwas fehlerhaftes, unsichtbares durch die Fehlerkorrektur ja erst sichtbar wird. Jetzt ist es auch dein Argument, auch noch gleich für Automatische Edits, wow. Wir lernen anscheined alle dazu.

MKnight wrote:

• So lassen wie's ist
  
• wikipedia:de=Jamel (Banzkow) (nicht existierende Wikiseite)
  
• wikipedia:de=Banzkow
  
• wikipedia ganz weg
  
• irgendwas anderes
  

ganz weg - es hat keinerlei Bezug zu einer Wikipedia-Seite (mit weiteren Informationen)

MKnight wrote:

Edit: Noch was:
https://www.openstreetmap.org/node/496533938 bezieht sich (eigentlich) auf https://de.wikipedia.org/wiki/Cap_Arcon … f,_1927%29
Verlinkt ist die Übersicht (disambiuish).

korrigieren! (Für mich auch ein Beispiel, wie aus der "Ferne" falsches noch falscher wird -> falsches wikidata.)

vielleicht kannst du dann auch
image=https://de.wikipedia.org/wiki/Cap_Arcona_(Schiff,_1927)#/media/File:Grevesm%C3%BChlen-cap-arcona-friedhof-umfriedung.JPG

verlinken

R0bst3r wrote:

Ich erinnere mich an eine Aussage, dass man einzelne Fehler nur beheben darf, wenn man das gesamte im Blick hat und alle Fehler eines Objekts erkennt.

Ich hätte vlt. nicht von "Fehlern" sprechen sollen, streng genommen sind sie das ja nicht.

MKnight wrote:

Was macht man denn in solchem Falle?

Ähnlich interessant finde ich auch diesen Fall. Dort wurde anscheinend in Wikipedia etwas aufgegliedert was eigentlich einen Oberbegriff hat. In dem Fall wäre die Seite also irgendwie auch korrekt.

Vielleicht sollte man da auch unterscheiden zwischen "related" und "noch nicht vorhanden".
Bei ersterem fände ich die Variante von nyuriks nicht schlecht, weil man so auch direkt auf Seiten verweisen kann wo der Punkt vielleicht nur ein Unterbegriff ist. Dessen Bedeutung dürfte auch nicht vergehen, selbst wenn dann eventuell ein direkter Verweis auf einen bestimmten Artikel dazukommen sollte.
Zweiteres ist murks, da hilft einem dann meist die disambiguation page auch nicht. Außer wenn es dann vielleicht irgendwann angelegt wurde.

Mal zur Dokumentation der (übrigen) grenzwertigen Sachen in Deutschland:

https://www.openstreetmap.org/node/496533938 https://de.wikipedia.org/wiki/Cap_Arcona (siehe Thread)
https://www.openstreetmap.org/node/4414499605 https://de.wikipedia.org/wiki/Jamel (siehe Thread)
https://www.openstreetmap.org/node/3240785489 https://de.wikipedia.org/wiki/Gehlsbach
https://www.openstreetmap.org/node/30109731 https://de.wikipedia.org/wiki/Kletzke (kein wiki-eintrag)
https://www.openstreetmap.org/node/1890221815 https://de.wikipedia.org/wiki/Siems (kein wiki-eintrag)
https://www.openstreetmap.org/node/599873093 https://de.wikipedia.org/wiki/Rixdorf
https://www.openstreetmap.org/node/244211691 https://de.wikipedia.org/wiki/Klebitz (kein wiki-eintrag)
https://www.openstreetmap.org/node/122469500 https://de.wikipedia.org/wiki/Habertshausen
https://www.openstreetmap.org/node/2397755662 https://de.wikipedia.org/wiki/Seiler (kein wiki-eintrag)
https://www.openstreetmap.org/node/3052070852 https://de.wikipedia.org/wiki/Rodt
https://www.openstreetmap.org/node/173829201 https://de.wikipedia.org/wiki/Frangenheim (kein wiki-eintrag)
https://www.openstreetmap.org/node/2627285369 https://de.wikipedia.org/wiki/Flachsr%C3%B6ste (ähm...)
https://www.openstreetmap.org/relation/1781197 https://de.wikipedia.org/wiki/Zollernalbbahn (siehe Thread)

(ja ich weiss, das kann man sich auch aus dem Query holen, nur wenn die aus dem Query verschwinden, wäre es bspw. interessant, wie das jeweils gelöst wurde)

Since yesterday-ish the query doesn't seem to be working anymore (504 Gateway Time-out). From what I can gather this is true for all other queries too. Any workaround?

kartonage wrote:

Since yesterday-ish the query doesn't seem to be working anymore (504 Gateway Time-out). From what I can gather this is true for all other queries too. Any workaround?

Yes, I'm aware of it - the service keeps freezing up, possibly due to memory issues (I'm running it on my test server, still looking for a proper server). The issue is tracked at https://jira.blazegraph.com/projects/BL … /BLZG-9058 - some Java help is highly appreciated. In the mean time, I'm automating service auto restarts.

nyuriks wrote:

kartonage wrote:

Since yesterday-ish the query doesn't seem to be working anymore (504 Gateway Time-out). From what I can gather this is true for all other queries too. Any workaround?

Yes, I'm aware of it - the service keeps freezing up, possibly due to memory issues (I'm running it on my test server, still looking for a proper server). The issue is tracked at https://jira.blazegraph.com/projects/BL … /BLZG-9058 - some Java help is highly appreciated. In the mean time, I'm automating service auto restarts.

I just added a monitoring task - it should automatically restart the service if it starts lagging.

nyuriks wrote:

the service keeps freezing up, possibly due to memory issues (I'm running it on my test server, still looking for a proper server). The issue is tracked at https://jira.blazegraph.com/projects/BL … /BLZG-9058 - some Java help is highly appreciated.

In any case I would check the JDK: you seem to be running OpenJDK, while https://github.com/blazegraph/database/ … egraph-deb suggest to use Oracle JDK instead. There may be subtle changes here, and OpenJDK may have not received the same amount of testing. To avoid chasing such strange bugs, I'd recommend to follow exactly the installation steps as per Blazegraph's docs.

mmd wrote:

nyuriks wrote:

the service keeps freezing up, possibly due to memory issues (I'm running it on my test server, still looking for a proper server). The issue is tracked at https://jira.blazegraph.com/projects/BL … /BLZG-9058 - some Java help is highly appreciated.

In any case I would check the JDK: you seem to be running OpenJDK, while https://github.com/blazegraph/database/ … egraph-deb suggest to use Oracle JDK instead. There may be subtle changes here, and OpenJDK may have not received the same amount of testing. To avoid chasing such strange bugs, I'd recommend to follow exactly the installation steps as per Blazegraph's docs.

Heh, this is a complex one. Wikidata itself runs a customized version of Blazegraph on OpenJDK, with their own custom data uploader and storage optimizations and functions. They haven't seen this issue. My service uses the Wikidata's version, plus contains additional minor modifications to optimize OSM data storage. See github.

Ok, then, let's wait for some feedback on the Jira issue. It's very unlikely to find someone around here who's familiar with blazegraph. Those minor modifications look rather innocent at first sight.

As you're reporting lock issues during COMMIT, that would either be related to OSM or Wikidata db updates? Is the data uploader setup similar to how Wikidata runs their updates? Do they also run multiple sources? Are those updates running in parallel and could potentially fight each other?

mmd wrote:

Ok, then, let's wait for some feedback on the Jira issue. It's very unlikely to find someone around here who's familiar with blazegraph. Those minor modifications look rather innocent at first sight.

As you're reporting lock issues during COMMIT, that would either be related to OSM or Wikidata db updates? Is the data uploader setup similar to how Wikidata runs their updates? Do they also run multiple sources? Are those updates running in parallel and could potentially fight each other?

Heh, seems like Blazegraph org itself seems mostly quiet - they might have ran out of money. I feel like most of the work and bugfixes is actually being done by others, e.g. WMF (smalyshev). Also, ideally anyone with enough Java experience might know the answer.

I am not sure if it's COMMIT or not, I would need to dive deeper into the code. Yes, WMF only runs one updater. The updater sends updates as a continuous stream of very small increments, each taking a split second to apply. On the other hand, the OSM updater I wrote sends data as much bigger bursts once a minute, but usually also takes very little time. So if there is an updater bug in Blazegraph, it is possible that I trigger it but Wikidata doesn't. Thanks for the idea.