La version 2 de Pleade n'est plus officiellement développée par Anaphore et AJLSM. Si des bogues bloquants sont constatés, ils pourront toutefois être corrigés.

Nous encourageons tous les utilisateurs de Pleade 2 à songer à une migration vers la version 3.

La version 3.1 est disponible depuis le 24 février 2009 sur SourceForge : > > Télécharger...

Voir le site de démonstration de Pleade 3 : > > Démonstration de Pleade 3

Plus d'information sur Pleade 3 : http://pleade.com/

La recherche documentaire

Un moteur de recherche doit nécessairement s'appuyer sur un modèle pour offrir ses différents services. La recherche documentaire dans PLEADE s'appuie entièrement sur la plate-forme SDX, sans en étendre les possibilités. Cette dernière possède ses propres caractéristiques, qui pourront évoluer, mais qui doivent être connues pour bien comprendre le fonctionnement de la recherche dans les documents EAD publiés avec PLEADE.

Pour décrire ce fonctionnement, nous allons présenter les trois modèles de base pour la recherche avec SDX et donc PLEADE :

  1. Un modèle de recherche : quel type de recherche permet le moteur, qu'est-ce qu'il retournera comme résultat ?

  2. Un modèle de documents à chercher : quels sont les documents que l'on peut indexer et chercher avec ces plates-formes ?

  3. Un modèle de requête : comment les utilisateurs peuvent exprimer leurs besoins de requêtes ?

1) Le modèle de recherche

Le modèle de recherche est purement conceptuel. Pour SDX, il repose sur certains concepts importants :

Unité de recherche

Une unité de recherche est un objet qui peut être retrouvé par SDX. Ainsi, dans une base de documents SDX où l'on retrouve deux unités de recherche, toute requête effectuée donnera nécessairement, 0, 1 ou 2 résultats. Ces unités de recherche sont définies au moment de l'indexation du document dans SDX et sont immuables par la suite.

La plupart du temps, une unité de recherche correspond à un document XML . Toutefois, il est tout à fait possible de fragmenter un document XML en plusieurs unités de recherche. Cependant, ces unités n'auront aucune relation particulière pour le moteur de recherche ; c'est un peu comme si elles provenaient de documents XML différents.

A noter que les unités de recherche sont également les unités d'affichage ou de présentation des documents dans SDX (mais pas nécessairement dans PLEADE).

Champs de recherche

Une unité de recherche est composée de plusieurs champs de recherche. Chaque champ a un nom et une valeur. Plusieurs champs peuvent porter le même nom dans une même unité de recherche ; on parlera alors d'un champ répétable ou à occurrences multiples. C'est pratique pour, par exemple, représenter les auteurs d'un ouvrage de manière indépendante.

Les champs peuvent être indexés par mots, et dans ce cas chaque mot est séparé et modifié (traditionnellement cela consiste à supprimer les accents et mettre les lettres en minuscules, mais cela peut être beaucoup plus complexe). Un champ peut également être indexé tel quel, on parle alors d'une indexation par champs. Dans un tel cas, pour retrouver une valeur, il faut utiliser la valeur complète du champ, pas seulement un mot.

A partir de ces unités de recherche qui contiennent des champs, il est possible d'effectuer des recherches. Les recherches portent toujours sur un ou plusieurs champs. En particulier, il n'existe pas de concept de champ plein texte dans SDX. Si on veut un champ qui inclut tout le texte d'une unité documentaire, il faut le créer et y mettre tout ce texte.

Il existe également un champ par défaut dans SDX ; très souvent, ce champ sera un champ de type plein texte. Cela permet de faire en sorte qu'une requête toute simple comme maison fasse ce que l'utilisateur attend : une recherche pour ce mot dans le texte intégral.

Une fois la recherche effectuée, SDX retourne des résultats de recherche. Ici, le développeur d'application a le choix entre deux grandes techniques pour présenter les résultats aux utilisateurs. La plupart du temps, SDX fournira un certain nombre de champs et leur valeur pour chaque unité documentaire. Les champs sont choisis dans la configuration de l'application. Cette méthode est tout à fait appropriée pour construire une liste brève de résultats de recherche.

La seconde technique consiste à retourner la source complète de l'unité documentaire, la plupart du temps le document XML qui a été indexé. Cette approche permet de répondre à des besoins plus complexes en matière de résultats de recherche.

Les résultats sont triés par défaut en ordre de pertinence probable, pertinence obtenue par un calcul statistique effectué avec des informations sur la base de documents et la requête. On peut toutefois demander à SDX de trier les résultats par n'importe quel champ de la base.

PLEADE ne fait rien de particulier par rapport à ce modèle de recherche. Toutefois, étant donné la nature des documents EAD, il est bien important d'en comprendre la nature. En effet, les documents EAD sont fortement hiérarchisés, et souvent très volumineux. C'est pourquoi PLEADE offre aux administrateurs de contenu la possibilité de fragmenter leurs documents pour créer de unités documentaires plus pertinentes. Ainsi, depuis un document EAD, on peut obtenir un grand nombre d'unités documentaires et donc de résultats de recherche.

Par ailleurs, cela signifie qu'on ne peut pas faire des requêtes du genre les unités de description archivistique qui se situent à l'intérieur d'une autre dont l'intitulé contient le mot maison et plus ancien de 1800, tout en ayant comme dans sa description de contenu le terme église. Ce type de requête, combinant contenu et structure, ne peut pas être exécuté de manière générale avec SDX, et donc PLEADE souffre de cette limite.

2) Le modèle de documents

Sans se tromper, un peut dire que le modèle de documents pour la recherche dans SDX est le modèle XML. En effet, tout document — valide ou bien formé — qui respecte la norme XML peut être indexé et par le fait même cherché avec SDX.

Toutefois, la réalité est un peu plus complexe. D'une part, les documents XML qui sont indexés par SDX peuvent être transformés préalablement à leur indexation. Cette transformation doit toujours donner un autre document XML, ce qui ne change pas fondamentalement le modèle, mais ce document XML peut être fort différent du document original, ce qui changera la manière de l'interroger. D'autre part, les données indexées par SDX ne sont pas directement reliées à leur emplacement dans le document XML qu'on lui fournit. SDX reçoit (depuis la transformation d'indexation sous le contrôle du développeur de l'application) une version transformée et surtout aplatie du document original, il ne reste plus que des champs et leur valeur, chaque champ pouvant être répété et dans un ordre quelconque. C'est pourquoi on peut considérer SDX comme un moteur de recherche pour documents XML, mais les documents XML sont aplatis pour correspondre au modèle de recherche présenté ci-dessus.

Dans le cas de PLEADE, la transformation d'indexation s'effectue en deux étapes. Dans un premier temps, le document XML est manipulé afin d'identifier un certain nombre d'informations (comme les coupures de documents, les cibles des liens hypertextes, etc.) qui seraient inefficaces de retrouver à une étape ultérieure du traitement, par exemple à l'affichage. L'avantage de les effectuer à ce moment est que le traitement ne s'effectue qu'une seule fois, c'est-à-dire lorsque le document est publié (et donc indexé par SDX). Cette première étape résulte en un document XML qui ne respecte plus l'EAD car on y a ajouté un certain nombre d'attributs, la plupart dans l'espace de noms pleade.

Ensuite, nous avons vu que le modèle de recherche de SDX repose sur la notion d'unités de recherche. Dans SDX, ces unités ne sont pas nécessairement un document XML au complet, elles peuvent être une partie de documents, car une transformation d'indexation, nécessairement appliquée sur un document, peut retourner plusieurs unités de recherche, accompagnées de leur source pour l'affichage. PLEADE utilise beaucoup cette capacité de SDX, car il permet de fragmenter les documents XML indexés en plusieurs unités de recherche, permettant à la fois de faire des recherches plus précises et de rendre l'affichage plus efficace car les parties affichées, qui correspondent à une unité documentaire, sont plus petites.

C'est la seconde étape de transformation d'indexation qui se charge de ce travail de fragmentation, en fonction des informations fournies lors de la publication par l'administrateur de contenus et préparées lors de la première étape de transformation. Les sources des fragments sont proches des parties du document EAD correspondant, avec les informations ajoutées par la première étape de transformation ainsi que des informations sur le contexte.

3) Le modèle de requête

Le modèle de requête supporté par SDX est un modèle booléen. Les requête sont une combinaison de critères, chaque critère étant spécifié sur un champ et étant relié aux autres par un opérateur booléen ET, OU ou SAUF.

Toutefois, il existe plusieurs méthodes pour représenter ces requêtes, des plus simples aux plus complexes. La plus directe est le langage de requête de Lucene qui est documenté sur le site de ce moteur de recherche. On y explique que des requêtes de type :

maison
+maison +église
+maison -église
maison AND église
+(maison église) +canada

sont tout à fait possible. Par ailleurs, un développeur d'applications SDX peut offrir toutes sortes de formulaires plus ou moins complexes pour représenter différemment ces équations de recherche booléennes.

Dans PLEADE, la recherche peut s'effectuer depuis toutes les pages à l'aide du langage illustré ci-dessus. Un administrateur de site peut définir plusieurs formulaires de recherche plus ou moins avancés, les offrir sur toutes les pages ou pour certains documents, voire certains groupes de documents, etc.


© 2003, 2004, 2005 PLEADE / AJLSM / Anaphore
Des questions ? Des remarques ? Utilisez les listes de discussions ! Vous voulez l'utiliser ? Vous pouvez le télécharger !