La version 2 de Pleade n'est plus officiellement développée par Anaphore et AJLSM. Si des bogues bloquants sont constatés, ils pourront toutefois être corrigés.

Nous encourageons tous les utilisateurs de Pleade 2 à songer à une migration vers la version 3.

La version 3.1 est disponible depuis le 24 février 2009 sur SourceForge : > > Télécharger...

Voir le site de démonstration de Pleade 3 : > > Démonstration de Pleade 3

Plus d'information sur Pleade 3 : http://pleade.com/

PLEADE et les documents EAC

Cette page donne quelques explications utiles pour comprendre le fonctionnement de la partie de PLEADE qui est dédiée à la publication et à la consultation de documents EAC. Attention, ces fonctionnalités sont disponibles seulement depuis la version 2 finale de PLEADE publiée en février 2007.

Une présentation des principes qui ont orienté le développement de la partie EAC est disponible par ailleurs, depuis le milieu de l'année 2006.

Une documentation plus complète pourra être ajoutée ultérieurement.

1) Niveau de support EAC

Une installation PLEADE 2.0 permet de publier et de consulter tout document EAC conforme à la DTD EAC beta, telle que téléchargeable à la page : http://jefferson.village.virginia.edu/eac/. La seule contrainte supplémentaire consiste, comme c'est aussi le cas pour les documents EAD, à renseigner l'élément Identifiant EAC <eacid>.

Le développement effectué prend en compte la totalité des éléments et attributs EAC, qu'il s'agisse des fonctionnalités d'indexation, de recherche ou de consultation. Cependant l'usage de cette DTD n'est pas répandu et il n'existe pas d'autre référence que la Tag Library de la DTD et sa traduction française par l'AFNOR . De plus nous avons travaillé sur un jeu de notices d'autorité certes diverses et provenant de différentes institutions, mais assez peu nombreux et uniquement français. L'interprétation qui a été faite du modèle peut donc être débattue. N'hésitez pas si vous avez des remarques ou suggestions !

2) Exemples

Un jeu de documents EAC, ainsi que deux documents EAD associés, sont fournis avec les sources de PLEADE 2, dans un fichier zip nommé EACandEADExamples.zip déposé dans le dossier examples. Ces documents sont diffusés à des fins de test dans le logiciel PLEADE exclusivement, avec l'accord des insitutions auteurs ; merci beaucoup à elles.

3) Fonctionnalités EAC disponibles dans la version 2 de PLEADE

Comme indiqué dans la page d'exposé des principes, l'administration des documents EAC est dévolue dans PLEADE à des pages spécifiques. Il faut, comme lorsqu'on veut gérer les documents EAD, s'identifier comme administrateur, les code et mot de passe par défaut étant les mêmes (admin/pleade). On verra alors au bas de la page HTML les boutons permettant de lister, supprimer et publier les documents EAC.

Le formulaire de publication de documents EAC est très simple, ne proposant aujourd'hui que quelques options : même si des rubriques arrivent à l'écran, il n'y a pas encore de choix possible dans ces rubriques (il n'y a qu'un format d'affichage, qu'un jeu de libellés).

Une base SDX spécifique de documents, nommée af (autority files) a été créée. Les champs d'indexation utilisés ont en général les mêmes noms que les éléments EAC. Ainsi on trouve un champ bioghist, un champ causa, un champ assetstruct, un champ funact. Certains éléments essentiels dans un document EAC ont fait l'objet d'une indexation plus précise, ce sont les éléments de saisie des vedettes nom de personne, de collectivité ou de famille. Chacun de ces éléments fait l'objet d'une indexation dans un champ de même nom (pershead est indexé dans un champ pershead) ; en outre les vedettes qui auront été marquées par un attribut authorized sont indexées dans un autre champ, et enfin toutes les vedettes sans distinction sont indexées dans un champ entityname. Le type de notice d'autorité, donné par la valeur de l'attribut type de l'élément racine eac, fait également l'objet d'une indexation. Enfin les éléments de lien ont également été indexés de façon très précise, ce qui permet notamment d'afficher les informations les concernant dans les listes de résultats de recherche.

La recherche dans le corpus de documents EAC ne se fait pas par les moyens de recherche disponibles depuis longtemps pour les documents EAD, mais par des formulaires spécifiques, accessibles en cliquant sur le menu Producteurs de la barre de menu :

  • un formulaire de recherche "simple", fonctionnant exactement comme le pavé de recherche simple situé en haut de chaque page d'un site PLEADE, dans lequel on peut utiliser les règles de syntaxe du moteur de recherche Lucene ;

  • un formulaire de recherche avancée, qui permet d'interroger plusieurs index, et qui peut être modifié à loisir puisqu'il est construit à partir d'un fichier de configuration obéissant aux mêmes règles syntaxiques que les fichiers de configuration des formulaires EAD (voir la page de présentation des formulaires de recherche avancée). L'interface HTML de configuration des formulaires ne peut pas actuellement être utilisée pour modifier ou créer un formulaire EAC, ce sera pour plus tard.

Les listes de résultats de recherche sont triables en fonction de divers critères. Si un résultat de recherche correspond à une notice dans laquelle des liens ont été établis, les informations utiles sur ces relations sont affichées. Si la notice d'autorité (en EAC) ou l'instrument de recherche (XML/EAD) cibles d'un lien sont disponibles dans la même installation PLEADE, ces liens sont actifs, pourvu qu'ils soient conformes aux règles exposées ci-dessous.

Une liste générale des notices d'autorité publiée, et trois autres listes, une par type d'entité (personne physique, personne morale, famille) sont accessibles en permanence en cliquant sur des items du menu Producteurs de la barre de menu.

Le format d'affichage est conforme à la norme ISAAR (CPF). Un tableau présente, dans l'ordre logique suivi par cette norme et donc en grandes rubriques, les informations d'identification et de description de l'entité, ainsi que les informations sur les relations qu'elle entretient et les données relatives à la notice elle-même. Les libellés des informations et rubriques sont conformes à ceux de la norme ISAAR (CPF) dans sa version française, et aux traductions des noms des éléments EAC telles qu'établies par le groupe AFNOR CG46/CN357/GE4 sur les données d'autorité. Là aussi, si vous avez besoin d'un autre format, ou de modifications, n'hésitez pas à vous manifester !

Cette partie du logiciel PLEADE ne vous est pas utile ? vous ne voulez pas que les utilisateurs de votre installation PLEADE aient accès à des listes de notices vides, à des formulaires qui ne serviraient à rien ? C'est très simple : le fichier de configuration de la barre de menu fournie s'appelle main.xml et il se trouve dans le dossier pleade-local\skin\menubars\ de votre installation. Vous pouvez l'éditer avec un éditeur XML ou un éditeur de texte, et supprimer ou passer en commentaire XML, l'élément menu dont le sous-élément label a comme contenu "Producteurs". Vous enregistrez le fichier main.xml modifié, vous arrêtez votre moteur de servlets Tomcat, supprimez le dossier tomcat_home\work, et redémarrez Tomcat.

4) Liens entre documents EAC, liens entre documents EAC et documents EAD

PLEADE construit des liens hypertexte valides entre documents EAC, ainsi qu'entre documents EAC et documents EAD, si les éléments de lien saisis dans ces documents l'ont été en respectant certaines règles simples. Nous allons prendre des exemples pour les expliquer.

4.1) Liens entre documents EAC

Voici un lien que PLEADE saura traiter correctement :

<eacrel reltype="subordinate" syskey="FRAD53_notairebruneau-lagarde.xml">
   <persname>Bruneau-Lagarde, Joseph-Marie</persname>
   <date normal="1774/1792">1774-1792</date>
   <descnote>J.-M. Bruneau-Lagarde a été notaire à Laval de 1774 à 1792.</descnote>
</eacrel>

L'élément eacrel est doté de deux attributs :

reltype

Cet attribut indique la nature de la relation établie entre l'entité en cours de description et l'entité cible du lien (ici, l'étude notariale a eu en son sein un notaire) .

syskey

Cet attribut est essentiel pour PLEADE, puisque dans cet attribut on trouve l'identifiant suivi de l'extension .xml, du document EAC cible. Si ce document EAC a été publié dans l'installation PLEADE, PLEADE affichera, dans la liste de résultats ou dans la page d'affichage de la notice d'autorité, un lien hypertexte valide. Si le document EAC cible n'a pas été publié, PLEADE affichera uniquement les informations données dans l'élément eacrel (ici, nom du notaire, dates de la relation, type de relation).

4.2) Liens entre documents EAC et documents EAD

Voici un exemple de lien entre un document EAC et un document EAD :

<resourcerel reltype="origination" syskey="DAFANCH00AP_0000515AP.xml">
<archunit>
   <unittitle>Fonds Pablo Picasso</unittitle>
   <repository>Centre historique des Archives nationales (Paris, France)</repository>
   <origination>Les archives de Pablo Picasso ont été données à l’Etat, par ses ayants droit, en 1992 [...]</origination>
</archunit>
</resourcerel>

Le principe est le même. Dans l'élément resourcerel prévu à cet effet par la DTD EAC, on trouve notamment deux attributs :

reltype

Cet attribut indique la nature de la relation établie entre l'entité décrite et l'instrument de recherche (ici, Pablo Picasso a produit un fonds d'archives décrit dans cet instrument de recherche).

syskey

Cet attribut est essentiel pour PLEADE, puisqu'on y trouve l'identifiant, suivi de l'extention .xml, du document EAD cible du lien. PLEADE agira pour cet élément resourcerel exactement comme indiqué plus haut pour eacrel.

Ici le lien est établi sans spécifier une section de l'instrument de recherche, et PLEADE affichera donc, dans le jeu de cadres prévu à cet effet, l'inventaire complet, en començant par la page de titre. Si on veut établir un lien vers une section particulière d'un document EAD, par exemple vers un composant archivistique, on ajoutera dans l'attribut syskey, après l'extension .xml, un pointeur donnant l'identifant de l'élément cible (on saisira le caractère # suivi de la valeur de l'attribut id de l' élément Composant c, par ex. Inventaire.xml#c123. Si on clique sur un tel lien hypertexte, PLEADE affichera, dans le jeu de cadres prévu pour afficher les documents EAD, l'unité documentaire correspondant au composant c cible du lien.

Vous voulez établir le lien inverse, afin que l'utilisateur puisse passer de l'instrument de recherche en EAD à la notice sur son producteur ? Alors vous devez saisir dans le document EAD un lien ressemblant à celui-ci (en reprenant l'exemple ci-dessus) :

<did>
   <unitid type="cote CHAN">515AP - MP/1992-2</unitid>
   <unittitle>Fonds Picasso</unittitle>
   <unitdate normal="1901/2000">XXe siècle</unitdate>
   <origination><persname authfilenumber="FRANCHAN_pablopicasso">Picasso, Pablo</persname></origination>
   <repository><emph render="bold">musée Picasso</emph>, hôtel Salé, 5 rue de Thorigny, 75 003 Paris</repository>
   <physdesc><extent>359 cartons</extent>, <extent>25 mètres linéaires</extent></physdesc>
</did>

Dans l'élément persname, l'attribut authfilenumber est renseigné en donnant l'identifiant du document EAC cible (tel que saisi dans l'élément eacid de ce document).

Il est possible d'établir une telle relation depuis n'importe quel élément persname, corpname et famname, situé à n'importe quelle position dans l'arbre des éléments EAD, et quel que soit l'élément englobant (origination, mais aussi, par exemple, un élément p situé dans un scopecontent ou un custodhist).

5) Entrepôt OAI

Les modifications nécessaires pour disposer au sein d'une installation PLEADE 2.0 d'un entrepôt OAI pour les documents EAC ont été faites le 11 septembre 2007, il faut donc récupérer des sources CVS postérieures à cette date pour en bénéficier.

Comme pour la base des documents EAD, il faut, pour définir la base des documents EAC comme un entrepôt OAI, éditer le fichier $PLEADE_HOME/pleade.properties présent dans les sources, et y renseigner quelques paramètres :

  • donner la valeur true au paramètre pleade.eac.oai.repository pour activer la fonctionnalité ;

  • donner un nom à l'entrepôt grâce au paramètre pleade.eac.oai.repository.name

  • fournir l'adresse de courriel de l'administrateur de l'entrepôt au moyen du paramètre pleade.eac.oai.repository.adminemail

Lorsqu'on exécutera le script d'installation, l'application PLEADE obtenue sera prête à fonctionner avec cet entrepôt.

Notez que les deux entrepôts OAI disponibles dans les sources de PLEADE fonctionnent indépendamment l'un de l'autre, de sorte que l'un d'eux peut très bien être activé et configuré, sans que l'autre le soit.

Les métadonnées de l'entrepôt de la base de documents EAC sont de deux sortes dans PLEADE 2, comme celles de l'entrepôt de la base de documents EAD : des enregistrements au format Dublin Core simple et des enregistrements au format Dublin Core qualifié. D'autres formats XML de métadonnées peuvent bien sûr être implémentés.

A notre connaissance, il n'existe pas d'application en production pour laquelle une implémentation OAI a été réalisée permettant d'exposer des métadonnées issues de documents EAC. Il n'y a pas non plus encore eu au niveau international de réflexion sur cette question, et il n'existe pas de tableau de correspondance entre éléments du modèle EAC et éléments du modèle Dublin Core qualifié. Nous sommes partie des principes suivants :

  • la ressource objet de la description, au sens du protocole OAI, est ici bel et bien une personne physique, une collectivité ou une famille, il ne s'agit pas d'un document ;

  • l'item qui décrit cette ressource est une notice d'autorité ;

  • l'enregistrement dont on va extraire les métadonnées de description de la ressource est un document EAC.

Nous avons défini un tableau de correspondance entre les éléments EAC décrivant l'entité (personne physique, famille, collectivité) et les éléments du format Dublin Core qualifié. Nous sommes partie des documents EAC dont nous disposions et nous sommes appuyée sur notre propre interprétation des deux formats et sur notre expérience. Le résultat pourra être très utilement discuté et évoluer. Voir le tableau de correspondance DC/EAC.

Les métadonnées OAI-PMH extraites des documents EAC sont actuellement conformes aux règles établies dans ce tableau de correspondance, sans qu'il soit implémenté de règles et mécanismes d'extraction explicite des métadonnées, comme c'est le cas pour les documents EAD.

Il est possible, en éditant le fichier $PLEADE_HOME/pleade-local/eac-oai.xconf, d'ajouter systématiquement des éléments Dublin Core ou Dublin Core qualifié aux enregistrements OAI générés, en saisissant directement ces éléments dans l'élément additions de ce fichier par exemple :

<additions>
			<dc:publisher>{le nom de l'institution ou de la personne qui édite la ou les notices
d'autorité}</dc:publisher>
			</additions>

.

Le fichier $PLEADE_HOME/pleade-local/eac-oai.xconf contient aussi, dans l'élément eactypes, la déclaration des informations susceptibles d'être incluses dans l'élément Dublin Core dc:type, en fonction de la valeur de l'attribut type de l'élément racine eac du document EAC.

6) Ce qui pourrait être fait en plus...

Nous avons prévu d'améliorer et de compléter les fonctionnalités disponibles. En ce qui concerne les compléments, nous pensons notamment ajouter une sortie PDF des notices d'autorité. Tous les travaux ultérieurs seront en particulier fonction de l'usage qui sera fait de cette partie par les utilisateurs de PLEADE et des réactions qui viendront.


© 2003, 2004, 2005 PLEADE / AJLSM / Anaphore
Des questions ? Des remarques ? Utilisez les listes de discussions ! Vous voulez l'utiliser ? Vous pouvez le télécharger !