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.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Mathematical Physics (AREA)
• Computational Linguistics (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Human Computer Interaction (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Information Transfer Between Computers (AREA)
• User Interface Of Digital Computer (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=8869338

Family Applications (1)

Country Status (4)

Families Citing this family (56)

Family Cites Families (4)

• 2001
  • 2001-11-13 FR FR0114661A patent/FR2832236B1/fr not_active Expired - Fee Related
• 2002
  • 2002-11-05 WO PCT/FR2002/003783 patent/WO2003042864A2/fr not_active Application Discontinuation
  • 2002-11-05 US US10/494,965 patent/US20050210000A1/en not_active Abandoned
  • 2002-11-05 EP EP02788036A patent/EP1444611A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events