Statut Logiciel libre Communauté
d’utilisateurs Importante communauté d’utilisateurs francophones (France Euro Méditerranée).
Logiciel inter-UNT francophone développé par UNIT.
Nature Outil de référencement et d'indexation en réseaux de portails compatibles OAI-PMH
Caractéristiques
fonctionnelles Recherche simple avancée et thématique sur les metadonnées recherche sur texte intégral
Référencement collaboratif des documents
Gestion des différents formats de metadonnées (LOM-fr, Dublin Core, …) Archivage du document natif des auteurs
Gestion de version
Ouverture sur les réseaux avec échange de metadonnées via le protocole OAI/PMH
Caractéristiques
techniques Développement en Java/J2e Environnement Linux
Url www.ori-oai.org
Url de téléchargement http://www.ori-oai.org/telechargements.html
Fiche
Veille ORI-OAI
Installation de version définitive UMVF
Niveau installateur Ingénieur
Temps d’installation Pour la version professionnelle (non démo) 1 journée d’installation
4 jours de configuration
Temps de paramétrage Très variable en fonction des ambitions du site.
De quelques jours dans un usage « par défaut » à quelques semaines.
Logiciel complémentaire Script en langage Ruby pour l’UMVF : moulinette qui transforme les notices de Cismef Rouen en notices acceptées par le logiciel ORI-OAI pour avoir une chaîne complère.
10 jours
Rédaction 1 jour
Installation
Veille ORI-OAI
Pré-requis
ORI-OAI est consitué d'un ensemble d'applications J2EE, ce sont les modules ORI-OAI. Ces modules fonctionnent sur un conteneur de servlet J2EE. Le conteneur de servlet J2EE conseillé (car utilisé en développement et en production par les établissements développeurs/testeurs) est le serveur web Tomcat -Jakarta.
On conseille l'utilisation de Java 5 et de Tomcat 5.5 . On conseille l'installation d'un serveur Tomcat par module pour plus de confort (même si on peut faire tourner tous les modules sur un seul serveur Tomcat) : les différents modules s'inter-connectent entre eux via WebService.
On conseille l'utilisation d'un environnement Linux (à un environnement Windows) même si on peut aussi
envisager de faire tourner ces applications sur d'autres environnements non testés pour le moment (Mac Os par exemple).
Dans le cadre de l'installation de tous les modules sur une seule machine, 4Go de RAM sont recommandés, 8Go est cependant certainement idéal : certains modules requièrent en effet un volume important de Mémoire Vive pour fonctionner au mieux (c'est le cas de l'éditeur de métadonnées).
Enfin, certains modules d'ORI-OAI s'appuient sur un serveur SQL (MySQL est recommandé - la base doit
supporter les transactions, le storage InnoDB de MySQL est à utiliser), un serveur XML (base de données eXist) et un LDAP (testé avec OpenLdap, mais tout serveur répondant au protocole LDAP est censé convenir).
Sources: http://www.ori-oai.org
Installation
Veille ORI-OAI
ORI-OAI se décompose en 7 modules :
• ORI-OAI-workflow pour la gestion des documents locaux
•
• ORI-OAI-harvesting pour la moisson d'autres entrepôts via le protocole OAI-PMH
•
• ORI-OAI-indexing pour l'indexation des ressources
•
• ORI-OAI-search pour la recherche de documents locaux et distants
•
• ORI-OAI-vocabulary qui gère les différentes classifications et vocabulaires
•
• ORI-OAI-repository pour exposer les fiches de métadonnées via le protocole OAI-PMH
• • ESUP-serveur-WebDAV développé dans le cadre de ESUP Portail, et proposé comme système de stockage de documents dans ORI-OAI
L'architecture du système ORI-OAI dans sa version 1.0 est présentée sur la diapositive suivante :
Description
Veille ORI-OAI
Sources: http://www.ori-oai.org
Sources: http://www.ori-oai.org
Description
Veille ORI-OAI
Intérêt pour l’UMVF
Veille ORI-OAI
L’UMVF se doit de faire évoluer son indexation suivant la logique internationale.
Elle doit utiliser le logiciel commun des UNT développé par UNIT (ORI-OAI).
Par ailleurs, dans le cadre du projet Mère-enfant, le Ministère des Affaires Etrangères nous a demandé que la banque de données centrale multimedia des DU soit indexée ORI-OAI.
Pour pouvoir utiliser ce logiciel, il fallait développer un module complémentaire qui
transforme les standards actuels d’indexation de l’UMVF, de Cismef et de Rennes, en
standard acceptable par le logiciel ORI-OAI; ceci, pour avoir un workflow complet.
Veille ORI-OAI
Annexe
Spécification d’une moulinette UMVF Cismef vers ORI-OAI
Etude
Veille ORI-OAI
Notices CISMEF -> LOM -> ORI-OAI
Cette étude porte sur l'exportation des fiches CISMEF en fiches LOM puis à leur intégration dans un ORI-OAI de Démonstration.
1. LOM / LOMFR / SUPLOMFR / ...
Le format LOM est utilisé car pour chacun des autres formats, le schéma XML n'existe actuellement pas.
Ce qu'il faut en retenir, c'est que d'un point de vue technique, faire du LOMFR / SUPLOMFR n'est à ce jour pas possible, le passage de LOM en LOMFR / SUPLOMFR ne sera qu'une
question technique de très faible ampleur, n'aura aucun effet (ou quasiment) pour l'étude faite ici.
2. Export en LOM des fiches CISMEF
Afin d'automatiser ensuite le processus, il est important de réaliser en premier lieu une transformation manuelle d'une notice CISMEF type en une notice LOM : c'est durant cette phase que l'on définit une correspondance entre le format donné par CISMEF et le LOM. La difficulté étant de choisir une correspondance qui respecte au mieux les recommandations LOM tout en perdant le moins d'informations possible par rapport aux fiches CISMEF initiales.
C'est l'exposition en format RDF (intégré dans le HTML) des fiches CISMEF qui permet ensuite
d'automatiser le procédé facilement.
Veille ORI-OAI
2.1. Conception (manuelle) d'un export de test : Fiche de test.
Il est important dès cette première phase d'exploiter les informations données au niveau de l'export RDF (et non pas au niveau du HTML).
Vous pouvez retrouver les fichiers utilisés/créés durant cette première phase dans le répertoire cismef_fiche_test. (zip en téléchargement)
La fiche 022258.html a été récupéré directement depuis cette url http://doccismef.chu- rouen.fr/html/nl/22/022258.html.
On en a retiré la partie RDF pour concevoir le fichier XML 022258_rdf.xml (simple coupé/collé).
Le fichier 022258_lom.xml a ensuite été réalisée manuellement.
Quelques notes pour cet export de 022258_rdf.xml en 022258_lom.xml :
• Après un premier jet, les correspondances ont été affinées en regardant l'échantillon des 10 fiches mis à disposition (cf le fichier cismef_listing.txt).
• La description donnée en RDF peut parfois ressembler à un ensemble de mots-clés (séparés par des virgules), c'est le cas de 022258_rdf.xml mais sur d'autres fiches, on récupère véritablement un texte descriptif. Donc on a logiquement préféré l'utilisation de la balise lom:description à la balise lom:keyword.
• Les mots-clés (subject) RDF correspondent à des mots-clés contrôlés issus d'un thésaurus spécifique (MESH/F- MESH). Ils ont ainsi toute leur place dans la partie classification du lom (avec l'objectif renseigné à discipline).
• Dans lom:keyword on a choisi de placer le CISMeFType
• Quelques éléments (très peu) n'ont pas été repris (pas de correspondance en LOM, pourrait figurer dans un schéma spécifique UMVF/CISMEF étendant le LOM (?)). C'est le cas, de cismef:Parrain, cismef:Departement, cismef:Pays. On pourrait aussi les ajouter à la description ....
Etude
Veille ORI-OAI
2.2. Moulinette/Script pour automatiser l'export vers LOM.
On a choisi le langage Ruby pour programmer le script d'export. Ce script, en Ruby, a l'avantage d'être simple à comprendre, concis, donc facile à reprendre, à étendre, etc. Multi-plateforme, le script peut tourner sous windows, mac-os, linux.
On peut subdiviser le script en 5 parties.
La première partie, outre la déclaration des librairies requises, définit des variables
constantes permettant d'établir une correspondance entre les vocabulaires RDF et ceux issus du LOM. Cette correspondance ne peut se faire (a priori, en tout cas par rapport aux éléments que l'on a) que de manière empirique. Aussi lors d'une exportation d'un ensemble autre que
l'échantillon actuel, il sera très certainement nécessaire de compléter les différents mapping (c'est à dire déclarer les correspondances manquantes entre les vocabulaires) (1).
(1) Le script signale en sortie standard par ce type de message :
### WARN: Map_formats doesn't know : zip
le fait qu'il manque une correspondance (dans ce cas la, il faut définir la correspondance de zip à application/zip [cf RFC2048, cf le document IEEE spécifiant la LOM]
La partie get_cismef_html lit le fichier cismef_listing.txt, récupère les fichiers ainsi listés via une requête HTTP pour les placer dans le répertoire cismef_html. Une conversion est nécessaire de l'encodage ISO-8859-1 vers l'encodage UTF-8 : d'une manière générale, UTF-8 est fortement conseillé notamment dans une optique d'échange, de partage de fichiers XML.
Etude
Veille ORI-OAI
La partie extract_cismef_rdf extrait simplement la partie RDF du fichier HTML pour les placer dans le répertoire cismef_rdf. On notera pour simple information que l'on a du
cependant modifier le préfixe d'un espace de noms, pour une raison X ou Y l'utilisation de value en tant que préfixe pose un problème au parser Ruby ReXML. On a simplement remplacé le préfixe value par val (ce qui n'a aucune conséquence).
La partie convert_rdf_lom est la partie la plus importante : c'est ici que l'on transforme les fichiers RDF en fichiers LOM. C'est donc ici que l'on peut affiner, faire évoluer la
correspondance RDF->LOM si on le souhaite. On notera que l'on procède en fait en
« remplissant » le fichier cismef_lom_template.xml que l'on utilise comme patron de conception pour les fichiers LOM (il peut ainsi permettre de positionner des valeurs génériques pour toutes les fiches LOM produites). Les fichiers LOM ainsi produits sont stockés dans le répertoire cismef_lom.
Enfin la dernière partie constitue la fonction principale. C'est elle qui est appelée lorsqu'on lance le script : 'ruby cismef_export.rb'. Elle appelle simplement séquentiellement les 3 fonctions ci-avant. Les 3 fonctions données avant stockant leurs résultats directement dans des répertoires spécifiques, une fois récupérés tous les fichiers RDF, et pour affiner, modifier la correspondance RDF->LOM en fonction des fichiers importés on peut par
exemple commenter l'appel aux 2 premières fonctions pour lancer uniquement l'export RDF->LOM.
Etude
Veille ORI-OAI
Notes : les classifications MESH/F-MESH sont à améliorer : on n'a pas pu correctement programmer la correspondance entre les termes MESH et F-MESH. En effet dans les RDF de Cismef, nous n'avons pas l'information de corrélation entre les termes MESH/F-MESH : ces termes sont donnés dans 2 blocs séparés et sont triés par ordre alphabétique (les correspondances anglais/français ne sont ainsi pas dans le même ordre).
Pour y remédier, le plus simple serait de faire en sorte que dans les fiches RDF de Cismef, l'ordre des éléments français/anglais coïncident, ce qui devrait résoudre directement ce problème (le script d'export devrait normalement ne pas être modifié pour autant).
Etude
Veille ORI-OAI
1.3. Validation des fiches LOM
Il est possible de valider les fichiers LOM via le schéma XML LOM. Les fichiers LOM doivent nécessairement être valides par rapport au schéma XML LOM pour qu'ils puissent être considérés comme respectant la LOM (ce n'est cependant pas une condition suffisante : le format VCARD n'est par exemple pas vérifié ...).
Pour valider un fichier LOM on peut simplement utiliser la librairie Xerces (librairie Java).
Dans le dossier validate_xml, on fournit une distribution de Xerces avec une ligne de commande (verif.sh) : depuis ce répertoire validate_xml, on peut appeler
./verif.sh $1
ou directement la ligne
java -classpath xerces-2_9_0/xercesImpl.jar:xerces-2_9_0/xercesSamples.jar:xerces-2_9_0/xml-apis.jar dom.Counter -s -n -v -f $1
où $1 est le fichier à valider.
Si l'on souhaite valider tous les fichiers du répertoire en une seule commande sous linux, on pourra ainsi lancer depuis validate_xml quelque chose du type :
find cismef_lom -name "*.xml" -exec ./verif.sh {} \; -print
Notez que le schéma est alors récupéré depuis le schemaLocation (connection web) donné dans chaque fiche XML LOM, pour chaque fichier ce qui peut prendre du temps. On peut accélérer le processus en changeant (temporairement) le schemaLocation des fiches pour le positionner sur une copie du schéma LOM en local.
[notez que pour les 10 fiches de l'échantillon ainsi exportées, on s'est bien sûr assuré qu'elles passaient au validateur].
Etude
Veille ORI-OAI
3. Démonstrateur ORI-OAI
On rappelle que les différents modules ORI-OAI sont libres et open-sources. C'est également le cas pour le code qui permet de construire le démonstrateur ORI-OAI lui-même (accessible librement via l'entrepôt subversion) http://sourcesup.cru.fr/projects/ori-oai-commons/
Par rapport au démonstrateur standard, on a :
• modifié les logos
• modifié les configurations des modules ori-oai-indexing et ori-oai-search pour prendre en compte la discipline de type MESH/F-MESH, ainsi que le module vocabulaire pour qu'il fournisse via le module ori-oai-indexing un vocabulaire simple des termes MESH/F-MESH
• fait en sorte d'initialiser le module ori-oai-workflow avec les fiches de l'export de notre échantillon (petite manipulation non triviale pour intégrer cela dans le démonstrateur, dans une installation standard l'appel de la target ant importmetadatas est plus directe).
• publié ces fiches pour qu'elles soient connues du moteur d'indexation
Notes : Les configurations faites ici seraient à améliorer pour une installation et une mise en exploitation : il faudrait notamment construire un fichier de vocabulaires présentant les termes MESH/F-MESH cela afin de :
• proposer une navigation thématique plus ergonomique dans l'interface de recherche
• proposer des sets oai-pmh en relation avec cette classification
• proposer une aide à la saisie dans l'éditeur de métadonnées.
De plus en terme de classification, les différentes UNT ont pris l'option d'utiliser la classification dewey comme classification pivot, il serait ainsi intéressant de renseigner cela dans les fiches LOM. D'une manière générale, les fiches LOM sont certainement à compléter au moins en partie afin d'exploiter au mieux le LOM.
On notera enfin que actuellement, le module ori-oai-workflow est difficilement maniable si un utilisateur doit gérer seul un nombre très important de ressources (par exemple 6000 fiches) ... ce n'est sans doute pas bloquant mais le module ori-oai-workflow devrait cependant évoluer pour améliorer cela rapidement (cf les tickets du module ori-oai-workflow sur la plateforme sourcesup.cru.fr).
