A Multi-Surface Consistency Audit of Software Citation Metadata

In der Welt der modernen Wissenschaft ist Software ebenso unverzichtbar geworden wie ein Mikroskop oder ein Teleskop. Sie ist das Werkzeug, mit dem Forscher Zahlen auswerten, den Klimawandel simulieren und das Verhalten von Atomen modellieren. Da diese Software ein Produkt menschlicher Arbeit und geistiger Anstrengung ist, hat die wissenschaftliche Gemeinschaft beschlossen, dass sie zitiert werden muss, genau wie ein Forschungspapier. Wenn ein Wissenschaftler ein bestimmtes Programm nutzt, um eine Entdeckung zu machen, sollte er den Menschen, die es geschrieben haben, die Version, die er verwendet hat, und den Ort, an dem man es finden kann, würdigen. Um dies zu ermöglichen, wurde ein System aufgebaut, bei dem Softwareprojekte digitale „Namensschilder“ hinterlassen können. Diese Tags sind maschinenlesbare Dateien, die den Titel des Projekts, die Namen seiner Autoren, die Versionsnummer und eine eindeutige Kennung enthalten, die darauf hinweist, wo sich die Software online befindet. Die Idee ist, dass, wenn ein Forscher, ein Bibliothekar oder ein Computerprogramm auf eines dieser Schilder blickt, sie alle dieselbe Geschichte über dasselbe Stück Software erzählen werden.

Ein kürzlich durchgeführte Studie stellte jedoch eine einfache, aber beunruhigende Frage: Stimmen diese Namensschilder tatsächlich miteinander überein? Die Forscher unter der Leitung von Pengyin Shan von der University of Illinois beschlossen, die digitalen Selbstbeschreibungen von 117 Open-Source-Research-Softwareprojekten zu prüfen. Sie untersuchten sieben verschiedene Orte, an denen ein Projekt sich selbst beschreiben könnte: eine spezifische Datei, die für Zitate gedacht ist, eine Datendatei für Archive, einen Datensatz in einem öffentlichen Register, in dem Software heruntergeladen wird, und den Text auf der Hauptwebseite des Projekts. Sie behandelten die Software als das einzelne Objekt und diese verschiedenen Dateien als unterschiedliche „Oberflächen“ oder Seiten dieses Objekts. Wenn das System perfekt funktioniert, sollte jede Oberfläche dasselbe aussagen. Wenn sie voneinander abweichen, führt dies zu Verwirrung darüber, wer die Arbeit geleistet hat, welche Version verwendet wurde und wo der Code zu finden ist. Die Studie ergab, dass das System weit davon entfernt ist, perfekt zu sein. Tatsächlich erzählten die Mehrheit der untersuchten Projekte unterschiedliche Geschichten an verschiedene Teile des Internets.

Die Forscher entwickelten einen sorgfältigen Prozess, um diese Projekte zu überprüfen. Sie sammelten eine Gruppe von 117 Software-Tools, darunter High-Performance-Computing-Tools, die für Supercomputing und Quantencomputing verwendet werden, sowie eine kleinere Gruppe von Tools, die von Community-Journalen akzeptiert worden waren. Für jedes Projekt luden sie an einem einzigen Tag Schnappschüsse der sieben verschiedenen Oberflächen herunter. Sie verwendeten dann ein Computerprogramm, um die Informationen zu normalisieren, indem sie die verschiedenen Dateiformate in eine gemeinsame Liste von sechs Schlüsseldaten übersetzten: den Titel, den Autor, die Version, das Jahr, die Lizenz und die eindeutige Kennung. Sie verglichen jedes Paar von Oberflächen, die für ein Projekt existierten, um zu sehen, ob die Fakten übereinstimmten. Um sicherzustellen, dass ihre Methode genau war, überprüften sie manuell eine große Stichprobe der Urteile des Computers und bestätigten, dass ihr Werkzeug fast zu 99 Prozent korrekt war.

Die Ergebnisse zeigten einen erheblichen Mangel an Konsistenz. Von den 117 Projekten hatten nur 62 mindestens zwei Oberflächen, die verglichen werden konnten. Unter diesen 62 Projekten wiesen 52, also etwa 84 Prozent, mindestens einen größeren Konflikt zwischen ihren Oberflächen auf. Das bedeutet, dass eine Person, die die Zitierdatei liest, andere Informationen erhält als jemand, der den Archivdatensatz oder die Downloadseite liest. Die Unstimmigkeiten traten am häufigsten bei den Listen der Autoren und den Titeln der Software auf. Während das Jahr und die Lizenz meist konsistent waren, stimmten die Kerndetails, die das Werk identifizieren, oft nicht überein. Die Studie fand heraus, dass das Problem nicht auf eine Art von Software beschränkt war; es trat bei High-Performance-Computing-Projekten, bei Tools, die vom Journal of Open Source Software begutachtet wurden, und bei Paketen, die von der pyOpenSci-Community akzeptiert wurden, gleichermaßen auf.

Einer der häufigsten Gründe für diese Konflikte war eine spezifische Verwechslung zwischen der Software und dem Forschungspapier, das sie beschreibt. In vielen Fällen beschrieben die Dateien, die die Software beschreiben sollten, tatsächlich das akademische Papier über die Software. Beispielsweise konnte eine Datei den Titel einer Konferenzpräsentation oder den Autor eines Journalartikels auflisten, während eine andere Datei den Namen des Codes selbst aufführte. Dies geschah in der Hälfte der verifizierten Konflikte. Die Forscher merkten an, dass dies nicht unbedingt ein Fehler in der Art und Weise ist, wie die Dateien geschrieben wurden, sondern vielmehr ein Spiegelbild einer tieferen Verwirrung darüber ist, was das „zitierfähige Objekt“ eigentlich ist. Ist es der Code oder ist es das Papier über den Code? Wenn die Dateien versuchen, auf das Papier zu verweisen, hören sie oft auf, auf die Software zu verweisen, was dazu führt, dass die Metadaten auseinanderdriften.

Eine weitere Quelle der Unstimmigkeit waren die öffentlichen Register, in denen Software heruntergeladen wird, wie etwa PyPI für Python oder npm für JavaScript. Diese Register verwenden oft kurze, technische Namen für Pakete, wie zum Beispiel „mpi4py“, während die eigenen Dateien der Software einen beschreibenden Titel wie „MPI for Python“ verwenden. Wenn ein Computer versucht, diese beiden Oberflächen abzugleichen, sieht er eine Titelabweichung. Die Studie fand heraus, dass ein großer Teil der Titel- und Autoren-Unstimmigkeiten durch diese Registereinträge verursacht wurde. Darüber hinaus stellten die Forscher fest, dass die aktuellsten Informationen oft an den Stellen fehlten, an denen automatisierte Werkzeuge nach ihnen suchen. Die Dateien, die Packaging-Tools lesen, wie etwa die Registereinträge, waren am wenigsten wahrscheinlich in der Lage, persistente Identifikatoren wie ORCIDs für Autoren zu enthalten, die entscheidend für die Verfolgung dessen sind, wer die Arbeit geleistet hat.

Die Studie untersuchte auch eine spezifische Funktion namens „Preferred Citation“ (bevorzugtes Zitat), die es einem Softwareprojekt ermöglicht, den Nutzern anzuweisen, ein anderes Objekt zu zitieren, meist ein Papier statt der Software selbst. Die Forscher fanden heraus, dass in 28 von 32 Projekten, die diese Funktion nutzten, das Befolgen der Anweisung zu einem Datensatz führte, der mit den eigenen Metadaten der Software widersprach. Das bedeutet, dass selbst wenn ein Projekt versucht, den Nutzer zu einem spezifischen Zitat zu führen, die Anleitung oft auf einen Datensatz verweist, der mit den anderen Informationen kollidiert, die das Projekt über sich selbst veröffentlicht hat. Dies schafft eine Situation, in der ein Nutzer, der den Regeln folgt, am Ende ein Papier zitiert, das nicht mit der Version der Software übereinstimmt, die er tatsächlich verwendet hat.

Die Forscher kamen zu dem Schluss, dass die aktuelle Infrastruktur für die Software-Zitation unvollständig ist. Obwohl die Werkzeuge zur Deklaration von Metadaten existieren und weit verbreitet sind, gibt es kein System, das prüft, ob die verschiedenen Deklarationen übereinstimmen. Die Studie zeigte, dass die Software bei der Mehrheit der überprüfbaren Projekte mit sich selbst über mindestens ein kritisches Detail uneinig ist. Diese Fragmentierung führt dazu, dass die Anerkennung oft aufgeteilt ist, die Herkunft unklar bleibt und automatisierte Systeme die Verwendung von Forschungssoftware nicht zuverlässig verfolgen können. Die Forscher veröffentlichten ihre Daten, ihren Code und ihre Liste der Projekte, damit andere die Prüfung wiederholen, prüfen können, ob sich die Lage im Laufe der Zeit verbessert hat, oder die Daten nutzen können, um Werkzeuge zu entwickeln, die diese Inkonsistenzen automatisch beheben können. Die Arbeit unterstreicht, dass wir, bevor wir der digitalen Anerkennungskultur für Software voll vertrauen können, zuerst sicherstellen müssen, dass die Software an allen Orten, an denen sie spricht, eine einzige, konsistente Geschichte erzählt.