Aller au contenu

Partage des données et conservation à long terme

A/ Périodes, modalités, restrictions ou embargos

Les modalités de partage et d’archivage varient selon la nature des données. Pour une vue d’ensemble de la politique de partage, se reporter aux tableaux de synthèse de la partie précédente.

Les jeux de données du périmètre 1 sont essentiellement constitués de codes sources informatiques ou de données textuelles formalisées (TEI, XML, RDF).

A.1 Codes sources

Les codes informatiques de logiciels et scripts sont gérés sur la plateforme Gitlab proposée par Huma-Num. D’autre part, une partie des dépôts est gérée et diffusée sur la plateforme Github afin d’augmenter leur visibilité et faciliter d’éventuelles contributions extérieures (code, remontée de bugs). Cela vaut surtout pour les logiciels ayant un fort potentiel de réutilisation en dehors du contexte de Biblissima+, ou pour lesquels des contributions de développeurs ou utilisateurs extérieurs sont souhaitées ou se sont déjà produites par le passé (c’est notamment le cas de Collatinus, qui dispose d’une petite communauté). Les dépôts issus de « forks » seront par essence eux aussi gérés sur Github.

Suivant le temps disponible, les besoins de citabilité du jeu ou l’impact recherché pour la réutilisation, 3 stratégies peuvent être adoptées :

Stratégie 1 : archivage « instantané » sans ajout de métadonnées, identifiant citable SWHID

  • Les codes sources gérés sur une plateforme de gestion de code source (Gitlab de préférence, Github si le développement Open Source implique la communauté) peuvent être sauvegardés et archivés sur la plateforme via une commande de demande de sauvegarde à partir de l’url de l’entrepôt1.

  • Le code source est sauvegardé et l’archive lui attribue un identifiant standardisé SWHID qui permet de pointer sur une version précise du code source2.

Stratégie 2 : dépôt avec métadonnées et obtention d’un DOI citable (Zenodo)

  • Les codes sources gérés sur le Gitlab d’Huma-Num pourront être déposés manuellement sur Zenodo, afin d’obtenir un DOI et une description par des métadonnées.

  • Les codes sources gérés sur Github peuvent être déposés automatiquement à partir de chaque version formalisée dans la plateforme (tags).

Stratégie 3 : dépôts via HAL et métadonnées, obtention d’un identifiant citable SWHID et modérés

  • Les codes sources gérés sur le Gitlab d’Huma-Num pourront également être déposés manuellement sur l’archive ouverte HAL avec ajout de 3 fichiers texte (README, AUTHORS et LICENSE) et une fiche de métadonnées minimale3. Le dépôt via HAL est modéré, ce qui apporte une forte visibilité au code déposé et une citation fiabilisée.

A.2 Données du cluster de données et référentiels d’autorité

Les données du portail et des référentiels d’autorité sont partagées par les API et web services qui permettent d’extraire les données en totalité.

Des exports au format RDF de chaque référentiel seront réalisés à intervalles réguliers et déposés sur Zenodo. Ils feront l’objet de data papers dans des revues (par exemple Humanités numériques, Journal of Open Humanities Data, etc.).

A.3 Données sur Nakala

Même si ce n’est pas spécifiquement prévu au stade de la version initiale du PGD, il est possible que certaines données de Biblissima+ soient également déposées sur Nakala, soit pour bénéficier de ses fonctionnalités particulières de publication de collections (Nakala Press) soit pour produire des collections cohérentes en lien avec les équipes partenaires qui auraient fait le choix de cette plateforme (notamment pour certains corpus de textes ou de partitions encodés en TEI). Il est à noter que les données déposées dans Nakala peuvent faire l’objet d’un projet de préservation avancée dans le cadre d’une convention de partenariat passé entre Huma-Num et le CINES4. Ce service est accessible pour des corpus sélectionnés par le comité de liaison5.

B/ Méthodes et outils nécessaires pour accéder aux données et les utiliser

Les outils logiciels nécessaires pour accéder aux données et les utiliser varient selon les formats choisis. Pour le détail, se reporter aux tableaux synthétiques de la partie précédente. En règle générale, les données textuelles formalisées au format XML ou RDF sont lisibles avec un simple éditeur de texte basique. En revanche le volume de certains fichiers peut nécessiter l’emploi d’un logiciel spécifique optimisant la consultation ou l’interrogation des données (par exemple un triplestore pour les dumps RDF, ou un moteur de base de données de type BaseX ou eXist-db pour les fichiers XML volumineux).

C/ Attribution d’identifiants pérennes uniques

Les stratégies de dépôt des codes sources du périmètre 1 de Biblissima+ permettent de combiner les avantages des deux types d’identifiants pérennes et uniques offerts par l’état de l’art en matière d’identification de codes sources et de données : les identifiants extrinsèques et les identifiants intrinsèques. Les premiers utilisent un registre pour conserver la correspondance entre l’identifiant et l’objet identifié. Les seconds reposent sur un accord sur la méthode à employer pour les calculer. Ils peuvent donc se passer de registres et d’une autorité garante.6

Identifiants pérennes et uniques des codes sources

Les codes sources ou jeux de données déposés dans Zenodo ou Nakala se voient automatiquement attribuer un identifiant pérenne unique extrinsèque de type DOI. Les codes sources archivés dans Software Heritage bénéficient d’un identifiant pérenne intrinsèque SWHID doté des fonctionnalités nécessaires à la citation de code source, tout en restant indépendant de l’implémentation technique de la gestion du code source (contrairement aux identifiants apportés par les plateformes Github ou Gitlab qui restent techniquement dépendants des choix techniques de ces plateformes).

Identifiants pérennes des entités des référentiels gérés via Wikibase

Les identifiants des entités des référentiels d’autorité sont construits comme les entités Wikidata sous la forme d’identifiants numériques préfixés par la lettre Q (ex. Q2987). Ils sont générés par l’instance Wikibase administrée par l’équipe portail. Si un doublon est repéré parmi les entités des référentiels, la plateforme permet de fusionner les deux entités et une reconduction des identifiants concernés est assurée de façon automatique. Cette fusion peut se faire aussi bien manuellement via l’interface de la plateforme, qu’automatiquement via l’API de Wikibase.

Identifiants des données du portail

Un système d'identifiants pérennes ARK a été mis en place pour les pages du portail Biblissima+. Ces URL ARK sont basées sur des identifiants opaques alphanumériques (reposant sur l'algorithme SHA1) générés de façon automatique lors de la phase de traitement des entités.

Ces identifiants ne sont donc pas gérés par un logiciel spécifiquement dédié à la gestion d’ARK (ex. Noid) et n’implémentent pas toutes les fonctionnalités liées aux ARK (qualificatifs, inflexion pour accéder aux métadonnées). Ils ne s'appuient pas non plus sur un résolveur ARK externe de type N2T.net : ainsi le logiciel Cubicweb, qui propulse le portail Biblissima+, agit comme le résolveur local des ARK Biblissima. Le coût de mise en place d'une infrastructure complète de gestion des ARK a été jugé trop important dans le cadre d’un projet d'ÉquipEx d'une durée limitée. Cependant, il est envisagé de verser à la fin du projet tous les identifiants ARK Biblissima dans le résolveur ARK global N2T.net, voire de les migrer vers une autre solution de type DOI, de sorte que leur maintenance puisse être transférée à une autre entité institutionnelle (par exemple le porteur Établissement Public Campus Condorcet). En conséquence l’utilisation des identifiants Biblissima au sein des ressources et corpus fournis par les équipes partenaires constituent un enrichissement pérenne et d'interopérabilité entre ressources valables à long terme et au-delà du contexte de Biblissima+.

Si un doublon est repéré parmi les pages du portail, la fusion de l'ancien identifiant ARK avec le nouveau est faite manuellement. La redirection de l'ancienne URL vers la nouvelle s'appuie sur une table de redirection maintenue par l'équipe et paramétrée au niveau du serveur Web.

  1. Utilisation possible d’une API pour automatiser le processus. ↩

  2. Pour plus d’informations sur le schéma d’identifiants et la plateforme, voir la documentation : https://docs.softwareheritage.org/ ↩

  3. https://www.softwareheritage.org/2019/11/28/saving-and-referencing-research-software-in-software-heritage/?lang=fr ↩

  4. cf. https://documentation.huma-num.fr/nakala-faq/#lors-de-la-demande-de-preservation-a-long-term ↩

  5. https://documentation.huma-num.fr/partenariat-hn-cines/ ↩

  6. D’après https://bbf.enssib.fr/consulter/bbf-2021-00-0000-002 ↩

Dernière mise à jour: October 13, 2023