Documentation SDX-2 Télécharger Installer Présentation Configuration Indexation Recherche OAI Entrepôts Moisson Javadoc Référence API-XSP Migration Schemas Performances | # SDX et les entrepôts OAI Un entrepôt OAI doit rendre disponibles des métadonnées à propos d'objets documentaires. Dans SDX, les objets documentaires sont gérés au niveau d'une base de documents, car ce sont les documents XML indexés, ou encore les fragments de ces documents XML. Il est donc tout à fait naturel d'associer un entrepôt OAI à une base de documents dans SDX. SDX permet donc de transformer toute base de documents en entrepôt OAI, et ce en intervenant au niveau de la configuration de cette base de documents (donc dans le fichier `application.xconf`) et, éventuellement, en programmant des pipelines. SDX se chargera des aspects tels que les dates de dernière modification, les enregistrements supprimés, etc. La reponsabilité du développeur de l'application est donc de : Fournir des informations générales à propos de l'entrepôt. Définir quelles unités documentaires de la base de documents feront partie de l'entrepôt OAI. Rendre disponibles des formats de métadonnées. Produire, pour chaque format, les métadonnées à partir des unités documentaires. Les trois premiers items sont purement déclaratifs et très simples à mettre en place. Le dernier item peut être plus ou moins compliqué, selon la complexité de la transformation entre une unité documentaire et un format de métadonnées. Puisqu'un entrepôt OAI est associé à une base de documents dans SDX, la configuration de cet entrepôt OAI se fera à l'intérieur d'un élément `sdx:documentBase` dans le fichier `application.xconf`. On aura donc une structure qui ressemble à celle-ci :
      <sdx:documentBase ...>
        <sdx:repositories>...</sdx:repositories>
        <sdx:fieldList>...</sdx:fieldList>
        <sdx:index>...</sdx:index>
        <sdx:oai-repository>...</sdx:oai-repository>
      </sdx:documentBase>
Dans la suite de cette page, nous allons expliquer la structure de l'élément `sdx:oai-repository`. ## Informations générales à propos de l'entrepôt OAI C'est l'élément `sdx:oai-repository` lui-même qui contient les informations générales à propos de cet entrepôt elles doivent être renseignées par le développeur de l'application. Ces informations sont surtout utiles pour les requêtes OAI avec le verbe Identify. Le nom de l'entrepôt OAI est une chaîne de caractères destinée à être lue par des personnes et qui permet de l'identifier sommairement. L'attribut `name` permet de renseigner cette information ; il est obligatoire. L'URL de base indique l'URL où se trouve l'entrepôt OAI. Eventuellement, SDX pourra peut-être renseigner automatiquement cette information, mais pour l'instant, vous devez le faire à l'aide de l'attribut `baseURL`, qui est obligatoire. Les adresses des administrateurs permettent de rejoindre par courrier électronique une ou des personnes en charge de cet entrepôt OAI. L'attribut `adminEmail` contient ces adresses, qui doivent être séparées par une espace s'il y en a plusieurs. Cet attribut est obligatoire. L'attribut `noPerResponse` permet de spécifier le nombre de documents renvoyés par page de résultats. La valeur par défaut est `1000`. Voici un exemple de configuration de ces informations générales :
      <sdx:oai-repository
        name="Thèses de doctorat de l'université Lumière Lyon 2 (France)"
        baseURL="http://monserveur.com/sdx/sdx/oai/mon-appli/ma-base"
        adminEmail="quelquun@quelquepart.pays unautre@ailleurs.com">
Les autres informations générales, c'est-à-dire la version du protocole supportée (2.0), la date la plus ancienne dans les documents de l'entrepôt OAI, le support ou non des enregistrements supprimés et la granularité des dates sont automatiquement générées par SDX ; elles n'ont pas besoin d'être renseignées dans le `application.xconf`. A noter que la granularité gérée par SDX est du type "à la journée" : "`YYYY-MM-DDThh:mm:ssZ`". Par ailleurs, SDX ne supporte pas deux fonctionnalités optionnelles du protocole : la possibiltié de fournir une description plus détaillées de l'entrepôt OAI de même que la possibilité de compresser les données. C'est pourquoi aucune configuration n'est prévue pour ces informations générales. ## Les unités documentaires faisant partie de l'entrepôt OAI Dans une base de documents SDX, on retrouve un certain nombre d'unités documentaires, soit des ensembles d'information qui peuvent être retournés comme résultat de recherche. La plupart du temps, ces unités documentaires correspondent à des documents XML indexés, mais parfois ces documents ont été fragmentés et dans ce cas il y aura plus d'unités documentaires que de documents XML. Par ailleurs, le scénario le plus courant consiste à offrir toutes les unités documentaires d'une base de documents dans l'entrepôt OAI correspondant. Toutefois, il peut arriver que seule une partie des unités documentaires doit s'y retrouver. SDX permet de configurer cela aisément sous la forme de restrictions. Le mécanisme général des restrictions est celui d'inclusion et d'exclusion d'unités documentaires, inclusions et exclusions qui doivent être exprimées sous la forme d'une requête de recherche. Si aucune mention de restriction n'est présente, alors toutes les unités documentaires font partie de l'entrepôt OAI. S'il y a au moins une inclusion, seules les unités documentaires qui la satisfont seront concernées, sauf si elles sont explicitement exclues. C'est un élément `sdx:oai-subset` qui permet de spécifier les restrictions ; il est donc facultatif et s'il n'est pas présent toutes les unités documentaires seront ajoutées à l'entrepôt. Il peut avoir deux sous-éléments, `sdx:include` pour une inclusion et `sdx:exclude` pour une exclusion. Ces deux éléments peuvent être dans n'importe quel ordre et répétés. Voici quelques exemples :
      <sdx:oai-repository>
        ...
        <!-- Seulement les unités qui satisfont une requête -->
        <sdx:oai-subset>
          <sdx:include query="sujet:physique"/>
        </sdx:oai-subset>
      </sdx:oai-repository>

      <sdx:oai-repository>
        ...
        <!-- Toutes les unités sauf certaines -->
        <sdx:oai-subset>
          <sdx:exclude query="statut:temp"/>
        </sdx:oai-subset>
      </sdx:oai-repository>

      <sdx:oai-repository>
        ...
        <!-- Combinaison de requêtes -->
        <sdx:oai-subset>
          <sdx:include query="sujet:physique sujet:chimie"/>
          <sdx:exclude query="statut:temp"/>
        </sdx:oai-subset>
      </sdx:oai-repository>
## Les formats de métadonnées disponibles Tous les entrepôts OAI doivent fournir des métadonnées en format Dublin Core. Mais d'autres formats peuvent également être envoyés sur demande. On doit donc spécifier quels sont les formats de métadonnées à offrir, mais aussi comment obtenir ces métadonnées à partir des unités documentaires contenues dans la base. Chaque format de métadonnées est spécifié par un élément `sdx:oai-format` que l'on retrouve à l'intérieur de `sdx:oai-repository`. Les attributs de cet élément permettent d'identifier et décrire ce format : L'attribut `name` permet de spécifier un nom descriptif pour ce format de métadonnées. Cet attribut est obligatoire. L'attribut `metadataPrefix` permet de spécifier le préfixe de ce format de métadonnées. Cette information est importante car toute la gestion des formats dans le protocole OAI se fait à l'aide de ce préfixe. Cet attribut est obligatiore. L'attribut `namespace` permet de spécifier le domaine de noms (au sens XML) associé à ce format de métadonnées, ce qui est également une contrainte du protocole OAI. L'attribut est obligatoire. L'attribut `schemaUrl` permet de spécifier l'endroit où se trouve le schéma XML que respectent les métadonnées. Encore une fois, il s'agit d'une contrainte imposée par le protocole OAI : toutes les métadonnées doivent respecter un schéma disponible via une URL. Cet attribut est donc bien sûr obligatoire. L'attribut `rootElement` permet de renseigner l'élément racine du format de métadonnées. TODO: pourquoi ? Il est optionnel. Ces attributs permettent donc de connaître les informations générales à propos du format de métadonnées. Il reste ainsi à savoir comment SDX doit obtenir ces métadonnées, et pour cela le développeur d'une application peut utiliser deux méthodes : les correspondances de champs et les pipelines. ### Méthode par correspondance de champs Cette méthode est définitivement la plus simple. En effet, une base de documents SDX contient un ou plusieurs champs de recherche propres à SDX. Dans certains cas, le format de métadonnées sera très simple et pourra être obtenu directement à partir de ces champs. Considérons le cas où la base de documents possède les champs suivants :
      <sdx:fieldList>
        <sdx:field name="auteur" type="field"/>
        <sdx:field name="titre" type="field"/>
        <sdx:field name="sujet" type="field"/>
      </sdx:fieldList>
Les champs auteur et sujet peuvent être répétés pour une même unité documentaire. Le protocole OAI nous impose de supporter au moins le format Dublin Core non qualifié, et celui-ci n'est qu'une collection plate d'éléments d'information simple, de type :
      <oai_dc:dc
          xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
          xmlns:dc="http://purl.org/dc/elements/1.1/"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/
               http://www.openarchives.org/OAI/2.0/oai_dc.xsd">

        <dc:identifier>Un identifiant</dc:identifier>
        <dc:title>Le titre</dc:title>
        <dc:creator>Un auteur</dc:creator>
        <dc:creator>Un autre auteur</dc:creator>
        <dc:subject>Un premier sujet ; Un second sujet</dc:subject>
      </oai_dc:dc>
Pour une situation semblable à celle-ci, on peut tout simplement obtenir le format Dublin Core en faisant correspondre les champs SDX à des éléments Dublin Core. La configuration nécessaire pour produire cet exemple serait :
       <sdx:oai-format
             name="OAI Dublin core"
             metadataPrefix="oai_dc"
             namespace="http://purl.org/dc/elements/1.1/"
             schemaUrl="http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
         <sdx:oai-fields>
           <sdx:oai-field name="identifier" sdxField="sdxdocid"/>
           <sdx:oai-field name="title" sdxField="titre" repeated="repeated"/>
           <sdx:oai-field name="creator" sdxField="auteur" repeated="repeated"/>
           <sdx:oai-field name="subject" sdxField="sujet" repeated="concatenate" separator=" ; "/>
         </sdx:oai-fields>
       </sdx:oai-format>
Cet exemple est déjà complet. Les éléments `sdx:oai-fields` et `sdx:oai-field` permettent respectivement de spécifier la liste de correspondances. Ensuite, l'élément `sdx:oai-field` peut avoir quatre attributs qui ont les significations suivantes : `name` : le nom de l'élément à générer dans le format de métadonnées. Obligatoire. `sdxField` : le nom du champ de recherche SDX dans la base de documents. Obligatoire. `repeated` : ce que SDX doit faire si un champ SDX est répété pour une unité documentaire. Les deux valeurs possibles sont : `repeated` et dans ce cas SDX va créer autant d'éléments dans le format de métadonnées qu'il y d'occurrences de champs SDX ; `concatenate`, et dans ce cas SDX va créer un seul élément dans le format de métadonnées, mais il va concaténer toutes les valeurs du champs SDX. Cet attribut est optionnel, la valeur par défaut est `repeated`. `separator` : le séparateur à utiliser entre les occurrences du champ SDX lorsqu'on décide de concaténer ces valeurs dans un seul élément de métadonnées. L'attribut est optionnel, sa valeur par défaut est `;` , et il est bien sûr inutile si on décide de répéter les éléments de métadonnées. Produire des métadonnées par correspondance de champs est donc très simple et ne fait intervenir que de la configuration. Si vous définissez des champs SDX proches de vos métadonnées, et que votre format de métadonnées est plat (comme le Dublin Core de l'OAI), cette technique peut être tout à fait suffisante. ### Méthode par pipeline Dans bien des cas, la méthode par correspondance de champs ne sera pas suffisante. Soit parce que le format de métadonnées n'est pas plat, ou encore parce qu'il n'est pas possible de produire les valeurs adéquates à partir des champs SDX. Dans ce cas, il faut utiliser la méthode du pipeline SDX. Conceptuellement, cette méthode est très simple : à chaque fois que SDX doit envoyer des métadonnées à propos d'une unité documentaire, il va transformer l'unité documentaire (forcément du XML) à l'aide d'un pipeline SDX, semblable à un pipeline utilisé pour indexer par exemple. La sortie de ce pipeline doit donc correspondre au format de métadonnées souhaité, en particulier respecter le schéma XML spécifié. Il est de la responsabilité du développeur de l'application de vérifier que les données produites par le pipeline sont correctes. On peut spécifier un pipeline de la même manière que pour un pipeline d'indexation. Il s'agit donc d'une série de transformations, chaque transformation pouvant être une transformation XSLT ou une classe Java. Le plus simple est bien sûr d'avoir une XSLT pour faire le travail. Voici un exemple d'un format de métadonnées produit par un pipeline avec deux transformations, la première étant une classe Java et la seconde une XSLT :
       <sdx:oai-format
             name="Mon format"
             metadataPrefix="mf"
             namespace="http://monserveur.com/mf/"
             schemaUrl="http://monserveur.com/mf.xsd">
        <sdx:pipeline id="oai-mf">
          <sdx:transformation id="oai-mf-1" type="com.monserveur.oai.mf"/>
          <sdx:transformation id="oai-mf-2" type="XSLT" src="../oai/mf.xsl"/>
        </sdx:pipeline>
      </sdx:oai-format>
Comme toujours, la classe com.monserveur.oai.mf doit implémenter l'interface fr.gouv.culture.sdx.pipeline.Transformation. Soulignons également que les méthodes par correspondance de champs et par pipeline sont exclusives ; un seul élément `sdx:pipeline` ou `sdx:oai-fields` doit être présent dans un élément `sdx:oai-format`.
| Auteur : Martin Sévigny ( AJLSM ) - 2005-10-06

| Home |
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.