1ère étape : préparer la configuration

Depuis le module ORI-OAI-quick-install, lancez la commande suivante :

ant init-config-repository

Ceci va créer l'arborescence des dossiers et fichiers servant à personnaliser le module dans le dossier [PATH_CUSTOM_CONFIG]/ori-oai-repository.

Attention

C'est au sein de ce dossier, et uniquement dans ce dossier que vous devrez personnaliser le module.

Le dossier a été créé avec les propriétés et les fichiers de configuration couramment modifiés par les exploitants. Si d'autres fichiers devaient être modifiés pour une configuration encore plus poussée, il suffit de copier le fichier de configuration d'origine depuis les sources du module vers le dossier config en respectant la même arborescence. Lors du déploiement, le fichier du dossier [PATH_CUSTOM_CONFIG] écrasera celui fourni par défaut dans les sources.

Structure du dossier [PATH_CUSTOM_CONFIG]/ori-oai-repository

Depuis la version 2.0 de ORI-OAI, toutes les configurations et la personnalisation se font depuis le dossier [PATH_CUSTOM_CONFIG] (avec 1 sous-dossier par module).
Voyons la structure du module qui nous concerne ici :

ori-oai-repository
- config
  - custom-config.properties : permet de définir les propriétés modifiables par l'exploitant
  - properties
    - repository-crosswalks-custom.xml : permet de définir de nouveaux formats ou de supprimer les formats exposés par le module
    - repository-filters.xml : permet de définir les filtres d'exposition des métadonnées
    - repository-sets-custom.xml : permet de définir de nouveaux sets ou de modifier les existants
- webapp
  - css : dossier permettant de surcharger les CSS fournies par défaut dans le module
  - media : images nécessaires à l'affichage

Configurations avancées

Filtrage des fiches indexées à exposer

Dans le fichier [PATH_CUSTOM_CONFIG]/ori-oai-repository/config/properties/repository-filters.xml, il y a possibilité de filtrer les fiches indexées que l'on veut exposer. Ce filtrage s'opère sur n'importe quelle métadonnée indexée (ex. : les entrepôts OAI , les formats de fiches....).

Chaque filtrage s'opère en ajoutant une entrée dans une des deux catégories de filtre :

commonFiltersList : ce sont les filtres communs à tous les formats.
formatFiltersList : ce sont les filtres spécifiques à chaque format.

En l'absence de filtre, toutes les fiches de métadonnées indexées sont exposées (aucun filtrage n'est effectué).

1. Exemples de filtres communs à tous les formats

Dans la configuration proposée par défaut, on filtre sur l'entrepôt d'origine (md-ori-oai-repository), en ne choisissant d'exposer que les fiches en provenance du workflow (ori-oai-workflow), donc de l'entrepôt local, ce qui correspond à l'entrée dans le bean commonFiltersList ainsi définie :

<entry key="md-ori-oai-repository">
	<list>
		<value>ori-oai-workflow</value>
	</list>
</entry>

En l'absence de liste, aucun filtrage n'est effectué sur l'entrepôt d'origine.

Autre exemple : Filtrage sur les formats de métadonnées
Définition d'une liste de formats, qui permet de restreindre la liste définie par les Crosswalks (voir section "Configuration des formats exposés", plus bas) :

<entry key="md-ori-oai-namespace">
	<list>
		<value>http://www.openarchives.org/OAI/2.0/oai_dc/</value>
	</list>
</entry>

En l'absence de liste ou de filtre de ce type, le filtrage sur les formats se base uniquement sur les Crosswalks (voir "Configuration des formats exposés", plus bas).

2. Exemples de filtres propres à un format

Si on souhaite n'exposer que les fiches LOM dont le titre est "java" ou commence par "info", il faut ajouter dans le bean formatFiltersList l'entrée suivante :

<entry key="http://ltsc.ieee.org/xsd/LOM">
	<map>
		<entry key="//lom:general/lom:title/lom:string[starts-with(@language,'fr')]">
			<list>
				<value>java</value>
				<value>info*</value>
			</list>
		</entry>
	</map>
</entry>

Configuration des formats exposés

Les formats exposés sont configurés dans le fichier [PATH_CUSTOM_CONFIG]/ori-oai-repository/config/properties/repository-crosswalks-custom.xml.

Deux types de configurations simples existent : l'exposition d'une fiche à l'identique et l'exposition d'une fiche par transformation XSLT.

Exposition d'un format à l'dentique (IdentityCrosswalk)

Ce type d'exposition ne fait qu'ajouter une couche OAI à une fiche de métadonnées déjà composée dans le format requis.

La configuration de ce type d'exposition se résume à définir le nom d'espace (namespace), l'URL du schéma XSD et le préfixe utilisé pour ce format. Ci-dessous, exemple pour l'exposition en LOM de fiches LOM :

<bean id="LOMIdentityCrosswalk"
 class="org.orioai.repository.domain.logic.crosswalk.IdentityCrosswalk" init-method="init">
 <property name="nameSpaceURL" value="http://ltsc.ieee.org/xsd/LOM" />
 <property name="schemaURL" value="http://ltsc.ieee.org/xsd/lomv1.0/lom.xsd" />
 <property name="inPrefix" value="lom" />
</bean>

La propriété inPrefix définit quel format d'entrée ce Crosswalk utilise, alors que le nom d'espace et le schema XSD sont ceux de la fiche produite en sortie (ici les deux schémas coïncident).

Exposition d'un format par transformation XSLT

Il s'agit de convertir une fiche d'un format donné vers un format différent, en utilisant une feuille de transformation XSL

La configuration doit, en plus des paramètres du format, préciser le nom du fichier XSLT. Ci-dessous, exemple pour l'exposition en Dublin Core de fiches LOM :

<bean id="LOMtoDCCrosswalk"
 class="org.orioai.repository.domain.logic.crosswalk.XSLTCrosswalk"
 init-method="init">
 <property name="xsltFile" value="${lomtodcFile}"/>
 <property name="nameSpaceURL" value="http://www.openarchives.org/OAI/2.0/oai_dc/ " />
 <property name="schemaURL" value="http://www.openarchives.org/OAI/2.0/oai_dc.xsd" />
 <property name="inPrefix" value="lom" />
 <property name="outPrefix" value="oai_dc" />
</bean>

La propriété inPrefix définit le format d'entrée (ici le LOM). La propriété outPrefix désigne le préfixe du format en sortie, après la transformation (ici le Dublin Core).

Crosswalk composite

Lorsqu'un format à produire en sortie utilise plusieurs formats possibles en entrée, comme c'est le cas pour OAI_DC qui peut provenir aussi bien de fiches LOM que Dublin Core, on configure une troisième sorte de Crosswalk, le Crosswalk composite, qui rassemble plusieurs Crosswalk des types précédents :

<bean id="compositeDCCrosswalk"
   class="org.orioai.repository.domain.logic.crosswalk.CompositeCrosswalk"  init-method="init">
   <property name="nameSpaceURL" value="http://www.openarchives.org/OAI/2.0/oai_dc/" />
   <property name="schemaURL" value="http://www.openarchives.org/OAI/2.0/oai_dc.xsd" />
   <property name="outPrefix" value="oai_dc" />
   <property name="crosswalks">
      <list>
         <ref bean="DCIdentityCrosswalk"  />
         <ref bean="LOMtoDCCrosswalk"  />
         <ref bean="TEFtoDCCrosswalk"  />
         <ref bean="CDMtoDCCrosswalk"  />
         <ref bean="DCFRtoDCCrosswalk"  />
      </list>
   </property>   
</bean>

Configuration des ensembles (sets) à partir d'une classification

(voir Cas d'utilisation : définir des nouveaux sets)

La génération d'un lot de sets s'appuie sur un vocabulaire de référence, qui doit être géré dans le module ORI-OAI-Vocabulary, sous la forme d'un fichier XML. Ce vocabulaire peut être utilisé par ailleurs dans les autres modules. Ce fichier est donc centralisé pour assurer la cohérence de l'ensemble, et accessible par Web Service via le module ORI-OAI-Vocabulary.

Le vocabulaire de référence va donner autant de sets qu'il contient de valeurs : 1 valeur dans le vocabulaire = 1 set.

Une implémentation simulacre (Mock) est fournie au cas où aucun module vocabulary ne serait disponible. Elle permet d'utiliser des fichiers sur le système de fichier local.

La configuration des ensembles proprement dite se situe dans le fichier [PATH_CUSTOM_CONFIG]/ori-oai-repository/config/properties/repository-sets-custom.xml. Elle se fait à l'aide des beans de class OaiSetInfos. Chacun de ces beans permet de définir le vocabulaire de référence et la façon dont il est mis en relation avec une métadonnée d'un format particulier.

Par défaut, trois beans OaiSetInfos sont définis dans le fichier livré par défaut (dont un, celui d'UNIT, est commenté et donc inactif). L'établissement voulant exposer ses fiches aura en effet vraisemblablement une préférence pour une classification propre à son établissement, ce qui ne l'empêchera pas, loin de là, d'être interopérable avec UNIT grâce à l'utilisation du schéma pivot Dewey.

Ces trois ensembles prédéfinis sont :

les 100 premiers codes Dewey
le champ "cout"

la classification UNIT (commentée donc)

<bean id="set100DeweyTaxonomy" class="org.orioai.repository.domain.model.set.OaiSetInfos" init-method="init">
   <property name="vocabularyId" value="dewey_100_taxonomie_regexp"/>
   <property name="rootTag" value="vdex"/>
   <property name="termXpath" value="//vdex:term"/>
   <property name="valueXpath" value=".//orioai:value"/>
   <property name="setSpecXpath" value="vdex:termIdentifier"/>
   <property name="setNameXpath" value="vdex:caption/vdex:langstring[@language = 'fr']"/>
   <property name="vocabularyNameXpath" value="//vdex:vocabName/vdex:langstring[@language = 'fr']"/>
   
   <property name="sources">
      <map>
         <entry>
            <key>
               <value>http://ltsc.ieee.org/xsd/LOM</value> 
            </key> 
            <bean class="org.orioai.repository.domain.model.set.OaiSetSourceInfos">
               <property name="xpath">
                  <list>
                     <value>//lom:classification/lom:taxonPath[lom:source/lom:string='dewey']/lom:taxon/lom:id</value> 
                     <value>//lom:classification/lom:taxonPath[starts-with(lom:source/lom:string,'CDD') or starts-with(lom:source/lom:string,'DDC')]/lom:taxon/lom:id</value>
                  </list>
               </property>
               <property name="luceneFieldName">
                  <list>
                     <value>lom.classification.ddc.id</value>
                  </list>
               </property>
            </bean>
            
         </entry>
         <!--entry>
            <key>
               <value>http://www.openarchives.org/OAI/2.0/oai_dc/</value> 
            </key> 
            <bean class="org.orioai.repository.domain.model.set.OaiSetSourceInfos">
               <property name="xpath">
                  <list>
                     <value>//dc:dewey</value>
                  </list>
               </property>
               <property name="luceneFieldName">
                  <list>
                     <value>dc.ddc</value>
                  </list>
               </property>
            </bean>
         </entry-->
      </map>
   </property>
</bean>

Configuration du vocabulaire:
Dans la première partie du bean, on trouve la propriété vocabularyId qui définit l'identifiant du vocabulaire utilisé, rootTag et valueXpath qui désignent les tag XML respectivement de la racine du vocabulaire et celui contenant les valeurs de la catégorie, qui seront comparées aux valeurs trouvée dans la taxonomie des fiches.
Lorsque qu'une des valeurs d'une catégorie correspond avec celle trouvée dans la fiche, la fiche appartient à l'ensemble de cette catégorie.
Les propriétés setSpecXpath et setNameXpath désignent les éléments XML(tag ou attribut) pour le nom et le code des ensembles générés.
Mise en correspondance avec une donnée de la fiche :
La propriété sources regroupent sous forme de Map la correspondance, pour différents formats de fiche, avec les valeurs définies pour les ensembles de la classification. Ainsi, pour chaque entrée la clé (key) désigne le nom d'espace d'un format de fiche, et les sous-propriétés xpath et luceneFieldName, respectivement le chemin XPATH de la donnée dans la fiche et le nom utilisé dans le module ORI-OAI-indexing pour indexer cette donnée.

Niveau de déboggage

Le niveau de débogage peut être modifié en éditant le fichier build.properties. Deux modes sont disponibles : prod ou debug.

Repository - Configuration avancée