sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-developers] RE : [sdx-developers] RE : Métadonnées systèmes


From: Martin Sévigny
Subject: [sdx-developers] RE : [sdx-developers] RE : Métadonnées systèmes
Date: Wed, 12 Jun 2002 14:40:19 +0200

Salut,

> Pour les champs/index, on peut postuler que le format actuellement
> défini est le coeur même de SDX, non ? Ca devrait donc se mapper sur
> Lucene ou sur n'importe quoi d'autre. Mais bon, si tu pouvais préciser
> ta pensée...

Si on postule que ce format est le cœur de SDX, alors nous n'avons pas
besoin d'autre moteur de recherche que Lucene car celui-ci le fait très
bien.

Supposons que nous avons une collection de documents textuels qui ont
des équations mathématiques en MathML ou des partitions musicales en
MusicML. Le fonctionnement actuel de SDX est totalement adapté à la
partie textuelle, mais si on a un besoin de recherche du style "les
documents qui ont des bouts en ré mineur en 3/4", alors on n'y arrivera
pas avec une indexation a priori.

Si on a une base de documents de type Lucene pour la partie textuelle,
avec un entrepôt XMLDB pour stocker les documents XML, alors ça va pour
le textuel.

Si on définit aussi une base de documents XMLDB avec le _même_ entrepôt
de documents (ce sera possible bientôt!) et qu'on fait des recherches
Xpath dessus, on pourra répondre aux requêtes sur la structure.

Dans un entrepôt XMLDB, les champs n'existent pas (toute la structure
XML est disponible en requêtes) et les index sont des index à la SQL :
de simples améliorations de performance. Donc je ne crois pas que la
définition des index XMLDB soit similaire à la définition des champs
Lucene.

> Pour l'ajout ou la suppression, c'est moi qui semble être aveugle. En
> quoi est-ce différent ? Idem pour les documents attachés.

Suppression, peut-être pas, mais ajout oui : dans une base de documents
XMLDB, pourquoi transformer le XML pour faire sortir des champs? Donc
plus simple, et sûrement différent. Pour documents attachés peut-être
que ce serait équivalent.

> Et pour les résultats, il semble que je sois encore 
> aveugle... Pourqoi 
> ne serait-on plus en linéaire ?

Ca pourrait l'être ou pas. En XMLQuery, j'espère que l'on pourra avoir
comme résultat un document XML qui reprend, par exemple, la hiérarchie
de ce qu'il a trouvé. Par exemple, si tu fais une recherche (dans un
grand document de type DocBook) telle que "//section[title[contains(.,
'test')]], ça pourrait être intéressant d'avoir comme résultat :

<section>
  <section>
    <section>
      <title>dsqkljsd test</title>
    </>
    <section>
      <section>
        <title>dqsljkd test ljksfd</title>
      </section>
    </section>
  </section>
</section>

De plus, en Xpath/Xquery, la notion d'unité documentaire (fondamentale
en SDX) n'a pas le même sens, toute partie de tout document XML ou de
collections de documents XML devient une unité documentaire potentielle.
Ca peut rester linéaire, mais je n'ose pas affirmer sans réflexion si ça
reste équivalent à ce qu'on a actuellement.

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]