A Multi-Surface Consistency Audit of Software Citation Metadata
Questo articolo esamina 117 progetti di software di ricerca open-source attraverso molteplici superfici di metadati leggibili dalle macchine e rileva che l'83,9% presenta almeno un conflitto nei campi principali, causato principalmente da discrepanze tra le descrizioni del software e i relativi record di pubblicazione.
Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Nel mondo della scienza moderna, il software è diventato essenziale quanto un microscopio o un telescopio. È lo strumento che i ricercatori usano per elaborare numeri, simulare il cambiamento climatico e modellare il comportamento degli atomi. Poiché questo software è un prodotto del lavoro umano e dell'impegno intellettuale, la comunità scientifica ha concordato che meriti di essere citato, proprio come un articolo di ricerca. Quando uno scienziato utilizza un programma specifico per fare una scoperta, deve dare credito alle persone che l'hanno scritto, alla versione utilizzata e al luogo in cui è possibile trovarlo. Per rendere possibile questo, è stato costruito un sistema in cui i progetti software possono lasciare dietro di sé dei "cartellini del nome" digitali. Questi cartellini sono file leggibili dalle macchine che contengono il titolo del progetto, i nomi dei suoi autori, il numero di versione e un identificatore unico che indica dove risiede il software online. L'idea è che se un ricercatore, un bibliotecario o un programma informatico esamina uno qualsiasi di questi cartellini, essi racconteranno tutti la stessa storia sullo stesso pezzo di software.
Tuttavia, uno studio recente ha posto una domanda semplice ma inquietante: questi cartellini del nome concordano effettivamente tra loro? I ricercatori, guidati da Pengyin Shan dell'Università dell'Illinois, hanno deciso di sottoporre un audit alle auto-descrizioni digitali di 117 progetti di software di ricerca open-source. Hanno esaminato sette luoghi diversi in cui un progetto potrebbe descrivere se stesso: un file specifico destinato alle citazioni, un file di dati per gli archivi, un record in un registro pubblico dove il software viene scaricato e il testo sulla pagina web principale del progetto. Hanno trattato il software come l'oggetto singolo e questi vari file come diverse "superfici" o facce di quell'oggetto. Se il sistema funziona perfettamente, ogni superficie dovrebbe dire la stessa cosa. Se dissentono, si crea confusione su chi abbia svolto il lavoro, quale versione sia stata utilizzata e dove trovare il codice. Lo studio ha scoperto che il sistema è tutt'altro che perfetto. In effetti, la maggior parte dei progetti esaminati raccontava storie diverse a diverse parti di internet.
I ricercatori hanno costruito un processo accurato per controllare questi progetti. Hanno raccolto un gruppo di 117 strumenti software, inclusi strumenti di calcolo ad alte prestazioni utilizzati per il supercomputing e il calcolo quantistico, nonché un gruppo più piccolo di strumenti che erano stati accettati da riviste della comunità. Per ogni progetto, hanno scaricato degli snapshot delle sette diverse superfici in un singolo giorno. Hanno poi utilizzato un programma per normalizzare le informazioni, traducendo i diversi formati di file in un elenco comune di sei fatti chiave: il titolo, l'autore, la versione, l'anno, la licenza e l'identificatore unico. Hanno confrontato ogni coppia di superfici esistenti per un progetto per vedere se i fatti corrispondevano. Per garantire l'accuratezza del loro metodo, hanno controllato manualmente un ampio campione dei giudizi del computer, confermando che il loro strumento era corretto quasi al 99 percento.
I risultati hanno rivelato una significativa mancanza di coerenza. Tra i 117 progetti, solo 62 avevano almeno due superfici confrontabili. Tra questi 62 progetti, 52, ovvero circa l'84 percento, contenevano almeno un conflitto importante tra le loro superfici. Ciò significa che, per la maggior parte di questi progetti, una persona che legge il file di citazione otterrebbe informazioni diverse rispetto a qualcuno che legge il record dell'archivio o la pagina di download. I disaccordi erano più comuni negli elenchi degli autori e nei titoli del software. Mentre l'anno e la licenza erano solitamente coerenti, i dettagli fondamentali che identificano l'opera spesso non corrispondevano. Lo studio ha scoperto che il problema non era limitato a un tipo di software; appariva nei progetti di calcolo ad alte prestazioni, negli strumenti revisionati dal Journal of Open Source Software e nei pacchetti accettati dalla comunità pyOpenSci.
Uno dei motivi più comuni di questi conflitti era un errore specifico tra il software e l'articolo di ricerca che lo descriveva. In molti casi, i file destinati a descrivere il software stavano in realtà descrivendo l'articolo accademico relativo al software. Ad esempio, un file poteva elencare il titolo di una presentazione a una conferenza o l'autore di un articolo di una rivista, mentre un altro file elencava il nome del codice stesso. Questo accadeva in metà dei conflitti verificati. I ricercatori hanno osservato che questo non è necessariamente un errore nel modo in cui i file sono stati scritti, ma piuttosto il riflesso di una confusione più profonda su cosa sia l' "oggetto citabile". È il codice, o è l'articolo che parla del codice? Quando i file cercano di puntare all'articolo, spesso smettono di puntare al software, causando la deriva dei metadati.
Un'altra fonte di disaccordo proveniva dai registri pubblici dove il software viene scaricato, come PyPI per Python o npm per JavaScript. Questi registri utilizzano spesso nomi brevi e tecnici per i pacchetti, come "mpi4py", mentre i file del software utilizzano un titolo descrittivo come "MPI for Python". Quando un computer cerca di far corrispondere queste due superfici, rileva una discrepanza nel titolo. Lo studio ha scoperto che una grande parte dei disaccordi su titoli e autori era guidata da questi record di registro. Inoltre, i ricercatori hanno scoperto che le informazioni più aggiornate erano spesso mancanti nei luoghi in cui gli strumenti automatizzati cercano. I file che gli strumenti di packaging leggono, come i record dei registri, erano i meno propensi a contenere identificatori persistenti come gli ORCID per gli autori, che sono cruciali per tracciare chi ha svolto il lavoro.
Lo studio ha anche esaminato una funzione specifica chiamata "citazione preferita", che consente a un progetto software di dire agli utenti di citare un oggetto diverso, solitamente un articolo, invece del software stesso. I ricercatori hanno scoperto che in 28 dei 32 progetti che utilizzavano questa funzione, seguire l'istruzione portava a un record che discordava dai metadati del software stesso. Ciò significa che anche quando un progetto cerca di guidare gli utenti verso una citazione specifica, la guida punta spesso a un record che entra in conflitto con le altre informazioni che il progetto ha pubblicato su se stesso. Questo crea una situazione in cui un utente che segue le regole potrebbe finire per citare un articolo che non corrisponde alla versione del software che ha effettivamente utilizzato.
I ricercatori hanno concluso che l'attuale infrastruttura per la citazione del software è incompleta. Sebbene esistano gli strumenti per dichiarare i metadati e siano ampiamente utilizzati, non esiste un sistema in grado di verificare se le diverse dichiarazioni concordino tra loro. Lo studio ha dimostrato che per la maggior parte dei progetti che possono essere controllati, il software è in disaccordo con se stesso su almeno un'informazione critica. Questa frammentazione significa che il credito è spesso diviso, la provenienza è poco chiara e i sistemi automatizzati non possono tracciare in modo affidabile l'uso del software di ricerca. I ricercatori hanno rilasciato i loro dati, il loro codice e la loro lista di progetti affinché altri possano ripetere l'audit, controllare se le cose siano migliorate nel tempo o utilizzare i dati per costruire strumenti in grado di correggere automaticamente queste incongruenze. Il lavoro evidenzia che prima di poter fidarsi pienamente del sistema di credito digitale per il software, dobbiamo prima assicurarci che il software racconti una storia singola e coerente in tutti i luoghi in cui parla.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.