Révision de l'EAD : travaux du groupe AFNOR suite à la réunion du TS-EAD à Yale
Claire Sibille (SIAF) a piloté le 21 mars 2012 une réunion conjointe des groupes AFNOR EAD (GE3) et EAC-CPF (GE4).
I – Rappel sur le rôle du TS-EAD et calendrier de révision
Le sous-comité technique pour l’EAD (TS-EAD) de la Society of American archivists, co-présidé par Michael Rush (Université de Yale) et William Stockting (British Library) a été créé en 2010. Une équipe restreinte (SDT) est chargée du développement et de la maintenance technique des formats d’échange de la SAA et présidée par Terry Catapano (université Columbia). Claire Sibille est membre du TS-EAD, Florence Clavaud est membre de la SDT.
- 1e réunion du TS-EAD : congrès annuel de la SAA à Washington (août 2010).
- Appel à commentaires (octobre 2010-mars 2011) + enquête sur les pratiques d’encodage
- Restitution des commentaires et des résultats de l’enquête : congrès de Chicago (août 2011).
- Examen en détail des commentaires lors de la réunion du TS-EAD à la Beinecke Library, université de Yale, New Haven, les 7-9 mars 2012.
Calendrier prévu pour la suite du processus de révision de l’EAD :
- réunions téléphoniques et travaux par sous-groupes pour étudier les points non évoqués à Yale, avril-juillet 2012
- réunion de l'équipe de développement, juillet 2012
- finalisation des décisions de révision, juillet 2012 [Cette date est jugée très optimiste par le GE3/4]
- diffusion des décisions auprès de la communauté professionnelle, août 2012, Congrès de la SAA (San Diego) et Congrès international des archives (Brisbane)
- diffusion d'une version alpha et appel à commentaires, août 2012
- diffusion d'une version beta et appel à commentaires, 15 janvier 2013
- prise en compte des commentaires par le TS-EAD, janvier-mars 2013
- réunion éditoriale sur la Tag Library, fin février-début mars 2013
- diffusion de la version finale du schéma et de la documentation, août 2013, Congrès de la SAA, Nouvelle-Orléans
II – Relevé des décisions prises par le TS-EAD et réactions des GE3 et 4
Schéma et documentation
1. Laisser à l'ICA le soin de développer un modèle conceptuel (ontologie) sur lequel pourrait se baser l'EAD 2013.
GE 3 et 4 : risques de problèmes de synchronisation entre le développement d’un modèle conceptuel et la révision de l’EAD.
2. L'EAD 2013 sera un schéma développé en RelaxNG ; des versions dérivées (W3C XML schéma, DTD) seront également diffusées.
3. Des outils de conversion automatiques seront fournis pour le transfert des données, comme ce fut le cas entre les première et deuxième versions de l’EAD.
4. Dictionnaire des balises et site web officiel : on partirait sur un document structuré en TEI, maintenu à l’aide d’un entrepôt.
5. L’élaboration d’un manuel technique n’est pas du ressort du TS-EAD mais de la Table ronde EAD (SAA) et des institutions désirant implémenter l’EAD.
Nature et objectifs généraux
6. Les demandes d’ajout/d’évolution doivent être soigneusement évaluées par le TS-EAD
7. Objectifs généraux définis par Michael Fox : « Le comité identifiera, dépréciera ou supprimera les éléments qui relèvent seulement de la présentation et non pas de la description archivistique, réduira les contenus mixtes et supprimera les éléments qui sont les restes de l’environnement SGML. Ces modifications rendront les instances EAD plus constantes dans leur contenu et, partant, plus faciles à échanger, à présenter et à interpréter ; plus simples et moins coûteuses à mettre en œuvre et à maintenir, et plus simples dans leur gestion dans différents environnements électroniques. »
8. L’EAD devra être rendue plus compatible avec les bases de données. Réduire les contenus mixtes quand c’est possible et pratique.
GE3 et 4 : Il existe un danger à aller trop loin en ce sens. Les instruments de recherche doivent pouvoir être conçus comme des textes. L’EAC-CPF ne comprend qu’un seul élément avec du contenu mixte, Segment de texte <span>, « qui sert à encoder les mots ou les phrases que l’on souhaite mettre en valeur, soit à des fins de style, soit pour souligner certaines propriétés spécifiques de ces mots ou phrases ». C’est trop pauvre.
9. Elimination de <eadgrp>, <archdescgrp> et <dscgrp>
10. Utilisation des éléments de mise en forme : remplacer <blockquote> par un élément <div>, division de texte, regroupant plusieurs paragraphes.
GE3 et 4 : il est suggéré d’introduire plutôt un élément <quote> sur le modèle de la TEI.
Florence Clavaud préconise la mise à disposition d’un modèle riche, préservant du contenu mixte là où c’est nécessaire et pertinent, et un modèle « light », plus adapté à des besoins plus simples, sériels, avec une architecture de base de données. Il fait tenir compte de la variabilité du texte encodé.
11. Tout attribut @type utilisant une liste fermée de valeurs doit avoir un nom spécifique, et n’est pas un @type générique ; tout attribut @type qui n’est pas une liste fermée est appelé @localtype.
12. Etudier comment le contenu généré par les utilisateurs peut être incorporé et identifié. Sont à prendre en compte les contrôles, la validité, l’assimilation scientifique des données ainsi générées. Il faut faire en sorte que les données provenant des utilisateurs ne soient pas sur le même plan que les autres mais clairement identifiées.
GE3 et 4 : l’ajout d’un élément @resp pour indiquer que telle ou telle partie d’instrument de recherche a été produite par un tel ou un tel nécessiterait peu de modélisation. Un élément <span> avec deux attributs, un pour l’auteur, un pour la validation des données, pourrait être une solution.
13. Valeurs locales dans les listes de valeurs des attributs : l’ajout d’une valeur valeur "other" et d’un attribut @other pour pouvoir définir des listes locales risque d’entraîner des problèmes de compatibilité. Le TS-EAD examinera l’utilisation des attributs par rapport à l’utilisation des valeurs disponibles.
Relations avec d’autres entités
14. Liens vers des ressources et des entités en relation : ajouter une section sur les relations inspirée de l’EAC-CPF (<resourceRelation>, <cpfRelation> et <functionRelation>) au niveau de <archdesc> et au niveau de tous les composants ; passer à xlink (comme dans l’EAC-CPF) et simplifier les mécanismes de liens (ne permettre que xlink:type="simple", supprimer les groupes de liens étendus, supprimer la distinction entre liens internes et externes, supprimer tous les attributs de lien de <title>
15. Insertion de données valides provenant d’autres espaces de nom XML : identifier les emplacements réservés à l'utilisation d'autres espaces de noms via l'élément Enveloppe d'objet XML <objectXMLWrap>.
16. Aligner les éléments de l’EAD avec ceux de l’EAC-CPF dans la mesure du possible
17. <bioghist> : maintenir cet élément dans l'EAD et fournir des exemples de bonne utilisation.
GE3 et 4 : comment apparier dans une instance EAD un <origination> contenant plusieurs <persname>, <corpname>, etc. et plusieurs <bioghist> ? <origination> ne devrait-il pas contenir le nom du producteur suivi d’une notice biographique/historique ?
18. Une utilisation de l’EAD seule doit rester possible : le format doit permettre et faciliter la séparation du contexte et de la description archivistique, mais sans que cela soit obligatoire.
En-tête EAD
19. Faire évoluer l’élément En-tête EAD<eadheader> en élément Contrôle <control> de manière à suivre au plus près le modèle de l’élément <control> de l’EAC-CPF.
GE 3 et 4 : <control> doit répondre à deux besoins : les métadonnées de l’instrument de recherche et le contrôle de la description, réparti, décliné entre les différents niveaux de la description. Le groupe Bonnes pratiques de l’EAD dans les bibliothèques recommande l’utilisation de <editionstmt> pour des modifications très importantes de l’instrument de recherche, <revisiondesc> étant réservé aux corrections de détail. Il est important de ne pas perdre la notion d’instrument de recherche. Il faut aussi traiter l’instance EAD comme un objet électronique susceptible d’être modifié. Il faut distinguer le contenu de la description et les métadonnées de préservation (informations sur le format informatique utilisé et sa traçabilité).
Il ne faut pas supprimer <titlestmt> ; le nom de l’élément <control> pose problème, il faudrait créer un élément englobant une notice bibliographique de l’instrument de recherche et un autre élément relatif au contrôle de la description.
20 et 30. Suppression de <frontmatter> : le TS-EAD y est favorable.
GE3 et 4 : l’utilisation de <frontmatter> doit être découragée dans l’encodage courant mais pourquoi s’en priver pour des conversions rétrospectives ? Il faudrait simplement supprimer <titlepage>.
21. Contenu de <eadid> : maintenu tel quel pour l’instant, sous réserve de la refonte de <eadheader> en <control>.
GE3 et 4 : s’agit-il du contenu de l’élément ou de l’attribut ? La tendance générale actuelle semble être de privilégier l’attribut et de ne pas renseigner l’élément, mais la logique base de données voudrait que l’on fasse porter l’obligation de contenu textuel sur l’élément.
22. Rejet de la proposition de créer des attributs facultatifs @file et @title dans <ead> pour extraire plus facilement les informations d'une instance EAD
23. Mention de plusieurs auteurs d’un instrument de recherche dans <titlestmt> : l’adoption du modèle EAC-CPF pour les événements de mise à jour (<maintenanceEvent>) pourrait permettre d’isoler les auteurs pour plusieurs événements liés à la création de l'instance EAD.
GE3 et 4 : la solution proposée (associer systématiquement un événement <eventType> à un auteur <agent> est plus complexe que ce qui était demandé. D’autres groupes (PREMIS notamment) ont déjà adressé ce problème.
24. Date d’élaboration d’un instrument de recherche ? Faut-il distinguer maintenance intellectuelle de la description et maintenance technique de l’instance EAD : le TS-EAD choisit le statu. L’adoption du modèle EAC-CPF pour les événements de mise à jour (<maintenanceEvent>) devrait permettre de régler le problème.
25. Clarifier le rôle de <descrules> et de <processinfo>
GE3 et 4 : il faudrait donner plus de granularité à <processinfo> pour pouvoir répondre au besoin de contrôle des différents niveaux de description.
26. Rejet de la proposition consistant à permettre d’enregistrer la taille d’une instance EAD : implémenter à la place <otherRecordId> et <localControl>.
27. Implémenter <otherRecordId> et <localControl> comme dans l'EAC- CPF pour marquer la présence d’éléments <dao> dans une instance EAD :
28. Ajouter les éléments <name> et <num> à l’élément <change> dans <revisiondesc>, sous réserve de l’évolution de <eadheader> en <control>
29. Supprimer <p> de <editionstmt>, <publicationstmt> et <seriestmt> ?
GE3 et 4 : il faudrait maintenir <editionstmt> et <publicationstmt> (voir commentaires n° 19 et 22), supprimer <seriestmt>).
31. Permettre l’enregistrement d’identifiants de notices s’appliquant à l’instance EAD dans différents systèmes.
Description archivistique – Éléments hiérarchiques
32. <archdesc> : maintien des éléments des description archivistique spécifique [contrairement à la proposition consistant à faire de <archdesc> un élément enveloppant uniquement des <c>] ; suppression de <runner>.
GE3 et 4 : si l’on supprime <dsc>, le maintien de <archdesc> se justifie moins (le plus haut niveau de description serait englobé dans un <c>). Ne faudrait-il pas d’ailleurs changer le nom de la balise Composant <c> en « unité de description » ?
33. Déprécier <dsc> et supprimer <dsc> des <c>.
34. Maintien des composants numérotés (<c01>, <c02>, etc.).
35. Maintien du statu quo concernant l’attribut @level qui n’est pas rendu obligatoire sauf au haut niveau.
36. Visibilité ou non des données au niveau du nœud ou du composant : l’EAD dispose de l’attribut @audience="internal". Il serait préférable d’indiquer qu’une partie de la collection n’est pas encore traitée, plutôt que de cacher complètement son existence.
GE 3 et 4 : il faudrait repenser @audience, ouvrir cet attribut à d’autres valeurs que internal/external, voir aussi comment utiliser <processinfo>, prévoir un attribut sur le statut de la rédaction.
Description archivistique – Éléments englobants
37. Revoir le rôle et le modèle de contenu de <did> et de ses éléments :
GE3 et 4 : il est regrettable de supprimer <unitdate> de <scopecontent> et de <unittittle> (utilisé pour encoder les dates constituant à elles seules un intitulé).
38. Revoir le rôle et le modèle de contenu de <physdesc> et de ses éléments : comparer le jeu d'éléments de <physdesc> avec les spécifications de ArchiveSpace pour l'importance matérielle.
GE3 et 4 : pourquoi seulement Archivespace ? Il existe d’autres outils et modèles. <genreform> connaît trois utilisations différentes dans les bibliothèques : type de document (image ou texte), typologie intellectuelle (album, journal intime, nouvelle…) et type technique (dans <physfacet>).
39. Déprécier <descgrp> et supprimer la récursivité des éléments <accessrestrict>, <accruals>, <acqinfo>, <bioghist>, <scopecontent>
Points d’accès contrôlés
40. Granularité dans l’encodage de <controlaccess> et des points d’accès : créer un élément <part> générique et répétable avec un attribut @type pour les éléments enfants de <controlaccess>. ; motion pour revoir le besoin d'une séparation sémantique des éléments enfants de <controlaccess>.
GE3 et 4 : il faut garder la séparation sémantique des <persname>, <famname>, corpname> et plus généralement tenir compte des deux régimes d’indexation différents (via <controlaccess> et au fil du texte). ; ce serait une fausse simplification qui n’apporterait rien ; la notion de <subject> gagnerait à être clarifiée (entités nommées ? mots-matières ?) ; l’utilisation de <part> ne doit pas être rendue obligatoire et s’accompagner de recommandations de bonnes pratiques.
41. Gestion des coordonnées géographiques : revoir le modèle sous-jacent des informations spatiales, en s’inspirant du modèle EAC-CPF pour <place>.
42. Modifier le type de données de l'attribut @source de NMTOKEN en xsd:string de sorte qu'un URI puisse être ajouté comme valeur ; reporter la discussion sur le renommage de l'attribut @authfilenumber ; revoir les éléments ayant un attribut @source et envisager d'inclure des identifiants
Description archivistique - Objets archivistiques numériques
43. Rendre les éléments <dao> et <daogrp> disponibles dans <altformavail> ? Selon le TS-EAD, cette proposition est recevable si elle vise à pouvoir distinguer les substituts numériques et les documents nativement numériques ; la solution serait plutôt la création d’un nouvel attribut obligatoire précisant si on a affaire à un original ou à une copie ; si la demande vise à pouvoir générer un lien direct vers l’objet numérique, elle doit être rejetée, un élément <ref> pointant vers le <c> approprié est la solution la plus adéquate.
GE3 et 4 : accrocher le lien ailleurs est très gênant, avec <ref> on désémantise l’information, si on remplit <dao> avec des liens, pourquoi ne pas tout dire dans <altformavail> ?
44. Rejet de la proposition permettant à <dao> de contenir les métadonnées sur l’objet numérique en relation (ou de s’y référer) : plutôt rendre possible l'import de métadonnées PREMIS ou METS. Les métadonnées techniques ne relèvent pas de la description archivistique ; il est recommandé d'utiliser <dao> pour les documents numériques appartenant au fonds et d'utiliser <resourceRelation> pour faire des relations avec des documents externes.
GE3 et 4 : METS pointe plutôt vers l’EAD (lien inverse de ce qui est suggéré).
45. Ajouter un identifiant d’objet archivistique numérique, étudier les détails du mécanisme avec les relations avec d'autres ressources.
46. Rejet d'une proposition consistant à développer des options valides pour localiser les éléments <dao>. Supprimer <dao> de <did> et de scopecontent>, laisser <dao> seulement dans <archdesc> et <c>.
Description archivistique - Encodage des dates
47. Reprendre le modèle EAC-CPF pour l’encodage des dates. Eliminer les valeurs par défaut des attributs @calendar et @era, clarifier dans la documentation que ces attributs se réfèrent au contenu de l'élément, pas aux données normalisées.
GE3 et 4 : pourquoi ne pas maintenir ces valeurs par défaut pour ne pas obliger à les ressaisir ?
Description archivistique – Langues et codes d’écriture
48. Permettre de spécifier la langue et l’écriture des informations contenues dans les éléments contenant du PCDATA (attributs @xml:lang, @scriptCode).
Description archivistique – Autres éléments
49. Modèle de données de <address> et utilisation de <addressline> : adopter le modèle utilisé dans l’EAC-CPF pour <address> ; limiter l'utilisation de <address> dans <repository> et dans ce qui remplacera <publicationstmt>.
50. Rejet d'une proposition tendant à rendre <scopecontent> disponible dans <archref> pour pouvoir citer correctement des sources archivistiques complémentaires. Solution : encoder <archref> dans <relatedmaterial> ou <separatedmaterial>, qui contient un <p> dans lequel les informations de présentation du contenu seraient mieux placées. Cette proposition pose des questions sur la manière dont l’EAD gère plus généralement les relations avec d’autres ressources.
51. Supprimer <archref>, <bibref> et <title> de <container>, <langmaterial>, <materialspec>, etc. Il s’agit d’un héritage de la conception de la DTD. A faire si le processus de révision le permet.
52. Supprimer <acqinfo> de <custodhist> et de <accessrestrict> ; retirer <legalstatus> de <accessrestrict>, en faire un élément enfant de <archdesc> et de <c> et lui donner le même modèle de données que <accessrestrict> ; retirer <arrangement> de <scopecontent>.
53. Permettre un encodage simplifié des index ? Une simple structure list/item pourrait être utilisée pour répondre au besoin exprimé dans cette demande. Faut-il déprécier <index> en faveur de l’utilisation de <list> ?
54. Simplifier le modèle de contenu des éléments <list>, <chronlist>. Déprécier l’attribut @continuation dans <list>.
55. Conserver l’élément <odd>
GE3 et 4 : utilisé dans les bibliothèques pour des descriptions d'imprimés.
56. Clarifier l’utilisation de <processinfo> et confirmer le mapping avec ISAD(G).
57. Résoudre le problème de normalisation des titres avec des articles initiaux ? Rejeter la proposition (le problème est plutôt lié au système qui ne tient pas compte de l’article initial).
58. Granularité dans l’encodage des éléments de titre : plutôt que de complexifier <title>, il serait préférable d’envisager des imports depuis les espaces de noms MARC ou MODS.
-----------------
Par ailleurs, de petits groupes ont été constitués au sein du TS-EAD pour approfondir les points vus de manière rapide au cours de la réunion de Yale :
1. <control>
2. considering <control> at every level
3. relations model in EAC-CPF for EAD
4. semantic separation of <controlaccess> elements
5. sources/bibliography/citation
6. @type
7. <origination>, <repository> content models
8. Dates content model
9. <bioghist> content model
10. Geocoding options
11. @authfilenumber name
Michael Rush a posté sur la liste internationale EAD le lien vers la documentation élaborée pour la réunion de Yale :
http://www2.archivists.org/groups/technical-subcommittee-on-encoded-archival-description-ead/encoded-archival-descriptio....
1) EAD Revision-Points of Emphasis.pdf - Présentation des quatre grands principes qui fondent la restructuration du format.
2) EADRevisionTechnicalConsiderations.pdf - Résumé des possibilités techniques et des limitations du schéma de l'EAD révisée.
3) EAD_Comments_digest.pdf - Version résumée des commentaires reçus à l'automne 2010.