Principes généraux de la description en EAD⚓
Les principes du catalogage en EAD découlent directement des principes de base de l'archivistique : respect du fonds, description du général au particulier, héritage des informations. Le présent manuel formalise la mise en oeuvre de ces principes énoncés dans les normes de signalement.
Réglementaire : Normes⚓
Le principe de signalement hiérarchisé (Cf. DeMArch § 1.4) est mis en oeuvre au sein de chaque fichier EAD, conformément à la DTD EAD.
Spécificité propre à Calames, ce principe est également mis en oeuvre par des relations d'inclusions entre fichiers EAD.
Hiérarchie des fichiers EAD dans Calames⚓
La spécificité, propre à Calames, que sont les relations entre fichiers EAD, implique d'abord de concevoir son arborescence globale et modéliser la hiérarchie de ses fonds, pour pouvoir déterminer :
quels sont les fichiers à créer
quelles relations entre eux ; voir Organiser les fichiers du Manuel de l'outil Calames
quelles informations de haut niveau de chaque fichier
les différents niveaux de hiérarchisation interne au fichier EAD : notamment l'exploitation du binôme d'attributs LEVEL / OTHERLEVEL du <archdesc> (valeur d'attribut obligatoire) et des composants <c> (usage recommandé).
La typologie des fichiers⚓
Le fichier maître et les fichiers sous-maîtres, spécificité Calames⚓
Le fichier maître, comme les éventuels fichiers sous-maîtres, est un fichier EAD qui ne contient que des éléments de haut niveau, sans composant <c> (le <dsc> doit être supprimé)
Ce types de fichier, maître et sous-maîtres, peuvent se réduire au minimum :
un élément <eadheader>.
Dans l'élément <did> de l'élément <archdesc>,
un élément <unittitle> correspondant à l'ensemble des fonds de l'établissement
un élément <repository> contenant lui-même un élément <corpname> avec le nom de l'établissement et, en attribut AUTHFILENUMBER, son numéro RCR Calames.
Ce RCR doit être le même que celui de tous les fichiers qui appartiennent à la même arborescence. (Voir le rôle du RCR dans Calames)
Le fichier [sous-]maître peut également contenir toute information nécessaire à l'affichage au plus haut niveau pour une bibliothèque. Voir le chapitre sur les différents <archdesc>.
Attention :
Le <dsc> ( <dsc type="othertype"><c id=""><did><unitid></unitid><unittitle></unittitle></did> </c></dsc>) qui figure dans les fichiers créés ex nihilo dans Calames doit être supprimé
Attention :
Dans l'interface publique :
la présence d'un <unitid> dans le fichier maître génère un dysfonctionnement de l'affichage de l'<unittitle> du fichier quand on descend dans l'arborescence
si l'<unititle> n'est pas saisi AVANT le <repository>, son contenu ne s'affiche pas
Indexation : il n'y a pas d'héritage possible ENTRE fichiers EAD. Il est donc inutile de développer des fichiers sous-maîtres au-delà du strict nécessaire à la navigation dans les fichiers maître et sous-maître qui forment le haut de l'arborescence globale.
Il n'y a pas de limite technique connue au nombre d'inclusions de fichiers possible dans Calames.
Les fichiers EAD correspondant à un fonds⚓
Ce sont ces fichiers qui répondent aux principes de création d'un nouvel instrument de recherche.
Selon l'histoire de l'établissement, les besoins de son public, les volumes à signaler et les moyens disponibles, deux logiques de signalement sont acceptés et donc deux types de fichiers EAD.
Soit un signalement synthétique : des fichiers sans composants (ou avec très peu de composants) mais qui présentent un haut niveau <archdesc> développé et complet offrant un signalement synthétique mais exhaustif de l'ensemble d'un fonds d'archives ; ce cas est indépendant de la taille réelle du fonds.
Exemple :
Fonds de la Fédération CGT des Métaux (FileId-3031), qui ne comprend que 3 composants <c> de même niveau sous un <archdesc> complet (dans l'interface publique)
Fonds Marcel Bataillon (Calames-2020115101481902) sans composant sous un <archdesc> complet (dans l'interface publique)
Conseil :
Pour un même niveau de précision, il est toujours préférable de faire une série de composants de 1er niveau, même succincts, qu'un <scopecontent> par définition non structuré.
Soit un signalement analytique approfondie : des fichiers qui tendent vers le signalement de chaque item constitutif dans la description du fonds et peuvent cumuler plusieurs niveaux de composants.
La création d'un niveau « enfant », exprimée sous la forme d'un élément Composant <c>, doit correspondre à une réalité intellectuelle ou matérielle de l'ensemble ou du document considéré.
Le niveau le plus général est celui de la description du fonds ou de la collection et le niveau le plus fin possible, celui de la plus petite division intellectuelle au sein d'une unité matérielle. Entre ces deux extrêmes, l'unité de communication constitue un niveau de description pertinent qu'il est souhaitable d'atteindre dans un signalement analytique.
Exemple :
FileId-3505, Fonds Bourdieu qui comprend sous le <archdesc> une hiérarchie de 8 niveaux de <c> ainsi répartis :8-58-307-204-355-417-198-48-0-0-0-0, 8 composants de 1er niveau, 58 de 2e niveau, 307 de 3e niveau, etc. soit 1 172 composants au total
Conseil : Où s'arrête la profondeur de description : niveau de description le plus fin⚓
La souplesse de l'EAD permet de choisir la profondeur donnée à la description.
L'établissement peut privilégier dans un premier temps une description synthétique de haut niveau, puis, selon ses priorités documentaires et sa politique de numérisation qui amène à descendre jusqu'à la pièce numérisée, développer progressivement une description plus précise au fur et à mesure du traitement.
Le système Calames et la DTD permettent jusqu'à 12 niveaux de composants sous un <archdesc>.
Cas particulier : le fichier de travail dit « fichier Modèle »⚓
Par défaut, l'Abes crée un fichier MODELE pour tout établissement qui se déploie dans Calames : seul le RCR Calames dans l'attribut AUTHFILNUMBER du <corpname> du <repository> correspond à celui de l'établissement. L'ensemble des autres éléments est à personnaliser par le correspondant.
Le rôle de ce fichier MODELE est de servir de matrice, par export Natif puis import,à la création de tous les fichiers de l'établissement ; il doit donc être adapté par le correspondant et contenir ce qui est indispensable et récurent.
Si l'établissement a recours à plusieurs modèles-types, le correspondant en crée autant que de besoin en veillant à mentionner MODELE dans leur intitulé (cf. le mémo de nommage).
Il ne doit donc pas systématiquement détailler ce qui n'a pas besoin de figurer que dans des fichiers maîtres ou sous-maîtres
Exemple :
Si l'arborescence couvre plusieurs lieux de conservation, il est pertinent de maintenir la précision de l'adresse de <repository><address> dans le fichier MODELE, car elle devra être précisée pour chaque fonds. cf. cas du MNHN.
En revanche si tous les fonds sont conservés au même endroit, la mention de l'adresse postale dans le <repository><address> du fichier maître suffit, sans qu'elle ait besoin de figurer dans le fichier MODELE.
Le fichier modèle destiné a servir de matrice au fichier avec unités documentaires doit contenir ce qui doit être systématiquement hérité de tous les composants.
Ainsi, si on veut que la boîte à outils offre systématiquement la fonction « contacter l'établissement », doit systématiquement y figurer une adresse de messagerie électronique (présence d'un @) : <repositoy><address><addressline>messagerie@xxx.fr</addressline></address></repository>
Eléments de structure EAD⚓
Tout fichier XML-EAD répond à la structure suivante :⚓
un élément <ead> englobant tout le contenu du fichier
au sein de
<ead> est imposé par la DTD :un élément <eadheader> En-tête EAD, contenant les métadonnées concernant la description et l'instrument de recherche (et non l'unité documentaire)
un <archdesc> Description archivistique, élément englobant toute la partie description de l'ensemble documentaire, qui comprend, imposés par la DTD
un <did> Identification et description ; il peut aussi contenir d'autres éléments hors <did> (voir le chapitre dédié Éléments de contexte) (contexte, histoire, accès, document en relation, liens, etc.)
un
<dsc> si le fichier comprend des composants <c>
Remarque : Les déclarations avant la balise <ead>⚓
Tout fichier XML débute par deux "déclarations" qui précisent, d'une part la version de XML utilisée et d'autre part le schéma de données : c'est là qu'est explicitée la DTD EAD 2002 à laquelle le fichier XML doit être conforme :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ead PUBLIC "+//ISBN 1-931666-00-8//DTD ead.dtd (Encoded Archival Description (EAD) Version 2002)//EN" "ead.dtd">
Exemple⚓
Exemple : Structure EAD⚓
Déclaration :
<ead>
<eadheader> [...] </eadheader> [comprend plusieurs éléments EAD imposés par la DTD]
<archdesc level="fonds"> [élément Description archivistique et présence de l'attribut LEVEL (liste fermée de valeurs) imposés par la DTD]
<did> [...] </did> [élément Identification et descripton imposé par la DTD]
<dsc> [élément Description des sous-composants imposé par la DTD, si on veut décrire des composants]
<c>
<did> [...] </did>
[...]
<c>
<did> [...] </did>
[...]
</c>
<c>
<did> [...] </did>
[...]
</c>
</c>
<c>
<did> [...] </did>
[...]
</c>
</dsc>
</archdesc>
<ead>
<archdesc> et composant <c>⚓
Logique de description dans les <archdesc> et <c>⚓
Similitudes⚓
La description archivistique d'un ensemble dans un <archdesc> se fait selon les mêmes principes que celle de ses composants enfants : la recommandation DeMArch ne traite pas séparément la description de l'ensemble documentaire et celle des documents.
En conséquence, il n'y a aucune différence dans les éléments EAD définis et autorisés entre le haut niveau <archdesc> et les différents niveaux de composants <c> : la description se fait dans le même élément <did> avec ses sous-éléments.
La seule différence imposée par la DTD est le caractère obligatoire de l'attribut LEVEL dans le <archdesc> qui est simplement possible dans les <c>.
Cette équivalence des éléments descriptifs permet aux héritages depuis le <archdesc> de fonctionner comme depuis un composant <c> ancêtre.
Indexation : la mise en oeuvre technique des héritages dans Calames est identique, que le contenu soit dans le <archdesc> ou dans les différents niveaux de la généalogie des composants <c>.
Par conséquent, pour couvrir cette double possibilité, parle-t-on systématiquement de "plus haut niveau pertinent" pour la saisie d'une information valable pour toute sa descendance.
Spécificités de signalement concernant les <archdesc>⚓
Il est cependant des éléments EAD plus spécifiquement attendus dans un <archdesc> qui présentent a priori un ensemble documentaire constitué et cohérent. (cf. les éléments attendus dans le haut niveau d'un instrument de recherche complet (avec ses composants)).
Et spécificités Calames⚓
Certains éléments, notamment le <repository>, sont utilisés de manière particulière dans le <archdesc> d'un fichier Calames.
La possibilité de créer une arborescence entre fichiers amène des règles spécifiques de contenu du <archdesc>
Caractéristiques⚓
Description archivistique <archdesc>⚓
Ainsi que l'énonce la Bonne pratique « l'élément <archdesc> ne peut pas contenir de texte libre mais uniquement les éléments spécifiques à la description archivistique.
Il contient la totalité de la description archivistique, organisée en plusieurs niveaux de description. »
Descriptions des sous-composants <dsc>⚓
Dans le respect des Bonnes pratiques, l'élément <dsc> dans Calames n'est utilisé que comme élément fils de <archdesc> et ne contient que des composants <c>. Pour un fichier EAD donné, l'ensemble des composants <c> doit être dans un unique <archdesc><dsc>.
Quand il n'y a aucun composant, que ce soit pour des fichiers maître ou sous-maître, ou pour des instruments de recherche synthétique, il n,e doit pas y avoir de <dsc>, même vide.
Composant <c>⚓
Dans le respect des Bonnes pratiques, Calames n'accepte que l'élément <c> non numéroté, dans autant de niveaux hiérarchiques que nécessaire.
Tout <c> doit contenir une valeur d'attribut ID, qui est fondamentale dans le fonctionnement de l'ensemble de l'application Calames.
Exemple⚓
Exemple : Les éléments EAD structurels d'un fichier⚓
Déclaration :
<ead>
<eadheader> [...] </eadheader> [comprend plusieurs éléments EAD imposés par la DTD]
<archdesc level="fonds"> [élément Description archivistique et présence de l'attribut LEVEL (liste fermée de valeurs) imposés par la DTD]
<did> [...] </did> [élément Identification et descripton imposé par la DTD]
<dsc> [élément Description des sous-composants imposé par la DTD, si on veut décrire des composants]
<c>
<did> [...] </did>
[...]
<c>
<did> [...] </did>
[...]
</c>
<c>
<did> [...] </did>
[...]
</c>
</c>
<c>
<did> [...] </did>
[...]
</c>
</dsc>
</archdesc>
<ead>
Mise en œuvre de la logique hiérarchique⚓
Les informations descriptives doivent être données au plus haut niveau pertinent, de telle sorte que
elles concernent ledit niveau en propre (<archdesc> ou composant <c>) et tous les niveaux qui en dépendent (composant <c> enfant)
elles ne soient pas répétées aux niveaux inférieurs
Les niveaux inférieurs héritent intellectuellement, et dans le fonctionnement effectif de l'indexation dans Calames, des informations des niveaux supérieurs.
Attributs LEVEL et OTHERLEVEL⚓
Ce binôme d'attributs permet de définir le niveau de description archivistique
Bonnes pratiques concernant LEVEL⚓
| L'attribut LEVEL est imposé par la DTD dans <archdesc> et recommandé dans <c>
|
Remarque : Rappel de quelques définitions⚓
level="fonds" : ensemble de documents de tout type, constitué de façon organique par une personne ou une collectivité, publique ou privée (le producteur du fonds) dans l'exercice de ses activités et en fonction de ses attributions.
level="collection" : ensemble de documents (fonds, dossiers, pièces) réunis par une personne physique ou une collectivité, y compris l'institution de conservation elle-même, en fonction de critères communs liés au contenu ou au support : auteur, thème, type de document, provenance, langue, fourchette chronologique. En ce sens, cette valeur correspond à la fois à une collection réunie par un collectionneur ou aux collections d'un établissement.
level="series" [série ou série organique] : correspond à un ensemble de dossiers réunis ou maintenus groupés par le responsable du classement parce qu'ils résultent d'une même activité, qu'ils se rapportent à une même fonction ou à un même sujet ou qu'ils revêtent une même forme ; cet ensemble peut, le cas échéant, être hiérarchisé sur différents niveaux.
La liste des valeurs des attributs LEVEL et OTHERLEVEL de <archdesc> et <c> utilisée dans Calames, en cohérence avec la liste des Bonnes pratiques, figure avec leur définition en annexe 2 du présent manuel.
Spécificités Calames⚓
Concernant LEVEL et OTHERLEVEL du <archdesc>⚓
Seules quatre valeurs sont acceptées dans le binôme LEVEL / OTHERLEVEL des <archdesc> Calames
Afin de pouvoir mettre en place un filtre de recherche publique qui limite l'interrogation aux seuls hauts niveaux des ensembles documentaires décrits, les valeurs acceptées pour un <archdesc> sont les suivantes :
Le <archdesc> s'applique à la fois à des fonds d'archives et des collections ; ce peut être fréquemment le cas pour des fichiers maîtres et sous-maîtres :
il existe une valeur spécifique à Calames et obligatoire concernant les valeurs du binôme des attributs LEVEL/OTHERLEVEL
LEVEL="otherlevel" OTHERLEVEL="Groupe_IR"
Le <archdesc> s'applique à une collection, une partie de collection ou une sous-collection
LEVEL="collection"
Le <archdesc> s'applique à un fonds d'archives, ou un sous-fonds qui doit être pris en compte lors d'une recherche publique qui se limite aux hauts niveaux
LEVEL="fonds"
Le <archdesc> s'applique à un sous-fonds ou une série qui n'a pas à être pris en compte lors d'une recherche publique qui se limite aux hauts niveaux
LEVEL="series"
Dans tous ces cas sont à considérer ce que le <archdesc> englobe soit directement dans le fichier EAD lui-même, soit virtuellement via le jeu des liaisons et inclusions entre fichiers EAD.
Attention :
Lors de la création d'un nouveau fichier EAD, la valeur par défaut de l'attribut LEVEL du <archdesc> est une valeur interdite par la DTD (la valeur "choisir"), afin de rappeler au catalogueur, notamment via les messages dans visio_controle, de sélectionner la valeur pertinente.
Dans le cas de fichiers liés, en vertu de la règle qui exige que le <archdesc> des fichiers liés reprenne les valeurs du <archdesc> du fichier EAD tête de liaison, la valeur de l'attribut LEVEL (et OTHERLEVEL) du <archdesc> du fichier lié est identique à celle du LEVEL (et OTHERLEVEL) du <archdesc> du fichier tête de liaison.
Remarque :
Les valeurs du binôme d'attributs LEVEL / OTHERLEVEL ne sont pas encore exploitées dans l'interface publique mais elles peuvent servir de filtre pour la production de listes par l'administrateur à des fins de contrôle qualité ou de gestion des données.
Concernant LEVEL et OTHERLEVEL des composants <c>⚓
Le minimum requis dans Calames⚓
Que tous les hauts niveaux de signalement d'un fonds ou d'une collection qui ne correspondraient exceptionnellement pas à un <archdesc> aient un attribut LEVEL systématiquement renseigné avec l'une des deux valeurs "fonds" ou "collection" suivant les cas.
Il est possible d'utiliser toutes les valeurs autorisées par les Bonnes pratiques au sein des éléments composants <c>, pour l'attribut LEVEL, ou le binôme LEVEL="otherlevel" et l'attribut OTHERLEVEL.
La liste des valeurs de LEVEL est contraignante, la liste des valeurs d'OTHERLEVEL est indicative : elle est cependant contrôlée par visio_controle
La liste complète des valeurs et définitions se trouve en annexe 2
Exemples d'articulation entre les différentes valeurs du binôme LEVEL / OTHERLEVEL⚓
Exemple : Cas de 3 fichiers d'une même arborescence⚓
<archdesc level="otherlevel" otherlevel="groupe_IR"> [FICHIER MAITRE]
<archdesc level="collection"> <did><unittitle>Manuscrits</unittitle></did> [FICHIER INCLUS n°1 COLLECTION]
<c level="collection"><did><unittitle>Collection de manuscrits du couvent Sainte Gudule</unittitle></did>
<c level="collection"><did><unittitle>Manuscrits français</unittitle></did>
<c level="item"><did><unittitle>Chartrier du XVIe siécle</unittitle></did></c>
<c level="item"><did><unitid type="cote">Ms45</unitid><unittitle>Psautier</unittitle></did></c>
[ALTERNATIVE a "item" SI ON VEUT SYSTEMATIQUEMENT ENCODER UNITE MATERIELLE ET UNITE INTELLECTUELLE]
<c level="otherlevel" otherlevel="document_unitaire"><did><unitid>Ms45</unitid><unittitle>Psautier</unittitle></did></c>
<c level="otherlevel" otherlevel="document_composite">
<did><unitid type="cote">Ms 2119</unitid><unittitle>Recueil d'oeuvres du P. Nicolas Coëffeteau</unittitle><physdesc><extent>79 feuillets</extent></physdesc></did>
<c level="otherlevel" otherlevel="subdivision_intellectuelle"><did><unittitle>L'évangile selon saint Matthieu, traduict sur le grec</unittitle><physdesc><extent>ff. 1-55</extent></physdesc></did></c>
<c level="otherlevel" otherlevel="subdivision_intellectuelle"><did><unittitle>Première leçon ou plustost préparation à la philosophie</unittitle><physdesc><extent>ff 56-79</extent></physdesc></did></c>
</c>
<c level="otherlevel" otherlevel="recueil_factice"><did><unitttitle>Partitions de Marie Jaëll</unittitle><physdesc><extent>4 brochures</extent><dimensions>format divers</dimensions></physdesc></did>
<c level="otherlevel" otherlevel="subdivision_matérielle"><did><unittitle>Toucher</unittitle><physdesc><extent>88 pages</extent><dimensions>35 cm</dimensions></physdesc></did></c>
<c level="otherlevel" otherlevel="subdivision_matérielle"><did><unittitle>Trois mélodies</unittitle><physdesc><extent>10 pages</extent><dimensions>30 cm</dimensions></physdesc></did></c>
</c>
</archdesc>
<archdesc level="fonds"><did><unittitle>Fonds Gaston et Paulin Paris</unittitle></did> [FICHIER INCLUS n°2 FONDS D'ARCHIVES]
<c level="fonds"><did><unittitle>Sous Fonds Paulin</unittitle></did>
<c level="series"><did><unittitle>Carnets de notes</unittitle></did>
<c level="item"><did><unittitle>Carnet <unitdate era="ce" calendar="gregorian" normal="1820">1820</unitdate></unittitle></did></c>
<c level="item"><did><unittitle>Carnet <unitdate era="ce" calendar="gregorian" normal="1821/1822">1821-1822</unitdate></unittitle></did></c>
</c>
<c level="series"><did><unittitle>Correspondance</unittitle></did>
<c level="file"><did><unittitle>Lettres à sa mère</unittitle><physdesc><extent>1 boite de 75 lettres</extent></physdesc></did></c>
<c level="recordgrp"><did><unittitle>Documents iconographiques</unittitle></did></c>
</c>
</archdesc>
Quand créer un nouvel instrument de recherche EAD ?⚓
Principe 1⚓
La description d'un fonds, ensemble identifié et organisé, donne lieu à la création d'un nouvel instrument de recherche (soit un fichier) EAD.
Dans un contexte de développement des échanges de données (exports, moissonnages plus ou moins ciblés, etc.) il est recommandé de créer un nouvel instrument de recherche EAD spécifique même pour les fonds de faible importance.
Principe 2⚓
Un manuscrit isolé ne doit pas faire l'objet d'un nouveau fichier EAD spécifique.
On considère le document isolé comme faisant partie d'une collection de l'institution concernée, et c'est cette collection ou sous-collection dans son ensemble que décrit l'instrument de recherche EAD.
Principe 3⚓
L'organisation du signalement des « collections » au sens de réunion « artificielle » d'unités documentaires sur un critère commun (par opposition à « fonds d'archives »), qui ne sont pas soumises au principe archivistique de respect des fonds, doit être la plus lisible possible pour le lecteur.
Elle peut légitimement évoluer et amener la création ou la réorganisation interne d'un instrument de recherche existant, y compris s'il est issu de la rétroconversion (CGM ou PALME).
La décision de réorganisation doit cependant être pesée afin
d'évaluer l'amélioration pour le public au regard de la somme de travail nécessaire,
de garantir la pérennité de l'organisation visée et sa capacité à intégrer, sans nouveau bouleversement, les évolutions probables du fonds, et éviter ainsi des changements continus de structure.
Conseil : Cas des rétroconversions CGM et PALME⚓
Voir les consignes spécifiques en cas de modifications de fichiers EAD issus des rétroconversions CGM ou PALME.
Principe 4⚓
Un instrument de recherche EAD spécifique peut et doit être créé lorsque l'imposent des circonstances telles que :
l'architecture générale des catalogues de l'établissement (exemple : cotations particulières dans le cas de classement topographique), en cohérence avec l'arborescence globale
et / ou la nécessité d'informations de haut niveau spécifiques (<author>, etc.).
Contrainte technique imposant la création d'un nouveau fichier EAD dans Calames⚓
En raison d'une contrainte technique qui limite la taille maximale possible pour un fichier EAD dans Calames (3,5 Mo), on peut être obligé de créer un nouveau fichier EAD sans logique imposée par le contenu. Le nouveau fichier EAD, reproduit intégralement le <archdesc> du fichier initial trop grand et le fichier nouvellement créé doit être lié au fichier initial qui devient ainsi « tête de liaison ».
Pour les fichiers EAD sans unité documentaire, qui ne sont pas à proprement parler des « instruments de recherche » car ayant pour seule fin de structurer l'arborescence globale du catalogue de l'établissement, voir le chapitre dédié du manuel du correspondant.
Règles transversales d'encodage EAD⚓
Bonnes pratiques : source de ces principes génériques⚓
Les principes énoncés ci-dessous ne sont pas tous explicités a priori dans le Guide des bonnes pratiques de l'EAD en bibliothèque, mais ils sont mis systématiquement en œuvre dans les statuts accordés dans le Guide, éléments par éléments, aux attributs, aux éléments parents et aux éléments fils ; voir le tableau de synthèse par élément et attribut du Guide des bonnes pratiques .
Exemple :
<acqinfo>
La non récursivité des éléments EAD⚓
Les Bonnes pratiques interdisent systématiquement l'usage d'un élément comme élément fils de lui-même, à l'exception notable de l'élément structurel composant <c>.
Exemple :
<acqinfo> est interdit comme fils de <acqinfo> : cf. copie d'écran ci-dessus
La non répétition des éléments EAD⚓
Hors éléments d'indexation, les Bonnes pratiques visent à interdire la répétition d'un même élément signifiant pour une même unité documentaire.
Depuis 2024, le tableau synthétique publié sur le site des Bonnes pratiques, explicite peu à peu la règle de répétabilité pour chaque élément.
Exemple :
Si plusieurs informations différentes relèvent de la restriction d'accès, la Bonne pratique interdit la répétition de l'élément porteur de signification <accessrestrict> au profit de la répétition, au sein d'un unique <accessrestrict>, de plusieurs éléments enfantsparagraphe <p>.
Si les Bonnes pratiques autorisent la répétition d'un élément descriptif ou de contexte, c'est toujours explicitement précisée et avec une obligation d'usage d'un attribut différent qui justifie la répétition
Exemple :
<extent> : « Lorsque plusieurs indications d'importance matérielle concernent l'unité documentaire, elles sont regroupées dans un seul élément <extent>, sans attribut. Si néanmoins il apparaît nécessaire, dans le contexte d'un établissement, de les distinguer on répète l'élément en utilisant l'attribut TYPE. »
Attention : Spécificité Calames⚓
En raison du fonctionnement de l'interface publique, Calames impose la répétition d'un même élément signifiant quand il y a besoin qu'une partie des informations soit masquée au public avec un attribut audience="internal" car cet attribut n'est pas pris en compte pour le paragraphe <p>
C'est notamment de cas de <otherfindaid>
Eviter le surbalisage⚓
Attention :
Au sein d'un même fichier EAD, ne pas répéter des informations déjà présentes au niveau supérieur, notamment des éléments d'indexation qui sont systématiquement hérités (cf. Annexe 1)
Si l'on rencontre, au sein d'un sous-composant, une information partiellement différente de celle donnée à un niveau supérieur, il est justifié de compléter l'information héritée par une information en propre. Dans ce cas, il ne s'agit pas de surbalisage car l'information encodée vient utilement compléter l'instrument de recherche.
Exemple :
Une même personne peut être encodée en haut niveau avec un <persname> qui a le ROLE de "producteur" et être répétée dans un composant enfant dans un <persname> qui a le ROLE de "destinataire" de correspondance.
Ne pas assimiler, par un usage abusif de certains éléments notamment des points d'accès, des informations qui portent sur les unités documentaires décrites et des informations qui portent sur des documents ou agents en relations, pour ne pas altérer l'indexation et entraîner une moindre qualité de la recherche.
Exemple : Ces usages sont interdits⚓
Utiliser un <persname role="070"> (auteur) comme enfant de <bibref> pour encoder un auteur d'un ouvrage cité en bibliographie pourrait laisser croire au public que Calames signale des archives de ce même auteur.
Utiliser un <corpname> (auteur) comme enfant de <originalsloc><p> ou <sepraratedmaterial><p>pour encoder l'établissement qui conserve le document en relation pourrait laisser croire au public que Calames signale des archives de ce même auteur.Ce qui doit être privilégié est l'encodage de la relation au signalement du document en relation dans un <archdesc>
Ne pas encoder des éléments avec des balises non exploitées : une structuration inutilement fine fait perdre du temps lors du catalogage et alourdit inutilement les données.
Le tableau de synthèse par élément et attribut du Guide de bonnes pratiques liste systématiquement, pour chaque élément, l'ensemble des élément fils définis par la DTD EAD et les répartit par statut : [imposé par la DTD], obligatoire, autorisé, autorisé sur projet spécifique, interdit.
Exemple :
Pour l'élément <langmaterial>
Dans Calames ne sont ni indexé, ni affiché au public les éléments interdits ou autorisé sur projet spécifique.
Les éléments autorisés sur projet spécifique peuvent donner lieu à la production de liste par l'Abes.
Ne pas laisser d'élément EAD vide dans une instrument de recherche⚓
Les élément EAD vide doivent être supprimé pour éviter d'alourdir inutilement les processus de publication d'export et de conversion.
Un élément vie est un élément qui n'a ni contenu textuel, ni valeur d'attribut. (le <dao> qui contient des valeurs d'attribut n'est donc pas concerné)