Fiche

1. ORI-OAI Fiche Veille

2. ORI-OAI Installation Veille

3. ORI-OAI Installation Veille

4. ORI-OAI Description Veille • 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 : Sources: http://www.ori-oai.org

5. ORI-OAI Description Veille Sources: http://www.ori-oai.org

6. ORI-OAI Veille Intérêt pour l’UMVF 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.

7. ORI-OAI Veille Annexe Spécification d’une moulinette UMVF Cismef vers ORI-OAI

8. ORI-OAI Etude Veille 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.

9. ORI-OAI Etude Veille • 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 ....

10. ORI-OAI Etude Veille • 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.

11. ORI-OAI Etude Veille 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.

12. ORI-OAI Etude Veille 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).

13. ORI-OAI Etude Veille 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].

14. ORI-OAI Etude Veille • 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).