Table of Contents | ||||||||
---|---|---|---|---|---|---|---|---|
|
1ère étape : préparer la configuration
Depuis le module ORI-OAI-quick-install, lancez la commande suivante :
Code Block |
---|
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.
Note | ||
---|---|---|
| ||
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 :
Panel |
---|
|
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 :
Code Block | ||||
---|---|---|---|---|
| ||||
<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) :
Code Block | ||||
---|---|---|---|---|
| ||||
<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 :
Code Block | ||||
---|---|---|---|---|
| ||||
<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 :
Code Block | ||||
---|---|---|---|---|
| ||||
<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 :
Code Block | ||||
---|---|---|---|---|
| ||||
<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 :
Code Block | ||||
---|---|---|---|---|
| ||||
<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)
Code Block xml xml <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.
Note | ||
---|---|---|
| ||
Avant de procéder à la configuration avancée, il est conseillé de consulter le document "Navigation dans les fichiers" pour mieux comprendre la structure des différents fichiers. |
Configurations avancées
Filtrage des fiches indexées à exposer
...
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 :
Code Block |
---|
<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) :
Code Block |
---|
<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 :
Code Block |
---|
<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
...
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)
...
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 :
Code Block |
---|
<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
...
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 :
Code Block |
---|
<bean id="LOMtoDCCrosswalk"
class="org.orioai.repository.domain.logic.crosswalk.XSLTCrosswalk"
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="inPrefix" value="lom" />
<property name="outPrefix" value="oai_dc" />
<property name="xsltFile" value="${xslt:dclom}"/>
</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
...
Code Block |
---|
<bean id="compositeDCCrosswalk"
class="org.orioai.repository.domain.logic.crosswalk.CompositeCrosswalk">
<constructor-arg>
<value>http://www.openarchives.org/OAI/2.0/oai_dc/</value>
</constructor-arg>
<constructor-arg>
<value>http://www.openarchives.org/OAI/2.0/oai_dc.xsd</value>
</constructor-arg>
<property name="outPrefix" value="oai_dc" />
<property name="crosswalks">
<list>
<ref bean="DCIdentityCrosswalk" />
<ref bean="LOMtoDCCrosswalk" />
</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.
Comme les autres Web Service, il est configurable dans le fichier repository-ws.xml, mais par défaut les valeurs importées depuis le fichier ori-oaicat.properties (décrit plus haut) suffisent au fonctionnement de base.
La configuration des ensembles proprement dite se situe dans le fichier conf/properties/repository-sets.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 :
...
Code Block |
---|
<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="xpathSources">
<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[starts-with(@language,'fr')],'CDD')]/lom:taxon/lom:id</value>
<value>//lom:classification/lom:taxonPath[starts-with(lom:source/lom:string[starts-with(@language,'en')],'DDC')]/lom:taxon/lom: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" value="//dc:dewey"/>
</bean>
</entry-->
</map>
</property>
</bean>
|
...
Niveau de déboggage
...
.Les niveaux disponibles sont : *debug*, *info*, *warn*, *error* et *fatal*, du plus prolixe au plus concis. Le niveau de déboggage influe sur les performances de l'application.
*Note* : Ce fichier est produit automatiquement lors de l'appel de la tâche ANT deploy, en fonction de ce qui est défini dans build.properties. Si vous désirez le changer à la main, ne pas oublier de préciser le chemin du fichier de log, par exemple :
...