[sdx-developers] RE : Relations entre les documents

[Martin Sevigny]

Bonjour,

> Mmmh... d'après le code, ça va plus loin car il semble que l'on peut 
> *partager* des documents attachés. On n'efface donc que quand le 
> compteur de références passe à 0. J'en profite pour dire que c'est un 
> excellent concept :-)

Oui, en SDX 2. J'ai omis ce détail pour simplifier ma description, mais
le point demeure : c'est le seul usage que fait SDX de la relation entre
un document indexé et un document qui lui est attaché.

> > Ayant deux relations possibles, on peut se poser la 
> question : doit-on 
> > rendre le concept générique? C'est-à-dire permettre tout type de 
> > relation? On pourrait penser que je suis en faveur, puisque tout ou 
> > presque est générique dans SDX, mais là je suis contre... 
> > Principalement parce que ça cause un problème d'implantation.
> 
> Mmmh. Quel serait-il ? Il est possible que je manque de 
> recul, mais dans 
> l'état actuel des choses, l'utilisation du fameux troisième index 
> pourrait selon moi être rendue possible en une cinquantaine 
> de lignes... 
> et je suis volontaire pour les rédiger !

Je ne sais pas, cet après-midi je n'en voyais pas de simple sans
utiliser un SGBD (j'essaie de l'éviter pour des raisons de simplicité
d'installation), mais je ne sais pas si c'est le TGV qui m'inspire, mais
j'en vois peut-être une...

Tu penses à des entrées à des champs dans un objet Database avec des
champs idDocumentSource, idDocumentCible, typeRelation? Et à un
identifiant de la relation qui serait la concaténation du contenu de ces
trois champs? Pourquoi pas...

> Les exemples cités ne sont-ils pas des démonstrations de cet intérêt ?

Du caractère générique des relations? Non. J'ai manqué quelque chose?

> ID_DOCUMENT_ATTACHE:1
> ID_DOCUMENT_ATTACHE:2
> ID_DOCUMENT_ATTACHE:3
> 
> Ca fonctionne, tant qu'on n'a qu'un seul champ. Mais si je veux, par 
> exemple, stocker le repository (cf. autre thread) :
> 
> ID_DOCUMENT_ATTACHE:1
> ID_DOCUMENT_ATTACHE:2
> ID_DOCUMENT_ATTACHE:3
> REPOSITORY_DOCUMENT_ATTACHE:A
> REPOSITORY_DOCUMENT_ATTACHE:B
> REPOSITORY_DOCUMENT_ATTACHE:C
> 
> comment je fais la nécessaire relation A1, B2, C3 ?

Non, c'est sûr, ça ne se fait pas ainsi. Pour moi le repository est
stocké ailleurs, autre thread ou pas. Mais le principe demeure, tu ne
peux pas stocker des paires de valeurs de cette façon.

> Pour les documents fragmentés, tu as un point *en plus* qui me paraît 
> primordial : la relation d'ordre. 

Tu vois, après y avoir longtemps réfléchi (ces documents fragmentés me
torturent l'esprit depuis plusieurs mois!), cet ordre ne m'intéresse pas
(tellement). Parce que si on s'intéresse à l'ordre, on doit s'intéresser
à la hiérarchie, sinon c'est inutile... Le but de fragmenter les
documents est seulement de définir des unités documentaires plus petites
que le document XML. Ces unités documentaires servent principalement à
la recherche (c'est l'unité retournée par comme résultat) et,
accessoirement, pour l'affichage, essentiellement pour rendre le tout
plus efficace (parce que l'affichage pourrait se faire avec une XSLT sur
le document parent : si on est capable de fragmenté à l'indexation, on
est capable de le faire à l'affichage...).

Et en recherche, l'ordre ne nous intéresse pas. Ou si peu... Mais
peut-être que oui, je ne sais pas... Pour trier/regrouper? Ouais... Dans
ce cas il faut que l'ordre soit par rapport à son parent immédiat.

> Mais peut-être as-tu une idée sur ce point qui serait radicalement 
> différente de la mienne ? Je serais très heureux de me tromper sur ce 
> point : de plus, c'est la période ;-)

Je ne pense pas que ce soit très différent. Je pense qu'il y aura des
relations, pourquoi pas génériques. Que ces relations seront stockées
dans un lookupindex.

> J'ajoute que ça crée une grosse différence entre les entrées 
> de lookup 
> des documents indexés et les entrées de lookup des autres (documents 
> documents attachés et... document originaux qui, eux aussi, 
> pourraient 
> bénéficier des raltions), mais ça, c'est marginal.

En fait, de quoi a-t-on besoin? De deux lookup ?

1) Informations générales sur un document (quelconque)

Ces informations sont :

- l'entrepôt où il est stocké (tous les documents)
- le type de document (concept SDX, tous les documents)
- le mime type (documents binaires, mais pourquoi pas tous?)

Dans ce lookup, les clés sont les identifiants (nécessairement uniques
dans une base) des documents.

2) Relations

Les identifiants seraient la concaténation de trois unités d'information
: l'identifiant du document source de la relation, l'identifiant du
document cible de la relation et le type de relation (String quelconque
a priori, mais SDX en définirait certains).

Il y aurait un champ pour chacune de ces trois unités d'information, et
enfin un dernier champ pour un numéro d'ordre.

Est-ce suffisant?

A bientôt,

Martin Sévigny