WO2003042864A2 - Interface graphique de portail web semantique - Google Patents

Interface graphique de portail web semantique Download PDF

Info

Publication number
WO2003042864A2
WO2003042864A2 PCT/FR2002/003783 FR0203783W WO03042864A2 WO 2003042864 A2 WO2003042864 A2 WO 2003042864A2 FR 0203783 W FR0203783 W FR 0203783W WO 03042864 A2 WO03042864 A2 WO 03042864A2
Authority
WO
WIPO (PCT)
Prior art keywords
request
class
user
manager
database
Prior art date
Application number
PCT/FR2002/003783
Other languages
English (en)
Other versions
WO2003042864A3 (fr
Inventor
Alain Michard
Original Assignee
Inria Institut National De Recherche En Informatique Et En Automatique
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inria Institut National De Recherche En Informatique Et En Automatique filed Critical Inria Institut National De Recherche En Informatique Et En Automatique
Priority to EP02788036A priority Critical patent/EP1444611A2/fr
Priority to US10/494,965 priority patent/US20050210000A1/en
Publication of WO2003042864A2 publication Critical patent/WO2003042864A2/fr
Publication of WO2003042864A3 publication Critical patent/WO2003042864A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2428—Query predicate definition using graphical user interfaces, including menus and forms

Definitions

  • the invention relates to querying a database.
  • the interrogation can be done by a "portal”, which is presented in the form of a graphic interface in relation to a database, whose data are accessible via a query language.
  • a portal on the "web” (or “web) is accessible on a public or private web server, and offers its users various possibilities of research and exploration of an information space made up of collections of resources (term in particular defined by the working group developing the new standards for Internet, 1TETF, "Internet Engineering Task Force").
  • Resources are entities containing data, such as, for example, a directory, a digital document or a set of data extracted from a database, which have a unique URI ("Universal Resource Identifier") and to which can access using a communication protocol.
  • URI Universal Resource Identifier
  • a web-based distributed information system therefore provides access to resources in various formats. Resources are organized in hierarchies of directories located on servers, the number and location of which vary widely depending on the case. Client applications on these servers allow users to explore the contents of directories and view data. Servers and client applications communicate using protocols, the most common of which are the hypertext transfer protocol HTTP ("HyperText Transfer Protocol") and the file transport protocol FTP ("File Transport Protocol").
  • HTTP Hypertext Transfer Protocol
  • FTP File Transport Protocol
  • a web may be public, as the world wide web known as "World Wide Web” or private, as is a business network called "intranet”.
  • semantic web designates a web whose resources are described by a set of variables called “descriptors” or “metadata”. These descriptors are used by programs that assist users to search for information or to filter information available on the Web, according to criteria specific to those users.
  • the set of descriptors authorized in a given semantic web form a conceptual diagram.
  • a conceptual diagram can be "oriented object ", in which case each resource is considered to be an instance of a class (at least), and relationships are defined between that class and the other classes in the conceptual schema. Any resource can then be described using attributes class-specific literals, and properties taking instance objects from other classes.
  • the evaluation of a request chosen by the user from predefined requests the evaluation being carried out by interrogating the database according to the designated request.
  • Neither of these methods allows the user to search for resources by specifying search criteria freely chosen from all possible search criteria in the database.
  • the user is therefore faced with limitations in his possibilities of seeking information.
  • the first method only authorizes the exploration of the hierarchy of categories without it being possible to search for resources, by criteria other than their belonging to these predefined categories.
  • the second method leads to a high noise level due to the polysemy of natural language terms.
  • the third method reduces the search possibilities to requests predefined by the programmer, and requires the latter to carry out specific programming for each request that he wishes to make available to the user.
  • the present invention improves the situation.
  • a computer system comprising a request manager, intended to work with a history manager and a graphical generator to display entities based on data stored in a database.
  • the request manager is able to react to the fact that a displayed entity is "pointed" by the user, by executing on the database an internal request, defined on the basis of a chosen request expression, depending of the type of the entity, and completed according to the entity. This provides new data, from which the display is changed.
  • the history manager is arranged to interact step by step with the request manager to build a user request from successive selections relating to the entities pointed by the user on the graphical interface.
  • the graphical generator is capable of displaying an adapted representation of the results produced by the request manager, according to a predetermined formatting.
  • the request manager is arranged to interrogate in the same way the class graphs describing the database and the class graphs describing the data.
  • the history manager is able to successively combine the elementary requests constructed from stored elements, according to a logical operator, to calculate the user request.
  • the present invention also provides a method for generating a graphical web portal interface, intended for querying a database, characterized in that it comprises the following steps: a. present the user with an initial display drawn from stored data, the entities displayed being of the class or object type, b. in response to the pointing by the user of an entity, to execute an internal request on the data base, defined starting from a query expression chosen, according to the type of the entity, and supplemented according to entity, c. modify the display from the data provided by step b, d. repeat steps b and c until the user decides.
  • the invention also covers a product program, which can be defined as comprising the functions for carrying out steps a to d of the above method, and / or as comprising the functions of the system defined above.
  • FIG. 1b represents instances of classes of the class graph of FIG.
  • FIG. 2 is a block diagram illustrating the web portal, the database management system, the web browser, as well as their interactions;
  • - Figure 3 is a flow chart of the operations used to implement the present invention
  • - Figure 4a is a flow chart of the operations involved in the evaluation of a user request
  • FIG. 4b is a block diagram illustrating the evaluation of a user request
  • FIG. 5 is a flowchart of operations used to implement the management of bookmarks
  • - Figure 6 is a flow chart of operations allowing selection by document management attributes
  • FIG. 7 is an example of a graphical interface, when displaying the class tree of a conceptual diagram
  • FIG. 8 illustrates the display of the structure of a class
  • FIG. 9 is an example of a graphical interface, representing the restriction of an elementary request to attribute values
  • FIG. 10 illustrates the restriction of the user request to values of document resource attributes
  • FIG. 11 shows the display of a list of objects resulting from the evaluation of a user request and an instance object of a class, chosen from this list;
  • FIG. 13 is an example of a platform for implementing the present invention.
  • a semantic web portal can, in fact, be used as a document management tool allowing to carry out a document search on a database.
  • a class graph is extracted from a conceptual diagram.
  • the expression "class graph” is used here for the sake of clarity, note that the corresponding representation in computer science can take different forms, generally non-graphic.
  • a class 100 (100-1 to 100-5) can be qualified by typed attributes 102. It can be linked to subclasses 107 (107-1 to 107-3) by the relation "under -class "110.
  • a daughter class 107 inherits the attributes of its mother class 100.
  • a class 108 (108-1 to 108-2) can be linked to class 100 by a relation labeled 104 (104-1 to 104-7 ), for example uses or exploits. Depending on the case, relation 104 may or may not be transitive.
  • a class graph makes it possible to define instance objects of the classes such as the objects 114 (114-1 to 114-3) of FIG. 1b, linked to their class by the instantiation relationship. Such an object is described using attributes 115 (115-1 to 115-2), and properties 116 (116-1 to 116-3).
  • the documentary resources themselves can be represented as instances of a class "documents" or its subclasses. These resources will therefore be described using the attributes and relationships defined, in the diagram, for this class of documents and for its possible subclasses.
  • the present invention can only be carried out if the conceptual diagram used respects the following restriction: a relation can have only one origin class D and one target class R, the relation being however defined for all subclasses of D and R.
  • a relation can have only one origin class D and one target class R, the relation being however defined for all subclasses of D and R.
  • RDF Resource Description Framework
  • the present invention makes it possible to explore a database constructed according to such a class graph, in an exhaustive manner, in order to find the objects and the resources having the properties specified by the user.
  • FIG. 2 represents the different functional blocks used to implement the present invention.
  • the portal PW includes a web server (SW), a request manager (GR), a history manager (GH), and a graphical generator (GG), all of which communicate with a web browser W and with a system of DBMS database management. Communication between the PW portal and the NW browser uses the HTTP protocol. Communication between the portal PW and the DBMS uses the request language LR.
  • LR is the relational query language RQL ("Relational Query Langage") defined by the FORTH research institute, and we use the relational DBMS PostgreSQL developed and distributed in free software, with an extension allowing the interpretation of the requests formulated in this language.
  • RQL Relational Query Langage
  • DBMS PostgreSQL relational DBMS PostgreSQL developed and distributed in free software, with an extension allowing the interpretation of the requests formulated in this language.
  • another database management system of the relational-object or purely object type
  • another LR query language such as the structured query language SQL-3 (“Structured Query Langage") or the OQL object database query language (“Query Language Object”), proposed by ODMG.
  • the DBMS database management system manages two databases, BDS and BDU, the respective roles of which are described below.
  • BDS and BDU the respective roles of which are described below.
  • DBMS database management system
  • the BDS database contains: - the description of the classes of the conceptual diagram with for each class, the list of its attributes, and the type of its attributes;
  • the structure of the BDS database makes it possible, using the LR language, to find the information that makes up the conceptual diagram, as well as the description of the instance objects of the diagram.
  • the BDU database contains information relating to the portal user, in particular the bookmark requests he has saved in previous sessions, the requests to which he is subscribed, as well as his access rights to subsets of the information system.
  • NW web browser Each user interacts with the device using an NW web browser. It is a popular software such as Internet Explorer from Microsoft, or Navigator from Netscape.
  • the NW browser is able on the one hand to create a graphic and textual representation of a resource described in a standardized language such as HTML (HyperText Markup Langage) or XML (extensible Markup Langage), and on the other hand to issue requests conforming to the HTTP protocol.
  • the designation by the user of a particular graphic entity causes NW to send a specific HTTP request RI.
  • NW has an extension which allows it to interpret the graphic language SVG ("Scalable Vector Graphics", extension distributed by the company Adobe).
  • the invention can be implemented on a SER server machine of the type given purely by way of example in FIG. 13, which includes at least one OSs operating system which supports the PW portal and the base servers. DBMS data, as well as a CPUs processor.
  • SER server machine communicates with CLI client machines users who are PC personal computers, connected to a local or public RES network, supporting the web to which the device gives access.
  • Each client machine comprises a processor CPUc, an operating system OSc, a browser NW, as well as peripherals such as a display screen ECR, a keyboard CL and a pointing device known as a "mouse" SOU.
  • the NW browser interacts with the server S W over the network.
  • the web server S W receives each HTTP request sent by a browser NW, and depending on the content of this request, activates the appropriate procedure of the request manager GR.
  • the server SW passes the parameters contained in the POST request to the request manager GR.
  • the server SW receives the HTML or XML resources generated by the graphic generator GG, and transmits them (RI 1) to the appropriate browser NW.
  • the SW server is also responsible for creating and managing interactive sessions for each user, ensuring that each HTTP request received from an NW browser is allocated to an interaction thread specific to an identified user.
  • the GR request manager ensures the logical processing of requests. It receives the entities pointed out by the user and generates an internal query to query the database on the structure of these entities. On the other hand, it queries the database according to the user request which has been transmitted to it by the history manager GH, a request which corresponds to the search desired by the user. It then transmits the results obtained to the GG graphic generator which displays a corresponding representation.
  • the request manager also manages all interactions with the user, as well as exchanges with the DBMS.
  • the DBMS returns the data corresponding to this request R6.
  • this data is coded in the XML RDF formalism.
  • the graphical generator GG is activated by the request manager GR by the communication R9, each time the latter obtains data from the DBMS in response to a request.
  • the GG graphical generator transforms this data into an XML or HTML representation which can be transmitted to the SW server (RIO) and then to the NW browser (Rll) to be interpreted and displayed there graphically.
  • the graphic generator GG is an XSLT interpreter which receives as input the XML tree produced by the request manager GR, and a predefined XSLT style sheet.
  • the GG processor transforms the XML tree into an HTML or SVG ("Scalable Vector Graphics") resource which is then transmitted to the server SW.
  • the history manager GH manages the history of elementary requests made by a user during an interactive session. Receiving R3 messages from the GR request manager, it updates for each user a data structure representing the history of the requests made by it during the interactive session.
  • the R3 messages relate to the structure of the entities designated by the user, obtained from a query of the database by the request manager GR.
  • Said data structure allows the history manager to calculate a request from a logical combination of elementary requests corresponding to the various elements of the data structure.
  • the history manager GH then returns the calculated user request R4 to the request manager GR which can then submit it to the DBMS for an evaluation (R5).
  • the request manager GR, the history manager GH and the graphic generator GG are written in the Java language, and the communication with the DBMS uses an interface conforming to the industrial standard JDBC ("Java DataBase Connectivity") , defined by the company Sun Microsystems.
  • JDBC Java DataBase Connectivity
  • FIGS. 3 to 6 show an example of the operation of the web portal system.
  • the rectangles with rounded angles represent actions of the user, and the rectangles with right angles represent the processing carried out by the device in response to these actions.
  • FIG. 3 describes the overall operation of the portal.
  • a user accesses the web portal.
  • This step can include interactive operations allowing the identification of the user by any suitable means. For example, we can ask the user to identify himself by entering his username and password. These identification operations are described in known embodiments. Thereafter, it will be assumed that the system has been able to identify the user.
  • the user is therefore authorized to access the initialization step 201.
  • the system initiates an interactive session for the user.
  • An interactive session begins when a user logs in and is identified, and ends when the user requests it or when the fixed duration of the session has elapsed.
  • the system also creates a session history, the role of which will be detailed in step 207.
  • the system searches the BDU database for the bookmarks defined for the user, then searches the BDS database for the hierarchy classes defined in the conceptual diagram. For example, in a particular embodiment, the search in the BDS database is carried out using the following RQL query:
  • the GG graphics generator can then generate a service presentation page (202).
  • Figure 7 shows an example of class presentation in the left frame of the browser. The content of the main right frame depends on each BDS database. The bookmarks appearing in the lower part of the left frame are described below in step 204.
  • the list of classes appearing in the left frame is generated by the graphical generator GG from the RDF resource of which Figure 12 is an extract , and an XSLT style sheet.
  • this HTML resource presenting the class hierarchy can be generated during the first request, then placed in cache memory. It will only be regenerated if the scheme is modified. This optimization, if it takes place, is carried out by the standard functions of the Web server used, independently of the request manager and the graphical generator.
  • step 202 the user can choose between the following actions:
  • step 205 the user selects by pointing one of the classes presented on the screen, this presentation being able to result from step 202 or from step 208.
  • the history manager GH updates the request history specific to the session and to the user.
  • This history makes it possible to determine at all times what is the request resulting from the boolean combination "AND" of all the choices made by the user during the interactive session.
  • One possibility is to represent this history as a dictionary of lists where the key is a transaction identifier in the current session, a new transaction being created each time the user selects a new class and where each item is a list:
  • the first element of this list is the identifier of the selected class.
  • - the second element can be: - the identifier (URI) of the property defined in the conceptual diagram between the current class selected and the class selected in the previous transaction, the direction of this property, ie the fact that one or the other of these two classes either origin or target of the relation not being taken into account. - a null value (represented in this document by the symbol Nil), if the current class has been selected in the hierarchy presented in the left frame of the display window, in one of the following cases:
  • the current class is the first one selected during the interactive session, 2) the user has chosen a class which has no relation to the previously selected class,
  • triples ⁇ name, operator, value ⁇ which describe the constraints of attribute values defined by the user for the selected class. It will be noted that these triplets are only created when the updating of the history results from step 211. When the updating of the history results from a class selection made in step 212, without the user has not yet specified attribute values, the entry created in the dictionary does not contain triples.
  • step 208 the request manager searches the BDS database for the list of attributes and properties of the selected class and its superclasses, the type of these attributes, the classes defining the value domains of the properties whose selected class is origin.
  • this information can be obtained by the following RQL query:
  • Equipment is assumed to be the identifier of the selected class.
  • FIG. 8 shows an example of a graphic presentation thus generated, after the user has selected the class "Equipment” in step 205.
  • the "Value”, “Date_acqui”, and “Type” buttons indicate to the user that the instances of the "Equipment” class have attributes of this name for which they can, he wishes, choose a value to further restrict the selection of these instances.
  • the "Supplier”, “Project”, “Team” and “Organization” buttons indicate to the user that these classes have a property which links them to the "Equipment” class. The user can select these classes using these buttons, to restrict the current selection, as described in step 205.
  • step 208 the user has the choice between the following options: - select one of the classes presented to him (step 205), namely a class linked to the current class by a property. Choosing this option will result in a change of current class;
  • step 211 select a class in the class hierarchy presented in the left frame of the viewing window.
  • step 210 request the display of the instance objects of the previously selected class
  • step 209 when the user activates the cancellation command, the history manager GH deletes from the session history the entry corresponding to the last selection made.
  • the GR request manager finds the structure of the previously selected class which happens to be that appearing in the last entry in the history thus updated.
  • the graphical generator GG can therefore produce a display of the structure of this class exactly as it was done in step 205 above.
  • the user decides to specify target values for the attributes of the instance objects of the current class that he wishes to select.
  • Figure 9 shows an example screen presented to a user during this step.
  • the system goes to step 207 to update the request history, the structure of which has been described above. During this update, triples ⁇ attribute name, operator, value ⁇ will be created in the entry corresponding to the current transaction for each of the attributes for which the user has specified a value.
  • step 210 the user requests the display of the instance objects of the current class, possibly selected on the basis of the attribute values chosen during step 212.
  • the request manager GR consults the history manager GH and obtains the tuple representing the last transaction. This tuple indicates the current class that has been selected, and if applicable, the attributes of this class for which the user has specified particular values. This tuple makes it possible to form a request whose semantics is:
  • oxx An ... Am are attributes defined for class C, C is the name of the current class, and ⁇ Ax, OP, Vi ⁇ represents a triplet ⁇ Attribute, Operator, Value ⁇ resulting from a choice by the user in step 212.
  • the current selection comprises several triplets, these are combined by the boolean operator "AND" performing the intersection of the subsets of objects selected by each of the triplets.
  • the choice of presentation attributes An ... Am may vary for each embodiment of the device and for each class of objects. This choice is checked and determined by the system administrator during system installation. In the examples of FIGS. 7 to 12, the objects have been represented by their symbolic name.
  • the query thus formed in the LR query language is submitted to the DBMS managing the BDS database.
  • the returned results are then transmitted to the GG graphics generator, which produces a presentation in HTML with an adequate layout.
  • FIG. 11 illustrates a possible presentation of an object thus selected.
  • step 211 the user requests the display of the list of documentary resources corresponding to the current selection.
  • the request manager GR receives the request for calculating the current selection of documentary resources, it activates the appropriate procedure of the history manager GH.
  • FIG. 4a illustrates the different stages of the evaluation of a user request.
  • the history manager GH selects a line from the request history in step 2110, from which it calculates the corresponding elementary request. , in the LR query language. It then temporarily stores this request in the variable REQ_EL (1).
  • the history manager then initializes a variable REQ (l), by assigning it the value REQ_EL (1), in step 2113.
  • the history manager GH repeats the following steps, for all the lines i of the request history, and this, until all the lines of the history have been treated:
  • step 2110 it selects a line i of the request history and constructs the corresponding elementary request REQ_EL (i), in step 2111.
  • Each line i of the history contains the characteristics of a corresponding transaction i to the class Ci pointed by the user.
  • the history manager calculates a REQ request (i), by combination according to a logical operator op determined in step 2111 of the elementary request REQ_EL (i) and of the previous request REQ (i) .
  • REQ (n) indeed contains the user request corresponding to the search documentary that the user wishes.
  • the history manager then goes to step 2113 where it transmits the last computed request REQ (n) to the request manager GR.
  • Step 2111 includes a preliminary step of analyzing the items of the history, to determine the elementary request REQ_EL (i) which corresponds to each transaction i, as well as the logical operator op of step 2113. This analysis is proceeds according to the following principles:
  • the elementary request relating to this class corresponds to "the selection of the set of digital documents having a defined relationship with the instances of the unbound class Ci".
  • This class Ci will therefore be used at step 2113, to extend the selection of digital documents, by including those having a defined relationship with the instances of the unbound class Ci.
  • the system generates a corresponding elementary request REQ_EL (i), which will be combined with REQ (i-l) by a logical operator op "OR";
  • the elementary request relating to this class corresponds to "the selection of all the digital documents whose attributes respect the value constraints indicated by the triplets of the history".
  • This class Ci will therefore be used in step 2113 to restrict the selection of documents to those whose attributes respect the value constraints indicated by the triples of this transaction i. This restriction is carried out by generating a corresponding elementary request REQ_EL (i), which will be combined with REQ (i-l) by a logical operator op "AND";
  • the elementary request relating to this class corresponds to "the selection of the set of digital documents having a defined relation with the instances of the linked class Ci ".
  • This class Ci will therefore be used in step 2113, to restrict the selection of digital documents having a defined relationship with the instances of the class Cl, the class Cl being the class selected during the first transaction of this chained list of transactions. This restriction is further achieved by generating a corresponding elementary request REQ_EL (i), which will be combined with REQ (i- 1) by a logical operator op "AND".
  • FIG. 4b represents the modules necessary for the evaluation of a request.
  • the converter / analyzer block CA converts the characteristics of transaction i, trans (i) stored in the history into an elementary request REQ JEL (i) formulated in query language. This block also determines the logical operator op as a function of trans (i).
  • the logical function block FL then calculates the new value REQ (i) from the inputs op, REQ_EL (i) and REQ (i-1) calculated in the previous step.
  • the history manager sends REQ (n) to the request manager GR.
  • the current selection of documentary resources is the result of the request whose semantics, expressed in pseudo-natural language is:
  • the present invention therefore allows the user to create, by simple successive interactive manipulations, complex queries to find documentary resources in a database.
  • the user request resulting from the flowchart described above makes it possible not only to find the identifiers of the target resources, but also a certain number of attributes of these resources, such as for example the title and the date of publication. , in order to present the user with a detailed display of the list of resources found.
  • the choice of these presentation attributes is specified in a resource external to the portal application code, to allow them to be modified independently of the portal program.
  • the request manager GR When the request manager GR receives the user request REQ (n), it submits it, in step 2114 of FIG. 4a, to the DBMS which returns the list of instances of the class "Documents" satisfactory to the terms of the request. This list is finally transmitted to the graphic generator GG, in step 2115, which performs a formatting allowing it to be displayed by the browser NW.
  • the list of documentary resources may be formed of titles, which are each the anchor of a hypertext link whose crossing causes the display of the resource itself, using the appropriate application chosen according to the format of the resource.
  • Step 213 of FIG. 3 allows the user to store the current request resulting from the non-canceled selections made previously in the interactive session.
  • the user can trigger this operation by pointing to the arrow-shaped button located immediately to the right of the "Bookmarks" title in the left frame of the browser.
  • a dialog box is presented to him asking him to choose a name for this current request. This name will be used later to present this request in the list of bookmarks as it appears in the exemplary embodiments of FIGS. 7, 8 and 9.
  • the request stored at step 213 is the same as that which was calculated and evaluated in step 211.
  • the current request is calculated according to the same algorithm as that used in step 211. However, the request is not transmitted to the BDS database for evaluation, but it is stored in the BDU database, with the symbolic name chosen by the user, the date and time of its creation. This request can later be evaluated. It can also be combined with other stored requests to form new requests, as described in Figure 5. A user with the necessary permissions can create a bookmark on behalf of a third-party user.
  • FIG. 6 illustrates the implementation of a selection of digital documents by means of predefined bookmarks.
  • a user having stored requests in the form of bookmarks can decide to form new requests by combining some of these stored requests. For this, he can choose a bookmark in step 204, then a logical operator "ET7OU" in step 2042, and finally a second bookmark at step 2043.
  • These successive designations characterize a new request which corresponds to:
  • the result of the new query is the intersection of the result sets of the two preexisting queries.
  • the result of the new query is the union of the result sets of the two preexisting queries.
  • the user can again form a new request by combining that which has just been created with another existing request.
  • the user can thus gradually define queries by intersections or unions of a selected number of queries.
  • the user can evaluate a saved bookmark at any time during an interactive session. If he has just constructed and named a new request using a bookmark from preexisting requests (FIG. 4), he can directly request the evaluation of the new request (step 2040); otherwise it can choose a bookmark in step 204, then request the evaluation of the request thus designated. In both cases, these operations cause the evaluation of the request stored under the name of the corresponding bookmark in the BDU database.
  • step 204 In the case where the user accesses the evaluation of a request from step 204, two scenarios may arise: - if step 204 is the first step performed in the current interactive session, the request is evaluated and the results displayed.
  • step 204 is triggered during the interactive session when selections have created a current request, a message asks the user to confirm the abandonment of the current request in favor of the request stored under the bookmark. If the user confirms his choice, the current request is abandoned, the session history is deleted and step 204 continues. If the user does not confirm his choice, step 204 is abandoned.
  • a user can subscribe to a stored bookmark and request to receive the results of the corresponding request by e-mail, this request being re-evaluated at a regular interval chosen by the user.
  • step 206 The user can at any time carry out step 206 by which he specifies attribute values which the digital documentary resources sought must respect.
  • This step is described in detail in Figure 6.
  • the user selects the parent class of these resources, presented in the example of Figures 7 to 11 under the name "Documents".
  • Figure 10 illustrates an example of a graphical interface for specifying the attributes of these resources.
  • the attributes appearing in this graphical interface could differ in each realization, since they are defined in the conceptual diagram used.
  • This graphical interface is therefore generated dynamically, in step 2060 of FIG. 6, by methods identical to those described in steps 201 and 202, only the structure request being here different.
  • the attributes presented are found in the BDS database using the following RQL query:
  • step 2061 of FIG. 6 the result of this request is formatted by the graphic generator GG as indicated in step 202 of FIG. 3, to display zones ⁇ attribute name, Operator, Value ⁇ for all the attributes of the "Documents" class.
  • step 2062 of FIG. 6 the user can designate and validate choices of attribute values.
  • a particular entry is then created in the session history in step 2063.
  • This entry comprises as many triples ⁇ Attribute, Operator, Value ⁇ as the user has specified constraints on the attributes. If such an entry exists in a session history, it is used in step 211 to restrict the selection of resources sought, without the position of this entry in the history being taken into account in the formation of the request. In other words, the choices of attribute values made during step 206 will have the same semantics whatever the moment in the interactive session at which the user performs step 206.
  • the user can either directly evaluate the user request (step 211), or choose a new class (step 205).
  • step 203 has the possibility of ending the current interactive session, by selecting step 203.
  • step 203 is triggered during an interactive session while selections are made. have created a current request, and while the last operation carried out is not a step 213, a message asks the user if he wishes to confirm the abandonment of the current request, or to perform step 213.
  • the invention is not limited to the embodiment described above by way of example. It can extend to other variants of resource exploration. It can in particular be used to build project management applications, for the use of a company or a group of companies. It can also be used to build document management and search applications for use by communities of users on the public web.
  • the invention does not make any assumptions about the methods used to create the instance objects of the classes, and to describe the documentary resources using these objects and specific attributes. It does not introduce limitations in the types of documentary resources managed. These can be files of all formats, collections or directories of files or directories, mailboxes of electronic mail, threads of discussion, whiteboards of systems of cooperation, etc.
  • the invention is perfectly compatible with an organization of the web into several segments or subsets, each segment being described in a BDS database.
  • the application proceeding to the complete or partial replication of the data specific to each segment in a centralized server or in multiple servers themselves distributed.
  • Such an architecture can offer users the possibility of searching for resources as has been described, either at the level of a segment or at the level of the complete web. It is also possible, according to the same principle, to organize the indexing of the web according to a hierarchy of segments at several levels.
  • the present invention also relates to the software code which it involves, particularly when it is made available on any medium readable on a computer.
  • “computer-readable medium” covers a storage medium, for example magnetic or optical, as well as a means of transmission, such as a digital or analog signal.
  • the invention relates only to the method of interrogation of this or these servers, and therefore does not claim to constitute a solution to all of the difficulties associated with such a hierarchical organization of the Web.

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

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, 1TETF, "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étadonnees" . 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é 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 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 1 ' 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. 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 lb 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'apas d'objection à la reproduction àl'identique par quiconque de ce document de brevet, tel qu'il apparaît dans les dossiers et/ou publications 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 lb, 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. 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 parle 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 W 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 deuxbases 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: - 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 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 S W à travers le réseau. Le serveur web S W 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 RI 0, 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. Le générateur graphique GG est activé par le gestionnaire de requêtes GR par la communication 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 (Rll) 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. On se réfère à la figure 3 qui décrit le fonctionnement global du portail. À 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:
sélect C, superclassof^ζC) from ClassfC}
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 F 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 //' 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. 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: - 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:
sélect *from {:Equipement}@P{:$$Y} where $$YinLiteral OR $$Yin 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 S VG 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 "Equipement" à l'étape 205. Les boutons "Valeur", "Date_acqui", 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. 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 à la transaction courante pour chacun des attributs pour lequel l'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
{Al, OP, Vi} ET {A2, OP, Vj}"
oxx 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. 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 à 1 ' é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 REQ_EL(1). Le gestionnaire d'historique initialise ensuite une variable REQ(l), en lui affectant la valeur REQ_EL(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 REQ_EL(i) correspondante, à 1 ' é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 REQ_EL(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 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 REQ_EL(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 à Y é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 REQ_EL(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 REQ_EL(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 Cl, la classe Cl é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 une requête élémentaire correspondante REQ_EL(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 REQ JEL(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, REQ_EL(i) et REQ(i-l) 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:
IT001 Equipement nil {Valeur > 10000} IT002 Projet Utilise {Localisation = Rocquencourt}
IT003 Personne nil {nom = *Smith) IT004 Documents nil {LastModified > 01:01: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 pour valeur "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. 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 1er 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 exρr4) ET expr5)] OU exprό, où, exprl = «D a un attribut "LastModified " dont la valeur est une date postérieure au 1er 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" », exprδ = «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 "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 delà 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 "ET7OU" à l'étape 2042, et enfin un deuxième signet à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. 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:
sélect *from {:Documents}@P{:$$Y} where $$Yin Literal
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. 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 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ère- ment 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

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, - 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 et5, 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 par l'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. 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-valeurs- opérateurs" pour les attributs documentaires, enré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.
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.
PCT/FR2002/003783 2001-11-13 2002-11-05 Interface graphique de portail web semantique WO2003042864A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP02788036A EP1444611A2 (fr) 2001-11-13 2002-11-05 Interface graphique de portail web semantique
US10/494,965 US20050210000A1 (en) 2001-11-13 2002-11-05 Semantic web portal graphic interface

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0114661A FR2832236B1 (fr) 2001-11-13 2001-11-13 Interface graphique de portail web semantique
FR01/14661 2001-11-13

Publications (2)

Publication Number Publication Date
WO2003042864A2 true WO2003042864A2 (fr) 2003-05-22
WO2003042864A3 WO2003042864A3 (fr) 2003-12-04

Family

ID=8869338

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/003783 WO2003042864A2 (fr) 2001-11-13 2002-11-05 Interface graphique de portail web semantique

Country Status (4)

Country Link
US (1) US20050210000A1 (fr)
EP (1) EP1444611A2 (fr)
FR (1) FR2832236B1 (fr)
WO (1) WO2003042864A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7490094B2 (en) 2004-05-06 2009-02-10 International Buisness Machines Corporation Importance of semantic web resources and semantic associations between two resources

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7526425B2 (en) 2001-08-14 2009-04-28 Evri Inc. Method and system for extending keyword searching to syntactically and semantically annotated data
US7584208B2 (en) 2002-11-20 2009-09-01 Radar Networks, Inc. Methods and systems for managing offers and requests in a network
US7640267B2 (en) * 2002-11-20 2009-12-29 Radar Networks, Inc. Methods and systems for managing entities in a computing device using semantic objects
US7433876B2 (en) 2004-02-23 2008-10-07 Radar Networks, Inc. Semantic web portal and platform
WO2006001008A2 (fr) * 2004-06-24 2006-01-05 Amir Lavi Systeme et procede facilitant la recherche sur un reseau de donnees
WO2006019016A1 (fr) * 2004-08-18 2006-02-23 Sony Corporation Dispositif d’éclairage de fond et dispositif d’affichage couleur à cristaux liquides
US20060112130A1 (en) * 2004-11-24 2006-05-25 Linda Lowson System and method for resource management
US7672968B2 (en) * 2005-05-12 2010-03-02 Apple Inc. Displaying a tooltip associated with a concurrently displayed database object
US20060282403A1 (en) * 2005-05-24 2006-12-14 Microsoft Corporation Selective collection, filtering and processing of transactions in multiple transaction classes
WO2007038844A1 (fr) * 2005-10-06 2007-04-12 Smart Internet Technology Crc Pty Ltd Procedes et systemes pour faciliter l'acces a un schema
EP1949273A1 (fr) 2005-11-16 2008-07-30 Evri Inc. Extension de recherche par mot cle a des donnees annotees syntaxiquement et semantiquement
US20070240103A1 (en) * 2006-03-29 2007-10-11 Beaton Murray J Use of UML state machines to model portal applications
US7797312B2 (en) * 2006-04-06 2010-09-14 International Business Machines Corporation Database query processing method and system
US7680787B2 (en) * 2006-04-06 2010-03-16 International Business Machines Corporation Database query generation method and system
US20080155008A1 (en) * 2006-05-09 2008-06-26 Lockheed Martin Corporation Track sort and select system
US8869066B2 (en) 2006-07-06 2014-10-21 Addthis, Llc Generic content collection systems
US8924838B2 (en) 2006-08-09 2014-12-30 Vcvc Iii Llc. Harvesting data from page
US8056092B2 (en) * 2006-09-29 2011-11-08 Clearspring Technologies, Inc. Method and apparatus for widget-container hosting and generation
US20080082627A1 (en) * 2006-09-29 2008-04-03 Allen Stewart O Method and Apparatus for Widget Container/Widget Tracking and Metadata Manipulation
US8239491B1 (en) * 2006-10-30 2012-08-07 Google Inc. Content request optimization
US7657611B2 (en) * 2006-10-30 2010-02-02 Google Inc. Content request optimization
US7899819B2 (en) * 2007-03-02 2011-03-01 Ehud Ben-Reuven Financial line data-base
US8266274B2 (en) 2007-03-06 2012-09-11 Clearspring Technologies, Inc. Method and apparatus for data processing
US9009728B2 (en) 2007-03-06 2015-04-14 Addthis, Inc. Method and apparatus for widget and widget-container distribution control based on content rules
US8954469B2 (en) * 2007-03-14 2015-02-10 Vcvciii Llc Query templates and labeled search tip system, methods, and techniques
US8204856B2 (en) * 2007-03-15 2012-06-19 Google Inc. Database replication
US20100174692A1 (en) * 2007-03-15 2010-07-08 Scott Meyer Graph store
US20100121839A1 (en) * 2007-03-15 2010-05-13 Scott Meyer Query optimization
US20090024590A1 (en) * 2007-03-15 2009-01-22 Sturge Timothy User contributed knowledge database
US20080256095A1 (en) * 2007-04-10 2008-10-16 Apertio Limited Adaptation in network data repositories
US8782085B2 (en) * 2007-04-10 2014-07-15 Apertio Limited Variant entries in network data repositories
US9112873B2 (en) * 2007-04-10 2015-08-18 Apertio Limited Alias hiding in network data repositories
US8402147B2 (en) * 2007-04-10 2013-03-19 Apertio Limited Nomadic subscriber data system
US20090076887A1 (en) * 2007-09-16 2009-03-19 Nova Spivack System And Method Of Collecting Market-Related Data Via A Web-Based Networking Environment
US8209378B2 (en) 2007-10-04 2012-06-26 Clearspring Technologies, Inc. Methods and apparatus for widget sharing between content aggregation points
AU2008312423B2 (en) * 2007-10-17 2013-12-19 Vcvc Iii Llc NLP-based content recommender
US8594996B2 (en) 2007-10-17 2013-11-26 Evri Inc. NLP-based entity recognition and disambiguation
CN101605141A (zh) * 2008-08-05 2009-12-16 天津大学 基于语义的Web服务关系网络系统
US20100107100A1 (en) * 2008-10-23 2010-04-29 Schneekloth Jason S Mobile Device Style Abstraction
US20110093500A1 (en) * 2009-01-21 2011-04-21 Google Inc. Query Optimization
WO2010120925A2 (fr) 2009-04-15 2010-10-21 Evri Inc. Recherche et optimisation de recherche à l'aide d'un modèle d'identifiant de position
WO2010120929A2 (fr) 2009-04-15 2010-10-21 Evri Inc. Génération de résultats de recherche personnalisés par l'utilisateur et construction d'un moteur de recherche à sémantique améliorée
US8200617B2 (en) 2009-04-15 2012-06-12 Evri, Inc. Automatic mapping of a location identifier pattern of an object to a semantic type using object metadata
US10628847B2 (en) 2009-04-15 2020-04-21 Fiver Llc Search-enhanced semantic advertising
US20100268600A1 (en) * 2009-04-16 2010-10-21 Evri Inc. Enhanced advertisement targeting
CA2779208C (fr) * 2009-10-30 2016-03-22 Evri, Inc. Perfectionnements apportes a des resultats de moteur de recherche par mot-cle a l'aide de strategies de requete ameliorees
US9710556B2 (en) 2010-03-01 2017-07-18 Vcvc Iii Llc Content recommendation based on collections of entities
US8645125B2 (en) 2010-03-30 2014-02-04 Evri, Inc. NLP-based systems and methods for providing quotations
US8306858B2 (en) 2010-07-14 2012-11-06 Google Inc. Consolidated content item request for multiple environments
US8838633B2 (en) 2010-08-11 2014-09-16 Vcvc Iii Llc NLP-based sentiment analysis
US9405848B2 (en) 2010-09-15 2016-08-02 Vcvc Iii Llc Recommending mobile device activities
US8725739B2 (en) 2010-11-01 2014-05-13 Evri, Inc. Category-based content recommendation
US9116995B2 (en) 2011-03-30 2015-08-25 Vcvc Iii Llc Cluster-based identification of news stories
US10223637B1 (en) 2013-05-30 2019-03-05 Google Llc Predicting accuracy of submitted data
US9516130B1 (en) * 2015-09-17 2016-12-06 Cloudflare, Inc. Canonical API parameters

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0851368A2 (fr) * 1996-12-26 1998-07-01 Sun Microsystems, Inc. Description de requêtes avancée et autoenseignante

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6012053A (en) * 1997-06-23 2000-01-04 Lycos, Inc. Computer system with user-controlled relevance ranking of search results
US6463426B1 (en) * 1997-10-27 2002-10-08 Massachusetts Institute Of Technology Information search and retrieval system
US7117434B2 (en) * 2001-06-29 2006-10-03 International Business Machines Corporation Graphical web browsing interface for spatial data navigation and method of navigating data blocks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0851368A2 (fr) * 1996-12-26 1998-07-01 Sun Microsystems, Inc. Description de requêtes avancée et autoenseignante

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ARPINAR I B ET AL: "MOODVIEW: AN ADVANCED GRAPHICAL USER INTERFACE FOR OODBMSS" SIGMOD RECORD, ASSOCIATION FOR COMPUTING MACHINERY, NEW YORK, US, vol. 22, no. 4, 1 décembre 1993 (1993-12-01), pages 11-18, XP000453415 *
LI W-S ET AL: "WEBDB HYPERMEDIA DATABASE SYSTEM" IEICE TRANSACTIONS ON INFORMATION AND SYSTEMS, INSTITUTE OF ELECTRONICS INFORMATION AND COMM. ENG. TOKYO, JP, vol. E82-D, no. 1, janvier 1999 (1999-01), pages 266-277, XP000831463 ISSN: 0916-8532 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7490094B2 (en) 2004-05-06 2009-02-10 International Buisness Machines Corporation Importance of semantic web resources and semantic associations between two resources

Also Published As

Publication number Publication date
FR2832236A1 (fr) 2003-05-16
FR2832236B1 (fr) 2004-04-16
US20050210000A1 (en) 2005-09-22
EP1444611A2 (fr) 2004-08-11
WO2003042864A3 (fr) 2003-12-04

Similar Documents

Publication Publication Date Title
WO2003042864A2 (fr) Interface graphique de portail web semantique
US5956720A (en) Method and apparatus for web site management
Kacprzyk et al. Computing with words in intelligent database querying: standalone and Internet-based applications
US8924408B2 (en) Automatic generation of database invocation mechanism for external web services
US7792817B2 (en) System and method for managing complex relationships over distributed heterogeneous data sources
US7376698B2 (en) System for preserving scripting objects and cloning the objects to a new document in response to a reload of the new document
US8489474B2 (en) Systems and/or methods for managing transformations in enterprise application integration and/or business processing management environments
US8510682B2 (en) Unifying navigation model
US8140545B2 (en) Data organization and evaluation using a two-topology configuration
US7421699B2 (en) Service meta model for an enterprise service architecture
US20030191769A1 (en) Method, system, and program for generating a program capable of invoking a flow of operations
US20030093436A1 (en) Invocation of web services from a database
US20030004931A1 (en) Managing results of federated searches across heterogeneous datastores with a federated result set cursor object
US20060173873A1 (en) System and method for providing access to databases via directories and other hierarchical structures and interfaces
US20080071734A1 (en) Iterative data analysis enabled through query result abstraction
JP2004362595A (ja) データベースオブジェクトスクリプト生成方法およびシステム
AU2002258640A1 (en) Method and apparatus for intelligent data assimilation
EP1435047A2 (fr) Procede et appareil d&#39;assimilation intelligente de donnees
JP2000090076A (ja) ドキュメント管理方法およびドキュメント管理システム
US7765203B2 (en) Implicit context collection and processing
US20070203889A1 (en) System and method for configuring search results using a layout editor
Bouguettaya et al. Supporting dynamic interactions among web-based information sources
US20060224633A1 (en) Common Import and Discovery Framework
Kacprzyk et al. Using Fuzzy Quering over the Internet to Browse through Information Resources
Wang Distributed geographic information systems on the Web

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 10494965

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2002788036

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002788036

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2002788036

Country of ref document: EP