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/

Définition d'un entrepôt OAI

Aujourd'hui, en particulier avec l'importance grandissante d'un protocole tel que l'OAI pour construire des portails documentaires ou le format Dublin Core pour décrire des ressources électroniques, la notion de métadonnées prend une importance considérable. Toutefois quelles sont les relations entre ces métadonnées et des documents EAD ? Ou comment fabriquer des métadonnées de type Dublin Core à partir d'un document EAD ? Le support du protocole OAI par PLEADE apporte une première réponse à ces problématiques. Mais cette implémentation sous-entend qu'il a fallu régler le problème de l'extraction de métadonnées à partir d'un document EAD.

Dans ce document, nous expliquons comment définir, configurer et utiliser un entrepôt OAI à l'intérieur d'une application PLEADE. Il est important de noter que nous ne détaillerons pas ici les principes du protocole d'échange de métadonnées OAI (protocole OAI-PHM). Nous présentons seulement spécifier qu'une base de documents constitue aussi un entrepôt OAI. Nous exposerons également la réflexion qui a accompagné la mise en place de l'extraction des métadonnées et l'identification des unités documentaires dans un document EAD.

Avertissement

Les fonctionnalités reliées aux entrepôts OAI été ajoutées dans les sources de PLEADE le 5 octobre 2004. Ces fonctionnalités feront donc partie de la version 1.1 de PLEADE et de toutes les versions subséquentes, mais elles ne font évidemment pas partie de la version 1.0.

Note

Les travaux ayant mené au suppport OAI dans PLEADE ont été en grande partie réalisés dans le cadre d'un projet de recherche avec le Centre historique des Archives nationales (CHAN, France). Nous les remercions, et tout particulièrement Florence Clavaud, de cette contribution importante.

1) Configuration de PLEADE et de l'entrepôt OAI

Définir un entrepôt OAI dans une application PLEADE ne nécessite pas d'installation supplémentaire, mais seulement quelques paramétrages complémentaires. Ainsi, si vous souhaitez définir une base de documents comme constituant un entrepôt OAI, vous devez modifier certains paramètres dans le fichier $PLEADE_HOME/pleade.properties:

  1. pour indiquer que vous désirez un entrepôt OAI, donnez la valeur true au paramètre de configuration pleade.oai.repository (par défaut dans le fichier livré avec PLEADE ce paramètre a la valeur false). Vous devriez alors avoir:

    # Désire-t-on un entrepôt oai // Do you want an OAI repository
    pleade.oai.repository=true
    

    Ce paramètre permet d'activer ou de désactiver la fonctionnalité d'entrepôt OAI dans l'application PLEADE.

  2. Indiquer l'adresse du serveur sur lequel est installé l'application PLEADE comme valeur pour le paramètre server.sdx.home.

    server.sdx.home=http://pleade.org/sdx
  3. Donner un nom à l'entrepôt grâce au paramètre pleade.oai.repository.name.

    pleade.oai.repository.name=EAD Resources
  4. Fournir l'adresse de courriel de l'administrateur de l'entrepôt comme valeur du paramètre pleade.oai.repository.adminemail.

    pleade.oai.repository.adminemail=admin.oai@pleade.org

Ces deux derniers paramètres contiennent les informations obligatoires à fournir selon le protocole OAI-PHM pour définir un entrepôt OAI.

2) Les formats de métadonnées disponibles

Le support du protocole OAI par PLEADE implémente deux formats de métadonnées: le Dublin Core simple et le Dublin Core qualifié.

2.1) Le Dublin Core simple

Le protocole OAI-PHM impose au moins un format pour les métadonnées: il s'agit du Dublin Core simple. Le Dublin Core simple est un modèle de données géré par le Dublin Core Metadata Initiative et destiné à décrire des ressources électroniques qui a vu son application s'élargir. Il s'agit d'un modèle de référence pour les échanges de métadonnées. Il est composé de 15 éléments optionnels et répétables permettant de décrire des ressources variées.

Tableau 1. Les 15 éléments du Dublin Core

identifieridentifiant de la ressource décritecoveragecouverture spatio-temporelle du contenu intellectuel de la ressource
titletitre de la ressourcelanguagelangue du contenu intellectuel
creatorauteur du contenu intellectueltypenature de la ressource (description intellectuelle)
contributorautre personne ayant contribué au contenu de la ressourceformatdescription physique ou digitale de la ressource
datedate associé à un événement de la vie de la ressourcesourceautre ressource dont est dérivée la ressource décrite
publisheréditeur de la ressourcerelationlien avec une autre ressource
descriptiondescription, notes, un aperçu du contenu de la ressourcerightsdroits
subjectdescripteurs-sujet, termes d'indexation  

2.2) Le Dublin Core qualifié

Le protocole permet aussi d'échanger des métadonnées dans d'autres formats. En plus du Dublin Core simple, un autre format d'échange a été défini; il s'agit du Dublin Core qualifié. Ce modèle est constitué des 15 éléments du Dublin Core qualifié auxquels viennent s'ajouter des éléments qualifiants.

Voir le tableau des éléments du Dublin Core qualifié.

3) Renseigner un document EAD pour PLEADE-OAI

Il est possible d'associer certains paramètres régissant l'extraction des métadonnées vers un format OAI à un document EAD lors de sa publication. En effet, quand l'option "entrepôt OAI" est activée, le formulaire de publication des documents dispose d'une section "Configuration de l'entrepôt OAI". Celle-ci permet de fixer certains paramètres:

  • Déterminer quel type de droits doit être associé à l'instrument de recherche publié. La liste des différents types de droit et leur libellé sont contenus dans le fichier $PLEADE_HOME/pleade-local/oai.xconf. Ce fichier est à modifier pour s'adapter à votre situation.

  • Choisir d'inclure ou non les sous-unités documentaires, c'est-à-dire que pour chaque unité documentaire d'avoir ou non des relations hasPart qui pointent vers les unités documentaires qu'elle contient.

  • Choisir d'inclure les descripteurs des composants archivistiques ancestraux. Si l'on choisit de les inclure, cela signifie qu'aux descripteurs propres de l'unité documentaire viendront s'ajouter ceux des niveaux archivistiques qui la contiennent.

  • Déterminer la forme d'écriture des relations entre les ressources. Les relations qui pointent vers d'autres unités documentaires issues du même document EAD peuvent s'écrire de deux manières:

    • soit seulement un nom de fichier

      par exemple :
      FRDAFANCH00AP_0000137AP_G5010.xml
    • soit sous la forme d'une URL: URL de base + identifiant de l'unité documentaire cible (celui-ci est ajouté automatiquement par PLEADE lors de l'extraction des métadonnées). Dans ce cas, il faut aussi préciser quelle est l'URL de base.

      http://pleade.org/sdx/pleade-oai/toc.xsp?fmt=tab&id=FRDAFANCH00AP_0000515AP
      avec pour URL de base http://pleade.org/sdx/pleade-oai/toc.xsp?fmt=tab&id=

      Selon que vous avez choisi d'associer une table des matières au document ou non, vous pouvez modifier cette URL de base en remplaçant toc.xsp (pour les documents avec table de matières) par doc.xsp (pour les documents sans table des matières ou affichage des documents en plein écran). Dans tous les cas, l'URL de base donnée par défaut permet de voir l'unité documentaire pointée.

4) Problématique de l'OAI dans un contexte EAD

La problématique des métadonnées et de l'EAD s'exprime beaucoup plus facilement si l'on sort du champ propre à l'archivistique. C'est pourquoi nous allons discuter de l'utilisation des métadonnées que peut faire par exemple une bibliothèque ou un centre de documentation. De plus, pour bien comprendre l'importance des métadonnées, nous allons réfléchir à leur utilisation dans un environnement bien précis, soit celui proposé par le protocole OAI.

4.1) Une ressource, une description, des enregistrements

Le protocole OAI offre un cadre théorique intéressant pour discuter de la notion de métadonnées dans un contexte documentaire. Pour ce faire, il définit trois concepts fondamentaux:

Ressource

La ressource (resource dans le protocole OAI) est l'objet lui-même, celui qui fait l'objet d'une description documentaire. Par exemple, dans une bibliothèque, les ressources sont en général des livres, alors que dans un centre d'archives les ressources seront des fonds d'archives, des séries, des dossiers, des pièces, etc. Les ressources peuvent également être des objets informatiques, comme une base de données, une page Web ou un document EAD. Les mêmes concepts et les mêmes méthodes pourront s'appliquer, mais il faut être prudent car les informations et leurs métadonnées peuvent parfois cohabiter au sein des mêmes entités informatiques, même si elles sont conceptuellement distinctes.

Description

La description (item dans le protocole OAI) est un concept abstrait. Il s'agit de l'information descriptive que l'on possède à propos d'une ressource. Cette description peut se matérialiser de multiples façons, dans de multiples formats, à l'aide de multiples systèmes. Par exemple, pour une bibliothèque, la fiche descriptive d'un ouvrage dans le catalogue sera une description. A ce niveau, il nous importe peu que ce soit une fiche imprimée ou informatique, la seule chose importante est que cette fiche existe.

Enregistrement

Les enregistrements (record dans le protocole OAI) sont des représentations concrètes, informatiques, des descriptions à propos des ressources. Il peut y avoir plusieurs enregistrements pour une même description, par exemple si ces descriptions sont disponibles en plusieurs formats ou dans différents systèmes informatiques. Un enregistrement peut être, par exemple, une notice en format MARC dans un catalogue de bibliothèque ou encore des métadonnées en format Dublin Core incluses dans une page Web.

Si l'on se place dans une perspective archivistique et dans le cadre de PLEADE, les ressources seront les fonds d'archives ou toute partie constituante de ces fonds. La description sera un instrument de recherche archivistique, ou une partie d'un instrument de recherche archivistique. Enfin, les enregistrements pourront avoir différentes formes, que ce soit des fiches dans une base de données, un document de type traitement de texte, ou un document XML en format EAD. Ainsi, dans le cadre qui nous intéresse, les enregistrements seront donc toujours des documents EAD ou des parties de documents EAD.

4.2) Éléments de description

Les éléments de description sont les différentes informations que l'on veut obtenir dans les enregistrements de métadonnées. Ce pourrait être, par exemple, un titre, un auteur, une date, etc. Puisque nous partons de documents EAD, nous pourrions considérer que cette question est déjà résolue. En effet, la DTD EAD propose un ensemble d'éléments de description pour constituer des instruments de recherche archivistique : intitulé, producteur, dates extrêmes, description du contenu, etc.

L'utilisation des éléments de description de l'EAD pour définir des métadonnées à propos des documents d'archives peut parfaitement se concevoir lorsque l'utilisation de ces métadonnées sera limitée à un contexte archivistique, où la DTD EAD est déjà utilisée ou à tout le moins connue. Toutefois, dans un contexte plus large l'utilisation de l'EAD comme format des enregistrements de métadonnées peut ne pas être appropriée. De plus, dans un contexte où le protocole OAI est utilisé pour transporter les métadonnées, il est nécessaire d'avoir des enregistrements de métadonnées en format Dublin Core.

C'est pourquoi il est intéressant et nécessaire de réfléchir aux éléments de description selon d'autres approches ou formats que l'EAD, en particulier le Dublin Core, et de proposer des correspondances ou des méthodes pour obtenir ces éléments de description depuis des structures EAD. Par exemple, comment obtenir un titre au sens Dublin Core depuis un document EAD ?

4.3) Qu'est-ce qu'une ressource ?

Dans un contexte simple tel que celui que l'on retrouve dans un centre de documentation, la question des ressources (au sens où il a été défini préalablement) est en général facile à résoudre, car il semble clair que l'ouvrage intellectuel (monographie, périodique, article de périodique) constitue une ressource acceptable et efficace à manipuler ou exploiter. Toutefois, dans un contexte archivistique, cette notion de ressource est beaucoup plus complexe et difficile à résoudre.

L'approche descriptive à multiples niveaux qu'utilisent les archivistes les amène à créer des instruments de recherche qui vont du général au particulier. Par exemple, l'instrument de recherche débutera par une description du fonds, ensuite les grandes séries feront l'objet elles-mêmes d'une description, et ainsi de suite pour les cartons, les dossiers, les documents ou pièces, etc. Pour compliquer légèrement la situation, dans le cas où l'instrument de recherche est structuré en XML avec la DTD EAD, un seul document XML contiendra l'ensemble de ces descriptions.

Dans un tel scénario, qu'est-ce qu'une ressource ? Le fonds ? Sûrement. Les séries ? Pourquoi pas ? Les pièces ? Les utilisateurs l'exigeront. En effet, tous ces niveaux de description peuvent être associés à une ressource, si le contexte où l'on utilisera cette notion de ressource le demande. Ainsi, dans un portail documentaire qui recense des objets du patrimoine d'une région, les utilisateurs seront intéressés à retrouver individuellement les différents sceaux conservés par un service d'archives. Ils seront également heureux d'apprendre que le service d'archives conserve un fonds à propos d'une institution, fonds qui contient notamment des sceaux.

Ici, nous nous intéressons au cas particulier où l'instrument de recherche est structuré en format XML avec la DTD EAD. C'est pourquoi nous devons proposer des solutions permettant d'identifier les ressources à l'intérieur d'un document EAD, afin de faire une extraction des métadonnées qui contienne non seulement les informations pertinentes mais en plus qui s'applique aux ressources appropriées.

4.4) Les identifiants

La plupart du temps, on souhaite obtenir des métadonnées dans le but de les échanger avec d'autres partenaires, ou dans le but d'alimenter des services documentaires de type portail ; ce sont du moins les contextes d'utilisation qui sous-tendent cette fonctionnalité.

Pour y arriver, il est essentiel de pouvoir également fournir des identifiants pérennes pour les différentes ressources et enregistrements. C'est pourquoi il est également important de réfléchir à la manière de définir ces identifiants, et ce pour chaque ressource que l'on peut identifier dans un document EAD.

L'identifiant permet aussi de créer des liens entre des ressources (instrument de recherche et ressources décrites, collection et composants archivistiques).

Dans PLEADE, l'identification des ressources subalternes est réglé au moment de la fragmentation. Chaque élément identifié comme formant une unité documentaire (d'après les critères de fragmentation) se voit attribuer un attribut pleade:id généré automatiquement et formé à partir de l'identifiant unique de l'instrument de recherche et de l'identifiant (attribut id) de l'élément correspondant. Si cet identifiant n'existe pas, alors il est généré automatiquement. Et à priori les instruments de recherche disposent d'un identifiant unique dans le contexte du centre d'archives basé sur celui du fonds décrit. Pour que celui-ci demeure unique dans un contexte d'utilisation plus large, une bonne pratique consiste à lui adjoindre une chaîne de caractères identifiant l'organisme de dépôt. Néanmoins, cette solution limite tout de même la pérennité des informations. Mais, à défaut d'avoir trouvé une autre solution plus satisfaisante...

5) Les ressources dans un document EAD

Comment identifier les parties pouvant décrire des ressources dans un document EAD ? La souplesse d'utilisation offerte par l'EAD ne facilite pas l'identification des parties susceptibles d'être éclatées en ressources indépendantes. En effet, la structure d'un instrument de recherche n'est pas fixe et dépend en général de l'application des consignes en vigueur dans l'institution productrice. Donc à priori, il n'existe pas de règles génériques pour déterminer les unités de fragmentation d'un instrument de recherche.

Dans PLEADE, un certain nombre de méthodes de fragmentation ont été mises en place. Elles sont déterminées par des critères à fixer au moment de la publication des documents EAD dans l'application. Il en résulte une série d'unités documentaires qui dans le contexte de l'OAI sont assimilées à des ressources. Dans la suite du document, on regroupera ces méthodes de fragmentation sous le terme "marquage implicite".

Une autre méthode pourrait aussi être envisagée, le marquage explicite. Lors de la production d'un document EAD, il s'agirait de marquer l'élément correspondant à une unité documentaire pertinente. La difficulté serait de faire en sorte que le document EAD marqué demeure valide suivant la DTD ou le schéma EAD. Cette contrainte implique donc l'utilisation d'un élément EAD pour coder cette information. Cet élément doit être présent dans tous les éléments susceptibles de représenter des ressources. Il semble que l'attribut encodinganalog serait le seul qui convienne.

Ces deux méthodes devraient permettre de couvrir la majeure partie des cas. D'autant plus qu'il serait possible de les utiliser conjointement.

5.1) Méthodes d'identification des ressources

Selon le marquage appliqué, implicite ou explicite, la manière de marquer le document, c'est-à-dire d'ajouter dans le code XML du document l'information indiquant où la fragmentation doit se faire, diffère:

  • dans PLEADE, soit la marquage implicite, insertion de l'attribut particulier pleade:break avec la valeur true dans les éléments au niveau desquels la fragmentation du document EAD doit s'effectuer, selon la méthode choisie.

  • pour le marquage explicite, insertion de oai:resource dans l'attributencodinganalog pour indiquer qu'au niveau de cet élément une ressource est identifiée.

    Exemple 1. Marquage explicite

    c/@encodinganalog="oai:resource autres informations"

6) Les éléments Dublin Core dans un document EAD

Une fois les unités documentaires marquées dans un document EAD, il reste à définir les champs-cible de l'extraction. Pour cette étape, encore deux méthodes possibles:

  • l'extraction explicite, soit l'indication au niveau d'un élément de sa cible

  • l'extraction implicite selon un tableau de correspondance avec en plus parfois des règles d'héritage. L'héritage touche principalement les termes d'indexation, le producteur, les cotes et les dates. Néanmoins, il est assujetti à des paramètres fixés dans le formulaire de publication des documents.

Malgré les règles d'héritage mises en place, il faut demeurer conscient de la perte d'information que le passage de l'EAD vers un format de données moins riche occasionne; en effet, on se propose de passer d'un modèle de données comportant plus d'une centaine d'éléments à une petite trentaine d'éléments. Ceci incite à donner des contenus significatifs aux éléments concernés par cette extraction.

6.1) Extraction explicite des métadonnées

Par l'intermédiaire de l'attribut encodinganalog, on indique à quel élément du Dublin Core qualifié on veut faire correspondre tel ou tel élément (ce critère viendra en plus de la correspondance implicite).

Afin d'identifier de manière univoque l'élément de destination, il faut que sa dénomination soit normalisée. Or pour définir de manière non ambiguë un élément, son nom ne suffit pas et fait aussi préciser le schème auquel il appartient. En ce qui concerne les éléments Dublin Core, ils disposent déjà d'identifiants pérennes sous la forme d'URI. Ce qui donne:

  • pour les éléments du Dublin Core simple : par exemple title, http://purl.org/dc/elements/1.1/title

  • pour les éléments qualifiants: par exemple created, http://purl.org/dc/terms/created

Cette solution présente l'avantage de contenir toute l'information nécessaire à l'extraction explicite, schème et élément cible, au même endroit. Elle autorise aussi es correspondances multiples; il suffit de séparer les occurrences des éléments cibles par des espaces.

encodinganalog="http://purl.org/dc/elements/1.1/audience http://purl.org/dc/elements/1.1/rights"

6.2) Extraction implicite des métadonnées

L'extraction implicite des métadonnées consiste à appliquer automatiquement les correspondances préalablement établies. Dans un tableau, on a indiqué pour chacun des éléments du Dublin Core qualifié quels étaient les éléments EAD d'où il fallait extraire l'information.

Ce tableau de correspondance détaille donc les correspondances pour deux niveaux archivistiques, eadheader et archdesc ou c, entre les éléments Dublin Core et les éléments EAD. On ne devrait retrouver dans ce tableau que les correspondances générales et applicables pour tous les documents EAD. Pour les cas particuliers, on pourra toujours passer par l'extraction explicite.

Voir le tableau de correspondance DC/EAD.

7) Autres informations

7.1) Le fichier $PLEADE_HOME/pleade-local/soai.xconf

Le fichier $PLEADE_HOME/pleade-local/soai.xconf permet de coder des informations propres à l'environnement et donc susceptibles d'être modifiées par les gestionnaires d'installations PLEADE . Ces informations interviennent essentiellement dans le processus de génération des enregistrements OAI. Nous expliquons ici comment modifier ce fichier.

Le fichier $PLEADE_HOME/pleade-local/soai.xconf est un fichier XML. Il permet de donner pour des niveaux archivistiques susceptibles de constituer des unités documentaires des informations complémentaires que l'on ne peut pas extraire du fichier EAD et communes à un certain nombre d'instruments de recherche.

Pour chaque niveau archivistique, on a quelque chose du type:

<units type="eadheader">
		<additions>
			<dc:type>instrument de recherche</dc:type>
			<dc:type>finding aid</dc:type>
		</additions>
		<access-rights>
			<access-right code="public">
				<dc:rights>droits moraux et droits d'exploitation commerciale réservés au Centre historique des Archives nationales</dc:rights>
				<dcterms:accessRights>données publiques</dcterms:accessRights>
			</access-right>
			<access-right code="private">
				<dc:rights>droits moraux et droits d'exploitation commerciale réservés uniquement au Centre historique des Archives nationales</dc:rights>
				<dcterms:accessRights>données non diffusables</dcterms:accessRights>
			</access-right>
		</access-rights>
	</units>

Quelques clés pour modifier et développer ce fichier:

  • L'élément units définit un niveau archivistique identifié grâce à l'attribut type. Ainsi dans l'exemple, les informations saisies s'appliqueront à l'unité documentaire englobée dans l'élément EAD eadheader.

  • L'élément additions contient des métadonnées exprimées en Dublin Core, simple ou qualifié, que l'on souhaite ajouter à celles qui seront extraites du document EAD. Il est conseillé de saisir ces informations dans plusieurs langues; dans ce cas, répéter l'élément autant de fois que de langue.

  • L'élément access-rights contient tous les types de droits susceptibles de pouvoir s'appliquer à un instrument de recherche. Aussi cet élément n'est-il présent que dans <units type="eadheader"/>. Chaque type de droits fait l'objet d'un access-right et est identifié par un code, attribut code. La valeur de ce dernier correspond à la valeur qui s'affiche dans la liste déroulante au niveau du critère "Type de droits à utiliser" de la section "Configuration de l'entrepôt OAI" du formulaire de publication d'un document dans PLEADE.

    L'élément access-rights est constitué des métadonnées relatives à la gestion des droits et codées en Dublin Core, simple ou qualifié. Là aussi, on peut saisir l'information en plusieurs langues et donc répéter l'élément correspondant.


© 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 !