2. Présentation de Notre Travail
6.2. Prototype
Nous décrirons tout d’abord la restriction par rapport au modèle du soutien théorique que nous avons proposé dans les deux chapitres précédents (CHAPITRE.4 et CHAPITRE.5) (paragraphe 6.2.2), puis nous présentons une description technique du prototype avec les modules que nous avons développés et ceux que nous avons réutilisés (paragraphe 6.2.2).
6.2.1. Parties Implémentées /Restriction du Modèle Théorique
L’hypothèse de la diversité des outils et des collections de recherche a des implications importantes sur l’implantation. En effet, il faut traiter deux aspects :
D’une part, en ce qui concerne le document, plus précisément :
- La disponibilité (ou l’accessibilité) : il est nécessaire que tous les utilisateurs puissent
visualiser et consulter les documents retrouvés par les autres.
- l’unité d’identification : il est indispensable de s’apercevoir que deux ou plusieurs
documents sont identiques même s’ils ont été retrouvés par des outils différents ou à partir de deux collections différentes. Donc, on impose à des documents identiques d’avoir le même identifiant.
D’autre part, en ce qui concerne la normalisation des requêtes et des documents. Les
requêtes et les documents de différents outils et collections de recherche doivent être rendus conformes à une norme unique pour tous, afin de garantir la persistance et l’intégrité de la mise en commun dans la mémoire collaborative et du traitement de ces requêtes et de ces documents.
Deux solutions sont possibles pour résoudre ces aspects :
- On maintient l’hypothèse de diversité des outils et des collections de recherche, et l’on suppose qu’on dispose de l’outil nécessaire qui garanti d’un coté, la disponibilité et l’unité d’identification des documents obtenus, et de l’autre coté, la représentation des requêtes et
des documents à l’aide d’une norme unique.
- On suppose que les utilisateurs travaillent sur le même type de système de recherche d’informations et sur les mêmes collections, alors on n’a aucun problème de normalisation.
Nous avons choisi la dernière solution plus simple à réaliser. Donc un seul moteur de recherche (« Google ») [Brin 1998] a été mis à la disposition des utilisateurs. Nous indiquons aux utilisateurs que le prototype interagit avec ce moteur de recherche, alors ils n’ont pas besoin d’apprendre une nouvelle syntaxe pour formuler la requête puisqu’ils sont déjà habitués à l’utiliser.
Nous avons réalisé un prototype, qui permet à l’utilisateur de participer simultanément à plusieurs sessions collaboratives et d’être soutenu de façon collaborative synchrone pour les
trois types de recherche du groupe (relâchée, coordonnée et jointe), nous avons implanté aussi
la présentation et la fusion de requêtes la présentation de résultats par rapport à la dimension
de temps dans la session courant et historique, et selon les critères de personnalisation
suivants : le jugement pour la valeur jugé-per, préférence, similarité de requêtes où nous
avons préféré décliner ce critère de similarité de requêtes en deux critères : celui de la similarité de requêtes (similarité de requêtes du point de vue du système), et celui de la similarité de résultats (similarité de requêtes du point de vue sémantique) et ceci pour les
deux valeurs similaire et dissimilaire. Cependant, dans l’état actuel du prototype, l’utilisateur
peut choisir le soutien selon les requêtes similaires dont les résultats sont différents ou les requêtes différentes dont les résultats sont similaires. Ces deux cas envisagés ne présentent pas souvent d’intérêt dans le contexte de l’expérimentation.
Le prototype permet de soumettre des requêtes en langue anglaise. Les requêtes sont considérées comme des ensembles de termes, nous ne prenons en compte ni la structure de la requête, ni sa représentation. Par exemple la requête qj sera considérée comme l’ensemble de termes Tqj, un traitement linguistique ou une sorte de lemmatisation a été appliquée sur les termes de requête, ainsi les termes ont été traités en supprimant les préfixes, suffixes selon les
règles dans le Tableau 1 de l’annexe B. Puisque nous considérons la requête comme un ensemble de termes, nous avons appliqué le modèle ensembliste et les opérations ensemblistes (intersection, disjonction, …) pour :
- calculer la similarité SimReq(qu, qj) du point de vue du système entre la requête qu de l’utilisateur u et une autre requête qj ainsi :
SimReq (qu, qj) = TTqquu∪∩TTqqjj
- fusionner les requêtes qj extraites dans QELtc en utilisant une disjonction entre leurs ensembles de termes Tqj :
Tqfusion = ∪qj ∈ QELtcTqj
L’évaluation de la requête par rapport au sujet de recherche est implantée (Eval-Etape = EvalPrec-Etape) tandis que son évaluation par rapport à la pertinence système EvalOrd-Etape n’a pas été implémentée.
Nous n’avons pas implanté la stratégie de soutien selon la typologie de l’utilisateur ainsi l’évaluation de l’efficacité de l’utilisateur est prise en terme de sa compétence dans le domaine c’est-à-dire la formule qui permet d’évaluer la session individuelle Eval-RII est celle
de l’évaluation par rapport au sujet de recherche (Eval-RII = EvalPrec-RII) et donc
l’évaluation par rapport à la pertinence système EvalOrd-RII n’a pas été implantée.
6.2.2. Implémentation Technique
Le système est maintenu sur un serveur de la machine mrim4. L’accès au système se fait au moyen d’une connexion Internet via un navigateur Web standard à l’adresse
http://mrim4:8080/CollaborativeResearch/html/Interface.html.
Nous avons implanté l’interface en utilisant (HTML), et le JSP (JavaServer Pages)
[Bergsten 2001] pour son contenu dynamique, le noyau en utilisant le langage orienté objet Java. Nous avons utilisé Eclipse (www.eclipse.org), un environnement de développement Java open-source et extensible, et la mémoire collaborative1 en utilisant la mémoire.
Un serveur Tomcat est utilisé pour gérer l’exécution de logiciel pour le compte de plusieurs utilisateurs. Le serveur Apache Tomcat, développé par le projet Apache Jakarta
(http://jakarta.apache.org), Tomcat est un serveur web totalement écrit en Java supportant la
spécification des servlets 2.2 et des JSP 1.1. pour l’utiliser, un environnement d’exécution Java doit être installé sur la machine. JSDK (Java Software Development Kit) pour windows
(http://java.sun.com/j2se).
Figure 6.3. Demande de soutien dans l’interface soutien.
Si nous prenons l’architecture système de la Figure 6.1. Nous avons réalisé la couche
interface d’accès avec ces trois groupes d’interface système, d’interface recherche et
d’interface soutien, la Figure 6.2 et la Figure 6.3 montrent des exemples de l’interface. En ce
qui concerne le noyau fonctionnel, nous avons développé l’unité système, et unité soutien, pour le traitement linguistique des requêtes ainsi que l’unité recherche qui interagit avec le
moteur de recherche google, nous avons réutilisé les composants techniques, développé par Bottraud [Bottraud 2003] dans le system AIRA (Adaptive Information Research Assistant).
Après cette explication sur l’architecture système et son implémentation, nous clarifions notre système avec l’exemple suivant.