Re: [sdx-developers] SDX 2.0?

[Pierrick Brihaye]

Salut,

Frédéric Glorieux a écrit:

> Je proposerais
>
> <sdx:query class="lucene..." name="complex" parameters="or"
> string="(+sdxall:1 +a*)">
> ...
> </query>
>
> L'idée c'est que la chaîne string donne les résultats présentés dessous
> (avec la classe précisée). Je ne pratique plus beaucoup SQL mais je crois me
> souvenir qu'on peut bien lui demander ça aussi.
En fait... je n'aime pas trop. Je préfère *réellement* <sdx:luceneQuery 
/> car tu postules que le format de l'élément (notamment l'attribut 
"string") pourra répondre à tous les besoins.
Je peux d'ores et déjà dire que ce ne sera pas le cas pour moi et qu'une 
représentation *XML* de cette "string" devrait être possible... ce qui 
la rend incompatible avec un mapping sur un attribut.
> | Je préfèrerais :
> | <sdx:result no="3">
> |   <luceneScore>0.107960686</luceneScore>
> |   <lucenePctScore>83</lucenePctScore>
> Surtout, ne pas changer les noms d'éléments. Il me semble que score est une
> info valable pour tout résultat.
Mmmh. Quelle est la notion de "score" lors d'une requête SQL ? X-Path ?

> Pour des pertinences booléennes (SQL),
> et bien ce sera 100%, pas de problème.
Tu as répondu à la question... :-)

> | Ensuite, on aurait <sdx:luceneField /> en lieu et place de <sdx:field>.
>
> Là je ne suis pas d'accord, cela dépend comment on implante d'autres
> chercheurs. On peut très bien dire qu'un résultat est une ligne d'une table,
> que les champs sélectionnés en sont les cases. Cela fait partie de la
> définition même d'une base SDX.
Bon, je crois que je vais être obligé de développer avant février :-)

Voilà :

Lucene, c'est la la BD (champ / valeur), de dimension 2... ou plutôt 2,5 
car les champs peuvent être multivalués. On le voit bien dans le XML 
suivant :
<sdx:document id="X">
  <sdx:field name="field1">value1</sdx:field>
  <sdx:field name="field2">value2</sdx:field>
  <sdx:field name="field2">value3</sdx:field>
</sdx:document>

Je n'ai rien contre cette approche car 97 ou 98% des requêtes que je 
formule chaque jour (essentiellement sous Google) se satisfont de cette 
fonctionnalité.
Ce que je voudrais *en plus*, c'est du XML de dimension 3... ou plutôt 
3,5 car les éléments peuvent être aussi multivalués. En fait, c'est du 
3,49 car les attributs ne peuvent pas l'être :-)
Voici le type *d'index* que je voudrais traiter :

<sdx:document id="X">
  <sdx:index semantics="title">How to Make an A-Bomb</sdx:index>
  <sdx:indexGroup semantics="author">
    <sdx:index semantics="firstname">Albert</sdx:index>
    <sdx:index semantics="lastname">Einstein</sdx:index>
  </sdx:indexGroup>
  <sdx:indexGroup semantics="author">
    <sdx:index semantics="firstname">Werner</sdx:index>
    <sdx:indexGroup semantics="composedlastname">
      <sdx:index semantics="prefix">von</sdx:index>
      <sdx:index semantics="lastname">Braun</sdx:index>
    </sdx:indexGroup>
  </sdx:indexGroup>
</sdx:document>

... ce qui me permettrait d'avoir un niveau de granularité assez 
costaud... qui me paraît incompatbile avec la notion de "champ".
En l'état actuel des mes recherches, je vois bien eXist gérer ça et on 
peut espérer qu'il sera parvenu à un degré de maturité suffisant dans 
quelques mois, lorsqu'il s'agira d'implémenter cette fonctionnalité.
Je n'en dit pas plus pour le moment : ça pourrait avoir une puissance 
phénoménale qui, hormis les problèmes mentionnés, serait complètement 
accessible depuis SDX... et à peu de frais encore !
> | Corollaire, la notion de tri, telle qu'actuellement disponible est
> également
> | très dépendante de Lucene et est peut-être à intégrer dans
> | <sdx:luceneQuery/>
>
> Les méthodes peut-être, mais pas la logique. Il me semble bien que l'on
> puisse superposer des clés de tris, en SQL, comme en sortie XSL d'un DB XML.
A voir...

> Tout le problème sera de définir les contrats Results ou Query.
On est bien d'accord :-)

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden