Bonjour,
André Davignon a écrit :
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 :
...
<dc:identifier>http://172.16.30.11:8080/demonotix/oai/Catalogue/Catalogue-0000027</dc:identifier>
> <dc:identifier> doit donc être traité pour avoir l'URL publique du
> document dont on reçoit les méta-données...
Oui, c'est l'un des problèmes que je soulevais. A noter le delta avec :
<header>
<identifier>
sdx:172.16.30.11:8080:recherche/Catalogue/Catalogue-0000028
</identifier>
<datestamp>2008-08-01T12:57:41Z</datestamp>
</header>
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.
J'ai peur de ne pas disposer de cette marge de manoeuvre :-)
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,
Avec un pipeline, le problème est différent. On ne connait pas l'adresse
du serveur, le nom de l'appli... sauf à les coder en dur, ce que je
voudrais éviter.
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
A noter que Lucene, qui avait proprement "pompé" cette portion du code
de SDX semble venir d'en changer pour quelque chose, apparemment, de
plus performant.
Et puis...
> <dc:title>Emotion,rire, conviction : quatre ans de coopération
> franco-colombienne en bibliothèques</dc:title>
Quel monde merveilleux que celui des bibliothèques ;-)
A+
p.b.
_______________________________________________
sdx-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/sdx-users
