FR2832236A1 - Interface graphique de portail web semantique - Google Patents

Abstract

Un système informatique, pour générer une interface graphique de portail web, comprend un gestionnaire de requêtes (GR), destiné à travailler avec un gestionnaire d'historique (GH) et un générateur graphique (GG) pour afficher des entités en fonction de données stockées dans une base de données. Le gestionnaire de requêtes (GR) réagit au fait qu'une entité affichée est " pointée " par l'utilisateur, en exécutant sur la base de données une requête interne, définie à partir d'une expression de requête choisie, en fonction du type de l'entité, et complétée d'après l'entité. Ceci fournit de nouvelles données, à partir desquelles l'affichage est modifié. Le gestionnaire d'historique (GH) interagit pas à pas avec ce gestionnaire de requêtes (OR), pour construire une requête utilisateur à partir de sélections successives relatives aux entités pointées par l'utilisateur sur l'interface graphique. Le générateur graphique (GG) affiche alors une représentation adaptée des résultats produits par le gestionnaire de requêtes, selon un format prédéterminé.

Description

<Desc/Clms Page number 1>

Interface graphique de portail Web Sémantique
L'invention concerne l'interrogation d'une base de données.

L'interrogation peut se faire par un"portail", qui se présente sous la forme d'une interface graphique en relation avec une base de données, dont les données sont accessibles via un langage de requête. Un portail sur le"web" (ou"toile") est accessible sur un serveur web public ou privé, et offre à ses utilisateurs diverses possibilités de recherche et d'exploration d'un espace d'informations composé de collections de ressources (terme notamment défini par le groupe de travail développant les nouveaux standards pour Internet, l'IETF,"Internet Engineering Task Force"). Les ressources sont des entités contenant des données, telles que, par exemple, un répertoire, un document numérique ou un ensemble de données extraites d'une base de données, qui ont un identificateur URI ("Universal Resource Identifier") unique et auxquelles on peut accéder à l'aide d'un protocole de communication.

Un système d'information distribué de type web offre donc l'accès à des ressources de formats variés. Les ressources sont organisées dans des hiérarchies de répertoires situés sur des serveurs, dont le nombre et l'implantation varient largement selon le cas. Des applications clientes de ces serveurs permettent à des utilisateurs d'explorer le contenu des répertoires et de visualiser les données. Serveurs et applications clientes communiquent à l'aide de protocoles dont les plus usités sont le protocole de transfert hypertextuel HTTP ("HyperText Transfer Protocol") et le protocole de transport de fichier FTP ("File Transport Protocol"). Un web peut-être public, comme l'est la toile mondiale dite"World Wide Web" ou privé, comme l'est un réseau d'entreprise dit"intranet".

On utilise parfois l'expression de"web sémantique". Cette expression désigne un web dont les ressources sont décrites par un ensemble de variables appelées"descripteurs"ou "métadonnées". Ces descripteurs sont utilisés par des programmes qui assistent les utilisateurs pour rechercher des informations ou pour filtrer les informations disponibles sur le Web, selon des critères propres à ces utilisateurs. L'ensemble des descripteurs autorisés dans un web sémantique donné forment un schéma conceptuel. Un schéma conceptuel peut être"orienté

<Desc/Clms Page number 2>

objet", auquel cas, chaque ressource est considérée comme une instance d'une classe (au moins), et des relations sont définies entre cette classe et les autres classes du schéma conceptuel. Toute ressource peut alors être décrite à l'aide des attributs littéraux propres à sa classe, et de propriétés prenant pour valeurs des objets instances d'autres classes.

Dans les dispositifs connus de recherche de données ou de ressources, les portails web exploitent seulement les schémas conceptuels relationnels, décrivant des bases de données structurées en tables. Ces dispositifs proposent l'une des trois méthodes suivantes ou une combinaison de celles-ci : - l'exploration d'un répertoire hiérarchique de ressources, sous la forme d'un ensemble de ressources liées dont la première présente les intitulés des catégories racine et les autres, présentent de proche en proche les catégories filles de celle antérieurement sélectionnée par l'utilisateur (relation transitive d'hyponymie), - la recherche de ressources selon l'occurrence dans celles-ci d'une ou plusieurs unités lexicales textuelles, - l'évaluation d'une requête choisie par l'utilisateur parmi des requêtes prédéfinies, l'évaluation étant réalisée par interrogation de la base de données selon la requête désignée.

Aucune de ces méthodes ne permet à l'utilisateur de rechercher des ressources en spécifiant des critères de recherche librement choisis parmi tous les critères de recherche possibles dans la base de données. L'utilisateur est donc confronté à des limitations dans ses possibilités de recherche d'information. En effet, la première méthode n'autorise que l'exploration de la hiérarchie des catégories sans qu'il soit possible de rechercher les ressources, par d'autres critères que leur appartenance à ces catégories prédéfinies. La deuxième méthode conduit à un taux de bruit élevé en raison de la polysémie des termes de langue naturelle. La troisième méthode réduit les possibilités de recherche aux requêtes prédéfinies par le programmeur, et impose à ce dernier de réaliser une programmation spécifique pour chaque requête qu'il souhaite mettre à disposition de l'utilisateur.

La présente invention vient améliorer la situation.

Elle propose à cet effet un système informatique comprenant un gestionnaire de requêtes, destiné à travailler avec un gestionnaire d'historique et un générateur graphique pour afficher

<Desc/Clms Page number 3>

des entités en fonction de données stockées dans une base de données. Avantageusement, le gestionnaire de requêtes est capable de réagir au fait qu'une entité affichée est"pointée" par l'utilisateur, en exécutant sur la base de données une requête interne, définie à partir d'une expression de requête choisie, en fonction du type de l'entité, et complétée d'après l'entité.

Ceci fournit de nouvelles données, à partir desquelles l'affichage est modifié. Le gestionnaire d'historique est agencé pour interagir pas à pas avec le gestionnaire de requêtes pour construire une requête utilisateur à partir de sélections successives relatives aux entités pointées par l'utilisateur sur l'interface graphique. Le générateur graphique est capable d'afficher une représentation adaptée des résultats produits par le gestionnaire de requêtes, selon un formatage prédéterminé.

Selon une autre aspect de l'invention, le gestionnaire de requêtes est agencé pour interroger de la même manière les graphes de classes décrivant la base de données et les graphes de classes décrivant les données.

Avantageusement, le gestionnaire d'historique est apte à combiner successivement les requêtes élémentaires construites à partir d'éléments stockés, selon un opérateur logique, pour calculer la requête utilisateur.

La présente invention propose également un procédé pour générer une interface graphique de portail web, destinée à interroger une base de données, caractérisé en ce qu'il comprend les étapes suivantes : a. présenter à l'utilisateur un affichage de départ tiré de données stockées, les entités affichées étant du type classe ou objet, b. en réponse au pointage par l'utilisateur d'une entité, exécuter une requête interne sur la base de données, définie à partir d'une expression de requête choisie, en fonction du type de l'entité, et complétée d'après l'entité, c. modifier l'affichage à partir des données fournies par l'étape b, d. reprendre les étapes b et c jusqu'à décision de l'utilisateur.

Enfin, l'invention couvre également un programme-produit, qui peut être défini comme comprenant les fonctions pour exécuter les étapes a à d du procédé ci-dessus, et/ou comme comprenant les fonctions du système défini ci-dessus.

<Desc/Clms Page number 4>

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexes sur lesquels : - la figure la représente un exemple de graphes de classes extrait d'un schéma conceptuel orienté objet ; - la figure 1 b représente des instances de classes du graphe de classes de la figure la ; - la figure 2 est un schéma-bloc illustrant le portail web, le système de gestion de bases de données, le navigateur web, ainsi que leurs interactions ;

- la figure 3 est un ordinogramme des opérations utilisées pour mettre en oeuvre la présente invention ; - la figure 4a est un ordinogramme des opérations intervenant dans l'évaluation d'une requête utilisateur ; - la figure 4b est un schéma-bloc illustrant l'évaluation d'une requête utilisateur ; - la figure 5 est un ordinogramme des opérations utilisées pour mettre en oeuvre la gestion des signets ; - la figure 6 est un ordinogramme des opérations permettant une sélection par attributs de gestion documentaire ; - la figure 7 est un exemple d'interface graphique, lors de l'affichage de l'arbre des classes d'un schéma conceptuel ; - la figure 8 illustre l'affichage de la structure d'une classe ; - la figure 9 est un exemple d'interface graphique, représentant la restriction d'une requête élémentaire à des valeurs d'attributs ; - la figure 10 illustre la restriction de la requête utilisateur à des valeurs d'attributs de ressources documentaires ; - la figure 11 représente l'affichage d'une liste d'objets résultant de l'évaluation d'une requête utilisateur et d'un objet instance d'une classe, choisi dans cette liste ; - la figure 12 représente, dans le formalisme RDF, une hiérarchie de classes et des propriétés qui les relient ; et - la figure 13 est exemple de plate-forme permettant de mettre en oeuvre la présente invention.

Le présent document peut contenir des éléments susceptibles d'une protection par droit d'auteur ou copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque de ce document de brevet, tel qu'il apparaît dans les dossiers et/ou publications

<Desc/Clms Page number 5>

des offices de brevet. Par contre, il réserve pour le reste l'intégralité de ses droits d'auteur et/ou de copyright.

Les dessins contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant.

La description détaillée ci-après sera faite principalement en référence au cas d'une gestion documentaire, à titre d'exemple non limitatif. Un portail web sémantique peut, en effet, être utilisé comme un outil de gestion documentaire permettant d'effectuer une recherche documentaire sur une base de données.

Sur la figure la, on a représenté un graphe de classes extrait d'un schéma conceptuel. L'expression"graphe de classe"est utilisé ici pour la clarté, remarque étant faite que la représentation correspondante en informatique peut revêtir différentes formes, en général non graphiques. Dans une telle modélisation, une classe 100 (100-1 à 100-5) peut être qualifiée par des attributs typés 102. Elle peut être liée à des sous-classes 107 (107-1 à 107-3) par la relation"sous-classe"110. Une classe fille 107 hérite des attributs de sa classe mère 100.

Une classe 108 (108-1 à 108-2) peut être liée à la classe 100 par une relation étiquetée 104 (104-1 à 104-7), par exemple utilise ou exploite. Selon les cas, la relation 104 peut être transitive ou non. Un graphe de classe permet de définir des objets instances des classes tels

que les objets 114 (114-1 à 114-3) de la figure Ib, reliés à leur classe par la relation d'instanciation. Un tel objet est décrit à l'aide d'attributs 115 (115-1 à 115-2), et de propriétés 116 (116-1 à 116-3).

Les ressources documentaires elles-mêmes peuvent être représentées comme des instances d'une classe"documents"ou de ses sous-classes. Ces ressources seront dès lors décrites à l'aide des attributs et des relations définis, dans le schéma, pour cette classe des documents et pour ses éventuelles sous-classes. Dans la version décrite, la présente invention ne peut être réalisée que si le schéma conceptuel utilisé respecte la restriction suivante : une relation ne peut avoir qu'une seule classe origine D et une seule classe cible R, la relation étant toutefois définie pour toutes les sous-classes de D et de R.

<Desc/Clms Page number 6>

Dans un mode de réalisation particulier, un tel modèle de schéma conceptuel, et les descriptions d'objets et de ressources qu'il autorise, sont exprimés dans le modèle de description des ressources RDF ("Resource Description Framework"), défini par le consortium international W3C, et peuvent être stockés dans une base de données.

La présente invention permet d'explorer une base de données construite selon un tel graphe de classe, de façon exhaustive, afin de trouver les objets et les ressources ayant les propriétés spécifiées par l'utilisateur.

La figure 2 représente les différents blocs fonctionnels utilisés pour mettre en oeuvre la présente invention. Le portail PW comprend un serveur web (SW), un gestionnaire de requêtes (GR), un gestionnaire d'historique (GH), et un générateur graphique (GG), l'ensemble communiquant avec un navigateur web NW et avec un système de gestion de bases de données SGBD. La communication entre le portail PW et le navigateur NW utilise le protocole HTTP. La communication entre le portail PW et le SGBD utilise le langage de requête LR.

Dans un mode de réalisation particulier, LR est le langage relationnel de requête RQL ("Relational Query Langage") défini par l'institut de recherche FORTH, et on utilise le SGBD relationnel PostgreSQL développé et diffusé en logiciel libre, doté d'une extension permettant l'interprétation des requêtes formulées dans ce langage. En variante, on peut utiliser un autre système de gestion de bases de données, du type relationnel-objet ou purement objet et un autre langage de requête LR, comme le langage structuré de requête SQL-3 ("Structured Query Langage") ou le langage d'interrogation de bases de données objet OQL ("Objet Query Langage"), proposé par l'ODMG.

Dans l'exemple, le système de gestion de base de données SGBD gère deux bases de données, BDS et BDU dont les rôles respectifs sont décrits ci-après. En variante il est possible d'utiliser deux SGBD distincts. Ce ou ces SGBD doivent être accessibles soit directement soit à travers une interface adéquate, par l'un des langages de requête LR cités ci-dessus.

La base de données BDS contient :

<Desc/Clms Page number 7>

- la description des classes du schéma conceptuel avec pour chaque classe, la liste de ses attributs, et le type de ses attributs ; - la description des relations définies entre les classes du schéma. Pour chaque relation est donné l'identificateur d'une classe origine, l'identificateur d'une classe cible, et une étiquette nommant la relation ; - les tables décrivant les objets instances des classes, avec les valeurs de leurs attributs et les identificateurs des objets cibles ; - les tables décrivant les ressources documentaires à l'aide d'attributs spécifiques définis dans le schéma conceptuel, et de propriétés prenant pour valeurs des objets instances de classes.

La structure de la base BDS permet, à l'aide du langage LR, de retrouver les informations qui composent le schéma conceptuel, ainsi que la description des objets instances du schéma.

La base de données BDU contient des informations relatives à l'utilisateur du portail, notamment les requêtes signets qu'il a enregistrées lors de sessions précédentes, les requêtes auxquelles il est abonné, ainsi que ses droits d'accès à des sous-ensembles du système

d'informations. Chaque utilisateur interagit avec le dispositif à l'aide d'un navigateur web NW. Il s'agit d'un logiciel de grande diffusion tels que Internet Explorer de la société Microsoft, ou Navigator de la société Netscape. Le navigateur NW est capable d'une part de créer une représentation graphique et textuelle d'une ressource décrite dans un langage normalisé tel que HTML (HyperText Markup Langage) ou XML (eXtensible Markup Langage), et d'autre part d'émettre des requêtes conformes au protocole HTTP. La désignation par l'utilisateur d'une entité graphique particulière provoque l'émission par NW d'une requête HTTP particulière RI. Dans un mode de réalisation particulier, NW est doté d'une extension qui lui permet d'interpréter le langage graphique SVG ("Scalable Vector Graphics", extension distribuée par la société Adobe).

L'invention peut-être mise en oeuvre sur une machine serveur SER du type de celle donnée purement à titre d'exemple sur la figure 13, qui comprend au moins un système d'exploitation OSs qui supporte le portail PW et les serveurs de bases de données SGBD, ainsi qu'un processeur CPUs. La machine serveur SER communique avec les machines clientes CLI

<Desc/Clms Page number 8>

des utilisateurs qui sont des ordinateurs personnels PC, connectés à un réseau local ou public
RES, supportant le web auquel le dispositif donne accès. Chaque machine cliente comportent un processeur CPUc, un système d'exploitation OSc, un navigateur NW, ainsi que des périphériques tels qu'un écran d'affichage ECR, un clavier CL et un périphérique de pointage dit"souris"SOU.

Le navigateur NW interagit avec le serveur SW à travers le réseau. Le serveur web SW reçoit chaque requête HTTP émise par un navigateur NW, et selon le contenu de cette requête, active la procédure adéquate du gestionnaire de requêtes GR. Lorsque la requête HTTP reçue est du type POST, le serveur SW passe au gestionnaire de requêtes GR les paramètres contenus dans la requête POST. Dans le sens inverse RIO, le serveur SW reçoit les ressources HTML ou XML générées par le générateur graphique GG, et les transmet (RI 1) au navigateur NW adéquat. Le serveur SW est en outre responsable de créer et de gérer des sessions interactives pour chaque utilisateur, garantissant que chaque requête HTTP reçue d'un navigateur NW est bien allouée à un fil d'interaction propre à un utilisateur identifié.

Le gestionnaire de requêtes GR assure le traitement logique des requêtes. Il reçoit les entités pointées par l'utilisateur et génère une requête interne pour interroger la base de données sur la structure de ces entités. Il interroge d'autre part la base de données selon la requête utilisateur qui lui a été transmise par le gestionnaire d'historique GH, requête qui correspond à la recherche souhaitée par l'utilisateur. Il transmet ensuite les résultats obtenus au générateur graphique GG qui affiche une représentation correspondante.

Le gestionnaire de requêtes gère, en outre, toutes les interactions avec l'utilisateur, ainsi que les échanges avec le SGBD.

Utilisant les paramètres R2 que lui transmet SW, et ceux R4 qu'il obtient du gestionnaire d'historique GH, il forme une ou plusieurs requête (s) dans le langage LR et adresse cette requête R5 au SGBD. Le SGBD retourne les données correspondantes à cette requête R6.

Dans une réalisation, ces données sont codées dans le formalisme XML RDF. Cependant, il serait possible d'utiliser un autre formalisme XML préservant la structure des résultats retournés par le SGBD.

<Desc/Clms Page number 9>

Le générateur graphique GG est activé par le gestionnaire de requêtes GR par la communi- cation R9, chaque fois que celui-ci obtient des données du SGBD en réponse à une requête.

Le générateur graphique GG transforme ces données en une représentation XML ou HTML qui pourra être transmise au serveur SW (RIO) puis au navigateur NW (RI 1) pour y être interprétée et affichée graphiquement. Dans une réalisation particulière, le générateur graphique GG est un interpréteur XSLT qui reçoit en entrée l'arbre XML produit par le gestionnaire de requête GR, et une feuille de style XSLT prédéfinie. Le processeur GG transforme l'arbre XML en une ressource HTML ou SVG ("Scalable Vector Graphics") qui est alors transmise au serveur SW.

Le gestionnaire d'historique GH assure la gestion de l'historique des requêtes élémentaires réalisées par un utilisateur pendant une session interactive. Recevant des messages R3 du gestionnaire de requête GR, il met à jour pour chaque utilisateur une structure de données représentant l'historique des requêtes émises par celui-ci au cours de la session interactive.

Les messages R3 portent sur la structure des entités désignées par l'utilisateur, obtenues à partir d'une interrogation de la base de données par le gestionnaire de requêtes GR. Ladite structure de données permet au gestionnaire d'historique de calculer une requête à partir d'une combinaison logique de requêtes élémentaires correspondant aux différents éléments de la structure de données. Le gestionnaire d'historique GH retourne alors la requête utilisateur calculée R4 au gestionnaire de requête GR qui peut alors la soumettre au SGBD pour une évaluation (R5).

Dans une réalisation particulière, le gestionnaire de requêtes GR, le gestionnaire d'historique GH et le générateur graphique GG sont écrits dans le langage Java, et la communication avec le SGBD utilise une interface conforme au standard industriel JDBC ("Java DataBase Connectivity"), défini par la société Sun Microsystems.

Sur les figures 3 à 6, on a représenté un exemple de fonctionnement du système de portail Web. Dans ces figures, les rectangles à angles arrondis représentent des actions de l'utilisateur, et les rectangles à angles droits figurent les traitements réalisés par le dispositif en réponse à ces actions.

<Desc/Clms Page number 10>

On se réfère à la figure 3 qui décrit le fonctionnement global du portail. A l'étape 200, un utilisateur accède au portail web. Cette étape peut comporter des opérations interactives permettant l'identification de l'utilisateur par tout moyen adéquat. Par exemple, on peut demander à l'utilisateur de s'identifier en saisissant son nom d'utilisateur et son mot de passe.
Ces opérations d'identification sont décrites dans des réalisations connues. Par la suite, on supposera que le système a pu identifier l'utilisateur.

L'utilisateur est donc autorisé à accéder à l'étape 201 d'initialisation. Au cours de cette étape, le système initialise une session interactive pour l'utilisateur. Une session interactive commence lorsqu'un utilisateur se connecte et est identifié, et se termine lorsque l'utilisateur le demande ou lorsque la durée fixée de la session est écoulée. Le système crée, en outre, un historique de session dont le rôle sera détaillé à l'étape 207. Le système recherche ensuite dans la base de données BDU les signets définis pour l'utilisateur, puis recherche dans la base de données BDS la hiérarchie des classes définies dans le schéma conceptuel. A titre d'exemple, dans une réalisation particulière, la recherche dans la base de données BDS est réalisée grâce à la requête RQL suivante : select C, superclassof (C) from Class (C) Cette requête pourra donner comme résultat une ressource RDF de la forme de celle représentée par la figure 12. On voit que ce résultat décrit chaque classe, dans le formalisme RDF, en indiquant quelle est sa super-classe dans le schéma conceptuel utilisé. La requête ci-dessus vise à construire des couples formés chacun d'un identificateur de classe et de l'identificateur de sa super classe. Dans l'exemple de la figure 12, l'ensemble des résultats est fourni sous forme d'un ensemble non ordonné (élément bag). Chaque couple est donné dans un élément li sous forme d'une séquence seq. Le premier couple est formé de l'identificateur de classe"Equipement", puis de l'identificateur de classe racine"Resource" prédéfinie dans le modèle RDF. Ce premier couple indique donc qu'il existe dans le schéma

conceptuel interrogé une classe"Equipement"au niveau le plus élevé défini dans le schéma. Le couple suivant indique qu'il existe une classe"Organisation", également au niveau le plus élevé du schéma conceptuel. Enfin, le dernier couple indique qu'il existe une classe "Ministère"dont la super-classe est la classe organisation.

<Desc/Clms Page number 11>

En utilisant cette ressource XML, le générateur graphique GG peut alors générer une page de présentation de service (202). La figure 7 montre un exemple de présentation des classes dans le cadre gauche du navigateur. Le contenu du cadre principal droit dépend de chaque base de donnée BDS. Les signets figurant dans la partie inférieure du cadre gauche sont décrits ci-après à l'étape 204. La liste de classes figurant dans le cadre gauche est générée par le générateur graphique GG à partir de la ressource RDF dont la figure 12 est un extrait, et d'une feuille de style XSLT. Dans une réalisation particulière, et dans un souci d'optimisation, cette ressource HTML présentant la hiérarchie des classes peut être générée lors de la première requête, puis placé en mémoire cache. Elle ne sera régénérée qu'en cas de modification du schéma. Cette optimisation, si elle a lieu, est réalisée par les fonctions standards du serveur Web utilisé, indépendamment du gestionnaire de requête et du générateur graphique.

A partir de l'étape 202, l'utilisateur a le choix entre les actions suivantes : - mettre fin à la session (étape 203), - sélectionner un signet enregistré (étape 204), - sélectionner la classe des documents (étape 206), ou - sélectionner l'une des classes de la hiérarchie de classes définies dans le schéma conceptuel (étape 205).

A l'étape 205, l'utilisateur sélectionne par pointage l'une des classes présentées à l'écran, cette présentation pouvant résulter de l'étape 202 ou de l'étape 208.

A l'étape 207, le gestionnaire d'historique GH met à jour l'historique de requête propre à la session et à l'utilisateur. Cet historique permet de déterminer à chaque instant quelle est la requête résultant de la combinaison booléenne"ET"de l'ensemble des choix faits par l'utilisateur au cours de la session interactive. Une possibilité consiste à représenter cet historique comme un dictionnaire de listes où la clé est un identificateur de transaction dans la session courante, une nouvelle transaction étant créée chaque fois que l'utilisateur sélectionne une nouvelle classe et où chaque item est une liste : - le premier élément de cette liste est l'identificateur de la classe sélectionnée.

- le second élément peut être :

<Desc/Clms Page number 12>

- l'identificateur (URI) de la propriété définie dans le schéma conceptuel entre la classe courante sélectionnée et la classe sélectionnée dans la transaction précédente, la direction de cette propriété, c'est à dire le fait que l'une ou l'autre de ces deux classes soit origine ou cible de la relation n'étant pas prise en compte.

- une valeur nulle (représentée dans le présent document par le symbole Nil), si la classe courante a été sélectionnée dans la hiérarchie présentée dans le cadre gauche de la fenêtre de visualisation, dans l'un des cas suivants :
1) la classe courante est la première sélectionnée au cours de la session interactive,
2) l'utilisateur a choisi une classe qui n'a pas de relation avec la classe précédemment sélectionnée,
3) l'utilisateur n'a pas souhaité prendre en compte une telle relation.

- les éléments suivants sont des triplets {nom, opérateur, valeur} qui décrivent les contraintes des valeurs d'attributs définies par l'utilisateur pour la classe sélectionnée. On remarquera que ces triplets ne sont créés que lorsque la mise à jour de l'historique résulte de l'étape 211.

Lorsque la mise à jour de l'historique résulte d'une sélection de classe faite à l'étape 212, sans que l'utilisateur n'ait encore spécifié de valeurs d'attributs, l'entrée créée dans le dictionnaire ne comporte pas de triplets.

A l'étape 208, le gestionnaire de requêtes recherche dans la base de données BDS la liste des attributs et des propriétés de la classe sélectionnée et de ses super-classes, le type de ces attributs, les classes définissant les domaines de valeur des propriétés dont la classe sélectionnée est origine. Dans une réalisation particulière, ces informations peuvent être obtenues par la requête RQL suivante :

select *from f. Equipement] @P (.-$$Yj where $$Yin Literal OR $$Y in Class où"Equipement"est supposé être l'identificateur de la classe sélectionnée. Le résultat de cette requête peut alors être transmis au générateur graphique GG qui produit une représentation HTML ou SVG de la structure de la classe. La figure 8 montre un exemple de présentation graphique ainsi générée, après que l'utilisateur a sélectionné la classe

<Desc/Clms Page number 13>

"Equipement"à l'étape 205. Les boutons"Valeur","Dateacqui", et"Type"indiquent à l'utilisateur que les instances de la classe"Equipement"ont des attributs de ce nom pour lesquels il peut, s'il le souhaite, choisir une valeur pour restreindre d'avantage la sélection

de ces instances. Les boutons"Fournisseur","Projet","Equipe"et"Organisme"signalent à l'utilisateur que ces classes ont une propriété qui les relie à la classe"Equipement".

L'utilisateur peut sélectionner ces classes à l'aide de ces boutons, pour restreindre la sélection courante, comme cela est décrit à l'étape 205.

A l'issue de l'étape 208, l'utilisateur a le choix entre les options suivantes : - sélectionner une des classes qui lui est présentée (étape 205), à savoir une classe reliée à la classe courante par une propriété. Le choix de cette option résultera dans un changement de classe courante ; - sélectionner une classe dans la hiérarchie de classes présentée dans le cadre gauche de la fenêtre de visualisation. On décrit à l'étape 211 en quoi une telle sélection de classe a une sémantique différente de la sélection de classe visée à l'alinéa précédent.

- annuler la sélection qui vient d'être opérée (étape 209) ; - spécifier des contraintes sur les valeurs des attributs de la classe courante pour restreindre la sélection d'objets à ceux satisfaisants ces contraintes (étape 212) ; - demander l'affichage des objets instances de la classe précédemment sélectionnée (étape 210) ; - demander l'affichage de la liste des ressources documentaires correspondant à la sélection courante (étape 211).

A l'étape 209, lorsque l'utilisateur active la commande d'annulation, le gestionnaire d'historique GH supprime de l'historique de session l'entrée correspondante à la dernière sélection réalisée. Le gestionnaire de requêtes GR retrouve ensuite la structure de la classe précédemment sélectionnée qui se trouve être celle figurant dans la dernière entrée de l'historique ainsi mis à jour. Le générateur graphique GG peut dès lors produire un affichage de la structure de cette classe exactement comme cela avait été fait lors de l'étape 205 précédente. En particulier, il est possible de conserver en mémoire RAM sous forme d'objets Java la représentation des structures des classes antérieurement explorées par l'utilisateur pour éviter d'avoir à ré-interroger la base de données BDS lorsque celui-ci annule des sélections et revient ainsi en arrière dans son historique d'interactions avec le dispositif.

<Desc/Clms Page number 14>

A l'étape 212, l'utilisateur décide de spécifier des valeurs cibles pour les attributs des objets instances de la classe courante qu'il souhaite sélectionner. La figure 9 montre un exemple d'écran présenté à un utilisateur lors de cette étape. L'utilisateur peut choisir l'un des opérateurs > ou < ou =, si l'attribut est numérique ou de type date, puis une valeur. Il peut spécifier une valeur dans le cas d'un attribut prenant pour valeur une chaîne de caractères.

Lorsque l'utilisateur valide ses choix de valeurs d'attributs, le système passe à l'étape 207 pour mettre à jour l'historique de requête dont la structure a été décrite ci-dessus. Lors de cette mise à jour des triplets {nom d'attribut, opérateur, valeur} seront créés dans l'entrée correspondant àlatransaction courante pour chacun des attributs pour lequel 1'utilisateur aura spécifié une valeur.

A l'étape 210, l'utilisateur demande l'affichage des objets instances de la classe courante, éventuellement sélectionnés sur la base des valeurs d'attributs choisies lors de l'étape 212.

Pour répondre à cette demande, le gestionnaire de requêtes GR consulte le gestionnaire d'historique GH et obtient le n-uplet représentant la dernière transaction. Ce n-uplet indique la classe courante qui a été sélectionnée, et le cas échéant, les attributs de cette classe pour lesquels l'utilisateur a indiqué des valeurs particulières. Ce n-uplet permet de former une requête dont la sémantique est :

"Trouver les valeurs des attributs An,... Am, de tous les objets Oj instances de C tels que (AI, < 9P, E72, CP, F" où An... Am sont des attributs définis pour la classe C, C est le nom de la classe courante, et {Ax, OP, Vi} représente un triplet {Attribut, Opérateur, Valeur} résultant d'un choix par l'utilisateur à l'étape 212. Lorsque la sélection courante comporte plusieurs triplets, ceux-ci sont combinés par l'opérateur booléen"ET"réalisant l'intersection des sous-ensembles d'objets sélectionnés par chacun des triplets. Le choix des attributs de présentation An... Am peut varier pour chaque réalisation du dispositif et pour chaque classe d'objets. Ce choix est contrôlé et déterminé par l'administrateur système, lors de l'installation du système. Dans les exemples des figures 7 à 12, on a représenté les objets par leur nom symbolique.

<Desc/Clms Page number 15>

La requête ainsi formée dans le langage de requête LR est soumise au SGBD gérant la base de données BDS. Les résultats retournés sont alors transmis au générateur graphique GG qui en réalise une présentation en HTML avec une mise en page adéquate.

L'utilisateur peut alors pointer l'un des objets présentés dans cette liste et en obtenir une description plus complète, incluant tous les attributs définis pour cet objet. La figure 11 illustre une présentation possible d'un objet ainsi sélectionné.

A l'étape 211, l'utilisateur demande l'affichage de la liste des ressources documentaires correspondant à la sélection courante. Lorsque le gestionnaire de requêtes GR reçoit la demande de calcul de la sélection courante de ressources documentaires, il active la procédure adéquate du gestionnaire d'historique GH.

On se réfère maintenant à la figure 4a qui illustre les différentes étapes de l'évaluation d'une requête utilisateur. En réponse à la demande d'évaluation de requête 211, transmise par le gestionnaire de requêtes, le gestionnaire d'historique GH sélectionne une ligne de l'historique de requête à l'étape 2110, à partir de laquelle il calcule la requête élémentaire correspondante, dans le langage de requête LR. Il stocke alors provisoirement cette requête dans la variable REQEL (1). Le gestionnaire d'historique initialise ensuite une variable REQ (l), en lui affectant la valeur REQEL (1), à l'étape 2113.

A la suite de cette phase d'initialisation, le gestionnaire d'historique GH réitère les étapes suivantes, pour toutes les lignes i de l'historique de requête, et ce, jusqu'à ce que toutes les lignes de l'historique aient été traitées : A l'étape 2110, il sélectionne une ligne i de l'historique de requête et construit la requête élémentaire REQEL (i) correspondante, à l'étape 2111. Chaque ligne i de l'historique contient les caractéristiques d'une transaction i correspondant à la classe Ci pointée par l'utilisateur. A la suite de cette sélection, le gestionnaire d'historique calcule une requête REQ (i), par combinaison selon un opérateur logique op déterminé à l'étape 2111 de la requête élémentaire REQEL (i) et de la requête précédente REQ (i). Lorsque toutes les lignes de l'historique ont été traitées, REQ (n) contient en effet la requête utilisateur correspondant à la recherche

<Desc/Clms Page number 16>

documentaire que souhaite l'utilisateur. Le gestionnaire d'historique passe alors àl'étape 2113 où il transmet la dernière requête calculée REQ (n) au gestionnaire de requêtes GR.

L'étape 2111 comprend une étape préalable d'analyse des items de l'historique, pour déterminer la requête élémentaire REQEL (i) qui correspond à chaque transaction i, ainsi que l'opérateur logique op de l'étape 2113. Cette analyse se déroule selon les principes suivants : - lorsque la classe Ci n'est pas liée à la précédente par une propriété identifiée dans l'historique, autrement dit, lorsque le troisième item de l'entrée dans l'historique a

la valeur nil, la requête élémentaire relative à cette classe correspond à"la sélection de l'ensemble des documents numériques ayant une relation définie avec les instances de la classe Ci non liée". Cette classe Ci sera donc utilisée à l'étape 2113, pour étendre la sélection des documents numériques, en y incluant ceux ayant une relation définie avec les instances de la classe Ci non liée. Pour cela, le système génère une requête élémentaire correspondante REQEL (i), qui sera combinée avec REQ (i-l) par un opérateur logique op"OU" ; - si la classe Ci est celle des documents numériques"Documents", ou l'une de ses

sous-classes (étape 206), telle que l'indique le deuxième item de l'entrée dans l'historique, la requête élémentaire relative à cette classe correspond à "la sélection de l'ensemble des documents numériques dont les attributs respectent les contraintes de valeurs indiquées par les triplets de l'historique". Cette classe Ci sera donc utilisée à l'étape 2113 pour restreindre la sélection des documents à ceux dont les attributs respectent les contraintes de valeurs indiquées par les triplets de cette transaction i. Cette restriction est réalisée en générant une requête élémentaire correspondante REQEL (i), qui sera combinée avec REQ (i-l) par un opérateur logique op"ET" ; - lorsque la classe Ci est liée à la précédente par une propriété identifiée dans l'historique, autrement dit, lorsque le troisième item de l'entrée dans l'historique est différent de nil, la requête élémentaire relative à cette classe correspond à "la sélection

de l'ensemble des documents numériques ayant une relation définie avec les instances de la classe Ci liée". Cette classe Ci sera donc utilisée à l'étape 2113, pour restreindre la sélection des documents numériques ayant une relation définie avec les instances de la classe CI, la classe CI étant la classe sélectionnée lors de la première transaction de cette liste chaînée de transactions. Cette restriction est encore réalisée en générant

<Desc/Clms Page number 17>

une requête élémentaire correspondante REQEL (i), qui sera combinée avec REQ (i-
1) par un opérateur logique op"ET".

La figure 4b représentent les modules nécessaires à l'évaluation d'une requête. Le bloc convertisseur/analyseur CA, convertit les caractéristiques la transaction i, trans (i) stockée dans l'historique en requête élémentaire REQEL (i) formulée en langage de requête. Ce bloc détermine également l'opérateur logique op en fonction de trans (i). Le bloc fonction logique FL calcule ensuite la nouvelle valeur REQ (i) à partir des entrées op, REQEL (i) et REQ (i-1) calculée à l'étape précédente. A l'étape n, le gestionnaire d'historique envoie REQ (n) au gestionnaire de requête GR.

Considérons maintenant, à titre d'exemple, l'historique suivant qui comporte quatre transactions :

ITOOI Equipment M/7/'My > 700 IT002 Projet Utilise {Localisation = Rocquencourt} IT003 Personne ni ! {nom = *Smith} IT004 Documents nil !/ Lb > 07 : OI : 2000} La signification de cet historique est la suivante. L'utilisateur, à la première étape 205, a sélectionné la classe"Equipement", puis à l'étape 212 a créé un filtre en indiquant une valeur minimum pour l'attribut"Valeur"des instances d'"Equipement".

Il a ensuite choisi la classe"Projet", liée à la classe"Equipement"par la propriété Utilise.

Pour cette classe, il a indiqué qu'il souhaitait ne prendre en compte que les Projets dont l'attribut Localisation a pourvaleur"Rocquencourt". L'utilisateur, en enchaînant la sélection de ces deux classes a indiqué qu'il souhaitait des documents concernant les équipements d'un prix supérieur à 10000, utilisé par les projets localisés à Rocquencourt.

L'utilisateur a ensuite sélectionné la classe"Personne"dans le cadre gauche de la fenêtre de visualisation. Cette classe n'est pas liée par une propriété identifiée à la classe précédente "Projet". Même si une telle propriété existait dans le schéma conceptuel, elle ne serait pas prise en compte ne figurant pas explicitement dans l'historique, du fait que l'utilisateur a sélectionné la classe"Personne"dans le cadre gauche de la fenêtre de visualisation.

<Desc/Clms Page number 18>

Enfin, l'utilisateur a sélectionné la classe"Documents", et a indiqué qu'il souhaitait restreindre la sélection de documents à ceux modifiés après le 1 er janvier 2000.

Dans cet exemple, la sélection courante de ressources documentaires est le résultat de la requête dont la sémantique, exprimée en langue pseudo-naturelle est : "Trouver toutes les ressources D instances de Document", telles que exprl ET [expr2 ET ( (expr3 OU expr4) ET expr5)] OU expr6, où,

exprl = D aun attribut"LastModified"dont lavaleur est une date postérieure au 1 er janvier 2000 , expr2 = D est reliée à X par une relation RI quelconque, X étant une instance de la classe "Equipement", l'attribut"Valeur"pour X ayant une valeur supérieure à 10000 , expr3 = X est reliée à Y par une relation Utilise , expr4 = Y est reliée à X par une relation Utilise , expr5 = Y est une instance de la classe"Projet", dont l'attribut"Localisation"a pour valeur la chaîne de caractères"Rocquencourt" , expr6 = D est liée à Z, Z étant une instance de la classe Personne, dont l'attribut Nom se termine par la chaîne de caractères"Smith" .

La présente invention permet donc à l'utilisateur de créer, par manipulations interactives successives simples, des requêtes complexes pour trouver des ressources documentaires dans une base de données.

En variante, la requête utilisateur résultant de l'organigramme décrit ci-dessus, permet non seulement de retrouver les identificateurs des ressources cibles, mais aussi un certain nombre d'attributs de ces ressources, tels que par exemple le titre et la date de publication, afin de présenter à l'utilisateur un affichage détaillé de la liste des ressources trouvées. Le choix de ces attributs de présentation est spécifié dans une ressource externe au code de l'application portail, pour permettre de les modifier indépendamment du programme du portail.

Lorsque le gestionnaire de requête GR reçoit la requête utilisateur REQ (n), il l'a soumet, à l'étape 2114 de la figure 4a, au SGBD qui retourne la liste des instances de la classe

<Desc/Clms Page number 19>

"Documents"satisfaisants aux termes de la requête. Cette liste est enfin transmise au générateur graphique GG, à l'étape 2115, qui réalise une mise en forme permettant son affichage par le navigateur NW. Comme pour la liste d'objets représentée sur la figure 11, la liste des ressources documentaires peut-être formée de titres, qui sont chacun l'ancre d'un lien hypertextuel dont la traversée provoque l'affichage de la ressource elle-même, à l'aide de l'application adéquate choisie en fonction du format de la ressource.

L'étape 213 de la figure 3, permet à l'utilisateur de mémoriser la requête courante résultant des sélections non annulées, réalisées antérieurement dans la session interactive. Dans l'exemple présenté dans les figures 8 et 9, l'utilisateur peut déclencher cette opération en pointant le bouton en forme de flèche situé immédiatement à droite du titre Signets dans le cadre gauche du navigateur. Lorsque l'utilisateur active la commande provoquant l'exécution de cette étape, une boîte de dialogue lui est présentée lui demandant de choisir un nom pour cette requête courante. Ce nom sera ultérieurement utilisé pour présenter cette requête dans la liste des signets telle qu'elle apparaît dans les exemples de réalisation des figures 7,8 et 9. Si l'utilisateur a précédemment réalisé l'étape 211, la requête mémorisée à l'étape 213 est la même que celle qui a été calculée et évaluée à l'étape 211. Si l'utilisateur n'est pas passé par l'étape 211, la requête courante est calculée selon le même algorithme que celui utilisé à l'étape 211. Toutefois, la requête n'est pas transmise à la base de données BDS pour évaluation, mais elle est mémorisée dans la base de données BDU, avec le nom symbolique choisi par l'utilisateur, la date et heure de sa création. Cette requête pourra ultérieurement être évaluée. Elle pourra également être combinée avec d'autres requêtes mémorisées pour former de nouvelles requêtes, comme cela est décrit dans la figure 5. Un utilisateur ayant les autorisations nécessaires peut créer un signet pour le compte d'un utilisateur tiers.

On se réfère maintenant à la figure 6 qui illustre la mise en oeuvre d'une sélection de documents numériques au moyen de signets prédéfinis. Un utilisateur ayant mémorisé des requêtes sous forme de signets (étape 213 de la figure 3), soit au cours de la session interactive courante soit aux cours de sessions antérieures, peut décider de former de nouvelles requêtes en combinant certaines de ces requêtes mémorisées. Pour cela, il peut choisir un signet à l'étape 204, puis un opérateur logique"ET"/"OU"à l'étape 2042, et enfin un deuxième signet

<Desc/Clms Page number 20>

à l'étape 2043. Ces désignations successives caractérisent une nouvelle requête qui correspond à : - une combinaison booléenne"ET"des deux requêtes préexistantes choisies, si l'opérateur "ET"a été désigné. Dans ce cas, le résultat de la nouvelle requête est l'intersection des ensembles résultats des deux requêtes préexistantes.

- une combinaison booléenne"OU"des deux requêtes préexistantes choisies, si l'opérateur "OU"a été désigné. Dans ce cas, le résultat de la nouvelle requête est l'union des ensembles résultats des deux requêtes préexistantes.

Ayant ainsi créé une nouvelle requête, et après l'avoir mémorisée sous un nom symbolique (signet) dans la base de donnée BDD conformément à l'étape 213 décrite ci-dessus, l'utilisateur peut de nouveau former une nouvelle requête en combinant celle qui vient d'être créée avec une autre requête existante. L'utilisateur peut ainsi de proche en proche définir des requêtes par des intersections ou unions d'un nombre choisi de requêtes.

L'utilisateur peut évaluer un signet mémorisé, à tout moment d'une session interactive. S'il vient de construire et de nommer par un signet une nouvelle requête à partir de requêtes préexistantes (figure 4), il peut demander directement l'évaluation de la nouvelle requête (étape 2040) ; sinon il peut choisir un signet à l'étape 204, puis demander l'évaluation de la requête ainsi désignée. Dans les deux cas, ces opérations provoquent l'évaluation de la requête mémorisée sous le nom du signet correspondant dans la base de données BDU.

Dans le cas où l'utilisateur accède à l'évaluation d'une requête depuis l'étape 204, deux cas de figures peuvent se présenter : - si l'étape 204 est la première étape réalisée de la session interactive courante, la requête est évaluée et les résultats affichés.

- si l'étape 204 est déclenchée au cours de la session interactive alors que des sélections ont créé une requête courante, un message demande à l'utilisateur de confirmer l'abandon de la requête courante au profit de la requête mémorisée sous le signet. Si l'utilisateur confirme son choix, la requête courante est abandonnée, l'historique de session est effacé et l'étape 204 se poursuit. Si l'utilisateur ne confirme pas son choix, l'étape 204 est abandonnée.

<Desc/Clms Page number 21>

Dans une variante de réalisation, un utilisateur peut s'abonner à un signet mémorisé et demander de recevoir les résultats de la requête correspondante par courrier électronique, cette requête étant ré-évaluée à un intervalle régulier choisi par l'utilisateur.

L'utilisateur peut à tout moment réaliser l'étape 206 par laquelle il spécifie des valeurs d'attributs que devront respecter les ressources documentaires numériques recherchées. Cette étape est décrite en détail dans la figure 6. Pour accéder à cette étape, l'utilisateur sélectionne la classe mère de ces ressources, présentée dans l'exemple des figures 7 à 11 sous le nom Documents . La figure 10 illustre un exemple d'interface graphique permettant de spécifier les attributs de ces ressources. Les attributs figurant dans cette interface graphique pourront différer dans chaque réalisation, puisqu'ils sont définis dans le schéma conceptuel utilisé.

Cette interface graphique est donc générée dynamiquement, à l'étape 2060 de la figure 6, par des méthodes identiques à celles décrites aux étapes 201 et 202, seule la requête de structure étant ici différente. Dans le mode de réalisation décrit dans les exemples, les attributs présentés sont retrouvés dans la base de données BDS à l'aide de la requête RQL suivante : select * from {.-Documents@P.'Y) whe e $ Y Zeral A l'étape 2061 de la figure 6, le résultat de cette requête est formaté par le générateur graphique GG comme indiqué à l'étape 202 de la figure 3, pour afficher des zones {nom d'attribut, Opérateur, Valeur} pour tous les attributs de la classe"Documents".

A l'étape 2062 de la figure 6, l'utilisateur peut désigner et valider des choix de valeurs d'attributs. Une entrée particulière est alors créée dans l'historique de session à l'étape 2063.

Cette entrée comporte autant de triplets {Attribut, Opérateur, Valeur} que l'utilisateur a spécifié de contraintes sur les attributs. Si une telle entrée existe dans un historique de session, elle est utilisée à l'étape 211 pour restreindre la sélection de ressources recherchées, sans que la position de cette entrée dans l'historique ne soit prise en compte dans la formation de la requête. En d'autres termes, les choix de valeurs d'attributs opérés lors de l'étape 206 auront la même sémantique quel que soit le moment dans la session interactive auquel l'utilisateur réalise l'étape 206.

<Desc/Clms Page number 22>

A l'issue de cette étape de mise à jour de l'historique, l'utilisateur peut soit évaluer directement la requête utilisateur (étape 211), soit choisir une nouvelle classe (étape 205).

En complément, l'utilisateur a la possibilité de mettre fin à la session interactive courante, en sélectionnant l'étape 203. Dans la réalisation proposée en exemple, si l'étape 203 est déclenchée au cours d'une session interactive alors que des sélections ont créé une requête courante, et alors que la dernière opération réalisée n'est pas une étape 213, un message demande à l'utilisateur s'il souhaite confirmer l'abandon de la requête courante, ou réaliser l'étape 213.

La description qui précède est présentée sous forme d'opérations à la manière d'un procédé.

On notera cependant que de nombreuses étapes sont déclenchées par l'action de l'utilisateur.

En conséquence, la séquence des opérations, telle que présentée, n'a pas de caractère obligatoire. Il s'agit plutôt d'opérations événementielles, déclenchées par l'action de l'opérateur en fonction du contexte que lui présente l'affichage, conformément à ce qui a été décrit.

Bien entendu, l'invention n'est pas limitée à la forme de réalisation décrite précédemment à titre d'exemple. Elle peut s'étendre à d'autres variantes d'exploration de ressources. Elle peut notamment être employée pour construire des applications de gestion de projets, à l'usage d'une entreprise ou d'un groupe d'entreprises. Elle peut également être utilisée pour construire des applications de gestion et de recherche documentaire à l'usage de communautés d'utilisateurs sur le Web public.

Par ailleurs, l'invention ne fait pas d'hypothèse sur les méthodes utilisées pour créer les objets instances des classes, et pour décrire les ressources documentaires à l'aide de ces objets et d'attributs spécifiques. Elle n'introduit pas de limitations dans les types de ressources documentaires gérées. Celles-ci peuvent être des fichiers de tous formats, des collections ou répertoires de fichiers ou de répertoires, des boîtes aux lettres de courrier électronique, des fils de discussion, des tableaux blancs de systèmes de coopération, etc.

Enfin, l'invention est parfaitement compatible avec une organisation du web en plusieurs segments ou sous-ensembles, chaque segment étant décrit dans une base de données BDS

<Desc/Clms Page number 23>

particulière, l'application procédant à la réplication complète ou partielle des données propres à chaque segment dans un serveur centralisé ou dans de multiples serveurs eux-mêmes distribués. Une telle architecture peut offrir aux utilisateurs la possibilité de rechercher des ressources comme cela a été décrit, soit au niveau d'un segment, soit au niveau du web complet. Il est également possible, selon le même principe, d'organiser l'indexation du web selon une hiérarchie de segments à plusieurs niveaux.

Dans la réalisation utilisée en exemple, le choix du formalisme RDF pour représenter le schéma conceptuel et tous les objets manipulés par l'application, est guidé par le fait que ce formalisme normalisé facilite considérablement l'échange de données entre de multiples serveurs, et dès lors, facilite également la réalisation de systèmes de web sémantiques indexés dans de multiples serveurs coopérants.

La présente invention vise également le code logiciel qu'elle fait intervenir, tout particulièrement lorsqu'il est mis à disposition sur tout support lisible sur un ordinateur. L'expression "support lisible par ordinateur"couvre un support de stockage, par exemple magnétique ou optique, aussi bien qu'un moyen de transmission, tel qu'un signal numérique ou analogique.

Toutefois, l'invention ne porte que sur la méthode d'interrogation de ce ou de ces serveurs, et ne prétend donc pas constituer une solution à l'ensemble des difficultés liées à une telle organisation hiérarchisée du Web.

Claims (20)

Revendications

1. Système informatique, du type comprenant un gestionnaire de requête (GR), destiné à travailler avec un gestionnaire d'historique (GH) et un générateur graphique (GG) pour afficher des entités en fonction de données stockées dans une base de données, caractérisé en ce que - le gestionnaire de requêtes (GR) est capable de réagir au fait qu'une entité affichée est pointée par l'utilisateur, en exécutant sur la base de données une requête interne, définie à partir d'une expression de requête choisie en fonction du type de l'entité, et complétée d'après l'entité, ce qui fournit de nouvelles données, à partir desquelles l'affichage est modifié, - le gestionnaire d'historique (GH) est agencé pour interagir pas à pas avec le gestionnaire de requêtes (GR) pour construire une requête utilisateur à partir de sélections successives relatives aux entités pointées par l'utilisateur sur l'interface graphique, et - le générateur graphique (GG) est capable d'afficher une représentation adaptée des résultats produits par le gestionnaire de requêtes, selon un formatage prédéterminé.

2. Système informatique selon la revendication 1, caractérisé en ce que le gestionnaire de requête (GR) comprend une requête de début pour interroger la base de données sur sa structure globale et afficher l'ensemble de ses classes et de ses sous-classes.

3. Système informatique selon la revendication 2, caractérisé en ce que le gestionnaire de requêtes (GR) est apte à interroger des entités, de type classe ou objet, pointées par l'utilisateur, sur leurs structures.

4. Système informatique selon l'une des revendications 2 et 3, dans lequel la base de données et les données elles-mêmes forment des graphes de classe, caractérisé en ce que le gestionnaire de requêtes (GR) est agencé pour interroger les graphes de classe, base de données et données, de la même manière.

5. Système informatique selon la revendication 4, caractérisé en ce que le gestionnaire de requêtes (GR) est capable d'exécuter une requête interne pour afficher les éléments suivants, en réponse à une entité pointée de type classe : - les classes liées, par une relation prédéterminée dans la base, à la classe pointée,

<Desc/Clms Page number 25>

- des zones nom-valeurs pour les attributs de la classe pointée ainsi que les opérateurs liés au type de chacun des attributs.

6. Système informatique selon la revendication 5, caractérisé en ce que le gestionnaire de requêtes (GR) est capable d'exécuter une requête interne pour afficher la liste des objets instances d'une entité pointée, de type classe, une fois sa structure affichée.

7. Système informatique selon la revendication 6, caractérisé en ce que le gestionnaire de requêtes (GR) est capable d'exécuter une requête interne pour afficher les éléments suivants, en réponse à une entité pointée de type objet : - les documents liés, par une relation prédéterminée dans la base, à l'objet pointé, - l'ensemble des attributs de l'objet pointé.

8. Système informatique selon l'une des revendications 3 et 5, caractérisé en ce que le gestionnaire d'historique (GH) comprend un moyen de stockage des éléments de structure de chaque entité pointée de type classe, ainsi que des valeurs d'attributs éventuellement choisies parl'utilisateur pour cette classe.

9. Système informatique selon la revendication 8, caractérisé en ce que le gestionnaire d'historique (GH) est apte à combiner successivement des requêtes élémentaires construites à partir des éléments stockés, selon un opérateur logique, pour calculer la requête utilisateur.

10. Système informatique selon la revendication 9 prise en combinaison avec la revendication 8, caractérisé en ce que l'opérateur logique est déterminé en fonction des éléments stockés.

11. Système informatique selon la revendication 9, caractérisé en ce que le gestionnaire d'historique (GH) est agencé pour transmettre la requête utilisateur calculée au gestionnaire de requêtes pour une évaluation.

12. Système informatique selon la revendication 1, caractérisé en ce que le gestionnaire de requête (GR) comprend un moyen de mémorisation des requêtes utilisateur sous un nom symbolique dans une liste de requêtes prédéfinies.

<Desc/Clms Page number 26>

13. Système informatique selon la revendication 12, caractérisé en ce que le gestionnaire d'historique (GH) est apte à construire une requête utilisateur à partir de deux requêtes antérieurement mémorisées, en les combinant par un opérateur logique choisi.

14. Système informatique selon la revendication 5, caractérisé en ce que le gestionnaire de requêtes (GR) est capable d'exécuter une requête interne pour afficher des zones"nom-valeursopérateurs"pour les attributs documentaires, en réponse à un pointage de la classe documentaire.

15. Procédé pour générer une interface graphique de portail web, destinée à interroger une base de données, caractérisé en ce qu'il comprend les étapes suivantes : a. présenter à l'utilisateur un affichage de départ tiré de données stockées, les entités affichées étant du type classe ou objet, b. en réponse au pointage par l'utilisateur d'une entité, exécuter une requête interne sur la base de données, définie à partir d'une expression de requête choisie en fonction du type de l'entité, et complétée d'après l'entité, c. modifier l'affichage à partir des données fournies par l'étape b, d. reprendre les étapes b et c jusqu'à décision de l'utilisateur

16. Procédé selon la revendication 15, caractérisé en ce que l'étape a comprend un affichage initial de l'ensemble des classes et des sous-classes de la base de données.

17. Procédé selon l'une des revendications 15 et 16, caractérisé en ce que l'étape b comprend une étape d'affichage des éléments suivants, en réponse à une entité pointée de type classe : - les classes liées, par une relation prédéterminée dans la base, à la classe pointée, - des zones nom-valeurs pour les attributs de la classe pointée ainsi que les opérateurs liés au type de chacun des attributs.

18. Procédé selon la revendication 17 prise en combinaison avec l'une des revendications 15 et 16, caractérisé en ce que les étapes a et b comprennent une étape d'interrogation du graphe de classe, cette interrogation s'appliquant à la base de données à l'étape a, et aux données elles-mêmes à l'étape b.

<Desc/Clms Page number 27>

19. Procédé selon la revendication 15, caractérisé en ce que l'étape c comprend un stockage préalable des éléments issus de l'étape b.

20. Procédé selon la revendication 19, caractérisé en ce qu'il comprend en outre une étape de combinaison successive de requêtes utilisateurs élémentaires, chacune issue des éléments stockés, selon un opérateur logique prédéterminé pour calculer la requête utilisateur.