User talk:Wurgl

Belatedly, -- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:43, 7 September 2017 (UTC)[reply]

Ich möchte von Dir eine hinreichende sachliche Begründung, warum deines Erachtens die Brachialmethode des Rückgängigmachen-Buttons gerechtfertigt war, um meinen Edit wegzuputzen? Vernünftiger ist es allemal, für richtig gehaltene Überarbeitungen vorzunehmen, ohne damit unnötige Konflikte zu produzieren. Ich halte es für einen Missbrauch des Buttons, wenn nicht sehr gute Gründe vorliegen. Denn die Sachlage ist durchaus nicht eindeutig.

Inhaltlich hats Du angegeben: "Bitte keine Namenseinträge". Der vorhandene GND war tatsächlich nur ein Namenseintrag "Fernández, Agustí". Wenn die dt. Nationalbibliothekare keine konkreten Werke vorliegen haben, die sie einarbeiten können, ist das nunmal so. Und so ein Namenseintrag ist doch besser als nichts! Er ist anschlussfähig und bereit, Werkeinträge nachtragen zu können.

Wikidata ist eigenständig. Nur weil es in der deutschen Wikipedia so eine Unerwünscht-Empfehlung gibt (samt detaillierten Verfahrensregeln), gilt sie nicht gleichermaßen für Wikidata (meines Wissens keine Verfahrensregeln). Das solltest Du zur Kenntnis nehmen. Oder nachweisen, dass ich mich irre. -- Justus Nussbaum (talk) 07:03, 17 August 2018 (UTC)[reply]

Ich ziehe mal den Spezialisten hinzu: @Kolja21: kann dir ausführlich erklären, warum Namenseinträge nicht nach Wikidata sollen. --Wurgl (talk) 07:08, 17 August 2018 (UTC)[reply]

Nur ganz kurz: Bitte die Beschreibung von Property:P227 lesen. --Wurgl (talk) 08:40, 17 August 2018 (UTC)[reply]

@Justus Nussbaum: Der Reversbutton schafft schnell böses Blut, da hast du natürlich recht, aber der Hinweis: "Bitte keine Namenseinträge" ist völlig korrekt. Das gilt vor allem für Wikidata, da hier keine mit Wikipedia vergleichbaren Wartungslisten existieren. Wir hatten schon öfters die Fälle, wo zwei Personen mit den gleichen Normdaten zusammengeführt wurden und später stellte sich heraus, dass die vermeintlichen Tps (Thesaurus Person) nur Tns - Platzhalter, vergleichbar mit Wikimedia disambiguation page (Q4167410) - waren. Gruß --Kolja21 (talk) 21:09, 17 August 2018 (UTC)[reply]

Wobei ich das Revert verwende, weil ich dort einen Änderungskommentar eingeben kann, eine Begründung für die Änderung. ich kann natürlich das ganz einfach so rauswerfen, aber dann macht ein anderer einen kommentarlosen Revert und was dann? Editwar? Oder Zeit mit langwierigen Erklärungen auf den Diskussionsseiten verschwenden? --Wurgl (talk) 21:14, 17 August 2018 (UTC)[reply]

Hello, would you like rollback rights? It would help you revert vandalism faster. -- Ajraddatz (talk) 18:21, 29 October 2019 (UTC)[reply]

I just do it for (some kind of) fun. About once a day I look at https://tools.wmflabs.org/wdvd/index.php?lang=de and if something looks unexpected/strange or like typical vandalism, I do a closer look. It is just half an hour per day, not more, main activity is deWP. I do not miss any rights here, thanks! And seriously: Some parts of Wikidata are still a big question mark for me. --Wurgl (talk) 18:30, 29 October 2019 (UTC)[reply]

Ok, well thanks for your help anyway! If you change your mind let me know. Regards, -- Ajraddatz (talk) 18:29, 30 October 2019 (UTC)[reply]

@Ajraddatz: In the german WP we are kind of discussing adding GND-Ids (see de:Benutzer_Diskussion:Wurgl/Fehler_GND#Wegen_Updates_…) automagically by some bot-script. Biographies, GND-Ids and VIAF-Ids are the main part of my contributions in de-Wikipedia. Since early 2017 I am doing with a bot on deWP (de:Special:Contributions/APPERbot), so I have a some of experience there, but not with wikidata. Any comments? Note: Even "don't do it" is a valid and accepted comment, no problem. Or any hints, any must read, any "contact xyz first"? --Wurgl (talk) 00:28, 6 November 2019 (UTC)[reply]

Hi, unfortunately I don't know much about that. You could ask on the project chat. -- Ajraddatz (talk) 00:34, 6 November 2019 (UTC)[reply]

Thx, @Wurgl:, for your modification to VIAF ID (P214) in Q27883339. Please, consider to help VIAF correct its own error adding this page, and others, if any, to Wikidata:WikiProject_Authority_control/VIAF_errors. -- Bargioni 🗣 09:17, 20 May 2020 (UTC)[reply]

Hi @Wurgl:, halte dich bitte mit Rollbacks wegen Vandalismus zurück, wenn du dir nicht wirklich sicher bist. Mit deinem Rollback hast du dafür gesorgt, dass wieder alte / unkorrekte Informationen in Wikidata standen. Ungeruehrt (talk) 17:39, 26 September 2020 (UTC)[reply]

@Ungeruehrt: Weißte, ich hab bei dem etwas gezögert. Habe dann doch wegen der Verunstaltung des Namens "Dörner" zu "Doener" von der gleichen IP. Ohne den "Doener" hätte ich das ganz sicher nicht angefasst. --Wurgl (talk) 17:47, 26 September 2020 (UTC)[reply]

Grüß dich, es ist alles in die Wege geleitet. Zwei Wikidata-Sätze bestehen, beide GND und LCCN sind sauber zugeordnet, ISNI-Satz wurde zur Korrektur angemeldet, die übrigen Normdaten sind exakt zugeordnet und (bei der jeweils anderen Person) auf no value gesetzt. Der VIAF-Satz wird in näheren Zukunft aufgesplittet werden. Ich denke daher, dass diese Edits nicht so wahnsinnig sinnvoll sind. Aber wenn du mehr Informationen hast, dann immer raus damit ː-) --Mai-Sachme (talk) 07:26, 21 March 2021 (UTC)[reply]

Der Grund für diese Edits sind die hirnbefreiten Bots. "Juhu, in der VIAF steht die ID, die trag ich jetzt auch ein." Jetzt aber ist die Situation "Och, die stehen schon da?". --Wurgl (talk) 07:29, 21 March 2021 (UTC)[reply]

Dear Wurgl,

I hope you are doing good,

I am Kholoud, a researcher at King’s College London, and I work on a project as part of my PhD research that develops a personalized recommendation system to suggest Wikidata items for the editors based on their interests and preferences. I am collaborating on this project with Elena Simperl and Miaojing Shi.

I would love to talk with you to know about your current ways to choose the items you work on in Wikidata and understand the factors that might influence such a decision. Your cooperation will give us valuable insights into building a recommender system that can help improve your editing experience.

Participation is completely voluntary. You have the option to withdraw at any time. Your data will be processed under the terms of UK data protection law (including the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018). The information and data that you provide will remain confidential; it will only be stored on the password-protected computer of the researchers. We will use the results anonymized to provide insights into the practices of the editors in item selection processes for editing and publish the results of the study to a research venue. If you decide to take part, we will ask you to sign a consent form, and you will be given a copy of this consent form to keep.

If you’re interested in participating and have 15-20 minutes to chat (I promise to keep the time!), please either contact me at kholoudsaa@gmail.com or use this form https://docs.google.com/forms/d/e/1FAIpQLSdmmFHaiB20nK14wrQJgfrA18PtmdagyeRib3xGtvzkdn3Lgw/viewform?usp=sf_link with your choice of the times that work for you.

I’ll follow up with you to figure out what method is the best way for us to connect.

Please contact me using the email mentioned above if you have any questions or require more information about this project.

Thank you for considering taking part in this research.

Regards

Kholoud

Hey Wurgl, soweit ich verstehe, verarbeitest Du gelegentlich Dumps von der GND für Dein persondata-Tool. Welche Dumps/Formate nimmst Du da, damit das effizient abläuft? Viele Grüße! —MisterSynergy (talk) 21:58, 25 February 2022 (UTC)[reply]

authorities-geografikum_lds.rdf.gz authorities-kongress_lds.rdf.gz authorities-person_lds.rdf.gz authorities-werk_lds.rdf.gz authorities-koerperschaft_lds.rdf.gz authorities-sachbegriff_lds.rdf.gz

Das war mal eine einzige Datei, haben die dann auf Wunsch von ??? aufgeteilt, waren mal 7, aber authorities-name_lds.rdf.gz gibts nicht mehr. --Wurgl (talk) 22:06, 25 February 2022 (UTC)[reply]

Kannst Du diese Dumps denn parsen, ohne sie erstmal komplett in den Hauptspeicher zu laden? —MisterSynergy (talk) 07:51, 26 February 2022 (UTC)[reply]

Ja! Ich parse von stdin als Stream … sowohl mit PHP (da mach ich das mit den Wikipedia-Dumps) als auch bei dem Programm in C++. --Wurgl (talk) 07:54, 26 February 2022 (UTC)[reply]

Nachtrag: Stdin als Stream und nicht von einem File, weil ich die Ausgabe von gzip -d parse, also quasi direkt vom komprimierten Zeugs. --Wurgl (talk) 07:56, 26 February 2022 (UTC)[reply]

Hm, und wie bekommst Du das dann interpretiert, so dass Du aus dem XML zum Beispiel eine Datenstruktur machst, die einen kompletten GND-Datensatz repräsentiert? —MisterSynergy (talk) 08:00, 26 February 2022 (UTC)[reply]

Tja. Bescheiden. Ich verwende SQlite (das ist im Single-Task-Betrieb schneller) und hab eine einfache Tabelle CREATE TABLE "gndData" ("gndId" TEXT NOT NULL, "fieldType" INTEGER NOT NULL, "data" TEXT NOT NULL) gndId ist klar, fieldType entspricht sowas wie "gndo:variantNameForThePerson" (allerdings als numerischer Wert) und data ist dann das Zeug was da steht. Wobei in data auch ein Inhalt stehen kann, der auf gndId verweist um diese rekursiven Konstrukte auflösen zu können.

Für ein paar Dinge die ich ganz speziell brauche wie den Typ (Person, Geographikum, Organisation, ...) hab ich noch eine Tabelle, ebenso für die Redirects, die Aliase und die VIAF.

Der erste Datensatz im File authorities-person_lds.rdf.gz sieht dann so aus:

select * from gndData where gndId = '100000193';
gndId|fieldType|data
100000193|30|Prof.
100000193|44|Ordinarius an der jurist. Fakultät der Univ. Leipzig
100000193|74|1695-02-20
100000193|77|1763-03-02
100000193|96|130374512
100000193|96|121453839
100000193|96|126261113
100000193|108|male
100000193|109|XA-DE
100000193|142|4038749-5
100000193|142|4035206-7
100000193|143|4035206-7
100000193|148|4035206-7
100000193|163|Bauer, Johann Gottfried
100000193|170|4025243-7
100000193|170|4029050-5
100000193|173|Rechenberg, Karl Otto: Institutionum iurisprudentiae naturalis  Lib. II.,  Tit.  1  -  4  ...
100000193|173|Dissertatio inauguralis de pacto remissorio ante concursum formalem in foro Saxoniae electoralis
100000193|173|Dissertatio inauguralis de aestimandis et restituendis fructibus, ad dec. nov. II
100000193|214|Baverus, Joan. Godofredus
100000193|214|Baverus, Io. Godofredus
100000193|214|Baverus, Ioan. Godofredus
100000193|214|Bauerus, Johannes Godofredus
100000193|214|Bauerus, Joannes Godofredus
100000193|214|Bauerus, Iohannes Godofredus
100000193|214|Bauerus, Ioan. Godofredus
100000193|214|Bauerus, Ioannes Godofredus
100000193|214|Baver, Ioh. Godofredvs
100000193|214|Bauer, Ioh. Godofredus
100000193|214|Bauer, Iohannes Godofredus
100000193|214|Bauer, Io. Godofredus
100000193|214|Bauer, Ioannes Godofredus
100000193|214|Bauer, Joannes Godofredus
100000193|214|Bauer, Johannes Gottofredus
100000193|214|Bauer, Johannes Gothofredus
100000193|214|Bauer, Johanes Gottfried
100000193|214|Bauer, Johannes Gottfried
100000193|219|http://www.wikidata.org/entity/Q55861550
100000193|219|http://isni.org/isni/0000000061362700
100000193|219|http://viaf.org/viaf/32334419
100000193|232|130374512
100000193|232|121453839
100000193|235|126261113
100000193|-159|100000193$1
100000193|-210|100000193$2
100000193|-210|100000193$3
100000193|-210|100000193$4
100000193|-210|100000193$5
100000193|-210|100000193$6
100000193|-210|100000193$7
100000193|-210|100000193$8
100000193|-210|100000193$9
100000193|-210|100000193$10
100000193|-210|100000193$11
100000193|-210|100000193$12
100000193|-210|100000193$13
100000193|-210|100000193$14
100000193|-210|100000193$15
100000193|-210|100000193$16
100000193|-210|100000193$17
100000193|-210|100000193$18
100000193|-210|100000193$19

Diese Einträge wie "100000193$1" sind dann die oben genannten rekursiven Datensätze:

select * from gndData where gndId = '100000193$1';
gndId|fieldType|data
100000193$1|103|Johann Gottfried
100000193$1|200|Bauer

Wie gesagt, eine bescheidene Abbildung. --Wurgl (talk) 08:18, 26 February 2022 (UTC)[reply]

Hm okay. Wenn Du den Stream liest, musst Du aber schon erstmal irgendwie festhalten, was die aktuelle GND-Entität ist und dann kannst Du Kram in Deine lokale Datenbank schreiben, bis Du irgendwann mal die nächste GND-Entität siehst. Ganze GND-Entitäten hast Du aber nie im Speicher.

Ich hatte gehofft, dass man das ähnlich komfortabel wie die JSON-Dumps von Wikidata verarbeiten kann. Darin sind Datenobjekte zeilenweise als individuelle JSON-Objekte serialisiert, so dass man den Dump eben zeilenweise lesen kann und jede Zeile dann direkt in eine Datenstruktur parst, die man dann (einmalig) sehr effizient nutzen kann. Mit Python geht das easy in weniger als 10 Zeilen.

Die GND-Dumps geben das aber augenscheinlich nicht her, ohne erstmal einiges an Bufferlogik zu schreiben. —MisterSynergy (talk) 08:38, 26 February 2022 (UTC)[reply]

Hmm … ich lese auch die Wikipedia-Dumps als XML wget -q -O - https://dumps.wikimedia.org/dewiki/latest/dewiki-latest-pages-articles-multistream.xml.bz2 | bzip2 -d | php ~/dumps/bild-tags.php Ja, ein bissl Kontext muss man sich halt merken. Wurgl (talk) 08:47, 26 February 2022 (UTC)[reply]

Das Format ist nebensächlich, weil man alles mit entsprechenden libraries parsen kann. Ich mache alles in Python, da ist JSON in vielerlei Hinsicht vorteilhaft. RDF (XML oder nt oder ttl oder whatever) geht auch, da könnte man dann zum Beispiel mit wenigen Zeilen Code individuelle Entitäten als Graph-Objekt einlesen und darauf SPARQL-Abfragen direkt in Python durchführen.

Blöd ist nur dies "ein bissl Kontext muss man sich halt merken", was die Sache umständlich und fehleranfällig macht. Die GND-Dumps sind so umständlich formatiert, dass ich folgende Optionen habe:

• erstmal alles in den Hauptspeicher lesen und dann parsen (braucht extrem viel Hauptspeicher)
• lokal buffern, bis eine sinnvolle Dateneinheit eingelesen ist (ist kompliziert zu implementieren)
• häppchenweise Information in der Größenordnung einzelner Tripel einlesen (unpraktisch)

Hilfreich wäre es, wenn die GND-Dumps ebenfalls mit zeilenweise portionierten Datenobjekten angeboten werden würden, zumindest in einigen Formaten. —MisterSynergy (talk) 09:31, 26 February 2022 (UTC)[reply]

Die haben auch andere Formate, siehe https://data.dnb.de/opendata/

Als ich das damals getippt habe, hab ich mit JSON nicht so die Erfahrung gehabt, eigentlich ne glatte Null an Erfahrung. Und wenn ich mit diese JSON-Dateien dort angucke … ich glaub nicht dass die einfacher zu lesen sind. Eine GND = ein Datensatz scheint dort nicht zu sein. Bei den Personen ist da am Anfang erstmal ein Array von Namen … wie es dann weitergeht … nee, will ich nicht wissen. Wurgl (talk) 09:41, 26 February 2022 (UTC)[reply]

Das eignet sich alles nicht, bzw. braucht einige Verrenkungen um nützlich zu sein. Ich hatte gehofft, dass die vielleicht anderswo noch was besseres haben :-) —MisterSynergy (talk) 09:56, 26 February 2022 (UTC)[reply]

Hab mir jetzt was brauchbares auf Basis des XML-Dumps gebastelt. Das läuft so mit ~1000 Entitäten je 4-6 Sekunden – braucht also einen halben Tag oder so für den gesamten Dump. Das ist allerdings kein Problem, man macht es ja idealerweise nur einmal alle paar Monate ;-) —MisterSynergy (talk) 15:06, 26 February 2022 (UTC)[reply]

Oho! Das ist langsam.

Ich bau mir immer aus vielen Datensätzen ein Statement der Art INSERT INTO blah (a, b, c) VALUES (1, 2, 3), (4, 5, 6), (7, 8, 9) zusammen und Indizes werden erst gebastelt, wenn alles drinnen ist – ich fang immer mit leeren Tabellen an, keine Update/Insert/Delete-Gehampel. Dauert so … hmm … gefühlt unter einer Stunde jedenfalls. Wurgl (talk) 15:11, 26 February 2022 (UTC)[reply]

Ja, finde auch dass das langsam ist – es kommt aber eben auch nicht so drauf an. Ich suche mir Zeilen zusammen, bis ich eine komplette Entität im Buffer habe und verarbeite den dann am Stück. Dann kann ich nämlich alles recht komfortabel mit SPARQL direkt in Python aus der Entität extrahieren. Letztlich tausche ich Geschwindigkeit gegen bequemen Zugriff ab… —MisterSynergy (talk) 15:18, 26 February 2022 (UTC)[reply]

Hallo Wurgl, ich habe gerade gesehen, dass die GNDs, die ich bei Vischer (Q2528123) gelöscht habe, von dir eingefügt wurden. [1] Mit dem Zusatz "Missbilligter Rang" war das natürlich kein Fehler, aber ich halte es für besser, mit different from (P1889) zu arbeiten. Das scheint die beste Möglichkeit zu sein, die Vermischungen bei VIAF zu beheben. Die Ränge sind zwar eine gute Idee, aber weder VIAF noch die meisten Bots können sie auslesen. --Kolja21 (talk) 17:00, 4 May 2022 (UTC)[reply]

Problem!

Ich hab auf de:Benutzer:APPER/VIAF (momentan) 528 Kandidaten wo die VIAF irgendwas mischt. Ca. 30 Stück haben (noch) keine andere Bibliothek als "Missbilligt" eingetragen, ca. 500 Stück haben mindestens eine als "missbilligt" eingetragen. Das ist eine Übersicht über die Menge.

Ich prüfe jeden Tag alle diese 500 VIAFs, ob immer noch die missbilligten im VIAF-Cluster sind (um genau sein: In dem VIAF-Cluster wo die GND zum Zeitpunkt der Prüfung steckt). Wenn nicht, dann steht da "kein missbilligter Rang" (oder wenn sich die VIAF geändert hat "VIAF nicht als missbilligt gekennzeichnet" und dann kann ich eventuell die VIAF in deWP eintragen oder aber eine weitere VIAF als "missbilligt".

Die Erfahrung aus der Abarbeitung dieser Liste in Form von Eintragen von missbilligten Rängen war diese, dass es durchaus Fälle gibt, vo die VIAF gleich bleibt auch wenn die LCCN rausgenommen wird. Ich kann also nicht davon ausgehen, dass eine Änderung des Clusters auch eine Änderung der VIAF bewirkt, auch nicht wenn die LCCN rausfliegt.

Wenn du die missbilligten rauswirfst, dann sehe ich keine Chance wie ich erkennen kann, ob der VIAF-Cluster sich zum positiven geändert hat. Irgendwo muss ich ja vorhalten, welche Bibliothek weg muss damit der sauber ist.

Das zweite Problem sind übereifrige Bots, die mit der Begründung "Bei der VIAF steht diese Bibliothek" diese Bibliotheken (die du rausgeworfen hast) wieder eintragen. --Wurgl (talk) 20:48, 4 May 2022 (UTC)[reply]

Das zweite Problem habe ich über Wikidata:Database reports/Constraint violations/P227 im Griff. Aber wenn dir der "Missbilligter Rang" bei der Wartungsarbeit hilft, werde ich in Zukunft drauf achten, nur die Einträge zu löschen, bei denen der Fehler in VIAF behoben ist. Hab' die Löschung daher rückgängig gemacht. - Insgesamt läuft die Arbeit auf Wikidata mittlerweile deutlich besser als früher. Es haben sich einige Profis eingefunden, auch wenn es immer wieder haarsträubende Falschzuordnungen und Vermischungen gibt. --Kolja21 (talk) 00:50, 5 May 2022 (UTC)[reply]

Wenn das nur zehn solcher Einträge wären, dann könnte man die per Hand abklappern, aber bei 500 immer wieder die Augen wund gucken … das geht einfach nicht. Ich werd aber mal schauen, ob ich bei "verschieden von" das andere Objekt angucken kann und dort die nicht gar so toll zugeordneten identifizieren kann. Das Problem des Nacharbeitens (aka Entfernens) übereifrig zugeordneter Bibliotheken bleibt, wobei mir hauptsächlich der gesperrte Matlin aufgefallen ist. --Wurgl (talk) 05:20, 5 May 2022 (UTC)[reply]

Weil immer wieder der Punkt "eine Person anlegen" bei so Vermischungen kommt. VIAF:8290149296173380670008 mit LCCN/NUKAT. Das ist wohl ein anderer, siehe Template:DNB bzw. mit Bild des Einbandes: http://randbuch.info/gehetzt-uebers-meer_nr20087 Mit 17 schreibt man sowas nicht, außerdem ist der aus deWP eher der Musik zugetan. Nun gibt es bei Heinz Korn (Q1600496) ein "different from" Heinz Korn (Q16014910) einen Wehrmachtsoffizier, der wäre zu dem Zeitpunkt immerhin schon 20 gewesen. Die ukrainische WP hat bissl was an Text, der ist es wohl auch nicht (war wohl eher Flieger und zur fragl. Zeit wahrscheinlich an der russischen Front, also keine Zeit um ein Buch zu schreiben). Noch einen dritten eintragen? Aber was außer fl. 1940 hab ich als Info? --Wurgl (talk) 06:52, 5 May 2022 (UTC)[reply]

Von dem Jugendbuchautor Heinz Korn (Q111843879) sind zwei Titel (1941/42) in der DNB vorhanden. Ich habe den Fall auf WP:GND/F gemeldet, da es sich eventuell um ein Pseudonym handelt, s. Angabe: "Gruber, Heinz (Verfasser)" in DNB 580034763. --Kolja21 (talk) 15:08, 5 May 2022 (UTC)[reply]

Off-Topic: Ich hab heute wegen GND 1028026412 genörgelt. Da ist das falsche Seddin verlinkt. Richtig wäre 4403737-5 oder 4396853-3. Mal sehen. Quasi ein Zufallstreffer, mir war der Ort irgendwie bekannt. Später ist mir dann eingefallen, dass ich mit dem Ortsnamen schon einmal gekämpft hab. --Wurgl (talk) 16:24, 5 May 2022 (UTC)[reply]

Bei den Geografika bewundere ich eh dein Durchhaltevermögen. Die Zuordnung von Personen ist mir schon kompliziert genug. --Kolja21 (talk) 16:42, 5 May 2022 (UTC)[reply]

Ach da finde ich immer wieder nette Links, wie zum Beispiel de:Ii … den Namen finde ich doch etwas unterhaltsam. --Wurgl (talk) 18:37, 5 May 2022 (UTC)[reply]

Hallo Wurgl, hast du einen Überblick, welche der 528 Kandidaten aus der Liste de:Benutzer:APPER/VIAF bislang noch ohne Wikidata-Eintrag für den Namensvetter sind? Ich habe Friedrich Knorr (Q111906751), Autor von "Kaninchen Krankheiten" (1983), angelegt und würde gerne ein paar weitere Fälle abarbeiten. Anhand dieser Auswahl könnte man dann beim nächsten VIAF-Update sehen, ob der zweite Eintrag in Wikidata ausreicht, um die Cluster zu optimieren. --Kolja21 (talk) 21:18, 8 May 2022 (UTC)[reply]

Ich kann das auswerten und dort reinmalen. Mal sehen, wann ich dazu komme. --Wurgl (talk) 21:30, 8 May 2022 (UTC)[reply]

@Kolja21: War einfacher als gedacht. Kannst damit was anfangen? --Wurgl (talk) 22:09, 8 May 2022 (UTC)[reply]

Super. Dann mache ich mich mal an die Arbeit. --Kolja21 (talk) 22:22, 8 May 2022 (UTC)[reply]

Hey Wurgl, hier hast Du mir im Februar mal eine Liste aller damals gültigen GND-Identifikatoren aus dem GND-Dump extrahiert. Die Liste wurde seitdem nicht aktualisiert. Ist es aufwändig, das nach jedem Dump-Release einmal automatisiert aktualisieren zu lassen? Dankeschön und Viele Grüße! —MisterSynergy (talk) 13:02, 19 October 2022 (UTC)[reply]

Ich glaub, ich hab die damals zu Hause extrahiert und hochgeschubst. Hab ich eben nochmals gemacht. Irgendwas zum Automatisieren hab ich wohl angefangen, aber der Status … Dezember 2020 ist das mal gelaufen *kopfkratz* ist lange her. --Wurgl (talk) 14:27, 19 October 2022 (UTC)[reply]

Ist das denn überhaupt kompliziert? Das würde ich sicherlich auch selbst hinbekommen, nur bin ich nicht so ganz im Bilde wie der GND-Dump aufgebaut ist.

Für meinen Bot bräuchte ich nämlich solch eine "jederzeit aktuelle" Liste. —MisterSynergy (talk) 17:39, 19 October 2022 (UTC)[reply]

Die Ids rausfischen ist simpel. 57 Files (Personen, Geographika, etc.), grep und sed (bzw. einfach nur sed). Wenn du mehr willst, isses halt XML-File mit rekursiven Strukturen verarbeiten. authorities-sachbegriff_lds.rdf.gz aus https://data.dnb.de/opendata/ ist das kleinste, prinzipiell sind die anderen auch so aufgebaut nur die XML-Tags sind eben andere bzw. mehr. Diese XML-Tags sollte man halt irgendwie sinnvoll … tja … welche braucht man, welche nicht. Sind halt Platzfresser weil redundant. --Wurgl (talk) 17:46, 19 October 2022 (UTC)[reply]

Was mir fehlt ist im Grunde bloß das Wissen, welche Files ich anschauen muss und wie sie intern aufgebaut sind, sprich wo ich nach Identifikatoren suchen muss. Und ich muss da halt am Ball bleiben, was bei den ganzen anderen Aufgaben die ich hier habe nicht so einfach ist :-)

XML wäre jetzt nicht mein präferiertes Format, sondern eher irgendwas RDF-artiges. —MisterSynergy (talk) 17:55, 19 October 2022 (UTC)[reply]

Die haben 3 Formate. XML verwende ich. Die anderen hab ich nur kurz angestarrt und dann beiseite gelegt. --Wurgl (talk) 18:03, 19 October 2022 (UTC)[reply]

Das turtle-File sieht auch ganz nett aus. Wie lange brauchst Du, um alle Dump einmal durchzugehen? —MisterSynergy (talk) 18:13, 19 October 2022 (UTC)[reply]

Zeiten kann ich nicht genau sagen. Wenn ich die Access-Zeiten auf Linux (ls -lu) anstarre, dann wohl so 1,5 Stunden ohne Index-Erzeugung in C++ mit zwei Threads und sqlite als Datenbank, wobei ich ohne Index einfüge und erst am Ende die Indizes erzeuge. --Wurgl (talk) 18:42, 19 October 2022 (UTC)[reply]

Alright es sieht aus als haben wir vor vier Tagen neue Dumps bekommen. Würdest Du mir das noch einmal erneuern? Dankeschön und Viele Grüße! :-) —MisterSynergy (talk) 10:15, 8 November 2022 (UTC)[reply]

Ja, am Freitag gabs kaputte Daten, siehe de:Benutzer_Diskussion:Wurgl/Fehler_GND#November_2022 und gestern gabs dann (nach einer Nörgelmail meinerseits) eine Korrektur. Ist hochgeschoben. --Wurgl (talk) 10:20, 8 November 2022 (UTC)[reply]

Danke. Bist Du sicher, dass das jetzt auf dem neuen Dump ausgewertet wurde? Die Datei sieht nämlich identisch aus zu der, die Du bereits am 19. Oktober hochgeschoben hattest. —MisterSynergy (talk) 10:31, 8 November 2022 (UTC)[reply]

Ärks! Jetzt bin ich sicher. Sorry. --Wurgl (talk) 10:35, 8 November 2022 (UTC)[reply]

Dankeschön, sieht jetzt besser aus. —MisterSynergy (talk) 10:46, 8 November 2022 (UTC)[reply]

Hello there's a new notice at https://viaf.org/viaf/data/ explaining what is the reason behind the lack of updates... "We are working on VIAF security and production environment improvements to provide you with a better experience." Kudos to @Linda.jansova who found out what's going on. Vojtěch Dostál (talk) 14:30, 6 November 2024 (UTC)[reply]

Thanks! Seems to be a new message. --Wurgl (talk) 16:24, 6 November 2024 (UTC)[reply]

Hi Wurgl and @Kolja21: While there is an issue with the triggering of distinct-values constraint (Q21502410) violations, there is a larger issue with knowingly and intentionally adding incorrect identifiers to items with deprecated rank, performed in a single edit. According to Help:Deprecation, the two uses for deprecated rank are (1) superseded and (2) now known to be wrong, but were once thought correct. Those two use cases are not applicable to the following:

1. Michael Krebs (Q15445562) : A value for Library of Congress authority ID (P244) was added in a single edit with deprecated rank, qualified with applies to other person (Q35773207).
2. Robert Metcalf (Q1277425) and Robert A. Metcalf (Q130849769) : It perplexes me why the two identifiers that were knowingly incorrect and were intentionally added (here and here) with deprecated ranks and qualified with applies to other person (Q35773207) were retained on the original item, but the identifier that was incorrectly added in an automated edit from a batch was moved to the new item. The value for J9U ID (P8189) was the only claim organically added in error and therefore the only one for which the use of a deprecated rank would apply.
3. Dagmar Engel (Q1157268), Dagmar Engel (Q130754230), and Dagmar Engel (Q130754238) : The VIAF cluster 70924043 currently contains three external identifiers, corresponding to three separate individuals, each of whom now have a Wikidata item. Because that current cluster is equally shared by those three individuals, wouldn't it therefore follow the practice of intentionally adding deprecated identifiers to add all three identifiers to all three items, deprecating the two non-applicable ones on each item (something that I am not suggesting be done)? Especially given that one of those identifiers was intentionally added with deprecated rank to the original existing item, by another editor, within 24 hours prior to the creation of the subsequent items.
4. Měnín (Q1639245) and Menen (Q213224) : A value for P244 was added to the first item with deprecated rank, followed by the addition of the same property value to the second item just two minutes afterward.
5. Special:Diff/1627219778
6. Special:Diff/1295301120
7. Special:Diff/1221976983
8. Special:Diff/1415778745
9. Special:Diff/1297345079

-- Dcflyer (talk) 03:28, 8 November 2024 (UTC)[reply]

I'm not sure about your interpretation. Michael Krebs (Q15445562) = VIAF:310637970 = LCAuth no2009168468 = case (2) LCAuth now known to be wrong. I'm not insting on adding the LCAuth with deprecated rank but how do you want to make sure that no bot and no user is adding the wrong LCAuth? How we avoid that the VIAF cluster needs to be checked again and again trying to find out why the cluster might be or might have been conflated? Imho the best way is - like Wurgl has done in this case - to create an item for LCAuth no2009168468 = Michael Krebs (Q130901082) and hope that VIAF will fix the conflation. --Kolja21 (talk) 03:53, 8 November 2024 (UTC)[reply]

PS: If you take a look at de:Benutzer:APPER/VIAF you see the efforts Wurgl, with the help of others, make to clean up mixed VIAF clusters. --Kolja21 (talk) 03:59, 8 November 2024 (UTC)[reply]

@Kolja21, could you please explain the rationale and logic behind number 2 above (Robert Metcalf)? And the item for Michael Krebs was just one example out of nine. Thanks. -- Dcflyer (talk) 04:32, 8 November 2024 (UTC)[reply]

And the LCAuth for Michael Krebs was known to be wrong when it was added, in a single edit with deprecated rank, qualified with applies to other person (Q35773207). The item's VIAF ID (P214) is deprecated as conflated, so it's unlikely that a bot would add any external identifiers from that cluster. -- Dcflyer (talk) 04:44, 8 November 2024 (UTC)[reply]

Are you joking? It's not only unlikely it happens daily. We have plenty of tools and bots that can't read rankes. KrBot even edits overwrites VIAF marked with deprecated rank. I don't have time to research who made which edit in all nine cases but I've created a GND for the entomologist Robert A. Metcalf. Imho we should not discuss the interpretation of the rules. Instead we should try to find out what is the best way to deal with conflated VIAF clusters. --Kolja21 (talk) 04:53, 8 November 2024 (UTC)[reply]

No, I am not joking.

Please see WD:AGF. -- Dcflyer (talk) 05:03, 8 November 2024 (UTC)[reply]

Exactly as described by Kolja21, it is sadly a reality. When simple removing some identifier from an item and marking the viaf as conflation, some weeks or month later a bot or a new user happily adds that identifier again. Maybe the user gets locked later, but the edits get not removed.

Tell me some way to break that circle with VIAF copying data from Wikidata and other sources into their clusters and later users copying that data from VIAF back into Wikidata? It works fine (for me) when a block that 2nd step by marking those items as deprecated.

Before I did it in this way, I had many items where the same wrong identifier was added again and again. --Wurgl (talk) 06:57, 8 November 2024 (UTC)[reply]

An Example where I am not involved: San Rocco (Q47125153): church in Prezza, Italy (some raw output from the database, Timestamp<Tab>user<Tab>change comment)

• 20190310121715 Thisismattmiller /* wbcreateclaim-create:1| */ Property:P244: nb2007001450, #quickstatements; batch #9029 by Thisismattmiller
• 20190311130147 Pietro /* wbremoveclaims-remove:1| */ Property:P244: nb2007001450
• 20190312035406 Thisismattmiller /* wbcreateclaim-create:1| */ Property:P244: nb2007001450, #quickstatements; batch #9102 by Thisismattmiller
• 20190312035408 Thisismattmiller /* wbsetreference-add:2| */ Property:P244: nb2007001450, #quickstatements; batch #9102 by Thisismattmiller
• 20191120134220 Pietro /* wbremoveclaims-remove:1| */ Property:P244: nb2007001450
• 20240905181359 ISNIplus /* wbcreateclaim-create:1| */ Property:P244: nb2007001450, batch #237147
• 20240905181400 ISNIplus /* wbsetreference-add:2| */ Property:P244: nb2007001450, batch #237147

nb2007001450 is about a church in Inzago which is close to Milan, Q47125153 describes a church in Prezza, Italy (prezza is in the east of Rome)

Now you can remove that ID a third time. Another bot or script will come and happily add it. If you mark it as deprecated, the bot/script will never touch it again. --Wurgl (talk) 17:28, 9 November 2024 (UTC)[reply]