Re: [sdx-developers] RE : Relations entre les documents

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> 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é.

Ca pose le problème de la mise à jour du document. J'en ai déjà parlé... 
et c'est bien explicité dans ma LuceneDocumentBase :-)

> 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...

En gros, c'est ça. Mais je pense que l'identifiant de la relation n'est 
même pas utile, même s'il reste naturellement obligatoire. L'important 
est qu'il soit unique. J'en reparle de suite...

> > 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?

Tout dépend ce que tu entends par "générique". Dans mon esprit, il n'est 
pas question de laisser au développeur d'applis la possibilité de 
définir ses relations propres. Ou alors, à lui d'écrire des classes ad 
hoc car je pense que si relations il y a, il faut les hard-coder, leur 
sémantique étant irrémédiablement liée à la logique applucative de SDX. 
Ceci dit, le concept me semble assez générique au sens codage de SDX 
pour qu'on s'y implique :-)

> > 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.

On est d'accord.

> 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.

C'est à ça que je pensais...

> 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.

Si tu entends pas lookupIndex un objet (qui n'en est pas encore un au 
stade actuel de SDX) du stype des entrées de lookup, je suis d'accord.

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

En gros, oui. D'où le 3ème index...

> 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.

Oui !

> 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.

Oui ! Mais il manque encore un truc :-) J'en parle de suite...

> Est-ce suffisant?

Non, le truc qui manque, c'est la notion de sens. Bien que dans les 
faits, on  n'ait pas beaucoup de variabilité sur ce point.

Récapitulons : une relation c'est :

1) une id (quelconque à mon avis : on peut concaténer pour que ça soit 
lisible)
2) un document 1
3) un document 2
4) un type (document attaché, fragment et document original qu'on avait 
oublié)
5) un ordre (si pertinent)
6) un sens (qui définit le concept d'origine et de destination : 1vers2, 
2vers1, indifférent)

J'ajoute qu'il y a tout de même des contraintes :

1) un id unique (ça tombe sous le sens mais il est bon de le préciser 
pour la génération d'id)
2) (document 1 + document 2 + type) unique : on ne peut avoir, par 
exemple, 2 fois la même relation avec, par exemple, un ordre différent, 
ou des sens opposés.

Le 2ème index aurait donc 6 champs et ferait usage des BooleanQuery si, 
dans un premier temps, on s'attaque à Lucene. Je maintiens mon opinion 
sur la cinquantaine de lignes :

5 pour l'initialisation
20 pour la création
15 pour la destruction
15 pour le test de l'existence d'une relation (utilisé avant création, 
pour éviter de faire 2 fois la même et à fins de contrôle lors de la 
destruction des documents)

Et quelques lignes ajoutées sur add() et delete(), lignes que l'on 
pourra gagner dans la création de l'entrée de lookup.

Je te concède tout à fait volontiers que si l'on veut créer un autre 
type de relation, il faudra une bonne raison :-)

A bientôt.

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