Méta OpenCitations : Méthodologie

Tableau des liens

• Résumé et introduction
• Travaux connexes
• Méthodologie
• Données et services
• Discussion
• Conclusion, remerciements et références

3. Méthodologie

OpenCitations Meta est alimenté à partir de données d'entrée au format CSV (c'est-à-dire sous forme de tableau). Ce choix n’est pas accidentel. Nous avons constaté que les données exposées par OpenCitations au format CSV (par exemple à partir de COCI (OpenCitations, 2022)) sont téléchargées plus fréquemment, par rapport aux mêmes données dans des formats plus structurés (c'est-à-dire JSON Scholix et RDF N-Quads). Cela est dû à la taille du fichier plus petite (par rapport à N-Quads et Scholix) et, surtout, à la plus grande lisibilité du format tabulaire pour un humain. Ce dernier est la principale raison pour laquelle le format d'entrée adopté par OpenCitations Meta est CSV, afin de faciliter le futur crowdsourcing de métadonnées bibliographiques issues des activités de conservation humaines (Heibi et al., 2019a).

La table d'entrée d'OpenCitations Meta comporte onze colonnes, correspondant à une linéarisation de l'OCDM (Daquino et al., 2020) : identifiant, titre, auteur, éditeur, date de publication, lieu, volume, numéro, page, type et éditeur. Pour une description détaillée de la façon dont chaque domaine est structuré, veuillez consulter (Massari & Heibi, 2022).

Une fois les données tabulaires CSV acquises, les données sont d'abord automatiquement organisées (étape Curateur), puis converties en RDF sur la base de l'OCDM (étape Créateur). Enfin, les CSV et RDF organisés sont stockés sous forme de fichiers, tandis qu'un triplestore correspondant est rempli de manière incrémentielle. La figure 2 résume le flux de travail.

3.1 Curateur : déduplication, enrichissement et correction

Le processus de curation effectue trois actions principales pour améliorer la qualité des données reçues : la déduplication, l'enrichissement et la correction.

L’approche choisie pour la déduplication des données repose strictement sur les identifiants. En d'autres termes, deux entités différentes sont considérées comme identiques si, et seulement si, toutes deux ont le même identifiant, par exemple un DOI pour les articles, un ORCID pour les personnes, un ISBN pour les livres et un ISSN pour les lieux de publication (par exemple les revues).

Différentes ressources portant le même identifiant sont fusionnées selon une règle précise : (1) si les ressources font partie du même fichier CSV, l'information de la première occurrence est privilégiée. Cependant (2) si la ressource est déjà décrite dans le triplestore, les informations du triplestore seront privilégiées. En d’autres termes, nous considérons les informations stockées dans le triplestore comme fiables, et elles ne peuvent être incrémentées qu’avec des données supplémentaires provenant d’une source CSV.

Une fois qu'une entité est dédupliquée, un nouvel identifiant interne permanent lui est attribué, appelé OpenCitations Meta Identifier (OMID). L'OMID a la structure [entity_type_abbreviation]/[supplier_prefix][sequential_number]. Par exemple, le premier article de revue jamais traité porte l'OMID br/0601, où br est l'abréviation de « ressource bibliographique » et 060 correspond au préfixe du fournisseur, qui indique la base de données à laquelle appartient la ressource bibliographique (dans ce cas, OpenCitations Méta). Enfin, 1 indique que cet OMID identifie la première ressource bibliographique de l'index jamais enregistrée pour ce préfixe.

Plus précisément, le préfixe du fournisseur utilisé pour OpenCitations Meta est « 06[1-9]*0 », c'est-à-dire « 06 » éventuellement suivi de n'importe quel nombre excluant zéro et d'un « 0 » à la fin. Par exemple, « 060 », « 0610 » et « 06230 » sont des préfixes de fournisseur valides dans OpenCitations Meta.

Les entités soumises à la déduplication et ensuite identifiées avec un OMID sont des identifiants externes (abr. id), des rôles d'agent (c'est-à-dire auteurs, éditeurs, abr. ar), des agents responsables (c'est-à-dire des personnes et des organisations, abr. ra), les modes de réalisation des ressources (c'est-à-dire les pages, abr. re), et les lieux, volumes et numéros (qui sont tous des ressources bibliographiques, abr. br). Les volumes et les numéros ont des OMID car ils sont traités comme des citoyens de première classe, et non comme des attributs d'articles. Cela présente l'avantage de permettre, par exemple, de rechercher les articles d'un numéro spécifique, les volumes d'une revue nommée ou les numéros de revues publiés au cours d'une certaine période. En revanche, les titres et les dates sont traités comme des valeurs littérales et non comme des entités.

La figure 3 illustre l'arbre décisionnel de déduplication. Étant donné une entité d’entrée et ses identifiants, il existe six résultats possibles :

1. Si l'entité n'a pas d'identifiant ou s'ils n'existent pas dans le triplestore, alors un nouvel OMID est créé pour l'entité ;

   
   

2. Si l'entité ne possède pas d'OMID, et si l'un de ses identifiants externes a déjà été associé à une et une seule autre entité, alors les deux entités sont fusionnées et traitées comme les mêmes ;

   
   

3. Si les identifiants externes de l'entité dans le CSV connectent deux entités ou plus au sein du triplestore qui étaient jusqu'à présent distinctes, et qu'aucun OMID n'est spécifié dans le CSV, alors un conflit survient qui ne peut pas être résolu automatiquement et nécessitera une intervention manuelle. Un nouvel OMID est créé pour cette entité conflictuelle. Par exemple, dans le CSV, le même nom de revue est associé à deux identifiants, issn : 1588-2861 et issn : 0138-9130 ; cependant, dans le triplestore, il y a des entrées pour deux entités distinctes, l'une avec l'identifiant issn:1588-2861 et l'autre avec l'identifiant issn:0138-9130, qui font en réalité référence à la même entité ;

   
   

4. Si une entité dans le CSV a un OMID qui existe dans le triplestore et qu'aucun autre ID n'est présent, les informations du triplestore écrasent celles du CSV. Le triplestore est ensuite mis à jour uniquement par l'ajout des détails manquants. En d’autres termes, spécifier son OMID pour une entité dans le CSV est un moyen de mettre à jour une entité existante dans OpenCitations Meta ;

   
   

5. Si une entité possède un OMID existant et que des identifiants supplémentaires sont associés à d'autres entités sans OMID (dans le CSV) ou avec le même OMID (dans le CSV ou le triplestore), alors les entités sont fusionnées. De plus, les informations du CSV sont écrasées par celles déjà disponibles dans le triplestore, et les détails manquants présents dans le CSV sont ensuite ajoutés au triplestore ;

   
   

6. Enfin, si des identifiants externes connectent plusieurs entités du triplestore avec des OMID différents, alors un conflit survient. Dans ce cas, l'OMID spécifié dans le CSV est prioritaire et seules les entités portant cet OMID sont fusionnées.

Compte tenu de ces règles générales, trois cas particuliers méritent une attention particulière. Le premier problème notable concerne l’ordre des auteurs et éditeurs, qui doit être maintenu selon l’OCDM. En cas de fusion, l'ordre enregistré lors de la création initiale de l'entité écrase les suivants et tout nouvel auteur ou éditeur est ajouté à la fin de la liste existante, comme le montre la figure 4.

Deuxièmement, dans le cadre de la fusion de deux ressources bibliographiques, les personnes impliquées en tant qu'auteurs ou éditeurs sans identifiant sont levées d'ambiguïté sur la base de leurs prénoms et noms de famille.

Le dernier cas significatif concerne la relation de confinement entre les articles, les numéros, les volumes et les lieux. Cette structure est conservée dans le cas d'une fusion, où deux volumes ou numéros sont considérés comme identiques seulement s'ils ont la même valeur, qui peut être un numéro séquentiel (par exemple « Volume 1 ») ou un nom arbitraire (par exemple « Clin_Sect » ).

3.2 Conservateur : vérification des erreurs

Une fois que toutes les entités ont obtenu un OMID, les données sont normalisées et les erreurs pouvant être traitées automatiquement sont corrigées. Tous les identifiants sont vérifiés en fonction de leur système d'identification – par exemple, l'exactitude syntaxique des ISBN, ISSN et ORCID est calculée à l'aide de formules spécifiques fournies par la documentation du système d'identification. Cependant, l'exactitude sémantique des identifiants n'est vérifiée que pour les ORCID et les DOI, ce qui se fait à l'aide d'API ouvertes pour vérifier leur existence réelle – puisque, par exemple, il est possible de produire un ORCID qui est syntaxiquement valide, mais qui ne l'est pas en fait. attribué à une personne.

Tous les caractères ambigus et alternatifs utilisés pour les espaces (par exemple tabulation, espace insécable, espace em) sont transformés en espace (caractère Unicode U+0020). De même, les caractères ambigus pour les traits d'union dans les identifiants, les pages, les volumes, les numéros, les auteurs et les éditeurs (par exemple les traits d'union insécables, le tiret, le signe moins) sont remplacés par un trait d'union moins (caractère Unicode U+002D).

Concernant les titres des ressources bibliographiques (colonnes « lieu » et « titre »), chaque mot du titre est en majuscule à l'exception de ceux qui contiennent des majuscules (qui sont probablement des acronymes, par exemple « FaBiO » et « CiTO »). Cette exception ne couvre cependant pas le cas des titres entièrement en majuscules. La même règle s’applique également aux auteurs et éditeurs, qu’ils soient particuliers ou organisations.

Les dates sont analysées en tenant compte à la fois de la validité du format, basé sur la norme ISO 8601 (AAAAMM-JJ) (Wolf & Wicksteed, 1997), et de la valeur (par exemple, le 30 février n'est pas une date valide). Le cas échéant, la date est tronquée. Par exemple, la date 2020-02-30 est transformée en 2020-02 car le jour de la date donnée n'est pas valide. de même, le 2020-27-12 sera tronqué à 2020 puisque le mois (et donc le jour) n'est pas valide. La date est supprimée si l'année n'est pas valide (par exemple, une année supérieure à 9999).

La correction des numéros de volumes et de numéros repose sur de nombreuses règles qui méritent une mention particulière. En général, nous avons identifié six classes d'erreurs pouvant survenir, et chaque classe différente est traitée en conséquence :

1. Numéro de tome et numéro de numéro dans le même champ (ex. « Vol. 35 N° spécial 1 »). Les deux valeurs sont séparées et affectées au champ correspondant.

2. Erreurs de préfixe (par exemple « .38 »). Le préfixe est supprimé.

   
   

3. Erreurs de suffixe (par exemple « 19/ »). Le suffixe est supprimé.

   
   

4. Erreurs d'encodage (par exemple « 5â\x80\x926 », « 38â39 », « 3???4 »). Seuls les chiffres aux extrémités sont conservés, séparés par un seul trait d'union. Par conséquent, les exemples sont corrigés respectivement en « 5-6 », « 38-39 » et « 3-4 », puisque « â\x80\x92 », « â » et « ??? » sont des traits d’union mal codés.

   
   

5. Volume classé comme numéro (par exemple « Volume 1 » dans le champ « numéro »). Si le modèle de volume est trouvé dans le champ « problème » et que le champ « volume » est vide, le contenu est déplacé vers le champ « volume » et le champ « problème » est défini sur null. Cependant, si le champ « issue » contient un modèle de volume et que le champ « volume » contient un modèle de problème, les deux valeurs sont inversées.

   
   

6. Numéro classé en volume (par exemple « Numéro spécial 2 » dans le champ « volume »). Il est traité de la même manière que le cas 5, mais dans des rôles inversés.

Nous avons considéré comme volumes les modèles contenant les mots « série originale », « volume », « vol » et volume dans diverses autres langues, par exemple « tome » en français et « cilt » en turc. Par exemple, « Original Series », « Volume 1 », « Vol 71 », « Tome 1 » et « Cilt : 1 » sont classés comme volumes. Au lieu de cela, nous avons considéré comme numéros les modèles contenant les mots « numéro », « numéro spécial » et numéro dans diverses langues, par exemple « horssérie » (numéro spécial en français) et « özel sayı » (numéro spécial en turc). Par exemple, le « numéro 2 », le « numéro spécial 2 », le « numéro spécial « Morphologie urbaine » », « Özel Sayı 5 » et « Hors-série 5 » sont classés comme numéros.

Enfin, dans le cas où une valeur est à la fois invalide dans son format et invalide parce qu'elle se trouve dans le mauvais champ, alors cette valeur est d'abord corrigée puis déplacée vers le bon champ, le cas échéant.

Une fois les données d'entrée levées, enrichies et corrigées, un nouveau fichier CSV est produit et stocké. Ce fichier représente la première sortie du processus (3a sur la figure 2).

3.3 Créateur : cartographie sémantique

Dans cette phase, les données sont modélisées en RDF suivant l'OCDM (Daquino et al., 2020). Cette ontologie réutilise les entités définies dans les ontologies SPAR pour représenter les entités bibliographiques (fabio:Expression), les identifiants (datacite:Identifier), les rôles d'agent (pro:RoleInTime), les agents responsables (foaf:Agent) et les détails du format de publication (fabio:Manifestation). . Le rôle d'agent (c'est-à-dire auteur, éditeur ou éditeur) est utilisé comme intermédiaire entre la ressource bibliographique et l'agent responsable, c'est-à-dire la personne ou l'organisation. Cette approche nous aide à définir des rôles et des statuts dépendants du temps et du contexte, comme l'ordre des auteurs (Peroni et al., 2012). La figure 5 représente les relations entre les différentes entités à travers le cadre graphique Graffoo (Falco et al., 2014).

Par exemple, dans OpenCitations Meta, l'entité avec l'OMID omid:br/062601067530 a le titre Open Access And Online Publishing : A New Frontier In Nursing ? (dcterms:title), et a été publié le 25/07/2012 (prism:publicationDate). En utilisant FRBR (Tillett, 2005), l'article est la version finale publiée, ou une expression de l'œuvre originale (fabio:Expression), qui a comme échantillon l'entité omid:re/06260837633 (frbr:embodiment), c'est-à-dire le publication imprimée correspondant aux pages 1905-1908 du volume du journal (prism:startingPage, prism:endingPage). Plus précisément, l'article fait partie (frbr:partOf) du numéro (fabio:JournalIssue) numéro 9 (fabio:hasSequenceIdentifier), contenu dans le volume (fabio:JournalVolume) numéro 68 de la salle Journal Of Advanced Nursing (fabio:Journal ).

De plus, la personne (foaf:Agent) Glenn Hunt (foaf:givenName, foaf:familyName) est le premier auteur (pro:RoleInTime) dans le cadre de cet article (pro:isDocumentContextFor). De même, le deuxième auteur est Michelle Cleary (pro:hasNext).

Enfin, cette publication possède l'OpenCitations Meta Identifier (OMID) omid:id/062601093630 (datacite:hasIdentifier), une entité de type datacite:Identifier. Il possède également un identifiant externe, qui utilise comme schéma d'identification un identifiant d'objet numérique (DOI) (datacite:usesIdentifierScheme) et qui a la valeur littérale « 10.1111/j.1365- 2648.2012.06023.x » (littéral :hasLiteralValue).

Une fois le mappage terminé, les données RDF produites peuvent être stockées (4a sur la figure 2) et téléchargées sur un triplestore (4b sur la figure 2).

3.4 Créateur : provenance et suivi des modifications

En plus de gérer leurs métadonnées, une grande importance est accordée à la provenance et au suivi des modifications des entités dans OpenCitations Meta. La provenance est un enregistrement indiquant qui a traité une entité spécifique en la créant, la supprimant, la modifiant ou la fusionnant, quand cette action a été effectuée et quelle était la source principale (Gil et al., 2010). Garder une trace de ces informations est crucial pour garantir la fiabilité des métadonnées dans OpenCitations Meta. En effet, la vérité d'une déclaration sur le Web et le Web sémantique n'est jamais absolue, et l'intégrité doit être évaluée par chaque application qui traite l'information en évaluant son contexte (Koivunen & Miller, 2001).

Cependant, outre le stockage des informations de provenance, les mécanismes permettant de comprendre l'évolution des entités sont essentiels lorsqu'il s'agit d'activités telles que les exercices d'évaluation de la recherche, où les modifications, dues à des corrections ou à des spécifications erronées, peuvent affecter l'évaluation globale d'un chercheur, d'un groupe de recherche ou d'un chercheur. toute une institution. Par exemple, le nom d'un établissement peut changer au fil du temps, et le reflet de ces changements dans une base de données « rend difficile l'identification de tous les noms et unités de l'établissement sans aucune connaissance de l'histoire de l'établissement » (Pranckut˙e, 2021). Ce scénario peut être évité en suivant l'évolution des données dans la base de données, permettant ainsi aux utilisateurs de comprendre cette dynamique sans accéder à des connaissances de base externes. À notre connaissance, aucune autre base de données sémantique de métadonnées scientifiques ne conserve la trace des changements et de la provenance dans le standard RDF 1.1.

Le mécanisme de provenance employé par OpenCitations décrit un instantané de création initial pour chaque entité stockée, potentiellement suivi d'autres instantanés détaillant la modification, la fusion ou la suppression des données, chacun marqué de son numéro d'instantané, comme résumé dans la figure 6.

Concernant la représentation sémantique, le problème de la modélisation de la provenance (Sikos & Philp, 2020) et du suivi des modifications en RDF (Pelgrin et al., 2021) a été discuté dans la littérature scientifique. À ce jour, aucune norme partagée ne permet d’atteindre ces deux objectifs. Pour cette raison, OpenCitations utilise les approches les plus largement partagées, à savoir les graphes nommés (Carroll et al., 2005), la Provenance Ontology (Lebo et al., 2013) et le Dublin Core (Board, 2020).

En particulier, chaque instantané est connecté au précédent via le prédicat prov:wasDerivedFrom et est lié à l'entité qu'il décrit via prov:specializationOf. De plus, chaque instantané correspond à un graphe nommé dans lequel sont décrites les métadonnées de provenance, à savoir l'agent responsable (prov:wasAttributedTo), la source primaire (prov:hadPrimarySource), l'heure de génération (prov:generatedAtTime) et, après le génération d'un instantané supplémentaire, l'heure d'invalidation (prov:invalidatedAtTime). Chaque instantané peut également éventuellement être représenté par une description en langage naturel de ce qui s'est passé (dcterms:description).

De plus, le modèle de provenance OCDM ajoute un nouveau prédicat, oco:hasUpdateQuery, décrit dans l'ontologie OpenCitations (Daquino & Peroni, 2019), qui exprime le delta entre deux versions d'une entité via une requête SPARQL UPDATE. La figure 7 affiche le modèle via un diagramme Graffoo.

Le processus de déduplication décrit à la section 3.1 s'effectue non seulement sur l'état actuel de l'ensemble de données mais sur l'ensemble de son historique en appliquant le mécanisme de suivi des modifications. En d'autres termes, si un identifiant peut être retracé jusqu'à une entité supprimée du triplestore, cet identifiant sera associé à l'OMID de l'entité supprimée. Si la suppression est due à une chaîne de fusion, l'OMID de l'entité résultante est prioritaire. Pour en savoir plus sur la méthodologie des requêtes temporelles, voir (Massari & Peroni, 2022). Pour plus de détails sur l'interface de programmation permettant de créer des données et de suivre les modifications selon les ontologies SPAR, consulter (Persiani et al., 2022).