WO2001095146A2 - Systeme et procede permettant l'importation semi-automatique de fragments de ressources d'informations - Google Patents

Systeme et procede permettant l'importation semi-automatique de fragments de ressources d'informations Download PDF

Info

Publication number
WO2001095146A2
WO2001095146A2 PCT/FR2001/001731 FR0101731W WO0195146A2 WO 2001095146 A2 WO2001095146 A2 WO 2001095146A2 FR 0101731 W FR0101731 W FR 0101731W WO 0195146 A2 WO0195146 A2 WO 0195146A2
Authority
WO
WIPO (PCT)
Prior art keywords
fragment
page
links
information
user
Prior art date
Application number
PCT/FR2001/001731
Other languages
English (en)
Other versions
WO2001095146A3 (fr
Inventor
Enrico MAÏM
Original Assignee
Maim Enrico
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
Priority claimed from FR0007245A external-priority patent/FR2805374B1/fr
Priority claimed from FR0007252A external-priority patent/FR2805376B1/fr
Priority claimed from PCT/FR2000/003157 external-priority patent/WO2001035269A2/fr
Application filed by Maim Enrico filed Critical Maim Enrico
Priority to AU2001295651A priority Critical patent/AU2001295651A1/en
Priority to PCT/FR2001/003043 priority patent/WO2002029625A2/fr
Publication of WO2001095146A2 publication Critical patent/WO2001095146A2/fr
Publication of WO2001095146A3 publication Critical patent/WO2001095146A3/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/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion

Definitions

  • the main objective of the present invention is to be able to compose information resources, in particular documents, semi-automatically, organized according to a tree structure of references on fragments of information in particular distant, as well as different systems and methods for managing such resources.
  • the user feeds a “personal portal” by assembling, by simple drag-and-drop, fragments of the interesting web pages that he discovers on the Web and, as this personal portal is enriched , the tool automatically suggests new and increasingly relevant fragments of web pages to him;
  • each user benefits from the discoveries of other users: by simple drag-and-drop, or at the automatic suggestion of the system, the user can draw from the pages of other personal portals fragments that interest him.
  • a first aspect of a first object of the present invention aims to make it possible to compose an information resource, in particular of a document, organized according to a tree structure of nodes, according to the following steps:
  • said node for at least one node of the resource, arranging said node as a fragment comprising said node as the root node of the fragment and all the sub-nodes of said root node,
  • the present invention aims to make it possible to compose an information resource, organized according to a tree structure of nodes, according to the following steps:
  • said node for at least one node of the resource, arranging said node as a fragment comprising said node as the root node of the fragment and all the sub-nodes of said root node,
  • the method comprises the following step: - when composing an upstream fragment such that the latter contains at least one additional subfragment, compose the downstream fragment by including said additional subfragment.
  • the method further comprises the following step:
  • composition in said downstream fragment of an additional subfragment includes an indication of a suggested mode of said new subfragment
  • composition in said downstream fragment of an additional subfragment is carried out provided that an indication of an accepted mode is associated with said additional subfragment in the upstream resource;
  • the method further comprises the step of selecting the most relevant subfragments from the additional subfragments before suggesting them in the downstream subfragment.
  • the invention proposes a system for composing an information resource, in particular a document, organized according to a tree structure of nodes,
  • Some preferred but non-limiting aspects include the following:
  • the system is characterized by the fact that the resource includes at least one node which is included in a first downstream fragment and which, associated with it, an update reference to another upstream fragment, to form a second downstream fragment which is sub-fragment of said first downstream fragment, and that said means make it possible to compose said second downstream fragment from the content of said other upstream fragment;
  • the system comprises means for arranging at least one node of the resource as a fragment;
  • the system comprises means for associating, with at least one fragment of the resource, an update reference to an upstream fragment, to form a downstream fragment;
  • the system comprises means for associating, with at least one sub-node of a downstream fragment, a reference of non-updating to the corresponding sub-node of the corresponding upstream fragment;
  • the system comprises means for associating, with at least one node included in a first downstream fragment, an update reference to another upstream fragment, to form a second downstream fragment which is sub-fragment of said first downstream fragment.
  • Another object of the present invention relates to a system and a method making it possible to manipulate, in particular to reproduce (import) from one site to another, fragments of XML sources representing for example information contents or services, presented for display on the screen through style sheets, acting only on their display presentation on the screen.
  • This object of the invention allows a new use of the content of sites on the Web.
  • a fragment of XML source allowing for example to present a service on the Web can be reproduced from one site to another, by the owners of the respective sites, and automatically configured according to the specificities of the host site.
  • graphic objects are used as “handles” and / or “targets” associated with the presentation of the fragments.
  • a handle is used to catch a fragment, in particular to drag and drop it where you want to reproduce it, this place being indicated graphically by a target.
  • the imported fragment can be automatically adapted, or even refused, to satisfy the constraints or preferences of the target container, and the conditions of an agreement (or contract) to be concluded if necessary between the owners of the sites of on either side of the transfer, can be proposed automatically first to the user who performs the drag and drop, then and asynchronously (in particular by means of an electronic mail) to the other party.
  • Web page XML sources are automatically decomposed
  • microstructures in atomic (indivisible) units, called microstructures
  • the macrostructure can advantageously be placed in a server different from that where the microstructures reside.
  • the management of the macrostructure can thus be entrusted to a third party, in particular to a "trusted third party" freely chosen by the users who share the same fragments of documents. Document management, which includes multiple references to fragments of other documents, is thus made more reliable.
  • this object of the invention provides a method for handling documents which can be used in particular for collaborative work through a network such as the Internet, allowing the user to manipulate fragments of said documents, said documents being on the one hand in their raw form consisting of a tree structure composed of nodes having information and attributes and represented in particular in XML language, said documents being on the other hand presented for display or other interface, in particular in HTML language and scripts, after transformation by programs , rewriting rules or style sheets, in particular in XSL language, characterized in that it comprises the following steps: (a) interactive means, making it possible to manipulate said fragments in particular with a pointing device such as a mouse, are assembled dynamically at the time of the construction of said presentation from the raw form of a document for display in manipulation mode ;
  • step (c) consequently the system updates in said document in its raw form each fragment which gave rise in step (a) to the assembly of means used in step (b).
  • the method comprises before step (a) a step in which the user requests a display presentation in manipulation mode.
  • Said request is made using a button or similar device.
  • Said button or similar device is used to request the version in manipulation mode of a presentation currently displayed in normal mode.
  • Said button or similar device is presented in the form of a graphic object forming part of said display presentation in normal mode, said graphic object being activatable by means of a pointing device such as the mouse to switch to manipulation mode.
  • said presentation commonly displayed in normal mode.
  • Said switching to the manipulation mode is carried out for a region selected by the user if necessary or if no region has been selected for the entire said presentation.
  • Said button or similar device is used in combination with the action which would have made it possible to submit a display request in normal mode.
  • Said request is made in a very slightly different way from that for obtaining the display presentation in normal mode, said difference consisting notably in adding a set of characters, such as for example the word "admin” preceded by the character "/",
  • step (a) said interactive means are implemented after knowledge of the system
  • step (b) said manipulation aims to edit the content of a fragment and results in step (c) in the modification of said content.
  • step (b) said manipulation aims to move or reproduce a fragment, in particular from one website to another, and in that it results in step (c) in the insertion of said fragment and / or a reference to said fragment under a node having a delimitation attribute (container).
  • Said interactive means include graphic objects usable with a pointing device such as in particular a mouse such that step (b) is carried out by a drag and drop operation of a first graphic object (handle) associated with a first fragment - in particular to reproduce or move - on a second graphic object (target) associated with a second fragment, step (c) said updating - in particular the insertion of said fragment to be reproduced or moved - takes place at least at the location determined by the properties of said second graphic object (target).
  • a pointing device such as in particular a mouse
  • each document in its raw form is broken down into a macrostructure and one or more microstructures of which at least one reference on each of them is found in said macrostructure and the process comprises, before step (a), a step consisting in recomposing , from said macrostructure and said microstructures, the document in its raw form.
  • Said decomposition comprises the following stages:
  • delimitation attributes each capable of distinguishing the fragments represented by each node whose parent node has said delimitation attribute
  • said decomposition comprises the following steps: during the creation of said original document, insert therein delimitation attributes each capable of grouping downward nodes with a parent node of said descendant nodes, extracting the information located at the grouped nodes , said extraction being carried out first on said document and then recursively on the information itself extracted, and create on the one hand a set of microstructures made up of the remains of the extracted information to which have been added attributes indicating at which positions were located the information extracted downstream in said recursive processing and on the other hand a document macrostructure constituted by a tree structure coarser than said document tree structure, in which said parent nodes corresponding to groupings are replaced by references to said information ons extracted, indicating the position of said extracted information in the structure, and in which said descendant nodes which are not themselves parent nodes are absent.
  • Step (c) includes actions in which one or more new references
  • Said microstructures are atomic.
  • the information extracted at each level in said recursive processing constitutes an accessible fragment whose structure is represented in said macrostructure, and said fragment consists of a microstructure or of several nested microstructures.
  • Said recomposition before step (a) can have the effect of inserting additional attributes on the nodes but in no case does it have the effect of modifying the structure of the document nodes in its raw form.
  • step (a) of the process the system transforms said document into XHTML except all the fragments of which a local style is preferred; these are copied in full so that their transformation can be carried out during a next pass within the framework of an iterative process in which at each pass, the fragments which have not yet been transformed into XHTML are transformed in their turn, until all the fragments have been processed.
  • step (c) of the process a new version of each reference to modified fragment and of each modified microstructure if necessary is created and the old versions of the fragments and microstructures (at least those on which no macrostructure points) are deleted .
  • the method provides at least one mechanism for automating at least one of the above-mentioned steps.
  • Another object of the invention is a data processing system intended to present documents on a display device or equivalent and making it possible to manipulate fragments of said documents in particular within the framework of collaborative work, said documents being on the one hand in their raw form made up of a tree structure composed of nodes having information and attributes, and represented in particular in XML language, and on the other hand presented for display in particular in HTML language and scripts, after translation by programs, rules rewrite or style sheets in particular in XSL language, characterized in that it comprises interactive means comprising graphic objects associated with said fragments and placed within said display presentation, allowing the user to perform said manipulation simply by acting on said graphic objects by means of a pointing device such as the mouse , in that it is capable of assembling and implementing said interactive means dynamically, on the fly, when the display of said fragments is called up, in particular from information associated with said fragments of documents in their raw form and in that said graphic objects have information allowing the system to find what are the fragments of the documents in their raw form to be updated according to the actions of the user.
  • Said manipulations consist in modifying the content of existing fragments or in creating new ones.
  • Said manipulations consist in reproducing or moving fragments from one website to another.
  • Said display presentation is constructed from documents, in their raw form, recomposed as already mentioned.
  • Said interactive means are restricted as a function of the action rights associated with said users.
  • the system is capable of deciding on the existence and the nature of said interactive means to be implemented in association with each fragment of a document in its raw form, according to the existence or the value of specific attributes possessed by said fragment if any.
  • the system is capable of assembling and implementing different interactive means for different types of information contained in said fragments of documents in their raw form.
  • the system is able to determine the choice of interactive means to be assembled from tags and attributes or other markers characterizing the nodes contained in said fragments of documents in their raw form.
  • Said choice is made in combination with the information contained in the data schemas to which said fragments of the documents conform in their raw form.
  • the creations, displacements or reproductions of fragments caused by the use of said interactive means automatically result in new fragments and / or in new references to fragments inserted in the documents in their raw form at positions resulting from said actions of the user.
  • each new fragment or reference to fragment inserted following an action by the user is determined from information stored in association with said graphic objects used in the context of said action.
  • the system is able to place in said display presentation said graphic objects, from a knowledge of the existence and the position in the tree structure of the document in its raw form, as well as specific attributes, of nodes having a delimitation attribute (container) and fragment nodes.
  • Separate interactive means are implemented for each node of a document in its raw form having a delimitation attribute (container) which also has an attribute indicating the fact that the fragments which it delimits can be manipulated with said means.
  • a delimitation attribute (container) which also has an attribute indicating the fact that the fragments which it delimits can be manipulated with said means.
  • the display presentation of a manipulable fragment of a document in its raw form includes a graphic object (button) allowing it to be selected by means of a pointing device in order in particular to consult aspects of said fragment which are not displayed. or edit the content, properties, links or style sheet allowing the presentation of said fragment.
  • the display presentation of a first manipulable fragment of a document in its raw form comprises a graphic object (handle) associated with said first fragment and making it possible to drag and drop it by means of a pointing device on a graphic object ( target) associated with a second manipulable fragment of a document in its raw form.
  • the graphic object (button) allowing to select a fragment is also a graphic object (handle) allowing to drag and drop it on a graphic object (target).
  • the graphic object (button) used to select a fragment is also a graphic object (target) on which the user can drag and drop a graphic object (handle).
  • Said drag-and-drop operation makes it possible to move or reproduce said first fragment at the location indicated by the graphic object (target) associated with said second fragment.
  • Said drag and drop operation makes it possible to create a memorized link between said first fragment and said second fragment.
  • Said drag and drop operation makes it possible to create a contract proposal between the owner of said first fragment and the owner of said second fragment.
  • Said graphic object associated with a second fragment is located on the same page as said graphic object associated with a first fragment.
  • Said graphic object associated with a second fragment is located on a different page than that of said graphic object associated with a first fragment.
  • Said graphic object associated with a second fragment is located in a page of a site different from that of said graphic object associated with a first fragment.
  • the handle graphic object associated with said first fragment is also a target graphic object and therefore allows dragging and dropping on it a graphic object associated with another fragment.
  • Another object of the present invention relates to new functionalities added to an Internet browser.
  • a tool for browsing the Internet comprises means for accessing pages in HTML or other language, either by direct entry of the URL address of the page to be reached, or by clicking using the button. a mouse on a link contained in a page, which points to another page.
  • the present invention aims to overcome these limitations of the state of the art and to propose a navigation system which allows, in an extremely simple and intuitive manner, to access pages relating to subjects which the user has considered. as relevant in relation to the current page.
  • Another object of the present invention is to provide the user with extremely simple and intuitive means of creating links from one page to another, with, where appropriate, bidirectionality, and this independently of any structure of link directories.
  • Yet another object of the present invention is to allow a user to benefit, selectively, from links created by third parties in relation to his own subjects of interest.
  • the invention proposes a navigation system implemented in a computer system for accessing pages provided in particular by servers via a computer network by activation of links, characterized in that it comprises in combination:
  • selection and display means suitable, when displaying a page constituting an end of at least one link, for selecting and displaying part of the structure of groups of links containing this or these links, and
  • Said links include added links, associated with said current page and making it possible to access other pages, and the display means are capable of displaying representations of said added links which can be activated directly by said input means.
  • the means for creating added links comprise an input means allowing the user to drag and drop the current page or a displayed element representing the current page to another displayed page or a displayed element representing said other page.
  • the system comprises means for displaying the current page and its associated added link display area and means for displaying the link display areas of a plurality of other pages, adjacent to one another.
  • each display area for added links also contains a displayed element representing the page to which said added links are associated, and the means for creating added links implement drag-and-drop operations between the displayed elements representing the pages and the displayed elements representing the added links.
  • the system comprises means for displaying, under the control of an input means acting on a given display area of added links, the page with which said added links are associated.
  • Said structure of groups of links is a tree structure of directories each containing other directories and / or created links.
  • Said links include bookmarks, and the selection and display means are capable of displaying only the groups of links containing a bookmark corresponding to the current page.
  • the selection and display means are capable of displaying in a first zone displayed elements representing added links, and in a second zone, bookmark directories containing a bookmark corresponding to the current page.
  • the second area is displayed by a hierarchical representation of said bookmark directories and, selectively, the contents of said directories.
  • the system comprises means for displaying a plurality of directories containing first displayed elements constituting links to pages and second graphic representations constituting links added between said pages, and means for manipulating by drag and drop said first and second graphic representations to add, delete or move from one directory to another links to pages or links added between pages.
  • the system comprises means for storing, in association with a plurality of users of client stations, a plurality of link tables designating, for each page constituting an end of a link created, the or each of these links.
  • the means for creating links are able to be controlled by means of comparative processing of said plurality of link tables, to create links in a state called suggested.
  • the system comprises means for displaying displayed elements representing each link created in said suggested state and, in association with each of said elements, means sensitive to an input device for modifying the state of the corresponding link.
  • the means for modifying the state of a link created in the suggested state include means for deleting the link.
  • the means for modifying the state of a link created in the suggested state include means for validating the link by bringing it into an accepted state.
  • the means for modifying the state of a link in the suggested or accepted state include means for validating the link by bringing it into a frozen state.
  • the system further comprises means for adjusting each link brought to the frozen state on an address at which the content of the page has been stored.
  • the system further comprises means capable, under the control of the user, of assigning to any accepted or frozen link an attribute for characterizing the type of interest carried by the user to the content designated by said link.
  • the characterization attributes include a "Supplier” attribute and a "Requestor” attribute.
  • the system comprises, in association with each displayed element representing a created link, a graphic coding means for designating the state of said link.
  • the graphic coding means comprises color coding in a frame surrounding said displayed element.
  • the system further comprises means controlled by the user to configure the comparative processing carried out on said plurality of link tables.
  • the means of configuration controlled by the user comprise means of selecting the users for the link tables from which the comparative processing is carried out.
  • said comparative processing means operate on a plurality of link tables containing only the links created validated.
  • the system comprises means for suggesting to a user, in association with access to a first page, a bidirectional added link with a second page, said second page being chosen by said system according in particular to its relevance for the user with regard to the first page in such a way that when accessing said second page, the reverse added link, from said second page to said first page, can be activated by the user.
  • - Said second page is chosen by the system also according to the frequency of access to it by the user.
  • said second page is chosen by the system also according to the number of preexisting added links associated with said second page.
  • the system comprises means for processing said second page so as to include therein an element for displaying said reverse link.
  • the processing means are configurable.
  • the processing means are capable of including said element for displaying the reverse link at a location on the second page normally intended to include an advertising banner or the like.
  • system further comprises means for selection by the user of external groups of links and the selection and display means are also capable, when displaying a page, of displaying the links of at least an external group of links selected.
  • - external link groups include at least one of:
  • - Said links are located in containers defined in the structure of the current page, and point to containers capable of enriching said current page in locations defined by the position of said containers in said structure.
  • Another object of the present invention to exploit in a more lasting manner the previous navigation routes of a user so that he can use them during current navigation.
  • This possibility of traversing reverse paths is based on a temporary memory, at the level of the browser of the client station, containing the N last addresses of the pages successively browsed.
  • the invention provides a navigation system implemented in a computer system for accessing pages at a client station, in particular pages provided by servers via a computer network by activating links, characterized in that it comprises combination: means for detecting the existence of a link from a consulted original page to a consulted landing page, means for storing identification information of said consulted landing page and, in association with said identification information, identification information of said original page consulted, and means for displaying reverse links capable, when a client station connected to the system accesses said landing page, to use the identification information of said landing page to find in said storage means the identification information of said original page and to display on the client station t in association with said landing page, an activatable element constituting a link to said original page.
  • the detection means are capable of detecting a mouse action on a link to said landing page, contained in the original page consulted or associated with it.
  • the reverse link display means are capable of displaying on the client workstation a plurality of activatable elements constituting links to a plurality of pages of different origin.
  • the reverse link display means are capable of displaying only activatable elements constituting links to pages selected for their content characteristics in relation to a profile of the user of the client computer.
  • the storage means are capable of storing identification information of original pages in association with identification information of landing pages on a user-by-user basis, while the means for displaying reverse links are suitable to find in said storage means the identification information of the original pages by also using user identification information.
  • the storage means are capable of storing, for each user who consults a landing page by activating a link associated with an original page, the identification information of said original page in association with the identification information of said landing page and said user identification information.
  • the system further comprises removal means capable, at least during the first display of activatable elements, to suppress on the initiative of the user the display of at least one activatable element.
  • the means for displaying reverse links are capable of displaying in a suggested state the activatable elements of the corresponding links to the original pages, while there are further provided means for modifying suitable states, during each display of an activatable element in the suggested state, to pass at the initiative of the user said activatable element in an accepted state or in a refused state.
  • the state modification means are also capable of passing the corresponding link in a frozen state at the initiative of the user, while means are provided for storing the corresponding original page in its current state and to allow access to said original page stored in its current state from the corresponding activatable element.
  • the means for displaying reverse links are capable of displaying the activatable elements in at least one display area contained in the destination page.
  • the reverse link display means are capable of displaying the activatable elements adjacent to a display area occupied by the destination page.
  • said activatable elements consist of miniaturized representations of the corresponding original pages.
  • the display means are also capable of displaying, in association with said destination page consulted, a plurality of activatable elements constituting a plurality of links which were contained in (or associated with) the original page.
  • the display means are also capable of displaying, in association with another page consulted by activation of one of the activatable elements of said plurality, an activatable element constituting a link to said original page.
  • the link detection means are capable of detecting the existence of a link from an original page to a landing page via one or more intermediate pages.
  • the present invention provides a navigation method implemented in a client computer station for accessing pages provided in particular by servers via a computer network by activating links and for displaying said pages, characterized in that it includes the following stages:
  • the local or remote consultation of means for memorizing a table of reverse links containing, in association with information identifying said current page, identification information of one or more source pages with links to said current page, and
  • the identification information of the source pages in said reverse link table is determined by the prior detection of a mouse action, in a source page, on a link to said current page.
  • the method further comprises a step of selecting, from among the source pages designated by said source page identification information, only the source pages having content characteristics determined with respect to a profile of the user of the client workstation, and the display step comprises the display of the only activatable elements constituting links to said selected source pages.
  • the storage means comprise a plurality of identified reverse link tables, corresponding to a plurality of users, and the step of consulting the storage means is carried out using user identification information.
  • the storage means comprise a single link table containing identification information of source pages in association with the identification information of said current page and with identification information of the user.
  • the storage means are contained in a server accessible by network from the client station.
  • the method further comprises a removal step capable, at least during the first display of an activatable element, to suppress on the initiative of the user the display of said activatable element.
  • the deletion step comprises, during the deletion of an element that can be activated by the user, the deletion, in the storage means, of the identification information of the source page concerned by said activatable element in association with the identification information of the current page for the user concerned.
  • the step of displaying reverse links comprises the display in a suggested state of the activatable elements of the corresponding links to the source pages, and the method further comprises a step of modifying the state of reverse link for, during each display of an activatable element in the suggested state, change to the initiative of the user said activatable element in an accepted state or in a refused state.
  • the step for modifying the reverse link state also includes the passage, at the initiative of the user, of the corresponding link in a frozen state, and the method also comprises a step for memorizing the content of the source page corresponding in its current state, to allow access to said source page stored in its current state from the corresponding activatable element.
  • the step of displaying reverse links comprises the display of activatable elements in at least one display area contained in the current page.
  • the step of displaying reverse links comprises the display of the activatable elements adjacent to a display area occupied by the current page.
  • said activatable elements consist of miniaturized representations of the corresponding original pages.
  • the display step also comprises the display, in association with said current page, of a plurality of activatable elements constituting a plurality of reverse links which were associated with at least one page upstream of the current page.
  • the display step also comprises the display, in association with said current page, of a plurality of activatable elements constituting a plurality of links to pages to which point links contained in at least one page upstream of the current page.
  • the storage means further comprise identification information from at least one source page of higher level, containing a direct link, or via at least one other page, to at least one of the pages sources identified in association with the current page, and the display step comprises the display of activatable elements constituting as many links to the source pages of higher level.
  • Another object of the present invention relates to adding to a basic page, under the control of the user, content from other sites or other pages, depending in particular on the profile (centers of interest, etc. .) of the user.
  • This object of the invention thus proposes a system navigation which allows, in an extremely simple, intuitive and selective way, to access pages on subjects that the user has considered relevant in relation to the current page, or even, through the same user interface, to enrich the content of a current page with contributions also likely to interest the user.
  • Yet another object of the present invention is to allow a user to benefit, selectively, either from links to pages, or from links to additional content to be incorporated into the current page, these links having been created by third parties in relation with the user's own topics of interest.
  • the invention provides a navigation system implemented in a computer system for accessing pages provided by servers in particular via servers over a computer network, characterized in that it comprises in combination:
  • reprocessing means capable, for each activated option, of locating the set of information of the or each activated option from said location data and of extracting from it the information to be added, and
  • said information to be added consists of links from the current page to other pages.
  • the display means are capable of displaying said links outside the current page.
  • the display means are capable of displaying said links superimposed on the current page.
  • the display means are capable of displaying said links in at least one location on the page consisting of a reserved area originally provided in the current page.
  • said reserved area is an advertising area.
  • Said information to be added consists of links located at predetermined locations on the current page and pointing to additional content for said page.
  • the current page contains a code for presenting said additional content.
  • a list of defined options is provided, based on a comparison processing between a profile of the user of the client workstation and a plurality of public profiles of other users, as being from close profiles.
  • a list of options defined from selection parameters provided by the user is provided. - at least one of the options is selected by default in the case where said current page has been sent to the client station by a user with whom said option is associated.
  • the or each list of options contains a list of designations of the sources of said options such as users.
  • the means for selecting and displaying option lists comprise means for selecting options on the basis of attributes for characterizing the type of interest carried by the sources of said options on the current page.
  • said attributes include an attribute "Offeror” and an attribute "Applicant”.
  • the system further comprises means for communicating a user of said client station with users who are the sources of said adding options.
  • system further comprises means for aggregating information to be added associated with at least two different addition options.
  • Another object of the present invention relates generally to tools allowing a user of a client workstation on a computer network such as the Internet, to benefit from structured sets of knowledge, which will be called in the suite "profiles", which have been developed by other users.
  • An object of the present invention is to find and identify, for the benefit of a given user, the existence of other users who share his interests (and tastes) with respect to a "current page" that said user given is visualizing and therefore represents the current context of his interests.
  • the invention aims to find the second "closest" users, that is to say having, in a network of links between pages that they provide. public availability, on the one hand said page, and on the other hand, around said page, the largest set of links in common with the first user.
  • Another object of the invention is to find second users close to a set of pages selected by the first user, rather than to a single page.
  • the invention aims to allow a search for second users in a focused manner, that is to say with much more relevance than if it were based on their simple overall profile of interests (ie vis the overall interest profile of the first user).
  • the goal is thus to compare the profiles of the users by disregarding the elements of these profiles which are not in the context which interests the user at the current time.
  • Yet another object of the invention is to achieve these objectives with reasonable machine resources, and reasonably short processing times.
  • Another object of the present invention is to be able to focus the search without having to classify the elements of the profiles according to shared categories, and therefore without having to agree on common vocabularies of categories.
  • the present invention can be implemented on the basis of a direct access search using appropriate data structures (such as reverse files) which make it possible to find the second close users directly from said page, or even from that page and its added links.
  • appropriate data structures such as reverse files
  • an object of the invention is to propose an original approach to the search for pages or other content neighboring a given page, by using not structured profiles, but based on the users who have created links on this page. or content.
  • the present invention proposes, according to a first aspect, a method of selective enrichment of graphs from a set of graphs each comprising a plurality of nodes constituted by sets of information such as pages, linked together by constituted arcs by links between said pages, two nodes connected by an arc constituting neighboring nodes, with each graph being associated a first path structure to the nodes of the graph and, with each node contained in at least one graph being associated a second path structure for the graphs containing this node, characterized in that it comprises the following steps:
  • step (a) comprises the following sub-steps:
  • each node can be assigned a characterization attribute of the type of interest carried to the set of information of said node in association with the graph considered, and step (a) is implemented on the only graphs for which said given node has a predetermined characterization attribute value.
  • this object of the present invention provides a method of searching for neighboring profiles among a plurality of profiles not linked by a common structure and accessible from a processing system, each profile being defined by a set of information and / or identifiers of such information specific to a given user, characterized in that it comprises the following steps:
  • each profile assigns at least certain information and / or certain information identifiers to groups chosen by the user according to their own interests, independently of group choices by other users,
  • each item of information and / or item of information identifier can be assigned a characterization attribute of the type of interest shown in said item of information in association with the profile considered, and said search step is carried out solely on the item of information which a predetermined characterization attribute value.
  • this object of the present invention provides a method of searching, among a plurality of information elements, for information elements neighboring a given information element, each information element being capable of '' belong to a plurality of profiles not linked by a common structure and accessible from a processing system, each profile being defined by a set of such information elements and / or identifiers of such own information elements to a given user, characterized in that each item of information is associated with a list of profiles containing said item, and in that it comprises the step consisting in searching for items of information for which the list of profiles responds at best to a predetermined similarity criterion with the list of profiles of said given item of information.
  • each item of information can be assigned a characterization attribute of the type of interest carried to said item of information in association with the profile considered, and the search step is implemented on the only profiles for which said information element has a predetermined characterization attribute value.
  • said characterization attributes include an attribute "Offeror” and an attribute "Requestor”.
  • Another object of the present invention relates to the automatic enrichment of requests, in particular on the Internet.
  • a user has, in containers (receptacles), content (links; fragments) selected according to areas of interest, and more particularly where content can be suggested to a user and accepted by him in a determined container associated with said user, and thus adopt a "category" in relation to this container.
  • the same content can be accepted by the same user in several of its containers, and thus adopt several different categories corresponding to these different containers.
  • provision may be made for at least one (generally several) particular server connected to the network to centralize the data of categories associated with the content as described above.
  • the present invention has for primary objective to use such a particular server to improve the targeting of requests presented by the user to another server of the network, having itself assigned categories to content, and this according to centers of 'interests determined from user-specific category data previously collected.
  • such a particular server by knowing that it has categories of containers associated with content which is the subject of a request, automatically and transparently enriches said request with additional criteria .
  • this particular server is capable of determining that, for a certain number of contents belonging to a given category, there are one or more other categories which have been assigned by the user to these same contents. It therefore exploits these other categories by using them as additional criteria to automatically enrich the request formed by the user.
  • the present invention will make it possible, using this enriched request, to select the contents in a “personalized” manner, that is to say taking into account the potential centers of interest of the user for the containers in question.
  • this object of the present invention proposes an intermediate server, capable of receiving from a client station a basic request normally used for direct access to a third-party server and redirecting a request to said third-party server, characterized in that it includes means for:
  • said additional criteria include at least one category identification of another container associated with said content.
  • the intermediate server further comprises means capable, when the third party server delivers raw information (XML) dissociated from presentation information (XSL) specific to the third server, to apply information to said raw information. presentation other than said presentation information specific to the third party server.
  • XML raw information
  • XSL presentation information
  • Yet another aspect of the present invention provides a method for assigning categories to content (fragments) accessible by a plurality of users, each content being moreover suitable for being selectively placed in a plurality of containers (receptacles) belonging to document structures, these containers each having category information, and each content that can be associated with a plurality of category information allowing users in particular to selectively access by a category criterion to said content or to automate the selection of the presentation of said content, comprising the step consisting, when a given content is placed in a given container of a document, to add the category information already associated with said content the category information possessed by said given container. Said category information added to the content is added in suggested mode.
  • a last object of the present invention relates generally to methods for determining degrees of proximity between contents with which “marks of interest” are associated, such as pages accessible by the Web.
  • expression of interest is meant, for example, the fact that for a given content, there is in another content (which will be called router content) a link to this content, or even the fact that for content, there are users who have placed bookmarks or the like on this content in their internet browsing system, or who access this content particularly frequently and / or regularly.
  • the present invention aims to determine degrees of proximity between contents and to categorize such contents automatically by analyzing the aforementioned marks of interest.
  • the present invention seeks to overcome these limits by automatically exploiting, on the one hand, links located in preexisting content, generally corresponding to pivotal pages of the Web or "routing contents" (that is to say pages whose essential function is to route the Internet user to subjects of interest), and on the other hand groups of links gradually structured by users (Internet users or web masters).
  • the present invention proposes according to a first aspect a method for determining a degree of proximity between contents in a set of N contents such as pages accessible by links on a network such as the Internet, in particular for the purpose of categorizing said contents, each content being accessible by a plurality of users, characterized in that it comprises the following steps:
  • A) for each content memorize in association with a plurality of users capable of accessing said content a plurality of information of marks of interest for said content,
  • step B) comprises, for any subset of 1 to N contents, the calculation of a probability for a user to show no interest in any of the contents of the subset
  • step C) comprises the calculation of a ratio between the product of probabilities obtained for all the subsets having an odd number of contents and the product of the probabilities obtained for all the subsets having an even number of contents.
  • each proximity coefficient is equal to 1 minus the value of said ratio.
  • the calculation of the value representative of the probability for a user to carry a mark of interest to at least any of the contents of the subset involves the probability for a user to carry a mark of interest to each of the contents of the subset.
  • At least certain contents of said set are capable of being reached by at least one link provided in at least one of a plurality of routing contents, in which case the information of user interest marks for such content is made up by the presence or absence of links in said plurality of routing content to this content.
  • the invention proposes a method for determining whether a first group of one or more contents is likely to be assigned the same category information as a second group of one or more contents to (x ) which (s) is already assigned the same category information, characterized in that it includes the implementation of the method as defined above on the set consisting of the contents of the first group and at least certain contents of the second group, and the assignment or not of said category information to the content (s) of the first group as a function in particular of the value of the proximity coefficient obtained.
  • the invention proposes a method for assigning category information to one or more contents of a first group, characterized in that it comprises the repeated implementation of the method according to the second aspect of the invention on sets made up of the content (s) of the first group and content belonging to other groups and to which information of a common category is assigned each time, and the assignment to the content (s) of the first group d '' at least one category information according to the different proximity coefficients obtained.
  • a document like the one illustrated schematically below, is quite naturally structured in a tree structure of nodes which group together other nodes at positions that we call the "Container" node:
  • a “Chapter” fragment includes a container for “Sections”, which in turn contains a container for “Paragraphs”, which can contain one or more containers containing “Elements”, as illustrated below. Note that in the example presented, the first paragraph fragment contains two containers, each containing two elements, and that between the two containers is the content "(always in the same paragraph 1) " which belongs to the same fragment. This structure can be explained by means of tags:
  • fragment- 'private can only be manipulated by its owner: it cannot be manipulated by other users, at least not” by being taken alone “(ie say it could be as a sub-fragment of another fragment if appropriate).
  • a fragment can have more than one container.
  • the article fragment could have had two containers (materialized by the DEBUT and FIN nodes) the first containing for example two sub-fragments and the second containing a sub-fragment:
  • the reference is implemented in the form of a "GetFragment" method call from a web service exposed by the server of the second document.
  • Other ways of implementing an update reference are of course possible (in particular by means of the XPath language).
  • modifying part of the content of the imported ARTICLE node consists in (1) creating a copy of all this content, (2) deleting the reference (mix: src- '... "), then (3) making the modification Since this reference has been deleted, the part which has not been modified can no longer be kept up to date.
  • N12; N131 for at least one node (N12; N131) of the resource, arrange said node as a fragment (F12; F131) comprising said node as the root node of the fragment and all the descendant nodes (N121, N122, N123, N1211, .. .; N1311, ...) of said root node,
  • NI 22 At least one descending node (NI 22) included in a first downstream fragment (F12) an update reference (R (N122, FA ')) to another upstream fragment (FA') contained in n 'whatever resource (Rz), to form a second downstream fragment (F 122) which is sub-fragment of the first downstream fragment (F 12),
  • - optionally, associating with at least one descending node (N121) of a downstream fragment a non-updating reference (NR (N121, SFA)) to the corresponding descending node of the corresponding upstream fragment, so that the content of each downstream fragment (F 12; SF122) is composed from the content of the corresponding upstream fragment (FA; FA '), with the exception of the content of each subfragment (SF121) corresponding to each descendant node (NI 21) to which is associated with a non-update reference.
  • content means "presentation of content”
  • the method further comprises the following step:
  • microstructure the information contained in the fragments - which we call "microstructure” - is separated from the structure of the fragments (seen as nested containers) - which we call “macrostructure”. This is illustrated in the two figures Fig.8 and Fig.9.
  • the first figure (Fig. 8) schematically shows a document with its microstructures (observe in particular the container nodes, diagrammed by ovals, which are at the locations where the fragments overlap each other):
  • FIG. 9 shows the same document with the microstructures that have been separated (now observe that the containers, represented by ovals, are found both in the fragments and in the microstructures):
  • Fig.10 and Fig.ll illustrate the breakdown into macrostructure and microstructure for the example used in the previous sections.
  • FIG. 12 illustrates two contexts and their references.
  • the microstructures are first grouped in a “mix: microstructures” node, the fragments and their nesting are then specified in the “mix: macrostructure” node (according to the diagram in the figure above). Note that as no fragment reference insertion has yet been made, all the fragments are references to microstructures (mix: micr-ref).
  • Figure Fig.13 shows the first document after inserting the article from the second document.
  • a fragment can consist of a reference to another fragment, the latter possibly being in another computer and being able to itself refer to a third fragment being in a third computer, and so on, until to the last fragment which points to it on a microstructure.
  • the idea of the cache is to store locally, in the context, the external microstructures accessed, at least some of them. In general, only microstructures that do not reside on the same machine will be stored.
  • the XML below now includes the cache (for this example, after inserting the 2nd article):
  • a freshness attribute (mic ⁇ time-loaded) and a renewal attribute (mic ⁇ refresh-every) are associated with the cache microstructures. By comparing the values of these two attributes the system decides if a cache microstructure is acceptable as it is (case where mic ⁇ time-loaded + mic ⁇ refresh-every ⁇ current time) or if it must be loaded again.
  • each (or selectively some) upstream fragment is associated with the references to the fragments that imported it (downstream). These are notified (DeleteCache) before deleting said upstream fragment, if applicable
  • Certain nodes of the hierarchical structure formed by HTML elements represent by nature containers (containing fragments ⁇ li> in this case).
  • Other nodes like ⁇ hl> to ⁇ h6>, can be seen as the beginning of a fragment in the sense that interests us.
  • a hyperlink ( ⁇ a>) can also be seen as a reference on a fragment. The user may want to "grab” and “drag and drop” such fragments to reproduce them elsewhere (as described in the next section "Presentation to the user").
  • Dragging and dropping a fragment in a document structured internally in the form of a context then consists of referencing it (in the form of a mix: fragment-ref, "update reference” ). It is therefore clear that the elements of the HTML files can be used as fragments, in the same way as the XML fragments described above, that is to say fragments which are referenced in a context.
  • the system used must therefore make it possible to select the nodes which will be used as a fragment, as well as those which will be used as sub-fragments if necessary. We can then modify parts of an imported fragment while allowing the rest of the imported fragment to be kept up to date in the future.
  • the HTML page in question is automatically transformed (on the fly, for example by a style sheet in XSLT; see on this subject the following section "Presentation to the user") before being presented to the user, so that "handles” (buttons) are displayed and allow him to select fragments and containers from a set of first fragments and containers presented by default.
  • These first containers and fragments are selected automatically according to rules (modifiable), such as for example: presenting all ⁇ ul> as container and all ⁇ li> as fragment.
  • each handle can be deleted or replaced by (or even duplicated in) another by following the tree structure of the HTML nodes ( note that, in this path, certain nodes can be ignored).
  • the user can thus select any fragment of the page. He thus distinguishes the fragments that interest him, configures their tree structure of receptacles and sub-fragments. He can delete a fragment and insert a new fragment into a container.
  • HTML resources thus fall within the general framework of the system described in this report. You can mix in the same macrostructure references to HTML and XML fragments (or other resources).
  • Fragments and containers imported from HTML pages of the Web can advantageously store a context created by a user.
  • the latter can for example take a page from an online bookseller, transform a list of books presented in the page into a container, and then use this container and the fragments it contains to (1) delete certain books from its "version personal ”(thus created) from the site of the bookseller 4 and (2) insert there other fragments (notably presenting other books) gleaned for example in another site of the bookseller 5 , while continuing to receive in this same container the new books presented in the future by the first bookseller.
  • the system first transforms it into a "classic" XML document where container and fragment nodes are specified using attributes, as described in the section "Container and fragment nodes in XML structures”. We are going to call this “assembly” or “reconstitution” of the document.
  • each element or microstructure (which results from the resolution of a reference) is transformed by a style sheet (in particular in XSLT). He is transformed
  • the system transforms the document into XHTML except for all fragments which have the attribute "mix: preferred-style” with a specified value (having the value “micr” or "fragment”). These are copied as is (word for word) so that their transformation can be carried out during a next pass.
  • the process is thus iterative and on each pass, the fragments which have not yet been transformed into XHTML, that is to say all the nodes which have a attribute “mix: preferred-style” specified and of which no ancestor has this same specified attribute, are transformed in their turn, until all the fragments (all the sub-fragments in depth) have been taken into account.
  • Figure Fig.14 shows a flowchart that describes this process.
  • the page presented to the user can be presented in “normal mode” or in “manipulation mode”.
  • Normal mode is the default mode corresponds to the page published normally.
  • the style sheet In manipulation mode, before applying a style sheet to the result of the resolution of a reference (for example to a microstructure), the style sheet is transformed automatically (on the fly) in order to insert "buttons" of manipulation in the page.
  • the system then makes it possible to manipulate, in particular to reproduce from one site to another, fragments of XML resources (documents) presented for display on the screen through style sheets, by acting only on their presentation. on screen display.
  • graphic objects are used as “handles” and / or “targets” associated with the presentation of the fragments.
  • a handle is used to catch a fragment, in particular to drag and drop it to the place where you want to reproduce it, this place being indicated graphically by a target.
  • the user can then grab one of the fragments to drag and drop it into one of his own pages (see figure Fig.17).
  • each page that can be manipulated (which the user can switch to manipulation mode) can have a toggle button (in Figure Fig.19, this button is here called “Click2handle”) 6 .
  • the current user who visits a page can in particular be: an unregistered visitor, a visitor registered and recognized by the system, or the owner of the page. (Obviously, a more detailed classification of users is possible).
  • registered and recognized visitors can "grab" a fragment to drag and drop it onto their own page, but they cannot modify it on the original page; the right of modification belonging only to the owner of the page visited.
  • buttons per manipulable fragment can be separate from the handle. In such a design there are altogether two buttons per manipulable fragment:
  • this button could have been part of the browser or as an extension of the browser; or it could have been placed in a single location on the site and made it possible to switch the commonly used page, the window with the focus ) • a delete button.
  • the handles also include buttons (called “container button”, see the figure above) which
  • the system allows information to be reused in particular inside a website (for example by its webmaster), between several sites or even from a page of a site to a personal version of it.
  • the imported fragment can be automatically adapted, or even refused, to satisfy the constraints or preferences of the target container, and the conditions of an agreement (or contract) to be concluded if necessary between the owners of the sites of on either side of the transfer, can be proposed automatically first to the user who performs the drag and drop, then and asynchronously (in particular by means of an electronic mail) to the other party.
  • the fragment returned during the reconstruction of a page can in particular have the form of an interactive form or other executable program.
  • a typical application is the publication on the Internet, or in an intranet, of a call for tenders requiring several contributions, the latter having to be combined and adapted to each other to meet the required requirements.
  • the system allows a first contributor to import the call for tenders on his site and to automatically republish it for second potential contributors after having subtracted from him the contribution which he proposes to offer himself.
  • a second contributor can then import the new version of the invitation to tender, complete the first offer with his own contribution proposal and automatically republish a third version of the invitation to tender, and so on.
  • the call for tenders gradually spreads and completes, while becoming more and more specialized, until the response includes all the necessary components.
  • Each contribution proposal is part of a chain of contributions and all the chains thus formed constitute a tree structure (or pyramid chain) of links which can be managed by each contributor from the link he has created.
  • the symmetrical application is the publication on the Internet of a lot (for example of goods) that is put up for sale, the constituents of said lot can be sold together (to a single buyer) or separately (to different buyers ), and the sale being concluded only if at the end of the chain the whole lot is purchased.
  • the sale proposal can be republished from buyer to buyer, each removing the part he proposes to buy, until the lot is sold entirely. Suggested, Accepted, Frozen, Refused modes
  • the suggested mode can be changed by the user (or by a system which plays the role of user): each subfragment can thus pass in accepted, refused or frozen mode. Note that by user we mean here the owner of the context in question (or a system which has the same rights).
  • the act of inserting (importing) a fragment into another fragment consists in inserting in the latter (in context) a reference to the former.
  • the fragment with this reference automatically takes the accepted mode. For example :
  • this same channel can also be used to communicate fragments from downstream to upstream, selectively.
  • the attribute “mix: upstream-fragment-id” of a fragment in suggested mode has for value the identifier of the fragment (accepted or frozen) which is in the upstream context.
  • each fragment in suggested mode has a “mix: nearest-accepted-ancestor” attribute which allows the system to easily find the upstream context by going back to the first ancestor fragment which is accepted or frozen.
  • a sub-fragment in suggested mode is not explicitly inserted in the macrostructure (in the context).
  • the document is in accepted mode and its sub-fragments are in suggested mode; they therefore do not appear explicitly in the context, as illustrated below:
  • the purpose of rejecting a fragment is to make it possible to avoid presenting it again: Each time a fragment is presented in accepted or frozen mode, the sub-fragments of said fragment are presented, except those in refused mode.
  • An accepted mode fragment consists of a reference to an upstream fragment.
  • a frozen fragment essentially consists of a copy of an upstream fragment.
  • a fragment in refused mode For each fragment in frozen mode, a fragment in refused mode, with a new identifier, is created in order to prevent the parent fragment upstream from resugging it (this is similar to the case of the refused fragment). However, this will only be done in the case where the parent of the referenced fragment is itself referenced by the parent of said frozen fragment (otherwise there would be no risk of suggestion!).
  • Deleting a fragment that is in suggested mode consists of putting it in refused mode.
  • Deleting a fragment involves deleting all of its sub-fragments.
  • Deleting a fragment which was created ex-nihilo consists in deleting it in the context (and consequently, also from the reconstituted document).
  • fragment-id is assigned to it (thus, for the downstream, it is deleted).
  • fragments which referenced it downstream are also deleted, either directly (following a notification, by "push") or as soon as the downstream system becomes aware of it (occasionally of a reconstruction, in "sweater”).
  • Modifying a fragment, in accepted mode consists of
  • the reconstruction starts with the call of a “GefFragment” procedure (the procedures are described below).
  • the latter launches the call "GetFragmentWithout” to Document2 to request the reconstitution of the article found in Document2, except the fragment Text4 (because it is in refused mode with the caller, see the list "List-” described with GetFragmentWithout procedure).
  • the first line above Document2, Article fragment, Accepted mode is thus deleted. It will therefore remain to be treated:
  • the GetFragmentWithout procedure (called on Document 2) returns the fragments and microstructures (retrieved at the end of the reference strings using the GetMicrostructures procedure described below) from the Document2 article:
  • the calling procedure consumes the following line (Document3, fragment Text5, accepted mode) by calling GetFragmentWithout on Document3.
  • the fragment and the Text5 microstructure thus brought back are placed in the assembly above, above the Text4 fragment (in accordance with its location in the macrostructure):
  • the GefFragment procedure consumes the following line (Documentl, Text4 microstructure) and places the Text4 'fragment, above the Text4 fragment (according to its location in the macrostructure):
  • Fragment Texte3 suggested mode "Fragment Texteashé, suggested mode” Fragment Texte ⁇ , accepted mode
  • Figure Fig.21 is a diagram showing the sequence of calls to these procedures.
  • GetMicrostructures by passing in parameter the identifier of said fragment referenced as well as all its descendant fragments which are in the same context and which we want to obtain microstructures (we pass a parameter an array, the first element of which is the identifier of the fragment we want to recompose, and the following elements of which are descendant fragments accepted at no cost).
  • a new List + (list of requested fragments) is created each time to be passed as an argument.
  • the mix: fragment-id that this list contains are those of the context that receives the call. They are in fact accepted fragments, the cache copy of which is not fresh.
  • a cycle takes place when a sub-fragment included in a fragment consists of a reference to said fragment or to an ancestor of it. This phenomenon can be “sneaky” (difficult to predict) since the cycle can be “long” and include references to fragments distributed in several documents for example.
  • the user could be offered various functions among the following which in particular could be performed by drag and drop:
  • the first of these functions consists in importing a fragment as already described above.
  • the second function is to copy a fragment reference (or microstructure if applicable) and then assign it frozen mode.
  • the third function is to copy a fragment reference (or microstructure if applicable) to the specified destination and then delete it at the origin.
  • mix: micr-ref or mix: fragment-ref
  • mix: fragment-ref can be attributes in the mix: fragment node, instead of being separate nodes.
  • microstructures can reside in the macrostructure instead of being deported in a “mix: microsrtuctures” element, but their form remains the same: they are devoid of child nodes under the containers they contain.
  • the microstructures and the elements of the cache can advantageously reside in DBs (managed by DBMS).
  • Each version of a fragment can advantageously be provided with a "derivation-count” attribute which is a reference counter which points to it. In the case where this attribute has the value zero for the first version of the DOCUMENT fragment, this can be directly deleted, or go into archiving mode.
  • a frozen fragment now consists of a reference to a specific version of an upstream fragment. So if for example we want to insert in another context (downstream) the first version of the document (recalled below)
  • the computer system used can then automatically create a relevance relationship between the information taken up and its new context (see Figure Fig. 2).
  • the principle of a suggestion engine is as follows: the user provides the system with the identifiers of a certain number of information which interested him (in particular the information which he re-uses in a given context; a directory of its bookmarks for example) and, thanks to the categories created automatically, the system returns other information which potentially will also interest it (by inserting it in this context; its directory of bookmarks for example).
  • the information which interested him, and which he provides as input to the system forms what we call an "implicit request"
  • the accepted (or frozen) fragments found in a container node can be considered as forming an implicit request addressed to the system.
  • the system which will now be described, automatically suggests to the user new fragments in this container.
  • the new suggested fragments are thematically close to the said accepted fragments and are of interest to the user, at least as much as the said accepted fragments (which constituted the implicit request).
  • the automatic categorization system also serves to filter the fragments in suggested mode which are transmitted from upstream to downstream 12 according to the process described so far (see the section “Suggested, Accepted, Frozen, Refused Modes”).
  • the system will store sets of fragments close to each other - these are “categories” - which it can reuse to process implicit future requests.
  • a category is a set of fragments centered around the same theme.
  • the “Reuse Ties” section presents different cases of reuse. 1 (and downstream, as an alternative)
  • the heart of the system is therefore an automatic and incremental categorization of the fragments, capable of:
  • the system is based on an automatic analysis of the references found in the contexts.
  • the pages of the Web are also analyzed and allow the system to be initialized with "universal categories".
  • the system creates universal categories (they emerge automatically) by finely analyzing the hypertext links found in web pages . These are obtained by surveying the web upstream and then downstream around the pages indicated in the implicit request: all of the pages analyzed include all the pages which are pointed to by the pages in which a hypertext link pointing to at least one is included. pages of the implicit request.
  • Web pages are assimilated to contexts and the hypertext links (generally pointing to other Web pages) which they contain are assimilated to references on fragments.
  • a method for filtering sites which can be tested on a search engine, consists of using the instruction "link: www.site, .com AND link: www.site j .com" (to find out the pages which point to a couple of sites: site, and sit ⁇ j ).
  • the query can be sophisticated to avoid internal links to the sites. Couples of competing sites (or from the same sector) are among those who return the most responses. Note that without the web analysis and innoculation process described above, it would have taken a lot of real users of the system from the start for the automatic categorization of fragments in contexts (without taking pages into account from the web) works.
  • the automatic categorization system is advantageously implemented in a decentralized manner, which means that the computing power and the storage are distributed over a certain number of machines, which can communicate with each other via a network (Internet), and d on the other hand that all the machines are on the same level (according to the principle of “peer-to-peeer” architecture in English terminology).
  • peer-to-peer each user can contribute to the system the categorizations of fragments resulting from their private reuse.
  • the number of resources available is linked to the number of users, since in principle everyone contributes by offering resources from their computer. As each user can only be interested in a limited number of domains, there are in the global system all the more users, and therefore resources, than different domains of interest to cover. However, resource requirements are linked to the volume of areas to be covered.
  • An advantage, essential for both the user and the owner of the web page, is to be able to personalize the web page automatically when it is accessed by the user.
  • the categories of new information that a user places (imports) in his personal version of a page characterize the user in relation to this page. These categories can be automatically transmitted to the server of the page in question, at the same time as the user's request. The server can then directly adapt the content of the page before transmitting it to the user. (Note that only the categories must be transmitted, not the information imported into the page).
  • the “Types of reuse” section presents different cases of reuse. For example, if a user likes flamengo music, this category being associated with one of the added links (described later in the "section” Added links & reverse added links ”) of his personal version of a Web page presenting a catalog of guitars, when he accesses this page again, the server will choose in priority a Spanish guitar to present to him in priority, said category being also associated with this product.
  • the latter adapts (personalizes) the requested page before providing it to the user.
  • the added links, references to fragments and other information associated with the personal version of a page are stored on a server.
  • Two modes of operation can be envisaged. These are illustrated schematically in the two figures Fig.23 and Fig.24.
  • the client station first finds the information related to the personal version of the requested web page. It then requests this web page (from the server that owns it), at the same time communicating the categories of added links (and other information) that are in the personal version.
  • the user's request is communicated, by the client station, only to the server of the personal version.
  • the latter is responsible for re-transmitting the request to the server of the requested web page, after having added the categories.
  • the return is done via the server of the personal version.
  • the relevant fragments returned by the server will be integrated into the contexts of the user, and their categories will eventually propagate towards other fragments of his contexts.
  • This method relates to the management of fragment categories and makes it possible to take advantage of manipulations of fragments made by users in document structures capable of receiving such fragments in containers (receptacles) themselves having category information.
  • the invention proposes a method for assigning categories to content accessible by a plurality of users, each content being moreover capable of being selectively placed in a plurality of containers belonging to document structures, these containers each having category information, and to each content that can be associated with a plurality of category information allowing users in particular to selectively access by a category criterion to said content or to automate the selection of the presentation of said content, comprising the step consisting of , when a given content is placed in a given container of a document, to add to the category information already associated with said fragment the category information possessed by said given container. Said category information added to the fragments can be added in suggested mode.
  • a fragment accepted by the user in a container adopts the category of this container, in addition to the categories of the other containers in which the user has also accepted this fragment if necessary. Since the system knows the categories of containers nested in a fragment that is the subject of a request, it can automatically enrich the request with additional criteria. Indeed, the system is capable of determining that, for a certain number of fragments of each of said categories, there are other categories which have been assigned by the user to these same fragments. The principle used here is to exploit these other categories by using them as additional criteria (or more exactly as "preferences") to automatically enrich the request formed by the user.
  • fragments are selected by the system in a “personalized” manner, that is to say taking into account the potential centers of interest of the user for the containers in question.
  • the categorizations carried out by the users can “go back” to the administrator of a site as suggestions of categorization for the fragments in question, so as to modify the XML structure of the page considered if the administrator judges it timely.
  • Figure Fig. 25 schematically illustrates the fact that the user finds the reverse link on each visit to the page towards which an added link points, whatever the time and the circumstances of this visit.
  • this is illustrated in square brackets
  • the added links are thus "bidirectional" (according to the description above), the owner of a page where one can place added links (in a personal version of the page), benefits from the fact that the visitor who adds a link to another page is encouraged to return to visit their own page each time they visit the other page.
  • the visitor is "loyal".
  • the (classic) hypertext links appearing on the original page are also transformed, by default, into bidirectional links in the personal version of the visitor, insofar as the latter does not delete them.
  • the owner of the original page thus benefits from the audience of the pages pointed to by these links. Indeed, each time you access each of these pointed pages, the visitor
  • the categorization spreads in both directions: not only the re-used information increases its chances of entering the categories of the fragments of the page that hosts it, but also this the latter increases its chances of entering the categories of re-used information; and it is obviously this second direction that particularly interests the owner of the page that hosts it.
  • a hypertext link in a web page represents a relationship as relevance implicitly declared by the author of this page. This is illustrated in figure Fig. 26.
  • the context will be a limited region of the page containing the hyperlink.
  • Scrapbooks are equivalent to bookmarks except that they use copies of web pages rather than links on them; these are "albums" in which web pages are stored. Scrapbooks can thus be used in the same approach: a relevance relationship can be created between the source of the stored page and the context (as precise as possible) in which it was placed.
  • FIG. 28 Another application is to associate an interesting page with a set of other interesting pages accessed frequently in the same navigation. All the other interesting pages are called "navigation context”. This is illustrated in figure Fig. 28.
  • Each access to an interesting page (for example: to a page accessed frequently or manipulated for a long time) is memorized and the system associates its position in the user's navigation sequence.
  • the system identifies, among the closest pages of interest in the navigation sequences, those which have been accessed in the same navigation, and increments their contextual proximity with the first page.
  • the interesting pages found in the same navigational context are thus identified and the navigational context emerges itself automatically. Relevancy relationships are then created between the pages and their navigational contexts.
  • the user can also group, in the same web page (if he has the right to manipulate it; for example within a personal version of a web page), fragments of the resources which he accesses.
  • the fragments thus assembled are presented after application of a style sheet (in particular in XSLT) or of a composition of several style sheets. At the storage level, they are materialized by references to the original fragments. This process has been widely described in the first half of this report.
  • a webmaster can thus compose the home page of his site by simple drag and drop of fragments. Since the imported fragments are references to the original fragments, the updates are automatically reflected.
  • a relevance relationship is then automatically created between an original fragment (within Pagel in Figure Fig. 30) and the page into which it is imported (Page 2).
  • the user creates links (which we call Added Links) between pages that he discovers during his navigation, especially on the Internet.
  • the classic bookmarks appearing in a directory of bookmarks in which the current visited page is found, are also automatically presented to it when visiting said current page.
  • Each user thus adds their own links to the mass of information available on the Web. (The figure Fig. 31 illustrates this concept.) While navigating, it sets up new links which will help it in its navigation in the future. He thus navigates in a “pro-active” way.
  • the user also creates added links when he locates a relationship by moving inside large pages or virtual worlds in 3 dimensions (in immersive virtual reality).
  • the creation of an Added Link can be done by simple drag and drop from the “handle” of the currently viewed page (for example of the commonly viewed 3D scene) to the handle of the page to be linked (other 3D scene).
  • Figure Fig. 33 illustrates that, as a result of access by the user to a pi page, the System automatically presents him with the Added Links p2, p3 and p4 that he had associated with the pi page during previous navigations.
  • the system is equipped with means for storing Added Links. These means make it possible, on each access to a page to which Added Links have been associated, to present these to the user in addition to said page.
  • an indirection is established towards the storage of the Added Links, in order to associate these links with this page before presenting it to the user.
  • the Links added by the user, by drag and drop (or manually by typing them on the keyboard), are stored in the system as illustrated schematically in FIG. 35 which presents a table of relations between pages associated with the current user.
  • the links presented to the user in association with P2 include all the other links on the PI page (namely links P3 and P4, see figure Fig. 38).
  • the pages accessed by the user by activating said other links are associated with reverse added links pointing to said page PI (in addition to the reverse link on page P2). This is what FIG. 39 illustrates.
  • each page accessed by the user, by activating a suggested link on a current page will be associated with the reverse added link pointing to the original page (and not only to the current page).
  • a first user can access, for a given page, the Links Added to a second user. These Added Links are then added to those which, if applicable, had already been associated with this same page with the first user.
  • the user can select (for example by clicking a check box) one or more items from these lists to indicate that he wishes to add their added links to his own list of added links.
  • the three lists are described below:
  • the content of the first list is optional: this content exists if the author of the page in question is himself a user of the system and wanted to suggest links added to the first user;
  • the second list (“neighbors of interest”) aims to present the first user with the groups most likely to contain interesting added links in relation to their interest profile; the list of these directories is determined automatically by the system by comparing the Miniweb of the users;
  • the third list (“buddies”) contains groups chosen by the first user (for example, groups belonging to the miniwebs of friends, colleagues, experts, etc.).
  • a fourth list of groups belonging to the first user can be added to the three lists above.
  • the name or pseudonym of the second user who is the sender of the added links received by the first user - or of the group containing these added links (note here that it can also be another group of the first user) - is automatically presented in first position in the third list (“buddies”) in active mode (that is to say selected) by default.
  • the third list can advantageously be based on:
  • Means for selecting added links, on the basis of criteria given by the user or associated with the current page, can be advantageously implemented. For example, the user can specify that he only wants to draw from the checked groups links added on labeled pages:
  • Added Links which are thus suggested to him must be distinguished from those which he had added himself, he may indeed refuse some of them.
  • Added Links can be in one of several different modes: “Suggested”, “Accepted”, “Refused” and “Frozen”, as described above.
  • the Added Links received by a first user, from the Added Links published by a second user (or from the Added Links of one of the groups of the first user), are with the first user initially in "Suggested" mode.
  • each Link Added in Suggested mode can switch to one of the other modes.
  • the human-machine interface allowing this is shown diagrammatically in FIG. 41.
  • the system stores the value of these two attributes for each reference (link) in the contexts (in the personal web -miniweb- of each user). It can thus take this into account in the process of selecting the directories to be offered to users.
  • the supplier attribute can be used by the user to inform about his own characteristics: the user can, for example, check the supplier attribute on a page presenting a film actor who looks like him, in the hope of being able to get in touch, by means of the system (for example by videoconference), with a user who appreciates this actor as it is presented in said page.
  • the system will offer the user neighbors who are “Requesters” of the product presented in the current page viewed. The user will then be able to interact with these users by computer-assisted means, in synchronous communication (instant messaging, etc.) or asynchronous ( forum and electronic mail augmented by special semi-automatic means to facilitate the coordination of group purchasing, in particular for negotiate prices with suppliers).
  • the system can be used to select directories instead of users.
  • the system can advantageously be used to select directories "close" to the first user, several directories of the same second user.
  • the selection of the closest directories can be done very efficiently thanks to a data structure (such as an inverted file) allowing to find in direct access the directories containing a given page (the current page of the user) the access direct can even be based on the given page and the Added Links associated with it.
  • the closest directories selected automatically, are presented to the user in the second list (entitled “neighbors of interest”) illustrated schematically in FIG. 40.
  • Publication of Added Links the user can check one or more of the directories offered to him by the system.
  • new Added Links drawn from this or these directories, are suggested to it on (in association with) the current page (as described in the previous section).
  • the system can also offer the user means of trying to get in touch - by means of communication on the Internet, such as "chat", videoconferencing, etc. - with the users having these directories who would be in line at the same time.
  • the system provides the user with these directories in order of their proximity.
  • Proximity can be calculated at different levels.
  • proximity is a function of the number of common Added Links associated with the current page.
  • Figure Fig. 42 illustrates the determination of proximity at level 1.
  • proximity is also a function of the number of common Added Links associated with pages linked to the current page by Added Link. This is illustrated in figure Fig. 43.
  • proximity is equal to proximity at level n-1, plus a function of the number of common Added Links associated with pages indirectly linked to the current page by Added Link, n being the number of indirection steps.
  • the system can enrich its proximity assessment by anticipating the probable propagation of Added Links in the future. Indeed, the Added Links which at the current moment are not yet propagated (suggested) from a close directory to another, will probably be in the future, and, if possible acceptance, will be ready to be suggested to a third directory ( And so on).
  • the system can enrich its proximity estimate by anticipating these propagations (suggestions) and acceptances, and by calculating the proximity of a directory, the anticipation having been taken into account.
  • One server can store information, can perform certain tasks, and two servers can exchange information in the form of messages.
  • a fragment is an object that can be referenced (referenced)
  • a context is an object that can create links (or references) to fragments.
  • Each context is therefore linked to a certain number of fragments (its fragments), and each fragment is linked to a certain number of contexts (its contexts).
  • each web page can play the role of both context and fragment.
  • the hypertext links which are there will be treated as references towards other pages which themselves will be treated as fragments.
  • a fragment server represents a fragment. It knows its fragments (those it references) and its contexts (which are other fragment servers), as well as its categories (category servers, introduced below.)
  • a fragment server is able to find and update its fragments and contexts. It is also able to find its categories, in collaboration with other servers (this process will be specified later), which means that the processing of an implicit request will start with requests for category lists to all fragment servers. referred to in said implied request.
  • the exploration servers provide an interface between the fragment servers and the references (for example page URLs). They allow a user to send a message to a fragment server (by giving for example the URL of the fragment) without knowing where this server is located.
  • the exploration servers form a network, and, upon receipt of a message, each exploration server is able to forward the message to another exploration server closer to the fragment server sought, so that 'after a while, the message reaches the exploration server knowing the fragment server, and then the fragment server itself.
  • This interface is also capable of creating a fragment server if it does not exist for the requested URL. This is illustrated in figure Fig. 44.
  • Each category is associated with a particular server, whose role is on the one hand to reference all the fragments that the associated category contains, and on the other hand to receive suggestions of fragments, which it can then accept or refuse .
  • each category will thus reference a set of over-categories as well as a set of sub-categories (see section “Merging of categories”).
  • FIG. 45 is illustrated an overview of the architecture of the system, with the three types of servers.
  • the crawl (n) message asks a fragment server to ensure that a depth of n fragment is known from it.
  • fragment server If a fragment (fragment server) does not know its context, it will send itself this message.
  • Each fragment receiving a crawl (n) message will return crawl (n-l) to all of its fragments.
  • a fragment server regularly checks to see that its set of fragments has not changed.
  • the fragment will say if it has already received an identical message (by comparing the value of Po transmitted), to save traffic in steps (3) and (6). In fact, it will accept the first such message, and respond with its list of categories.
  • the server P 0 manages the list of categories
  • each fragment server is responsible for categorizing. In other words, when a new category is created, it is sent to all the fragments (those which take part in the categorization, i.e. those which have a common context), which will then propose themselves to the category.
  • the context receives messages from fragments that have not yet been categorized, it will choose among them those who most deserve to create a new category, and send its address to the initial fragment. This decision is made by considering the best score obtained by the fragment for a category. If all the fragments for which the context is responsible are properly categorized, they say so to the initial fragment. (10a) If there are still uncategorized fragments, the initial fragment will choose one (among those which had already been selected in point 9), and create a new category. It will then transmit, via its contexts, this new category to all the fragments. Then we resume at point 7 with this new category.
  • the categorization algorithm works as follows:
  • This source consists of:
  • Po will have received sets of poorly categorized fragments, and will be able to choose M.
  • messages pass from user to fragments (hypertext links), and, for new fragments, from the fragment to its exploration server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • User Interface Of Digital Computer (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé permettant de composer de manière semi-automatique des ressources d'information, notamment des documents, organisées selon une structure arborescente de références sur des fragments d'informations notamment distants, ainsi que différents systèmes et procédés pour gérer de telles ressources. Le procédé est remarquable en ce qu'il permet de composer une ressource d'informations, notamment un document, organisée selon une structure arborescente de noeuds, selon les étapes suivantes: pour au moins un noeud de la ressource, agencer ledit noeud comme un fragment comportant ledit noeud comme noeud racine du fragment et tous les sous-noeuds dudit noeud racine, associer à au moins un fragment de la ressource une référence de mise à jour vers un fragment amont, pour former un fragment aval, associer à au moins un sous-noeud du fragment aval une référence de non-mise à jour, de telle sorte que le contenu du fragment aval est composé à partir du contenu du fragment amont, et le cas échéant à partir de contenus d'autres fragments, à l'exception du contenu de chaque sous-fragment correspondant à chaque sous-noeud auquel est associée une référence de non-mise à jour. L'invention concerne aussi un système associé.

Description

SYSTÈME ET PROCÈDE PERMETTANT L'IMPORTATION SEMI- AUTOMATIQUE DE FRAGMENTS DE RESSOURCES D'INFORMATIONS
La présente invention a pour objectif principal de pouvoir composer de manière semi-automatique des ressources d'information, notament des documents, organisées selon une structure arborescente de références sur des fragments d'informations notamment distants, ainsi que différents systèmes et procédés pour gérer de telles ressources.
Une application typique visée par la présente invention est un système de veille collaborative sur la Toile ayant deux caractéristiques principales :
- l'utilisateur alimente un « portail personnel » en assemblant, par de simples glisser-déposer, des fragments des pages de la Toile intéressants qu'il découvre sur la Toile et, au fur et à mesure de l'enrichissement de ce portail personnel, l'outil lui suggère automatiquement de nouveaux fragments de pages de la Toile de plus en plus pertinents ;
- chaque utilisateur bénéficie des découvertes des autres utilisateurs : par de simples glisser-déposer, ou sur suggestion automatique du système, l'utilisateur peut puiser dans les pages des autres portails personnels des fragments qui l'intéressent.
Un premier aspect d'un premier objet de de la présente invention vise à permettre de composer une ressource d'informations, notamment d'un document, organisée selon une structure arborescente de nœuds, selon les étapes suivantes :
- pour au moins un nœud de la ressource, agencer ledit nœud comme un fragment comportant ledit nœud comme nœud racine du fragment et tous les sous-nœuds dudit nœud racine,
- associer à au moins un fragment de la ressource une référence de mise àjour vers un fragment amont, pour former un fragment aval,
- associer à au moins un sous-nœud du fragment aval une référence de non-mise àjour, de telle sorte que le contenu du fragment aval est composé à partir du contenu du fragment amont, et le cas échéant à partir de contenus d'autres fragments, à l'exception du contenu de chaque sous-fragment correspondant à chaque sous-nœud auquel est associée une référence de non-mise àjour.
Plus précisément, la présente invention vise à permettre de composer une ressource d'informations, organisée selon une structure arborescente de nœuds, selon les étapes suivantes :
- pour au moins un nœud de la ressource, agencer ledit nœud comme un fragment comportant ledit nœud comme nœud racine du fragment et tous les sous-nœuds dudit nœud racine,
- associer à au moins un fragment de la ressource une référence de mise àjour vers un fragment amont, pour former un fragment aval,
- le cas échéant, associer à au moins un sous-nœud inclus dans un premier fragment aval, une référence de mise àjour vers un autre fragment amont, pour former un deuxième fragment aval qui est sous-fragment dudit premier fragment aval,
- le cas échéant, associer à au moins un sous-nœud d'un fragment aval une référence de non- mise àjour vers le sous-nœud correspondant du fragment amont correspondant, de telle sorte que le contenu de chaque fragment aval est composé notamment à partir du contenu du fragment amont correspondant, à l'exception du contenu de chaque sous-fragment correspondant à chaque sous-nœud auquel est associée une référence de non-mise àjour.
Selon un autre aspect avantageux, le procédé comprend l'étape suivante : - lors de la composition d'un fragment amont telle que ce dernier contienne au moins un sous- fragment supplémentaire, composer le fragment aval en incluant ledit sous-fragment supplémentaire.
Alternativement, le procédé comprend en outre l'étape suivante :
- lors de chaque composition d'un fragment aval, utiliser la référence de mise àjour vers le fragment amont pour inclure dans le fragment aval tout sous-fragment supplémentaire du fragment amont.
D'autres aspects préférés mais non limitatifs sont les suivants :
- lesdits fragments supplémentaires sont ceux qui n'ont pas encore été complètement pris en compte à l'aval ;
- la composition dans ledit fragment aval d'un sous-fragment supplémentaire inclut une indication d'un mode suggéré dudit nouveau sous-fragment ;
- la composition dans ledit fragment aval, d'un sous-fragment supplémentaire, est effectué à condition qu'une indication d'un mode accepté soit associé audit sous-fragment supplémentaire dans la ressource amont ;
- le procédé comprend en outre l'étape consistant à sélectionner les sous-fragments les plus pertinents parmi les sous-fragments supplémentaires avant de les suggérer dans le sous-fragment aval.
- ladite association d'une référence résulte d'une opération de glisser-déposer de la présentation d'un fragment à l'écran d'affichage, au moyen d'un dispositif de pointage tel qu'une souris.
- ladite association d'une référence de mise àjour résulte en la création, sous le fragment aval, de nouveaux sous-nœuds correspondant aux sous-nœuds du fragment amont.
Selon un autre aspect, l'invention propose un système de composition d'une ressource d'informations, notamment d'un document, organisée selon une structure arborescente de nœuds,
- ayant au moins un nœud de la ressource agencé comme un fragment comportant ledit nœud comme nœud racine du fragment et tous les sous-nœuds dudit nœud racine,
- avec au moins un fragment de la ressource ayant, associé à lui, une référence de mise à jour vers un fragment amont, pour former un fragment aval,
- avec, le cas échéant, au moins un sous-nœud d'un fragment aval ayant, associé à lui, une référence de non-mise àjour vers le sous-nœud correspondant du fragment amont correspondant, caractérisé en ce qu'il comprend des moyens pour composer le contenu de chaque fragment aval notamment à partir du contenu du fragment amont correspondant, à l'exception du contenu de chaque sous-fragment correspondant à chaque sous-nœud auquel est associée une référence de non-mise àjour.
Certains aspects préférés mais non limitatifs incluent les suivants :
- le système est caractérisé par le fait que la ressource inclut au moins un nœud qui est inclus dans un premier fragment aval et qui a, associé à lui, une référence de mise àjour vers un autre fragment amont, pour former un deuxième fragment aval qui est sous-fragment dudit premier fragment aval, et que ledits moyens permettent de composer ledit deuxième fragment aval à partir du contenu dudit autre fragment amont ;
- le système comprend des moyens pour agencer au moins un nœud de la ressource comme un fragment ; - le système comprend des moyens pour associer, à au moins un fragment de la ressource, une référence de mise àjour vers un fragment amont, pour former un fragment aval ;
- le système comprend des moyens pour associer, à au moins un sous-nœud d'un fragment aval, une référence de non-mise àjour vers le sous-nœud correspondant du fragment amont correspondant ;
- le système comprend des moyens pour associer, à au moins un nœud inclus dans un premier fragment aval, une référence de mise àjour vers un autre fragment amont, pour former un deuxième fragment aval qui est sous-fragment dudit premier fragment aval.
Un autre objet de la présente invention concerne un système et un procédé permettant de manipuler, notamment de reproduire (importer) d'un site à l'autre, des fragment de sources XML représentant par exemple des contenus d'information ou des services, présentés pour affichage à l'écran à travers des feuilles de style, en n'agissant que sur leur présentation d'affichage à l'écran.
Cet objet de l'invention permet une nouvelle utilisation des contenus des sites sur la Toile. Un fragment de source XML permettant par exemple de présenter un service sur la Toile peut être reproduit d'un site à l'autre, par les propriétaires des sites respectifs, et configuré automatiquement en fonction des spécificités du site d'accueil.
Pour reproduire un fragment, on utilise des objets graphiques servant de « poignée » et/ou de « cible » associés à la présentation des fragments. Une poignée sert à attraper un fragment, pour notamment le glisser-déposer à l'endroit où l'on veut le reproduire, cet endroit étant indiqué graphiquement par une cible. Ces objets graphiques apparaissent sur simple demande de l'utilisateur en cliquant sur un bouton qui est facile à mettre en œuvre.
Au moment du glisser-déposer, le fragment importé peut être adapté automatiquement, voire refusé, pour satisfaire les contraintes ou préférences du récipient cible, et les conditions d'un accord (ou contrat) à conclure le cas échéant entre les propriétaires des sites de part et d'autre du transfert, peuvent être proposées automatiquement d'abord à l'utilisateur qui effectue le glisser- déposer, ensuite et de manière asynchrone (notamment au moyen d'un courrier électronique) à l'autre partie.
Les sources XML des pages Web sont décomposées automatiquement
- en unités atomiques (indivisibles), appelées microstructures,
- et en une structure d'assemblage appelée macrostructure.
Enfin, la macrostructure peut avantageusement être placée dans un serveur différent de celui où réside les microstructures. La gestion de la macrostructure peut ainsi être confiée à une entité tierce, notamment à un « tiers de confiance » librement choisi par les utilisateurs qui partagent de mêmes fragments de documents. La gestion des documents, qui comportent de multiples références à des fragments d'autres documents, est ainsi fiabilisée.
Ainsi cet objet de l'invention propose un procédé de manipulation de documents utilisables notamment pour le travail collaboratif à travers un réseau tel que l'Internet, permettant à l'utilisateur de manipuler des fragments desdits documents, lesdits documents étant d'une part dans leur forme brute constitués d'une structure arborescente composée de nœuds possédant des informations et des attributs et représentés notamment en langage XML, lesdits documents étant d'autre part présentés pour affichage ou autre interface, notamment en langage HTML et scripts, après transformation par programmes, règles de réecriture ou feuilles de styles notamment en langage XSL, caractérisé en ce qu'il comprend les étapes suivantes : (a) des moyens interactifs, permettant de manipuler lesdits fragments notamment avec un dispositif de pointage tel qu'une souris, sont assemblés dynamiquement au moment de la construction de ladite présentation à partir de la forme brute d'un document pour affichage en mode manipulation ;
(b) l'utilisateur utilise certains de ces moyens interactifs pour manipuler lesdits fragments dans leur présentation d'affichage en mode manipulation;
(c) en conséquence le système met àjour dans ledit document dans sa forme brute chaque fragment ayant donné lieu en l'étape (a) à l'assemblage de moyens utilisés en l'étape (b).
Le procédé comprend avant l'étape (a) une étape dans laquelle l'utilisateur requiert une présentation d'affichage en mode manipulation.
Ladite requête s'effectue en utilisant un bouton ou dispositif analogue.
Ledit bouton ou dispositif analogue est utilisé pour requérir la version en mode manipulation d'une présentation couramment affichée en mode normal.
Ledit bouton ou dispositif analogue est présenté sous la forme d'un objet graphique faisant partie de ladite présentation d'affichage en mode normal, ledit objet graphique étant activable au moyen d'un dispositif de pointage tel que la souris pour faire basculer au mode manipulation ladite présentation couramment affichée en mode normal.
Ledit basculement au mode manipulation est effectué pour une région sélectionnée par l'utilisateur le cas échéant ou si aucune région n'a été sélectionnée pour toute ladite présentation.
Ledit bouton ou dispositif analogue est utilisé en combinaison avec l'action qui aurait permis de soumettre une requête d'affichage en mode normal.
Ladite requête s'effectue de manière très légèrement différente de celle pour obtenir la présentation d'affichage en mode normal, ladite différence consistant notamment à ajouter un ensemble de caractères, tel que par exemple le mot "admin" précédé du caractère "/",
- à la fin du texte de la requête d'affichage en mode normal
- ou dans le texte de la requête d'affichage en mode normal, juste après le nom de domaine.
En l'étape (a) lesdits moyens interactifs sont mis en oeuvre après prise de connaissance par le système
- de l'existence,
- la position dans la structure arborescente du document
- et les attributs desdits nœuds fragments et de leurs nœuds parents dans lesdits documents dans leur forme brute.
En l'étape (b) ladite manipulation a pour but d'éditer le contenu d'un fragment et résulte en l'étape (c) en la modification dudit contenu.
En l'étape (b) ladite manipulation a pour but de déplacer ou reproduire un fragment, notamment d'un site Internet à l'autre, et en ce qu'elle résulte en l'étape (c) en l'insertion dudit fragment et/ou d'une référence audit fragment sous un noeud ayant un attribut de délimitation (récipient).
Lesdits moyens interactifs comportent des objets graphiques utilisables avec un dispositif de pointage tel que notamment une souris tels que l'étape (b) s'effectue par une opération de glisser-déposer d'un premier objet graphique (poignée) associé à un premier fragment - notamment à reproduire ou déplacer - sur un deuxième objet graphique (cible) associé à un deuxième fragment, l'étape (c) ladite mise àjour - notamment l'insertion dudit fragment à reproduire ou déplacer - s'effectue au moins à l'emplacement déterminé par les propriétés dudit deuxième objet graphique (cible).
Au préalable chaque document dans sa forme brute est décomposé en une macrostructure et une ou plusieurs microstructures dont au moins une référence sur chacune d'elles se trouve dans ladite macrostructure et le procédé comprend avant l'étape (a), une étape consistant à recomposer, à partir de ladite macrostructure et lesdites microstructures, le document dans sa forme brute.
Ladite décomposition comprend les étapes suivantes :
- lors de la création ou d'une mise àjour dudit document, insérer dans celui-ci des attributs de délimitation (récipient) aptes chacun à distinguer les fragments représentés par chaque nœud dont le nœud parent possède ledit attribut de délimitation,
- extraire lesdits fragments, c'est-à-dire les informations délimitées par chaque nœud dont le nœud parent possède ledit attribut de délimitation, ladite extraction étant effectuée d'abord sur ledit document et ensuite récursivement sur les informations elle-mêmes extraites, et créer d'une part un ensemble de microstructures chacune étant constituée du reste des informations extraites à l'aval dans ledit traitement récursif, auquel a été ajouté des attributs de position (récipient-id) indiquant à quelles positions se trouvaient ledites informations extraites et d'autre part une macrostructure dudit document constituée par une structure arborescente plus grossière que ladite structure arborescente du document, dans laquelle : chaque nœud dont le nœud parent possède ledit attribut de délimitation (récipient) est remplacé par une référence à une microstructure, chaque nœud possédant lui-même ledit attribut de délimitation (récipient) est remplacé par un nœud (récipient) indiquant la position (recipient-id) desdites microstructures extraites à l'aval dans ledit traitement récursif et tous les nœuds qui ne possèdent pas ledit attribut de délimitation et dont le nœud parent ne possède pas non plus ledit attribut de délimitation sont absents.
Alternativement, ladite décomposition comprend les étapes suivantes : lors de la création dudit document d'origine, insérer dans celui-ci des attributs de délimitation aptes chacun à regrouper des nœuds descendants avec un nœud parent desdits nœuds descendants, extraire les informations situées aux nœuds regroupés, ladite extraction étant effectuée d'abord sur ledit document et ensuite récursivement sur les informations elle-mêmes extraites, et créer d'une part un ensemble de microstructures constituées des restes des informations extraites auxquels ont été ajouté des attributs indiquant à quelles positions se trouvaient les informations extraites à l'aval dans ledit traitement récursif et d'autre part une macrostructure du document constituée par une structure arborescente plus grossière que ladite structure arborescente de document, dans laquelle lesdits nœuds parents correspondant à des regroupements sont remplacés par des références auxdites informations extraites, indiquant la position desdites informations extraites dans la structure, et dans laquelle lesdits nœuds descendants qui ne sont pas eux-mêmes des nœuds parents sont absents.
L'étape (c) comprend des actions dans lesquelles une ou plusieurs nouvelles références
- soit à une microstructure, - soit à un nœud qui se trouve dans une macrostructure et dont un nœud ancêtre possède ledit attribut de délimitation (récipient), peuvent être insérés ou supprimés au niveau d'un nœud qui possède ledit attribut de délimitation.
Lesdites microstructures sont atomiques.
Les informations extraites à chaque niveau dans ledit traitement récursif constituent un fragment accessible dont la structure est représentée dans ladite macrostructure, et ledit fragment est constitué d'une microstructure ou de plusieurs microstructures imbriquées.
Ladite recomposition avant l'étape (a) peut avoir comme effet l'insertion d'attributs supplémentaires sur les nœuds mais en aucun cas n'a comme effet de modifier la structure des nœuds du document dans sa forme brute.
Lors de l'application des feuilles de style, et d'autres programmes de transfoπnations le cas échéant, dans l'étape (a) du procédé, le système transforme en XHTML ledit document sauf tous les fragments dont un style local est préféré ; ces derniers sont copiés intégralement afin que leur transformation puisse être effectuée lors d'un prochain passage dans le cadre d'un procédé itératif dans lequel à chaque passage, les fragments qui n'ont pas encore été transformés en XHTML sont transformés à leur tour, jusqu'à que tous les fragments aient été traités.
En l'étape (c) du procédé : une nouvelle version de chaque référence à fragment modifié et de chaque microstructure modifié le cas échéant est créée et les anciennes versions des fragments et microstructures (au moins celles sur lesquelles aucune macrostructure ne pointe) sont supprimées.
Le procédé fournit au moins un mécanisme permettant d'automatiser au moins l'une des étapes sus-mentionnées.
Un autre objet de l'invention est un système de traitement de données destiné à présenter des documents sur un dispositif d'affichage ou équivalent et permettant de manipuler des fragments desdits documents notamment dans le cadre d'un travail collaboratif, lesdits documents étant d'une part dans leur forme brute constitués d'une structure arborescente composée de nœuds possédant des informations et des attributs, et représentés notamment en langage XML, et d'autre part présentés pour affichage notamment en langage HTML et scripts, après traduction par programmes, règles de réecrirure ou feuilles de styles notamment en langage XSL, caractérisé en ce qu'il comprend des moyens interactifs comportant des objets graphiques associés auxdits fragments et placés au sein de ladite présentation d'affichage, permettant à l'utilisateur d'effectuer ladite manipulation simplement en agissant sur lesdits objets graphiques au moyen d'un dispositif de pointage tel que la souris, en ce qu'il est apte à assembler et mettre en oeuvre lesdits moyens interactifs dynamiquement, à la volée, à l'appel de l'affichage desdits fragments, à partir notamment d'informations associées auxdits fragments des documents dans leur forme brute et en ce que lesdits objets graphiques possèdent des informations permettant au système de retrouver quels sont les fragments des documents dans leur forme brute à mettre àjour en fonction des actions de l'utilisateur.
Lesdites manipulations consistent à modifier le contenu de fragments existants ou à en créer de nouveaux.
Lesdites manipulations consistent à reproduire ou déplacer des fragments d'un site Internet à l'autre. Ladite présentation d'affichage est construite à partir de documents, dans leur forme brute, recomposées comme déjà mentionné.
Lesdits moyens interactifs sont restreints en fonction des droits d'action associés auxdits utilisateurs.
Le système est apte à décider de l'existence et la nature desdits moyens interactifs à mettre en œuvre en association avec chaque fragment d'un document dans sa forme brute, en fonction de l'existence ou la valeur d'attributs spécifiques possédés par ledit fragment le cas échéant.
Le système est apte à assembler et mettre en oeuvre des moyens interactifs différents pour des types différents d'information contenue dans lesdits fragments des documents dans leur forme brute.
Le système est apte à déterminer le choix des moyens interactifs à assembler à partir des balises et attributs ou autres marqueurs caractérisant les noeuds contenus dans lesdits fragments des documents dans leur forme brute.
Ledit choix s'effectue en combinaison avec les informations contenues dans les schéma de données auquels se conforment lesdits fragments des documents dans leur forme brute.
Les créations, déplacements ou reproductions de fragments causés par l'utilisation desdits moyens interactifs résultent automatiquement en de nouveaux fragments et/ou en de nouvelles références à fragments insérés dans les documents dans leur forme brute à des positions découlant desdites actions de l'utilisateur.
Lesdits nouveaux fragments et/ou références à fragments sont insérés
- sous un nœud possédant un attribut spécifique de délimitation (récipient)
- et entre des nœuds fragments déjà existants le cas échéant.
La position de chaque nouveau fragment ou référence à fragment inséré suite à une action de l'utilisateur est déterminée à partir d'informations mémorisées en association avec lesdits objets graphiques utilisés dans le cadre de ladite action.
Le système est apte à placer dans la présentation d'affichage lesdits objets graphiques, à partir d'une prise de connaissance de l'existence et la position dans la structure arborescente du document dans sa forme brute, ainsi que des attributs spécifiques, de nœuds possédant un attribut de délimitation (récipient) et de nœuds fragments.
Des moyens interactifs distincts sont mis en oeuvre pour chaque nœud d'un document dans sa forme brute possédant un attribut de délimitation (récipient) qui possède également un attribut indiquant le fait que les fragments qu'il délimite sont manipulables avec lesdits moyens.
La présentation d'affichage d'un fragment manipulable d'un documents dans sa forme brute comprend un objet graphique (bouton) permettant de le sélectionner au moyen d'un dispositif de pointage afin notamment de consulter des aspects dudit fragment qui ne sont pas affichés ou d'éditer le contenu, les propriétés, les liens ou la feuille de style permettant la présentation dudit fragment.
La présentation d'affichage d'un premier fragment manipulable d'un document dans sa forme brute comprend un objet graphique (poignée) associé audit premier fragment et permettant de le glisser-déposer au moyen d'un dispositif de pointage sur un objet graphique (cible) associé à un deuxième fragment manipulable d'un document dans sa forme brute. L'objet graphique (bouton) permettant de sélectionner un fragment est également un objet graphique (poignée) permettant de le glisser-déposer sur un objet graphique (cible).
L'objet graphique (bouton) permettant de sélectionner un fragment est également un objet graphique (cible) sur lequel l'utilisateur peut glisser-déposer un objet graphique (poignée).
Ladite opération de glisser-déposer permet de déplacer ou reproduire ledit premier fragment à l'emplacement indiqué par l'objet graphique (cible) associé audit deuxième fragment.
Ladite opération de glisser-déposer permet de créer un lien mémorisé entre ledit premier fragment et ledit deuxième fragment.
Ladite opération de glisser-déposer permet de créer une proposition de contrat entre le propriétaire dudit premier fragment et le propriétaire dudit deuxième fragment.
Ledit objet graphique associé à un deuxième fragment est situé dans la même page que ledit objet graphique associé à un premier fragment.
Ledit objet graphique associé à un deuxième fragment est situé dans une page différente que celle dudit objet graphique associé à un premier fragment.
Ledit objet graphique associé à un deuxième fragment est situé dans une page d'un site différent de celui dudit objet graphique associé à un premier fragment.
L'objet graphique poignée associé audit premier fragment est également un objet graphique cible et permet en conséquence de glisser-déposer sur lui un objet graphique associé à un autre fragment.
Un autre objet de la présente invention concerne des nouvelles fonctionnalités ajoutés à un navigateur Internet.
Classiquement, un outil de navigation sur l'Internet comprend des moyens pour accéder à des pages en langage HTML ou autre, soit par saisie directe de l'adresse URL de la page à atteindre, soit en cliquant à l'aide du bouton d'une souris sur un lien contenu dans une page, qui pointe vers une autre page.
On connaît également les techniques de « signets » (boomarks en terminologie anglo-saxone), « marque-pages », « favoris », etc. qui permettent à un utilisateur, lorsqu'il consulte une page courante, de mémoriser et de classer, dans une structure arborescente de répertoires ou dossiers, des liens vers ces pages, qui permettront à l'utilisateur, dans le futur, d'accéder à nouveau à ces pages par un simple clic de souris après avoir le cas échéant ouvert le répertoire correspondant.
Ces techniques connues présentent toutefois un certain nombre de limitations. En particulier :
- lorsque l'utilisateur est en train de consulter une page courante, il lui est systématiquement nécessaire, pour consulter d'autres pages susceptibles de traiter du même sujet, d'entrer dans la structure arborescente de répertoires de « signets », « marque-pages », « favoris » ou autres et de naviguer dans cette structure pour retrouver les liens vers lesdites pages ;
- l'utilisateur est contraint par une structure arborescente de répertoires, au sein de laquelle la navigation locale d'un répertoire à l'autre peut se trouver extrêmement fastidieuse dès que le nombre de répertoires, sous-répertoires et liens devient importante ;
- les outils existants ne sont susceptibles que de créer des liens unidirectionnels situés dans un répertoire donné et pointant vers une page, et il n'existe aucun moyen, au cours de la consultation d'une page courante, pour associer à cette page et non pas à un répertoire, des liens vers d'autres pages. La présente invention vise à pallier ces limitations de l'état de la technique et à proposer un système de navigation qui permette, d'une manière extrêmement simple et intuitive, d'accéder à des pages portant sur des sujets que l'utilisateur a considéré comme pertinents en relation avec la page courante.
Un autre objet de la présente invention est de proposer à l'utilisateur des moyens extrêmement simples et intuitifs de création de liens d'une page vers une autre, avec le cas échéant une bidirectionnalité, et ceci indépendamment de toute structure de répertoires de liens.
Un autre objet encore de la présente invention est de permettre à un utilisateur de bénéficier, sélectivement, de liens créés par des tiers en relation avec ses propres sujets d'intérêt.
Ainsi l'invention propose un système de navigation mis en œuvre dans un système informatique pour accéder à des pages fournies notamment par des serveurs via un réseau informatique par activation de liens, caractérisé en ce qu'il comprend en combinaison :
- des moyens pour afficher une page courante,
- des moyens permettant à un utilisateur de créer et de mémoriser, au sein d'une structure de groupes de liens, des liens dont ladite page constitue une extrémité ;
- des moyens de sélection et d'affichage aptes, lors de l'affichage d'une page constituant une extrémité d'au moins un lien, à sélectionner et afficher une partie de la structure de groupes de liens contenant ce ou ces liens, et
- des moyens d'entrée permettant à l'utilisateur de sélectionner et d'activer les liens affichés contenus dans ladite partie de la structure de groupes de liens.
Des aspects préférés, mais non limitatifs, du système selon cet objet de l'invention sont les suivants :
- lesdits liens comprennent des liens ajoutés, associés à ladite page courante et permettant d'accéder à d'autres pages, et les moyens d'affichage sont aptes à afficher des représentations desdits liens ajoutés activables directement par lesdits moyens d'entrée.
- les moyens de création de liens ajoutés comprennent un moyen d'entrée permettant à l'utilisateur de glisser-déposer la page courante ou un élément affiché représentant la page courante vers une autre page affichée ou un élément affiché représentant ladite autre page.
- il est prévu une zone d'affichage de liens ajoutés associée à ladite page courante et apte à contenir lesdits éléments affichés représentant les liens ajoutés vers lesdites autres pages.
- le système comprend des moyens pour afficher la page courante et sa zone d'affichage de liens ajoutés associée et des moyens pour afficher les zones d'affichage de liens d'une pluralité d'autres pages, de façon contiguë les unes aux autres.
- chaque zone d'affichage de liens ajoutés contient également un élément affiché représentant la page à laquelle lesdits liens ajoutés sont associés, et les moyens de création de liens ajoutés mettent en œuvre des opérations de glisser-déposer entre les éléments affichés représentant les pages et les éléments affichés représentant les liens ajoutés.
- le système comprend des moyens pour afficher, sous la commande d'un moyen d'entrée agissant sur une zone donnée d'affichage de liens ajoutés, la page à laquelle lesdits liens ajoutés sont associés.
- lesdits éléments affichés représentant les pages auxquelles les liens ajoutés sont associés et lesdits liens ajoutés sont constituées par des images miniaturisées desdites pages associées ou des pages vers lesquelles pointent lesdits liens ajoutés. - lesdits liens ajoutés sont sélectivement monodirectionnels ou bidirectionnels.
- ladite structure de groupes de liens est une structure arborescente de répertoires contenant chacun d'autres répertoires et/ou des liens créés.
- lesdits liens comprennent des marque-pages, et les moyens de sélection et d'affichage sont aptes à afficher les seuls groupes des liens contenant un marque-page correspondant à la page courante.
- les moyens de sélection et d'affichage sont aptes à afficher dans une première zone des éléments affichés représentant des liens ajoutés, et dans une seconde zone des répertoires de marque-pages contenant un marque-page correspondant à la page courante.
- la seconde zone sont affichés par une représentation hiérarchique lesdits répertoires de marque- pages et, sélectivement, les contenus desdits répertoires.
- le système comprend des moyens pour afficher une pluralité de répertoires contenant des premiers éléments affichés constituant des liens vers des pages et secondes représentations graphiques constituant des liens ajoutés entre lesdites pages, et des moyens pour manipuler par glisser-déposer lesdites premières et secondes représentations graphiques pour ajouter, supprimer ou déplacer d'un répertoire à l'autre des liens vers des pages ou des liens ajoutés entres pages.
- lesdits liens vers des pages constituent lesdits marque-pages.
- le système comprend des moyens pour mémoriser, en association avec une pluralité d'utilisateurs de postes clients, une pluralité de tables de liens désignant, pour chaque page constituant une extrémité d'un lien créé, le ou chacun de ces liens.
- les moyens de création de liens sont aptes à être commandés par des moyens de traitement comparatif de ladite pluralité de tables de liens, pour créer des liens dans un état dit suggéré.
- le système comprend des moyens pour afficher des éléments affichés représentant chaque lien créé dans ledit état suggéré et, en association avec chacun desdits éléments, des moyens sensibles à un dispositif d'entrée pour modifier l'état du lien correspondant.
- les moyens de modification de l'état d'un lien créé dans l'état suggéré comprennent des moyens pour supprimer le lien.
- les moyens de modification de l'état d'un lien créé dans l'état suggéré comprennent des moyens pour valider le lien en l'amenant dans un état accepté.
- les moyens de modification de l'état d'un lien dans l'état suggéré ou accepté comprennent des moyens pour valider le lien en l'amenant dans un état gelé.
- le système comprend en outre des moyens pour ajuster chaque lien amené à l'état gelé sur une adresse à laquelle le contenu de la page a été mémorisé.
- le système comprend en outre des moyens capables, sous la commande de l'utilisateur, d'affecter à tout lien accepté ou gelé un attribut de caractérisation du type d'intérêt porté par l'utilisateur au contenu désigné par ledit lien.
- les attributs de caractérisation comprennent un attribut « Offreur » et un attribut « Demandeur ».
- lesdits moyens de traitement comparatif sont aptes à prendre en compte les attributs de caractérisation donnés aux liens.
- le système comprend, en association avec chaque élément affiché représentant un lien créé, un moyen de codage graphique pour désigner l'état dudit lien. - le moyen de codage graphique comprend un codage de couleur dans un cadre entourant ledit élément affiché.
- le système comprend en outre des moyens commandés par l'utilisateur pour paramétrer le traitement comparatif effectué sur ladite pluralité de tables de liens.
- les moyens de paramétrage commandés par l'utilisateur comprennent des moyens de sélection des utilisateurs pour les tables de liens desquels le traitement comparatif est effectué.
- lesdits moyens de traitement comparatif opèrent sur une pluralité de tables de liens contenant seulement les liens créés validés.
- le système comprend des moyens pour suggérer à un utilisateur, en association avec l'accès à une première page, un lien ajouté bidirectionnel avec une seconde page, ladite seconde page étant choisie par ledit système en fonction notamment de sa pertinence pour l'utilisateur au regard de la première page de telle manière que lors de l'accès ladite seconde page, le lien ajouté inverse, de ladite seconde page vers ladite première page, puisse être activé par l'utilisateur.
- ladite seconde page est choisie par le système également en fonction de la fréquence d'accès à celle-ci par l'utilisateur.
- ladite seconde page est choisie par le système également en fonction du nombre de liens ajoutés préexistants associés à ladite seconde page.
- le système comprend des moyens de traitement de ladite seconde page de manière à y inclure une élément d'affichage dudit lien inverse.
- les moyens de traitement sont paramétrables.
- les moyens de traitement sont aptes à inclure ledit élément d'affichage du lien inverse en un emplacement de la seconde page normalement destiné à comporter un bandeau publicitaire ou analogue.
- le système comprend en outre des moyens de sélection par l'utilisateur de groupes extérieurs de liens et les moyens de sélection et d'affichage sont également aptes, lors de l'affichage d'une page, à afficher les liens d'au moins un groupe extérieur de liens sélectionné.
- les groupes extérieurs de liens comprennent au moins l'un parmi :
- des groupes de liens présélectionnés par un administrateur de la page,
- des groupes de liens présélectionnés par le système comme étant proches d'au moins un groupe de liens propre à l'utilisateur,
- des groupes de liens établis par le système comme étant pertinents vis-à-vis d'au moins un groupe de liens propre à l'utilisateur, et
- des groupes de liens présélectionnés par l'utilisateur.
- lesdits liens sont situés dans des contenants définis dans la structure de la page courante, et pointent vers des contenants aptes à enrichir ladite page courante en des emplacements définis par la position desdits contenants dans ladite structure.
Un autre objet de la présente invention d'exploiter de façon plus pérenne les parcours antérieurs de navigation d'un utilisateur pour qu'il puisse les mettre à profit au cours d'une navigation courante.
Il existe dans les navigateurs classiques un outil (typiquement des boutons « précédent » et « suivant » activables par souris) , le bouton « précédent » permettant à un utilisateur de parcourir pas à pas le chemin inverse de celui qu'il vient de parcourir d'une page à l'autre au cours de sa navigation, ce chemin inverse étant toutefois limité typiquement à une dizaine de retours en arrière.
Cette possibilité de parcourir des chemins inverses est basée sur une mémoire temporaire, au niveau du navigateur du poste client, contenant les N dernières adresses des pages sucessivement parcourues.
On comprend que cette technique connue de navigation en arrière est extrêmement rudimentaire.
Ainsi l'invention propose un système de navigation mis en œuvre dans un système informatique pour accéder au niveau d'un poste client à des pages fournies notamment par des serveurs via un réseau informatique par activation de liens, caractérisé en ce qu'il comprend en combinaison : des moyens de détection de l'existence d'un lien d'une page d'origine consultée vers une page de destination consultée, des moyens de mémorisation d'une information d'identification de ladite page de destination consultée et, en association avec ladite information d'identification, d'une information d'identification de ladite page d'origine consultée, et des moyens d'affichage de liens inverses aptes, lorsqu'un poste client connecté au système accède ladite page de destination, à utiliser l'information d'identification de ladite page de destination pour retrouver dans lesdits moyens de mémorisation l'information d'identification de ladite page d'origine et pour afficher sur le poste client en association avec ladite page de destination, un élément activable constituant un lien vers ladite page d'origine.
Des aspects préférés, mais non limitatifs, du système selon l'invention sont les suivants :
- les moyens de détection sont aptes à détecter une action de souris sur un lien vers ladite page de destination, contenu dans la page d'origine consultée ou associé à elle.
- les moyens d'affichage de liens inverses sont aptes à afficher sur le poste client une pluralité d'éléments activables constituant des liens vers une pluralité de pages d'origine différentes.
- les moyens d'affichage de liens inverses sont aptes à n'afficher que des éléments activables constituant des liens vers des pages sélectionnées pour leurs caractéristiques de contenu par rapport à un profil de l'utilisateur du poste client.
- les moyens de mémorisation sont aptes à mémoriser des informations d'identification de pages d'origine en association avec des informations d'identification de pages de destination sur une base utilisateur par utilisateur, tandis que les moyens d'affichage de liens inverses sont aptes à retrouver dans lesdits moyens de mémorisation les informations d'identification des pages d'origine en utilisant également une information d'identification de l'utilisateur.
- les moyens de mémorisation sont aptes à mémoriser, pour chaque utilisateur qui consulte une page de destination par l'activation d'un lien associé à une page d'origine, l'information d'identification de ladite page d'origine en association avec l'information d'identification de ladite page de destination et ladite information d'identification de l'utilisateur.
- le système comprend en outre des moyens de suppression aptes, au moins lors du premier affichage d'éléments activables, à supprimer à l'initiative de l'utilisateur l'affichage d'au moins un élément activable.
- il est prévu des moyens aptes, lors de la suppression d'un élément activable par l'utilisateur, à supprimer, dans les moyens de mémorisation, l'information d'identification de la page d'origine concernée par ledit élément activable en association avec l'information d'identification de la page de destination. - les moyens d'affichage de liens inverses sont aptes à afficher dans un état suggéré les éléments activables des liens correspondants vers les pages d'origine, tandis qu'il est prévu en outre des moyens de modification d'état aptes, lors de chaque affichage d'un élément activable dans l'état suggéré, à faire passer à l'intiative de l'utilisateur ledit élément activable dans un état accepté ou dans un état refusé.
- les moyens de modification d'état sont également aptes à faire passer à l'intiative de l'utilisateur le lien correspondant dans un état gelé, tandis qu'il est prévu des moyens pour mémoriser la page d'origine correspondante dans son état courant et pour permettre l'accès à ladite page d'origine mémorisée dans son état courant à partir de l'élément activable correspondant.
- les moyens d'affichage de liens inverses sont aptes à afficher les éléments activables dans au moins une zone d'affichage contenue dans la page de destination.
- les moyens d'affichage de liens inverses sont aptes à afficher les éléments activables de façon adjacente à une zone d'affichage occupée par la page de destination.
- lesdits éléments activables sont constitués par des représentations miniaturisées des pages d'origine correspondantes.
- les moyens d'affichage sont également aptes à afficher, en association avec ladite page de destination consultée, une pluralité d'éléments activables constituant une pluralité de liens qui étaient contenus dans (ou associés à) la page d'origine.
- les moyens d'affichage sont également aptes à afficher, en association avec une autre page consultée par activation de l'un des éléments activables de ladite pluralité, un élément activable constituant un lien vers ladite page d'origine.
- les moyens de détection de liens sont aptes à détecter l'existence d'un lien d'une page d'origine vers une page de destination via une ou plusieurs pages intermédiaires.
Selon un autre aspect, la présente invention propose un procédé de navigation mis en œuvre dans un poste informatique client pour accéder à des pages fournies notamment par des serveurs via un réseau informatique par activation de liens et pour afficher lesdites pages, caractérisé en ce qu'il comprend les étapes suivantes :
- lors de la consultation d'une page courante, la consultation locale ou à distance de moyens de mémorisation d'une table de liens inverses contenant, en association avec une information d'identification de ladite page courante, des informations d'identification d'une ou plusieurs pages sources possédant des liens vers ladite page courante, et
- des moyens d'affichage de liens inverses aptes, à partir desdites informations d'identification consultées, à afficher en association avec l'affichage de ladite page courante des éléments activables constituant autant de liens vers la ou les pages sources.
Des aspects préférés mais non limitatifs de ce procédé sont les suivants :
- les informations d'identification des pages sources dans ladite table de liens inverses sont déterminées par la détection préalable d'une action de souris, dans une page source, sur un lien vers ladite page courante.
- le procédé comprend en outre une étape de sélection, parmi les pages sources désignées par lesdites informations d'identification de pages sources, des seules pages sources possédant des caractéristiques de contenu déterminées par rapport à un profil de l'utilisateur du poste client, et l'étape d'affichage comprend l'affichage des seuls éléments activables constituant des liens vers lesdites pages sources sélectionnées. - les moyens de mémorisation comprennent une pluralité de tables de liens inverses identifiées, correspondant à une pluralité d'utilisateurs, et l'étape de consultation des moyens de mémorisation s'effectue en utilisant une information d'identification de l'utilisateur.
- les moyens de mémorisation comprennent une table de liens unique contenant des informations d'identification de pages sources en association avec l'information d'identification de ladite page courante et avec une information d'identification de l'utilisateur.
- les moyens de mémorisation sont contenus dans un serveur accessible par réseau à partir du poste client.
- le procédé comprend en outre une étape de suppression apte, au moins lors du premier affichage d'un élément activable, à supprimer à l'initiative de l'utilisateur l'affichage dudit élément activable.
- l'étape de suppression comprend, lors de la suppression d'un élément activable par l'utilisateur, la suppression, dans les moyens de mémorisation, de l'information d'identification de la page source concernée par ledit élément activable en association avec l'information d'identification de la page courante pour l'utilisateur concerné.
- l'étape d'affichage de liens inverses comprend l'affichage dans un état suggéré des éléments activables des liens correspondants vers les pages sources, et le procédé comprend en outre une étape de modification d'état de lien inverse pour, lors de chaque affichage d'un élément activable dans l'état suggéré, faire passer à l'intiative de l'utilisateur ledit élément activable dans un état accepté ou dans un état refusé.
- l'étape de modification d'état de lien inverse comprend également le passage, à l'intiative de l'utilisateur, du lien correspondant dans un état gelé, et le procédé comprend en outre une étape de mémorisation du contenu de la page source correspondante dans son état courant, pour permettre l'accès à ladite page source mémorisée dans son état courant à partir de l'élément activable correspondant.
- l'étape d'affichage de liens inverses comprend l'affichage des éléments activables dans au moins une zone d'affichage contenue dans la page courante.
- l'étape d'affichage de liens inverses comprend l'affichage des éléments activables de façon adjacente à une zone d'affichage occupée par la page courante.
- lesdits éléments activables sont constitués par des représentations miniaturisées des pages d'origine correspondantes.
- l'étape d'affichage comprend également l'affichage, en association avec ladite page courante, d'une pluralité d'éléments activables constituant une pluralité de liens inverses qui étaient associés à au moins une page en amont de la page courante.
- l'étape d'affichage comprend également l'affichage, en association avec ladite page courante, d'une pluralité d'éléments activables constituant une pluralité de liens vers des pages vers lesquelles pointent des liens contenus dans au moins une page en amont de la page courante.
- les moyens de mémorisation comprennent en outre une information d'identification d'au moins une page source de niveau supérieur, contenant un lien direct, ou par l'intermédiaire d'au moins une autre page, vers au moins l'une des pages sources identifiées en association avec la page courante, et l'étape d'affichage comprend l'affichage d'éléments activables constituant autant de liens vers les pages sources de niveau supérieur.
Un autre objet de la présente invention concerne l'ajout à une page de base, sous le contrôle de l'utilisateur, des contenus provenant d'autres sites ou d'autres pages, en fonction notamment du profil (centres d'intérêt, etc.) de l'utilisateur. Cet objet de l'invention propose ainsi un système de navigation qui permette, d'une manière extrêmement simple, intuitive et sélective, d'accéder à des pages portant sur des sujets que l'utilisateur a considéré comme pertinents en relation avec la page courante, ou encore, par la même interface utilisateur, d'enrichir le contenu d'une page courante avec des apports également susceptibles d'intéresser l'utilisateur.
Un autre objet encore de la présente invention est de permettre à un utilisateur de bénéficier, sélectivement, soit de liens vers des pages, soit de liens vers des contenus additionnels à incorporer à la page courante, ces liens ayant été créés par des tiers en relation avec les propres sujets d'intérêt de l'utilisateur.
Ainsi l'invention propose un système de navigation mis en œuvre dans un système informatique pour accéder au niveau d'un poste client à des pages fournies notamment par des serveurs via un réseau informatique, caractérisé en ce qu'il comprend en combinaison :
- des moyens pour afficher une page courante,
- des moyens pour sélectionner et afficher en sus de la page courante au moins une liste d'options d'ajout d'informations en association avec ladite page, à chaque option d'ajout étant associées des données de localisation d'un ensemble d'informations contenant les informations à ajouter,
- des moyens d'entrée permettant à l'utilisateur de sélectivement activer ou inactiver chacune desdites options,
- des moyens de retraitement aptes, pour chaque option activée, à localiser l'ensemble d'infoπnations de la ou de chaque option activée à partir desdites données de localisation et à en extraire les informations à ajouter, et
- des moyens pour afficher la page complétée par la ou lesdites informations à ajouter. Des aspects préférés, mais non limitatifs, du système selon l'invention sont les suivants :
- lesdites informations à ajouter sont constituées par des liens de la page courante vers d'autres pages.
- les moyens d'affichage sont aptes à afficher lesdits liens à l'extérieur de la page courante.
- les moyens d'affichage sont aptes à afficher lesdits liens en superposition sur la page courante.
- les moyens d'affichage sont aptes à afficher lesdits liens dans au moins un emplacement de la page constitué par une zone réservée prévue à l'origine dans la page courante.
- ladite zone réservée est une zone de publicité.
- lesdites informations à ajouter sont constituées par des liens situés à des emplacements prédéterminés de la page courante et pointant vers des contenus additionnels pour ladite page.
- la page courante contient un code de présentation desdits contenus additionnels.
- il est prévu une liste d'options définies. à partir de paramètres de sélection fournis par l'auteur de la page courante.
- au moins l'une des options est sélectionnée par défaut à l'initiative de l'auteur de la page courante.
- il est prévu une liste d'options définies, à partir d'un traitement de comparaison entre un profil de l'utilisateur du poste client et une pluralité de profils publics d'autres utilisateurs, comme étant issues de profils proches.
- il est prévu une liste d'options définies à partir de paramètres de sélection fournis par l'utilisateur. - au moins l'une des options est sélectionnée par défaut dans le cas où ladite page courante a été émise vers le poste client par un utilisateur auquel est associée ladite option.
- la ou chaque liste d'options contient une liste de désignations des sources desdites options telles que des utilisateurs.
- les moyens de sélection et d'affichage de listes d'options comprennent des moyens pour sélectionner des options sur la base d'attributs de caractérisation du type d'intérêt porté par les sources desdites options à la page courante.
- lesdits attributs comprennent un attribut « Offreur » et un attribut « Demandeur ».
- le système comprend en outre des moyens de mise en communication d'un utilisateur dudit poste client avec des utilisateurs qui sont les sources desdites options d'ajout.
- le système comprend en outre des moyens d'agrégation d'informations à ajouter associées à au moins deux options d'ajout différentes.
Un autre objet de la présente invention concerne d'une façon générale des outils permettant à un utilisateur d'un poste client sur un réseau informatique tel que l'Internet, de bénéficier d'ensembles structurés de connaissances, que l'on appellera dans la suite « profils », qui ont été développés par d'autres utilisateurs.
On connaît dans l'état de la technique divers procédés informatiques de filtrage collaboratif et autres qui permettent de détecter des similitudes entres profils d'utilisateurs.
Un objet de la présente invention est de rechercher et d'identifier, pour le bénéfice d'un utilisateur donné, l'existence d'autres utilisateurs qui partagent ses intérêts (et ses goûts) par rapport à une « page courante » que ledit utilisateur donné est en train de visualiser et qui représente donc le contexte courant de ses intérêts.
Ainsi, par rapport à une page courante visualisée par un premier utilisateur, l'invention vise à trouver les deuxièmes utilisateurs les plus « proches », c'est-à-dire ayant, dans un réseau de liens entre pages qu'ils mettent à la disposition du public, d'une part ladite page, et d'autre part, autour de ladite page, l'ensemble le plus grand de liens en commun avec le premier utilisateur.
Un autre objet de l'invention est de trouver des deuxièmes utilisateurs proches par rapport à un ensemble de pages sélectionnées par le premier utilisateur, plutôt que par rapport à une seule page.
Plus précisément, l'invention vise à permettre une recherche de deuxièmes utilisateurs de manière focalisée, c'est-à-dire avec beaucoup plus de pertinence que si l'on se basait sur leur simple profil global d'intérêts (vis-à-vis du profil global d'intérêts du premier utilisateur). Le but est ainsi de comparer les profils des utilisateurs en faisant abstraction des éléments de ces profils qui ne sont pas dans le contexte qui intéresse l'utilisateur au moment courant. Autrement-dit, on cherche à éviter de « diluer » dans une masse d'éléments importante le nombre des éléments pertinents (par rapport au contexte courant) qui se trouvent être en commun entre le premier utilisateur et un deuxième utilisateur avec lequel il est comparé, et à relativiser la recherche en fonction de la taille du domaine du contexte courant.
Un autre objet encore de l'invention est d'atteindre ces objectifs avec des ressources machine raisonnables, et des temps de traitement raisonnablement courts.
Par ailleurs, pour focaliser les recherches de profils voisins, on pourrait certes partitionner les éléments des profils selon des catégories adoptées par l'ensemble des utilisateurs, ce qui permettrait de les classer globalement ou par rapport à des attributs qui les caractérisent. On spécifierait ainsi leur appartenance aux domaines respectifs pris en compte lors des recherches, ce qui permettrait d'élaguer les éléments des profils qui ne sont pas dans le domaine d'intérêt courant de l'utilisateur. Cependant, la catégorisation des éléments des profils nécessiterait pour les utilisateurs de s'entendre sur les vocabulaires de catégories à partager. Or cette approche n'est pas avantageusement adaptée à des systèmes largement décentralisés tels que l'Internet.
Un autre objet de la présente invention est de pouvoir focaliser la recherche sans devoir classer les éléments des profils selon des catégories partagées, et donc sans avoir à s'entendre sur des vocabulaires communs de catégories.
Au niveau des performances, la présente invention peut être mise en oeuvre sur la base d'une recherche en accès direct grâce à des structures de données appropriées (telles que des fichiers inversés) qui permettent de retrouver les deuxièmes utilisateurs proches directement à partir de ladite page, ou même à partir de ladite page et de ses liens ajoutés.
Enfin un objet de l'invention est de proposer un approche originale de la recherche de pages ou autres contenus voisins d'une page donnée, en exploitant non pas des profils structurés, mais en se basant sur les utilisateurs ayant créé des liens sur cette page ou contenu.
Ainsi la présente invention propose selon un premier aspect un procédé d'enrichissement sélectif de graphes à partir d'un ensemble de graphes comprenant chacun une pluralité de nœuds constitués par des ensembles d'informations tels que des pages, reliés entre eux par des arcs constitués par des liens entre lesdites pages, deux nœuds reliés par un arc constituant des nœuds voisins, à chaque graphe étant associée une première structure de chemin d'accès aux nœuds du graphe et, à chaque nœud contenu dans au moins un graphe étant associée une seconde structure de chemin d'accès aux graphes contenant ce nœud, caractérisé en ce qu'il comprend les étapes suivantes :
(a) à partir de l'identification d'un nœud donné d'un premier graphe associé à un utilisateur et de l'identification des voisins dudit nœud, identifier en utilisant les première et seconde structures de chemin d'accès tous les graphes contenant ledit nœud donné et un ensemble de nœuds voisins présentant un degré de similitude le plus élevé avec les nœuds voisins du premier graphe, et
(b) afficher sur un poste client accessible par ledit utilisateur du premier graphe les nœuds qui sont des voisins dudit nœud donné dans chacun desdits graphes identifiés sélectionnés et qui ne sont pas des voisins dudit nœud donné dans le premier graphe, en vue de leur ajout dans ledit premier graphe.
Avantageusement, l'étape (a) comprend les sous-étapes suivantes :
(al) à partir d'un critère comprenant au moins l'identification d'un nœud donné d'un premier graphe associé à un utilisateur, identifier en utilisant la seconde structure de chemin d'accès tous les graphes répondant à ce critère,
(al) à partir de la première structure de chemin d'accès associée au premier graphe, identifier les nœuds voisins dudit nœud donné,
(a3) pour chaque graphe identifié à la sous-étape (al), parcourir sa première structure de chemin d'accès pour identifier les nœuds voisins dudit nœud donné dans le graphe considéré,
(a4) comparer les nœuds voisins identifiés dans le premier graphe avec les nœuds voisins identifiés dans chacun des graphes identifiés, et
(a5) sélectionner le ou les graphes identifiés dont les nœuds voisins présentent un degré de similitude le plus élevé avec les nœuds voisins du premier graphe.
De façon également avantageuse, à chaque nœud peut être affecté un attribut de caractérisation du type d'intérêt porté à l'ensemble d'informations dudit nœud en association avec le graphe considéré, et l'étape (a) est mise en œuvre sur les seuls graphes dont ledit nœud donné présente une valeur d'attribut de caractérisation prédéterminée. Selon un deuxième aspect, cet objet de la présente invention propose un procédé de recherche de profils voisins parmi une pluralité de profils non liés par une structuration commune et accessibles à partir d'un système de traitement, chaque profil étant défini par un ensemble d'informations et/ou d'identifiants de telles informations propres à un utilisateur donné, caractérisé en ce qu'il comprend les étapes suivantes :
- au niveau de chaque profil, affecter au moins certaines informations et/ou certains identifiants d'informations à des groupes choisis par l'utilisateur en fonction de ses propres centres d'intérêts, de façon indépendante des choix de groupes par les autres utilisateurs,
- à partir d'un jeu d'informations et/ou d'identifiants d'informations de départ appartenant à un même groupe d'un utilisateur, rechercher dans chacun desdits profils des jeux similaires d'informations ou identifiants, en ne considérant à chaque fois que les informations ou identifiants appartenant à un même groupe de l'utilisateur correspondant audit profil, en sélectionnant les profils pour lesquels la similitude entre jeux d'informations ou identifiants est la plus grande.
Avantageusement, à chaque information et/ou identifiant d'information peut être affecté un attribut de caractérisation du type d'intérêt porté à ladite information en association avec le profil considéré, et ladite étape de recherche est mise en œuvre sur les seules informations qui présentent une valeur d'attribut de caractérisation prédéterminée.
Selon un troisième aspect, cet objet la présente invention propose un procédé de recherche, parmi une pluralité d'éléments d'information, d'éléments d'information voisins d'un élément d'information donné, chaque élément d'information étant susceptible d'appartenir à une pluralité de profils non liés par une structuration commune et accessibles à partir d'un système de traitement, chaque profil étant défini par un ensemble de tels éléments d'informations et/ou d'identifiants de tels éléments d'informations propres à un utilisateur donné, caractérisé en ce qu'à chaque élément d'information est associée une liste de profils contenant ledit élément, et en ce qu'il comprend l'étape consistant à rechercher des éléments d'informations dont la liste de profils répond au mieux à un critère de similitude prédéterminé avec la liste de profils dudit élément d'information donné.
De façon préférée, à chaque élément d'information peut être affecté un attribut de caractérisation du type d'intérêt porté audit élément d'information en association avec le profil considéré, et l'étape de recherche est mise en œuvre sur les seuls profils pour lesquels ledit élément d'information présente une valeur d'attribut de caractérisation prédéterminée.
Par exemple, lesdits attributs de caractérisation comprennent un attribut « Offreur » et un attribut « Demandeur ».
Un autre objet de la présente invention concerne l'enrichissement automatique des requêtes notamment sur l'Internet. On se place ici dans le contexte où un utilisateur dispose, dans des contenants (récipients), de contenus (liens ; fragments) sélectionnés en fonction des centres d'intérêts, et plus particulièrement où des contenus pourront être suggérés à un utilisateur et acceptés par lui dans un contenant déterminé associé audit utilisateur, et ainsi adopter une « catégorie » en relation avec ce contenant.
Plus précisément encore, un même contenu pourra être accepté par un même utilisateur dans plusieurs de ses contenants, et ainsi adopter plusieurs catégories différentes correspondant à ces différents contenants. Dans un tel contexte, on pourra prévoir qu'au moins un (en général plusieurs) serveur particulier connecté au réseau centralisera les données de catégories associées au contenus comme décrit plus haut.
La présente invention a pour premier objectif de recourir à un tel serveur particulier pour améliorer le ciblage de requêtes présentées par l'utilisateur à un autre serveur du réseau, ayant lui-même attribué des catégories à des contenus, et ceci en fonction de centres d'intérêts déterminés à partir des données de catégories propres à l'utilisateur, précédemment recueillies.
Selon cet objet de l'invention, un tel serveur particulier, par la connaissance qu'il a des catégories de contenants associées à un contenu qui fait l'objet d'une requête, enrichit de façon automatique et transparente ladite requête par des critères supplémentaires. Notamment, ce serveur particulier est capable de déterminer que, pour un certain nombre de contenus appartenant à une catégorie donnée, il existe une ou plusieurs autres catégories qui ont été attribuées par l'utilisateur à ces mêmes contenus. Il exploite donc ces autres catégories en les utilisant en tant que critères supplémentaires pour enrichir automatiquement la requête formée par l'utilisateur.
On comprend donc que la présente invention permettra, à l'aide de cette requête enrichie, de sélectionner les contenus de manière « personnalisée », c'est-à-dire en tenant compte des centres d'intérêts potentiels de l'utilisateur pour les contenants en question.
Plus particulièrement, cet objet de la présente invention propose un serveur intermédiaire, apte à recevoir d'un poste client une requête de base normalement utilisée pour accéder directement à un serveur tiers et à rediriger une requête vers ledit serveur tiers, caractérisé en ce qu'il comprend des moyens pour :
- lors d'un accès d'un utilisateur à un serveur tiers via ledit serveur intermédiaire, au cours duquel une information provenant du serveur tiers est acceptée par l'utilisateur dans un contenant déterminé, mémoriser en association avec ladite information une identification de catégorie propre à l'utilisateur, associée audit contenant,
- à chaque requête formée par un utilisateur auprès d'un serveur tiers via ledit serveur intermédiaire,
* identifier l'utilisateur adressant ladite requête,
* à partir des identifications de catégories précédemment mémorisées, construire une requête enrichie contenant ladite requête de base et un ou plusieurs valeurs de critères additionnels déduits desdites identifications de catégories, et
- adresser audit serveur tiers ladite requête enrichie.
Avantageusement, lorsque ladite requête concerne un contenu destiné à être le cas échéant accepté dans un contenant donné, lesdits critères additionnels comprennent au moins une identification de catégorie d'un autre contenant associé audit contenu.
En outre, de façon préférée, le serveur intermédiaire comprend en outre des moyens aptes, lorsque le serveur tiers délivre des informations brutes (XML) dissociées d'informations de présentation (XSL) propres au serveur tiers, à appliquer auxdites informations brutes des informations de présentation autres que lesdites information de présentation propres au serveur tiers.
Encore un autre aspect de la présente invention propose un procédé pour affecter des catégories à des contenus (fragments) accessibles par une pluralité d'utilisateurs, chaque contenu étant par ailleurs propre a être sélectivement placé dans une pluralité de contenants (récipients) appartenant à des structures de documents, ces contenants possédant chacun des informations de catégorie, et à chaque contenu pouvant être associé une pluralité d'informations de catégories permettant aux utilisateurs notamment de sélectivement accéder par un critère de catégorie audit contenu ou d'automatiser la sélection de la présentation dudit contenu, comprenant l'étape consistant, lorsqu'un contenu donné est placé dans un contenant donné d'un document, à ajouter aux informations de catégorie déjà associées audit contenu les informations de catégorie possédées par ledit contenant donné. Lesdites informations de catégories ajoutées aux contenus sont ajoutées en mode suggéré.
Enfin un dernier objet de la présente invention concerned'une façon générale des procédés pour déterminer des degrés de proximité entre des contenus auxquels sont associées des « marques d'intérêt », tels que des pages accessibles par la Toile (Web).
On entend ici par « marque d'intérêt » par exemple le fait que pour un contenu donné, il existe dans un autre contenu (que l'on appellera contenu routeur) un lien vers ce contenu, ou encore le fait que pour un contenu, il existe des utilisateurs qui ont placé des signets ou analogues sur ce contenu dans leur système de navigation Internet, ou qui accèdent de façon particulièrement fréquente et/ou régulière à ce contenu.
Plus précisément, la présente invention vise à déterminer des degrés de proximité entre contenus et à catégoriser de tels contenus de façon automatique en en analysant les marques d'intérêt précitées.
Jusqu'à présent, la catégorisation de pages est effectuée en général manuellement de manière plus ou moins sophistiquée et complète au niveau de portails généralistes ou spécialisés, et, à part quelques approches basées sur l'analyse sémantique des contenus des textes qui ne donnent pas de résultats assez satisfaisants, et malgré diverses approches théoriques développées en matière de catégorisation, il n'existe pas aujourd'hui de moyen permettant concrètement, de façon automatique et dynamique, de regrouper à large échelle des contenus en catégories.
La présente invention vise à pallier ces limites en exploitant de façon automatique d'une part des liens situés dans des contenus préexistants, correspondant en général à des pages pivots de la Toile ou « contenus routeurs » (c'est-à-dire des pages dont la fonction essentielle est de router l'internaute vers des sujets d'intérêt), et d'autre part des groupes de liens structurés petit à petit par des utilisateurs (internautes ou webmestres).
Ainsi la présente invention propose selon un premier aspect un procédé pour déterminer un degré de proximité entre contenus dans un ensemble de N contenus tels que des pages accessibles par liens sur un réseau tel que l'Internet, notamment à des fins de catégorisation desdits contenus, chaque contenu étant accessible par une pluralité d'utilisateurs, caractérisé en ce qu'il comprend les étapes suivantes :
A) pour chaque contenu, mémoriser en association avec une pluralité d'utilisateurs susceptibles d'accéder audit contenu une pluralité d'informations de marques d'intérêt pour ledit contenu,
B) pour tout sous-ensemble de contenus appartenant audit ensemble et constitué par un nombre de contenus compris entre 1 et N, calculer à partir desdites informations de marque d'intérêt, une valeur au moins approximativement représentative de la probabilité pour qu'un utilisateur porte une marque d'intérêt au contenu ou à l'un quelconque au moins des contenus du sous-ensemble, et
C) calculer à partir desdites valeurs un coefficient de proximité entre les contenus de l'ensemble.
Avantageusement, l'étape B) comprend, pour tout sous-ensemble de 1 à N contenus, le calcul d'une probabilité pour qu'un utilisateur ne porte de marque d'intérêt à aucun des contenus du sous-ensemble, et en ce que l'étape C) comprend le calcul d'un rapport entre le produit des probabilités obtenues pour tous les sous-ensemble ayant un nombre impair de contenus et le produit des probabilités obtenues pour tous les sous-ensembles ayant un nombre pair de contenus.
Dans ce cas, il est préférable que chaque coefficient de proximité soit égal à 1 diminué de la valeur dudit rapport.
De façon avantageuse également, le calcul de la valeur représentative de la probabilité pour qu'un utilisateur porte une marque d'intérêt à l'un quelconque au moins des contenus du sous- ensemble met enjeu la probabilité pour qu'un utilisateur porte une marque d'intérêt à chacun des contenus du sous-ensemble.
En outre, au moins certains contenus dudit ensemble sont susceptibles d'être atteints par au moins un lien prévu dans au moins un parmi une pluralité de contenus routeurs, auquel cas les informations de marques d'intérêt d'utilisateur pour un tel contenu sont constitués par la présence ou non de liens dans ladite pluralité de contenus routeurs vers ce contenu.
Selon un deuxième aspect, l'invention propose un procédé pour déterminer si un premier groupe d'un ou de plusieurs contenus est susceptible de se voir affecter une même information de catégorie qu'un second groupe d'un ou de plusieurs contenus au(x)quel(s) est déjà affectée une même information de catégorie, caractérisé en ce qu'il comprend la mise en œuvre du procédé tel que défini ci-dessus sur l'ensemble constitué par les contenus du premier groupe et au moins certains contenus du second groupe, et l'affectation ou non de ladite information de catégorie au(x) contenu(s) du premier groupe en fonction notamment de la valeur du coefficient de proximité obtenu.
Selon un troisième aspect, l'invention propose un procédé pour affecter une information de catégorie à un ou plusieurs contenus d'un premier groupe, caractérisé en ce qu'il comprend la mise en œuvre répétée du procédé selon le deuxième aspect de l'invention sur des ensembles constitués par le ou les contenus du premier groupe et des contenus appartenant à d'autres groupes et auxquels sont affectés à chaque fois une information de catégorie commune, et l'affectation au(x) contenu(s) du premier groupe d'au moins une information de catégorie en fonction des différents coefficients de proximité obtenus.
D'autres aspects, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description détaillée suivante d'une forme de réalisation préférée de celle-ci, donnée à titre d'exemple non limitatif et faite en référence aux dessins annexés.
Table des matières
Table des matières 21
Introduction 22
Introduction à la structure en récipients et fragments 22
Nœuds récipients et fragments dans les structures XML 24
Introduction à la ré-utilisation de fragments 27
Macrostructure & Microstructures 28
Introduction à la structuration en Macrostructure et Microstructures 28
Macrostructure & Microstructures 29
Importation de fragments 31
Cache 32
Références sur des nœuds externes 34
Présentation à l'utilisateur 35
Assemblage du document XML 35
Application de feuilles de style 36 Présentation en Mode Manipulation 37
Applications typiques 39
Modes Suggéré, Accepté, Gelé, Refusé 40
Fonction de canal de communication 40
Importation d'un fragment 40
Un fragment en mode suggéré n'existe qu'implicitement 42
Un fragment en mode refusé existe explicitement 42
Fragment en mode accepté 43
Fragment en mode gelé 45
Suppression d'un fragment 46
Assemblage du document XML à présenter à l'utilisateur 48
Possibilité de créer des cycles 51
Fonctions usuelles 51
Quelques variantes 51
Catégorisation automatique et suggestions 54
Objectifs premiers 54
Propagation des catégories grâce aux ré-utilisations de fragments 56
Architecture générale du système de catégorisation automatique 64
Catégorisation 66
Entrée d'un fragment dans une catégorie 72
Quantité de raisons communes entre pages ou fragments 74
Détection de l'anomalie de fragments très proches 78
Fusion de catégories 79
Compléments à la description de procédés de catégorisation 80
Introduction
Introduction à la structure en récipients et fragments
Un document, comme celui illustré schématiquement ci-dessous, est tout naturellement structuré en une arborescence de nœuds qui regroupent d'autres nœuds à des positions que nous appelons nœud « Récipient » :
Document
Chapitre
Section
Paragraphe 1
" Elément
" Elément (toujours dans le même paragraphe 1)...
1. Elément
2. Elément Paragraphe 2
Figure Par exemple, un fragment « Chapitre » comporte un récipient pour des « Sections », qui à leurs tours contiennent un récipient pour des « Paragraphes », ces derniers pouvant contenir un ou plusieurs récipients contenant des « Eléments », comme illustré ci-dessous. Observer que, dans l'exemple présenté, le fragment premier paragraphe comporte deux récipients, chacun contenant deux éléments, et qu'entre les deux récipients se trouve le contenu « (toujours dans le même paragraphe 1)... » qui appartient au même fragment. Cette structure peut être explicitée au moyen de balises:
<Fragment> Document
<Récipient >
<Fragment > Chapitre
<Récipient >
<Fragment > Section
<Récipient >
<Fragment > Paragraphe 1
<Récipient >
<Fragment >
" Elément
</Fragment >
<Fragment >
" Elément
</Fragment >
</Récipient > (toujours dans le même paragraphe 1)...
<Récipient >
<Fragment >
1. Elément </Fragment > <Fragment >
2. Elément </Fragment >
</Récipient > </Fragment >
<Fragment > Paragraphe 2
<Récipient >
<Fragment > Figure </Fragment > < Récipient > </Fragment > < Récipient > </Fragment> </Récipient > </Fragment> < Récipient > </Fragment>
On va appliquer la méthode décrite ci-après au cas de structures XML, mais elle peut s'appliquer à n'importe quel formalisme.
Nœuds récipients et fragments dans les structures XML
Dans une structure XML, on peut préciser quels sont les nœuds récipients en leur affectant un attribut que nous allons simplement intituler « récipient ».
Par la même occasion, on peut spécifier les autorisations d'accès au récipient, notamment quels sont les groupes d'utilisateurs qui peuvent y insérer des fragments. Par exemple, « récipient = "Private" » signifie que seul le propriétaire du site peut y insérer des fragments.
Ceci est illustré dans l'exemple ci-dessous que nous utiliserons dans la suite, où nous avons un document XML composé des nœuds DOCUMENT, ARTICLE, TITRAILLE, CONTENUS, CONTENU, etc, et où nous spécifions que les nœuds DOCUMENT et CONTENUS sont des récipients :
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<DOCUMENT recipient="private">
<ARTICLE> πTRAILLE/>
<CONTENUS recipient="private">
<CONTENU>
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>rextei</PARAGRAPHE> </CONTENU> <CONTENU>
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>7eΛ:te2</PARAGRAPHE> </CONTENU>
</CONTENUS> </ARTICLE> </DOCUMENT> Avantageusement, la granularité des fragments manipulables (manipulables de manière atomique) -et des autorisations d'accès qu'ils offrent- est alors spécifiée implicitement :
• Tous les nœuds « enfants directs » de chaque nœud récipient, ainsi que le nœud racine (ici le nœud DOCUMENT), sont des fragments manipulables, avec par défaut la valeur
« fragment="private" ». l
Le fait qu'un nœud est un fragment manipulable (dans la suite, pour simplifier l'écriture nous écrirons « fargment » au lieu de « fragment manipulable ») peut aussi être spécifié explicitement au moyen d'un attribut :
• Les nœuds ayant un attribut fragment (et une valeur pour cet attribut) sont des fragments.
Un fragment ayant l'attribut « fragment- 'private" » ne peut être manipulé que par son propriétaire : il ne peut pas être manipulé par les autres utilisateurs, du moins pas « en étant pris tout seul » (c'est-à-dire qu'il pourrait l'être en tant que sous-fragment d'un autre fragment le cas échéant).
Un fragment ayant l'attribut « fragment="public" » peut être « attrapé » par n'importe quel utilisateur, pour être « ré-utilisé » ailleurs (notion que nous introduisons un peu plus loin). Les utilisateurs autres que le propriétaire ne peuvent cependant pas le modifier.
Comme le décrit schématiquement la figure Fig.l, entre les deux extrêmes « public » et « privé » des autorisations peuvent être attribuées à des groupes particuliers d'utilisateurs.
Un système infoπnatique peut expliciter ces nœuds fragments et récipents et les numéroter2 (pour les identifier). Ci-dessous ceci est illustré en gras. On a supposé que dans cet exemple au préalable l'utilisateur a voulu que le le fragment ARTICLE soit public. On a par ailleurs préfixé par « mix: » (en tant que « namespace ») tous les attributs introduits.
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<DOCUMENT xmlns:mix="urn:x-schema: ..." mix:fragment="private" mixrfragment- id="l" mix:recipient="private" mix:recipient-id="l" >
<ARTICLE mix:fragment="public" mix:fragment-id= "2"> ΓITRAILLE/>
<CONTENUS mix:recipient="private" mix:recipient-id="l">
<CONTENU
Figure imgf000026_0001
mix:fragment-id= "3">
<INTERTITRES />
<ILLUSTRATIONS/>
<PARAGRAPHE>rextei</PARAGRAPHE> </CONTENU> <CONTENU mix:fragment="private" mix:fragment-id= "4">
<ιNTERTιTRES />
<ILLUSTRATIONS/>
1 De plus, le nœud racine a par défaut implicitement l'attribut recipient="private" si son nœud enfant est défini comme étant un fragment.
2 Noter que la portée du numéro de fragment est le document, tandis que pour un récipient la portée de son numéro est le fragment qui le contient. <PARAGRAPHE>rexte2</PARAGRAPHE>
</CONTENU> </CONTENUS> </ARTICLE> </DOCUMENT>
Un fragment peut posséder plus d'un récipient. Ainsi, par exemple, le fragment article aurait pu posséder deux récipients (matérialisés par les nœuds DEBUT et FIN) le premier contenant par exemple deux sous-fragments et le deuxième contenant un sous-fragment :
<ARTICLE mix:fragment="public" mix:fragment-id= "2"> rιTRAILLE/>
<CONTENUS >
<DEBUT mix:recipient="private" mix:recipient-id="l">
<CONTENU mix:fragment="private" mix:fragment-id= "3">
</CONTENU>
<CONTENU mix:fragment="private" mix:fragment-id= "4">
</CONTENU> <DEBUT/> <FIN mb recipient- 'private" mix:recipient-id="2">
<RECAPITULATIF mix:fragment="private" mix:fragment-id= "5">
< RECAPITULATIF>
<FΓN/> </CONTENUS>
</ARTICLE>
Le document présenté a comme adresse « cheminl/docl.xml ». Supposons qu'il existe également un deuxième document, « chemin2/doc2.xml », qui ait exactement la même structure que le premier, mais qui contienne les paragraphes Texte 3 et Texte4 à la place de Texte 1 et Texte2 respectivement. La section suivante introduit les ré-utilisations de fragments entre documents et prendra ces deux documents comme exemple. Introduction à la ré-utilisation de fragments
On va maintenant permettre à l'utilisateur d'insérer (importer) dans un document des fragments qui notamment peuvent se trouver dans d'autres documents.
Supposons que l'utilisateur veuille insérer le fragment n° 2 du deuxième document dans le premier document à la suite de l'article existant. Comme il voudrait que le nouvel article soit tenu àjour dans le premier document quand il est modifié dans le deuxième document il préférera insérer une référence à cet article plutôt qu'une copie de cet article. Ceci est illustré ci- dessous :
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<DOCUMENTxmlns:mix="urn:x-schema:..." mix:fragment-id= "1" mix:recipient-id="l" >
<ARTICLE mix:fragment="public" mix:fragment-id="2" >
</ARTICLE>
<ARTICLE mix:fragment="public" mix:fragment-id="5" mix:src="http://domaineX/WebServiceY/GetFragment?context=/cheminZ/doc2.xml & fragment-id=456"/>
</DOCUMENT>
Dans l'exemple ci-dessus, la référence est mise en oeuvre sous la forme d'un appel de méthode « GetFragment » d'un service web exposé par le serveur du deuxième document. D'autre manière de mettre en œuvre une référence de mise àjour sont bien sûr possibles (notamment au moyen du langage XPath).
Cette approche est simple mais n'offre pas les avantages que nous présentons plus loin et qui consistent à pouvoir manipuler les fragments à une granularité plus fine que celle du fragment importé en entier (« faire de la chirurgie fine ») tout en continuant à bénéficier par la suite de la tenue àjour pour les parties non modifiées. En effet, modifier une partie du contenu du nœud ARTICLE importé consiste à (1) créer une copie de tout ce contenu, (2) supprimer la référence (mix:src- '..."), puis (3) effectuer la modification sur cette copie. Comme on a supprimé la référence, la partie qui n'a pas été modifiée ne peut plus être tenu àjour.
On notera aussi à ce stade de la description que, d'une manière générale, l'acte de ré-utiliser, qui consiste à reprendre une information pour la placer dans un nouveau contexte après adaptation éventuelle (par exemple, après adaptation automatique par la « feuille de style » du nouveau contexte, ce qu'on va décrire plus loin), revient implicitement à déclarer qu'elle est pertinente dans ce nouveau contexte, et que l'on peut alors créer automatiquement une relation de pertinence entre l'information reprise et son nouveau contexte (voir la figure Fig.2). On peut ensuite exploiter les relations ainsi créées pour catégoriser automatiquement les informations réutilisées (les catégories pouvant même émerger automatiquement) et alimenter ainsi un nouveau type de moteur de recherche : un moteur de suggestion. Ceci sera décrit plus loin à la section « Catégorisations automatiques ». - pour au moins un nœud (N12 ; N131) de la ressource, agencer ledit nœud comme un fragment (F12 ; F131) comportant ledit nœud comme nœud racine du fragment et tous les nœuds descendants (N121, N122, N123, N1211, ... ; N1311, ...) dudit nœud racine,
- associer à au moins un fragment (F 12) de la ressource une référence de mise àjour (R(N12, FA)) vers un fragment amont (FA) (contenu dans n'importe quelle ressource, c'est-à- dire dans une autre ressource (Ry) ou dans la même ressource), pour former un fragment aval,
- éventuellement, associer aussi à au moins un nœud descendant (NI 22) inclus dans un premier fragment aval (F12) une référence de mise àjour (R(N122, FA')) vers un autre fragment amont (FA') contenu dans n'importe quelle ressource (Rz), pour former un deuxième fragment aval (F 122) qui est sous-fragment du premier fragment aval (F 12),
- éventuellement, associer à au moins un nœud descendant (N121) d'un fragment aval une référence de non-mise àjour (NR(N121, SFA)) vers le nœud descendant correspondant du fragment amont correspondant, de telle sorte que le contenu de chaque fragment aval (F 12 ; SF122) est composé à partir du contenu du fragment amont correspondant (FA ; FA'), à l'exception du contenu de chaque sous- fragment (SF121) correspondant à chaque nœud descendant (NI 21) auquel est associée une référence de non-mise àjour. (Par « contenu » entendre « présentation du contenu »).
Le procédé comprend en outre l'étape suivante :
- lors de chaque composition d'un fragment aval, utiliser la référence de mise àjour vers le fragment amont pour ajouter dans le fragment aval tout sous-fragment qui a été ajouté (et qui est en mode accepté, c'est-à-dire validé) dans ledit fragment amont (ou alternativement n'inclure qu'une sélection parmi lesdits sous-fragments ajoutés), avec une indication d'un mode suggéré du sous-fragment.
Nous décrirons tout d'abord la structure de données en ignorant les modes accepté, suggéré, etc.
Ces derniers seront décrits plus tard à la section « Modes Suggéré, Accepté, Gelé et Refusé ».
Quant à la sélection parmi les sous-fragments ajoutés, elle sera décrite à la section
« Catégorisation automatique ».
Les détails de ce procédé sont progressivement décrits dans la suite du rapport.
Macrostructure & Microstructures
Pour éviter les redondances, l'information contenue dans les fragments - que nous appelons « microstructure » - est séparée de la structure des fragments (vue comme des contenants imbriquées) - que nous appelons « macrostructure ». Ceci est illustré dans les deux figures Fig.8 et Fig.9.
La première figure (Fig.8) montre schématiquement un document avec ses microstructures (observez notamment les nœuds récipients, schématisés par des ovales, qui se trouvent aux emplacements où les fragments s'imbriquent les uns dans les autres) :
La deuxième figure (Fig.9) montre le même document avec les microstructures qui ont été séparées (observez maintenant que les récipients, représentés par des ovales, se trouvent tant dans les fragments que dans les microstructures):
Les deux figures Fig.10 et Fig.ll illustrent la décomposition en macrostructure et microstructures pour l'exemple utilisé dans les sections précédentes.
Nous appelons « context » (« contexte » en français) le couple {macrostructure ; microstructures}. La figure Fig.12 illustre deux contextes et leurs références. Le contexte représentant le document de notre exemple, avant insertion de l'article du second document, est présenté ci-dessous. Les microstructures sont d'abord regroupés dans un nœud « mix:microstructures », les fragments et leur imbrication sont ensuite spécifiés dans le nœud « mix:macrostructure » (conformément au schéma de la figure ci-avant). Noter que comme aucune insertion de référence à fragment n'a encore été faite, tous les fragments sont des références à des microstructures (mix:micr-ref).
< ?xml version= "1.0" encoding="iso-8859-l" ?> <mix:context xmlns:mix="urn:x-schema:..."> <mix:microstructures mix:last-micr-id="4"> <DOCUMENT mix:micr-id="l" mix:recipient-id="l"/> <ARTICLE mix:micr-id="2"> <TITRAILLE/>
<CONTENUS mix:recipient-id="l"/> </ARTICLE>
<CONTENU mix:micr-id="3"> <INTERTITRES/> <ILLUSTRATIONS/> <PARAGRAPHE>rextei<PARAGRAPHE> </CONTENU>
<CONTENU mix:micr-id="4"> <INTERTITRES/> <ILLUSTRATIONS/> <PARAGRAPHE>7eΛ:te2<PARAGRAPHE> </CONTENU> </mix:microstructures>
<mix:macrostructure mix:last-fragment-id="4"> <mix:fragment mix:fragment-id="l" mix:autorizations="private"> <mix:micr-ref mix:micr-id="l"> (DOCUMENT) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="2" mix:autorizations="public"> <mix:micr-ref mix:micr-id="2"> (ARTICLE) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="3" mix:autorizations="private"> <mix:micr-ref mix:micr-id="3"> (1er CONTENU) </mix:micr-ref </mix:fragment>
<mix:fragment mix:fragment-id="4" mix:autorizations="private"> <mix:micr-ref mix:micr-id="4"> (2e CONTENU) </mix:micr-ref> </mix:fragment> </mix:recipient> </mix:micr-ref> </mix: fragments </mix:recipient> </mix:micr-ref> </mix:fragment > </mix:macrostructure> Importation de fragments
La figure Fig.13 montre le premier document après insertion de l'article du deuxième document.
Après l'insertion de l'article du deuxième document, le noeud fragment qui représente le document (voir dans le contexte présenté précédemment « DOCUMENT lère version » mentionné entre paranthèses) est remplacé par une nouvelle version (voir ci-dessous «DOCUMENT 2e version » mentionné entre parenthèses)3. Noter que comme une insertion a été faite, certains fragments sont maintenant des références à fragments « mix:fragment-ref » (ce sont ce qu'on avait appelle des « Références de mise-à-jour » ; pour simplifier, on les appellera des références).
< ?xml version= "1.0" encoding="iso-8859-l" ?> <mix:context xmlns:mix="urn:x-schema: ...">
<mix:macrostructure mix:last-fragment-id="7"> <mix:fragment mix:fragment-id="l" mix:autorizations="private"> (DOCUMENT 2e version) <mix:micr-ref mix:micr-id="l"> (DOCUMENT) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="2" mix:autorizations="public"> <mix:micr-ref mix:micr-id≈"2"> (1er ARTICLE) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="3" mix:autorizations="private"> <mix:micr-ref mix:micr-id="3"> (1er CONTENU) </mix:micr-ref> </mix:fragment>
<mix:fragment mix:fragment-id="4" mix:autorizations="private"> <mix:micr-ref mix:micr-id="4"> (2e CONTENU) </mix:micr-ref> </mix:fragment> </mix:recipient> </mix:micr-ref> </mix:fragment>
<mix:fragment mix:fragment-id="5" mix:autorizations="public"> <mix:fragment-ref mix:src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2" > (2e ARTICLE) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="6" mix:autorizations="private"> <mix:fragment-ref mix:src=" http ://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=3"/> (1er CONTENU) </mix:fragment>
<mix:fragment mix:fragment-id- " mix:autorizations="private"> <mix:fragment-ref mix:src=" http ://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=4"/> (2e CONTENU) < mix:fragment> </mix:recipient>
3 Noter que pour des raisons de clarté, on a ici ajouté tous ses sous-fragments. En réalité, ceci ne se fera en qu'au fur et à mesure des besoins, comme décrit plus loin dans la section «Manipulations et Suggestions ». </mix:fragment-ref > </mix: fragment> </mix:recipient> </mix:micr-ref > </mix:fragment > </mix:macrostructure>
L'exemple ci-dessus illustre la création de références à des fragments se trouvant dans un autre contexte. Le lecteur aura compris que la même approche permet aussi de référencer des fragments du même contexte (comme l'illustre schématiquement la figure précédente). Nous verrons plus loin que l'on peut d'ailleurs aussi référencer des éléments de documents externes non structurés sous la forme de contexte.
Cache
Comme décrit plus haut, un fragment peut être constitué d'une référence à un autre fragment, ce dernier se trouvant éventuellement dans un autre ordinateur et pouvant lui même référencer un troisième fragment se trouvant dans un troisième ordinateur, et ainsi de suite, jusqu'au dernier fragment qui lui pointe sur une microstructure.
En conséquence, pour assembler toutes les microstructures récupérées au bout des chaînes de références, beaucoup de communications entre machines peuvent être nécessaires. L'assemblage du document à partir de son contexte peut donc être relativement lourd.
De plus, il suffit qu'une seule machine (ou logiciel serveur) dans une chaîne soit en panne, ou qu'une seule connexion soit rompue, pour que ladite microstructure en bout de chaîne ne puisse pas être récupérée, c'est-à-dire téléchargée de proche en proche jusqu'au document que l'on cherche à assembler.
L'idée du cache est de mémoriser en local, dans le contexte, les microstructures externes accédées, du moins certaines d'entre elles. On ne mémorisera en général que les microstructures qui ne résident pas sur la même machine.
Le code XML ci-dessous inclut maintenant le cache (pour l'exemple considéré, après insertion du 2e article):
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<mix:context xmlns:mix="urn:x-schema:..."> <mix:microstructures mix:last-micr-id="4">
</mix:microstructures> <mix:cache mix:last-cache-id="3"> <ARTICLE mix:cache-id="l" mix:time-loaded="..." mix:refresh-every="..." mix:src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2"> < TTRAILLE/>
<CONTENUS mix:recipient-id=" 1 "/> </ARTICLE>
<CONTENU mix:cache-id="2" mix:time-loaded="..." mix:refresh-every="..." mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=3"/>
<ΓNTERTITRES/> <ILLUSTRATIONS/>
<PARAGRAPHE>reΛ:te3<PARAGRAPHE> </CONTENU> <CONTENU mix:cache-id="3" mix:time-loaded="..." mix:refresh-every="..." mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=4"/>
<ΓNTERTITRES/> <ILLUSTRATIONS/>
<PAPvAGRAPHE>7fejcte4<PARAGRAPHE> </CONTENU> </mix:cache>
<mix:macrostructure mix:last-fragment-id="7"> <mix:fragment mix:fragment-id="l" mix:autorizations="private"> <mix:micr-ref mix:micr-id="l"> (DOCUMENT) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="2" mix:autorizations="public">(ler ARTICLE)
</mix:fragment>
<mix:fragment mix:fragment-id="5" mix:autorizations="public">(2e ARTICLE)
<mix:cache-ref mix:cache-id=" 1 "/>
<mix:fragment-ref mix:src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2"
>
<mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="6" mix:autorizations="private"> <mix:cache-ref mix:cache-id="2"/> (1er CONTENU) <mix:fragment-ref mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=3"/> </mix:fragment>
<mix:fragment mix:fragment-id="7" mix:autorizations="private"> <mix:cache-ref mix:cache-id="3"/> (2e CONTENU) <mix:fragment-ref mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=4"/> </mix:fragment> </mix:recipient> </mix:fragment-ref > </mix:fragment> </mix:recipient> </mix:micr-ref> </mix:fragment > </mix:macrostructure>
Approche «pull »
Un attribut de fraîcheur (micπtime-loaded) et un attribut de renouvellement (micπrefresh-every) sont associés aux microstructures du cache. En comparant les valeurs de ces deux attributs le système décide si une microstructure du cache est acceptable tel quel (cas où micπtime-loaded + micπrefresh-every < temps actuel) ou si elle doit être chargée à nouveau.
Approche « push » Une approche en « push » est aussi possible : à chaque (ou sélectivement certains) fragment amont sont associé les références sur les fragments qui l'ont importé (à l'aval). Ces derniers sont notifiés (DeleteCache) avant la suppression dudit fragment amont, le cas échéant
Exemple (les références vers l'aval sont notés « mix:back-ref ») :
<mix:fragment mix:fragment-id="7" mix:autorizations="private"> <mix:back-refs>
<mix:back-ref =" http://.../.../DeleteCache?context=/.../docA.xml &fragmenfld=257> <mix:back-ref =" http://.../.../DeleteCache?context=/.../docB.xml &fragmentld=85>
</mix:back-refs>
<mix:cache-ref mix:cache-id- ' 123 "/>
<mix:fragment-ref mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc3.xml &fragmentId==4"/> </mix:fragment>
Bien entendu, les approches « pull » et « push » peuvent être combinées.
Références sur des nœuds externes
Dans un contexte on peut référencer des éléments de n'importe quelle ressource, notamment d'une ressource XML classique ou d'un fichier HTML, ou d'un autre type de document, fichier ou base de données. Prenons l'exemple d'un fichier HTML :
<html>
<head>
<title>Portals</tit!e> </head> <body>
<ul>
<li>
<a href=" ...">TexteA<la> </li> <li>
TexteB </li> </ul>
</body> , </hrml>
Certains nœuds de la structure hiérarchique que forment les éléments HTML, comme par exemple ceux ayant la balise <ul>, représentent par nature des récipients (contenant des fragments <li> en l'occurrence). D'autres nœuds, comme <hl> à <h6>, peuvent être vus comme le début d'un fragment au sens qui nous intéresse. Un hyperlien (<a>) peut aussi être vu comme une référence sur un fragment. L'utilisateur peut vouloir « attraper » et « glisser-déposer » de tels fragments pour les reproduire ailleurs (selon la description faite à la section suivante « Présentation à l'utilisateur »).
Le fait de glisser-déposer un fragment (dans un document structuré en interne sous la forme d'un contexte) consiste alors à le référencer (sous la forme d'un mix:fragment-ref, « référence de mise-à-jour »). On voit donc bien que les éléments des fichiers HTML peuvent être utilisés comme des fragments, au même titre que les fragments XML décrits précédemment, c'est-à-dire des fragments que l'on référence dans un contexte.
Cependant, à la différence des fragments que l'on a présentés dans les sections précédentes, il n'y a pas d'attributs (mix:recipient ou mix:fragment) pour distinguer les fragments (et définir à priori leurs granularités et autorisations d'accès) et par conséquent tous les éléments HTML sont potentiellement des fragments !
Le système utilisé doit donc permettre de sélectionner les nœuds qui vont servir de fragment, ainsi que ceux qui vont servir de sous-fragments le cas échéant. On pourra alors modifier des parties d'un fragment importé tout en permettant au reste du fragment importé d'être tenu àjour dans le futur.
Pour ce faire, la page HTML en question est automatiquement transformée (à la volée, par exemple par une feuille de style en XSLT ; voir à ce sujet la section suivante « Présentation à l'utilisateur ») avant d'être présentée à l'utilisateur, de manière à ce que des « poignées » (boutons) soient affichées et lui permettent de sélectionner des fragments et récipients parmi un ensemble de premiers fragments et récipients présentés par défaut. Ces premiers récipients et fragments sont sélectionnés automatiquement selon des règles (modifiables), comme par exemple : présenter tous les <ul> comme récipient et tous les <li> comme fragment. De plus, l'utilisateur peut naviguer d'un élément à son parent ou enfant : sur commande de l'utilisateur, chaque poignée peut être supprimée ou remplacéee par (ou encore dupliquée en) une autre en suivant l'arborescence des nœuds HTML (noter que, dans ce cheminement, certains nœuds peuvent être ignorés). L'utilisateur peut ainsi sélectionner n'importe quel fragment de la page. Il distingue ainsi les fragments qui l'intéresse, configure leur arborescence de récipients et sous- fragments. Il peut supprimer un fragment et insérer un nouveau fragment dans un récipient.
Les ressources HTML rentrent ainsi dans le cadre général du système décrit dans ce rapport. On peut mixer dans une même macrostructure des références à fragment HTML et XML (ou encore d'autres ressources).
Les fragments et récipients importés des pages HTML du Web peuvent avantageusement emichir un contexte créé par un utilisateur. Ce dernier peut par exemple prendre une page d'un libraire en ligne, transformer en récipient une liste de livres présentée dans la page, et utiliser ensuite ce récipient et les fragments qu'il contient pour (1) supprimer certains livres de sa « version personnelle » (ainsi créée) du site du libraire4 et (2) y insérer d'autres fragments (présentant notamment d'autres livres) glanés par exemple dans un autre site de libraire5, tout en continuant de recevoir dans ce même récipient les nouveaux livres présentés dans le futur par le premier libraire.
Par eilleurs, dans le cadre des écrans de taille réduite des nouveaux ordinateurs portables (« PocketPC », etc), le fait de pouvoir suggérer à l'utilisateur, automatiquement, des fragments de pages HTML, plutôt que des pages entières, prend une importance accrue. Nous verrons à la section « Catégorisations automatiques » comment des fragments, notamment des fragments de pages HTML, peuvent être suggérés automatiquement en fonction de leurs catégories.
Présentation à l'utilisateur
Assemblage du document XML
Pour qu'un contexte puisse être exploité à l'extérieur du système (notamment pour qu'il puisse être présenté à l'utilisateur sous la forme d'une page affichée) le système le transforme d'abord en un document XML « classique » dans lequel les nœuds récipients et fragments sont spécifiés au moyen d'attributs, comme décrit à la section « Nœuds récipients et fragments dans les structures XML ». On va appeler cela « assemblage » ou « reconstitution » du document.
4 (non pas du site public mais de sa version personnelle de ce site public, qui est stockée sous la forme d'un contexte)
5 (c'est-à-dire dans sa version personnelle des pages de cet autre site) Avantageusement, comme ce ne sont que des attributs qui spécifient quels sont les nœuds récipients et fragments, on n'ajoute pas de nouveaux nœuds et la structure des nœuds reste donc inchangée.
Pour l'exemple présenté jusqu'ici, le document XML reconstitué à partir du contexte aura l'allure suivante :
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<DOCUMENT xmlns:mix="urn:x-schema: ..." mixxontext =" ... " mix:fragment-id=" 1 " mix:fragment="private" mix:recipient-id=" 1 " mix:recipient="private" ...> <ARTICLE mix:fragment-id="2" mix:fragment="public" ...> <riTRAJLLE/> <CONTENUS mix:recipient-id="l" mix:recipient="private">
<CONTENU mix:fragment-id= "3" mix:fragment="private"...>
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>rextei</PARAGRAPHE> </CONTENU> <CONTENU mix:fragment-id= "4" mix:fragment="private"...>
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>reΛte2</PARAGRAPHE> </CONTENU> </CONTENUS> </ARTICLE> </DOCUMENT>
Un procédé simple de reconstitution d'un document XML à partir d'un contexte est le suivant :
1. Accès au contexte en question
2. Assemblage des résultat des « résolutions » des références : toutes les références à fragments se trouvant dans le contexte sont résolus. Pour ce faire, pour chacune d'elle,
" soit elle pointe sur une microstructure (se trouvant dans le contexte courant), auquel cas la résolution retourne cette microstructure
" soit elle pointe sur un élément externe (par exemple la référence pointe sur un nœud d'un fichier XML classique), auquel cas la résolution retourne cet élément u soit elle pointe sur une autre référence dans le même contexte, auquel cas la référence pointée est elle-même résolue (récursivement)
" soit elle pointe sur une autre référence dans un autre contexte, auquel cas a. si la microstructure correspondante se trouve dans le cache et ses attributs de fraîcheur et de renouvellement autorisent de l'utiliser, alors la résolution retourne cette microstructure b. sinon la référence pointée est elle-même résolue (récursivement)
Application de feuilles de style
Avant présentation à l'utilisateur, chaque élément ou microstructure (qui résulte de la résolution d'une référence) est transformé par une feuille de style (notamment en XSLT). Il est transformé
" soit par la feuille de style associé au document entier assemblé (le fragment à la racine) soit par la feuille de style associée au récipient qui l'accueille soit par la feuille de style associée au fragment ou à la microstructure qui était pointé.
Pour spécifier l'option choisie, à chaque fragment peuvent être associés les attributs suivants :
« mix:micr-style-src » spécifiant la feuille de style qui a été choisie par l'auteur de la microstructure de tête dudit fragment,
« mix:fragment-style-src » spécifiant la feuille de style pour ledit fragment (choisie par son propriétaire),
« mixφreferred-style » qui figure dans le cas où le propriétaire dudit fragment préfère appliquer le style de la microstructure de tête dudit fragment (« mix:preferred-style = "micr" ») ou celui dudit fragment (« mix:preferred-style = "fragment" »). Dans le cas où aucun style local n'est préféré (alors c'est le style du document entier qui sera appliqué), le troisième attribut ne sera pas spécifié, et les premiers et/ou deuxième attributs ne serviront que pour les fragments importés plus à l'aval.
Dans le cas où l'auteur de la microstructure en question exige que son propre style soit appliqué, il peut ajouter cette contrainte au moyen d'un attribut supplémentaire (« mix:enforce-style- to="public" - la valeur "public" donnée à indique que cette exigence n'est à appliquer que pour le grand public). Avantageusement, le système respectera alors cette exigence automatiquement en forçant la valeur de l'attribut mix:preferred-style (mix:preferred-style="micr").
Un procédé d'implémentation possible est le suivant :
Lors de l'application des feuilles de style, le système transforme en XHTML le document sauf tous les fragments qui ont l'attribut « mix:preferred-style » avec une valeur spécifiée (ayant comme valeur "micr" ou "fragment"). Ces derniers sont copiés tels quels (mot à mot) afin que leur transformation puisse être effectuée lors d'un prochain passage. Le procédé est ainsi itératif et à chaque passage, les fragments qui n'ont pas encore été transformés en XHTML, c'est-à-dire tous les nœuds qui ont un attribut « mix:preferred-style » spécifié et dont aucun ancêtre a ce même attribut spécifié, sont transformés à leur tour, jusqu'à que tous les fragments (tous les sous- fragments en profondeur) aient été pris en compte.
La figure Fig.14 présente un organigramme qui décrit ce procédé.
Présentation en Mode Manipulation
La page présentée à l'utilisateur peut être présentée en « mode normal » ou en « mode manipulation ».
Le mode normal est celui par défaut correspond à la page publiée normalement.
En mode manipulation, avant d'appliquer une feuille de style au résultat de la résolution d'une référence (par exemple à une microstructure), la feuille de style est transformée automatiquement (à la volée) afin d'insérer des « boutons » de manipulation dans la page.
Le système permet alors de manipuler, notamment de reproduire d'un site à l'autre, des fragment de ressources (documents) XML présentés pour affichage à l'écran à travers des feuilles de style, en n'agissant que sur leur présentation d'affichage à l'écran.
Pour reproduire un fragment, on utilise des objets graphiques servant de « poignée » et/ou de « cible » associés à la présentation des fragments. Une poignée sert à attraper un fragment, pour notamment le glisser-déposer à l'endroit où l'on veut le reproduire, cet endroit étant indiqué graphiquement par une cible. Ces objets graphiques apparaissent sur simple demande de l'utilisateur.
Ce procédé est illustré par la figure Fig. 15.
Quand l'internaute clique sur le « bouton pour passer en mod manipulation », les poignées des fragments qui peuvent être importées sont ajoutées à la page affichée (en fonction des autorisations accordées à l'utilisateur), comme illustré dansla figure Fig. 16 :
L'utilisateur peut alors attraper un des fragments pour le glisser-déposer dans une de ses propres pages (voir la figure Fig.17).
Le résultat de l'opération de glisser-déposer illustré dans les figures ci-avant est illustré en figure Fig. 18.
Détails des boutons de manipulation
Optionnellement, chaque page manipulable (que l'utilisateur peut faire passer en mode manipulation) peut possède un bouton de basculement (dans la figure Fig.19, ce bouton est ici intitulé « Click2handle »)6.
L'effet principal de cliquer sur le bouton « Click2handle » est de faire apparaître les poignées de manipulation des récipients et fragments de la source de la page (voir figure Fig.20). Ces poignées n'apparaîtront que pour les récipients et fragments en fonction des droits attribués aux utilisateurs. Ainsi, pour un fragment « private », aucune poignée n'apparaîtra à un visiteur (visiteur grand public) du site. Il existe même des fragments pour lesquels la poignée n'apparaîtra pour aucun utilisateur ; les attributs « mix :fragment » décrits précédemment servent ainsi à spécifier la granularité des fragments vus (manipulables) par l'utilisateur.
L'utilisateur courant qui visite une page peut notamment être : un visiteur non enregistré, un visiteur enregistré et reconnu par le système, ou le propriétaire de la page. (Bien évidemment, une classification plus fine des utilisateurs est possible). Typiquement, les visiteurs enregistrés et reconnus peuvent « attraper » un fragment pour le glisser-déposer dans leur propre page, mais ils ne peuvent pas le modifier dans la page d'origine; le droit de modification n'appartenant qu'au propriétaire de la page visitée.
D'autres règles peuvent être spécifiées, et selon les droits possédés par l'utilisateur, une même poignée peut permettre une ou plusieurs manipulations parmi les suivantes :
1. éditer (modifier) le contenu du fragment en question,
2. le supprimer,
3. l'attraper (le bouton joue le rôle de « poignée ») pour le glisser-déposer dans un autre (ou le même) récipient, a. avant un fragment existant le cas échéant (en le déposant sur un bouton « fragment », voir la figure ci-après) b. ou en dernière position (en le déposant au niveau d'un bouton « récipient », voir la figure ci-après)
4. et jouer le rôle de « cible » permettant de déposer à cet endroit un autre fragment.
Le bouton servant à supprimer un fragment peut être distinct de la poignée. Dans une telle conception on a en tout deux boutons par fragment manipulable :
• une poignée édition + poignée + cible,
(Alternativement, ce bouton aurait pu faire partie du navigateur ou en tant qu'extension du navigateur; ou encore, il aurait pu être placé à un seul endroit du site et permettre de faire basculer la page couramment utilisée, la fenêtre qui a le focus) • un bouton suppression.
Les poignées de manipulation incluent aussi des boutons (appellées « bouton récipient », voir la figure ci-avant) qui
1. indiquent la position de fin d'un récipient,
2. permettent de créer un nouveau fragment à cette position dans le récipient
3. et jouent le rôle de cible pour y déposer un fragment que l'on veut reproduire.
Applications typiques
Le système permet à ce que des ré-utilisations d'information puissent notamment être effectuées à l'intérieur d'un site Web (par exemple par son webmaster), entre plusieurs sites ou encore à partir d'une page d'un site vers une version personnelle de celle-ci.
Au moment du glisser-déposer, le fragment importé peut être adapté automatiquement, voire refusé, pour satisfaire les contraintes ou préférences du récipient cible, et les conditions d'un accord (ou contrat) à conclure le cas échéant entre les propriétaires des sites de part et d'autre du transfert, peuvent être proposées automatiquement d'abord à l'utilisateur qui effectue le glisser- déposer, ensuite et de manière asynchrone (notamment au moyen d'un courrier électronique) à l'autre partie.
En effet, dans la mesure où les références de mise àjour sont des appels de méthodes exposés par des services web, comme nous l'illustrons dans ce rapport, le fragment retourné lors de la reconstitution d'une page peut notamment avoir la forme d'un formulaire interactif ou autre programme exécutable.
Une application typique est la publication sur l'Internet, ou dans un intranet, d'un appel d'offres nécessitant plusieurs contributions, ces dernières devant être combinées et adaptées les unes aux autres pour répondre aux exigences requises. Avantageusement, le système permet à un premier contributeur d'importer l'appel d'offres sur son site et de le republier automatiquement à destination de deuxièmes contributeurs potentiels après lui avoir soustrait la contribution qu'il propose d'offrir lui-même. Un second contributeur peut alors importer la nouvelle version de l'appel d'offre, compléter la première offre avec sa propre proposition de contribution et automatiquement republier une troisième version de l'appel d'offres, et ainsi de suite. L'appel d'offres se répand et se complète ainsi progressivement, tout en se spécialisant de plus en plus, jusqu'à que la réponse comprenne la totalité des composants nécessaires. Chaque proposition de contribution s'insère dans une chaîne de contributions et l'ensemble des chaînes ainsi formée constitue une structure arborescente (ou chaîne pyramidale) de maillons qui peut être gérée par chaque contributeur à partir du maillon qu'il a créé.
L'application symmétrique est la publication sur l'Internet d'un lot (par exemple de marchandises) que l'on met en vente, les constituants dudit lot pouvant être vendus ensemble (à un seul acheteur) ou séparément (à des acheteurs différents), et la vente n'étant conclue que si en fin de chaîne tout le lot est acheté. En utilisant le système, la proposition de vente peut être republiée d'acheteur en acheteur, chacun ôtant la partie qu'il propose d'acheter, jusqu'à que le lot soit vendu entièrement. Modes Suggéré, Accepté, Gelé, Refusé
On va maintenant décrire le procédé qui consiste à assembler un document, notamment présenter en « mode suggéré » les sous-fragments d'un fragment inséré et permettre à l'utilisateur de les valider ou les refuser. Dans le cas où un sous-fragment est validé, d'autres fragments à l'aval pourront avoir une référence sur lui et il pourra encore être modifié ou supprimé.
Les références à fragment (nœuds mix:fragment-ref) peuvent être en mode « suggéré »,
« accepté » (c'est-à-dire validé), « refusé » et optionnellement en mode « gelé » (respectivement
« suggested », « accepted », « refused », « frozen » dans les exemples).
Fonction de canal de communication
A chaque présentation (à l'utilisateur ou à un système ayant ce rôle) d'un fragment en mode accepté, tous ses sous-fragments se trouvant en mode suggéré sont aussi présentés.
Ainsi, quand dans une chaîne de références (résultant d'une suite de glisser-déposer comme décrit à la section précédente), un nouveau sous-fragment est inséré ou créé ex-nihilo au sein d'un fragment « amont », ce sous-fragment est présenté en mode suggéré à chaque nouvelle présentation, à l'aval, de chaque fragment qui référence ledit fragment amont, de chaque fragment (encore plus aval) qui réfrénée ce dernier, et ainsi de suite de l'amont vers l'aval. Un fragment en mode accepté participe ainsi à un « canal de communication » de l'amont vers l'aval7 pour les nouveaux sous-fragments ajoutés.
Le mode suggéré peut être changé par l'utilisateur (ou par un système qui joue le rôle d'utilisateur) : chaque sous-fragment peut ainsi passer en mode accepté, refusé ou gelé. Noter que par utilisateur on entend ici le propriétaire du contexte en question (ou un système qui a les mêmes droits).
Importation d'un fragment
Par définition des modes, un fragment en mode suggéré ou refusé ne peut pas être importé (glissé-déposé) dans un autre fragment (à l'aval). En revanche, un fragment en mode accepté ou gelé le peut.
Comme décrit précédemment, le fait d'insérer (importer) un fragment dans un autre fragment consiste à insérer dans ce dernier (dans le contexte) une référence sur le premier. D'office, le fragment ayant cette référence prend le mode accepté. Par exemple :
<mix:fragment mix:fragment-id="5" mix:autorizations="public" mix:mode="accepted">
<mix:fragment-refmix:src= "http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=2"/>
</mix:fragment >
Si on insère, ou si on crée ex-nihilo, un sous-fragment dans un fragment qui est en mode suggéré, ce dernier passe automatiquement en mode accepté, et ce procédé se répète (de parent en parent de parent, et ainsi de suite) vers la racine jusqu'au prochain nœud accepté ou gelé.8
7 Noter que, comme il l'est indiqué plus loin dans la section « Quelques variantes », ce même canal peut aussi servir à communiquer des fragments de l'aval vers l'amont, sélectivement.
8 Ceci s'explique par le fait que ledit sous-fragment importé sera d'office en mode accepté et consistera donc en une référence. Puisque la structure est arborescente, son fragment parent doit aussi être matérialisé par une référence et ne pourra donc pas être en mode suggéré. Et ainsi de suite, tous ses fragments ancêtres doivent nécessairement être matérialisés par une référence et doivent être en mode accepté ou gelé. Pour illustrer par un exemple, reprenons (ci-dessous) le document reconstitué (qui était présenté à la section « Présentation à l'utilisateur ») et complétons-le en explicitant les modes (noter que dans cet exemple, tout le document à été importé, c'est pourquoi l'article et ses contenus sont en mode suggéré) :
<DOCUMENT mix:context="..." mix:fragment-id="l" mix:fragment="private" mix:recipient- id="l" mix:recipient="private" mix:mode="accepted">
<ARTICLE mix:upstream-fragment-id="12" mix:fragment="public" mix:mode="sιιggested" mix:nearest-accepted-ancestor="l ">
<ΓITRAILLE/>
<CONTENUS mix:recipient-id="l" mix:recipient="private">
<CONTENU mix:upstream-fragment-id= "13" mix:fragment- 'private" mix:mode="suggested" mix:nearest-accepted-ancestor="l">
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>7exte/< PARAGRAPHE> </CONTENU>
<CONTENU mix:upstream-fragment-id= "14" mix:fragment="private" mix:mode="suggested" mix:nearest-accepted-ancestor="l">
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>rexte2</PARAGRAPHE> </CONTENU> </CONTENUS> </ARTICLE> </DOCUMENT>
Dans un document reconstitué, l'attribut « mix:upstream-fragment-id » d'un fragment en mode suggéré a pour valeur l'identifiant du fragment (accepté ou gelé) importé qui se trouve dans le contexte amont. En outre, chaque fragment en mode suggéré a un attribut « mix:nearest- accepted-ancestor » qui permet au système de trouver facilement le contexte amont en remontant au premier fragment ancêtre qui soit accepté ou gelé.
Le fait d'insérer maintenant un nouveau contenu dans l'article entraîne le passage de ce dernier en mode accepté et aussi de créer un nouvel identifiant (mix:fragment-id="2") local au contexte : <DOCUMENT mix:context="..." mix:fragment-id="l" mix:fragment="private" mix:recipient- id="l" mix:recipient="private" mix:mode="accepted">
<ARTICLE mix:fragment-id="2" mix:fragment="public" mix:mode="accepted"> TITRAILLE/> <CONTENUS mix:recipient-id="l" mix:recipient="private">
<CONTENU mix:upstream-fragment-id= "13" mix:fragment="private" mix:mode="suggested">
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>rextei</PARAGRAPHE> </CONTENU>
<CONTENU mix:fragment-id= "3" mix:fragment="private" mix:mode="accepted">
<INTERTITRES />
<ILLUSTRATIONS/>
<PARAGRAPHE>rexte.?</PARAGRAPHE> </CONTENU>
<CONTENU mix:upstream-fragment-id= "14" mix:fragment="private" mix:mode="suggested"> <INTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>rexte2</PARAGRAPHE> </CONTENU> </CONTENUS> </ARTICLE> </DOCUMENT>
Un fragment en mode suggéré n'existe qu'implicitement
Un sous-fragment en mode suggéré n'est pas explicitement inséré dans la macrostructure (dans le contexte). Dans l'exemple présenté ci-dessus (avant l'insertion d'un contenu supplémentaire), le document est en mode accepté et ses sous-fragments sont en mode suggéré ; ils ne figurent donc pas explicitement dans le contexte, comme illustré ci-dessous :
<mix:fragment mix:fragment-id="l" mix:autorizations="private" mix:mode="accepted"> (DOCUMENT)
<mix: fragment-ref mix: src=" http ://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml
&fragmentId=ll"/> <mix:recipient mix:recipient-id=" 1 ">
(ici se trouve implicitement tout l'article en mode suggéré)
</mix:recipient> </mix:micr-ref> </mix:fragment>
Dans le contexte, suite au fait d'accepter, de geler ou encore de refuser un fragment qui était présenté en mode suggéré, un fragment explicite (mix: fragment) avec une référence sur le fragment à l'amont (mix: fragment-ref) est créé. Nous allons maintenant examiner ces cas.
Un fragment en mode refusé existe explicitement
Refuser un fragment a pour but de permettre d'éviter de le présenter à nouveau : A chaque présentation d'un fragment en mode accepté ou gelé, sont présentés les sous-fragments dudit fragment sauf ceux en mode refusé.
Supposons maintenant que le deuxième sous-fragment CONTENU (qui, comme tout le reste de l'article, était implicitement en mode suggéré) soit maintenant refusé. La forme reconstituée sera alors comme suit :
<DOCUMENT mix:context="..." mix:fragment-id="l" mix:fragment="private" mix:recipient- id="l" mix:recipient="private" mix:mode="accepted">
<ARTICLE mix:fragment-id="2" mix:fragment="public" mix:mode="accepted"> riTRAILLE/>
<CONTENUS mix:recipient-id=" 1" mix:recipient="private">
<CONTENU mix:upstream-fragment-id= "13" mix:fragment="private" mix:mode="suggested" mix:nearest-accepted-ancestor=" 1 ">
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>7exte7</PARAGRAPHE> </CONTENU>
<CONTENU fragment-id= "4" mix:fragment="private" mix:mode="refused" >
<ΓNTERTITRES /> <ILLUSTRATIONS/>
<PARAGRAPHE>rexte2</PARAGRAPHE> </CONTENU>
</CONTENUS> </ARTICLE> </DOCUMENT>
En effet, une référence doit alors être créée dans le contexte pour ce sous-fragment avec l'attribut mix:mode- 'refused" ainsi que pour le fragment parent (article). Voici un extrait de ce contexte :
<mix:fragment mix:fragment-id="l" mix:autorizations="private" mix:mode="accepted"> (DOCUMENT)
<mix:fragment-ref mix:src=
"http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml
&fragmentld=ll">
<mix:recipient mix:recipient-id=" 1 ">
<mix:fragment mix:fragment-id="2" mix:autorizations="public" mix:mode="accepted"> (ARTICLE)
<mix:fragment-ref mix:src=
"http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml
&fragmenfld=12">
<mix:recipient mix:recipient-id=" 1 ">
(le premier CONTENU est en mode suggéré, donc il ne figure pas explicitement ; par contre le deuxième CONTENU est en mode refusé, donc il figure explicitement)
<mix:fragment mix:fragment-id=="4" mix:autorizations="private" mix:mode="refused"> (2e CONTENU) <mix:fragment-ref mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.x ml &fragmentId=14"/> </mix:fragment> </mix:recipienf </mix:fragment-ref > </mix:fragment> </mix:recipient> </mix:fragment-ref> </mix:fragment>
Fragment en mode accepté
Un fragment en mode accepté consiste en une référence sur un fragment à l'amont.
On peut insérer (créer ou importer) des sous-fragments dans un fragment accepté à l'aval, indépendamment des sous-fragments à l'amont. Ces sous-fragments insérés seront par défaut eux-même en mode accepté. Les fragments acceptés sont sauvegardés dans le cache, comme décrit précédemment dans la section « Cache », sauf que l'on va maintenant mémoriser en plus tous leurs sous-fragments qui sont en mode suggérés, et introduire un nœud <mix:clipped> pour les autres sous-fragments de manière à garder une trace de leur emplacement.
Illustrons ceci avec l'exemple qui était donné dans la section « cache », mais supposons que le premier des deux sous-fragments (CONTENU) de l'article importé est en mode suggéré et que le deuxième est en mode accepté:
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<mix:context xmlns:mix="urn:x-schema: ..."> <mix:microstructures mix:last-micr-id="4">
</mix:microstructures> <mix:cache mix:last-cache-id="3"> <ARTICLE mix:cache-id="l" mix:time-loaded="..." mix:refresh-every="..." mix:src= ',http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2"> riTRAILLE/>
<CONTENUS mix:recipient-id=" 1 "/> <CONTENU>
<INTERTITRES/> <ILLUSTRATIONS/> <PARAGRAPHE>rexte3<PARAGRAPHE> </CONTENU>
<mix:clipped mix:fragment-id=7 /> </ARTICLE>
<CONTENU mix:cache-id="2" mix:time-loaded="..." mix:refresh-every=" ..." mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentId=4"/> <INTERTITRES/> <ILLUSTRATIONS/> <PARAGRAPHE>rexte4<PARAGRAPHE> </CONTENU> </mix:cache>
<mix:macrostructure mix:last-fragment-id="7"> <mix:fragment mix:fragment-id="l" mix:autorizations="private"> <mix:micr-ref mix:micr-id="l"> (DOCUMENT) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="2" mix:autorizations="public">(ler ARTICLE)
</mix:fragment>
<mix:fragment mix:fragment-id="5" mix:autorizations="public" mix:mode="accepted">(2e ARTICLE) <mix:cache-ref mix:cache-id=" 1 "/> <mix: fragment-ref mix:src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2"> <mix:recipient mix:recipient-id=" 1 "> (Ici se trouve implicitement le 1er sous-fragment CONTENU en mode suggéré)
<mix:fragment mix:fragment-id="7" mix:autorizations- 'private" mix:mode="accepted"> (2e CONTENU) <mix:cache-ref mix:cache-id="2"/> <mix:fragment-ref mix:src=
"http://domaineX/serviceY/GetFragment?context==/pathZ/doc2.xml &fragmentId=4"/> </mix:fragment> </mix:recipient> </mix:fragment-ref > </mix: fragment> </mix:recipient> </mix:micr-ref> </mix: fragment > </mix:macrostructure>
Fragment en mode gelé
Un fragment en mode gelé consiste essentiellement en une copie d'un fragment à l'amont.
Ainsi, par exemple, si on veut insérer à l'aval la version courante du noeud DOCUMENT à un instant donné, dans le contexte à l'aval on doit ajouter la copie de sa microstructure, ainsi qu'une référence à cette copie dans la macrostructure, avec un attribut mix:mode="frozen". Ceci se fera non seulement pour le fragment DOCUMENT mais aussi, par défaut (l'utilisateur pourra changer le mode), pour tous ses fragments descendants (en l'occurrence ARTICLE et CONTENU) :
< ?xml version= "1.0" encoding= "iso-8859-1" ?> <mix:context xmlns :mix= "urn :x-schema :... "> <mix:microstrucrures mix:last-micr-id= "7">
<DOCUMENT mix:micr-id="4" mix:recipient-id= "1" mix:orig-src="..."/> <ARTICLE mix:micr-id="5" mix:orig-src="...">
<TITRAILLE/>
<CONTENUS mix:recipient-id=" 1 "/> </ARTICLE> <CONTENU mix:micr-id="6" mix:orig-src="...">
<INTERTITRES/>
<ILLUSTRATIONS/>
<PARAGRAPHE>7fe tei<PARAGRAPHE> <CONTENU/> <CONTENU mix:micr-id="7" mix:orig-src="...">
<INTERTITRES/>
<ILLUSTRATIONS/>
<PARAGRAPHE>rejcte2<PARAGRAPHE> <CONTENU/> </mix:microsrructures> <mix:cache>
</mix:cache>
<mix:macrostructure mix:last-fragment-id="l 1">
<mix:fragment mix:fragment-id="8" mix:autorizations="private" mix:mode="frozen">
<mix:micr-ref mix:micr-id="4"/> (DOCUMENT) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="9" mix:autorizations="public" mix:mode="frozeιι">
<mix:micr-ref mix:cache-id="5"/>(ARTICLE) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="10" mix:autorizations="private" mix: mode="frozen">
<mix:micr-ref mix:cache-id="6"/> (1er CONTENU) </mix: fragments
<mix:fragment mix:fragment-id="l 1" mix:autorizations="private" mix: mode="frozen">
<mix:micr-ref mix:cache-id="7"/> (2e CONTENU) </mix: fragments </mix:recipient> </mix:fragment> </mix:recipient> </mix: fragment >
<mix:fragment mix:fragment-id="12" mix:mode="refused" > (DOCUMENT) <mix:fragment-ref mix:src=
"http://domaineX/serviceY/GetFragment ?context=/pathZ/doc2.xml&fragmentId= '/> </mix: fragment >
<mix:fragment mix:fragment-id="13" mix:mode="refused" > (ARTICLE) <mix:fragment-ref mix:src="http :// domaineX/serviceY/GetFragment ?context=/pathZ/doc2.xml&fragmentId=2"/> </mix:fragment >
<mix:fragment mix:fragment-id="14" mix:mode="refused" > (1er CONTENU) <mix: fragment-ref mix:src=" http ://domaineX/service Y/GetFragment ?context=/pathZ/doc2.xml &fragmentld=3 "/> </mix: fragment >
<mix:fragment mix:fragment-id="15" mix:mode="refused" > (2e CONTENU) <mix: fragment-ref mix:src=" http://domaineX/service Y/GetFragment ?context=/pathZ/doc2.xml &fragmentId=4"/> </mix:fragment > </mix:macrostructure> </mix:context>
Pour chaque fragment en mode gelé, un fragment en mode refusé, avec un nouvel identifieur, est créé dans le but d'éviter que le fragment père à l'amont ne le lui resuggère (c'est similaire au cas du fragment refusé). Toutefois, ceci ne se fera que dans le cas où le parent du fragment référencé est lui-même référencé par le parent dudit fragment gelé (sinon il n'y aurait pas de risque de suggestion !).
Dans le cas où une microstructure à ajouter figurait déjà dans l'ensemble des microstructures, on peut détecter cela et éviter de l'ajouter à nouveau. Pour détecter qu'elle figurait déjà on compare son attribut spécifiant son origine (mix:orig-src). Un compteur de « références sur soi » (mix:reference-count) est alors associé à la microstructure pour éviter de la supprimer tant qu'il y a encore un fragment qui pointe sur elle.
Suppression d'un fragment
Supprimer un fragment qui est en mode suggéré consiste à le faire passer en mode refusé. Supprimer un fragment implique de supprimer tous ses sous-fragments. Supprimer un fragment qui était créé ex-nihilo consiste à le supprimer dans le contexte (et en conséquence, aussi du document reconstitué).
Dans le cas où l'on veut supprimer un fragment (qui est en mode accepté ou gelé et dont le fragment parent pointe sur le parent du fragment référencé à l'amont) :
» son mode passe à refusé, (Rappelons qu'un fragment en mode refusé ne sera pas resuggéré à partir du fragment parent à l'amont)
• et un nouveau mix:fragment-id lui est attribué (ainsi, pour l'aval, il est supprimé).
Dès que le système qui gère le contexte aura pris connaissance, le cas échéant, du fait que le parent du fragment référencé à l'amont n'existe plus (car ce dernier a lui aussi été supprimé), il ne sera plus utile de le garder en mode refusé, il sera donc supprimé.
Lorsqu'un fragment est supprimé, les fragments qui le référençaient à l'aval sont aussi supprimés, soit directement (suite à une notification, en « push ») soit dès que le système à l'aval en prend connaissance (à l'occasion d'une reconstitution, en « pull »).
Si un fragment supprimé était refusé à l'aval, sa trace (en mode refusé) à l'aval disparaîtra au moment du prochain accès au contexte aval9.
Modifier un fragment en mode suggéré implique, au préalable, de changer son mode à accepté.
Modifier un fragment, en mode accepté, consiste à
• lui associer une nouvelle référence (pointant sur une nouvelle microstructure ou un fragment différent)
» dans le cas où son parent pointe sur le parent du fragment référencé à l'amont, créer un nouveau fragment (avec un nouveau mix:fragment-id) qui est en mode refusé et qui contient l'ancienne référence pointant sur le fragment à l'aval (celui qui était importé, mais que l'on a maintenant modifié)
" supprimer les anciennes données dans le cache et y sauvegarder celles correspondant audit fragment différent (le cas échéant).
Par exemple, considérons (dans un contexte) le fragment importé suivant :
<mix:fragment mix:fragment-id="5" mix:autorizations="public"> <mix: fragment-ref mix:src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2"> supposons que l'on veuille le remplacer par une microstructure ayant le numéro 123. Si on suppose que son parent pointe sur le parent du fragment référencé à l'amont, l'ancien fragment sera en fait dédoublé en 2 fragments : un nouveau fragment ayant la nouvelle microstructure et l'ancien fragment ayant maintenant un nouvel identifieur (987). Ceci est illustré ci-dessous :
<mix:fragment mix:fragment-id="5" mix:autorizations="public">
<mix:micr-ref mix:micr-ref=" 123 "/> -ζ/mix:fragment> <mix:fragment mix:fragment-id="987" mode="refused">
<mix: fragment-ref mix:src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2"/> </mix:fragment>
9 A chaque présentation du fragment parent d'un fragment refusé, la nécessité de garder ce dernier est vérifié : non seulement on utilise la référence pour éviter de le présenter à l'aval (comme déjà décrit), mais de plus si le fragment n'existe plus à l'amont, on en profite pour le supprimer aussi à l'aval. Lorsque la « microstructure de tête » d'un fragment est modifiée de manière importante (c'est-à- dire de telle sorte que la configuration de ses nœuds récipient soit modifiée), les branches (ou sous-branches) de sous-fragments qui sont restées intactes subsistent dans le nouveau fragment parent de manière à ce que les fragments qui les référençaient à l'aval puissent continuer à le faire. En revanche, les nouvelles branches de sous-fragments, le cas échéant, seront présentés à l'aval en mode suggéré.
Assemblage du document XML à présenter à l'utilisateur
Reprenons l'exemple présenté à la fin de la section «Introduction à la structuration en Macrostructure et Microstructures » (figure 6). On va illustrer comment reconstituer l'article importé dans le Document 1 pour le présenter à l'utilisateur avec ses CONTENUS TexteS, Texteό, Texteδ, Texte4',βt Texte7. Pour la simplicité de l'exemple, on fait l'hypothèse que les données se trouvant dans le cache ne sont pas suffisemment fraîches, et qu'il faut donc les recharger.
Dans le contexte, plus précisément, dans la partie de la macrostructure concernant le deuxième article, il y a seulement les références suivantes (en plus des références aux microstructures Textel et Texte2) : a Document2, fragment Article, mode accepté a Document3, fragment Texteδ, mode accepté
• Document 1, microstructure Texte4' a Document2, fragment Texte4, mode refusé
La reconstitution démarre avec l'appel d'une procédure « GefFragment » (les procédures sont décrites plus loin). Cette dernière lance l'appel « GetFragmentWithout » au Document2 pour demander la reconstitution de l'article qui se trouve dans le Document2, sauf le fragment Texte4 (car il est en mode refusé chez Pappellant, voir la liste « Liste- » décrite avec la procédure GetFragmentWithout). La première ligne ci-dessus (Document2, fragment Article, mode Accepté) est ainsi cosommée. Il restera donc à traiter:
" Documenta, fragment Texte5, mode accepté
" Document 1, microstructure Texte4' a Document2, fragment Texte4, mode refusé
La procédure GetFragmentWithout (appellée sur Document 2) retourne les fragments et les microstructures (récupérées en bout des chaînes de références au moyen de la procédure GetMicrostructures décrite plus loin) de l'article de Document2:
• Fragment Texte3 <• Fragment Texteό
• Fragment Texte4, sous la forme d'un élément « mix:clipped »
" Fragment Texte7
La procédure appelante (GefFragment) consomme la ligne suivante (Document3, fragment Texte5, mode accepté) en appelant GetFragmentWithout sur le Document3 . Le fragment et la microstructure Texte5 ainsi ramenés sont placés dans l'ensemble ci-dessus, au-dessus du fragment Texte4 (conformément à son emplacement dans la macrostructure):
• Fragment Texte3, mode suggéré • Fragment Texteό, mode suggéré » Fragment Texte5, mode accepté
• Fragment Texte4, sous la forme d'un élément « mix lipped », mode refusé
• Fragment Texte'/ ', mode suggéré
Ensuite la procédure GefFragment consomme la ligne suivante (Documentl, microstructure Texte4 ") et place le fragment Texte4 ', au-dessus du fragment Texte4 (conformément à son emplacement dans la macrostructure) :
• Fragment Texte3, mode suggéré " Fragment Texteό, mode suggéré " Fragment Texteδ, mode accepté
" Fragment Texte4 ', microstructure
• Fragment Texte4, sous la forme d'un élément « mix lipped », mode refusé
• Fragment Texte7, mode suggéré
Elle consomme ensuite la dernière ligne restante (Document2, fragment Texte4, mode refusé), et tente ainsi de placer Texte4 qui se trouvait déjà sous la forme « mixxlipped » dans le document en cours d'assemblage.
Finalement, ce dernier est supprimé, puisqu'il ne servira plus de repère pour le placement, toutes les lignes ayant été consommées.
Nous voyons que le mécanisme mis en œuvre pour reconstituer le document XML est essentiellement composé de trois procédures GefFragment, GetFragmentWithout et GetMicrostructures, présentées ci-dessous. La figure Fig.21 est un schéma présentant l'enchaînement des appels à ces procédures.
Fragment Fragment Fragment
GetFragmerit" ϋetFragmentWithotrr OetMicrostructures" GetMicrostructures
Fig.21 Les signatures de ces procédures sont les suivantes public string GetFragment(string context, string fragmentld) public string GetFragmentWithout (string context, string fragmentld, string[,] Liste-) public string[] GetMicrostructures (string context, string[,] Liste+)
GefFragment
Assemble le fragment demandé et tous ses fragments descendants sauf les fra ments en mode refusé.
Si le fragment demandé ou l'un de ses sous-fragments est une référence vers un autre fragment ; alors, on appelle la procédure GetFragmentWithout, en lui passant en paramètre l'identification de ce fragment, et de tous ses sous-fragments que l'on ne veut pas. (cf. A l'appel de GetFragmentWithout) .
GetFragmentWithout
A l'appel : Une nouvelle « Liste- » (liste des fragments non sollicités) est créée à chaque fois pour être passée en argument. Les mix:fragment-id que cette liste contient sont ceux du contexte qui reçoit l'appel.
Elle contient les mix:fragment-id des sous-fragments refusés et gelés, ainsi que ceux des sous- fragments acceptés encore frais. Pour ces derniers on y joint en plus la valeur de l'attribut mix: last-updated.
A la réception :
Assemble la microstructure du fragment demandé avec tous ses fragments descendants, sauf ceux passés dans la Liste-, en les recomposant récursivement (en leur passant la même Liste- en paramètre).
Pour tous les fragments reçus dans la Liste- (sauf cas particulier décrit ci-dessous), on y ajoute un attribut « mix:content-clipped » et on ne retourne pas le contenu (on ne retourne ni le contenu de sa microstructure ni ses propres fragments descendants).
Cas particulier des fragments reçus dans la Liste- qui ont un «mix:last-updated » : si le fragment en question a été mis àjour depuis le temps donné dans la valeur de cet attribut, on le recompose, sinon on est dans le cas normal de la Liste-.
Si le fragment demandé est une référence de fragment, alors on appelle la procédure
GetMicrostructures en lui passant en paramètre l'identifiant dudit fragment référencé ainsi que tous ses fragments descendants qui sont dans le même contexte et dont on veut obtenir les microstructures (on passe un paramètre un tableau, dont le premier élément est l'identifiant du fragment que l'on veut recomposer, et dont les éléments suivants sont les fragments descendants acceptés non frais).
Au retour (on se trouve dans GefFragment):
On crée une copie du fragment recomposé partiellement, pour le cache. Dans cette copie, pour tous les fragments descendants qui sont acceptés dans le fragment courant, s'ils ont été reconstitués (cela veut dire que le cache n'était pas àjour), alors on met àjour le cache pour ce sous-fragment non àjour, et on met un attribut mix lipped pour ce sous-fragment non àjour dans la copie du fragment recomposé partiellement. Une fois cela fait pour tous les fragments descendants, on peut alors mettre àjour le cache du fragment que l'on recompose.
Pour chaque nœud ayant un attribut mix:content-clipped, on recompose en interne leur contenu s'ils ne sont pas en mode refusé.
On fait ensuite une comparaison de la macro-structure du fragment et du fragment recomposé retourné.
Dans la macro-structure pour tous les fragments qui sont dans le fragment recomposé, on met à jour les attributs de chaque fragment.
Dans la macro-structure pour tous les fragments qui ne sont pas dans le fragment recomposé, on appelle GefFragment sur chacun de ces fragments.
GetMicrostructures
A l'appel :
Une nouvelle Liste+ (liste des fragments sollicités) est créée à chaque fois pour être passée en argument. Les mix:fragment-id que cette liste contient sont ceux du contexte qui reçoit l'appel. Ce sont en fait des fragments acceptés dont la copie cache n'est pas fraîche.
A la réception :
Retourne les microstructures qui sont passés dans la Liste+.
Tous les fragments sollicités dans la Liste+ ont un «last-updated ». Si le fragment en question a été mis àjour depuis le temps donné dans la valeur de cet attribut, on le recompose, sinon on est implicitement dans le cas des fragments non sollicités, et on retourne <mix:clipped mix:fragment-id=" ... "/>
Après retour :
On recompose le document à partir d'une part de la macro-structure du fragment, d'autre part, grâce à la liste de microstructures retournée.
Possibilité de créer des cycles
Il est permis pour l'utilisateur d'importer un fragment causant la création d'un cycle. Un cycle a lieu quand un sous-fragment inclus dans un fragment consiste en une référence sur ledit fragment ou sur un ancêtre à lui. Ce phénomène peut être « sournois » (difficile à prévoir) dans la mesure où le cycle peut être « long » et inclure des références à des fragments répartis dans plusieurs documents par exemple.
Lors de la reconstitution (assemblage) du document à présenter à l'utilisateur, dans ce document on n'incluera pas de sous-fragment en mode suggéré qui débuterait un cycle (car le système partirait sinon en boucle infinie). On incluera par contre tous les sous-fragments acceptés ou gelé, même s'ils représentent le début d'un cycle. En effet, ceux-ci ne présentent aucun risque de boucle infinie, puisqu'ils sont assemblés à partir de la macrostructure qui est une structure de base et non pas une structure dérivée comme les fragments suggérés.
Fonctions usuelles
Au niveau de l'interface de manipulation, on pourrait offrir à l'utilisateur diverses fonctions parmi les suivantes qui notamment pourront être effectuées par un glisser-déposer :
1. Créer une référence à un autre fragment (on appelera cela « dériver »)
2. Copier un fragment (si le fragment à copier est en mode suggéré, il devra d'abord passer en mode accepté)
3. Déplacer un fragment
La première de ces fonctions consiste à importer un fragment comme déjà décrit plus haut. La deuxième fonction consiste à copier une référence à fragment (ou à microstructure le cas échéant) et ensuite lui assigner le mode gelé.
La troisième fonction consiste à copier une référence à fragment (ou à microstructure le cas échéant) à la destination indiquée et la supprimer ensuite à l'origine.
Quelques variantes
1) D'autres structurations sont permises. Par exemple, les mix:micr-ref (ou mix:fragment-ref) peuvent être des attributs dans le nœud mix:fragment, au lieu d'être des nœuds séparés. Au lieu de
<mix:macrostructure mix: last-fragment-id=" 5 "> <mix:fragment mix:fragment-id="l" mix:autorizations="private"> <mix:micr-ref mix:micr-id="l"> on pourrait avoir <mix:macrostructure mix: last-fragment-id=" 5 "> <mix:fragment mix:fragment-id="l" mix:autorizations="private" mix:micr-id="l">
2) Les microstructures peuvent résider dans la macrostructure au lieu d'être déportées dans un élément « mix:microsrtuctures », mais leur forme reste pareille : elles sont dépouvues des nœuds enfants sous les récipients qu'elles contiennent.
3) Au lieu de feuilles de style (par exemple en XSLT) d'autres types de traitement peuvent être appliqués sur les fragments avant présentation à l'utilisateur. 4) Les suggestions peuvent aussi se faire vers l'amont. Le « canal de communiction » peut être bidirectionnel.
5) Les microstructures et les éléments du cache peuvent avantageusement résider dans des BD (gérés par des SGBD).
6) Archivage de versions dans la macrostructure:
Deux compteurs sont introduits: mix:derivation-count et mixxached-count.
Reprenons l'exemple présenté à la section « Macrostructure & Microstructure » et traitons maintenant l'archivage de versions dans la macrostructure. Après l'insertion de l'article du deuxième document, le noeud fragment qui représente le document est remplacé par une nouvelle version (voir « DOCUMENT 2e version » mentionné entre paranthèses), comme présenté ci-dessous.
< ?xml version= "1.0" encoding="iso-8859-l" ?>
<mix:context xmlns:mix="urn:x-schema:x-files/mix-system-schema.xdr">
<mix:macrostructure mix: last-fragment-id=" 5 "> <mix:fragment mix:fragment-id="l" mix:autorizations="private"> (DOCUMENT) <mix:versions>
<mix:micr-ref mix:version="l" mix:micr-id="l" mix:derivation-count="..."10>
(DOCUMENT lère version)
</mix:micr-ref>
<mix:micr-ref mix:version="2" mix:micr-id="l"> (DOCUMENT 2e version) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="2" mix:autorizations="public"> <mix:versions>
<mix:micr-ref mix:version="l" mix:micr-id=" 2 "> (1er ARTICLE) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="3" mix:autorizations="private"> <mix:versions>
<mix:micr-ref mix:version="l" mix:micr-id=" 3 "> (1er CONTENU) </mix:micr-ref </mix:versions> </mix:fragment>
<mix:fragment mix:fragment-id="4" mix:autorizations="private"> <mix:versions>
<mix:micr-ref mix:version="l" mix:micr-id="4"> (2e CONTENU) </mix:micr-ref> </mix:versions> </mix:fragment> </mix:recipient> </mix:micr-ref> </mix:versions> </mix:fragment>
<mix:fragment mix:fragment-id="5" mix:autorizations="public"> <mix:versions>
Chaque version d'un fragment peut avantageusement être muni d'un attribut « derivation-count » qui est un compteur des références qui pointe sur elle. Dans le cas où cet attribut a la valeur zéro pour la première version du fragment DOCUMENT, celle-ci peut directement être supprimée, où passer en mode archivage. <mix: fragment-ref mix:version="l" mix: src=" http:// domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=2" > (2e ARTICLE) <mix:recipient mix:recipient-id=" 1 "> <mix:fragment mix:fragment-id="6" mix:autorizations="private"> <mix:versions>
<mix:fragment-ref mix:version="l" mix:src=" http ://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentld=3"> (1er CONTENU) </mix:fragment-ref> </mix:versions> </mix:fragment>
<mix:fragment mix:fragment-id="7" mix:autorizations="private"> <mix:versions>
<mix: fragment-ref mix:version="l" mix:src=" http://domaineX serviceY/GetFragment?context=/pathZ/doc2.xml &fragmentld=4"> (2e CONTENU) </mix:fragment-ref> </mix:versions> </mix:fragment> </mix:recipient> </mix:fragment-ref > </mix:versions> <fmix: fragment> </mix:recipient> </mix:micr-ref> </mix:versions> </mix: fragment > </mix:macrostructure>
Un fragment en mode gelé consiste maintenant en une référence sur une version déterminée d'un fragment à l'amont. Ainsi si par exemple on veut insérer dans un autre contexte (à l'aval) la première version du document (rappelée ci-dessous)
<mix:fragment mix:fragment-id="l" mix:autorizations="private"> (DOCUMENT)
<mix:versions>
<mix:micr-ref mix:version=="l" mix:micr-id="l" mix:derivation-count="..."> (DOCUMENT lère version)
dans le contexte à l'aval on doit spécifier cette version explicitement dans l'attribut src (mix:src= "cheminl/ docl.xml?fragment-id=l&version-id=l") ; noter que spécifier l'attribut mode gelé (mix:mode- 'frozen") est alors redondant et peut être omis :
<mix:fragment-ref mix: version- ' ..." mix:src=" http://domaineX/serviceY/GetFragment?context=/pathZ/doc2.xml&fragmentId=l&version =1" mix:mode="frozen"> (DOCUMENT lère version)
L'attribut mix:derivation-count="..." de la version 1 du fragment à l'amont (qui est le compteur des références sur soi) est alors incrémenté. Ceci a pour conséquence que cette dernière ne pourra pas être réellement supprimée avant que la référence (à l'aval) que l'on vient d'insérer ne soit supprimée.
Catégorisation automatique et suggestions
Objectifs premiers
Comme déjà mentionné à la section « Introduction à la ré-utilisation de fragments » l'acte de réutiliser11 (ou importer), qui consiste à reprendre une information pour la placer dans un nouveau contexte après adaptation éventuelle (par exemple, après adaptation automatique par la « feuille de style » du nouveau contexte), revient implicitement à déclarer qu'elle est pertinente dans ce nouveau contexte.
Le système informatique utilisé peut alors créer automatiquement une relation de pertinence entre l'information reprise et son nouveau contexte (voir la figure Fig. 2). On peut alors exploiter les relations ainsi créées pour catégoriser automatiquement les informations ré-utilisées (les catégories pouvant même émerger automatiquement) et alimenter ainsi un nouveau type de moteur de recherche : un moteur de suggestion.
Le principe d'un moteur de suggestion est le suivant: l'utilisateur fournit au système les identifiants d'un certain nombre d'informations qui l'ont intéressé (notamment les informations qu'il ré-utilise dans un contexte donné ; un répertoire de ses bookmarks par exemple) et, grâce aux catégories créées automatiquement, le système lui retourne d'autres informations qui potentiellement l'intéresseront également (en les insérant dans ce contexte ; son répertoire de bookmarks par exemple). Les informations qui l'ont intéressé, et qu'il fournit en entrée du système, forment ce que nous appelons une « requête implicite »
Ainsi, les fragments acceptés (ou gelés) se trouvant dans un nœud récipient peuvent être considérés comme formant une requête implicite adressée au système. Le système, que l'on va maintenant décrire, suggère automatiquement à l'utilisateur de nouveaux fragments dans ce récipient. Les nouveaux fragments suggérés sont thématiquement proches desdits fragments acceptés et sont intéressant pour l'utilisateur, du moins autant que l'étaient lesdits fragments acceptés (qui constituaient la requête implicite).
Le système de catégorisation automatique sert par ailleurs à filtrer les fragments en mode suggéré qui sont transmis de l'amont à l'aval12 selon le procédé décrit jusqu'ici (voir la section « Modes Suggéré, Accepté, Gelé, Refusé »).
De façon à pouvoir profiter du travail déjà effectué, le système va stocker des ensembles de fragments proches les uns des autres -ce sont des « catégories »- qu'il pourra réutiliser pour traiter des requêtes implicites futures. Une catégorie est un ensemble de fragments centrées autour d'un même thème. Pour pouvoir répondre à une requête implicite, comme l'illustre schématiquement la figure Fig.22, le système va :
• Déterminer les catégories de la requête implicite
• Renvoyer les fragments bien représentés dans les catégories de chaque fragment de la requête implicite et les présenter en mode suggéré dans le récipient qui avait servi de requête implicite.
La section « Tyes de ré-utilisations » présente différents cas de ré-utilisation. 1 (et de l'aval vers l'amont, en variante) Le cœur du système est donc une catégorisation automatique et incrémentale des fragments, capable de :
• Déterminer dans quelle mesure deux fragments sont proches ;
• Quand un fragment doit entrer ou sortir d'une catégorie ;
• Il peut décider quand créer ou supprimer une catégorie ;
• Et finalement, il construit une hiérarchie pour ces catégories, de façon à pouvoir cibler la requête plus précisément.
Pour effectuer ces décisions, notamment pour déterminer dans quelle mesure deux fragments sont proches, le système est basé sur une analyse automatique des références se trouvant dans les contextes. Les pages de la Toile (le Web) sont également analysées et permettent d'initialiser le système avec des « catégories universelles ».
Ainsi, au démarrage d'un processus de catégorisation dans un nouveau domaine d'intérêt (représenté par une nouvelle requête implicite), le système crée des catégories universelles (elles émergent automatiquement) en analysant finement les liens hypertextes se trouvant dans les pages du Web. Ces dernières sont obtenus en arpentant le web en amont puis en aval autour des pages indiquées dans la requête implicite : l'ensemble des pages analysées inclut toutes les pages qui sont pointées par les pages dans lesquelles est inclus un lien hypertexte pointant sur au moins une des pages de la requête implicite.
Les pages du Web sont assimilées à des contextes et les liens hypertextes (pointant en général sur d'autres pages Web) qu'elles contiennent sont assimilés à des références sur des fragments.
En justification des équations de calcul de proximité (que l'on va présenter en détail à la section « Quantité de raisons communes entre pages ou fragments »), les contextes (ou les pages du Web) sont assimilés à des « utilisateurs » 3 (que sont les auteurs des contextes ou pages web) qui sont intéressés par les « raisons d'aimer » offertes par les fragments (ou pages) qui y sont importés (liées).
Intuitivement, si beaucoup d'utilisateurs aiment certains fragments en commun, il est probable que ces fragments soient intéressants pour de mêmes raisons. On dit alors qu'ils présentent les mêmes raisons d'aimer et qu'ils sont donc proches. Ainsi, dans le cas du Web par exemple, si beaucoup de pages ont des liens hypertextes sur des mêmes pages, ces dernières sont probablement proches. Cette technique, qui sera élaborée en détail dans la section « Quantité de raisons communes entre fragments », peut par exemple permettre de découvrir (avec plus de précision que d'autres méthodes14) les sites des concurrents d'une entreprise à partir du site web de cette dernière, ou découvrir les entreprises ou organisations du même secteur.
Quand un fragment est extrait d'une page du Web (voir plus haut la section « Références sur des nœuds externes ») pourvue d'une catégorie, il peut hériter de la catégorie de cette page. Les catégories universelles qui émergent en analysant le Web sont ainsi « innoculées » dans les contextes quand on y insère des fragments de pages du Web. En effet, ces catégories se propagent ensuite d'un fragment à l'autre, d'un contexte à l'autre, puisque quand un fragment se retrouve beaucoup de fois avec d'autres fragments dans des contextes différents, le système détecte sa proximité avec ces autres fragments et il finit par entrer dans leur catégorie commune le cas échéant ou sinon une nouvelle catégorie est créée.
13 (appelles aussi « contenus routeur »)
14 Une méthode pour filtrer les sites, que l'on peut expérimenter sur un moteur de recherche, consiste à utiliser l'instruction « link:www.site,.com AND link:www.sitej.com » (pour connaître les pages qui pointent sur un couple de sites : site, et sitβj). On peut sophistiquer la requête pour éviter les liens internes aux sites. Les couples de sites concurrents (ou de même secteur) sont parmi ceux qui retournent le plus de réponses. A noter que sans le procédé d'analyse du Web et d'innoculation décrit ci-dessus, il aurait fallu dès le départ beaucoup d'utilisateurs réels du système pour que la catégorisation automatique des fragments dans les contextes (sans prendre en compte les pages du Web) fonctionne.
En revanche, l'analyse des liens du Web ne donne pas de bons résultats pour les sites trop confidentiels dont très peu de gens parlent sur Internet. Dans le futur, l'exploitation d'une base répartie de fragments dans des contextes pourrait contribuer à résoudre ce problème lorsque le nombre d'utilisateurs du système sera suffisamment important, car il y aura plus de producteurs de contextes non publics contenant des fragments (ne serait-ce que les « bookmarks » !) que de producteurs de pages web publiées sur l'Internet.
Avant que l'on ne décrive les procédés de calcul de proximité et de catégorisation automatique, la section suivante « Propagation des catégories grâce aux ré-utilisations de fragments » décrit les procédés et les dispositifs avantageant la propagation des catégories (). L'une des techniques est celle des « liens inverses » (ou références inverses). Bien que les liens hypertextes soient assymmétriques par nature, à chaque création d'un lien, le système propose automatiquement un lien inverse en mode suggéré ; les liens deviennent ainsi « bidirectionnels ». Quand un utilisateur crée un lien (référence) vers une page P2 dans sa version personnelle d'une page PI (c'est en quelque sorte un bookmark contextuel), chaque fois qu'il ira visiter P2 il verra un lien vers PI (à moins qu'il ne le refuse expressément). Et (s'il ne le refuse pas) on pense alors qu'il aime PI dans le contexte de P2 (et on en tient compte dans les calculs de catégorisation). Le fait d'ajouter un nouveau contexte (utilisateur) à une page augmente pour celle-ci les chances de rentrer dans les catégories des autres pages qu'aime cet utilisateur (voir « Quantité de raisons communes entre fragments »).
Enfin, le système de catégorisation automatique est avantageusement mis en œuvre de manière décentralisée, ce qui signifie que la puissance de calcul et le stockage sont répartis sur un certain nombre de machines, qui peuvent communiquer entre eux via un réseau (Internet), et d'autre part que toutes les machines sont au même niveau (selon le principe d'architecture en « peer-to- peeer » en terminologie anglo-saxone). En « peer-to-peer » chaque utilisateur peut contribuer au système les catégorisations de fragments résultant de ses ré-utilisations privées. De plus, en « peer-to-peer », le nombre de ressources à disposition est lié au nombre d'utilisateurs, puisqu'en principe chacun contribue en offrant des ressources de son ordinateur. Comme chaque utilisateur ne peut s'intéresser qu'à un nombre restreint de domaines, il y a dans le système global d'autant plus d'utilisateurs, et donc de ressources, que de domaines d'intérêt différents à couvrir. Or, justement, les besoins en ressources sont liés au volume des domaines à couvrir.
Propagation des catégories grâce aux ré-utilisations de fragments
Propagation par personnalisation
Un avantage, essentiel tant pour l'utilisateur-internaute que pour le propriétaire de la page Web, est de pouvoir personnaliser la page Web automatiquement lors de son accès par l'utilisateur.
Les catégories des nouvelles informations qu'un utilisateur place (importe) dans sa version personnelle d'une page, caractérisent l'utilisateur par rapport à cette page. Ces catégories peuvent être automatiquement transmises au serveur de la page en question, en même temps que la requête de l'utilisateur. Le serveur peut alors directement adapter le contenu de la page avant de la transmettre à l'utilisateur. (Noter que seuls les catégories doivent être transmises, non pas les informations importées dans la page).
15 La section « Tyes de ré-utilisations » présente différents cas de ré-utilisation. Par exemple, si un utilisateur aime la musique flamengo, cette catégorie étant associée à un des liens ajoutés (décrits plus loin à la « section « Liens ajoutés & Liens ajoutés inverses ») de sa version personnelle d'une page Web présentant un catalogue de guitares, quand il accédera à nouveau à cette page, le serveur choisira en priorité une guitare espagnole à lui présenter en priorité, ladite catégorie étant également associée à ce produit.
Schématiquement, le procédé est le suivant :
1. l'utilisateur accède à une page Web.
2. Il en crée une version personnelle (contexte).
3. Il y place des informations (liens ajoutés, références à fragments, annotations, etc).
4. Quand il veut accéder à nouveau à la même page Web, les catégories de ces informations sont automatiquement (s'il est d'accord) communiqués au serveur Web.
5. Ce dernier adapte (personnalise) la page demandée avant de la fournir à l'utilisateur.
Les liens ajoutés, références à fragments et autres informations associés à la version personnelle d'une page sont stockés dans un serveur. Deux modes de fonctionnement peuvent être envisagés. Ceux-ci sont illustrés schématiquement dans les deux figures Fig.23 et Fig.24.
Selon le premier mode de fonctionnement illustré sur la figure Fig.23, le poste client retrouve tout d'abord les informations liées à la version personnelle de la page Web demandée. Il demande ensuite cette page Web (au serveur qui la possède), en communiquant en même temps les catégories des liens ajoutés (et des autres informations) qui se trouvent dans la version personnelle.
Dans le deuxième mode de fonctionnement illustré sur la figure Fig. 24, la requête de l'utilisateur est communiquée, par le poste client, uniquement au serveur de la version personnelle. Ce dernier se charge de re-transmettre la requête au serveur de la page Web demandée, après lui avoir ajouté les catégories. Le retour se fait via le serveur de la version personnelle.
Ainsi, les fragments pertinents retournés par le serveur seront intégrés dans les contextes de l'utilisateur, et leurs catégories se propageront éventuellement vers d'autres fragments de ses contextes.
On va maintenant décrire un procédé particulier et qui peut être utilisé de manière séparée. Ce procédé concerne la gestion des catégories de fragment et permet de tirer parti de manipulations de fragments faites par des utilisateurs dans des structures de documents aptes a recevoir de tels fragments dans des contenants (récipients) possédant eux-mêmes des informations de catégorie.
L'invention propose à cet effet un procédé pour affecter des catégories à des contenus accessibles par une pluralité d'utilisateurs, chaque contenu étant par ailleurs propre a être sélectivement placé dans une pluralité de contenants appartenant à des structures de documents, ces contenants possédant chacun des informations de catégorie, et à chaque contenu pouvant être associé une pluralité d'informations de catégories permettant aux utilisateurs notamment de sélectivement accéder par un critère de catégorie audit contenu ou d'automatiser la sélection de la présentation dudit contenu, comprenant l'étape consistant, lorsqu'un contenu donné est placé dans un contenant donné d'un document, à ajouter aux informations de catégorie déjà associées audit fragment les informations de catégorie possédées par ledit contenant donné. Lesdites informations de catégorie ajoutées aux fragments peuvent être ajoutées en mode suggéré.
Autrement dit, un fragment accepté par l'utilisateur dans un contenant adopte la catégorie de ce contenant, en plus des catégories des autres contenants dans lesquels l'utilisateur a aussi accepté ce fragment le cas échéant. Dans la mesure où le système connaît les catégories des contenants imbriqués dans un fragment qui fait l'objet d'une requête, il peut automatiquement enrichir la requête par des critères supplémentaires. En effet, le système est capable de déterminer que, pour un certain nombre de fragments de chacune desdites catégories, il existe d'autres catégories qui ont été attribuées par l'utilisateur à ces mêmes fragments. Le principe utilisé ici est d'exploiter ces autres catégories en les utilisant en tant que critères supplémentaires (ou plus exactement en tant que « préférences ») pour enrichir automatiquement la requête formée par l'utilisateur.
Par exemple, dans un fragment qui fait l'objet d'une requête, se trouve imbriqué un contenant de catégorie « guitare», et chez l'utilisateur, un certain nombre de fragments de cette catégorie possèdent également la catégorie « objet d'art ». On exploite donc le fait qu'a priori, dans ce contenant, l'utilisateur préférera recevoir (par le processus de suggestion décrit par ailleurs) des fragments qui possèdent non seulement la catégorie « guitares », mais également la catégorie « objets d'art ». Ainsi, pour le contenant de catégorie « guitare », la requête de l'utilisateur peut être enrichie par le critère supplémentaire : catégorie = « objet d'art ». On observera ici que, s'il n'existe aucun fragment appartenant à ces deux catégories simultanément, le système propose alors à l'utilisateur les fragments appartenant simplement à la catégorie « guitares ». Le critère supplémentaire sera ainsi pris en compte comme étant une « préférence ».
On comprend donc que les fragments sont sélectionnés par le système de manière « personnalisée », c'est-à-dire en tenant compte des centres d'intérêts potentiels de l'utilisateur pour les contenants en question.
Par ailleurs, les catégorisations effectuées par les utilisateurs peuvent « remonter » vers l'administrateur d'un site en tant que suggestions de catégorisation pour les fragments en question, de manière à modifier la structure XML de la page considérée si l'administrateur le juge opportun.
Créer des références inverses
Quand un utilisateur ré-utilise (importe) une information (un fragment), non seulement une relation de pertinence est créée vers l'information ré-utilisée (comme mentionné plus haut), mais, de plus, un lien inverse (et implicitement une relation de pertinence inverse), à partir de l'information ré-utilisée vers le contexte dans lequel elle est ré-utilisée, peut être créé pour cet utilisateur. L'utilisateur peut bien sûr supprimer ce lien inverse, si, cas exceptionnel16, il n'est pas pertinent.
La figure Fig. 25 illustre schématiquement le fait que l'utilisateur retrouve le lien inverse à chaque visite de la page vers laquelle pointe un lien ajouté, quel que soit le moment et les circonstances de cette visite. De plus (ceci est illustré entre crochets), quand un lien hypertexte (classique) figure dans une page (PI), ce lien est considéré comme équivalent à un lien ajouté quand il est reproduit dans la version personnelle (PI'), un lien inverse est donc aussi créé.
Les liens ajoutés étant ainsi « bidirectionnels » (selon la description ci-dessus), le propriétaire d'une page où l'on peut placer des liens ajoutés (dans une version personnelle de la page), bénéficie du fait que le visiteur qui ajoute un lien vers une autre page est incité à revenir visiter sa propre page chaque fois qu'il va visiter l'autre page. Le visiteur est « fidélisé ».
De plus, les liens hypertextes (classiques) figurant dans la page d'origine se transforment aussi, par défaut, en liens bidirectionnels dans la version personnelle du visiteur, dans la mesure où ce dernier ne les supprime pas. Le propriétaire de la page d'origine profite ainsi de l'audience dés pages pointées par ces liens. En effet, à chaque accès à chacune de ces pages pointées, le visiteur
16 En général, quand une information est intéressante par rapport à une autre information, l'inverse est aussi le cas dans une certaine mesure. sera incité à revisiter la page d'origine. Les liens ajoutés et les liens ajoutés inverses sont décrits plus loin à la section « Liens ajoutés & Liens ajoutés inverses ».
Propagation par liens inverses
Si le lien inverse n'est alors pas supprimé, la catégorisation se propage dans les deux sens : non seulement l'information ré-utilisée augmente ses chances d'entrer dans les catégories des fragments de la page qui l'accueille, mais aussi cette dernière augmente ses chances d'entrer dans les catégories de l'information ré-utilisée ; et c'est évidemment cette deuxième direction qui intéresse particulièrement le propriétaire de la page qui accueille.
Dans le cas où le propriétaire d'une page Web (page d'origine) permet à ses visiteurs d'emprunter cette page pour en faire une version personnelle, quand un visiteur y place un lien ajouté, en général le propriétaire de la page d'origine augmente ses chances de la faire connaître par d'autres internautes intéressés par les catégories du lien ajouté. C'est une manière de faire « référencer »17 sa page, dans le moteur de suggestion, par les visiteurs de la page eux-mêmes. Il peut ainsi augmenter son audience.
Même les ré-utilisations faites par le propriétaire de la page (par exemple les liens hypertextes classiques insérés dans la page) voient en général leurs effets démultipliés par les visiteurs qui ne les suppriment pas dans leur version personnelle de la page. Pour cette raison, l'auteur d'une nouvelle page (non encore catégorisée) a intérêt à y insérer des liens hypertextes vers des pages déjà catégorisées et qui intéresseront les visiteurs de la nouvelle page (le choix de ces liens peut être déterminé automatiquement grâce à la personnalisation). En effet, dans la mesure où ces liens ne seront pas supprimés dans leurs versions personnelles, comme ils sont bidirectionnels, ils serviront à propager ces catégories vers la nouvelle page.
Types de ré-utilisations (ou importations)
Les liens hypertextes du Web
On assimile un lien hypertexte à une importation de fragment. Par nature un lien hypertexte dans une page Web représente une relation as pertinence déclarée implicitement par l'auteur de cette page. Ceci est illustré en figure Fig. 26. Avantageusement, nous avons donc tout le Web comme premier corpus pour alimenter le système de catégorisation automatique (et le moteur de suggestion) avant même qu'il n'y ait des utilisateurs proprement dit du système d'importation de fragments !
Cette relation de pertinence peut se faire avec le contexte précis dans lequel le lien hypertexte a été placé. Par exemple, le contexte sera une région limitée de la page contenant le lien hypertexte.
Les liens personnels
Bookmarks (Liens favoris, signets)
Quand un internaute mémorise un lien en tant que « bookmark » (ou « favori ») au moyen de son navigateur, il déclare implicitement qu'il s'intéresse à la page pointée par ce lien. Le système peut alors créer une relation de pertinence entre l'utilisateur et cette page. Ceci est illustré à la figure Fig. 27.
Cette relation peut se faire avec le contexte précis dans lequel le bookmark a été placé. Par exemple, le contexte sera le chemin au répertoire particulier de bookmarks dans lequel il a été mis.
17 (au sens du référencement dans un annuaire du Web) Les « scrapbooks » sont équivalents aux bookmarks à ceci près qu'ils utilisent des copies de pages Web plutôt que des liens sur elles ; ce sont des « albums » dans lesquels des pages du Web sont mémorisées. Les scrapbooks peuvent ainsi être exploitées dans la même approche : une relation de pertinence peut être créée entre la source de la page mémorisée et le contexte (le plus précis possible) dans lequel il a été placé.
Navigation
Une autre application est d'associer une page intéressante avec un ensemble d'autres pages intéressantes accédées fréquemment dans une même navigation. L'ensemble des autres pages intéressantes est appelé « contexte navigationnel ». Ceci est illustré en figure Fig. 28.
Chaque accès à une page intéressante (par exemple : à une page accédée fréquemment ou manipulée longuement) est mémorisé et le système lui associe sa position dans la séquence de navigation de l'utilisateur. Quand la même page est accédée à nouveau, le système identifie, parmi les pages intéressantes les plus proches dans les séquences de navigation, celles qui ont été accédées dans la même navigation, et incrémenté leurs proximités contextuelles avec la première page. Les pages intéressantes se trouvant dans un même contexte navigationnel sont ainsi identifiées et le contexte navigationnel émerge lui-même automatiquement. Des relations de pertinence sont alors créées entre les pages et leurs contextes navigationnels.
Liens ajoutés
Ce sont des liens sur des pages intéressantes non pas dans l'absolu (comme dans le cas des bookmarks classiques) mais par rapport à une autre page visitée. L'utilisateur a alors l'avantage de les retrouver automatiquement lors des visites ultérieures sur ladite autre page18. Une relation de pertinence est alors créée entre la page pointée par le lien ajouté et la page à laquelle le lien ajouté est associé. Ceci est illustré schématiquement à la figure Fig. 29.
Pour associer un lien ajouté à une page, l'utilisateur crée une « version personnelle » de celle-ci. Les liens ajoutés sont ainsi des bookmarks que l'utilisateur associe directement à sa version personnelle d'une page qu'il visite.
Fragments de sources XML de page affichée
Plutôt que de collectionner des bookmarks, l'utilisateur peut aussi regrouper, dans une même page Web (s'il a le droit de la manipuler ; par exemple au sein d'une version personnelle d'une page Web), des fragments des ressources auxquelles il accède. Les fragments ainsi assemblés sont présentés après application d'une feuille de style (notamment en XSLT) ou d'une composition de plusieurs feuilles de style. Au niveau du stockage, ils sont matérialisés par des références aux fragments d'origine. Ce procédé a largement été décrit dans la première moitié du présent rapport.
Par exemple, un webmaster peut ainsi composer la page d'accueil de son site par de simples glisser-déposer de fragments. Comme les fragments importés sont des références aux fragments d'origine, les mises-à-jour se répercutent automatiquement.
Une relation de pertinence est alors créée automatiquement entre un fragment d'origine (au sein de Pagel dans la figure Fig. 30) et la page dans laquelle il est importé (Page 2).
Liens ajoutés & Liens ajoutés inverses
L'utilisateur de créer des liens (que nous appelons Liens Ajoutés) entre des pages qu'il découvre au gré de sa navigation, notamment sur l'Internet.
18 De plus, les bookmarks classiques, figurant dans un répertoire de bookmarks dans lequel la page courante visitée se trouve, lui sont aussi présentés automatiquement lors de la visite de ladite page courante. Chaque utilisateur ajoute ainsi ses propres liens dans la masse d'informations disponible sur le Web. (La figure Fig. 31 illustre ce concept.) Tout en navigant, il met en place de nouveaux liens qui l'aideront dans sa navigation dans le futur. Il navigue ainsi de manière « pro-active ».
Autrement dit, pour chaque utilisateur, l'ensemble des Liens Ajoutés (son « mini Web ») s'ajoute au Web auquel il avait déjà accès. En effet, le système s'installe entre le navigateur et les sites visités, et augmente pour chaque utilisateur le réseau des liens hypertextes qui sont à sa disposition pour naviguer. (La figure Fig. 32 illustre ce concept.)
L'utilisateur crée aussi des liens ajoutés quand il repère une relation en se déplaçant à l'intérieur de grandes pages ou des mondes virtuels en 3 dimensions (en réalité virtuelle immersive). Dans tous les cas, la création d'un Lien Ajouté peut se faire par simple glisser-déposer de la « poignée » de la page couramment visualisée (par exemple de la scène 3D couramment visualisée) vers la poignée de la page à relier (autre scène 3D).
La figure Fig. 33 illustre qu'en résultat d'un accès par l'utilisateur à une page pi, le Système lui présente automatiquement les Liens Ajoutés p2, p3 et p4 qu'il avait associé à la page pi au cours de navigations précédentes.
Le système est doté de moyens de stockage des Liens Ajoutés. Ces moyens permettent, à chaque accès à une page à laquelle des Liens Ajoutés ont été associés, de présenter ces derniers à l'utilisateur en supplément de ladite page.
Pour ce faire, comme l'illustre conceptuellement la figure Fig. 34, une indirection est établie vers le stockage des Liens Ajoutés, afin d'associer ces liens à cette page avant de la présenter à l'utilisateur.
Les Liens ajoutés par l'utilisateur, par glisser-déposer (ou manuellement en les tapant au clavier), sont stockés dans le système comme l'illustre schématiquement la figure Fig. 35 qui présente une table de relations entre pages associée à l'utilisateur courant.
Les Liens Ajoutés sur une page entraînent la création de Liens Ajoutés inverses sur les pages pointées par ces Liens Ajoutés. Ainsi, comme l'illustre la figure Fig. 36, en conséquence de la création des Liens Ajoutés de p2,p3 et p4 sur la page pi, un Lien Ajouté pi s'ajoute automatiquement sur les pages p2, p3 et p4.
Lorsque l'utilisateur active un lien dans une page PI vers une page P2 (voir la figure Fig. 37), les liens présentés à l'utilisateur en association avec P2, incluent tous les autres liens de la page PI (à savoir les liens P3 et P4, voir la figure Fig. 38).
Aux pages accédées par l'utilisateur en activant lesdits autres liens (P3 et P4) sont associés des liens ajoutés inverses pointant sur ladite page PI (en plus du lien inverse sur la page P2). C'est ce que la figure Fig. 39 illustre.
Autrement dit, à chaque page accédée par l'utilisateur, en activant un lien suggéré au niveau d'une page courante, sera associé le lien ajouté inverse pointant sur la page d'origine (et non seulement sur la page courante).
Groupes de liens proposés à l'utilisateur
Un premier utilisateur peut accéder, pour une page donnée, aux Liens Ajoutés chez un deuxième utilisateur. Ces Liens Ajoutés s'ajoutent alors à ceux qui, le cas échéant, avaient déjà été associés à cette même page chez le premier utilisateur. On va maintenant décrire la manière dont les liens d'un deuxième utilisateur sont sélectionné par le premier utilisateur pour y puiser des liens ajoutés. Pour chaque page à laquelle accède le premier utilisateur, trois listes de groupes de liens appartenant à des deuxièmes utilisateurs lui sont proposées, comme l'illustre la figure Fig. 40.
L'utilisateur peut sélectionner (par exemple en cliquant une case à cocher) un ou plusieurs éléments de ces listes pour indiquer qu'il souhaite ajouter leurs liens ajoutés dans sa propre liste de liens ajoutés. Les trois listes sont décrites ci-dessous :
1. le contenu de la première liste est optionnel : ce contenu existe dans le cas où l'auteur de la page en question est lui-même un utilisateur du système et a voulu suggérer des liens ajoutés au premier utilisateur ;
2. la deuxième liste (« voisins d'intérêt ») a pour objet de présenter au premier utilisateur les groupes ayant le plus de probabilité de contenir des liens ajoutés intéressants par rapport à son profil d'intérêts ; la liste de ces répertoires est déterminée automatiquement par le système en comparant les Miniweb des utilisateurs ;
3. la troisième liste (« copains ») contient des groupes choisis par le premier utilisateur (par exemple, des groupes appartenant aux miniwebs d'amis, collègues, experts, etc.).
Selon une variante, peut s'ajouter aux trois listes ci-dessus une quatrième liste des groupes appartenant au premier utilisateur.
Le nom ou pseudonyme du deuxième utilisateur qui est l'émetteur des liens ajoutés reçus par le premier utilisateur - ou du groupe contenant ces liens ajoutés (on notera ici qu'il peut également s'agir d'un autre groupe du premier utilisateur) - est présenté d'office en première position dans la troisième liste (« copains ») en mode actif (c'est-à-dire sélectionné) par défaut.
La troisième liste, peut avantageusement être basée sur :
- une « liste par défaut » donnée globalement par l'utilisateur pour toutes les pages ;
- et « surchargée » par les préférences fournies par l'utilisateur expressément pour la page en question.
Dans l'ensemble de liens ajoutés associés à la page qu'il est en train de visualiser, l'utilisateur reçoit les liens ajoutés supplémentaires puisés dans les groupes sélectionnés dans ces trois listes. On peut ainsi considérer que l'utilisateur « visite » ces groupes.
Des moyens pour sélectionner des liens ajoutés, sur la base de critères données par l'utilisateur ou associés à la page courante, peuvent être avantageusement mis en œuvre. Par exemple, l'utilisateur peut spécifier qu'il ne veut puiser dans les groupes cochés que des liens ajoutés sur des pages étiquettées :
- « Demandeur » plutôt que « Offreur », afin de découvrir de nouveaux clients plutôt que de nouveaux vendeurs,
- selon des critères concernant l'audience visée : « Age », « Zone Géographique », « Sexe », « Préférence » (parmi un ensemble fini de préférences),
- etc.
Les Liens Ajoutés qui lui sont ainsi suggérés doivent être distingués de ceux qu'il avait lui-même ajoutés, il peut en effet en refuser certains. Dans ce but, les Liens Ajoutés peuvent se trouver dans un parmi plusieurs modes différents: « Suggéré », « Accepté », « Refusé » et « Gelé », comme décrit plus haut.
Les Liens Ajoutés reçus par un premier utilisateur, à partir des Liens Ajoutés publiés par un deuxième utilisateur (ou à partir des Liens Ajoutés d'un des groupes du premier utilisateur), sont chez le premier utilisateur au départ en mode « Suggéré ».
Suite à une action de l'utilisateur, chaque Lien Ajouté en mode Suggéré peut passer à l'un parmi les autres modes. L'interface homme-machine permettant ceci est schématisé à la figure Fig. 41.
On va maintenant décrire un perfectionnement du système permettant à l'utilisateur d'associer aux liens qui l'ont intéressé des attributs, tels que le souhait d'achat ou de vente du produit représenté par l'information pointée (ou plus généralement des attributs de type « Offreur » et « Demandeur »). Ces attributs sont exploités par le système pour affiner la sélection de répertoires spécialistes et proches, et la mise en relation d'utilisateurs intéressés par de mêmes contenus et se trouvant dans une situation de complémentarité.
Lors de l'acceptation d'un lien, l'utilisateur a deux « cases à cocher » à sa disposition, à savoir :
« Demandeur » et « Offreur ».
Il cochera « Demandeur » s'il se positionne comme demandeur, et sur « Offreur » s'il se positionne comme « offreur », vis à vis de la « chose » présentée dans la page courante. On observera que ces deux possibilités ne sont pas exclusives : il peut se positionner à la fois comme demandeur et comme offreur.
Le système mémorise la valeur de ces deux attributs pour chaque référence (lien) dans les contextes (dans la toile personnelle -miniweb- de chaque utilisateur). Il peut ainsi en tenir compte dans le procédé de sélection des répertoires à proposer aux utilisateurs.
Pour actionner la sélection de répertoires proposés dans les deux premières listes (« spécialistes » et « voisins ») en fonction de ces deux attributs, l'utilisateur a deux autres cases à cocher
« Demandeur » et « Offreur » à sa disposition.
Ces deux autres cases à cocher sont cochées par défaut.
En décochant « Demandeur », l'utilisateur spécifie qu'il ne s'intéresse pas à visiter les répertoires positionnés comme demandeur en regard de la chose présentée dans la page courante.
De même, en décochant « Offreur », l'utilisateur précise qu'il ne souhaite pas recevoir de liens à partir de répertoires positionnés comme offreur en ce qui concerne la chose présentée dans la page courante.
Ces attributs peuvent avoir une interprétation plus large que celle concernant l'achat et la vente.
Par exemple, l'attribut Offreur peut être utilisé par l'utilisateur pour informer sur ses propres caractéristiques : l'utilisateur peut par exemple cocher l'attribut offreur sur une page présentant un acteur de cinéma qui lui ressemble, dans l'espoir de pouvoir se mettre en contact, au moyen du système (par exemple par vidéoconférence), avec une utilisatrice qui apprécie cet acteur tel qu'il est présenté dans ladite page.
Dans le cas d'une application d'achat groupé, le système proposera à l'utilisateur des voisins qui sont « Demandeurs » du produit présenté dans la page courante visualisée. L'utilisateur pourra alors interagir avec ces utilisateurs par des moyens assistés par ordinateur, en communication synchrone (messagerie instantanée, etc) ou asynchrone (forum et courrier électronique augmentés de moyens semi-automatiques spéciaux pour faciliter la coordination d'achat groupé, notamment pour négocier les prix avec les Offreurs).
Détails de la Détection de Répertoires Proches
Comme les utilisateurs peuvent placer des mêmes Liens Ajoutés dans des répertoires différents, le système peut servir à sélectionner des répertoires au lieu d'utilisateurs. Notamment, le système peut avantageusement servir à sélectionner des répertoires « proches » du premier utilisateur plusieurs répertoires d'un même deuxième utilisateur. Dans la suite, nous décrivons donc l'approche consistant à sélectionner des répertoires plutôt que des utilisateurs. La sélection des répertoires les plus proches peut se faire très efficacement grâce à une structure de données (tel qu'un fichier inversé) permettant de retrouver en accès direct les répertoires contenant une page donnée (la page courante de l'utilisateur) l'accès direct peut même se baser sur la page donnée et les Liens Ajoutés qui lui sont associées.
Les répertoires les plus proches, sélectionnés automatiquement, sont présentés à l'utilisateur dans la deuxième liste (intitulée « voisins d'intérêt ») illustrée de manière schématique dans la figure Fig. 40. Comme déjà décrit dans la section précédente (« Publication de Liens Ajoutés »), l'utilisateur peut cocher un ou plusieurs des répertoires qui lui sont proposés par le système. En résultat, de nouveaux Liens Ajoutés, puisés dans ce ou ces répertoires, lui sont suggérés sur (en association avec) la page courante (conformément à la description de la section précédente). Bien évidemment, l'on peut doter le système de paramètres déterminant dans quel ordre les Liens
Ajoutés suggérés seront présentés à l'utilisateur (par exemple, en fonction du prix payé par les clients pour les pages que ces Liens Ajoutés pointent).
Le système peut aussi offrir à l'utilisateur des moyens de tenter de se mettre en relation - par des moyens de communication sur Internet, tels que le « chat », la visio-conférence, etc - avec les utilisateurs possédant ces répertoires qui seraient en ligne en même temps.
On va maintenant décrire la méthode de calcul de proximité adaptée aux Liens Ajoutés.
En partant de la page courante (c'est-à-dire la page visualisée par le premier utilisateur) avec ses
Liens Ajoutés dans le répertoire courant - ou avec l'union des Liens Ajoutés associés à cette page dans les répertoires courants sélectionnés par l'utilisateur - le système trouve parmi les autres répertoires (du premier utilisateur et/ou parmi les répertoires publiés de seconds utilisateurs) contenant ladite page, ceux qui ont le score de proximité le plus élevé autour de ladite page.
En résultat, le système fournit à l'utilisateur ces répertoires dans l'ordre de leur proximité.
La proximité peut être calculée à différents niveaux.
Au premier niveau, la proximité est fonction du nombre de Liens Ajoutés communs associés à la page courante. La figure Fig. 42 illustre la détermination de la proximité au niveau 1.
Au niveau 2, la proximité est en plus fonction du nombre de Liens Ajoutés communs associés aux pages reliées à la page courante par Lien Ajouté. Ceci est illustré dans la figure Fig. 43.
Au niveau n, la proximité est égal à la proximité au niveau n-1, plus une fonction du nombre de Liens Ajoutés communs associés aux pages reliées indirectement à la page courante par Lien Ajouté, n étant le nombre d'étapes d'indirection.
Le système peut enrichir son évaluation de proximité en anticipant les propagations probables de Liens Ajoutés dans le futur. En effet, les Liens Ajoutés qui au moment courant ne sont pas encore propagés (suggérés) d'un répertoire proche à un autre, le seront probablement dans le futur, et, après acceptation éventuelle, seront prêts à être suggérés à un troisième répertoire (et ainsi de suite). Le système peut enrichir son estimation de proximité en anticipant ces propagations (suggestions) et acceptations, et en calculant la proximité d'un répertoire l'anticipation ayant été prise en compte.
On va maintenant introduire une méthode plus générale de détection de proximité, qui permettra de catégoriser les informations automatiquement.
Architecture générale du système de catégorisation automatique
Pour permettre la décentralisation, on va introduire la notion de serveur virtuel. Le mot
« serveur » sera utilisé dans la suite pour désigner un tel objet.
Un serveur peut stocker des informations, peut effectuer certaines tâches et deux serveurs peuvent échanger des informations sous forme de messages.
Nous avons à notre disposition un nombre non limité de serveurs.
Serveurs de fragment
Le système travaille sur un ensemble de contextes et de fragments. Généralisons un peu ces concepts : un fragment est un objet pouvant être référé (référencé), et un contexte est un objet pouvant créer des liens (ou références) vers des fragments. Chaque contexte est donc lié à un certain nombre de fragments (ses fragments), et chaque fragment est liée à un certain nombre de contextes (ses contextes).
En particulier, chaque page web peut jouer le rôle à la fois de contexte et de fragment. En effet, les liens hypertextes qui s'y trouvent vont être traités comme des références vers d'autres pages qui eux-mêmes vont être traités comme des fragments. Un serveur de fragment représente un fragment. Il connaît ses fragments (ceux qu'il référence) et ses contextes (qui sont d'autres serveurs de fragment), ainsi que ses catégories (des serveurs de catégories, introduits ci-après.)
Un serveur de fragment est capable de trouver et mettre àjour ses fragments et contextes. Il est également capable de trouver ses catégories, en collaboration avec d'autres serveurs (ce processus sera précisé plus tard), ce qui signifie que le traitement d'une requête implicite commencera par des demandes de listes des catégories à tous les serveurs de fragment dont il est question dans ladite requête implicite.
Serveurs d'exploration
Les serveurs d'exploration fournissent une interface entre les serveurs de fragment et les références (par exemple les URLs des pages). Ils permettent à un utilisateur d'envoyer un message à un serveur de fragment (en donnant par exemple l'URL du fragment) sans savoir où ce serveur se trouve.
Les serveurs d'exploration forment un réseau, et, à réception d'un message, chaque serveur d'exploration est capable de renvoyer le message en direction d'un autre serveur d'exploration plus proche du serveur de fragment recherché, de sorte qu'après un certain temps, le message parvient au serveur d'exploration connaissant le serveur de fragment, et puis au serveur de fragment lui-même.
Cette interface est également capable de créer un serveur de fragment s'il n'en existe pas pour l'URL demandé. Ceci est illustré en figure Fig. 44.
Serveurs de catégorie
A chaque catégorie est associé un serveur particulier, dont le rôle est d'une part de référencer l'ensemble des fragments que la catégorie associée contient, et d'autre part de recevoir des suggestions de fragments, qu'il peut ensuite accepter ou refuser.
De plus, étant donné que les catégories forment une hiérarchie, c'est aux serveurs de catégories de la construire et la maintenir àjour. Chaque catégorie va ainsi référencer un ensemble de surcatégories ainsi qu'un ensemble de sous-catégories (voir section « Fusion de catégories »).
Capacité des serveurs
En figure Fig. 45 est illustré une vue d'ensemble de l'architecture du système, avec les trois types de serveurs.
Comment trouver les contextes d'un fragment ?
Il y a deux moyens d'obtenir une liste de contextes pour un fragment donné, lorsque celui-ci est inconnu du système :
1) On utilise un moteur externe, qui donnera directement la liste cherchée (notamment s'il s'agit d'une page Web)
2) En suivant les liens en avant jusqu'à une certaine profondeur. Courte description de la deuxième méthode ( illustré en figure Fig. 46) :
Le message crawl(n) demande à un serveur de fragment de s'assurer qu'une profondeur de n fragment soit connue depuis lui.
Si un fragment (serveur de fragment) ne connaît pas ses contexte, elle va s'envoyer ce message.
Chaque fragment recevant un message crawl(n) va renvoyer crawl(n-l) à tous ses fragments.
Un serveur de fragment s'assure régulièrement que son ensemble de fragments n'a pas changé.
En cas de changement, il va informer les serveurs concernés (en disant à chacun soit qu'il a un nouveau contexte, soit qu'il en a perdu un.)
Ainsi, les serveurs n'ont en principe pas besoin de chercher leurs contextes plus d'une fois, car ils seront informés des changements futurs. Catégorisation
Première catégorisation d'un fragment
On va étudier ici ce qui se passe quand un serveur de fragment (P0) reçoit un message demandant sa liste de catégories alors que le fragment n'est pas du tout catégorisé. Notation : les fragments (ou page) sont notés P, les contextes (ou utilisateur) U et les catégories K.
Pour obtenir ces catégories, on va tout d'abord constituer l'ensemble de fragments avant au moins un contexte commun avec Pn. Puis on va faire en sorte que tous les fragments de cet ensemble soient catégorisés.
Tout d'abord, il s'agit d'envoyer à tous ces fragments (rappelons que par fragment, on entend serveur de fragment ; de même, par catégorie on entend serveur de catégorie) l'ensemble des catégories qui y existent déjà, de façon à ce que ces fragments se mettent àjour vis-à-vis de ces catégories. Ceci est schématisé à la figure Fig. 47a.
(1) Po va demander à tous ses contextes d'envoyer les catégories de leurs fragments au fragment initial.
(2) Les contexte vont donc (à réception du message) demander à leurs fragments d'envoyer leurs catégories au fragment initial.
(3) Comme réponse au message (2), le fragment va dire s'il a déjà reçu un message identique (en comparant la valeur de Po transmise), pour économiser du trafic aux étapes (3) et (6). En fait, il va accepter le premier message de ce genre, et répondre avec sa liste de catégories.
(4) Chaque contexte va fusionner les ensembles de catégories qu'il a reçus et les envoyer au fragment initial
(5) Maintenant, Po va fusionner tous les ensembles qu'il a reçus, et obtenir l'ensemble complet des catégories de ses fragments. Il va donc informer chaque fragment individuellement de cette liste de catégories. Il va donc la transmettre à ses contexte. (Car il ne connaît pas l'ensemble des fragments de ses contextes)
(6) Les contextes renvoient cette liste de catégories à leurs fragments qui avaient répondu « ok » dans le message (3). (Ce qui évitera qu'un même fragment reçoive cette liste à double)
Maintenant, on va travailler jusqu'à ce que chaque fragment de l'ensemble soit catégorisée. Cette opération est effectuée comme suit :
Le serveur P0 gère la liste des catégories ;
Et chaque serveur de fragment est responsable de se catégoriser. Autrement dit, quand une nouvelle catégorie est créée, elle est envoyée à tous les fragments (ceux qui participent à la catégorisation, i.e. ceux qui ont un contexte commun), qui vont ensuite se proposer à la catégorie.
Et ensuite, quand un contexte n'a pas réussi à se catégoriser, il va demander au serveur initial de créer une nouvelle catégorie. Ceci est illustré schématiquement à la figure Fig. 47b.
(7) Chaque fragment va demander aux catégories reçues s'il peut y entrer (voir plus loin section « Constitution des catégories »), et
(T) le serveur de fragment est tout de suite informé de la décision.
(8) Chaque fragment va dire au contexte (qui lui avait proposé une liste de catégories) s'il se considère bien ou pas bien catégorisé.
(9) Si le contexte reçoit des messages de fragments non encore catégorisés, il va choisir parmi eux ceux qui méritent le plus de créer une nouvelle catégorie, et envoyer son adresse au fragment initial. Cette décision est effectuée en considérant le meilleur score obtenu par le fragment pour une catégorie. Si tous les fragments dont le contexte est responsable sont bien catégorisés, il le disent au fragment initial. (10a) S'il reste des fragments non catégorisés, le fragment initial va en choisir un (parmi ceux qui avaient déjà été sélectionnés au point 9), et créer une nouvelle catégorie. Il va ensuite transmettre, via ses contextes, cette nouvelle catégorie à tous les fragments. Ensuite on reprend au point 7 avec cette nouvelle catégorie.
(10b) Si tous les contextes avaient répondu « c'est fini pour moi » au point (9), la catégorisation est terminée. Le fragment initial va demander à tous les serveurs de catégorie qu'il a créé de s'insérer dans la hiérarchie, de fusionner si nécessaire, et castera.
Parallélisation du procédé
Il est utile d'adapter l'algorithme de catégorisation décrit ci-dessus en tenant compte du fait que les serveurs sont regroupés en machines, et qu'il est possible de communiquer avec une machine. L'algorithme décrit ci-dessus utilisait un canal de communication entre le fragment initial et l'ensemble des fragments qui ont des contextes communs. Afin d'alléger l'effort fourni par le fragment initial, les contextes servaient d'intermédiaire. Nous allons changer ce point en utilisant non pas les serveurs de fragments contextes du fragment initial, mais les machines contenant les serveurs de fragments concernés. Le nombre de ces machines sera noté M. La figure Fig. 47c présente cette architecture.
D'autre part, comme une seule catégorie était créée pendant un cycle, et qu'un seul serveur de catégorie devait se confronter à toutes les pages (fragments) de l'ensemble, il n'était pratiquement pas effectué de calculs en parallèle. Ainsi, nous allons permettre de créer plusieurs catégories simultanément (autant qu'il y a de machines), et donc de faire plusieurs cycles en même temps.
Finalement, au lieu de demander à un serveur de catégorie de recevoir les listes d'utilisateurs de toutes les pages les unes après les autres, il serait plus raisonnable d'envoyer les pages du noyau de la catégorie à toutes les pages les unes après les autres.
Voici la nouvelle version de l'algorithme appliqué aux machines réelles :
(On suppose connaître l'ensemble des machines contenant les fragments ayant des contextes communs avec Po)
Avant de commencer l'algorithme complet, voici une marche à suivre pour confronter un ensemble d'au plus catégories avec tous les fragments (voir la figure Fig. 47d).
(1) Tout d'abord, on choisit une machine pour chaque catégorie, et on envoie chaque catégorie à sa machine.
(2) La machine va ensuite confronter chacun de ses fragments à ceux du noyau de la catégorie, et décider les changements à effectuer dans la catégorie.
(3) En réponse au message (1), les machines informent le fragment initial Po des changements à effectuer dans la catégorie.
(4) Une fois que toutes les réponses sont venues, on décale les correspondances des catégories (la catégorie envoyée à la machine Mu sera ensuite envoyée à la machine Mi si \<M, et à la machine Mo sinon), et on recommence au point (2).
On effectuera ces opérations (opérations 2à4) M fois, pour avoir confronté toutes les catégories avec toutes les machines.
L'algorithme de catégorisation fonctionne comme suit :
Nous avons une source de catégories, et un ensemble de fragments. Nous allons prendre M catégories à la fois de cette source, et les confronter avec tous les fragments en utilisant la procédure ci-dessus.
Nous nous arrêtons lorsque la source s'est tarie.
Cette source consiste en :
1. Les catégories déjà existantes dans l'ensemble 2. Les fragments non suffisamment catégorisés.
1. Pour obtenir la liste des catégories des fragments des contextes de Po (voir figure Fig.48) :
* Le fragment initial va demander à toutes les machines l'union des ensembles de catégories de leurs fragments.
* Chaque machine va demander sa liste de catégories existantes à chacun de ses fragments.
* Chaque machine fusionne alors toutes ses listes et renvoie le résultat au fragment initial.
* Le fragment initial va fusionner tous les ensembles obtenus.
2. Pour obtenir des fragments non suffisamment catégorisées, on demande aux machines, lors de la dernière passe (2)-(4) de la confrontation fragment-catégories, de donner un ensemble d'au plus M fragments mal catégorisés.
Ainsi, à la fin de cette confrontation, Po aura reçu des ensembles de fragments mal catégorisés, et pourra en choisir M.
Répartir les serveurs dans des machones
En regardant les algorithmes utilisés, on voit que les messages transitent toujours le long des même axes :
Pour les serveurs d'exploration, les messages transitent le long des arcs prédéfinis ;
Pour le crawl, les messages transitent d'utilisateur à fragments (liens hypertextes), et, pour les nouveaux fragments, du fragment à son serveur d'exploration.
Ci-dessous nous utilisons systématiquement le mot page au lieu de fragment.
Pour la catégorisation, il y a un grand trafic de messages entre utilisateurs et pages (de nouveau le long des liens hypertextes), et, à côté de ça, les mises àjour de liens entre pages et catégories, qui sont plus difficiles à prévoir au moment de la création !
Il faudrait donc favoriser le regroupement de serveurs de page liés, et celui de serveurs d'exploration liés. D'autre part, il semble naturel également de mettre un serveur d'exploration dans la même machine qu'une (ou plusieurs) de ses pages, dans la mesure du possible...
Maintenant, il faut tâcher de bien répartir les serveurs dans les machines, de façon à éviter qu'une machine se voie attribuer trop de tâches.
Création d'un serveur de page
Données : on a un ensemble de machines et de serveurs déjà existants, et une nouvelle page apparaît, avec un ensemble de pages et d'utilisateurs dont les serveurs de page sont connus.
Choisir la machine à laquelle attribuer la page.
Pour obtenir ces ensembles d'utilisateurs et de pages, il y a deux possibilités :
1) En passant par un moteur de recherche: on obtient facilement les listes d'urls des utilisateurs, en plus des pages, et on va chercher quels sont les serveurs de page déjà existants pour ces urls.
2) En utilisant le crawl décrit plus haut: En ce cas, le serveur de page attend la réponse de ses pages pour décider son adresse, car à cet instant les utilisateurs accessibles par crawl auront eu le temps de l'en informer
Il s'agit d'une part de favoriser le regroupement de serveurs liés (par des liens hyper-textes) et d'autre part d'éviter qu'il y ait des machines qui restent vides. Un ensemble de machines candidates pour accueillir le nouveau serveur est donc constitué, avec des machines contenant les serveurs des pages et des utilisateurs, et de quelques serveurs vides. (Voir figure Fig. 49)
1. Trouver les machines contenant les serveurs des pages liées, et le serveur d'exploration associé au nouveau serveur.
2. Obtenir un ensemble de machines vides par le répertoire associé au serveur à l'origine de la création.
3. Choisir une machine dans l'ensemble obtenu et y créer le serveur Pour effectuer ce choix, on favorise :
" Les machines contenant moins de serveurs
• Les machines contenant plus de liens de ou vers le nouveau serveur 4. Choisir le répertoire de machines vide du nouveau serveur
Pour ce faire, on peut soit reprendre le même répertoire, soit lui demander le répertoire le moins utilisé
Création d'un serveur de catégorie
Il faut noter ici que personne n'est lié à un serveur de catégorie avant que la catégorisation qui l'a créé ne soit achevée, et par conséquent on peut attendre ce moment pour choisir la machine qui l'hébergera, au moment où on connaît son ensemble de pages.
Ensuite, on a intérêt à placer les serveurs de catégorie avec leurs pages, comme ces dernières devront souvent demander à la catégorie s'ils y appartiennent toujours. Donc finalement la procédure à effectuer est identique à celle pour un serveur de page :
1. Trouver les machines contenant les serveurs des pages contenues.
2. Obtenir un ensemble de machines vides par le répertoire associé au serveur créant ce serveur de catégorie.
3. Choisir une machine dans l'ensemble obtenu et y créer le serveur Pour effectuer ce choix, on favorise :
• Les machines contenant moins de serveurs
• Les machines contenant plus de liens vers le nouveau serveur
4. Choisir le répertoire de machines vides du nouveau serveur.
Pour ce faire, on peut soit reprendre le même répertoire, soit lui demander le répertoire le moins utilisé.
Réalisation sur des machines non fiables
Le modèle précédent ne peut être directement appliqué à un ensemble de machines reliées à
Internet, car elles peuvent se déconnecter à tout moment.
Pour pouvoir travailler sur un tel ensemble de machines, il faudrait être capable de profiter de la puissance de calcul d'une machine tant qu'elle est allumée, et ne pas trop perdre d'informations si elle disparaît.
Un problème apparaît alors, concernant le stockage des informations : bien qu'il soit envisageable d'utiliser une redondance de chaque information sur plusieurs machines pour diminuer les risques d'une perte, il est plus raisonnable d'exiger un stock de machines dignes de confiance dont le rôle soit d'assurer cette tâche.
Phares et lucioles
On va supposer qu'un petit ensemble de machine, les « phares », ne s'éteignent jamais. Les autres sont les « lucioles ». Lorsqu'un calcul doit être effectué, les lucioles intervenant dans le calcul vont télécharger l'information la plus récente depuis les phares ; quand une information change, la luciole va en informer le phare. Ceci est illustré à la figure Fig. 50.
On peut d'autre part considérer que l'attribution d'un serveur à une luciole est effectuée au dernier moment, et que si une luciole devient indisponible, alors ses serveurs sont déplacés soit dans une autre luciole prenant déjà part au calcul, soit une nouvelle luciole est recherchée, pour reprendre le calcul à l'endroit où il avait été abandonné.
Motivations
Il faut de plus trouver une motivation pour les propriétaires de ces machines pour qu'ils n'éteignent pas leur machine au milieu d'un calcul important, et même simplement pour qu'ils acceptent d'être connecté au système. En général, un utilisateur faisant une requête au système la fera sur son propre ordinateur, en tant que luciole. Ceci signifie qu'on peut supposer que sa machine restera allumée pendant tout le traitement de la requête. Si ce n'est pas le cas, la requête peut échouer, car ça signifie que l'utilisateur n'est pas intéressé par les résultats. En conséquence, il est possible d'utiliser la machine de l'utilisateur pour centraliser les opérations.
D'autre part, comme cet utilisateur fera probablement plus qu'une requête dans un même domaine, il est possible de faire une sorte de cache sur sa machine, de façon à limiter la quantité de données transférées avec les phares.
Et finalement, on peut proposer à l'utilisateur de mettre sa machine à disposition, et en échange d'être àjour en permanence sur le domaine qui l'intéresse.
Etant donné qu'il y aura nécessairement plus d'un utilisateur du système intéressé par un certain domaine, on peut compter sur un ensemble de machines autres que la source de la requête comme puissance de calcul, bien qu'il soit très possible que ces dernières s'éteignent sans prévenir.
Algorithme
En résumé, pour traiter une requête les opérations effectuées sont :
1. La luciole va mettre àjour ses données stockées, en interrogeant le ou les phares associés, et obtenir un ensemble de lucioles susceptibles de l'aider
2. La luciole va choisir les lucioles qui contribueront à la catégorisation et va redistribuer les serveurs sur elles.
3. Les lucioles effectuent la catégorisation
4. Les lucioles se synchronisent régulièrement avec les phares.
5. Lorsque la catégorisation est terminée, la luciole source peut en informer son utilisateur La luciole source connaît donc la distribution des serveurs sur les autres lucioles prenant part au calcul ; si l'une d'elle s'éteint (si par exemple elle ne répond plus), elle va se charger de répartir les serveurs concernés sur les autres lucioles.
Si la luciole source cesse de répondre, la catégorisation va s'interrompre d'elle-même, mais seul le travail effectué depuis la dernière synchronisation avec le phare sera perdu. Si par exemple la même requête est effectuée plus tard, la catégorisation reprendra au point où elle avait été interrompue. (Voir section « Mise àjour des catégories d'un fragment « ).
Contraintes
En mettant sa machine à disposition, on pourrait permettre à son propriétaire d'imposer certaines limites à sa contribution, en particulier l'espace disque qu'il accepte de donner.
De plus, lorsqu'il effectue une requête, l'utilisateur peut imposer un intervalle de temps après lequel il veut avoir une réponse.
Il faut tenir compte de ces contraintes lors de l'attribution des serveurs aux différentes lucioles. Il sera parfois impossible d'effectuer une catégorisation complète respectant toutes les contraintes, et la réponse sera alors donnée après une catégorisation partielle. La figure Fig. 51 illustre ce procédé.
Recherche de lucioles et distribution des serveurs
On va associer à chaque catégorie une liste des lucioles qui y sont intéressées.
Lorsque la luciole va télécharger les informations nécessaires pour la catégorisation, elle va recevoir avec chaque catégorie une liste de lucioles.
Ensuite, elle va chercher à contacter chaque luciole de la liste pour savoir lesquelles sont disponibles, et quel est leur espace disque.
Une fois que la catégorisation est terminée, la luciole initiale va s'ajouter aux listes des lucioles intéressées, pour chaque catégorie retournée par la requête.
Une fois que l'ensemble des lucioles devant effectuer la catégorisation est constitué, on peut effectuer un travail similaire à celui de la création de serveurs vu dans le modèle précédent, en attribuant pour chaque serveur une des lucioles de la liste (voir plus haut section «Création d'un serveur de page »), et la catégorisation est ensuite effectuée comme avant (voir plus haut section
« Parallélisation »).
Si une luciole autre que la luciole centrale ne répond pas après un certain temps, la luciole centrale va distribuer la liste de serveurs que la luciole éteinte gérait parmi les autres, et renvoyer les messages qui n'avaient pas reçu de réponse.
Ensuite, chaque fois qu'une catégorie a achevé sa création, elle est transmise au phare, et de même lorsque des nouvelles pages entrent dans une catégorie.
Mise àjour des catégories d'un fragment
Il n'est pas nécessaire de refaire tout le travail vu à la section précédente si le fragment est déjà un peu catégorisé. Plus précisément, il est nécessaire que le système sache profiter d'un travail déjà effectué tout en restant àjour.
En fait, lorsque le serveur de fragment reçoit une demande de catégories, il doit prendre la décision de lancer ou ne pas lancer une catégorisation. Autrement dit, il doit décider si les dernières catégories sont suffisamment àjour.
Voici quelques facteurs (parmi d'autres) qui permettraient de prendre cette décision :
• Les changements dans la liste de contextes depuis la dernière catégorisation
En effet, l'ensemble des contextes d'un fragment intervient de façon essentielle dans les relations entre lui et les catégories, et plus les changements sont importants, plus les chances que les catégories doivent évoluer sont importantes
• Le temps écoulé depuis la dernière catégorisation
Les catégories changent au fil du temps. Ceci signifie qu'après un certain temps il faut considérer une catégorisation comme devenant périmée.
• La fréquence des requêtes de catégorisation
Ceci se mesure par exemple avec le nombre de requêtes implicites concernant ce fragment effectuées pendant le dernier mois. Une fréquence élevée de sollicitations est un indice que le fragment est important, et donc qu'il est important que sa catégorisation soit précise.
D'autre part, si le serveur a lancé une catégorisation, chaque fragment de l'ensemble P(U(Po)) (les fragments ayant des contextes communs) peut décider, relativement à l'ensemble des catégories, avec lesquelles elle va se mettre àjour. (Etape 7)
Voici une liste de facteur pour cette décision :
• PO est beaucoup plus important que les autre, car la catégorisation est effectuée à partir d'une requête vers PO.
• Les changements dans la liste de contextes depuis la dernière catégorisation
• Le dernier score du fragment vis-à-vis des autres catégories
L'acceptation d'un fragment dans une catégorie est effectuée en calculant le score de ce couple (P-K), puis en le comparant à un certain seuil. Ceci signifie que les fragments ayant obtenu un score proche de ce seuil ont plus de chance de voir leur appartenance à la catégorie changer que les autres. Par conséquent, il faut vérifier plus souvent les couples ayant eu un score proche de ce seuil, qu'il lui ait été supérieur ou inférieur, comme illustré à la figure Fig. 52. Entrée d'un fragment dans une catégorie
On va préciser les techniques utilisées par un serveur de catégorie pour décider l'entrée ou non d'un fragment.
Raisons d'aimer
• Le système est basé sur la notion de raisons d'aimer un fragment, décrit à la section suivante. Une page (ou un fragment) peut être aimée pour différentes raisons, et un utilisateur (propriétaire du contexte contenant le fragment) peut être sensible à un certain nombre de raisons.
• L'intérêt d'un utilisateur envers une page (fragment) est expliqué par la présence de raisons dans la page auxquelles il est sensible.
• La notion de quantité de raisons d'un ensemble sera utilisée ici, et correspond à la probabilité pour un utilisateur aléatoire d'être intéressé par une raison de cet ensemble.
• L'homogénéité d'un ensemble de pages (fragments) est défini par la quantité de raisons communes à toutes ces pages (à tous ces fragments). Le mot proximité est synonyme d'homogénéité dans ce rapport.
Equations
La probabilité d'aimer un certain fragment P; sera notée •. La probabilité d'aimer au moins un fragment parmi Pi, Pj, ..., Pn sera notée p,j...„. L'homogénéité (Le., la quantité de raisons communes) sera notée x (ou r), avec éventuellement entre parenthèses ou en indice les fragments dont il est question.
Des calculs algébriques permettent d'obtenir des équations donnant la quantité de raisons communes entre plusieurs fragments (voir section suivante « Quantité de raisons communes ») :
— x = , et . ai .nsi . d,e sui .t.e , (t.ous . les sous-ensembiles i •mpai •rs au
Figure imgf000073_0001
numérateur, et les autres au dénominateur). Les barres supérieures indiquent des compléments, et p0, la probabilité d'aimer au moins une page d'un ensemble vide, est une constante égale à zéro ; elle est présente dans l'équation pour des raisons de cohérence.
Exigences d'une catégorie
A l'intérieur de chaque catégorie se trouve un sous-ensemble de fragments appelé le noyau de la catégorie, et qui contient les fragments qui « représentent » la catégorie. Pour qu'un fragment entre dans une catégorie, il doit être proche de tous les fragments de son noyau. Ainsi, il est possible de calculer le score d'un fragment pour une catégorie, notamment en calculant la moyenne arithmétique des proximités du fragment candidat avec tous les fragments du noyau. Chaque catégorie possède un seuil, qui est le score minimal vis-à-vis du noyau qui est exigé pour entrer dans la catégorie. Il est ensuite possible de modifier quelque peu les exigences d'entrée, en demandant par exemple que le fragment ne soit pas seulement proche en moyenne de tous les fragments du noyau, mais qu'il soit suffisamment proche du tous les fragments du noyau, (le score est alors calculé en prenant la plus petite valeur rencontrée). Des procédés complémentaires (dans le sens où ils peuvent de préférence être mis en œuvre en combinaison avec ce qui est décrit ici) sont décrits plus loin à la section « Algorithmes de construction de catégories ».
Constitution du noyau d'une catégorie
Les fragments du noyau de la catégorie sont donc les fragments qui décident des entrées et des sorties de fragments de la catégorie. Elles doivent donc avoir un bon score relativement à la catégorie. Il est de plus superflu d'avoir deux fragments très proches l'un de l'autre dans le noyau, étant donné qu'ils donneront souvent les mêmes résultats. Une méthode possible de calcul est ainsi la suivante.
Pour confronter un fragment avec une catégorie :
• On calcule son score vis-à-vis des fragments actuellement dans le noyau, et s'il est suffisant, la fragment entre dans la catégorie.
• Si le score est suffisamment grand, la catégorie va entrer dans le noyau, à condition que la plus grande homogénéité avec un fragment du noyau n'ait pas été trop grande.
A noter qu'un fragment ne peut entrer dans le noyau d'une catégorie que s'il est fiable
(populaire). Cette notion sera détaillée plus loin.
A côté de ça, il reste possible pour un fragment d'entrer ou sortir du noyau et/ou de la catégorie, en effectuant les mêmes tests.
Le score d'un fragment est la moyenne arithmétique : (K'P) = Card 'K) Σ (P,'P) (Ker eSt le n°yaU)
Soit ω le plus grand score obtenu :
Figure imgf000074_0001
Ceci est illustré à la figure Fig. 53.
Fiabilité
Les équations présentées plus haut supposent que les informations que nous avons sont complètes, c'est-à-dire que l'ensemble des utilisateurs ayant un intérêt pour le fragment correspond exactement à l'ensemble des utilisateurs propriétaires d'un contexte contenant le fragment. Et donc qu'aucun des utilisateurs n'ayant pas référencé le fragment n'y serait intéressé, ce qui n'est évidemment pas le cas. En réalité, il y a pour chaque fragment un ensemble d'utilisateurs qui ne l'ont jamais vu. Et parmi eux ceux qui l'auraient aimé ne peuvent le faire savoir au système. Ceci est illustré à la figure Fig. 54.
Afin d'alléger le problème, on peut d'une part un peu modifier les équations pour rendre les résultats plus proches de la réalité, et d'autre part introduire un mécanisme pour calculer la fiabilité d'un certain résultat.
La quantité de raisons communes calculée d'après l'équation sera toujours inférieure ou égale à la quantité de contextes du fragment qui en a le moins. Il est possible de rendre comparable des valeurs d'homogénéité en divisant par la quantité d'utilisateurs de la page la moins connue :
Figure imgf000074_0002
A titre d'illustration (voir figure Fig. 55), trois exemples de couples de pages ayant la même quantité (réelle) de raisons communes, mais ayant des popularités différentes.
Liens de navigation, pondération des liens
Un autre défaut, non corrigé par la division ci-dessus, est qu'il y a parfois des groupes de pages
(ou fragments) qui se connaissent tous entre elles, typiquement car elles font partie d'un même site, et comme en plus elles parlent de la même chose, elles risquent d'être toutes liées entre elles. Et tous ces liens internes étoufferont les liens externes, qui semblent pourtant plus importants ! Ceci est illustré par la figure Fig. 56.
Pour ce faire, on va chercher à affaiblir ces liens internes, pour renforcer les liens externes.
Pour ce faire, nous allons simplement affaiblir les liens reliant deux pages que nous savons proches, en affectant un poids à chaque lien, poids qui sera égal au complément de la proximité des deux pages reliées. (Plus la proximité est grande, plus le lien doit être affaibli) Une fois que les liens sont ainsi pondérés, il est possible de calculer l'homogénéité d'un ensemble de page en utilisant non plus le nombre d'utilisateurs, mais la somme de leurs poids. Ensuite, pour trouver le nombre d'utilisateurs utilisant au moins une page parmi un ensemble, on va prendre la somme, pour tous ces utilisateurs, du poids le plus élevé. Ceci est illustré à la figure Fig. 57 pour l'exemple numérique suivant :
Le nombre d'utilisateurs de A est égal à 0.9+0.2+0.4+fl.#=2.3
Le nombre d'utilisateurs de B est égal à 09+0. +0.3+0.5=1.8
Le nombre d'utilisateurs de A ou B Ç PAB est égal à 0.9+0.2+0.9+0+0.3+0.5=3.6
Ainsi, si on suppose que le nombre total d'utilisateur est égal à 100, le calcul de la proximité de
A et B donne :
^ = PΛ ' PB_ = 0-977 - 0.982 ^ ce ^ donne • ^ΛB_ ≈ Q 264 = 26Λ% PB - PAB 1 - 0.964 pB
Le problème bien connu des « liens de navigation » est ainsi résolu. Ceci est illustré à la figure Fig. 58.
Estimation de la fiabilité
Etant donné que les réponses données à l'utilisateurs reposent sur ces audacieuses extrapolations, il est utile de savoir estimer la fiabilité des résultats.
Toutes les corrections apportées consistent à estimer, parmi les utilisateurs n'ayant pas mis de liens, quelle quantité ne l'ont pas fait par désintérêt mais par non-connaissance de la page. Il en suit que plus la quantité d'utilisateur est faible, plus les extrapolations sont hasardeuses, et plus elle est grande, plus le résultat est précis. Plus le résultat est fiable. Ainsi, on peut faire correspondre la fiabilité d'une homogénéité à la plus petite valeur ?,- de l'ensemble considéré. D'autre part, comme décrit plus haut, seules les pages (fragments) fiables peuvent entrer dans le noyau d'une catégorie, ce qui signifie en l'occurrence les fragments populaires. Ainsi, on peut calculer, pour chaque fragment de la réponse à une requête implicite, sa fiabilité : Des fragments de la requête ont amené à choisir une catégorie, et cette catégorie contenait un des fragments proposés. La fiabilité de cette chaîne peut être calculée en multipliant la fiabilité du choix de la catégorie par la fiabilité du choix du fragment; par exemple le ou logique des fragments de la catégorie présentes dans la requête multiplié par la popularité du fragment retourné :
f Pi (R=requête)
Figure imgf000075_0001
Quantité de raisons communes entre pages ou fragments
On va maintenant utiliser le terme « contenu » qui signifie fragment ou page. On peut associer à chaque contenu la probabilité qu'il soit aimé par un utilisateur aléatoire. Cette probabilité peut être approchée en prenant la proportion des utilisateurs auxquels on a accès. Supposons par exemple que le nombre total des utilisateurs ayant eu l'occasion d'examiner un contenu donné soit de 10000, et que 1% d'entre eux, c'est-à-dire 100 utilisateurs, aient manifesté leur intérêt à ce contenu (peu importe la manière de déterminer cet intérêt : bookmarks ou autre critère). On peut alors estimer que 1% est la probabilité courante de s'intéresser à ce contenu. Avec un grand nombre d'utilisateurs, il est probable que les raisons pour lesquelles ils sont intéressés par un contenu soient variées. Par exemple, leur intérêt peut porter au sujet traité dans la page, à la nature d'un produit présenté dans la page, ou aux caractéristiques du produit, tel que son prix notamment, ou encore à l'esthétique de la page elle-même, aux liens qu'elle regroupe, etc. Il est aussi à noter qu'un utilisateur peut s'intéresser à un contenu pour plusieurs raisons. Considérons un ensemble de contenus aimés par un ensemble d'utilisateurs. Chaque contenu est aimé pour un ensemble de raisons (c'est l'union des raisons de l'aimer pour les différents utilisateurs) et il y a des intersections entre les ensembles de raisons associés aux contenus. Les contenus associés à chaque « intersection commune » forment un « groupe de contenus intéressants pour de mêmes raisons ».
Elargissement de la notion d'Utilisateur
Le système de catégorisation automatique que l'on se propose de construire se base sur l'observation de l'intérêt que portent les utilisateurs (les internautes) aux contenus accessibles sur la Toile. Or, au démarrage du système cette observation est impossible puisque les utilisateurs ne vont faire connaître leurs intérêts pour les pages que progressivement en cours d'utilisation du système. C'est donc un cercle vicieux :
- le système ne peut catégoriser sans que les utilisateurs utilisent le système ;
- les utilisateurs n'utiliseront pas le système si les catégories ne sont pas créées.
La présente invention apporte une solution : Les liens vers les contenus de la Toile sont directement accessibles, même avant le démarrage du système, et signifient que leurs auteurs respectifs s'intéressent aux contenus pointés par ces liens. L'idée est de considérer les contenus existants de la Toile comme des utilisateurs virtuels (contenus dits « routeurs »). On a ainsi à disposition un ensemble « d'utilisateurs » dès le démarrage du système. Le procédé consiste à analyser les contenus de la Toile et à suivre les liens qui s'y trouvent afin de constituer un ensemble de contenus en association avec les contenus qu'ils « aiment » respectivement.
Pour les utilisateurs « virtuels » que sont les contenus routeurs, et à la différence des contenus consultés par les utilisateurs réels, on ne peut pas distinguer entre les contenus qui ont été effectivement consultés par les utilisateurs virtuels et les contenus qu'ils n'ont pas été effectivement consultés. On suppose alors que chaque utilisateur virtuel a pris connaissance de tous les contenus vers lesquels il pointe. La conséquence est que les valeurs calculées pour la proximité entre des contenus (ou autrement dit, « l'homogénéité » d'un ensemble de contenus) seront surévaluées. D'où l'intérêt des mesures décrites plus haut à la section « Fiabilité ».
Equations
On va maintenant justifier les équations présentés précédemment. Considérons deux contenus, PI et P2. On sait (on a pu observer) qu'il y a
- NI utilisateurs qui ont eu l'occasion de voir PI,
- N2 utilisateurs qui ont eu l'occasion de voir P2, et parmi eux :
- ni utilisateurs ont aimé PI,
- n2 utilisateurs ont aimé P2
La figure Fig. 59 représente, dans un diagramme de Venn, l'ensemble des raisons d'aimer que présente PI (c'est le contenu du cercle) ; l'extérieur du cercle représente le complément de cet ensemble :
La probabilité (pi) qu'un utilisateur aléatoire parmi les NI utilisateur, aime au moins une des raisons que présente PI est : pl = nl /Nl La probabilité pi' est son complément (c'est-à-dire, c'est la probabilité qu'un utilisateur aléatoire parmi les NI utilisateurs, n'aime aucune des raisons que présente PI) : pl' = l - pl Il en est de même pour P2 : p2 = n2 /N2 p2' = l - p2 La figure Fig. 60 représente l'union des raisons de PI et P2 :
La probabilité pl2' de n'aimer aucune des raisons de cette union est le complément de la probabilité d'aimer les raisons que présente PI ou P2 (au moins une des raisons de l'union). Avantageusement, on pourra adopter l'approximation suivante : pl2 = nl2 /N12 pl2' = l - pl2 où
- nl2 est est le nombre d'utilisateurs qui ont aimé PI ou P2 ou encore PI et P2,
- et N12 est le cardinal de l'union des ensembles des utilisateurs qui ont consultés (eu l'occasion de voir) PI et P2 respectivement.
Notons que, si les événements d'aimer PI et P2 étaient indépendants, autrement dit si le fait d'aimer PI était indépendant du fait d'aimer P2, pl2 aurait été égal au produit de pi et p2 (la probabilité d'occurrence de deux événement indépendants est le produit des probabilités d'occurrence de chacun). Dans le cas où l'observation montre que pl2 ≠ ρl.p2, (aux imprécisions de mesure près) :
- soit PI et P2 ont des raisons communes d'être aimés (et donc le fait d'aimer l'un augmente les chances d'aimer l'autre)
- soit PI et P2 sont antagonistes, c'est-à-dire que le fait d'aimer l'un diminue les chances d'aimer l'autre.
On va maintenant calculer la quantité exacte de raisons communes entre PI et P2.
La figure Fig. 61 représente différents ensembles de raisons que l'on distingue.
Les trois régions mises en évidence - R(P1 \ P2), R(P1) inter R(P2), R(P2 \ PI) - sont indépendantes par définition. Par conséquent,
- comme l'illustre schématiquement la figure Fig. 62, la probabilité pi' (de ne pas aimer PI) est égal au produit de o la probabilité de ne pas aimer les raisons de PI qui ne sont pas des raisons de P2 (ne rien aimer qui soit spécifique à PI) R( P1 \ P2) o et la probalité de ne pas aimer l'intersection des raisons de PI et P2 (ne pas aimer les raisons d'aimer qu 'ils présentent en commun) R(P1) inter R(P2)
- Symétriquement, comme l'illustre la figure Fig. 63, la probabilité p2' (de ne pas aimer P2) est égal au produit de o la probabilité de ne pas aimer R( PI) inter R(P2) o et la probabilité de ne pas aimer R( P2 \ PI)
- et enfin, comme l'illustre la figure Fig. 64, la probabilité pl2' (de n'aimer ni PI ni P2) est égal au produit de o la probabilité de ne pas aimer les raisons de PI qui ne sont pas des raisons de P2 (ne rien aimer qui soit spécifique à PI) R( P1 \ P2) o la probalité de ne pas aimer l'intersection des raisons de PI et P2 (ne pas aimer les raisons d'aimer qu'ils présentent en commun) R( PI) inter R(P2) o et la probabilité de ne pas aimer les raisons de P2 qui ne sont pas des raisons de PI (ne rien aimer qui soit spécifique à PI) R( P2 \ PI) Ainsi, quand on multiplie pi' ( les chances de ne pas aimer PI ) par p2' (les chances de ne pas aimer P2 ), on obtient la probabilité de n'aimer aucun des deux fragments multipliée par la probabilité d'aimer l'intersection des raisons, illustré par la figure Fig. 65 :
Donc la probalité de ne pas aimer les raisons communes à PI et P2 est le rapport pl'.p27pl2', comme sur la figure Fig. 66.
Il suffit ensuite de prendre le complément pour obtenir la probabilité d'aimer les raisons communes à PI et P2, autrement dit, la « quantité de raisons communes », que nous notons par la lettre r : rl2 = l -pl'.p27pl2' Noter que si les fragments ne sont ni indépendants ni antagonistes, la probabilité au dénominateur (pl2') est plus grande que le produit des probabilités au numérateur (pl'.p2'). La quantité de raisons communes (rl2) est alors un nombre compris entre zéro et un. Dans le cas de fragments antagonistes, la quantité de raisons communes (rl2) est un nombre négatif (entre zéro et moins l'infini). Le fait de trouver une quantité de raisons communes négative, et donc de déceler des pages antagonistes, sera exploité dans les procédés de catégorisations que nous décrivons plus loin.
Des pages antagonistes ne rentrerons jamais dans une même catégorie ; la quantité de raisons communes d'une catégorie sera ainsi toujours comprise entre zéro et 1.
Illustrons le raisonnement pour le cas de 3 fragments (voir figure Fig. 67):
En utilisant la même approche que pour 2 fragments, on multiplie tous les ensembles qui ne concernent qu'une page (voir figure Fig. 68):
La figure Fig. 69 présente un diagramme de Venn qui montre le nombre de fois que chaque raison a été prise en compte dans ce produit :
Ensuite on divise par les ensembles qui concernent deux pages (voir figure Fig. 70).
La figure Fig. 71 illustre le résultat obtenu.
Et pour finir, on multiplie par les utilisateurs n'aimant rien (voir figure Fig. 72). ... pour trouver les raisons à l'intersection commune (voir figure (Fig. 73). On a donc bien, en résumé du cas trois P (voir figure Fig. 74).
On a ajouté au dénominateur le complément de la probabilité qui correspond aux utilisateurs d'aucun P (donc ce complément est égal à 1). Pour 3 fragments, la quantité de raisons communes est ainsi : rl23 = l - pl'.p2'.p3'.pl23' / pl2'.pl3'.p23' (pl2', pl3' et p23' sont les compléments des probabilités respectives pl2, pl3 et p23 d'aimer au moins 1 fragment sur deux parmi les trois, et pi 23' est le complément de la probabilité d'aimer au moins l'un des trois fragments).
Quelque soit le nombre de pages, on peut obtenir la valeur exacte de l'intersection (c'est-à-dire la quantité de raisons communes). Le procédé est le suivant :
- pour chaque P on prend au numérateur le nombre d'utilisateurs qui ne l'aiment pas divisé par le nombre d'utilisateurs qui l'ont vu,
- ensuite pour chaque paire de P on prend au dénominateur le nombre d'utilisateurs qui ne les aiment pas divisé par le nombre d'utilisateurs qui les ont vus, - ensuite pour chaque triplet on prend au numérateur le nombre d'utilisateurs qui ne les aiment pas divisé par le nombre d'utilisateurs qui les ont vus,
- et ainsi de suite, en changeant de côté de la fraction à chaque fois.
A la fin, on obtient une valeur qui correspond à la proportion d'utilisateurs qui n'aiment pas l'intersection des raisons (les raisons communes) de l'ensemble de pages. En prenant le complément on trouve la proportion des utilisateurs qui aiment les raisons communes, que l'on appelle la quantité de raisons communes.
On peut montrer que pour chaque type de raison (raison contenue dans un fragment seulement, dans deux fragments, dans trois, ...), le nombre de fois qu'il sera compté avec les ensembles d'un nombre pair de P est le même que le nombre de fois qu'il sera compté avec les ensembles d'un nombre impair de P, à l'unique exception de celles qui sont communes à tous les P, d'où la validité du procédé.
Illustrons le cas où on a la fraction pour 3 fragments
(pl'.p2'.p3'.pl23' / pl2'.pl3'.p23') et on veut en ajouter un quatrième (on veut calculer la quantité de raisons entre les 4 fragments). Pour ce faire, on divise cette fraction par une autre fraction qui est composée des mêmes facteurs mais en ayant ajouté l'indice « 4 » (au détail près qu'on a aussi ajouté p4') :
(pl'.p2'.p3'.pl235 / pl2'.pl3'.p23')
/ (pl4'.p24'.p34'.pl234' / pl24'.pl34'.p234'.p4')
La méthode est la même pour passer de 4 à 5 fragments, de 5 à 6 fragments et ainsi de suite.
Détection de l'anomalie de fragments très proches
Il existe un cas où le modèle des raisons est en désaccord avec la réalité : celui des fragments identiques ou très proches.
En effet, lorsque les utilisateurs mettent des liens, c'est non seulement vers des fragments qui répondent à leurs intérêts, mais aussi vers des fragments quelque peu différents les uns des autres. Ce qui signifie que lorsque deux fragments « deviennent » (pour les besoins du raisonnement) depuis l'indépendance, de plus en plus proches les uns des autres, la probabilité de les retrouver ensemble ( c'est-à-dire la proximité, qui est liée à la valeur de la fraction utilisée pour trouver les intersections ) va tout d'abord augmenter (car les fragments sont proches, ce qui est montré correctement par le modèle), puis soudainement cette probabilité va chuter, jusqu'à devenir inférieure à la valeur qu'on avait quand ils étaient indépendants (car précisément les gens ne « bookmarkent » pas des fragments trop proches, et encore moins des fragments identiques). D'après le modèle décrit dans les sections précédentes, les deux fragments répondant aux même raisons, ils devraient intéresser exactement les mêmes utilisateurs, et par conséquent, les utilisateurs ayant un lien vers le premier devraient être les mêmes que les deuxièmes. Or (comme expliqué plus haut), en réalité l'ensemble des utilisateurs du premier et l'ensemble des utilisateurs du deuxième seront plus disjoints que confondus. La conséquence est que le calcul de l'intersection des raisons (proximité ou quantité de raisons communes) de ces deux fragments donnera une intersection vide ou très petite (alors qu'il s'agit de fragments identiques !).
Ce qui permet de voir qu'il s'agit de fragments très proches, c'est que leurs proximités respectives vis-à-vis des autres fragments sont similaires. A l'extrême, les fragments identiques vont entrer dans les mêmes catégories tout en ayant entre eux (pour l'algorithme) une quantité de raisons communes nulle.
La solution est donc de corriger le tir en adjoignant aux algorithmes, fonctionnant sur le modèle des raisons, une fonction qui recherche ce genre d'îlots, c'est-à-dire un ensemble de fragments qui sont tous dans les mêmes catégories avec des scores équivalents (ils ont un même « profil »), mais qui sont lointains les uns des autres. Les P très proches peuvent ainsi être identifiés et le cas échéant se comporter comme un seul P pour l'algorithme. Toute catégorie associée à l'un est alors automatiquement aussi associée à l'autre.
Le procédé de détection de P très proches consiste à comparer les catégories avec un mécanisme similaire à l'attribution d'une catégorie à un utilisateur (en fait, on considère la catégorie comme un utilisateur ; voir plus haut la section « Attribution d'une catégorie à un utilisateur ») : on regarde l'ensemble des P de la catégorie, puis les catégories de ces P, et on compare les quantités de raisons communes. Lorsqu'on découvre ainsi des couples de catégorie identiques, on les fusionne. Si on a dû fusionner ainsi deux catégorie d'une même sur-catégorie19, il y a des chances que ce soit dû à des fragments identiques. En cas de doutes, on peut étudier ces catégorie (dans les parties qui ne leur sont pas communes) pour voir si elles contiennent des fragments effectivement très proches, et en particulier le fragment ayant déclenché la création d'une nouvelle catégorie. Lorsqu'on a trouvé un couple candidat, il doit vérifier les symptômes de l'identité qui sont : o mêmes catégories et mêmes scores (profils très similaires) o quantité de raisons communes nulle ou négative. A ce moment, l'algorithme peut soumettre les fragments à une comparaison des fragments proprement dits.
Cas particulier des pages miroir :
Le problème peut être réduit lors de l'analyse des pages web ; lorsqu'on suit les liens d'une page, on compare chaque page avec celle qui la précède pour voir s'il s'agit d'un miroir. Si c'est le cas, on identifie les deux par un même fragment.
Fusion de catégories
Il arrive parfois qu'une sous-catégorie construite dans une première catégorie soit quasiment identique (en terme de contenus et donc de raisons) à une sous-catégorie (forcément distincte pour l'algorithme, comme elle est construite indépendamment) construite dans une autre catégorie.
Un exemple : Soit une catégorie qui a été construite autour du thème des avions, et une autre qui a été construite autour du thème des bateaux (par hasard). Ces deux catégories pouront avoir dans leur intersection, des contenus qui notamment
" parlent respectivement des avions et des bateaux • parlent des avions et des bateaux conjointement (dans le même contenu) " mais également des hydravions, qui sont à la fois des avions et des bateaux (ça va sur l'eau) et en particulier, lorsque l'algorithme construira des sous-catégories pour les bateaux et les avions, il va trouver une catégorie hydravions comme enfant de la catégorie avion, ainsi qu'une catégorie hydravions comme enfant de la catégorie bateaux.
Il est donc nécessaire que l'algorithme sache identifier (fusionner) ces deux catégories (et donner à la catégorie résultante les deux catégories avions et bateaux comme parents ). Ceci est illustré en figure Fig. 75.
19 Si elles n'ont pas la même sur-catégorie, on donne toutes les sur-catégories comme parents à la catégorie nouvellement créée (ceci est décrit plus loin à la section « Fusion de catégories »). Le procédé est celui déjà décrit en section « Détection de l'anomalie de contenus très proches ». Il revient à comparer les catégories avec un mécanisme similaire à l'attribution d'une catégorie à un contexte (en fait, on considère la catégorie comme un contexte) : on regarde l'ensemble des fragments de la catégorie, puis les catégories de ces fragments, et on compare les quantités de raisons communes. Lorsqu'on découvre ainsi des couples de catégorie identiques, on les fusionne. Si elles n'ont pas la même sur-catégorie (sinon on se trouve dans le cas de l'anomalie de contenus très proches déjà décrit), on donne toutes les sur-catégories comme parents à la catégorie nouvellement créée (et réciproquement).
On va organiser les catégories en une taxonomie, dont la structure est un poly-arbre et dans laquelle il faut pouvoir insérer une catégorie candidate proposée, en la fusionnant si nécessaire avec une catégorie existante. Les axiomes classiques d'un poly-arbre sont les suivants :
• Quelles que soient deux catégories A et B, A sur-catégorie de B B sous-catégorie de A.
[ANTI-SYMETRIE DES RELATIONS]
• Il n'existe pas de suite non-vide (Ao ; A\ ... ; AN) telle que pour tout i inférieur à N, Ai soit sur-catégorie de Aj+i et AN soit sur-catégorie de Ao. [ABSENCE DE CYCLES]
• Pour toute catégorie B il existe une suite (Ao ;
Figure imgf000081_0001
... ; AN) OÙ AO est l'espace et A égale B, telle que pour tout i inférieur à N, Aj soit sur-catégorie de Ai+i. [CONNEXITE]
Nous ajoutons un troisième axiome qui interdit l'existence de raccourcis (pas possible de passer d'un bout à l'autre d'une chaîne en une fois)
• Quelque soit un couple de catégories (X ;Y) où X est sur-catégorie de Y, Il n'existe pas de suite de plus de deux éléments (A0 ; A\ ... ; AN) OÙ A0=X et AN=Y telle que pour tout i inférieur à N, Aj soit sur-catégorie de AJ-H- (ABSENCE DE RACOURCIS)
On regarde les contenus de la catégorie candidate, puis chacune des catégories de ces contenus. Pour chaque catégorie considérée, on cherche l'intersection de raisons (quantité de raisons communes r) entre la catégorie candidate et la catégorie considérée (les deux étant associés à un ensemble de contenus). Si r est proche de la quantité de raisons communes de la catégorie candidate, alors
- si r est aussi très proche de la catégorie considérée, alors on va fusionner la catégorie candidate avec la catégorie considérée
- sinon la catégorie candidate sera « enfant » (placée en dessous) de la catégorie considérée sinon
- si r est proche de la catégorie considérée, alors la catégorie candidate sera « parent » (placée au-dessus) de la catégorie considérée
- sinon il n'y a pas de relation entre la catégorie candidate et la catégorie considérée dans la taxonomie.
Compléments à la description de procédés de catégorisation
Attribution d'une catégorie à un utilisateur
Il s'agit, pour un utilisateur donné, en connaissant l'ensemble des contenus vers lesquels il possède un lien (c'est-à-dire les contenus qu'il aime), de déterminer l'ensemble des catégories qui l'intéressent.
Le système analyse les contenus qu'aime l'utilisateur, puis chacune des catégories de ces contenus. Pour chaque catégorie considérée, on cherche l'intersection de raisons (proximité) entre l'utilisateur et la catégorie (les deux étant associés à un ensemble de contenus), et on attribue la catégorie si l'intersection est suffisante.
En résultat, la valeur de l'intersection (proximité) est mémorisée comme étant le score de la catégorie pour cet utilisateur ;
Le calcul de proximité entre un utilisateur et une catégorie se fait sur la base théorique suivante : La probabilité d'un contenu aléatoire d'être aimé par un utilisateur Ul est le rapport entre le nombre de contenus que l'utilisateur Ul aime et le nombre de contenus qu'il a vus. Soit pi cette probabilité (et pi' son complément). De même, soit p2 la probabilité pour ce contenu d'être aimé par un utilisateur U2 (et soit p2' son complément). Et enfin, soit pl2 la probabilité d'être aimé par Ul ou U2 (et pl2' de n'être aimé ni par Ul ni par U2). En utilisant le même raisonnement que celui décrit plus haut dans la section « Quantité de raisons communes entre contenus », la quantité de raisons communes entre Ul et U2 est le complément du rapport (pl'.p27pl2'), soit : rl2 = l - pl'.p2' / pl2'
En divisant rl2 par la probabilité la plus petite d'un des utilisateurs d'aimer un contenu aléatoire (autrement dit : la plus petite entre pi et p2), on a la « proximité d'intérêt » entre les deux utilisateurs.
Une catégorie peut être vue comme un utilisateur (puisque les deux sont associés à un ensemble de contenus) et on peut ainsi calculer la proximité d'intérêt entre un utilisateur et une catégorie.
Algorithmes de construction automatique de catégories
On va maintenant décrire quelques variantes du procédé de catégorisation décrit plus haut. D'un point de vue général, il s'agit de parcourir l'ensemble des contenus et insérer chaque contenu (ou insérer un nouveau contenu soumis au système) dans les catégories qui l'acceptent, et créer des nouvelles catégories en cas de besoin (pour les premiers contenus en particulier, quand il n'y a pas de catégories du tout).
Comme les contenus considérés au début n'auront pas eu l'occasion d'entrer dans les catégories créés vers la fin, il est nécessaire de faire deux passages, le deuxième ne provoquant que des entrées de contenus dans des catégories (pas de création de nouvelle catégorie).
Ainsi, l'on peut définir un procédé ou algorithme notamment par les trois types de décisions qu'il devra prendre :
- dans quel ordre parcourt-il les contenus ?
- quand un contenu entre-t-il dans une catégorie ?
- quand un contenu doit-il fonder une nouvelle catégorie ?
Procédé « brutal »
Pour qu'un contenu entre dans une catégorie :
- le contenu doit avoir une intersection avec tous les autres contenus de la catégorie pris individuellement (pour avoir une catégorie d'ordre 2) ;
- le contenu doit avoir une intersection avec tous les couples de la catégorie (pour avoir un ordre 3), et ainsi de suite...
- au lieu d'exiger que tous ces tests réussissent, on peut demander que la moyenne arithmétique de leurs résultats soit bonne.
(On note ici que l'on préfère la moyenne arithmétique à la moyenne géométrique, qui donne trop de poids aux bas résultats, qui se produisent précisément quand on a affaire à des contenus très proches - voir plus haut la section « Détection de l'anomalie de contenus très proches »). Pour qu'un contenu fonde une nouvelle catégorie, il doit :
- n'avoir réussi une entrée dans aucune catégorie existante,
- ou, si on veut être moins exigeant, le meilleur résultat obtenu à un test d'entrée dans une catégorie doit être inférieur à un certain seuil,
- ou encore, pour être plus exigeant, il doit être antagoniste avec une ou des page de la catégorie ; ceci est caractérisé par une valeur négative de quantité de raisons communes avec la catégorie.
Procédé « Heuristique »
Cet algorithme effectue moins de tests que le procédé brutal, et se limite à ceux qui sont les plus importants ou alors ceux qui risquent le plus d'échouer. Il est mis en œuvre comme suit :
- les contenus sont parcourus aléatoirement, - pour qu'un contenu entre dans une catégorie, il lui suffit d'être proche des meilleurs (tests importants) ainsi que des moins bons (tests dangereux) contenus de la catégorie,
- les meilleurs contenus sont ceux qui sont les plus « représentatifs » de la catégorie, c'est-à-dire ceux qui en moyenne sont plus proches des autres que les autres,
- les moins bons sont ceux qui ont failli ne pas y rentrer.
Procédé « Devinette »
Celui-ci fonctionne comme le premier, mais lorsque les quantités de raisons communes deviennent trop lourdes à calculer, il sélectionne quelques termes de la grande fraction à calculer (voir la section « Quantité de raisons communes entre contenus ») de façon à pouvoir deviner les autres sans trop de risque d'erreur, et donc d'estimer l'intersection même pour des grands ensembles de contenus. Autrement dit, il s'agit d'extrapoler la valeur de la grande fraction de l'expression de proximité, à partir d'un faible nombre de facteurs, ainsi que de déterminer le choix des facteurs pour avoir une approximation optimale.
Les facteurs sont rassemblés en groupes : un groupe pour les facteurs ne concernant qu'un contenu (ordre 1), un pour ceux qui concernent deux contenus (ordre 2), etc. On a vu en section 5 « Quantité de raisons communes entre contenus » que les groupes sont placés alternativement de chaque côté de la barre de la fraction, comme suit : (1)(3)(5)(7) ... / (0)(2)(4)(6)(8)... On connaît la valeur de certains facteurs isolés, ainsi que de certains groupes. Une autre donnée importante est le plus petit et le plus grand facteur trouvés dans chaque groupe. Ajouter un contenu consiste notamment à ajouter un groupe. La plus grande augmentation possible entre deux groupes est fonction de leurs facteurs extrêmes (plus petit facteur ; plus grand facteur).
Procédé « Hiérarchique »
Alors que les précédents algorithmes construisent un ensemble de catégories uniformes, celui-ci construit une hiérarchie de catégories : en partant de l'espace initial, il construit les niveaux de la hiérarchie les uns après les autres, en appliquant un algorithme parmi les précédents, mais en fonctionnant en « niveaux » : il commence par parcourir tous les contenus et constitue des catégories en étant très peu exigeant (catégories d'ordre deux, seuils bas ...), puis il effectue le même travail sur chacune des catégories, en étant plus exigeant qu'au précédent niveau ou en cherchant à construire des catégories d'ordre plus élevé, comme illustré sur la figure 103. De plus, la construction d'une catégorie permet de trier les contenus qu'elle contient, de façon à pouvoir choisir l'ordre dans lequel ses P seront pris.
Procédé « Granulaire »
Ce procédé étend le précédent, en se constituant non seulement une hiérarchie de catégories, mais aussi une hiérarchie de « grains » qui sont des mini-catégories d'un petit nombre de contenus, qui ne sont pas divisées au cours de l'algorithme, et qui sont donc traitées globalement : à chaque niveau on cherche à faire entrer des grains (les grains remplacent donc les contenus dans les algorithmes) dans les catégories existantes, et au cours de ces tests, on constitue des grains plus gros qui serviront aux niveaux suivants, comme sur la figure 104. On passe ainsi directement de l'ordre 2 à l'ordre 4, puis (s'il est nécessaire de poursuivre) à l'ordre 8, etc. On a respectivement des grains qui sont des couples de contenus, puis des quadruplets de contenus, puis des octuplets de contenus, etc.
Procédé « Paresseux »
Pour des raisons de temps, il se peut que la recherche de catégories selon le procédé
« Hiérarchique » ou « Granulaire » doive être interrompue à certains endroits de l'arbre. Dans cette situation, certaines catégories ne seront pas redécomposées à des niveaux aussi fins (ordres ou seuils aussi élevés) que d'autres. Ce sont les requêtes des utilisateurs qui provoqueront alors des redécompositions à des niveaux plus fins.

Claims

REVENDICATIONS
1. Procédé de composition d'une ressource (Rx) d'informations, notamment d'un document, organisée selon une structure arborescente de nœuds (Ni), caractérisé en ce qu'il comprend les étapes suivantes :
- pour au moins un nœud (N12 ; N131) de la ressource, agencer ledit nœud comme un fragment (F12 ; F131) comportant ledit nœud comme nœud racine du fragment et tous les sous- nœuds (N121, N122. N1211, ... ; N1311, ...) dudit nœud racine,
- associer à au moins un fragment (F 12) de la ressource une référence de mise àjour (R(N12, FA)) vers un fragment amont (FA), pour former un fragment aval,
- associer à au moins un sous-nœud (NI 21) du fragment aval une référence de non-mise à jour (NR(N121, SFA)), de telle sorte que le contenu du fragment aval (F 12) est composé à partir du contenu du fragment amont (FA), et le cas échéant à partir de contenus d'autres fragments (FA'), à l'exception du contenu de chaque sous-fragment (SF121) correspondant à chaque sous-nœud (N121) auquel est associée une référence de non-mise àjour.
2. Procédé de composition d'une ressource (Rx) d'informations, notamment d'un document, organisée selon une structure arborescente de nœuds (Ni), caractérisé en ce qu'il comprend les étapes suivantes :
- pour au moins un nœud (N12 ; N131) de la ressource, agencer ledit nœud comme un fragment (F12 ; F131) comportant ledit nœud comme nœud racine du fragment et tous les sous- nœuds (N121, N122, N1211, ... ; N1311, ...) dudit nœud racine,
- associer à au moins un fragment (F 12) de la ressource une référence de mise àjour (R(N12, FA)) vers un fragment amont (FA), pour former un fragment aval,
- le cas échéant, associer à au moins un sous-nœud (NI 22) inclus dans un premier fragment aval (F12) une référence de mise àjour (R(N122, FA')) vers un autre fragment amont (FA'), pour former un deuxième fragment aval (F122) qui est sous-fragment dudit premier fragment aval (F 12),
- le cas échéant, associer à au moins un sous-nœud (N121) d'un fragment aval une référence de non-mise àjour (NR(N121, SFA)) vers le sous-nœud correspondant du fragment amont correspondant, de telle sorte que le contenu de chaque fragment aval (F 12 ; SF122) est composé notamment à partir du contenu du fragment amont correspondant (FA ; FA'), à l'exception du contenu de chaque sous-fragment (SF121) correspondant à chaque sous-nœud (N121) auquel est associée une référence de non-mise àjour.
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'il comprend en outre l'étape suivante :
- lors de la composition d'un fragment amont telle que ce dernier contienne au moins un sous-fragment supplémentaire, composer le fragment aval en incluant ledit sous-fragment supplémentaire.
4. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'il comprend en outre l'étape suivante : - lors de chaque composition d'un fragment aval, utiliser la référence de mise àjour vers le fragment amont pour inclure dans le fragment aval tout sous-fragment supplémentaire du fragment amont.
5. Procédé selon l'une des revendications 3 et 4, caractérisé en ce que lesdits fragments supplémentaires sont ceux qui n'ont pas encore été complètement pris en compte à l'aval.
6. Procédé selon l'une des revendications 3 à 5, caractérisé en ce que la composition dans ledit fragment aval d'un sous-fragment supplémentaire inclut une indication d'un mode suggéré dudit nouveau sous-fragment.
7. Procédé selon l'une des revendications 3 à 6, caractérisé en ce que la composition dans ledit fragment aval, d'un sous-fragment supplémentaire, est effectué à condition qu'une indication d'un mode accepté soit associé audit sous-fragment supplémentaire dans la ressource amont.
8. Procédé selon l'une des revendications 3 à 7, caractérisé en ce qu'il comprend en outre l'étape consistant à sélectionner les sous-fragments les plus pertinents parmi les sous-fragments supplémentaires avant de les suggérer dans le sous-fragment aval.
9. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que ladite association d'une référence de mise àjour résulte en la création, sous le fragment aval, de nouveaux sous- nœuds correspondant aux sous-nœuds du fragment amont.
10. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que ladite association d'une référence résulte d'une opération de glisser-déposer de la présentation d'un fragment à l'écran d'affichage, au moyen d'un dispositif de pointage tel qu'une souris.
11. Système de composition d'une ressource (Rx) d'informations, notamment d'un document, organisée selon une structure arborescente de nœuds (Ni),
- ayant au moins un nœud (N12 ; N131) de la ressource agencé comme un fragment (F12 ; F131) comportant ledit nœud comme nœud racine du fragment et tous les sous-nœuds (N121, N122, N1211, ... ; N1311, ...) dudit nœud racine,
- avec au moins un fragment (F 12 ; F 122) de la ressource ayant, associé à lui, une référence de mise àjour (R(N12, FA) ; R(N122,FA')) vers un fragment amont (FA ; FA'), pour former un fragment aval (F 12 ; F 122),
- avec, le cas échéant, au moins un sous-nœud (N121) d'un fragment aval ayant, associé à lui, une référence de non-mise àjour (NR(N121, SFA)) vers le sous-nœud correspondant du fragment amont correspondant, caractérisé en ce qu'il comprend des moyens pour composer le contenu de chaque fragment aval (FI 2 ; SF122) notamment à partir du contenu du fragment amont correspondant (FA ; FA'), à l'exception du contenu de chaque sous-fragment (SF121) correspondant à chaque sous-nœud (N121) auquel est associée une référence de non-mise àjour.
12. Système selon la revendication 11, caractérisé en ce que la ressource (Rx) inclut au moins un nœud (NI 22) qui est inclus dans un premier fragment aval (F 12) et qui a, associé à lui, une référence de mise àjour (R(N122, FA')) vers un autre fragment amont (FA'), pour former un deuxième fragment aval (F 122) qui est sous-fragment dudit premier fragment aval (F 12), et en ce que ledits moyens permettent de composer ledit deuxième fragment aval (F 122) à partir du contenu dudit autre fragment amont (FA').
13. Système selon l'une des revendications 11 et 12, caractérisé en ce qu'il comprend des moyens pour agencer comme un fragment, au moins un nœud (N12 ; N131) de la ressource.
15. Système selon l'une des revendications 11 et 12, caractérisé en ce qu'il comprend des moyens pour associer, à au moins un fragment (F 12 ; F 122) de la ressource, une référence de mise àjour (R(N12, FA) ; R(N122,FA')) vers un fragment amont (FA ; FA'), pour former un fragment aval (F12 ; F122).
15. Système selon la revendication 14, caractérisé en ce qu'il comprend des moyens permettant le glisser-déposer de fragments de l'amont vers l'aval, et en ce que ladite association d'une référence de mise àjour est le résultat d'une opération de glisser-déposer dudit fragment amont vers un emplacement associé au fragment parent du fragment aval et représentant la position du fragment aval dans ledit fragment parent.
16. Système selon l'une des revendications 11 et 12, caractérisé en ce qu'il comprend des moyens pour associer, à au moins un sous-nœud (N121) d'un fragment aval, une référence de non-mise àjour (NR(N121, SFA)) vers le sous-nœud correspondant du fragment amont correspondant.
17. Système selon l'une des revendications 11 et 12, caractérisé en ce qu'il comprend des moyens pour associer, à au moins un nœud (NI 22) inclus dans un premier fragment aval (F 12), une référence de mise àjour (R(N122, FA')) vers un autre fragment amont (FA'), pour former un deuxième fragment aval (F122) qui est sous-fragment dudit premier fragment aval (F12).
18. Procédé de manipulation de documents utilisables notamment pour le travail collaboratif à travers un réseau tel que l'Internet, permettant à l'utilisateur de manipuler des fragments desdits documents, lesdits documents étant d'une part dans leur forme brute constitués d'une structure arborescente composée de nœuds possédant des informations et des attributs et représentés notamment en langage XML, lesdits documents étant d'autre part présentés pour affichage ou autre interface, notamment en langage HTML et scripts, après transformation par programmes, règles de réecriture ou feuilles de styles notamment en langage XSL, caractérisé en ce qu'il comprend les étapes suivantes : a) des moyens interactifs, permettant de manipuler lesdits fragments notamment avec un dispositif de pointage tel qu'une souris, sont assemblés dynamiquement au moment de la construction de ladite présentation à partir de la forme brute d'un document pour affichage en mode manipulation ; b) l'utilisateur utilise certains de ces moyens interactifs pour manipuler lesdits fragments dans leur présentation d'affichage en mode manipulation; c) en conséquence le système met à jour dans ledit document dans sa forme brute chaque fragment ayant donné lieu en l'étape (a) à l'assemblage de moyens utilisés en l'étape (b).
19. Procédé selon la revendication 18, caractérisé en ce qu'il comprend avant l'étape (a) une étape dans laquelle l'utilisateur requiert une présentation d'affichage en mode manipulation.
20. Procédé selon la revendication 19, caractérisé en ce que ladite requête s'effectue en utilisant un bouton ou dispositif analogue.
21. Procédé selon la revendication 20, caractérisé en ce que ledit bouton ou dispositif analogue est utilisé pour requérir la version en mode manipulation d'une présentation couramment affichée en mode normal.
22. Procédé selon la revendication 21, caractérisé en ce que ledit bouton ou dispositif analogue est présenté sous la forme d'un objet graphique faisant partie de ladite présentation d'affichage en mode normal, ledit objet graphique étant activable au moyen d'un dispositif de pointage tel que la souris pour faire basculer au mode manipulation ladite présentation couramment affichée en mode normal.
23. Procédé selon l'une des revendications 21 et 22, caractérisé en ce que ledit basculement au mode manipulation est effectué pour une région sélectionnée par l'utilisateur le cas échéant ou si aucune région n'a été sélectionnée pour toute ladite présentation.
24. Procédé selon la revendication 20, caractérisé en ce que ledit bouton ou dispositif analogue est utilisé en combinaison avec l'action qui aurait permis de soumettre une requête d'affichage en mode normal.
25. Procédé selon la revendication 19, caractérisé en ce que ladite requête s'effectue de manière très légèrement différente de celle pour obtenir la présentation d'affichage en mode normal, ladite différence consistant notamment à ajouter un ensemble de caractères, tel que par exemple le mot "admin" précédé du caractère "/",
• à la fin du texte de la requête d'affichage en mode normal
" ou dans le texte de la requête d'affichage en mode normal, juste après le nom de domaine.
26. Procédé selon la revendication 18, caractérisé en ce qu'en l'étape (a) lesdits moyens interactifs sont mis en oeuvre après prise de connaissance par le système
" de l'existence,
• la position dans la structure arborescente du document " et les attributs desdits nœuds fragments et de leurs nœuds parents dans lesdits documents dans leur forme brute.
27. Procédé selon la revendication 18, caractérisé en ce qu'en l'étape (b) ladite manipulation a pour but d'éditer le contenu d'un fragment et en ce qu'elle résulte en l'étape (c) en la modification dudit contenu.
28. Procédé selon la revendication 18, caractérisé en ce qu'en l'étape (b) ladite manipulation a pour but de déplacer ou reproduire un fragment, notamment d'un site Internet à l'autre, et en ce qu'elle résulte en l'étape (c) en l'insertion dudit fragment et/ou d'une référence audit fragment sous un noeud ayant un attribut de délimitation (récipient).
29. Procédé selon l'une des revendications 18 et 26 à 28, caractérisé en ce que :
" lesdits moyens interactifs comportent des objets graphiques utilisables avec un dispositif de pointage tel que notamment une souris,
• en ce que l'étape (b) s'effectue par une opération de glisser-déposer d'un premier objet graphique (poignée) associé à un premier fragment - notamment à reproduire ou déplacer - sur un deuxième objet graphique (cible) associé à un deuxième fragment,
• et en ce qu'en l'étape (c) ladite mise à jour - notamment l'insertion dudit fragment à reproduire ou déplacer - s'effectue au moins à l'emplacement déterminé par les propriétés dudit deuxième objet graphique (cible).
30. Procédé selon la revendication 18, caractérisé en ce que :
• au préalable chaque document dans sa forme brute est décomposé en une macrostructure et une ou plusieurs microstructures dont au moins une référence sur chacune d'elles se trouve dans ladite macrostructure
• et en ce qu'il comprend avant l'étape (a), une étape consistant à recomposer, à partir de ladite macrostructure et lesdites microstructures, le document dans sa forme brute.
31. Procédé selon la revendication 30 caractérisé en ce que ladite décomposition comprend les étapes suivantes :
" lors de la création ou d'une mise àjour dudit document, insérer dans celui-ci des attributs de délimitation (récipient) aptes chacun à distinguer les fragments représentés par chaque nœud dont le nœud parent possède ledit attribut de délimitation,
• extraire lesdits fragments, c'est-à-dire les informations délimitées par chaque nœud dont le nœud parent possède ledit attribut de délimitation, ladite extraction étant effectuée d'abord sur ledit document et ensuite récursivement sur les informations elle-mêmes extraites, et créer o d'une part un ensemble de microstructures chacune étant constituée du reste des informations extraites à l'aval dans ledit traitement récursif, auquel a été ajouté des attributs de position (récipient-nb) indiquant à quelles positions se trouvaient ledites informations extraites o et d'autre part une macrostructure dudit document constituée par une structure arborescente plus grossière que ladite structure arborescente du document, dans laquelle :
" chaque nœud dont le nœud parent possède ledit attribut de délimitation (récipient) est remplacé par une référence à une microstructure,
• chaque nœud possédant lui-même ledit attribut de délimitation (récipient) est remplacé par un nœud (récipient) indiquant la position (recipient-nb) desdites microstructures extraites à l'aval dans ledit traitement récursif
• et tous les nœuds qui ne possèdent pas ledit attribut de délimitation et dont le nœud parent ne possède pas non plus ledit attribut de délimitation sont absents.
32. Procédé selon la revendication 30 caractérisé en ce que ladite décomposition comprend les étapes suivantes :
" lors de la création dudit document d'origine, insérer dans celui-ci des attributs de délimitation aptes chacun à regrouper des nœuds descendants avec un nœud parent desdits nœuds descendants, 1 extraire les informations situées aux nœuds regroupés, ladite extraction étant effectuée d'abord sur ledit document et ensuite récursivement sur les informations elle-mêmes extraites, et créer o d'une part un ensemble de microstructures constituées des restes des informations extraites auxquels ont été ajouté des attributs indiquant à quelles positions se trouvaient les informations extraites à l'aval dans ledit traitement récursif o et d'autre part une macrostructure du document constituée par une structure arborescente plus grossière que ladite structure arborescente de document, dans laquelle lesdits nœuds parents correspondant à des regroupements sont remplacés par des références auxdites informations extraites, indiquant la position desdites informations extraites dans la structure, et dans laquelle lesdits nœuds descendants qui ne sont pas eux-mêmes des nœuds parents sont absents.
33. Procédé selon l'une des revendications 18 à 32, caractérisé en ce que l'étape (c) comprend des actions dans lesquelles une ou plusieurs nouvelles références
" soit à une microstructure,
" soit à un nœud qui se trouve dans une macrostructure et dont un nœud ancêtre possède ledit attribut de délimitation (récipient), peuvent être insérés ou supprimés au niveau d'un nœud qui possède ledit attribut de délimitation.
34. Procédé selon l'une des revendications 30 à 33, caractérisé en ce que lesdites microstructures sont atomiques.
35. Procédé selon l'une des revendications 30 à 33, caractérisé en ce que les informations extraites à chaque niveau dans ledit traitement récursif constituent un fragment accessible dont la structure est représentée dans ladite macrostructure, et en ce que ledit fragment est constitué d'une microstructure ou de plusieurs microstructures imbriquées.
36. Procédé selon l'une des revendications 18 et 30 à 35, caractérisé en ce que ladite recomposition avant l'étape (a) peut avoir comme effet l'insertion d'attributs supplémentaires sur les nœuds mais en aucun cas n'a comme effet de modifier la structure des nœuds du document dans sa forme brute.
37. Procédé selon l'une des revendications 18 et 30 à 36, caractérisé en ce que lors de l'application des feuilles de style, et d'autres programmes de transformations le cas échéant, dans l'étape (a), le système transforme en XHTML ledit document sauf tous les fragments dont un style local est préféré ; ces derniers sont copiés intégralement afin que leur transformation puisse être effectuée lors d'un prochain passage dans le cadre d'un procédé itératif dans lequel à chaque passage, les fragments qui n'ont pas encore été transformés en XHTML sont transformés à leur tour, jusqu'à que tous les fragments aient été traités.
38. Procédé selon l'une des revendications 18 et 30 à 37, caractérisé en ce qu'en l'étape (c) : " une nouvelle version de chaque référence à fragment modifié et de chaque microstructure modifié le cas échéant est créée " et les anciennes versions des fragments et microstructures sur lesquelles aucune macrostructure ne pointe sont supprimées.
39. Système de traitement de données, caractérisé en ce qu'il fournit au moins un mécanisme permettant d'automatiser au moins l'une des étapes mentionnées aux revendications 18 à 38.
40. Système de traitement de données destiné à présenter des documents sur un dispositif d'affichage ou équivalent et permettant de manipuler des fragments desdits documents notamment dans le cadre d'un travail collaboratif, lesdits documents étant d'une part dans leur forme brute constitués d'une structure arborescente composée de nœuds possédant des informations et des attributs, et représentés notamment en langage XML, et d'autre part présentés pour affichage notamment en langage HTML et scripts, après traduction par programmes, règles de réecriture ou feuilles de styles notamment en langage XSL, caractérisé
• en ce qu'il comprend des moyens interactifs comportant des objets graphiques associés auxdits fragments et placés au sein de ladite présentation d'affichage, permettant à l'utilisateur d'effectuer ladite manipulation simplement en agissant sur lesdits objets graphiques au moyen d'un dispositif de pointage tel que la souris,
" en ce qu'il est apte à assembler et mettre en oeuvre lesdits moyens interactifs dynamiquement, à la volée, à l'appel de l'affichage desdits fragments, à partir notamment d'informations associées auxdits fragments des documents dans leur forme brute
" et en ce que lesdits objets graphiques possèdent des informations permettant au système de retrouver quels sont les fragments des documents dans leur forme brute à mettre à jour en fonction des actions de l'utilisateur.
41. Système selon la revendication 40, caractérisé en ce que lesdites manipulations consistent à modifier le contenu de fragments existants ou à en créer de nouveaux.
42. Système selon la revendication 40, caractérisé en ce que lesdites manipulations consistent à reproduire ou déplacer des fragments d'un site Internet à l'autre.
43. Système selon l'une des revendications 40 à 42, caractérisé en ce que ladite présentation d'affichage est construite à partir de documents, dans leur forme brute, recomposées selon les revendications 13 à 20.
44. Système selon l'une des revendications 40 à 43, caractérisé en ce que lesdits moyens interactifs sont restreints en fonction des droits d'action associés auxdits utilisateurs.
45. Système selon l'une des revendications 40 à 44, caractérisé en ce qu'il est apte à décider de l'existence et la nature desdits moyens interactifs à mettre en œuvre en association avec chaque fragment d'un document dans sa forme brute, en fonction de l'existence ou la valeur d'attributs spécifiques possédés par ledit fragment le cas échéant.
46. Système selon l'une des revendications 40 à 45, caractérisé en ce qu'il est apte à assembler et mettre en oeuvre des moyens interactifs différents pour des types différents d'information contenue dans lesdits fragments des documents dans leur forme brute.
47. Système selon la revendication 40 à 46, caractérisé en ce qu'il est apte à déterminer le choix des moyens interactifs à assembler à partir des balises et attributs ou autres marqueurs caractérisant les noeuds contenus dans lesdits fragments des documents dans leur forme brute.
48. Système selon la revendication 40 à 47, caractérisé en ce que ledit choix s'effectue en combinaison avec les informations contenues dans les schéma de données auquels se conforment lesdits fragments des documents dans leur forme brute.
49. Système selon l'une des revendication 40 à 48, caractérisé en ce que les créations, déplacements ou reproductions de fragments causés par l'utilisation desdits moyens interactifs résultent automatiquement en de nouveaux fragments et/ou en de nouvelles références à fragments insérés dans les documents dans leur forme brute à des positions découlant desdites actions de l'utilisateur.
50. Système selon la revendication 40 à 49, caractérisé en ce que lesdits nouveaux fragments et/ou références à fragments sont insérés
" sous un nœud possédant un attribut spécifique de délimitation (récipient) " et entre des nœuds fragments déjà existants le cas échéant.
51. Système selon l'une des revendications 40 à 50, caractérisé en ce que la position de chaque nouveau fragment ou référence à fragment inséré suite à une action de l'utilisateur est déterminée à partir d'informations mémorisées en association avec lesdits objets graphiques utilisés dans le cadre de ladite action.
52. Système selon l'une des revendications 40 à 51, caractérisé et en ce que le système est apte à placer dans la présentation d'affichage lesdits objets graphiques, à partir d'une prise de connaissance de l'existence et la position dans la structure arborescente du document dans sa forme brute, ainsi que des attributs spécifiques,
" de nœuds possédant un attribut de délimitation (récipient) " et de nœuds fragments.
53. Système selon l'une des revendications 40 à 52, caractérisé en ce que des moyens interactifs distincts sont mis en oeuvre pour chaque nœud d'un document dans sa forme brute possédant un attribut de délimitation (récipient) qui possède également un attribut indiquant le fait que les fragments qu'il délimite sont manipulables avec lesdits moyens.
54. Système selon l'une des revendications 40 à 53, caractérisé en ce que la présentation d'affichage d'un fragment manipulable d'un documents dans sa forme brute comprend un objet graphique (bouton) permettant de le sélectionner au moyen d'un dispositif de pointage afin notamment de consulter des aspects dudit fragment qui ne sont pas affichés ou d'éditer le contenu, les propriétés, les liens ou la feuille de style permettant la présentation dudit fragment.
55. Système selon l'une des revendications 40 à 54, caractérisé en ce que la présentation d'affichage d'un premier fragment manipulable d'un document dans sa forme brute comprend un objet graphique (poignée) associé audit premier fragment et permettant de le glisser-déposer au moyen d'un dispositif de pointage sur un objet graphique (cible) associé à un deuxième fragment manipulable d'un document dans sa forme brute.
56. Système selon les revendications 54 et 55 prises en combinaison, caractérisé en ce que l'objet graphique (bouton) permettant de sélectionner un fragment est également un objet graphique (poignée) permettant de le glisser-déposer sur un objet graphique (cible).
57. Système selon les revendications 54 et 55 prises en combinaison, caractérisé en ce que l'objet graphique (bouton) permettant de sélectionner un fragment est également un objet graphique (cible) sur lequel l'utilisateur peut glisser-déposer un objet graphique (poignée).
58. Système selon la revendication 55, caractérisé en ce que ladite opération de glisser- déposer permet de déplacer ou reproduire ledit premier fragment à l'emplacement indiqué par l'objet graphique (cible) associé audit deuxième fragment.
59. Système selon la revendication 55, caractérisé en ce que ladite opération de glisser- déposer permet de créer un lien mémorisé entre ledit premier fragment et ledit deuxième fragment.
60. Système selon la revendication 55, caractérisé en ce que ladite opération de glisser- déposer permet de créer une proposition de contrat entre le propriétaire dudit premier fragment et le propriétaire dudit deuxième fragment.
61. Système selon l'une des revendication 55 à 60, caractérisé en ce que ledit objet graphique associé à un deuxième fragment est situé dans la même page que ledit objet graphique associé à un premier fragment.
62. Système selon l'une des revendication 55 à 60, caractérisé en ce que ledit objet graphique associé à un deuxième fragment est situé dans une page différente que celle dudit objet graphique associé à un premier fragment.
63. Système selon l'une des revendication 55 à 60, caractérisé en ce que ledit objet graphique associé à un deuxième fragment est situé dans une page d'un site différent de celui dudit objet graphique associé à un premier fragment.
64. Système selon la revendication 55, caractérisé en ce que l'objet graphique poignée associé audit premier fragment est également un objet graphique cible et permet en conséquence de glisser-déposer sur lui un objet graphique associé à un autre fragment.
65. Système de navigation mis en œuvre dans un système informatique pour accéder à des pages fournies notamment par des serveurs via un réseau informatique par activation de liens, caractérisé en ce qu'il comprend en combinaison :
- des moyens pour afficher une page courante,
- des moyens permettant à un utilisateur de créer et de mémoriser, au sein d'une structure de groupes de liens, des liens dont ladite page constitue une extrémité ;
- des moyens de sélection et d'affichage aptes, lors de l'affichage d'une page constituant une extrémité d'au moins un lien, à sélectionner et afficher une partie de la structure de groupes de liens contenant ce ou ces liens, et
- des moyens d'entrée permettant à l'utilisateur de sélectionner et d'activer les liens affichés contenus dans ladite partie de la structure de groupes de liens.
66. Système selon la revendication 65, caractérisé en ce que lesdits liens comprennent des liens ajoutés, associés à ladite page courante et permettant d'accéder à d'autres pages, et en ce que les moyens d'affichage sont aptes à afficher des représentations desdits liens ajoutés activables directement par lesdits moyens d'entrée.
67. Système selon la revendication 66, caractérisé en ce que les moyens de création de liens ajoutés comprennent un moyen d'entrée permettant à l'utilisateur de glisser-déposer la page courante ou un élément affiché représentant la page courante vers une autre page affichée ou un élément affiché représentant ladite autre page.
68. Système selon l'une des revendications 66 et 67, caractérisé en ce qu'il est prévu une zone d'affichage de liens ajoutés associée à ladite page courante et apte à contenir lesdits éléments affichés représentant les liens ajoutés vers lesdites autres pages.
69. Système selon l'une des revendications 66 à 68, caractérisé en ce qu'il comprend des moyens pour afficher la page courante et sa zone d'affichage de liens ajoutés associée et des moyens pour afficher les zones d'affichage de liens d'une pluralité d'autres pages, de façon contiguë les unes aux autres.
70. Système selon la revendication 65, caractérisé en ce que chaque zone d'affichage de liens ajoutés contient également un élément affiché représentant la page à laquelle lesdits liens ajoutés sont associés, et en ce que les moyens de création de liens ajoutés mettent en œuvre des opérations de glisser-déposer entre les éléments affichés représentant les pages et les éléments affichés représentant les liens ajoutés.
71. Système selon l'une des revendications 69 et 70, caractérisé en ce qu'il comprend des moyens pour afficher, sous la commande d'un moyen d'entrée agissant sur une zone donnée d'affichage de liens ajoutés, la page à laquelle lesdits liens ajoutés sont associés.
72. Système selon l'une des revendications 66 à 71, caractérisé en ce que lesdits éléments affichés représentant les pages auxquelles les liens ajoutés sont associés et lesdits liens ajoutés sont constituées par des images miniaturisées desdites pages associées ou des pages vers lesquelles pointent lesdits liens ajoutés.
73. Système selon l'une des revendications 66 à 72, caractérisé en ce que lesdits liens ajoutés sont sélectivement monodirectionnels ou bidirectionnels.
74. Système selon l'une des revendications 65 à 73, caractérisé en ce que ladite structure de groupes de liens est une structure arborescente de répertoires contenant chacun d'autres répertoires et/ou des liens créés.
75. Système selon la revendication 65, caractérisé en ce que lesdits liens comprennent des marque-pages, et en ce que les moyens de sélection et d'affichage sont aptes à afficher les seuls groupes des liens contenant un marque-page correspondant à la page courante.
76. Système selon les revendications 74 et 77 prises en combinaison, caractérisé en ce que les moyens de sélection et d'affichage sont aptes à afficher dans une première zone des éléments affichés représentant des liens ajoutés, et dans une seconde zone des répertoires de marque-pages contenant un marque-page correspondant à la page courante.
77. Système selon la revendication 76, caractérisé en ce que dans la seconde zone sont affichés par une représentation hiérarchique lesdits répertoires de marque-pages et, sélectivement, les contenus desdits répertoires.
78. Système selon l'une des revendications 74 à 77, caractérisé en ce qu'il comprend des moyens pour afficher une pluralité de répertoires contenant des premiers éléments affichés constituant des liens vers des pages et secondes représentations graphiques constituant des liens ajoutés entre lesdites pages, et des moyens pour manipuler par glisser-déposer lesdites premières et secondes représentations graphiques pour ajouter, supprimer ou déplacer d'un répertoire à l'autre des liens vers des pages ou des liens ajoutés entres pages.
79. Système selon la revendication 78, caractérisé en ce que lesdits liens vers des pages constituent lesdits marque-pages.
80. Système selon l'une des revendications 65 à 79, caractérisé en ce qu'il comprend des moyens pour mémoriser, en association avec une pluralité d'utilisateurs de postes clients, une pluralité de tables de liens désignant, pour chaque page constituant une extrémité d'un lien créé, le ou chacun de ces liens.
81. Système selon la revendication 80, caractérisé en ce que les moyens de création de liens sont aptes à être commandés par des moyens de traitement comparatif de ladite pluralité de tables de liens, pour créer des liens dans un état dit suggéré.
82. Système selon la revendication 81, caractérisé en ce qu'il comprend des moyens pour afficher des éléments affichés représentant chaque lien créé dans ledit état suggéré et, en association avec chacun desdits éléments, des moyens sensibles à un dispositif d'entrée pour modifier l'état du lien correspondant.
83. Système selon la revendication 82, caractérisé en ce que les moyens de modification de l'état d'un lien créé dans l'état suggéré comprennent des moyens pour supprimer le lien.
84. Système selon l'une des revendications 82 et 83, caractérisé en ce que les moyens de modification de l'état d'un lien créé dans l'état suggéré comprennent des moyens pour valider le lien en l'amenant dans un état accepté.
85. Système selon l'une des revendications 82 à 84, caractérisé en ce que les moyens de modification de l'état d'un lien dans l'état suggéré ou accepté comprennent des moyens pour valider le lien en l'amenant dans un état gelé.
86. Système selon la revendication 85, caractérisé en ce qu'il comprend en outre des moyens pour ajuster chaque lien amené à l'état gelé sur une adresse à laquelle le contenu de la page a été mémorisé.
87. Système selon l'une des revendications 84 à 86, caractérisé en ce qu'il comprend en outre des moyens capables, sous la commande de l'utilisateur, d'affecter à tout lien accepté ou gelé un attribut de caractérisation du type d'intérêt porté par l'utilisateur au contenu désigné par ledit lien.
88. Système selon la revendication 87, caractérisé en ce que les attributs de caractérisation comprennent un attribut « Offreur » et un attribut « Demandeur ».
89. Système selon l'une desdites revendications 87 et 88, caractérisé en ce que lesdits moyens de traitement comparatif sont aptes à prendre en compte les attributs de caractérisation donnés aux liens.
90. Système selon l'une des revendications 87 à 89, caractérisé en ce qu'il comprend, en association avec chaque élément affiché représentant un lien créé, un moyen de codage graphique pour désigner l'état dudit lien.
91. Système selon la revendication 90, caractérisé en ce que le moyen de codage graphique comprend un codage de couleur dans un cadre entourant ledit élément affiché.
92. Système selon l'une des revendications 81 à 91, caractérisé en ce qu'il comprend en outre des moyens commandés par l'utilisateur pour paramétrer le traitement comparatif effectué sur ladite pluralité de tables de liens.
93. Système selon la revendication 92, caractérisé en ce que les moyens de paramétrage commandés par l'utilisateur comprennent des moyens de sélection des utilisateurs pour les tables de liens desquels le traitement comparatif est effectué.
94. Système selon l'une des revendications 81 à 93, caractérisé en ce que lesdits moyens de traitement comparatif opèrent sur une pluralité de tables de liens contenant seulement les liens créés validés.
95. Système selon l'une des revendications 66 à 73, caractérisé en ce qu'il comprend des moyens pour suggérer à un utilisateur, en association avec l'accès à une première page, un lien ajouté bidirectionnel avec une seconde page, ladite seconde page étant choisie par ledit système en fonction notamment de sa pertinence pour l'utilisateur au regard de la première page de telle manière que lors de l'accès ladite seconde page, le lien ajouté inverse, de ladite seconde page vers ladite première page, puisse être activé par l'utilisateur.
96. Système selon la revendication 95, caractérisé en ce que ladite seconde page est choisie par le système également en fonction de la fréquence d'accès à celle-ci par l'utilisateur.
97. Système selon l'une des revendications 95 et 96, caractérisé en ce que ladite seconde page est choisie par le système également en fonction du nombre de liens ajoutés préexistants associés à ladite seconde page.
98. Système selon l'une des revendications 95 à 97, caractérisé en ce qu'il comprend des moyens de traitement de ladite seconde page de manière à y inclure une élément d'affichage dudit lien inverse.
99. Système selon la revendication 98, caractérisé en ce que les moyens de traitement sont paramétrables.
100. Système selon l'une des revendications 98 et 99, caractérisé en ce que les moyens de traitement sont aptes à inclure ledit élément d'affichage du lien inverse en un emplacement de la seconde page normalement destiné à comporter un bandeau publicitaire ou analogue.
101. Système selon la revendication 65, caractérisé en ce qu'il comprend en outre des moyens de sélection par l'utilisateur de groupes extérieurs de liens et en ce que les moyens de sélection et d'affichage sont également aptes, lors de l'affichage d'une page, à afficher les liens d'au moins un groupe extérieur de liens sélectionné.
102. Système selon la revendication 101, caractérisé en ce que les groupes extérieurs de liens comprennent au moins l'un parmi :
- des groupes de liens présélectionnés par un administrateur de la page,
- des groupes de liens présélectionnés par le système comme étant proches d'au moins un groupe de liens propre à l'utilisateur,
- des groupes de liens établis par le système comme étant pertinents vis-à-vis d'au moins un groupe de liens propre à l'utilisateur, et - des groupes de liens présélectionnés par l'utilisateur.
103. Système selon la revendication 65, caractérisé en ce que lesdits liens sont situés dans des contenants définis dans la structure de la page courante, et pointent vers des contenus aptes à enrichir ladite page courante en des emplacements définis par la position desdits contenants dans ladite structure.
104. Système de navigation mis en œuvre dans un système informatique pour accéder au niveau d'un poste client à des pages fournies notamment par des serveurs via un réseau informatique par activation de liens, caractérisé en ce qu'il comprend en combinaison : des moyens de détection de l'existence d'un lien d'une page d'origine consultée vers une page de destination consultée, des moyens de mémorisation d'une information d'identification de ladite page de destination consultée et, en association avec ladite information d'identification, d'une information d'identification de ladite page d'origine consultée, et des moyens d'affichage de liens inverses aptes, lorsqu'un poste client connecté au système accède ladite page de destination, à utiliser l'information d'identification de ladite page de destination pour retrouver dans lesdits moyens de mémorisation l'information d'identification de ladite page d'origine et pour afficher sur le poste client en association avec ladite page de destination, un élément activable constituant un lien vers ladite page d'origine.
105. Système selon la revendication 104, caractérisé en ce que les moyens de détection sont aptes à détecter une action de souris sur un lien vers ladite page de destination, contenu dans la page d'origine consultée ou associé à elle.
106. Système selon l'une des revendications 104 et 105, caractérisé en ce que les moyens d'affichage de liens inverses sont aptes à afficher sur le poste client une pluralité d'éléments activables constituant des liens vers une pluralité de pages d'origine différentes.
107. Système selon la revendication 106, caractérisé en ce que les moyens d'affichage de liens inverses sont aptes à n'afficher que des éléments activables constituant des liens vers des pages sélectionnées pour leurs caractéristiques de contenu par rapport à un profil de l'utilisateur du poste client.
108. Système selon l'une des revendications 104 à 107, caractérisé en ce que les moyens de mémorisation sont aptes à mémoriser des informations d'identification de pages d'origine en association avec des informations d'identification de pages de destination sur une base utilisateur par utilisateur, et en ce que les moyens d'affichage de liens inverses sont aptes à retrouver dans lesdits moyens de mémorisation les informations d'identification des pages d'origine en utilisant également une information d'identification de l'utilisateur.
109. Système selon la revendication 108, caractérisé en ce que les moyens de mémorisation sont aptes à mémoriser, pour chaque utilisateur qui consulte une page de destination par l'activation d'un lien associé à une page d'origine, l'information d'identification de ladite page d'origine en association avec l'information d'identification de ladite page de destination et ladite information d'identification de l'utilisateur.
110. Système selon l'une des revendications 104 à 109, caractérisé en ce qu'il comprend en outre des moyens de suppression aptes, au moins lors du premier affichage d'éléments activables, à supprimer à l'initiative de l'utilisateur l'affichage d'au moins un élément activable.
111. Système selon les revendications 109 et 110 prises en combinaison, caractérisé en ce qu'il est prévu des moyens aptes, lors de la suppression d'un élément activable par l'utilisateur, à supprimer, dans les moyens de mémorisation, l'information d'identification de la page d'origine concernée par ledit élément activable en association avec l'information d'identification de la page de destination.
112. Système selon la revendication 111, caractérisé en ce que les moyens d'affichage de liens inverses sont aptes à afficher dans un état suggéré les éléments activables des liens correspondants vers les pages d'origine, et en ce qu'il est prévu en outre des moyens de modification d'état aptes, lors de chaque affichage d'un élément activable dans l'état suggéré, à faire passer à l'intiative de l'utilisateur ledit élément activable dans un état accepté ou dans un état refusé.
113. Système selon la revendication 112, caractérisé en ce que les moyens de modification d'état sont également aptes à faire passer à l'intiative de l'utilisateur le lien correspondant dans un état gelé, et en ce qu'il est prévu des moyens pour mémoriser la page d'origine correspondante dans son état courant et pour permettre l'accès à ladite page d'origine mémorisée dans son état courant à partir de l'élément activable correspondant.
114. Système selon l'une des revendications 104 à 113, caractérisé en ce que les moyens d'affichage de liens inverses sont aptes à afficher les éléments activables dans au moins une zone d'affichage contenue dans la page de destination.
115. Système selon l'une des revendications 104 à 113, caractérisé en ce que les moyens d'affichage de liens inverses sont aptes à afficher les éléments activables de façon adjacente à une zone d'affichage occupée par la page de destination.
116. Système selon l'une des revendications 104 à 115, caractérisé en ce que lesdits éléments activables sont constitués par des représentations miniaturisées des pages d'origine correspondantes.
117. Système selon l'une des revendications 104 à 116, caractérisé en ce que les moyens d'affichage sont également aptes à afficher, en association avec ladite page de destination consultée, une pluralité d'éléments activables constituant une pluralité de liens qui étaient associés à la page d'origine.
118. Système selon la revendication 117, caractérisé en ce que les moyens d'affichage sont également aptes à afficher, en association avec une autre page consultée par activation de l'un des éléments activables de ladite pluralité, un élément activable constituant un lien vers ladite page d'origine.
119. Système selon la revendication 104, caractérisé en ce que les moyens de détection de liens sont aptes à détecter l'existence d'un lien d'une page d'origine vers une page de destination via une ou plusieurs pages intermédiaires.
120. Procédé de navigation mis en œuvre dans un poste informatique client pour accéder à des pages fournies notamment par des serveurs via un réseau informatique par activation de liens et pour afficher lesdites pages, caractérisé en ce qu'il comprend les étapes suivantes :
- lors de la consultation d'une page courante, la consultation locale ou à distance de moyens de mémorisation d'une table de liens inverses contenant, en association avec une information d'identification de ladite page courante, des informations d'identification d'une ou plusieurs pages sources possédant des liens vers ladite page courante, et
- des moyens d'affichage de liens inverses aptes, à partir desdites informations d'identification consultées, à afficher en association avec l'affichage de ladite page courante des éléments activables constituant autant de liens vers la ou les pages sources.
121. Procédé selon la revendication 120, caractérisé en ce que les informations d'identification des pages sources dans ladite table de liens inverses sont déterminées par la détection préalable d'une action de souris, dans une page source, sur un lien vers ladite page courante.
122. Procédé selon l'une des revendications 120 et 121, caractérisé en ce qu'il comprend en outre une étape de sélection, parmi les pages sources désignées par lesdites informations d'identification de pages sources, des seules pages sources possédant des caractéristiques de contenu déterminées par rapport à un profil de l'utilisateur du poste client, et en ce que l'étape d'affichage comprend l'affichage des seuls éléments activables constituant des liens vers lesdites pages sources sélectionnées.
123. Procédé selon l'une des revendications 120 à 122, caractérisé en ce que les moyens de mémorisation comprennent une pluralité de tables de liens inverses identifiées, correspondant à une pluralité d'utilisateurs, et en ce que l'étape de consultation des moyens de mémorisation s'effectue en utilisant une information d'identification de l'utilisateur.
124. Procédé selon l'une des revendications 120 à 122, caractérisé en ce que les moyens de mémorisation comprennent une table de liens unique contenant des informations d'identification de pages sources en association avec l'information d'identification de ladite page courante et avec une information d'identification de l'utilisateur.
125. Procédé selon l'une des revendications 123 et 124, caractérisé en ce que les moyens de mémorisation sont contenus dans un serveur accessible par réseau à partir du poste client.
126. Procédé selon l'une des revendications 120 à 125, caractérisé en ce qu'il comprend en outre une étape de suppression apte, au moins lors du premier affichage d'un élément activable, à supprimer à l'initiative de l'utilisateur l'affichage dudit élément activable.
127. Procédé selon les revendication 126 prise en combinaison avec l'une des revendication 20 à 22, caractérisé en ce que l'étape de suppression comprend, lors de la suppression d'un élément activable par l'utilisateur, la suppression, dans les moyens de mémorisation, de l'information d'identification de la page source concernée par ledit élément activable en association avec l'information d'identification de la page courante pour l'utilisateur considéré.
128. Procédé selon la revendication 127, caractérisé en ce que l'étape d'affichage de liens inverses comprend l'affichage dans un état suggéré des éléments activables des liens correspondants vers les pages sources, et en ce qu'il comprend en outre une étape de modification d'état de lien inverse pour, lors de chaque affichage d'un élément activable dans l'état suggéré, faire passer à l'intiative de l'utilisateur ledit élément activable dans un état accepté ou dans un état refusé.
129. Procédé selon la revendication 128, caractérisé en ce que l'étape de modification d'état de lien inverse comprend également le passage, à l'intiative de l'utilisateur, du lien correspondant dans un état gelé, et en ce qu'il comprend en outre une étape de mémorisation du contenu de la page source correspondante dans son état courant, pour permettre l'accès à ladite page source mémorisée dans son état courant à partir de l'élément activable correspondant.
130. Procédé selon l'une des revendications 120 à 129, caractérisé en ce que l'étape d'affichage de liens inverses comprend l'affichage des éléments activables dans au moins une zone d'affichage contenue dans la page courante.
131. Procédé selon l'une des revendications 120 à 129, caractérisé en ce que l'étape d'affichage de liens inverses comprend l'affichage des éléments activables de façon adjacente à une zone d'affichage occupée par la page courante.
132. Procédé selon l'une des revendications 120 à 131, caractérisé en ce que lesdits éléments activables sont constitués par des représentations miniaturisées des pages d'origine correspondantes.
133. Procédé selon l'une des revendications 120 à 132, caractérisé en ce que l'étape d'affichage comprend également l'affichage, en association avec ladite page courante, d'une pluralité d'éléments activables constituant une pluralité de liens qui étaient associés à au moins une page en amont de la page courante.
134. Procédé selon l'une des revendications 120 à 133, caractérisé en ce que l'étape d'affichage comprend également l'affichage, en association avec ladite page courante, d'une pluralité d'éléments activables constituant une pluralité de liens vers des pages vers lesquelles pointent des liens contenus dans au moins une page en amont de la page courante.
135. Procédé selon la revendication 120, caractérisé en ce que les moyens de mémorisation comprennent en outre une information d'identification d'au moins une page source de niveau supérieur, contenant un lien direct, ou par l'intermédiaire d'au moins une autre page, vers au moins l'une des pages sources identifiées en association avec la page courante, et en ce que l'étape d'affichage comprend l'affichage d'éléments activables constituant autant de liens vers les pages sources de niveau supérieur.
136. Système de navigation mis en œuvre dans un système informatique pour accéder au niveau d'un poste client à des pages fournies notamment par des serveurs via un réseau informatique, caractérisé en ce qu'il comprend en combinaison :
- des moyens pour afficher une page courante,
- des moyens pour sélectionner et afficher en sus de la page courante au moins une liste d'options d'ajout d'informations en association avec ladite page, à chaque option d'ajout étant associées des données de localisation d'un ensemble d'informations contenant les informations à ajouter,
- des moyens d'entrée permettant à l'utilisateur de sélectivement activer ou inactiver chacune desdites options,
- des moyens de retraitement aptes, pour chaque option activée, à localiser l'ensemble d'informations de la ou de chaque option activée à partir desdites données de localisation et à en extraire les informations à ajouter, et
- des moyens pour afficher la page complétée par la ou lesdites informations à ajouter.
137. Système selon la revendication 136, caractérisé en ce que lesdites informations à ajouter sont constituées par des liens de la page courante vers d'autres pages.
138. Système selon la revendication 137, caractérisé en ce que les moyens d'affichage sont aptes à afficher lesdits liens à l'extérieur de la page courante.
139. Système selon la revendication 137, caractérisé en ce que les moyens d'affichage sont aptes à afficher lesdits liens en superposition sur la page courante.
140. Système selon la revendication 139, caractérisé en ce que les moyens d'affichage sont aptes à afficher lesdits liens dans au moins un emplacement de la page constitué par une zone réservée prévue à l'origine dans la page courante.
141. Système selon la revendication 140, caractérisé en ce que ladite zone réservée est une zone de publicité.
142. Système selon la revendication 136, caractérisé en ce que lesdites informations à ajouter sont constituées par des liens situés à des emplacements prédéterminés de la page courante et pointant vers des contenus additionnels pour ladite page.
143. Système selon la revendication 142, caractérisé en ce que la page courante contient un code de présentation desdits contenus additionnels.
144. Système selon l'une des revendications 136 à 143, caractérisé en ce qu'il est prévu une liste d'options définies à partir de paramètres de sélection fournis par l'auteur de la page courante.
145. Système selon la revendication 144, caractérisé en ce que au moins l'une des options est sélectionnée par défaut à l'initiative de l'auteur de la page courante.
146. Système selon l'une des revendications 136 à 143, caractérisé en ce qu'il est prévu une liste d'options définies, à partir d'un traitement de comparaison entre un profil de l'utilisateur du poste client et une pluralité de profils publics d'autres utilisateurs, comme étant issues de profils proches.
147. Système selon l'une des revendications 136 à 143, caractérisé en ce qu'il est prévu une liste d'options définies à partir de paramètres de sélection fournis par l'utilisateur.
148. Système selon la revendication 147, caractérisé en ce qu'au moins l'une des options est sélectionnée par défaut dans le cas où ladite page courante a été émise vers le poste client par un utilisateur auquel est associée ladite option.
149. Système selon l'une des revendications 136 à 148, caractérisé en ce que la ou chaque liste d'options contient une liste de désignations des sources desdites options telles que d'autres utilisateurs.
150. Système selon l'une des revendications 136 à 149, caractérisé en ce que les moyens de sélection et d'affichage de listes d'options comprennent des moyens pour sélectionner des options sur la base d'attributs de caractérisation du type d'intérêt porté par les sources desdites options à la page courante.
151. Système selon la revendication 150, caractérisé en ce que lesdits attributs comprennent un attribut « Offreur » et un attribut « Demandeur ».
152. Système selon l'une des revendications 136 à 151, caractérisé en ce qu'il comprend en outre des moyens de mise en communication d'un utilisateur dudit poste client avec des utilisateurs qui sont les sources desdites options d'ajout.
153. Système selon l'une des revendications 136 à 152, caractérisé en ce qu'il comprend en outre des moyens d'agrégation d'informations à ajouter associées à au moins deux options d'ajout différentes.
154. Procédé d'enrichissement sélectif de graphes à partir d'un ensemble de graphes comprenant chacun une pluralité de nœuds constitués par des ensembles d'informations tels que des pages, reliés entre eux par des arcs constitués par des liens entre lesdites pages, deux nœuds reliés par un arc constituant des nœuds voisins, à chaque graphe étant associée une première structure de chemin d'accès aux nœuds du graphe et, à chaque nœud contenu dans au moins un graphe étant associée une seconde structure de chemin d'accès aux graphes contenant ce nœud, caractérisé en ce qu'il comprend les étapes suivantes :
(a) à partir de l'identification d'un nœud donné d'un premier graphe associé à un utilisateur et de l'identification des voisins dudit nœud, identifier en utilisant les première et seconde structures de chemin d'accès tous les graphes contenant ledit nœud donné et un ensemble de nœuds voisins présentant un degré de similitude le plus élevé avec les nœuds voisins du premier graphe, et
(b) afficher sur un poste client accessible par ledit utilisateur du premier graphe les nœuds qui sont des voisins dudit nœud donné dans chacun desdits graphes identifiés sélectionnés et qui ne sont pas des voisins dudit nœud donné dans le premier graphe, en vue de leur ajout dans ledit premier graphe.
155. Procédé selon la revendication 154, caractérisé en ce que l'étape (a) comprend les sous- étapes suivantes :
(al), à partir d'un critère comprenant au moins l'identification d'un nœud donné d'un premier graphe associé à un utilisateur, identifier en utilisant la seconde structure de chemin d'accès tous les graphes répondant à ce critère,
(a2) à partir de la première structure de chemin d'accès associée au premier graphe, identifier les nœuds voisins dudit nœud donné, (a3) pour chaque graphe identifié à la sous-étape (al), parcourir sa première structure de chemin d'accès pour identifier les nœuds voisins dudit nœud donné dans le graphe considéré,
(a4) comparer les nœuds voisins identifiés dans le premier graphe avec les nœuds voisins identifiés dans chacun des graphes identifiés, et
(a5) sélectionner le ou les graphes identifiés dont les nœuds voisins présentent un degré de similitude le plus élevé avec les nœuds voisins du premier graphe.
156. Procédé selon l'une des revendications 154 et 155, caractérisé en ce qu'à chaque noeud peut être affecté un attribut de caractérisation du type d'intérêt porté à l'ensemble d'informations dudit nœud en association avec le graphe considéré, et en ce que l'étape (a) est mise en œuvre sur les seuls graphes dont ledit nœud donné présente une valeur d'attribut de caractérisation prédéterminée.
157. Procédé selon la revendication 156 caractérisé en ce que lesdits attributs de caractérisation comprennent un attribut « Offreur » et un attribut « Demandeur ».
158. Procédé de recherche de profils voisins parmi une pluralité de profils non liés par une structuration commune et accessibles à partir d'un système de traitement, chaque profil étant défini par un ensemble d'informations et/ou d'identifiants de telles informations propres à un utilisateur donné, caractérisé en ce qu'il comprend les étapes suivantes :
- au niveau de chaque profil, affecter au moins certaines informations et/ou certains identifiants d'informations à des groupes choisis par l'utilisateur en fonction de ses propres centres d'intérêts, de façon indépendante des choix de groupes par les autres utilisateurs,
- à partir d'un jeu d'informations et/ou d'identifiants d'informations de départ appartenant à un même groupe d'un utilisateur, rechercher dans chacun desdits profils des jeux similaires d'informations ou identifiants, en ne considérant à chaque fois que les informations ou identifiants appartenant à un même groupe de l'utilisateur correspondant audit profil, en sélectionnant les profils pour lesquels la similitude entre jeux d'informations ou identifiants est la plus grande.
159. Procédé selon la revendication 158, caractérisé en ce qu'à chaque information et/ou identifiant d'information peut être affecté un attribut de caractérisation du type d'intérêt porté à ladite information en association avec le profil considéré, et en ce que ladite étape de recherche est mise en œuvre sur les seules informations qui présentent une valeur d'attribut de caractérisation prédéterminée.
160. Procédé selon la revendication 159, caractérisé en ce que lesdits attributs de caractérisation comprennent un attribut « Offreur » et un attribut « Demandeur ».
161. Procédé de recherche, parmi une pluralité d'éléments d'information, d'éléments d'information voisins d'un élément d'information donné, chaque élément d'information étant susceptible d'appartenir à une pluralité de profils non liés par une structuration commune et accessibles à partir d'un système de traitement, chaque profil étant défini par un ensemble de tels éléments d'informations et/ou d'identifiants de tels éléments d'informations propres à un utilisateur donné, caractérisé en ce qu'à chaque élément d'information est associée une liste de profils contenant ledit élément, et en ce qu'il comprend l'étape consistant à rechercher des éléments d'informations dont la liste de profils répond au mieux à un critère de similitude prédéterminé avec la liste de profils dudit élément d'information donné.
162. Procédé selon la revendication 161, caractérisé en ce qu'à chaque élément d'information peut être affecté un attribut de caractérisation du type d'intérêt porté audit élément d'information en association avec le profil considéré, et en ce que l'étape de recherche est mise en œuvre sur les seuls profils pour lesquels ledit élément d'information présente une valeur d'attribut de caractérisation prédéterminée.
163. Procédé selon la revendication 162, caractérisé en ce que lesdits attributs de caractérisation comprennent un attribut « Offreur » et un attribut « Demandeur ».
164. Serveur intermédiaire, apte à recevoir d'un poste client une requête de base normalement utilisée pour accéder directement à un serveur tiers et à rediriger une requête vers ledit serveur tiers, caractérisé en ce qu'il comprend des moyens pour :
- lors d'un accès d'un utilisateur à un serveur tiers via ledit serveur intermédiaire, au cours duquel une information provenant du serveur tiers est acceptée par l'utilisateur dans un contenant (récipient) déterminé, mémoriser en association avec ladite information une identification de catégorie propre à l'utilisateur, associée audit contenant,
- à chaque requête formée par un utilisateur auprès d'un serveur tiers via ledit serveur intermédiaire,
* identifier l'utilisateur adressant ladite requête,
* à partir des identifications de catégories précédemment mémorisées, construire une requête enrichie contenant ladite requête de base et un ou plusieurs valeurs de critères additionnels déduits desdites identifications de catégories, et
- adresser audit serveur tiers ladite requête enrichie.
165. Serveur selon la revendication 164, caractérisé en ce que, lorsque ladite requête concerne un contenu (lien ; fragment) destiné à être le cas échéant accepté dans un contenant donné, lesdits critères additionnels comprennent au moins une identification de catégorie d'un autre contenant associé audit contenu.
166. Serveur selon l'une des revendications 164 et 165, caractérisé en ce qu'il comprend en outre des moyens aptes, lorsque le serveur tiers délivre des informations brutes (XML) dissociées d'informations de présentation (XSLT, etc..) propres au serveur tiers, à appliquer auxdites informations brutes des informations de présentation autres que lesdites information de présentation propres au serveur tiers.
167. Procédé pour affecter des catégories à des contenus (fragments) accessibles par une pluralité d'utilisateurs, chaque contenu étant par ailleurs propre a être sélectivement placé dans une pluralité de contenants (récipients) appartenant à des structures de documents, ces contenants possédant chacun des informations de catégorie, et à chaque contenu pouvant être associé une pluralité d'informations de catégories permettant aux utilisateurs notamment de sélectivement accéder par un critère de catégorie audit contenu ou d'automatiser la sélection de la présentation dudit contenu, comprenant l'étape consistant, lorsqu'un contenu donné est placé dans un contenant donné d'un document, à ajouter aux informations de catégorie déjà associées audit contenu les informations de catégorie possédées par ledit contenant donné.
168. Procédé selon la revendication 167, caractérisé en ce que lesdites informations de catégories ajoutées aux contenus sont ajoutées en mode suggéré.
169. Procédé pour déterminer un degré de proximité entre contenus dans un ensemble de N contenus tels que des pages accessibles par liens sur un réseau tel que l'Internet, notamment à des fins de catégorisation desdits contenus, chaque contenu étant accessible par une pluralité d'utilisateurs, caractérisé en ce qu'il comprend les étapes suivantes :
A) pour chaque contenu, mémoriser en association avec une pluralité d'utilisateurs susceptibles d'accéder audit contenu une pluralité d'informations de marques d'intérêt pour ledit contenu,
B) pour tout sous-ensemble de contenus appartenant audit ensemble et constitué par un nombre de contenus compris entre 1 et N, calculer à partir desdites informations de marque d'intérêt, une valeur au moins approximativement représentative de la probabilité pour qu'un utilisateur porte une marque d'intérêt au contenu ou à l'un quelconque au moins des contenus du sous-ensemble, et C) calculer à partir desdites valeurs un coefficient de proximité entre les contenus de l'ensemble.
170. Procédé selon la revendication 169, caractérisé en ce que l'étape B) comprend, pour tout sous-ensemble de 1 à N contenus, le calcul d'une probabilité pour qu'un utilisateur ne porte de marque d'intérêt à aucun des contenus du sous-ensemble, et en ce que l'étape C) comprend le calcul d'un rapport entre le produit des probabilités obtenues pour tous les sous-ensemble ayant un nombre impair de contenus et le produit des probabilités obtenues pour tous les sous- ensembles ayant un nombre pair de contenus.
171. Procédé selon la revendication 170, caractérisé en ce que chaque coefficient de proximité est égal à 1 diminué de la valeur dudit rapport.
172. Procédé selon la revendication 169, caractérisé en ce que le calcul de la valeur représentative de la probabilité pour qu'un utilisateur porte une marque d'intérêt à l'un quelconque au moins des contenus du sous-ensemble met en jeu la probabilité pour qu'un utilisateur porte une marque d'intérêt à chacun des contenus du sous-ensemble.
173. Procédé selon l'une des revendications 169 à 172, caractérisé en ce qu'au moins certains contenus dudit ensemble sont susceptibles d'être atteints par au moins un lien prévu dans au moins un parmi une pluralité de contenus routeurs, et en ce que les informations de marques d'intérêt d'utilisateur pour un tel contenu sont constitués par la présence ou non de liens dans ladite pluralité de contenus routeurs vers ce contenu.
174. Procédé pour déterminer si un premier groupe d'un ou de plusieurs contenus est susceptible de se voir affecter une même information de catégorie qu'un second groupe d'un ou de plusieurs contenus au(x)quel(s) est déjà affectée une même information de catégorie, caractérisé en ce qu'il comprend la mise en œuvre du procédé selon l'une des revendications 169 à 173 sur l'ensemble constitué par les contenus du premier groupe et au moins certains contenus du second groupe, et l'affectation ou non de ladite information de catégorie au(x) contenu(s) du premier groupe en fonction notamment de la valeur du coefficient de proximité obtenu.
175. Procédé pour affecter une information de catégorie à un ou plusieurs contenus d'un premier groupe, caractérisé en ce qu'il comprend la mise en œuvre répétée du procédé selon la revendication 174 sur des ensembles constitués par le ou les contenus du premier groupe et des contenus appartenant à d'autres groupes et auxquels sont affectés à chaque fois une information de catégorie commune, et l'affectation au(x) contenu(s) du premier groupe d'au moins une information de catégorie en fonction des différents coefficients de proximité obtenus.
PCT/FR2001/001731 2000-06-06 2001-06-05 Systeme et procede permettant l'importation semi-automatique de fragments de ressources d'informations WO2001095146A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2001295651A AU2001295651A1 (en) 2000-10-02 2001-10-02 Method for monitoring information resources on a network
PCT/FR2001/003043 WO2002029625A2 (fr) 2000-10-02 2001-10-02 Procede de surveillance de ressources d'information sur un reseau

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
FR0007254 2000-06-06
FR0007245A FR2805374B1 (fr) 1999-11-10 2000-06-06 Systeme de navigation mis en oeuvre dans un systeme informatique pour acceder a des pages fournies par des serveurs via un reseau informatique
FR0007252A FR2805376B1 (fr) 1999-11-10 2000-06-06 Procede d'enrichissement selectif de graphes contenant a leurs noeuds des ensembles informations
FR00/07251 2000-06-06
FR00/07252 2000-06-06
FR00/07254 2000-06-06
FR00/07245 2000-06-06
FR0007251 2000-06-06
FR0007815 2000-06-19
FR00/07815 2000-06-19
FRPCT/FR00/03157 2000-11-10
PCT/FR2000/003157 WO2001035269A2 (fr) 1999-11-10 2000-11-10 Systeme de partage d'informations entre au moins deux utilisateurs sur un reseau informatique
FR0017325 2000-12-29
FR00/17325 2000-12-29

Publications (2)

Publication Number Publication Date
WO2001095146A2 true WO2001095146A2 (fr) 2001-12-13
WO2001095146A3 WO2001095146A3 (fr) 2005-04-07

Family

ID=27546306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/001731 WO2001095146A2 (fr) 2000-06-06 2001-06-05 Systeme et procede permettant l'importation semi-automatique de fragments de ressources d'informations

Country Status (1)

Country Link
WO (1) WO2001095146A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003100548A2 (fr) * 2002-05-23 2003-12-04 Koninklijke Philips Electronics N.V. Langage de balisage dynamique
WO2005045698A2 (fr) 2003-10-24 2005-05-19 Enrico Maim Procede mis en oeuvre dans un environnement informatique pour engendrer une vue courante a partir d’au moins un objet d’information source susceptible de varier
WO2006108865A2 (fr) 2005-04-12 2006-10-19 Enrico Maim Procedes pour permettre l'acces a des ressources modifiables par des utilisateurs dans un environnement informatique, et ressources structurees a cet effet

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GRONBAEK K ET AL: "Open hypermedia as user controlled meta data for the Web" COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 33, no. 1-6, juin 2000 (2000-06), pages 553-566, XP004304791 ISSN: 1389-1286 *
INTERNATIONAL BUSINESS MACHINES CORPORATION: "XML element forms: building blocks of XML-based applications" RESEARCH DISCLOSURE, KENNETH MASON PUBLICATIONS, HAMPSHIRE, GB, vol. 428, no. 95, décembre 1999 (1999-12), pages 1-3, XP007125195 ISSN: 0374-4353 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003100548A2 (fr) * 2002-05-23 2003-12-04 Koninklijke Philips Electronics N.V. Langage de balisage dynamique
WO2003100548A3 (fr) * 2002-05-23 2004-05-21 Koninkl Philips Electronics Nv Langage de balisage dynamique
CN100465948C (zh) * 2002-05-23 2009-03-04 皇家飞利浦电子股份有限公司 动态标记语言
WO2005045698A2 (fr) 2003-10-24 2005-05-19 Enrico Maim Procede mis en oeuvre dans un environnement informatique pour engendrer une vue courante a partir d’au moins un objet d’information source susceptible de varier
EP1719061A2 (fr) * 2003-10-24 2006-11-08 Enrico Maim Procédé mis en oeuvre dans un environnement informatique pour engendrer une vue courante à partir d'au moins un objet d'information source susceptible de varier
WO2006108865A2 (fr) 2005-04-12 2006-10-19 Enrico Maim Procedes pour permettre l'acces a des ressources modifiables par des utilisateurs dans un environnement informatique, et ressources structurees a cet effet
WO2006108865A3 (fr) * 2005-04-12 2007-06-28 Enrico Maim Procedes pour permettre l'acces a des ressources modifiables par des utilisateurs dans un environnement informatique, et ressources structurees a cet effet
US8442996B2 (en) 2005-04-12 2013-05-14 Enrico Maim Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefore
US9076015B2 (en) 2005-04-12 2015-07-07 Enrico Maim Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefore

Also Published As

Publication number Publication date
WO2001095146A3 (fr) 2005-04-07

Similar Documents

Publication Publication Date Title
Anandhan et al. Social media recommender systems: review and open research issues
US20220075812A1 (en) Using content
EP1719061A2 (fr) Procédé mis en oeuvre dans un environnement informatique pour engendrer une vue courante à partir d&#39;au moins un objet d&#39;information source susceptible de varier
Vossen et al. Unleashing Web 2.0: From concepts to creativity
Bonzanini Mastering social media mining with Python
Gretarsson et al. Smallworlds: visualizing social recommendations
EP1470501B1 (fr) Procedes et systemes de recherche et d&#39;association de ressources d&#39;information telles que des pages web
WO2006108865A2 (fr) Procedes pour permettre l&#39;acces a des ressources modifiables par des utilisateurs dans un environnement informatique, et ressources structurees a cet effet
FR3043816B1 (fr) Procede de suggestion de contenus extraits d’un ensemble de sources d’information
KR101593991B1 (ko) 컨텐트 추천 방법 및 그 장치
WO2001035269A2 (fr) Systeme de partage d&#39;informations entre au moins deux utilisateurs sur un reseau informatique
Chatterjee et al. Python social media analytics
WO2016198635A1 (fr) Gestion de noms de domaine du reseau internet
Liu et al. Selenite: Scaffolding decision making with comprehensive overviews elicited from large language models
WO2001095146A2 (fr) Systeme et procede permettant l&#39;importation semi-automatique de fragments de ressources d&#39;informations
Medynskiy et al. Exploring websites through contextual facets
Vossen et al. From Version 1.0 to Version 2.0: A brief history of the web
Yadav et al. Social Network with Web Crawler & Cluster
FR2806184A1 (fr) Systeme de navigation mis en oeuvre dans un systeme informatique pour acceder a des pages fournies par des serveurs via un reseau informatique
Jäschke et al. Organizing Publications and Bookmarks in BibSonomy.
FR2807182A1 (fr) Systeme de traitement de donnees oriente objet a chargement progressif
Yu et al. Social networks and the semantic Web
Potnis Folksonomy-based User-centric Information Organization Systems
FR2807180A1 (fr) Procede et systeme de gestion, dans un poste informatique, de l&#39;affichage d&#39;elements d&#39;affichage, notamment d&#39;elements charges depuis un poste distant
Opirskyi et al. Topological Approach to Wikipedia Page Recommendation

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP