L’EAD3 et les conséquences de la nouvelle version – Naoned

L’EAD3 et les conséquences de la nouvelle version

Cet article est une traduction d’un article original publié sur le site web du projet APEx.

Résumé

L’EAD (Encoded Archival Description : Description archivistique encodée) a fait l’objet d’une révision majeure au cours de ces trois dernières années. Le présent article tente d’apporter un certain éclairage sur les objectifs de cette révision, sur les mesures prises ainsi que sur certains des changements envisagés pour l’EAD3. L’article traite ainsi des activités du sous-comité technique de la société des archivistes américains (SAA : Society of American Archivists) sur l’EAD (TS-EAD) jusqu’au début de février 2014, lorsque la version gamma de l’EAD3 a été dévoilée pour recevoir les dernières observations de la communauté EAD. La dernière partie de l’article fournit également une première évaluation de l’impact attendu d’une éventuelle évolution de l’EAD 2002 en EAD3, avec l’exemple du Portail européen des archives.

________________________________________________________________________________

Introduction

L’EAD, la norme la plus ancienne et sans doute la mieux établie en matière de description d’archives internationales, a fait l’objet d’une révision majeure au cours de ces trois dernières années. Au début du mois de février 2014, la troisième version du nouveau format EAD (EAD3) a été dévoilée par le sous-comité technique sur l’EAD (TS-EAD) de la société des archivistes américains (SAA), qui a maintenu la norme depuis sa première version remontant à la fin des années 1990. Cette version gamma de l’EAD3 est maintenant disponible pour recevoir les dernières observations de la communauté EAD jusqu’au 1er mars 2014.

L’évolution du schéma peut être suivie sur GitHub où il est également possible, pour les utilisateurs GitHub, de consulter les questions en suspens qui sont encore en cours de discussion et de signaler des problèmes supplémentaires trouvés dans la version gamma de l’EAD3. Toute personne qui n’est pas inscrite sur GitHub peut envoyer son commentaire via un formulaire.

En outre, on peut également trouver une version préliminaire de la bibliothèque de balises EAD3 – EAD3 Tag Library (version gamma) et la communauté EAD est invitée à fournir des instances tests encodées dans le format EAD3 gamma sur GoogleDrive. Ces instances tests incluent bien entendu également des commentaires (<!– [text] –>) afin de fournir des observations au TS-EAD sur les aspects qui pourraient ne pas être suffisamment clairs ou qui pourraient nécessiter une nouvelle révision et quelques précisions.

Objectifs de la révision de l’EAD

Lorsque le TS-EAD a entrepris de réviser l’EAD après une première demande de commentaires entre octobre 2010 et février 2011, plusieurs objectifs généraux ont été définis pour la révision.

Améliorer l’interopérabilité avec d’autres normes archivistiques

Il s’agit en particulier de l’EAC-CPF (Encoded Archival Context – Corporate Bodies, Persons, and Families : Contexte archivistique encodé – personnes morales, personnes et familles)[1], la norme de communication pour décrire des personnes, des familles et des personnes morales qui ont créé, conservé ou travaillé avec certains documents d’archives et échangé ces descriptions entre les différents systèmes source et cible. L’EAC-CPF avait déjà fait l’objet d’une révision et avait été publiée dans sa version actuelle en mars 2010, soit environ six mois avant le début du processus de révision de l’EAD. Un des objectifs de cette révision était donc d’orienter une nouvelle version de l’EAD vers les solutions trouvées lors de la création de l’EAC-CPF en ce qui concerne le codage de certains éléments d’information, tels que les dates et les données de contrôle sur les instances EAD elles-mêmes. Les autres normes internationales utilisées par la communauté archivistique et qui ont permis de se concentrer sur cet objectif étaient, entre autres, METS (Metadata Encoding & transmission Standard)[2] et PREMIS (Preservation Metadata : Implementation Strategies)[3].

Sinon, en examinant la façon dont les autres normes utilisent et codent certaines informations, une autre option pour améliorer l’interopérabilité de l’EAD avec ces normes serait d’inclure les correspondances des termes, ce qui pourrait ainsi rendre possible l’insertion de certaines données codées selon une autre norme dans un document EAD. Un troisième aspect de cette discussion visait l’amélioration de l’interopérabilité en définissant plus clairement et plus précisément que dans la version actuelle (l’EAD 2002[4]),où et comment les documents dans d’autres normes peuvent être liés ; c’est à dire, dans quel élément ces liens devraient être inclus, si un attribut doit être utilisé pour les spécifications et s’il doit y avoir une liste fixe de valeurs pour les attributs correspondants.

Améliorer intrinsèquement la facilité d’usage et les échanges en EAD

Le deuxième objectif concerne les divers aspects qui avaient été commentés par les membres de la communauté EAD au cours des premiers stades de la révision de l’EAD. L’EAD étant un cadre assez souple permettant de s’adapter à des circonstances, des besoins et des objectifs donnés, son usage n’est pas nécessairement identique d’une institution à une autre. Cela peut évidemment compliquer un échange de fichiers EAD entre différentes institutions, surtout lorsqu’il s’agit de cas où le même type d’informations est encodé dans différents éléments de l’EAD.

Ainsi, les commentaires reçus à cet égard demandent d’apporter plus de précisions quant à la façon de coder certaines informations, et, éventuellement, de réduire au minimum la quantité totale d’éléments. Cela concerne non seulement la question du référencement et du lien des éléments tels que les sous-éléments de <controlaccess> et leur relation avec les fichiers d’autorités externes pour ce qui est des noms, des index, des noms de lieux, etc. mais aussi la question de l’utilisation d’éléments comme la version numérotée et non numérotée des éléments <c> représentant les différents sous-composants au sein de la hiérarchie d’un fonds d’archives, d’une collection ou d’un autre autre type de groupe de dossiers.

Cet objectif nous a aussi permis de nous concentrer sur l’encodage des données plutôt que sur leur présentation, nous poussant à nous demander si les éléments de mise en forme, qui possèdent également des équivalents en HTML, comme <head>, <table>, <list> ou <emph>, devaient être conservés directement dans l’EAD ou plutôt laissés au format XSLT (Extensible Stylesheet Language Transformations) à des fins de présentation en ligne.

S’inscrivant dans la même lignée mais avec un point central différent, il a été suggéré de minimiser les options pour le contenu mixte, c’est à dire les éléments de l’EAD qui permettent d’avoir du contenu à côté de sous-éléments de marquage supplémentaire pour des parties de ce contenu. Exemple : l’encodage d’informations de langage concernant les éléments décrits dans le format :

tagging_picture1

 

 

 

 

Au lieu d’avoir simplement :

tagging_picture2

 

 

 

Cette dernière option poserait moins de problème en ce qui concerne, par exemple, l’importation d’informations dans une base de données utilisée localement.

Améliorer l’utilisation de l’EAD dans d’autres contextes

En ce qui concerne les évolutions actuelles dans le domaine de l’accès en ligne aux descriptions d’archives, pas seulement sur le site d’une institution propre, mais aussi dans des domaines, inter-domaines ou des projets et portails thématiques spécifiques (le Portail européen des archives par exemple), certaines améliorations, comme de rendre l’EAD plus interopérable pour les environnements multilingues, ont été mises à l’étude dans le cadre de la révision de l’EAD. En outre, le TS-EAD souhaite examiner la question de l’inclusion, ou au moins du référencement, du contenu généré par l’utilisateur, fournissant donc des lignes directrices sur la manière de procéder avec l’EAD.

Déroulement de la révision

Pour tous les changements possibles envisagés, la directive principale a non seulement été de créer et de définir une nouvelle version de l’EAD, mais également de définir et d’assurer la migration à partir des versions précédentes de l’EAD vers la nouvelle version. Étant donné que l’EAD a été utilisée dans le domaine des archives pendant près de deux décennies, il existe un grand nombre d’utilisateurs à travers le monde pour qui la nouvelle version doit offrir des améliorations et des possibilités supplémentaires pour le codage de descriptions archivistiques, ce qui dépasse de loin le défi que représentait le passage de l’EAD 2002 à l’EAD3.

Étapes franchies

Schéma N°1

Image 1 : Déroulement de la première invitation à formuler des commentaires au lancement de la version bêta de l’EAD3

Comme mentionné ci-dessus, le processus de révision a commencé avec une invitation à formuler des commentaires en octobre 2010. À la date butoir, en février 2011, plus de 120 commentaires avaient été reçus et regroupés en cinq sections : schéma et documentation, nature générale et objectif, relations aux ressources et aux entités liées, titre EAD et description archivistique. Cette dernière catégorie a en outre été structurée en sept sous-sections qui traitent des questions et des propositions relatives aux éléments hiérarchiques, éléments d’encapsulage, conditions d’accès contrôlé, objets d’archivage numérique, codages des dates, langues, scripts et autres éléments.

Les résultats de la phase de commentaires ont été présentés lors de la table ronde sur l’EAD organisée pendant la réunion annuelle de l’ASA à Chicago en août 2011. Les observations et les informations recueillies au cours de cette présentation ont été reprises lors d’une réunion de travail du TS-EAD en mars 2012, elle-même suivie de plusieurs conférences téléphoniques tout au long de l’année et d’une réunion de travail de l’équipe de développement du schéma (SDT : Schema Development Team) de l’ASA tenue en octobre 2012. La version alpha de la nouvelle EAD a vu le jour en février 2013 et une réunion de travail de l’équipe de la bibliothèque de balises pour l’EAD a été organisée sur cette base. Une deuxième phase de commentaires s’est ensuite achevée en avril 2013. De nouvelles conférences téléphoniques et d’autres réunions en face-à-face et en petit comité ont abouti à la version bêta de la nouvelle EAD en août 2013, juste à temps pour l’assemblée annuelle de la SAA à la Nouvelle Orléans.

Après la version bêta

La version bêta a une fois de plus, été suivie d’une période de test de deux mois pendant lesquels de nouveaux commentaires ont été recueillis et une réunion conjointe de la TS-EAD et du sous-comité technique de l’EAC-CPF (TS-EAC-CPF) à la Nouvelle Orléans en août 2013 a enfin donné un nom à la nouvelle version : EAD3. En plus de la présentation de la situation actuelle et du calendrier prévisionnel des tâches restantes à cette date pour permettre l’achèvement du processus de révision, la réunion conjointe a également traité de certaines questions en suspens, telles que les licences du schéma et de la bibliothèque de balises, l’utilisation du groupe d’éléments <relations>, etc.

Après cela, et après la fin de la collecte de commentaires à propos de la version bêta, le TS-EAD et ses sous-groupes ont continué à travailler sur l’analyse et le traitement de tous les bugs et commentaires reçus de la communauté EAD et de la liste de diffusion de l’EAD, ainsi que sur les points abordés durant les réunions traitant de la bibliothèque de balises, afin de décider des solutions pour les questions en suspens et de préparer le lancement de la version gamma. La version gamma de l’EAD3 étant maintenant entrée en phase de test, il reste peu de temps avant la finalisation de l’EAD3 et sa validation par les commissions compétentes de la SAA en vue d’une publication au cours du deuxième semestre 2014.

Schéma N°2(1)

Image 2 : Déroulement prévu pour les étapes restantes

En détails : les décisions prises à ce jour

Les décisions prises à ce jour sont nombreuses comme on pouvait s’y attendre après plus de trois années de travail, d’évaluations et de commentaires détaillés envoyés par la communauté EAD, y compris en ce qui concerne le lancement de la version bêta de l’EAD3.

Elles peuvent être regroupées de la façon suivante :

  • décisions prises à l’égard de certains éléments
  • décisions prises à l’égard de certains types de données
  • décisions prises à l’égard du rapprochement avec l’EAC-CPF
  • décisions prises sur les aspects généraux
  • décisions prises sur des aspects spécifiques
  • décisions prises à l’égard de nouveaux éléments et d’éléments qu’il est recommandé de ne plus utiliser

Décisions relatives à certains éléments

Un des éléments qui a été discuté plus en détail est l’élément englobant <c> pour la description des sous-composantes d’une unité archivistique, tels que des séries, des fichiers ou des éléments d’un fonds ou d’une collection. Dans l’EAD 2002, cet élément peut être utilisé sous forme numérotée avec des options de <c01> à <c12> , créant ainsi un système de classification de 13 niveaux, incluant <archdesc> comme le niveau de description de l’unité la plus élevée dans un certain contexte. Cependant, <c> peut également être utilisé non numéroté, ce qui crée un système hiérarchique encore plus profondément structuré. Comme les deux options sont largement utilisées, de manière plus ou moins équivalente, décider de conserver l’une ou l’autre aurait généré un défi majeur pour une bonne partie de la communauté EAD dans le contexte du passage de l’EAD 2002 à l’EAD3. Par conséquent, il a été décidé de conserver les deux.

Un autre sujet important pendant le processus de révision a été l’utilisation d’éléments d’indexation ou d’accès contrôlé tels que <persname>, <geogname>, <corpname>, etc. et leur utilisation pour le référencement des fichiers d’autorité nationaux et internationaux externes pour certains groupes de termes. La version alpha de février 2013 a essayé de faire une distinction entre les éléments de codage de noms, par exemple :

tagging_picture 5

Et les éléments pour le référencement de noms de vocabulaires externes, par exemple :

tagging_picture 6

Toutefois, cela revenait encore une fois à proposer deux éléments différents pour des utilisations similaires, la version bêta est donc revenue sur ce point et l’utilisation générale des éléments <*name> dans les deux cas a donc été décidée. Partout dans l’EAD3 où sont fournis <persname>, <geogname>, etc., un sous-élément <part> est maintenant obligatoire ; il permet par exemple de faire la distinction entre les noms et les prénoms via l’attribut @localtype et de référencer des vocabulaires externes.

La version gamma étant conçue pour mieux prendre en charge les applications légères de données liées, les éléments <controlaccess> (name, subject, geogname, function, occupation et title) ont donc tous les attributs suivants :

  • @source [URI ou une chaîne pour le nom du référenciel d’où provient ce terme]
  • @rules [URI ou une chaîne pour les règles par lesquelles un terme est défini]
  • @identifier [URI ou une chaîne pour le terme]
  • @relator [URI ou une chaîne pour un terme de relation, et un chemin de migration pour@role de l’EAD 2002, qui a été supprimé de ces éléments, éliminant ainsi tout risque de collision sémantique avec la définition xlink de @role]
  • @localtype [URI ou une chaîne pour toute autre sous-classes locale] »[5]

Décisions relatives à certains types de données

Le modèle de contenu pour plusieurs éléments a fait l’objet de discussions lors de la révision, en particulier en ce qui concerne les possibilités d’avoir des paires structurées/non structurées pour coder certaines données. Cela devrait, d’une part, créer une plus grande interopérabilité avec les bases de données, et d’autre part, permettre de récupérer directement certaines informations. Les décisions prises à cet égard concernent les éléments suivants (entre autres) :

– <unitdate>, utilisé pour coder la date de création de l’unité archivistique décrite, la contrepartie <unitdatestructured> sera créée. Cette dernière intègrera une structure similaire à celle des dates dans l’EAC-CPF, en fournissant des sous-éléments tels que <datesingle> et <daterange> avec <fromdate> et <todate> pour coder les dates simples et des plages de dates. En outre, l’élément <dateset> sera disponible pour créer diverses combinaisons avec les deux éléments susmentionnés. Les deux façons d’encoder les dates seront activées pour englober les formats de date normalisés comme <unitdate> le fait déjà dans l’EAD 2002.
Avec le lancement de la version gamma, la « validation de modèle pour les attributs de normalisation [sic] de date a été supprimée. Un schéma Schematron séparé sera fourni pour valider les attributs de date par rapport à la norme ISO 8601. Les modèles ont été retirés pour permettre l’utilisation de normes de date alternatives. »[6]

– De manière similaire, <physdesc> sera désormais accompagné de <physdescstructured> . Alors que le premier élément est destiné à être utilisé avec une information textuelle simple, le deuxième comprend déjà les sous-éléments connus (et quelques nouveaux) pour coder la description physique d’une unité archivistique. Tandis que les éléments <dimensions> et <physfacet> restent plus ou moins inchangés, <extent> et <genreform> en tant que sous-éléments de <physdescstructured> seront tous les deux remplacés par une combinaison d’éléments obligatoires <quantity> (qui peut être laissé vide et qui, dans la version gamma de l’EAD3, accepte les attributs @approximate) et <unittype>. Si l’utilisateur a l’intention de coder l’étendue d’une unité archivistique, c’est-à-dire l’espace que cette unité occupe dans le répertoire de l’institution ou les caractéristiques physiques ou de genre de l’unité, le nouvel élément <physdescstructured> doit être défini comme « spaceoccupied » ou « materialtype ». Plusieurs informations relevant de la description physique (ex : deux éléments <physdescstructured> ou plus) peuvent en outre être regroupées avec un autre élément nouveau : <paralellphysdescset>.

– Les informations sur la langue du support peuvent désormais être codées en suivant une approche plus distinctive pour les langues et les scripts. <langmaterial> permet la réunion de l’information de la langue avec le sous-élément répétable <language>, qui n’inclut plus maintenant qu’un attribut de codage de la langue conformément à la norme ISO 639-2b, ou alors permet aussi de fournir des informations sur la/les langue(s) et script(s) présents dans l’unité archivistique décrite. Cette dernière option qui combine les éléments <language> et <script> dans un nouvel élément englobant <languageset>, permet également à l’utilisateur de coder là où il peut y avoir plusieurs langues avec un seul script, ou inversement :

tagging_picture 7

Tandis que <langmaterial> n’accepte plus de contenu, il existe un nouveau sous-élément <descriptivenote> qui prévoit la possibilité de fournir des informations sur la/les langue(s) et script(s) d’une manière plus explicite.

– Les éléments servant à coder des données sur le créateur d’archives (<origination>) et sur l’institution qui détient et qui gère le support (<repository>) ont également échangé leurs modèles de contenu mixte contre des modèles de données plus précis, permettant de référencer des sources et des référentiels externes fournissant des informations supplémentaires. Ces éléments exigent désormais un sous-élément du groupe de <corpname>, <famname>, <name> et <persname>, ce dernier étant seulement applicable pour <origination>. L’élément <repository> comprend en outre le sous-élément <address> pour les coordonnées de contact. Le sous-élément <descriptivenote> qui avait été activé pour les deux éléments dans la version bêta de l’EAD3, « a été retiré de <origination> et de <repository> car peu utilisé »[7] dans la version gamma de l’EAD3.

Décisions relatives au rapprochement avec l’EAC-CPF

En dehors de relatifs petits changements tels que les options supplémentaires de codage de dates pour <unitdatestructured> comme mentionné ci-dessus, le rapprochement avec l’EAC-CPF a également introduit deux des plus grands changements de l’EAD3. Tout d’abord, l’élément <eadheader> pour les données bibliographiques et d’autres informations sur l’outil de recherche (versions imprimées et codées) remplacé par <control> pour les données administratives sur le fichier EAD lui-même. Comparativement à l’EAC-CPF, l’EAD3 conservera cependant l’élément <filedesc> dans <control> pour les métadonnées bibliographiques telles que le titre de l’outil de recherche, l’auteur, l’éditeur, la date et le lieu de publication. La version gamma de l’EAD3 a aussi « restauré @langencoding, @scriptencoding, @dateencoding, @countryencoding et @repositoryencoding dans <control>. Chacun de ces attributs peuvent être définis sur les valeurs par défaut de l’EAD 2002 ou sur « autre ».[8]

En dehors de <filedesc>, l’élément <control> englobe différents sous-éléments d’information de maintenance liés à l’instance de l’EAD. Alors que l’EAC-CPF utilise des listes fixes de valeurs pour certains de ces éléments, l’EAD3 « a déplacé les valeurs des éléments énumérés pour <publicationstatus>, <maintenancestatus>, <agenttype> et <eventtype> […] vers un attribut de « valeur » pour permettre l’utilisation d’autres langues dans les éléments eux-mêmes ».[9] Ce changement pourrait aussi être réexaminé par la TS-EAC-CPF.

Un autre ajout provenant de l’EAC-CPF est l’élément <relations> avec ses différents sous-éléments pour coder les relations entre l’unité archivistique décrite dans l’instance EAD et, par exemple, les personnes, les personnes morales et les familles décrites dans une instance EAC-CPF ou d’autres ressources.

« Dans l’EAD3, <relations> sera considéré comme un élément « expérimental », non inclus dans le schéma officiel. Un schéma séparé et incluant <relations> pour les implémentations de l’EAD qui l’utilisent est disponible. Cette disposition est un compromis entre le désir de fournir une fonctionnalité de liens entre les données plus robuste, introduite par <relations> dans l’EAC-CPF, et certaines préoccupations selon lesquelles <relations> pourrait dupliquer les fonctionnalités déjà disponibles au sein de <controlaccess> et que la mise en œuvre réussie de <relations> pourrait dépendre de référenciels externes encore sous-développés. »[10]

Décisions relatives aux aspects généraux

En ce qui concerne les aspects généraux de la révision, la question des noms d’éléments orthographiques et d’attributs et celle de la documentation doivent être détaillées dans deux exemples. La version alpha de la nouvelle EAD préconisait un changement de l’orthographe en employant la « CamelCase » (pour tous les éléments et attributs constitués par deux ou plusieurs termes, le deuxième et le troisième de ces termes doivent commencer par une lettre majuscule.) Ex : <unitdate> serait devenu <unitDate>. Bien que cette norme figure parmi les meilleures pratiques actuelles pour la définition XML et qu’elle a aussi été utilisée lors de la définition de l’EAC-CPF, tout l’historique que l’EAD (contrairement à l’EAC-CPF par exemple) en termes d’utilisation et d’utilisateurs, a conduit à revenir sur cette pratique dès la version bêta. Autrement, les possibilités pour une rétro-compatibilité aurait été trop restreintes.

Une autre suggestion concernant la version alpha faisait part de la nécessité de mieux souligner la documentation des changements ; c’est-à-dire de ne plus seulement utiliser la bibliothèque de balises pour décrire et résumer les changements effectués entre l’EAD 2002 et l’EAD3, mais aussi de documenter les changements dans le nouveau schéma lui-même. Les versions bêta et gamma ont donc été toutes deux publiées avec une bibliothèque de balises mise à jour.

Décisions relatives à certains aspects spécifiques

Afin de mieux prendre en charge l’échange de fichiers EAD, en particulier dans des environnements multilingues, tous les éléments de l’EAD3 pouvant contenir des informations textuelles permettent l’utilisation des attributs @lang et @script. Avec ces attributs, la langue et le script à appliquer au contenu d’un élément peuvent être encodés. En outre, le nouvel élément <foreign> a été introduit pour permettre le balisage intraligne de la langue et du script de seulement une partie d’un texte, par exemple :

tagging_picture 8

Pour ce qui est de l’objectif de préciser comment et où utiliser certains éléments, l’EAD3 vient en outre « sortir » des éléments tels que <arrangement> (dorénavant « élément frère » et non plus sous-élément de <scopecontent>), <legalstatus> (nouvel « élément frère » et non pas sous-élément de <accessrestrict>) et <unitdate> (dorénavant « élément frère » et non plus sous-élément de <unittitle>). De même, les différents éléments <note> ont été renommés en fonction de leur contexte, par exemple <didnote> lorsqu’utilisé dans le cadre de description d’identification <did> ; <controlnote> lorsqu’utilisé avec des vocabulaires contrôlés ; <descriptivenote> lorsqu’utilisé comme des informations descriptives supplémentaires spécifiquement dans l’élément <control> ; <footnote> lorsqu’utilisé comme tel.

Le dernier changement à aborder ici est intervenu entre la version bêta et gamma. Il fait référence à l’élément <daogrp>, l’un des éléments qu’il a été recommandé de ne plus utiliser.

« En réponse aux commentaires demandant le retour de <daogrp> durant la bêta, […] [les développeurs ont créé] <daoset>, qui englobe deux ou plusieurs éléments <dao>. Cet ajout reconnaît la nécessité de lier plusieurs éléments <dao> mais élimine toujours le modèle de lien étendu lourd et peu utilisé de <daogrp>. Au sein de <dao>, <daodesc> a été remplacé par <descriptivenote>. Cela a été fait par souci de simplicité : <descriptivenote> était déjà disponible ailleurs dans le schéma et accepte un ou plusieurs <p>, plutôt que <daodesc>, qui accepte <head>,<list>, <table> et d’autres éléments de bloc, mais […] dont on a trouvé presque aucune occurence. En outre, @coverage (avec les valeurs « whole » ou « part ») [a été ajouté] à <dao>. »[11]

Décisions relatives aux nouveaux éléments et aux éléments qu’il est recommandé de ne plus utiliser

Comme dans tous les processus de révision de l’EAD jusqu’à présent, certains nouveaux éléments et attributs ont été ajoutés et quelques éléments actuels de l’EAD 2002 vont être écartés. Le premier groupe comprend les ajouts suivants :

  • @containerid avec <container> pour fournir un identifiant, par exemple de la boîte ou du dossier dans lequel le support est logé ;
  • @instanceurl avec <recordid> pour inclure l’URL du XML-EAD ;
  • <representation> comme élément frère de <recordid> pour inclure l’URL de n’importe quel genre de représentation (HTML, PDF, etc.) de l’instance de l’EAD ;
  • <geographiccoordinates> comme sous-élément de <geogname> pour permettre l’encodage des coordonnées géographiques d’un lieu ou d’une région selon des systèmes d’encodage tels que WGS84, OSGB36 ou ED50.

Parmi les éléments qui seront écartés figurent <frontmatter> (information de page de titre formatée), les éléments de regroupement <eadgrp>, <archdescgrp>, <dscgrp>, <descgrp>, <daogrp> et <linkgrp> ainsi que <runner> et <note>. En outre, il sera recommandé de ne plus utiliser les sous-éléments de <bibref> (c’est-à-dire <bibseries> et <imprint>)

Package de livraison pour l’EAD3

Lorsque l’EAD3 sera publié au second semestre 2014, le schéma mis à jour sera accompagné d’une feuille de style de migration pour une transition générale de l’EAD 2002 vers l’EAD3. Ces documents seront mis à disposition sous la licence CC0 tandis que la bibliothèque de balises, tout comme la troisième partie de la publication, optera pour CC-BY. Cette dernière résumera le processus de révision et les résultats obtenus, définira les éléments et attributs de l’EAD3 et fournira des passerelles pour les autres normes ainsi que des exemples de codage. De plus, les schémas Schematron seront fournis pour utilisation avec certaines données normalisées, comme par exemple les dates selon la norme ISO 8601.

Impact de la révision de l’EAD sur le portail européen des archives

Comme tout projet de réseau d’envergure, l’APEx (Archives Portal Europe network of excellence) a rigoureusement suivi le processus de révision en vigueur. Plusieurs membres du projet sont aussi membres du TS-EAD, du TS-EAC-CPF et de l’équipe de développement de schéma, et le dossier de travail du projet sur les normes et directives a activement fourni des recommandations pour les versions alpha et bêta jusqu’à présent. Il reste à savoir quand et dans quelle mesure l’EAD3 sera adoptée par l’APEx et le portail européen des archives, mais les réponses à ces questions sont actuellement fortement dépendantes du calendrier définitif du processus de révision en corrélation avec la durée de vie du projet.

Utilisation de l’EAD par le portail européen des archives

Un profil central de l’EAD a été défini pour le portail européen des archives appelé apeEAD. Ce profil se base sur une comparaison de l’utilisation actuelle et de l’utilisation de l’EAD dans les pays partenaires et les institutions du prédécesseur de l’APEx, le projet APEnet (2009-2012). Il est actuellement en train d’être adapté (et d’autres outils sont en cours de développement) pour le portail européen des archive (ex : nouvelles fonctionnalités centrales ou expansion du réseau de fournisseurs de contenu et donc du nombre de formats de données d’origine utilisables.

Pour ce qui est des présentations et des fonctionnalités centrales, l’apeEAD est utilisé comme format cible pour la conversion de formats de données locales et pour la validation, en tant que base pour la présentation centrale et l’index de recherche et en tant que base pour d’autres conversions, par exemple vers l’EDM (Europeana Data Model) pour l’échange de données d’archivage avec le portail inter-domaines Europeana.

Avec l’EAD jouant un rôle central dans le système du portail européen des archives pour l’échange et la diffusion des descriptions archivistiques, l’analyse de l’impact de la transition vers l’EAD3 doit tenir compte des aspects principaux suivants :

  • Les avantages et les possibilités offertes par la nouvelle version doivent s’équilibrer avec la charge de travail résultant de son adaptation.
  • L’impact possible, sur la structure centrale elle-même, mais aussi sur les fournisseurs de contenu du portail et sur les agrégateurs nationaux, doit être pris en compte.

Schéma N°3(2)

Image 3 : Système du portail européen des archives et utilisation de l’EAD

Changements nécessaires et aspects à considérer

Le principal défi généré par la transition de l’EAD 2002 à l’EAD3 sera sans doute le changement qui touchera <eadheader> <control> puisque cela affectera dans une certaine mesure les données de maintenance qui sont utilisées pour la gestion des données dans le back-end du portail européen des archives. Cela fait spécifiquement référence au passage de <eadid> en tant qu’identifiant du fichier EAD à <recordid> puisque l’ajout de certains éléments obligatoires dans cette partie, comme par exemple <maintenancestatus>, peut probablement être traité à l’aide de valeurs par défaut généralement applicables.

En outre, certains des sous-éléments de <did> ont été modifiés, comme mentionné ci-dessus, l’affichage et éventuellement l’index de recherche devront être adaptés, et peut-être même aussi certaines parties des feuilles de conversion qui ont été développées. Cela fait référence à des éléments tels que <origination> et <repository> comportant des sous-éléments obligatoires ou à <physdesc> et <physdescstructured>. En ce qui concerne <unitdate>, il serait d’abord nécessaire d’évaluer les avantages éventuels de l’utilisation de sa nouvelle version structurée ; autrement, conserver le format actuel de <unitdate> avec @normal est l’option la plus probable. De plus petites modifications, telles que <note> dans <did> donnant donc <didnote>, ne devraient pas poser de problèmes trop importants ; il en sera peut-être de même pour <extref> et <extptr> qui ne sont plus utilisés et qui devront donc être modifiés en <ref> et <ptr>. Les éléments frères de <did> (par exemple, <scopecontent>, <bioghist>, etc.) restent essentiellement inchangés.

Dans tous les cas, le principal intérêt pour le portail européen des archives réside dans les possibilités de l’EAD3 pour ce qui est du codage de contenu multilingue avec les attributs @lang et @script. Aussi, le codage plus structuré offert avec l’élément <relations> pourrait représenter un vrai plus en ce qui concerne la création d’un corpus plus souple de différents types de données pour le portail européen des archives ou d’autres ressources externes. Quant à la possibilité d’avoir un codage plus structuré pour certaines données, il reste à voir dans quels cas cela pourrait être un avantage pour le portail européen.

Les options sont nombreuses et beaucoup de choses pourraient et peuvent être réalisées grâce à l’EAD3, et le dossier du projet APEx traitant des normes et des lignes directrices présentera sûrement une analyse plus détaillée de la nouvelle version de l’EAD une fois qu’elle sera officiellement adoptée et publiée, ce qui pourrait conduire à une possible mise à jour de l’apeEAD basée sur EAD3, en préparation pour recevoir les modifications techniques finales.

______________________________________________________________________________

  1. Voir la bibliothèque de balises, le schéma, des exemples relatifs à l’EAC-CPF et plus encore sur http://eac.staatsbibliothek-berlin.de/ (consulté le 10 février 2014).
  2. Voir le schéma, la documentation, les profils et des exemples de METS sur http://www.loc.gov/standards/mets/ (consulté le 10 février 2014). 
  3. Voir l’état actuel de PREMIS et toute la documentation liée sur http://www.loc.gov/standards/premis/ (consulté le 10 février 2014). 
  4. Voir les informations sur l’EAD 2002 ainsi que sur la version précédente : l’EAD 1.0 sur http://www.loc.gov/ead/ (consulté en février 2014). 
  5. Co-président du TS-EAD, Michael Rush,  bibliothèque Beinecke Rare Book & Manuscript Library de l’université de Yale, dans son courriel envoyé à la liste de diffusion de l’EAD (EAD@listserv.loc.gov) le 6 février 2014 à propos du lancement de la version gamma de l’EAD3. 
  6. Courriel rédigé par le co-président du TS-EAD, Michael Rush, le 6 février 2014, à propos du lancement de la version gamma de l’EAD3.
  7. Idem.
  8. Idem.
  9. Idem.
  10. Idem.
  11. Idem.

 

Partagez
0 commentaire(s) on L’EAD3 et les conséquences de la nouvelle version

Post a comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *