OpenCitations Meta: Methodik

Linktabelle

• Zusammenfassung und Einleitung
• Verwandte Arbeiten
• Methodik
• Daten und Dienste
• Diskussion
• Schlussfolgerung, Danksagungen und Referenzen

3. Methodik

OpenCitations Meta wird aus Eingabedaten im CSV-Format (d. h. tabellarisch) gefüllt. Diese Wahl ist kein Zufall. Wir haben festgestellt, dass von OpenCitations im CSV-Format bereitgestellte Daten (z. B. von COCI (OpenCitations, 2022)) häufiger heruntergeladen werden als dieselben Daten in strukturierteren Formaten (d. h. JSON Scholix und RDF N-Quads). Dies liegt an der geringeren Dateigröße (im Vergleich zu N-Quads und Scholix) und vor allem an der besseren Lesbarkeit des tabellarischen Formats für einen Menschen. Letzteres ist der Hauptgrund, warum das von OpenCitations Meta verwendete Eingabeformat CSV ist, um das zukünftige Crowdsourcing bibliografischer Metadaten aus menschlichen kuratorischen Aktivitäten zu erleichtern (Heibi et al., 2019a).

Die Eingabetabelle von OpenCitations Meta hat elf Spalten, die einer Linearisierung des OCDM entsprechen (Daquino et al., 2020): ID, Titel, Autor, Herausgeber, Veröffentlichungsdatum, Veranstaltungsort, Band, Ausgabe, Seite, Typ und Herausgeber. Eine ausführliche Beschreibung der Struktur der einzelnen Felder finden Sie unter (Massari & Heibi, 2022).

Sobald die tabellarischen CSV-Daten erfasst wurden, werden die Daten zunächst automatisch kuratiert (Kurator-Schritt) und dann basierend auf dem OCDM in RDF konvertiert (Ersteller-Schritt). Schließlich werden die kuratierten CSV- und RDF-Dateien als Dateien gespeichert, während ein entsprechender Triplestore schrittweise befüllt wird. Abbildung 2 fasst den Arbeitsablauf zusammen.

3.1 Kurator: Deduplizierung, Anreicherung und Korrektur

Der Kurationsprozess führt drei Hauptaktionen aus, um die Qualität der empfangenen Daten zu verbessern: Deduplizierung, Anreicherung und Korrektur.

Der für die Datendeduplizierung gewählte Ansatz basiert strikt auf Kennungen. Anders ausgedrückt werden zwei unterschiedliche Entitäten genau dann als gleich angesehen, wenn beide die gleiche Kennung haben, z. B. eine DOI für Artikel, eine ORCID für Personen, eine ISBN für Bücher und eine ISSN für Publikationsorte (z. B. Zeitschriften).

Verschiedene Ressourcen mit derselben Kennung werden nach einer genauen Regel zusammengeführt: (1) Wenn die Ressourcen Teil derselben CSV-Datei sind, werden die Informationen des ersten Vorkommens bevorzugt. (2) Wenn die Ressource jedoch bereits im Triplestore beschrieben ist, werden die Informationen im Triplestore bevorzugt. Mit anderen Worten betrachten wir die im Triplestore gespeicherten Informationen als vertrauenswürdig und sie können nur mit zusätzlichen Daten aus einer CSV-Quelle erweitert werden.

Sobald eine Entität dedupliziert wurde, wird ihr ein neuer, permanenter interner Identifikator zugewiesen, der als OpenCitations Meta Identifier (OMID) bezeichnet wird. Der OMID hat die Struktur [Entitätstypabkürzung]/[Lieferantenpräfix][fortlaufende Nummer]. Beispielsweise hat der erste jemals verarbeitete Zeitschriftenartikel die OMID br/0601, wobei br die Abkürzung für „bibliografische Ressource“ ist und 060 dem Lieferantenpräfix entspricht, das die Datenbank angibt, zu der die bibliografische Ressource gehört (in diesem Fall OpenCitations Meta). Schließlich gibt 1 an, dass diese OMID die erste bibliografische Ressource des Index identifiziert, die jemals für dieses Präfix erfasst wurde.

Genauer gesagt lautet das für OpenCitations Meta verwendete Lieferantenpräfix „06[1-9]*0“, d. h. „06“ optional gefolgt von einer beliebigen Zahl außer Null und einer „0“ am Ende. Beispielsweise sind „060“, „0610“ und „06230“ gültige Lieferantenpräfixe in OpenCitations Meta.

Die Entitäten, die einer Deduplizierung unterliegen und anschließend mit einer OMID identifiziert werden, sind externe Kennungen (Abk. id), Agentenrollen (d. h. Autoren, Herausgeber, Verleger, Abk. ar), verantwortliche Agenten (d. h. Personen und Organisationen, Abk. ra), Ressourcenverkörperungen (d. h. Seiten, Abk. re) sowie Veranstaltungsorte, Bände und Ausgaben (die alle bibliografische Ressourcen sind, Abk. br). Bände und Ausgaben haben OMIDs, weil sie als erstklassige Bürger behandelt werden und nicht als Attribute von Artikeln. Dies hat den Vorteil, dass man beispielsweise nach den Aufsätzen einer bestimmten Ausgabe, den Bänden einer benannten Zeitschrift oder Zeitschriftenausgaben suchen kann, die innerhalb eines bestimmten Zeitraums erschienen sind. Im Gegensatz dazu werden Titel und Daten als wörtliche Werte und nicht als Entitäten behandelt.

Abbildung 3 veranschaulicht den Entscheidungsbaum für die Deduplizierung. Bei einer gegebenen Eingabeentität und ihren Kennungen gibt es sechs mögliche Ergebnisse:

1. Wenn die Entität keine Kennungen hat oder diese im Triplestore nicht vorhanden sind, wird für die Entität eine neue OMID erstellt.

   
   

2. Wenn die Entität keine OMID hat und einer ihrer externen Bezeichner bereits mit genau einer anderen Entität verknüpft wurde, werden die beiden Entitäten zusammengeführt und als gleich behandelt.

   
   

3. Wenn die externen Kennungen der Entität in der CSV-Datei zwei oder mehr Entitäten innerhalb des Triplestores verbinden, die bisher unterschiedlich waren, und in der CSV-Datei keine OMID angegeben ist, entsteht ein Konflikt, der nicht automatisch gelöst werden kann und ein manuelles Eingreifen erfordert. Für diese konfliktbehaftete Entität wird eine neue OMID erstellt. Beispielsweise ist in der CSV-Datei derselbe Zeitschriftenname mit zwei Kennungen verknüpft, issn:1588-2861 und issn:0138-9130; im Triplestore gibt es jedoch Einträge für zwei verschiedene Entitäten, eine mit der Kennung issn:1588-2861 und die andere mit der Kennung issn:0138-9130, die sich in Wirklichkeit auf dieselbe Entität beziehen;

   
   

4. Wenn eine Entität in der CSV-Datei eine OMID hat, die im Triplestore vorhanden ist, und keine anderen IDs vorhanden sind, überschreiben die Informationen im Triplestore die in der CSV-Datei. Der Triplestore wird dann nur durch das Hinzufügen fehlender Details aktualisiert. Mit anderen Worten: Die Angabe der OMID für eine Entität in der CSV-Datei ist eine Möglichkeit, eine vorhandene Entität in OpenCitations Meta zu aktualisieren.

   
   

5. Wenn eine Entität eine vorhandene OMID hat und zusätzliche Kennungen mit anderen Entitäten ohne OMID (in der CSV) oder mit derselben OMID (in der CSV oder im Triplestore) verknüpft sind, werden die Entitäten zusammengeführt. Darüber hinaus werden die Informationen in der CSV mit den bereits im Triplestore vorhandenen Informationen überschrieben und fehlende Details in der CSV werden dann zum Triplestore hinzugefügt.

   
   

6. Wenn externe Kennungen mehrere Entitäten im Triplestore mit unterschiedlichen OMIDs verbinden, kommt es schließlich zu einem Konflikt. In diesem Fall hat die in der CSV-Datei angegebene OMID Vorrang und es werden nur Entitäten mit dieser OMID zusammengeführt.

Angesichts dieser allgemeinen Regeln verdienen drei besondere Fälle besondere Aufmerksamkeit. Das erste bemerkenswerte Problem betrifft die Reihenfolge der Autoren und Herausgeber, die gemäß OCDM beibehalten werden muss. Im Falle einer Zusammenführung überschreibt die Reihenfolge, die bei der Erstellung der Entität aufgezeichnet wurde, nachfolgende Reihenfolgen, und alle neuen Autoren oder Herausgeber werden am Ende der vorhandenen Liste hinzugefügt, wie in Abb. 4 dargestellt.

Zweitens werden im Rahmen der Zusammenführung zweier bibliographischer Ressourcen die beteiligten Personen als Autoren oder Herausgeber ohne Kennung anhand ihrer Vor- und Nachnamen unterschieden.

Der letzte wichtige Fall betrifft die Containment-Beziehung zwischen Artikeln, Ausgaben, Bänden und Veranstaltungsorten. Diese Struktur bleibt im Falle einer Zusammenführung erhalten, wobei zwei Bände oder Ausgaben nur dann als gleich betrachtet werden, wenn sie denselben Wert haben, der eine fortlaufende Nummer (z. B. „Band 1“) oder ein beliebiger Name (z. B. „Clin_Sect“) sein kann.

3.2 Kurator: Fehlervermeidung

Sobald alle Entitäten eine OMID erhalten haben, werden die Daten normalisiert und die Fehler, die automatisch behandelt werden können, korrigiert. Alle Kennungen werden anhand ihres Kennungsschemas überprüft – beispielsweise wird die syntaktische Korrektheit von ISBNs, ISSNs und ORCIDs anhand spezifischer Formeln berechnet, die in der Dokumentation des Kennungsschemas bereitgestellt werden. Die semantische Korrektheit der Kennungen wird jedoch nur für ORCIDs und DOIs überprüft, was mithilfe offener APIs erfolgt, um ihre tatsächliche Existenz zu überprüfen – da es beispielsweise möglich ist, eine ORCID zu erstellen, die syntaktisch gültig ist, aber tatsächlich keiner Person zugewiesen ist.

Alle mehrdeutigen und alternativen Zeichen, die für Leerzeichen verwendet werden (z. B. Tabulator, geschütztes Leerzeichen, Geviert), werden in Leerzeichen (Unicode-Zeichen U+0020) umgewandelt. Ebenso werden mehrdeutige Zeichen für Bindestriche innerhalb von IDs, Seiten, Bänden, Ausgaben, Autoren und Herausgebern (z. B. geschützte Bindestriche, Halbgeviertstrich, Minuszeichen) in Bindestrich-Minus (Unicode-Zeichen U+002D) geändert.

Bei den Titeln bibliografischer Ressourcen (Spalten „Veranstaltungsort“ und „Titel“) wird jedes Wort im Titel großgeschrieben, mit Ausnahme der Wörter, die darin Großbuchstaben enthalten (wahrscheinlich Akronyme, z. B. „FaBiO“ und „CiTO“). Diese Ausnahme gilt jedoch nicht für Titel, die vollständig großgeschrieben sind. Dieselbe Regel gilt auch für Autoren und Herausgeber, egal ob Einzelpersonen oder Organisationen.

Bei der Analyse von Daten wird sowohl die Gültigkeit des Formats, basierend auf ISO 8601 (JJJJMM-TT) (Wolf & Wicksteed, 1997), als auch der Wert (z. B. ist der 30. Februar kein gültiges Datum) berücksichtigt. Bei Bedarf wird das Datum gekürzt. Beispielsweise wird das Datum 2020-02-30 in 2020-02 umgewandelt, da der Tag des angegebenen Datums ungültig ist. Ebenso wird 2020-27-12 auf 2020 gekürzt, da der Monat (und damit der Tag) ungültig ist. Das Datum wird verworfen, wenn das Jahr ungültig ist (z. B. ein Jahr größer als 9999).

Die Korrektur von Band- und Heftnummern erfolgt nach zahlreichen Regeln, die besondere Erwähnung verdienen. Generell haben wir sechs Fehlerklassen identifiziert, die auftreten können, und jede dieser Klassen wird entsprechend behandelt:

1. Bandnummer und Heftnummer im selben Feld (z.B. „Vol. 35 N° spécial 1“). Die beiden Werte werden getrennt und dem entsprechenden Feld zugeordnet.

2. Präfixfehler (z. B. „.38“). Das Präfix wird gelöscht.

   
   

3. Suffixfehler (z. B. „19/“). Das Suffix wird gelöscht.

   
   

4. Kodierungsfehler (z. B. „5â\x80\x926“, „38â39“, „3???4“). Nur die Zahlen an den Extremen werden beibehalten, getrennt durch einen einzelnen Bindestrich. Daher werden die Beispiele in „5-6“, „38-39“ bzw. „3-4“ korrigiert, da „â\x80\x92“, „â“ und „???“ falsch kodierte Bindestriche sind.

   
   

5. Als Ausgabe klassifizierter Band (z. B. „Band 1“ im Feld „Ausgabe“). Wenn das Bandmuster im Feld „Ausgabe“ gefunden wird und das Feld „Band“ leer ist, wird der Inhalt in das Feld „Band“ verschoben und das Feld „Ausgabe“ auf Null gesetzt. Wenn das Feld „Ausgabe“ jedoch ein Bandmuster enthält und das Feld „Band“ ein Ausgabemuster enthält, werden die beiden Werte vertauscht.

   
   

6. Ausgabe als Band klassifiziert (z. B. „Sonderausgabe 2“ im Feld „Band“). Die Behandlung erfolgt analog zu Fall 5, allerdings mit vertauschten Rollen.

Wir haben jene Muster als Bände betrachtet, die die Wörter „Originalserie“, „Band“, „Band“ und Band in verschiedenen anderen Sprachen enthalten, z. B. „Tome“ auf Französisch und „Cilt“ auf Türkisch. Beispielsweise werden „Originalserie“, „Band 1“, „Band 71“, „Tome 1“ und „Cilt: 1“ als Bände klassifiziert. Stattdessen haben wir jene Muster als Ausgaben betrachtet, die die Wörter „Ausgabe“, „Sonderausgabe“ und Ausgabe in verschiedenen Sprachen enthalten, z. B. „horssérie“ (Sonderausgabe auf Französisch) und „özel sayı“ (Sonderausgabe auf Türkisch). Beispielsweise werden „Ausgabe 2“, „Sonderausgabe 2“, „Sonderausgabe ‚Urban Morphology‘“, „Özel Sayı 5“ und „Hors-série 5“ als Ausgaben klassifiziert.

Ist ein Wert schließlich sowohl hinsichtlich seines Formats als auch deshalb ungültig, weil er im falschen Feld steht, wird der Wert zunächst korrigiert und anschließend, falls zutreffend, in das richtige Feld verschoben.

Nach der Disambiguierung, Anreicherung und Korrektur der Eingabedaten wird eine neue CSV-Datei erstellt und gespeichert. Diese Datei stellt die erste Ausgabe des Prozesses dar (3a in Abb. 2).

3.3 Ersteller: Semantische Abbildung

In dieser Phase werden Daten in RDF nach dem OCDM modelliert (Daquino et al., 2020). Diese Ontologie verwendet in den SPAR-Ontologien definierte Entitäten wieder, um bibliografische Entitäten (fabio:Expression), Kennungen (datacite:Identifier), Agentenrollen (pro:RoleInTime), verantwortliche Agenten (foaf:Agent) und Details zum Veröffentlichungsformat (fabio:Manifestation) darzustellen. Die Agentenrolle (d. h. Autor, Herausgeber oder Verleger) wird als Proxy zwischen der bibliografischen Ressource und dem verantwortlichen Agenten, d. h. der Person oder Organisation, verwendet. Dieser Ansatz hilft uns, zeit- und kontextabhängige Rollen und Status zu definieren, wie z. B. die Reihenfolge der Autoren (Peroni et al., 2012). Abb. 5 zeigt die Beziehungen zwischen den verschiedenen Entitäten durch das grafische Framework von Graffoo (Falco et al., 2014).

Beispielsweise hat in OpenCitations Meta die Entität mit OMID omid:br/062601067530 den Titel Open Access And Online Publishing: A New Frontier In Nursing? (dcterms:title) und wurde am 25.07.2012 veröffentlicht (prism:publicationDate). Unter Verwendung von FRBR (Tillett, 2005) ist der Artikel die endgültige veröffentlichte Version oder ein Ausdruck des Originalwerks (fabio:Expression), das als Beispiel die Entität omid:re/06260837633 (frbr:embodiment) hat, also die gedruckte Veröffentlichung, die den Seiten 1905-1908 des Zeitschriftenbands entspricht (prism:startingPage, prism:endingPage). Genauer gesagt ist der Artikel Teil (frbr:partOf) der Ausgabe (fabio:JournalIssue) Nummer 9 (fabio:hasSequenceIdentifier), die im Band (fabio:JournalVolume) Nummer 68 des Journal Of Advanced Nursing (fabio:Journal) enthalten ist.

Darüber hinaus ist die Person (foaf:Agent) Glenn Hunt (foaf:givenName, foaf:familyName) der erste Autor (pro:RoleInTime) im Kontext dieses Artikels (pro:isDocumentContextFor). Ebenso ist die zweite Autorin Michelle Cleary (pro:hasNext).

Schließlich verfügt diese Veröffentlichung über den OpenCitations Meta Identifier (OMID) omid:id/062601093630 (datacite:hasIdentifier), eine Entität vom Typ datacite:Identifier. Sie verfügt außerdem über einen externen Identifikator, der als Identifikationsschema einen Digital Object Identifier (DOI) (datacite:usesIdentifierScheme) verwendet und den Literalwert „10.1111/j.1365- 2648.2012.06023.x“ (literal:hasLiteralValue) hat.

Sobald das Mapping abgeschlossen ist, können die erstellten RDF-Daten gespeichert (4a in Abb. 2) und in einen Triplestore hochgeladen werden (4b in Abb. 2).

3.4 Urheber: Herkunft und Änderungsverfolgung

Neben der Handhabung ihrer Metadaten wird der Herkunft und der Änderungsverfolgung von Entitäten in OpenCitations Meta große Bedeutung beigemessen. Die Herkunft ist eine Aufzeichnung darüber, wer eine bestimmte Entität verarbeitet hat, indem er sie erstellt, gelöscht, geändert oder zusammengeführt hat, wann diese Aktion durchgeführt wurde und was die primäre Quelle war (Gil et al., 2010). Die Verfolgung dieser Informationen ist entscheidend, um die Zuverlässigkeit der Metadaten in OpenCitations Meta sicherzustellen. Tatsächlich ist die Wahrheit einer Aussage im Web und im semantischen Web nie absolut, und die Integrität muss von jeder Anwendung, die Informationen verarbeitet, durch Bewertung ihres Kontexts beurteilt werden (Koivunen & Miller, 2001).

Neben der Speicherung von Herkunftsinformationen sind jedoch auch Mechanismen zum Verständnis der Entwicklung von Entitäten von entscheidender Bedeutung, wenn es um Aktivitäten wie Forschungsbewertungsübungen geht, bei denen Änderungen aufgrund von Korrekturen oder falschen Angaben die Gesamtbewertung eines Wissenschaftlers, einer Forschungsgruppe oder einer ganzen Institution beeinflussen können. Beispielsweise kann sich der Name einer Institution im Laufe der Zeit ändern, und die Darstellung dieser Änderungen in einer Datenbank „erschwert die Identifizierung aller Namen und Einheiten der Institution ohne Kenntnis der Geschichte der Institution“ (Pranckut˙e, 2021). Dieses Szenario kann verhindert werden, indem die Entwicklung der Daten in der Datenbank verfolgt wird, sodass Benutzer diese Dynamik verstehen können, ohne auf externes Hintergrundwissen zugreifen zu müssen. Unseres Wissens verfolgt keine andere semantische Datenbank mit wissenschaftlichen Metadaten Änderungen und Herkunft im Standard-RDF 1.1.

Der von OpenCitations verwendete Herkunftsmechanismus beschreibt einen anfänglichen Erstellungs-Snapshot für jede gespeicherte Entität, möglicherweise gefolgt von weiteren Snapshots, die Änderungen, Zusammenführungen oder Löschungen von Daten detailliert beschreiben, wobei jeder Snapshot mit seiner Snapshot-Nummer gekennzeichnet ist, wie in Abb. 6 zusammengefasst.

In Bezug auf die semantische Darstellung wurde das Problem der Provenienzmodellierung (Sikos & Philp, 2020) und der Änderungsverfolgung in RDF (Pelgrin et al., 2021) in der Fachliteratur diskutiert. Bislang erreicht kein gemeinsamer Standard beide Ziele. Aus diesem Grund verwendet OpenCitations die am weitesten verbreiteten Ansätze, d. h. benannte Graphen (Carroll et al., 2005), die Provenance Ontology (Lebo et al., 2013) und Dublin Core (Board, 2020).

Insbesondere ist jeder Snapshot über das Prädikat prov:wasDerivedFrom mit dem vorherigen verbunden und über prov:specializationOf mit der Entität verknüpft, die er beschreibt. Darüber hinaus entspricht jeder Snapshot einem benannten Graphen, in dem die Provenienzmetadaten beschrieben werden, nämlich der verantwortliche Agent (prov:wasAttributedTo), die primäre Quelle (prov:hadPrimarySource), die Generierungszeit (prov:generatedAtTime) und, nach der Generierung eines zusätzlichen Snapshots, die Ungültigkeitszeit (prov:invalidatedAtTime). Jeder Snapshot kann optional auch durch eine Beschreibung des Geschehens in natürlicher Sprache dargestellt werden (dcterms:description).

Darüber hinaus fügt das OCDM-Provenienzmodell ein neues Prädikat hinzu, oco:hasUpdateQuery, das in der OpenCitations Ontology (Daquino & Peroni, 2019) beschrieben wird und das Delta zwischen zwei Versionen einer Entität über eine SPARQL UPDATE-Abfrage ausdrückt. Abb. 7 zeigt das Modell über ein Graffoo-Diagramm.

Der in Abschnitt 3.1 beschriebene Deduplizierungsprozess findet nicht nur im aktuellen Zustand des Datensatzes statt, sondern in seiner gesamten Historie, indem der Änderungsverfolgungsmechanismus erzwungen wird. Mit anderen Worten: Wenn eine Kennung auf eine aus dem Triplestore gelöschte Entität zurückgeführt werden kann, wird diese Kennung mit der OMID der gelöschten Entität verknüpft. Wenn die Löschung auf eine Merge-Kette zurückzuführen ist, hat die OMID der resultierenden Entität Vorrang. Weitere Informationen zur Methodik der Zeitdurchquerungsabfragen finden Sie unter (Massari & Peroni, 2022). Weitere Einzelheiten zur Programmierschnittstelle zum Erstellen von Daten und Verfolgen von Änderungen gemäß den SPAR-Ontologien finden Sie unter (Persiani et al., 2022).