Morgen MisterSynergy, in Wikidata gibt es offenbar immer noch Tns, die, selbst wenn sie mit "deprecated rank" gekennzeichnet sind, als individualisierte Datensätze interpretiert werden. Weißt du, wann es den letzten Botlauf gab, um Tns aufzuspüren?
Topic on User talk:MisterSynergy
Morgen. Das dürfte schon ein bisschen her sein. Ich habe das mal eine Weile mit den Abfragen unter User talk:Jneubert#Queries gemacht, die aber nicht mehr laufen. Soweit ich weiß, sind die Tns auch nicht mehr Teil der GND, richtig?
Ja, seit Juli 2020 sind die Tns offiziell nicht mehr Bestandteil der Gemeinsamen Normdatei. Alle Titel wurden entlinkt. In VIAF sind sie mittlerweile auch nicht mehr enthalten. Laut Wikidata:WikiProject Authority control/Tn fand der letzte Botlauf im Juni 2018 statt, aber eventuell wurden auch später noch Tns per Bot gelöscht, ohne dass die Löschung dokumentiert wurde.
Sind die (ehemaligen) Tns denn noch irgendwo GND-seitig dokumentiert?
Die alten Datensätze lassen sich noch aufrufen (Beispiel: Tn 154405787), aber man sieht leider nicht mehr, welche Titel einst verknüpft waren. Hilfreich sind allerdings die Schreibvarianten, die in den Tns genannt werden, vor allem wenn die Namen transkribiert wurden. Deswegen haben wir sie auch in deWP nicht per Bot aus der Normdatenvorlage entfernt, sondern arbeiten sie von Hand ab.
Hmm, beim Query Endpoint von User:Jneubert sind die Tns offenbar nicht mehr enthalten.
Ich müsste irgendeinen Zugangspunkt finden, wo ich die ehemaligen Tns abrufen kann. Das Format ist eigentlich relativ egal. Dann könnte ich das mit dem Bestand in Wikidata abgleichen und Dir eine Arbeitsliste zusammenstellen.
Kannst du umgekehrt vorgehen und eine Liste erstellen, die alle in Wikidata eingetragenen IDs, die nicht in der aktuellen GND-Liste verzeichnet sind, enthält? Das müssten dann Tns und Verwechlungen mit anderen Katalognummern sein. @Wurgl: Hast du einen Tipp?
Hmm, den letzten (oder vorletzten) Dump der Tns vom März 2020 hab ich hier rumliegen. 374.601.910 Bytes als gzip. Ich kann dir auch einfach eine Liste von Ids erstellen (7.032.817 Stück), allerdings ist es in beiden Fällen durchaus möglich, dass in der Zwischenzeit aus einem Tn ein Tp wurde, das müsste man in einem zweiten Schritt (Zugriff auf die Webseite) filtern. Im Dump sind 7.046.133 Tns, in meiner Datenbank nur 7.032.817, die Differenz von 13.316 sind wohl so umgewandelte, aber nur die bis Nov. umgewandelten, neueren Dump der DNB gibt es nicht.
Wenn Du mir einen Link zu Deinem Tn-Dump gibst, schaue ich mir das heute Abend mal genauer an.
9 GB rohes RDF. Lovely.
Naja, es gibt ja Parser für alles mögliche… :-D
Danke euch beiden! Mich interessiert vor allem die Größenordnung. Wenn es weniger als hundert Fehler sind, arbeite ich die Liste gerne von Hand ab.
Die VIAF hat im aktuellen Dump nur diesen einzigen und einsamen Datensatz, wo ein (damaliger) Tn verknüpft ist: https://viaf.org/viaf/43441528/ Und der ist eine Weiterleitung auf einen Tp, also kein sichtbarer Effekt: http://d-nb.info/gnd/10353251X ⇒ https://d-nb.info/gnd/105567375X Wikidata ist nicht verknüpft, hat also nix damit zu tun.
Auf diese Art ist also nix zu finden.
Wurgl, die Datei ist in bisschen groß fürs schnelle Extrahieren mit meinen bereits vorhandenen Skripten. Hast Du auch eine direkte Liste von Tn-Identifikatoren, so dass ich das nicht erst neu zusammenbasteln muss? Dann würde ich die direkt nehmen und die RDF-Datei erstmal beiseite lassen.
https://persondata.toolforge.org/data/Tns.txt.gz Simpelstes Textformat Profi-Tipp: Mit Ping reagiere ich schneller
Danke, das ist auf die Schnelle tatsächlich einfacher.
Hier ist nichts eilig, ich kann eh meist nur kurz reinschauen und brauche keine zügige Antwort. Allerdings bekommst Du doch eigentlich sowieso eine Notification, wenn hier Aktivität im Topic ist – oder?
In den globalen Einstellungen hab ich einen Haken bei "Diskussionsseiten-Abonnement", der wirkt sich wohl nur auf diese neue Antworten-Funktion aus, nicht hier auf diese "andere" Art der Diskussionsseite. Jedenfalls hab ich da einmal so als Test aktiviert und dann gabs einen blauen Knubbel. Hier passiert nix.
Hab ma geforscht. Da scheinen ja Schlaumeier am Werk zu sein. Wenn ich hier auf "globale Einstellungen" gehe, dann sehe ich "Strukturierte Diskussion" als Ankreuzpunkt. Wenn ich die Einstellungen in deWP aufmache und dort auf "globale Einstellungen" gehe, dann gibt es den Punkt "Strukturierte Diskussion" nicht, daher hab ich dort auch keinen Haken. Woher soll ich als hauptsächlicher deWP-user auch wissen, dass es hier andere globale Einstellungen gibt. Irgendwie muss ich da an die Multiversen denken, analog sind hier Multigloben oder sowas. Haken gesetzt, jetzt ist der Pro-Tipp obsolet und ich werde in de:WP:TWS mal nörgeln.
Ah, interessant. Mir ist es längst in Fleisch und Blut übergegangen, dass ich für Antworten (und neue Topics auf Seiten, die ich beobachte) Wikimedia-weit benachrichtigt werde. Sehr praktisch.
Problem könnte sei, dass dewiki die "Structured Discussions" (formerly known as "Flow") überhaupt nicht hat. Es gab da mal eine Diskussion im Kurier, danach war die Einführung praktisch vom Tisch. Leider.
Ich hab mal, wie angekündigt, genörgelt: de:Wikipedia:Technik/Werkstatt#Die_nichtglobalen_"Globalen_Einstellungen"
Und ja, die Ursache wird wohl die Nichtaktivierung diverser Features/Extensions sein. Das ist aber ein rein technischer Aspekt, der ist lösbar. Benutzerfreundlich ist das nicht.
So, ich habe jetzt den Bestand mit dem Tn-Dump abgeglichen. Da lassen sich 2699 Identifikatoren finden, die wahrscheinlich eine Tn sind und nicht missbilligten Rang haben.
User:Kolja21, das sind vermutlich zu viele für händisches bearbeiten – richtig? Wenn ich da einen Bot mache, entferne ich dann lieber diese Aussagen, oder stelle ich den Rang auf missbilligt? Wenn ja, soll ein entsprechender Qualifikator dazu?
Nachtrag: das entsprechende Skript und die Ergebnisliste sind auch öffentlich abrufbar.
So 10 Stück aus der Liste (nicht die ersten, sondern einfach ein paar) hab ich geguckt, alle Tn ("Status: Datensatz ist nicht mehr Bestandteil der Gemeinsamen Normdatei (GND)"). Sieht gut aus.
Das sind mehr Tns als ich befürchtet hatte. Bislang wurden nur die Listen dokumentiert und anschließend die Platzhalter per Bot entfernt:
- Wikidata:WikiProject Authority control/Tn
User:KasparBot/GND Type N(erl.)
Mit Rängen zu arbeiten (Grund für die Zurückweisung: fehlerhafter Wert des Identifikators = Q54975531) ist keine schlechte Idee, macht aber vermutlich zu viel Arbeit. Man bräuchte wiederum eine Liste, in der diese Fälle aufgeführt sind, müsste anschließend die Einträge löschen, in denen bereits eine GND vorliegt etc.
PS: Mit Rängen zu arbeiten, hätte allerdings den Vorteil, dass wir die Arbeit in Wikipedia und Wikidata zusammenlegen könnten. Was haltet ihr von der Idee, die Tns aus Wikipedia nach Wikidata zu exportieren und in Wikipedia zu löschen? Das würde die de:Kategorie:Wikipedia:GND fehlt entlasten, ohne das Informationen verloren gehen.
Mit Personen mach ich nicht so viel herum, da sind eher Silewe, Miebner etc. gefragt, vielleicht in deWP bei de:Hilfe Diskussion:Normdaten ansprechen?
Das mit dem Export war nur eine spontane Idee. Ich will kein großes Fass aufmachen. Erst mal sollten wir die Frage klären, wie wir in Wikidata vorgehen: Tns löschen oder die ehemaligen Platzhalter mit "missbilligter Rang" kennzeichnen?
Ich tendiere zu rauswerfen. hab mir ein paar angeguckt, gefühlt 30% sind per Batch eingetragen, die anderen von mir total unbekannten Benutzern, somit wohl nicht aus deWP
Tja und ich wäre für den missbilligten Rang. Der vermeidet einigermaßen, dass das erneut importiert wird und macht die Zuordnung weiter verfügbar.
Ich könnte auch einen Bot anbieten, der das täglich oder wöchentlich einmal glattzieht (oder einen Report schreibt). Tn-Verwaltung ist nicht besonders komplex, das kann und sollte automatisiert werden um die wertvollen manuellen Edit-Kapazitäten für wirklich wichtige Sachen zurückzuhalten. Davon gibt es bei der GND-Verwaltung ja genug zu tun.
Erneutes Importieren wird es nicht geben weil es die Ids nicht mehr gibt. Es wird auch kein Dump der Tns mehr zur Verfügung gestellt, dieses Dumpfile oben ist vom März 2020, danach gabs das nicht mehr, du findest diese Datensätze auch ausschließlich mit der ID.
Ok, klingt überzeugend. Dann also: Liste nach Wikidata:WikiProject Authority control/Tn kopieren und die Tns per Bot löschen. Ideal wäre, wenn jemand die Zeit findet, die alten und neue Tn-Listen im Stil von Wikidata:WikiProject Authority control/Tn#Feb 2015 list zusammenzufassen, aber das eilt nicht.
Oh, ich war zu langsam ... Habe die neuen Beiträge noch nicht gelesen.
Mein Vorschlag: Wer immer die Arbeit übernimmt, kann entscheiden, welche der beiden Vorgehensweisen er bevorzugt. Die Tns sind einerseits überflüssig und störend, andererseits helfen die Namensvarianten, die dort dokumentiert sind, in manchen Fälen bei der Recherche. Nachdem die Fälle von Hand überprüft wurden, sollten die Tns allerdings endgültig gelöscht werden, so wie wir es auch in Wikipedia handhaben.
Wir haben auch abseits von diesen ~2700 Fällen noch etwas über 2000 weitere, die bereits missbilligten Rang haben: https://w.wiki/4pgH.
Ich würde die 2700 Fälle erstmal dazu tun, damit das weiter zugänglich ist. Nach außen sind diese missbilligten Identifikatoren für Datennutzer kaum sichtbar, das wäre echt für interne Zwecke so abgelegt.
Importe können halt aus diversen Quellen vorgenommen werden, wo die alten Tns irgendwie noch zugeordnet sind.
Wenn wir das zeitlich eng getaktet überwachen, sollte das aber nicht wieder so aus dem Ruder laufen und damit in Zukunft hoffentlich kein Problem mehr sein. Oder?
Perfekt! An der Abfrage gefällt mir vor allem die Spalte "Reason for deprecation". Mit Wikidata Query Service kann man besser arbeiten als mit den Listen. - Nochmal herzlichen Dank für deine Mühe.
Hier ist noch eine korrigierte Version der Abfrage: https://w.wiki/4pgW.
Die erste Version hat eventuelle Import-Referenzen mit imported from Wikimedia project (P143) nicht richtig hinbekommen.
So, ich habe jetzt einen Bot, der diese Aussagen auf missbilligten Rang setzt und den reason for deprecated rank (P2241)-Qualifikator mit Wert incorrect identifier value (Q54975531) ergänzt. Beispieledits sind hier.
Das Skript macht einen Lookup jedes zu verändernden GND-Identifikators über User:Jneubert's SPARQL-Endpoint bei der ZBW, um zu verifizieren dass es sich tatsächlich nicht mehr um einen in der GND enthaltenen Identifikator handelt. Das Skript ist dasselbe wie bereits zuvor verlinkt.
Soll ich das erstmal so einmal durchlaufen lassen für die ~2700 Fälle?
Ja gerne! Die drei Beispiele sehen gut aus. Das macht dann insgesamt ~4770 Fälle. Ich vermute, es werden in Zukunft nicht mehr viele hinzukommen; zumindest was die Tns betrifft. Mit deiner Abfrage (w.wiki/4pgW) lässt sich das dann leicht überprüfen.
So, der Rückstau an abzuarbeitenden Fällen ist erstmal erledigt. Zumindest nach Wurgl's Liste sind zurzeit keine Tn's mehr in Wikidata mit nicht-missbilligtem Rang.
Zwei Sachen noch:
- Man könnte sicherlich diverse andere Sachen auch automatisiert managen. Wenn jemand zum Beispiel eine Liste aller zurzeit gültigen GND-Identifikatoren auftreiben kann, können wir gut abgleichen, was wir sonst so für ungültige GNDs haben. Auch die Sache mit den Weiterleitungen könnten wir weiter automatisieren. Mehr Ideen sind willkommen – über den SPARQL-Endpoint der ZBW können wir wirklich vieles abgleichen.
- Außerdem sollten wir das regelmäßig und automatisiert glattziehen. Ich kann dazu einen Bot anbieten, mit Task-Bewilligung und regelmäßiger, zum Beispiel täglicher Aktualisierung. Dann könnten wir die wertvolle manuelle Editierarbeit für die wirklich komplizierten, nicht-automatisierbaren Fälle reservieren.
Meinungen?
Also eine Liste der Gültigen kannst haben. Kein Problem.
ABER: Die Dumps der GND gibts nur alle 4 Monate und in der Zeit seit dem letzten Dump (mindestens sind das zwei Tage) werden IDs neu angelegt, du müsstest bei den Dump-Unbekannten also prüfen, was die Webseite murmelt. Wobei ich bei angelegten Weiterleitungen (der GNDs, nicht die bei uns) nicht ganz sicher bin, ich glaub die liefern auch eine gültige Webseite (das Weiterleitungsziel) aus.
https://persondata.toolforge.org/data/GNDs.txt.gz 9.035.300 Einträge
Danke, ich schau es mir mal an. Von wann ist der letzte Dump?
Insgesamt haben wir zwar immer "tausende" Fälle zu bearbeiten, aber das kann man ganz gut abgleichen. Hab ich mit den "potentiellen" Tns ja auch gerade so gemacht. Einfach blind bearbeiten wäre sicherlich nicht so schlau.
https://data.dnb.de/opendata/ bzw. 23. November
Weiterleitungen wurden früher schon mal automatisiert umgebogen, dabei aber leider die Fundstelle und das Abfragedatum beibehalten. Bei Personen (GND, Typ p) ist das nicht so problematisch (es gibt keine Vorgänger und Nachfolger und ein meist eindeutige Zuordnung), aber bei Geografika, Werken und Sachbegriffen geht das schnell schief und es gab einiges Chaos.
Bei Weiterleitungen würde ich nicht auflösen, sondern erstmal einen entsprechenden Qualifikator ergänzen sowie – sofern gewünscht – einen einheitlichen Rang einstellen.
Wurgl, haben wir auch alle GND-Weiterleitungen irgendwo schnell abrufbar?
Zu Weiterleitungen hab ich kein Dump-File, ich weiß nichtmal ob es eines gibt.
Fürchte dann muss ich doch mal irgendeinen Dump durchparsen. Beim SPARQL-Endpoint kann man das zwar grundsätzlich abfragen – aber es gelingt mir nicht, alle Weiterleitungen in einer Abfrage zu bekommen; offenbar sind es zu viele.
Mach' dir nicht zu viel Arbeit. Mit den Tns sind wir schon mal einen riesigen Schritt weiter. (Danke noch mal!) Wenn eine Weiterleitung vorliegt, gibt es in der Regel zwei oder mehr GND-Einträge, die dann in div. Fehlerlisten auftauchen.
Übrigens: Ein Botauftrag, der noch offen ist, betrifft die Vereinheitlichung von Qualifikatoren. User:Emu hatte darauf hingewiesen, dass einheitlich named as (P1810) verwendet werden sollte. Der Botlauf wurde genehmigt, aber nicht vollständig ausgeführt, siehe Wikidata talk:Requests for permissions/Bot/AmmarBot.
Das ist eigentlich nicht so viel Arbeit. Ich will zurzeit eh mal wieder was nicht-administratives hier machen, was zuletzt viel zu kurz gekommen ist. Der Admin-Kram ist nämlich mit Sicherheit nicht der spaßige Teil der Beteiligung an diesem Projekt hier.
So, erstmal zu den GND-Weiterleitungen: ich glaube, ich habe die nun beim GND-SPARQL-Endpoint extrahieren können. Demnach haben wir zurzeit wohl keine einzige gültige GND, die hier per reason for deprecated rank (P2241)-Qualifikator als Weiterleitung markiert ist (gut!); andersherum sind aber etwas über 1300 GND-Weiterleitungen hier nicht als solche identifiziert, und häufig auch nicht mit dem missbilligten Rang ausgestattet. Ich würde anbieten, per Bot…
- … den entsprechenden Qualifikator zu ergänzen
- … den Rang auf missbilligt setzen
- … das GND-Weiterleitungsziel mit normalem Rang zu ergänzen, sofern nicht vorhanden
Stößt das auf Zustimmung?
Das sollte auch fertig sein. Alle GND-Weiterleitungen haben nun missbilligten Rang, den entsprechenden Qualifikator, und dazu ist das Weiterleitungsziel ebenfalls als Aussage (mit normalem oder bevorzugtem Rang) vorhanden.
Dann zu darüberhinaus ungültigen GNDs: davon finde ich zurzeit rund 800. Was das sein kann:
- Neuerer Identifikator, der im Dump beim GND-SPARQL-Endpoint noch nicht enthalten ist (i.e. eigentlich doch gültig)
- Fehlnutzung von GND ID (P227) anstelle von DNB editions (P1292)
- Sonstiger Fehler
Diese Liste braucht vermutlich manuelles Abarbeiten. Soll ich sie mal irgendwo hinspeichern zum genaueren Untersuchen?
Wikidata:WikiProject Authority control/GND (Rotlink) wäre der passende Ort. Aber eine 800er-Liste ist zu lang. Zumindest weiß ich nicht, wer sie abarbeiten sollte. Ich würde vorschlagen, fehlerhafte IDs mit fehlerhafter Wert des Identifikators (Q54975531) zu kennzeichnen, dann können wir sie zusammen mit den Tns abarbeiten. - Was die Verwechslung DNB/GND betrifft, wäre es natürlich schön, wenn das ein Bot automatisch umstellen könnte. Und zu den neuen IDs, die noch nicht im Dump enthalten sind: Diese müssten leicht auszuschließen sein. Beispiel: GND 1252137834 wurde am 18.2. angelegt. Alle IDs, die danach kommen, werden vorerst als korrekt akzeptiert.
Ja da mache ich mich als nächstes dran. Einen Teil davon kann ich sicherlich irgendwie automatisieren mit diversen Crosschecks zur Sicherheit. Eine Arbeitsliste für manuelles Abarbeiten macht wohl eher erst danach Sinn.
Zuletzt die Sache mit den named as (P1810)-Qualifikatoren: das ist auch per Bot recht einfach zu erledigen und sowas (in der Art) hab ich schon häufiger gemacht. Wenn es keine Einwände gibt, dann würde ich das mal zeitnah erledigen.
Es gibt allerdings eine handvoll Fälle, bei denen bereits beide Qualifikatoren vorhanden sind, zum Teil mit verschiedenen Strings. Die wären lieber händisch abzuarbeiten: https://w.wiki/4rfC
Die "handvoll Fälle" sind abgearbeitet. Du kannst den Bot anwerfen.
Der Bot ist durch, alle Qualifikatoren sind umgestellt.
Mit den "ungültigen" würde ich sagen: Warte bis Mitte/Ende März, dann sollte ein neuer Dump kommen und da sind dann nicht 800 zu prüfen, sondern vielleicht 50.
Sonst: Per curl die Dinger einzeln abklopfen. Bei ungültigen kommt eine leere Seite mit Status 404. Beispiel: https://d-nb.info/gnd/6136814-2 (-3 ist gültig). Bei gültig kommt Status 303
Ich fang mal bei dem letzten Punkt an, die Sache mit den named as (P1810)-Qualifikatoren. Gerne, das ist, soweit ich sehe, unstrittig. (Die andere Punkte schaue ich mir morgen an.)
Danke schon mal!
Was mich in dem Zusammenhang noch interessiert: Wie viele GNDs für Personen, bei denen Lebensdaten und Beruf bekannt sind, sind bislang noch nicht in Wikidata erfasst? Bislang wurden nur 15% der GNDs importiert. Um Dubletten zu vermeiden, können man vor dem Import abgleichen, ob bereits ein Objekt mit dem passenden VIAF-Cluster vorhanden ist. Diese Fälle müssten von Hand bearbeitet werden. Alle anderen GNDs könnte man per Bot importieren.
Ich habe mir das jetzt angeschaut. Ich finde im (derzeit jüngsten) GND-Dump von Oktober 2021 insgesamt ~5.65 Millionen Personen mit GND-Identifikator; ~1.90 Millionen davon haben sowohl ein Geburtsdatum und einen Beruf in GND angegeben; davon wiederum sind ~721.000 mit einem Wikidata-Objekt ausgestattet; entsprechend "fehlen" noch 1.18 Millionen.
Klingt das plausibel?
Ja, das kann hinkommen. Wenn man aus den 1,18 Millionen jene Datensätze rausfiltert, die über VIAF in Wikidata erfasst sind, bleibt immer noch ein beachtlicher Rest. Spricht etwas dagegen, diese GNDs per Bot zu importieren?
Ich schaue morgen mal, ob das besser abschätzbar ist. Die VIAFs sind ja auch im GND-Dump vermerkt, da müsste ich schonmal vorab etwas besser abgleichen können.
Die VIAF in der GND ist schön, aber nix immer aktuell.
Du kannst aber (zumindest für Personen) live übersetzen:
Zu https://viaf.org/viaf/sourceID/DNB%7C106181243X bekommst du einen 301er und ein Redirect auf http://viaf.org/viaf/220908876 Dem Redirect brauchst nicht zu folgen, der enthält schon die VIAF.
Das geht aber nicht für andere Datensätze, wo diese PPN (oder wie sich das nennt) als Local_Authority_ID verwendet wird, zum Beispiel bei manchen/vielen Geographika geht das nicht.
Das kennst du? https://www.oclc.org/developer/api/oclc-apis/viaf/authority-cluster.en.html
Sonst gibt es am Anfang jeden Monats auf http://viaf.org/viaf/data/ ein File wie viaf-20220207-links.txt.gz (das Datum ändert sich). Dort sind die Zuordnungen zwischen VIAF und den Bibliotheken zu finden (die Reihenfolge scheint undefiniert zu sein, das macht Probleme wenn mehrere Datensätze einer Bibliothek verlinkt sind) http://viaf.org/viaf/100109330 DNB|116991992 http://viaf.org/viaf/100109330 DNB@http://d-nb.info/gnd/116991992 Die erste der beiden Zeilen (die mit dem Pipe) gibt es (fast) immer und (fast) für jede Bibliothek. Die zweite gibt es bei den Bibliotheken, wo manchmal (oder immer) der Link unterschiedlich zur ID ist: z.B. DNB oder BNF, dummerweise gibts diesen Zweiten mit @ nicht bei allen VIAF-DNB-Zuordnungen, weiß der Geier warum. Zu den einzelnen Wikis (kommt wohl aus Wikidata und zu Worldcat gibts nur den Link mit dem Klammeraffen).
Beispiel wo es nur den Link mit | gibt: Online: https://viaf.org/viaf/2157222576684970374/ beachte: kein Link unter dem DNB-Icon! http://viaf.org/viaf/2157222576684970374 DNB|1197308210
Beispiel eines Geographikums mit unterschiedlicher ID in der Pipe- und @-Zeile http://viaf.org/viaf/154251299 DNB|040570924 http://viaf.org/viaf/154251299 DNB@http://d-nb.info/gnd/4057092-7
Diesen Dump schaue ich mir erstmal an. Hier geht es um viel zu viele IDs als dass man sie individuelle abfragen könnte.
Wundere dich nicht. Die VIAF liefert die Daten recht langsam aus. Ist nicht deine Verbindung, die klemmt.
Es gibt auch den kompletten VIAF-Dump, aber der Download würde ziemlich ewig dauern (mein Browser lügt was von knapp 10 Studnen), da verzichte ich gerne darauf.
So, ich hatte ein bisschen Zeit und hier geht es weiter:
Von den weiter oben erwähnten 1.18 Millionen Tps, die in der GND Geburtsdatum und Beschäftigung angegeben haben und die in Wikidata noch fehlen, ist die zugeordnete VIAF-ID in ~157.000 Fällen in Wikidata verfügbar (per Februar-Mapping von VIAF.org). Hier wäre zu prüfen, inwiefern die GND ebenfalls importiert werden kann. Auf der anderen Seite sind bei 1.027 Millionen Fällen weder die GND noch ihre zugeordnete VIAF-ID hier bei Wikidata zu finden; das ist in meinen Augen viel zu viel, um es einfach so zum Zwecke der Vollständigkeit zu importieren.
Klingt viel, aber was die Vollständigkeit betrifft, wäre ein Import zu begrüßen. Bislang wurden vor allem Wissenschaftler, die in der 2. Hälfte des 20. Jhs. geboren wurde, per Massenimport in Wikidata eingetragen (ORCID, Mathematics Genealogy Project etc.). In der GND sind aber bekanntlich Personen aus allen Berufsgruppen seit der Antike erfasst. Man muss nicht alle GNDs auf einmal importieren, sondern könnte sich eine Gruppe heraussuchen (Beispiel: Franzosen aus dem 19. Jh.). In zwei, drei Monaten kann man dann überprüfen, ob sich der Import der Testgruppe gelohnt hat.
Das müsste trotzdem zunächst per Bot-Task und ggf. auch im Project chat diskutiert werden. 1M neue Datenobjekte sind ~1% der aktuellen Größe von Wikidata – das ist durchaus signifikant.
Zu beachten ist auch, dass nicht mehr angestrebt wird, einfach alle verfügbaren Daten zu importieren – der Trend geht zu verteilten Linked-Data-Instanzen, die per federated queries abgefragt werden. Die GND ist in der Hinsicht eigentlich schon gut aufgestellt, wenngleich die sich sicher auch noch ausprobieren. Es hat sich seit einiger Zeit herauskristallisiert, dass die Software hinter Wikidata aus sehr grundsätzlichen Gründen nicht so skaliert, dass man hier einfach alles importieren könnte.
Ich bin auch etwas skeptisch, ich habe noch immer nicht den Eindruck, dass wir die GND-Massenimporte im Nummernbereich Q94… und Q95… besonders gut verdaut haben. Andererseits fallen mir immer wieder Fälle auf, bei denen wir kein Wikidata-Item haben, obwohl die Personen recht relevant sind, aber aus irgendwelchen Gründen noch keinen Artikel in den Wikipedien bekommen haben und auch nicht in einer Importaktion hereingeholt wurden.
Man könnte die Vermutung anstellen, dass ein gut ausgebauter GND-Datensatz tendenziell für eine herausgehobene Relevanz spricht (der Umkehrschluss ist nicht zulässig). Könnte man vielleicht daran denken, eine Gruppe von besonders gut ausgebauten GND-Datensätzen nach Wikidata zu importieren? @MisterSynergy Gibt es eine einfache Möglichkeit, solche besonders gut ausgebauten Datensätze herauszufiltern?
Nur mal so: Im Dump hast du keine Info auf die zugeordneten Werke …
Ja – im Grund machen wir das hier schon, indem wir auf Personen mit Geburtsdatum und Beschäftigung eingrenzen. Man könnte noch mehr Kriterien einschließen, was die Zahl der möglicherweise zu importierenden Datenobjekte dann natürlich reduziert.
"Zeitüberschreitungsgrenze erreicht": Kann es sein, dass die Abfrage https://w.wiki/4pgW zu groß geworden ist (result: 6843 items)? Ich kann sie im Moment nicht mehr aufrufen. Anders gefragt: Würde es helfen, wenn du sie aufspaltest?
Scheint hier zu laufen. Die Abfrage dauert sicherlich recht lange (über eine halbe Minute hier), aber im Zweifel hilft es, sie einfach noch einmal auszuführen.
Nur zur Info: Am Wochenende habe ich im GND-Endpoint die aktuelle Version des GND-Dumps (2021-11) eingestellt, auf einer anderen Maschine, mit fuseki-4.5.0-SNAPSHOT und TDB2. Falls sich für eure Nutzung etwas geändert hat, lasst es mich gerne wissen.
Bei den Weiterleitungen gibt es ein Problem mit musikalischen Werken: "GND identifier 7656167-7 redirects to 118742973." Das stimmt leider nicht: Das Werk ist nicht der Komponist. Der Gewinnerdatensatz ist GND 300410581 aus dem Altbestand des Deutschen Musikarchivs (DMA). @Wurgl Du hast das Problem auf deWP gelöst. Wie hast du die korrekte Weiterleitung gefunden? @MisterSynergy Kannst du feststellen, welche Botedits betroffen sind?
Hülfe! Das hab ich vor 3-4 Jahren getippt. Kann ich jetzt nicht so schnell sagen.
Das hier ist das Record in authorities-werk_lds.rdf.gz
<rdf:Description rdf:about="https://d-nb.info/gnd/300410581">
<rdf:type rdf:resource="https://d-nb.info/standards/elementset/gnd#MusicalWork"/>
<wdrs:describedby>
<rdf:Description rdf:about="https://d-nb.info/gnd/300410581/about">
<dcterms:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/"/>
<dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2021-01-20T00:30:32.000</dcterms:modified>
</rdf:Description>
</wdrs:describedby>
<gndo:gndIdentifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string">300410581</gndo:gndIdentifier>
<owl:sameAs rdf:resource="http://viaf.org/viaf/204590341"/>
<owl:sameAs rdf:resource="http://www.wikidata.org/entity/Q47006462"/>
<gndo:oldAuthorityNumber rdf:datatype="http://www.w3.org/2001/XMLSchema#string">(DE-588)7656167-7</gndo:oldAuthorityNumber>
<owl:sameAs rdf:resource="https://d-nb.info/gnd/7656167-7"/>
<dnbt:deprecatedUri rdf:datatype="http://www.w3.org/2001/XMLSchema#string">https://d-nb.info/gnd/7656167-7</dnbt:deprecatedUri>
<gndo:oldAuthorityNumber rdf:datatype="http://www.w3.org/2001/XMLSchema#string">(DE-588c)7656167-7</gndo:oldAuthorityNumber>
<gndo:oldAuthorityNumber rdf:datatype="http://www.w3.org/2001/XMLSchema#string">(DE-101c)300410581</gndo:oldAuthorityNumber>
<gndo:variantNameForTheWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Anthems, Z 58C</gndo:variantNameForTheWork>
<gndo:variantNameForTheWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thou know'st, Lord</gndo:variantNameForTheWork>
<gndo:variantNameForTheWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thou know'st, Lord, Z 58C</gndo:variantNameForTheWork>
<gndo:variantNameForTheWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Funeral anthem of Queen Mary</gndo:variantNameForTheWork>
<gndo:variantNameForTheWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thou know'st, Lord Z 58C</gndo:variantNameForTheWork>
<gndo:preferredNameForTheWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thou knowest, Lord, the secrets of our hearts</gndo:preferredNameForTheWork>
<gndo:firstComposer rdf:resource="https://d-nb.info/gnd/118742973"/>
<gndo:formOfWorkAndExpression rdf:resource="https://d-nb.info/gnd/4142618-6"/>
<gndo:thematicIndexNumericDesignationOfMusicalWork rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Z 58C</gndo:thematicIndexNumericDesignationOfMusicalWork>
<gndo:gndSubjectCategory rdf:resource="https://d-nb.info/standards/vocab/gnd/gnd-sc#14.4p"/>
<gndo:geographicAreaCode rdf:resource="https://d-nb.info/standards/vocab/gnd/geographic-area-code#XA-GB"/>
<gndo:biographicalOrHistoricalInformation xml:lang="de">Trauermusik für Queen Mary, 1695</gndo:biographicalOrHistoricalInformation>
<gndo:biographicalOrHistoricalInformation xml:lang="de">Für SATB, 'Flatt trumpets', Bc. - Z 58C: Second setting</gndo:biographicalOrHistoricalInformation>
<gndo:dateOfPublication rdf:datatype="http://www.w3.org/2001/XMLSchema#string">1695</gndo:dateOfPublication>
</rdf:Description>
Hab etwas nachgedacht. Ich mach nur Datenbankzugriffe und die Datenbank wird aus den Dumps aufgebaut. Ist übrigens SQLite und C++-Code und läuft hier bei mir zu Hause. Das war zu einer Zeit, als ich in PHP noch nicht so zu Hause war, würde ich heute nicht mehr so machen. Egal.
Wenn es noch weitere solche schrägen Umleitungen gibt, dann würde ich das mal per Mail melden.
https://d-nb.info/gnd/1241770700 ist auch sowas, sollte nach https://d-nb.info/gnd/1241770697 weiterleiten https://d-nb.info/gnd/1236657691 sollte nach https://d-nb.info/gnd/1236710428 weiterleiten
Ich schreib mal eine Mail
Kann es sein, dass https://d-nb.info/gnd/7656167-7 in dem Datenobjekt von Anfang an eine falsche Zuordnung war?
Nein, Wurgl hat etliche dieser Weiterleitungen aufgespürt. Aus einem Grund, der mir nicht klar ist, wurden die Dubletten statt auf das Werk auf den Komponisten verlinkt. In der Wartungsliste :de:Benutzer:Wurgl/Fehler GND wurden die Weiterleitungen trotzdem korrekt (Werk → Werk) angezeigt.
Okay, interessant.
In den RDF-Daten ist nachvollziehbar, dass 7656167-7 tatsächlich zu dem Werk 300410581 gehört. Das ist auch beim ZBW-Endpoint so nachzulesen. Die URL leitet aber zum Komponisten 118742973 weiter. Leider hab ich das Weiterleitungsziel über das die URL bestimmt, und nicht am SPARQL-Endpoint ausgelesen :-)
Kann das mal bitte jemand zur DNB weiterleiten, oder kennt jemand jemanden der sich das hier anschauen möchte? Das sieht wie ein Bug aus.
Ich kann grundsätzlich nochmal alle Weiterleitungen abgleichen und schauen, ob wir weitere solcher Diskrepanzen aufspüren. Das Problem wird so langsam greifbar…
Mail ist raus. Die zwei Beispiele von mir und die 7656167-7. Sollte reichen.
Gab es hier eigentlich schon eine Antwort?
Nö :-(
Ich bin einmal über alle Weiterleitungen gegangen und habe folgende Fälle gefunden:
(Erstmal wieder rausgenommen, hier ist was durcheinandergeraten; mache heute Abend eine neue Tabelle)
Dauert leider ein bisschen; ich möchte gern am ZBW-SPARQL-Endpoint was abfragen, aber der scheint zurzeit nicht verfügbar zu sein. Die Sache ist aber nicht vergessen.
Hab das jetzt nochmal gemacht, und eigentlich war das letztes Mal schon gar nicht so falsch:
Die ersten sechs Fälle sind korrigiert. August Albert hat seine Identität gewechselt, was neben den wilden mix&merges einer jeder Späße in Wikidata ist, die einen in den Wahnsinn treiben.
Die beiden August Alberts sind jetzt klar getrennt:
- August Albert (Q60178345): no description
- August Albert (Q60182384): German chemist and professor
@Bovlb: Sorry for hitting the reverse button but for the clean up I had to start all over again.
Done Die Liste ist abgearbeitet.
Sorry, es gibt noch was zu überprüfen: Nicht alle schwach individualisierten Normdatensätze sind Tns. (Die Werke, auf dessen Autor sich der Datensatz bezieht, werden nur im OGND angezeigt.) Außerdem wurde vor der Änderung der Tns in Textstrings (Juni 2020), ein Schwung Tns in Tps umgewandelt, so wie es das ursprüngliche Konzept vorsah. (Tns waren dafür gedacht, nach Ergänzung der biographischen Daten in Tp-Datensätze umgewandelt zu werden. Das Konzept, das rückblickend etwas naiv anmutet, war mit der Erweiterung des Nutzerkreises obsolet.) Der genannte Fall gehört, glaube ich, nicht dazu. Wie immer kann User:Wurgl Genaueres dazu sagen.
Ich verstehe noch nicht genau, was wir hier prüfen wollen. Das ist ja ein Edit vom 2019 gewesen.
(falsches Beispiel; hat sich erledigt)
Ich könnte einmal über alle missbilligten GNDs gehen und den aktuellen Status abfragen. Das sind zurzeit etwa 6000 Identifikatoren, siehe https://w.wiki/4tDB für eine grobe Abschätzung (mit incorrect identifier value (Q54975531) kennzeichnen wir zurzeit Tns mit missbilligtem Rang; undifferentiated identifier value (Q68648103) passt eigentlich besser, wird aber zurzeit überhaupt nicht genutzt). —~~~~
undifferentiated identifier value (Q68648103) beschreibt einen Tn in der Tat besser. Ich habe den Qualifikator in die Liste Help:P227 aufgenommen.
Ich habe für alle GNDs, die missbilligt sind und den Qualifikator reason for deprecated rank (P2241): incorrect identifier value (Q54975531) hatten, nach einer individuellen Überprüfung des Tn-Status den Qualifikator zum Wert undifferentiated identifier value (Q68648103) verändert. Demnach haben wir zurzeit 2839 Tn-Identifikatoren, die allesamt korrekt ausgezeichnet sind, und nur 6 verbleibende missbilligte GNDs mit dem Qualifikator incorrect identifier value (Q54975531).
Danke. Die 2839 Tns sollte man von Hand überprüfen. In Wikisource sind offenbar noch viele eingetragen, während ich in deWP bislang auf keinen Fall gestoßen bin, wo ein Tn noch vorhanden war. Leider führen die Platzhalter dazu, dass VIAF Probleme hat, die korrekte GND mit anderen Normdatensätzen zusammenzuführen. Und auch das VIAF-Script in Wikidata zeigt keine GND an, wenn ein Platzhalter in einem Objekt eingetragen ist.
- Zunächst ein Update: mittlerweile sind es 3126 Tn-GNDs. Unter den missbilligten GNDs ohne Grund für die Missbilligung waren noch einige versteckt, die ich jetzt auch ausgezeichnet habe. Mehr erwarte ich jetzt aber wirklich nicht, zumindest nicht im aktuellen Bestand.
- Was mit den Tns passiert, ist mir relativ egal. Eigentlich gehören sie nicht hier her, aber mit missbilligtem Rang stören sie formell nicht – allerdings verstehen das nicht notwendigerweise alle Datennutzer. Im aktuellen Zustand sind sie jedenfalls gut zugänglich und damit auch wartbar.
- Was in Wikisource passiert, ist mir nicht bekannt. Wäre es hilfreich, dort eine lokale GND-Abgleich-Kategorie einzuführen? Es ist leider nicht einfach möglich das Wikidata-seitig zu evaluieren, es müsste in Wikisource passieren.
- "Das VIAF-Skript in Wikidata" ist mir nicht bekannt. Wo finde ich es?
Die GNDs wurden aus Wikisource importiert, dort aber nicht gelöscht. Daher müssen die Fehler von Hand korrigiert werden. Es sind aber nicht viele Fälle, und eine eigene Wartungskat imho nicht nötig. Das VIAF-Skript ("Add More Identifiers from VIAF") = User:Bargioni/moreIdentifiers. Störend ist, dass KrBot Einträge korrigiert, aber dabei Quelle und Rang ignoriert hat (Special:Diff/976930260). Das sind Edits von 2019, und ich denke, er hat (nach mehreren Beschwerden) die Arbeit eingestellt.
Was die Liste mit verwendeten Qualifikatoren betrifft: Für schwach individualisierte Normdatensätze eignet sich unconfirmed (Q28831311). Die Fälle muss man dann von Hand abarbeiten.
Ist "schwach individualisierter Normdatensatz" denn überhaupt irgendwie fest definiert, oder ist das eher eine lose genutze Umschreibung für einen Stub-Datensatz in der GND?
Es gibt Katalogisierungslevel. Tp6 = schwach individualisiert, aber in der Praxis hat sich das nur bedingt durchgesetzt. Was mich an die Frage weiter oben erinnert: Kannst du ohne großen Aufwand feststellen, wie viele GNDs für Personen, bei denen Lebensdaten und Beruf bekannt sind, bislang noch nicht in Wikidata erfasst sind?
Zu dem Abgleich: grundsätzlich sollte es möglich sein, aber ich komme gerade und eigentlich schon seit ein paar Tagen nicht an den SPARQL-Endpoint dran.
Bei dem genannten Beispiel GND 103191968 für den Literaturwissenschaftler Aleksandr Alekseevich Ninov (Q59630915) stimmt der Katalogisierungslevel. PICA3-Feld 005 = Tp6. Wenn ein Bibliothekar den Datensatz bearbeitet, wird der Level aber nicht automatisch angehoben, und umgekehrt gibt es Datensätze der Zentralredaktion, die das höchste Level (Tp1) tragen, aber eher dürftig sind.
Bei den schwach individualisierten Normdatensätzen würde ich vorschlagen, sie einfach ohne Qualifikator und mit normalem Rang zu führen. Ich verstehe, dass die Zuordnung manchmal auf einiger Spekulation beruht; trotzdem denke ich, dass wir erstmal von einer korrekten Zuordnung ausgehen sollten, solange nicht jemand explizit Zweifel äußert.
In den Linked-Data-Dumps ist das Kategorisierungslevel glaub ich gar nicht enthalten, oder?
Nee, in den Dumps ist leider nicht alles enthalten. Der Level fehlt und es fehlt (z.B.) auch diese Zeile "Quelle", die man auf der Webseite sieht.
Punkt 1: Das sehe ich auch so. Für Wartungslisten (de:Benutzer:Emu/GND) können die Level allerdings nützlich sein. Punkt 2: Das weiß wie immer Wurgl am besten.
Bezugnehmend auf Kolja21's posting vom 24 February 2022 3:49 AM, betreffend Tn -> Tp Umwandlungen.
Ich bin den Großteil der missbilligten GNDs nochmal durchgegangen. Je nach Grund für die Missbilligung (nach https://w.wiki/4wrX) finde ich:
- Alle mit "redirect" oder "undifferentiated identifier value" as Grund für die Missbilligung sind keine solchen Fälle.
- "refers to different subject", "applies to other person" und "conflation" habe ich nicht geprüft, die scheinen aber von sich aus unverdächtig.
- Alle anderen rund 120 Fälle, inklusive derer ohne angegebenen Grund für die Missbilligung, habe ich ebenfalls nicht geprüft. Hier wäre zu überlegen, inwiefern diese Qualifikatoren überhaupt sinnvoll sind.
Ich glaube nicht, dass hier noch in substantiellem Umfang Arbeit zu erledigen ist und erachte das erstmal als erledigt.
Der eventuelle Import von einer sechsstelligen Anzahl von vermeintlich fehlenden GNDs basierend auf VIAF-Clustern ist noch offen. Das ist als nächstes dran.
Viel kann ich nicht sagen, außer dass die ID 103191968 im Dump authorities-name_lds.rdf.gz enthalten ist und in meiner simplen Textliste Tns.txt.gz von Tn-IDs nicht.
Hinweis: Es gibt frische DNB-Dumps vom 2. März 2022
Es gibt auch einen frischen VIAF-Dump
Danke. Gibt es einen Vorschlag, wie wir die GNDs, die bereits über VIAF mit Wikidata verknüpft sind, einpflegen können? Weiter oben war von ~157.000 Fällen die Rede. Welche Filter und Abfragemöglichkeiten gibt es?
Also ich habe alles vorliegen, rein theoretisch könnte das mit meinem Bot oder gar QuickStatements innerhalb von rund zwei Tagen eingepflegt werden.
Allerdings traue ich der Sache noch nicht so richtig. Wieviele Fälle wären Fehler? Was müssten wir abgleichen? Da müssen wir erstmal genauer hinschauen.
Würde es vielleicht helfen, wenn ich mal 100 zufällige Fälle aus dem Datensatz zur Verfügung stelle und wir das manuell anschauen?
Könnte man nicht die Fälle herausfiltern, in denen Geburts- und Todesjahr übereinstimmen? Geburtsjahr alleine reicht leider nicht (Sportler in Wikipedia vs. Akademiker in der DNB). Die Masse an Tp6, bei denen man oft erst umständlich recherchieren muss, wer gemeint ist, eignet sich nicht für den automatischen Import, das sehe ich immer wieder an der de:Kategorie:Wikipedia:GND in Wikipedia fehlt, in Wikidata vorhanden.
Man könnte alles mögliche abgleichen. Die Ich habe leider kein Gefühl dafür, was alles sinnvoll wäre. Da ich die Sachen aus dem Dump extrahiere, ist effektiv GND-seitig alles abgleichbar, was im RDF-Dump drin ist. Wikidata-seitig können wir auch alles abgleichen. Es ist zu beachten, dass nicht alle Abgleiche immer trivial sind (Genauigkeiten, fehlende Daten, ungenaue Datumsangaben, etc.).
Zu beachten ist, dass der Abgleich auf den VIAF-Clustern (mit Stand 7. Februar 2022) basiert. Kann jemand abschätzen, wieviele Cluster (Prozent oder so) die durch Vermischungen versaut haben?
Nach meiner Erfahrung sind prozentuell relativ wenige VIAF-Cluster problematisch, aber wenn sie problematisch sind, dann richtig. Deshalb sind Stichproben zwar sinnvoll, aber in ihrer Aussagekraft begrenzt. Problematisch sind tendenziell bestimmte Berufsgruppen (speziell Sportler) und Allerweltsnamen. Man könnte alle Peter und Karl sowie alle Müller und Meier ausschließen, das wäre vermutlich schon eine deutliche Verbesserung. --Emu (talk) 13:19, 8 March 2022 (UTC)
Eine ganz andere Sache die man machen könnte, das ist aber etwas wilder:
Es geht um Geographika. In Q1931017 ist VIAF:246906212 eingetragen. Das ist nicht ganz falsch. In de:Michelbach am Heuchelberg ist GND 1168670705 eingetragen, das ist schon richtiger.
Problem ist, dass dieses Kaff eingemeindet wurde. Also bis 30.6.1970 war der (vorhandene) VIAF-Datensatz mit der GND 7827792-9 gültig und ab 1.7.1970 ist GND 1168670705 mit VIAF:5321153954925905680004 gültig.
Ich hab einmal so eine Wikidata-Objekt gesehen, wo beide GNDs eingetragen waren. Einmal mit "gültig bis" und einmal als "preferred" mit "gültig ab".
Das sehe ich mal so als Idee: Wenn die deWP einen DNB-Datensatz hat und der hat einen Vorgänger und in Wikidata ist eine VIAF, die den Vorgänger klammert, dann die GND-Kette der Vorgänger zu der VIAF (manchmal gibt es mehrere Vorgänger!) eintragen bzw. ergänzen. Wobei das nur, wenn diese Vorgänger/Nachfolger-Kette durch Datum qualifiziert abgegrenzt ist.
Bei Geografika und Körperschaften ist der automatische Import besonders problematisch. Imho sollte man sich vorerst auf Personen konzentrieren. Eine Liste mit Allerweltsnamen ist mir nicht bekannt, daher bleibt eigentlich nur, wie vorgeschlagen, Name + Geburts- + Todesjahr. Das sind die Fälle, die man per Bot importieren könnte. Für den großen Rest sehe ich nur die Möglichkeit, strukturierte Listen zu erstellen, in denen die GNDs z.B. nach Typ, Katalogisierungslevel, Geburtsjahr (Personen) und/oder Land (Geografika), aufgeführt werden.
Daher ja die Einschränkung: Wenn in deWP eine GND ist … Okay, könnte man noch einschränken auf "eine GND die keinen Nachfolger hat".
Irgendwie verzetteln wir uns hier :-)
Wir machen erstmal den Import für Personenobjekte, und weiter oben hat User:Kolja21 auch noch eine Aufgabe zur Überprüfung da gelassen, die ein bisschen Aufmerksamkeit braucht. Danach schauen wir weiter.