[sdx-users] Autres informations sur l'OAI

[Martin Sevigny]

Bonjour,

Pierrick a déjà bien répondu à la requête indirecte de Muriel
Foulonneau, et de plus j'ai donné des informations hors liste aussi à ce
sujet, mais j'ajoute quelques compléments. Je vous signale notamment
qu'en fin de message il y a des informations sur l'état d'avancement.

-----
SDX users est trop lourde pour moi je me suis désabonnée. Ce que
j'aimerais
savoir c'est ce que ça représente sur application qui tourne d'avoir à
changer la version de SDX pour mettre en place l'OAI et si ce que
prépare
Martin pour le repository OAI sera paramétrable ou s'il faudra des
développements.
-----

Première chose, "Martin" ne prépare rien ;-) Ensuite, l'idée derrière
l'ajout de toute fonctionnalité, c'est justement de ne pas obliger les
utilisateurs à faire le développement eux-mêmes, donc bien sûr ce sera
du paramétrage, pas du développement.

Maintenant, la grande crainte de Muriel (et peut-être d'une majorité ou
minorité silencieuse), c'est que les fonctionnalités OAI soient
complètement intégrées à SDX plutôt que diffusées sous la forme d'un
module (ou une idée du genre). A ce sujet, j'aimerais apporter quelques
commentaires.

Sur l'idée de "modules SDX", pour l'instant l'idée n'a jamais été
étudiée, les fonctionnalités ont toujours fait partie d'une distribution
complète. Donc on n'était parti sur la même idée pour l'OAI dans la
version 2.2 de SDX. Suite à cette demande (légitime), nous avons vérifié
ce qu'impliquerait une mise à jour "uniquement" OAI pour SDX 2.1, et
voici ce que nous avons identifié jusqu'à maintenant:

- mettre à jour sdx/WEB-INF/lib/sdx*.jar
- mettre à jour sdx/WEB-INF/cocoon.xconf (ajout de la déclaration d'un
module)
- mettre à jour sdx/sitemap.xmap
- ajouter le dossier sdx/sdx/oai (il est nouveau)
- ajouter sdx/admin/oai (le nom pourrait changer, il s'agit d'une
interface d'administration tout à fait optionnelle mais tout de même
cool ;-) )

Pas besoin de réindexer, à condition d'accepter une chose : une
différence d'une à deux heures dans les dates de modification des
données, parce qu'avec l'OAI SDX passe au temps UTC, alors qu'auparavant
c'était le temps local. Mais en général, 2 heures dans une base
documentaire, ce n'est pas critique ;-)

Donc je pense que ça peut se gérer sans trop de craintes...

Le moissonneur OAI intégré à SDX sera défini de manière assez générale.
Ce sera essentiellement une interface Java qui aura comme principale
fonction de retourner un flux SAX (API standard pour traitement XML en
flux) à partir d'informations de moissonnage : entrepôt à moissonner,
action à effectuer, paramètres associés aux actions (dates, sets, etc.).

Cette interface aura deux implémentations concrètes dans un premier
temps. Une première sera une implémentation "Base de documents SDX /
Lucene", qui permettra donc d'indexer les données recueillies dans une
base de documents. C'est ce qui sera utilisé le plus souvent. La seconde
sera une implémentation assez générique, qui ne fera que passer le flux
SAX à ce qu'on va lui donner comme récepteur. Ce sera utilisé par
exemple par l'interface d'administration pour montrer les résultats
d'une "requête" OAI, pour tester par exemple. Je pense aussi à une
troisième, qui prendrait le flux et stockerait les résultats dans un
fichier quelconque, ou une collection de fichiers, si ça peut en amuser
certains.

La question des repository est plus intimement liée à SDX, c'est normal,
le rôle d'un entrepôt OAI est d'envoyer du XML comme réponse à une
requête HTTP. SDX fait déjà cela (l'API URL est très très semblable à
l'OAI dans son idée générale), il le fera maintenant dans un contexte
OAI.

Pour faire cela, on a évidemment besoin de savoir quelles données
envoyées, et pour cela on a besoin d'un modèle de données et d'un modèle
de gestion de ces données. Peu importe les outils utilisés pour servir
d'entrepôt, ils seront nécessairement fortement liés à ces modèles
sous-jacents, que ceux soient génériques ou spécifiques. Donc ici,
l'intérêt était d'avoir des outils _liés_ à SDX, alors c'est normal
qu'ils le soient.

Par contre, on a essayé de faire en sorte que ces critères soient
respectés:

- si on ne s'intéresse pas à l'OAI, on a rien à faire, on n'expose pas
nos données en OAI
- si on a déjà une structure de champs SDX proches de l'OAI-Dublin Core,
il faut que ce soit très facile d'être un entrepôt OAI
- si on a une structure de champs SDX loin de l'OAI-Dublin Core, il faut
que ce soit possible d'être un entrepôt OAI
- si on en a envie, on peut envoyer des formats (XML) autre que le
OAI-DC, produits à partir des documents qu'on a géré
- si on le veut, on peut définir simplement des sets à partir des champs
SDX

Il est certain que si on n'a pas de base de documents SDX (donc
d'application SDX 2.x), il n'y a absolument aucun intérêt à utiliser le
"module" entrepôt OAI de SDX. Tout comme si on n'a pas de base de
données MySQL, il n'y a strictement aucun intérêt à utiliser un entrepôt
OAI qui fonctionne avec MySQL, tout comme si on n'a pas de fichiers dans
un format X, on n'a aucun intérêt à utiliser un entrepôt OAI qui
fonctionne sur des fichiers en format X, tout comme...

Comme plusieurs le savent, le support de l'OAI est l'élément majeur de
la future version 2.2 de SDX. Aujourd'hui, sauf erreurs à corriger,
toute la partie obligatoire du protocole est supportée, ainsi que
certaines parties optionnelles, les autres sont en cours de
développement, mais c'est presque terminé.

Il restera à faire ceci:

- tester, tester, tester, ...
- faire le module d'administration
- écrire la documentation

Ça ne devrait pas tarder, notamment pour les tests que nous devons faire
de toutes façons dans le cadre d'un projet. J'aurais envie de dire qu'on
aura une version finale 2.2 de SDX au courant du mois d'août.

Concernant l'interface d'administration, on avait prévu ce genre de
choses:

* Pour toute base de documents qui s'expose en OAI
  - voir les "logs" des requêtes gérées, vider ce log
  - vider les informations de gestion que SDX doit conserver pour gérer
les "deleted records"

* Pour toute base de documents qui veut être alimentée par un
moissonneur OAI
  - voir les "logs" des moissons effectuées, vider ce log
  - démarrer une moisson, avec des paramètres spécifiques
  - démarrer une moisson telle qu'elle fut paramétrée dans le
application.xconf
  - faire ces moissons en réels (indexation des notices) ou en test
(affichage des résultats ou stockage dans des fichiers)

* Pour tous les administrateurs:
  - faire des moissons pour des test (affichage des résultats ou
stockage dans des fichiers)

On pensera sûrement à d'autres...

Merci à ceux qui se sont rendus jusqu'ici et à bientôt,

Martin Sévigny