Re: [sdx-users] SDX 2.3 et entrepôt OAI

[André Davignon]

Bonjour,

> A propos de la configuration d'un entrepôt OAI en utilisant les
> <sdx:oai-field>, je sais que le projet "Notix" utilise correctement ce
> mécanisme avec 2.3 dans un premier temps et maintenant avec SDX 2.4.
> Si André Davignon passe sur la liste, il pourrait peut-être t'en dire
> plus...
>   

Oui, pour l'entrepôt OAI de Notix, j'ai bien utilisé les tags 
<sdx:oai-field> et cela fonctionne correctement avec SDX 2.3 et 2.4 :

http://portail.documentation.equipement.gouv.fr/demonotix/oai/Catalogue?verb=ListRecords&metadataPrefix=oai_dc

Seul problème dans mon cas, le <dc:identifier> est généré par SDX sur 
l'adresse du serveur, ce qui donne quelque chose comme ça :

- <#> <oai_dc:dc 
xmlns:oai_dc="*http://www.openarchives.org/OAI/2.0/oai_dc/*"; 
xmlns:dc="*http://purl.org/dc/elements/1.1/*"; 
xmlns:xsi="*http://www.w3.org/2001/XMLSchema-instance*"; 
xsi:schemaLocation="*http://www.openarchives.org/OAI/2.0/oai_dc/ 
http://www.openarchives.org/OAI/2.0/oai_dc.xsd*";>
     <dc:title>Emotion,rire, conviction : quatre ans de coopération 
franco-colombienne en bibliothèques</dc:title>
...
 
<dc:identifier>http://172.16.30.11:8080/demonotix/oai/Catalogue/Catalogue-0000027</dc:identifier>
</oai_dc:dc>

<dc:identifier> doit donc être traité pour avoir l'URL publique du 
document dont on reçoit les méta-données...

Pour éviter cela, il est possible de faire en sorte que pour toute 
servlet demandée sur un port (disons 8081), Tomcat répond avec une URL 
de base dont on peut définir le DNS, dans mon cas 
http://portail.documentation.equipement.gouv.fr. On a alors :

<dc:identifier>http://portail.documentation.equipement.gouv.fr/demonotix/oai/Catalogue/Catalogue-0000027</dc:identifier>

Il faut, dans server.xml de Tomcat, définir sur le port 8081 
(http://tomcat.apache.org/tomcat-5.5-doc/proxy-howto.html) :

<Connector port="8081" ...
             proxyName="portail.documentation.equipement.gouv.fr"
             proxyPort="80"/>



Ce problème ne se présente peut-être pas dans le cas de l'utilisation 
d'un pipeline SDX pour l'entrepôt OAI, mais je n'ai pas fait le test. En 
tous cas, il peut être contourné.

[moisson OAI] :

Tant qu'on y est ;-), un feature request, dont j'avais discuté avec 
Martin Sévigny, serait de permettre à SDX de moissonner sur appel d'un 
URL. Des modifications avaient été apportées à SDX 2.3 dans ce sens mais 
ne s'étaient pas avérées concluantes. Actuellement, à ma connaissance, 
la moisson ne peut être déclenchée qu'en fonction du paramétrage de 
application.xconf tandis que la moisson sur appel d'URL (de 
l'application SDX qui moissonne) peut s'avérer bien pratique.

> A propos du passage SDX 2.3 à 2.4 :
>   
...

> J'oublie peut-être certaines choses, mais voilà les plus importantes que
> j'ai en tête.
>   

Certains problèmes peuvent apparaître en raison du passage de Lucene 1.4 
à 2.2 (est-ce bien 2.2 ?), en raison de modifications d'API (je pense à  
la méthode luceneReader.getFieldNames), mais ce n'est pas _strictement_ 
lié à SDX. Plutôt à Lucene.

Mais j'ai aussi rencontré dans SDX 2.4 des différences de constructeurs 
de certains objets (peut-être dûs au changement de version de Lucene) :

fr.gouv.culture.sdx.search.lucene.analysis.filter.ISOLatin1AccentFilter
fr.gouv.culture.sdx.search.lucene.analysis.filter.FrenchStandardFilter

En dehors de cela, et surtout des précisions apportées par Malo Pichot, 
le passage à SDX 2.4 n'a pas été très difficile pour Notix, en dehors 
d'un patch pour Lucene (classe org.apache.lucene.index.term) qui ne 
fonctionnait plus. Encore un fois, c'est lié au changement de version de 
Lucene.

André Davignon