Titel-Diskrepanz bei OECD iLibrary
Closed this issue · 3 comments
Ich habe via Ygor (https://gokb.org/ygor) die 2019er KBART der OECD iLibrary in die GOKb (org) gespielt (ohne Anreicherung in der ZDB oder EZB) - allerdings sind im Package zu wenig Titel mit "rüber" gekommen https://gokb.org/gokb/resource/show/org.gokb.cred.Package%3A1080754 . Das Package war vorher leer gewesen, allerdings kann ich mich erinnern, dass ich vor dem Zusammenlegen der GOKb-Instanzen bereits einmal die Titel der OECD iLibrary eingespielt hatte. Ich denke es ist aber ein GOKb Problem und kein Ygor Problem? Wie kommt es bei einem Teil der Titel dazu, dass diese nicht ins GOKb Package kommen?
Auf den ersten Blick sieht das für mich nicht unbdingt nach einem Bug aus, sondern nach einer Datamanager-Aufgabe zur nachträglichen Bereinigung. Das Paket hat 18 offene Review Requests, die vermutlich einen Aufschluss über die Fehler geben:
https://gokb.org/gokb/resource/show/org.gokb.cred.Package%3A1080754#review -> Load Open Requests
Einige Titel wurden dort vermutlich auf Grund von uneindeutigen Identifikatoren miteinander verschmolzen.
Ich habe mir das gerade einmal angeschaut und sehe zwei Probleme bzw Fragen: 1) Die in der Liste "Load open requests" ausgegebenen Informationen bedeuten, dass diese Titel jetzt alle aufgrund der Systemrückmeldung nicht mitgekommen sind? Ein kurzer Blick rein, zeigt ja das es hier scheinbar zuvor eine erste Anreicherung gab mit ZDB Infos, jetzt hatte Miriam aber ja bewusst ohne gesagt - daher darf meiner Meinung nach hier nicht mit alten Informationen angereichert werden bzw die neuen deshalb nicht aufgenommen werden. Was soll hier auch der Datamanger prüfen? Der weiss ja nicht, was er wirklich prüfen soll - und theoretisch sollte die gesamte neue KBART (ohne Verluste) aufgenommen werden. 2) In der Liste darf aus Datenschutzgründen "raised by" nicht auftauchen - da darf bzw. muss die curatory group auftauchen. bitte dies zwingend einmal im gesamten system prüfen und anpassen - immer die übergeordnete Einheit ist der verursacher, nie eine person.
@MiriKon Das Problem bestand letztendlich darin, dass jemand die früher existierenden Titel als ungültig/gelöscht markiert hatte, was die Anzeige in der Paketansicht (Titles/TIPPs (xxx/xxx)) durcheinander gebracht hat. Ich schaue mal, wie man das am besten in Zukunft verhindern kann.
@michaselbach
zu 1):
Die in der Liste "Load open requests" ausgegebenen Informationen bedeuten, dass diese Titel jetzt alle aufgrund der Systemrückmeldung nicht mitgekommen sind?
Nein, die Review Request weisen lediglich auf beim Import identifizierte mögliche Konflikte in der GOKb hin.
Ein kurzer Blick rein, zeigt ja das es hier scheinbar zuvor eine erste Anreicherung gab mit ZDB Infos, jetzt hatte Miriam aber ja bewusst ohne gesagt - daher darf meiner Meinung nach hier nicht mit alten Informationen angereichert werden ...
Die GOKb hält eine global gültige Liste an Titeln, die anhand aller ihrer externen Identifikatoren unterschieden werden. Ein neuer Titel wird dementsprechend nicht erstellt, falls den eingehenden Titelinformationen zuverlässig ein bestehender Titel zugewiesen werden kann. Ob der bestehende Titel noch weitere IDs wie etwa eine ZDB-ID hat, welche in den eingespielten Daten nicht vorhanden sind, ist dabei egal. Werden bei dem Matching mögliche Konflikte erkannt, werden hierfür Review Requests generiert (s.u.).
... bzw die neuen deshalb nicht aufgenommen werden.
Die einzelnen Zeilen einer KBART-Datei werden nicht durch die globalen Titelaufnahmen, sondern durch die (paketgebundenen) TIPPs repräsentiert. In diesem spezifischen Fall hat die KBART-Liste 859 Zeilen, und es wurden korrekterweise 859 TIPPs erstellt. Die Liste ist somit vollständig in der GOKb abgebildet. Kann ein TIPP nicht angelegt werden, stimmt in der Regel etwas an den Daten nicht (z.B. Startdatum nach Enddatum in der Coverage), oder es liegt ein größeres, von der Datei unabhängiges Problem vor.
Die Review-Requests für dieses Paket lassen sich wie folgt gruppieren:
-
...was matched on one identifier... (New TI created)
Erläuterung: Es gab Überschneidungen bei den Identifikatoren mit einem anderen Titel, aber auch Konflikte, daher wurde
vorsichtshalber ein neuer Titel angelegt, der möglicherweise eine Dublette darstellt. Ein menschliches Review ist nötig, um eine mögliche Bereinigung (Deduplizierung/Korrektur) durchzuführen. Ursache in dieser Datei waren 6 ISSNs/eISSNs, die mehrfach vorkamen.Bsp.: https://gokb.org/gokb/resource/show/org.gokb.cred.JournalInstance%3A12545559#identifiers und
https://gokb.org/gokb/resource/show/org.gokb.cred.JournalInstance:12566243#identifiers unterscheiden sich letztendlich nur
durch die Endung-enin der DOI -
Ingest file ... matched an existing ... (Identifier type mismatch)
Erläuterung: Ein Fall, in dem eine bereits bekannte Print-ISSN als eISSN (oder andersherum) verwendet wurde. Es sollte online überprüft werden, welche korrekt ist, und die falsche entfernt (bzw. als falsch markiert) werden.Bsp.: https://gokb.org/gokb/resource/show/org.gokb.cred.JournalInstance:553961#identifiers
-
Match was made on 1st class identifier but title name seems to be very different (Added variant)
Erläuterung: Hier gab es eine komplette Übereinstimmung der Identifikatoren, aber unterschiedliche Haupttitel. Da Titel im Vergleich zu Identifikatoren weniger zuverlässig verstanden wird, wurde der neue Titelname lediglich als Namensvariante des bestehenden Titels aufgenommen.Bsp.: https://gokb.org/gokb/resource/show/org.gokb.cred.JournalInstance:545396
zu 2):
Das ist ein guter Hinweis. Wir sind dabei, im Hintergrund die Zuweisung von Reviews an Kuratorengruppen einzubauen, sind damit aber noch nicht fertig. Ich würde aber schon einmal in einem kleineren Update die Anzeige dementsprechend anpassen.