FR 2806184 A1 20010914 FR 0017327 A 20001229 La présente invention concerne d'une façon générale un systèmes 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. Elle concerne plus précisément 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 , 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. Il existe par ailleurs 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. La présente invention a pour objet d'enrichir significativement, et le cas échéant sélectivement, les possibilités de navigation par exemple d'un internaute, et 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. 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 deuxième aspect, la présente invention propose un p rocé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. 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 limitatifet faite en référence aux dessins annexés. Introduction de la description On va présenter dans la suite dans quatre chapitres, différents systèmes et procédés liés entre eux. Le chapitre 1 vise en particulier des perfectionnements à la gestion de l'affichage sur écran d'éléments graphiques tels que des pages de la Toile, des parties de pages ou encore des fenêtres d'un système d'exploitation, dans différentes circonstances telles que le chargement de pages ou des opérations de glisser-déposer. Le chapitre II vise, en utilisant notamment la gestion d'affichage du chapitre 1, à permettre à un utilisateur de créer des liens personnels entre des pages de la Toile, et vise également différentes techniques pour mettre à profit ces liens créés. Le chapitre III vise, en utilisant notamment les techniques de liens créés du chapitre II, différentes techniques d'enrichissement mutuel des connaissances notamment via l'Internet. Il reprend à cet égard des notions exposées dans le chapitre II et les généralise. Le chapitre IV présente un procédé et système permettant d'effectuer des manipulations sur des documens et mettant en #uvre les techniques présentés dans les chapitres précédents. Chapitre 1 - Gestion de zones d'affichage superposées (Fig 1-27) En référence tout d'abord à la figure 1, on a représenté schématiquement une page interactive P, telle qu'une page en langage HTML, qui doit être chargée sur un réseau lent et/ou irrégulier tel que l'Internet, et qui est volumineuse (quelques dizaines de Kilo-octets, voire plus de cent Kilo-octet, ou même plus). Cette page est décomposée en deux zones d'affichage Zl et Z2 couvrant ensemble, typiquement, une fenêtre d'un logiciel de navigation sur Internet. Dans l'exemple de la figure 1, un élément de page E2 est chargé dans la zone Zl, tandis qu'un élément de page E5 est chargé dans la zone Z2. L'une de ces zones (la zone Zl en l'occurrence) est définie comme pouvant tolérer le recouvrement de l'affichage de la page P par l'affichage d'éléments externes. Autrement dit, la décomposition en zones permet de distinguer une zone (Zl) dans laquelle l'affichage de l'élément courant (l'élément E2) peut être recouvert (entièrement ou partiellement) par l'affichage d'un (ou plusieurs) éléments qui n'appartiennent pas à la page interactive P. Bien entendu, les zones en question pourraient être de n'importe quelle forme, et constituées de parties (sous-zones) contiguës ou non. Selon la présente invention, on vise à faire patienter l'utilisateur pendant le chargement de la page interactive, l'idée de base consistant à lui présenter au préalable un élément supplémentaire (élément El dans les schémas qui suivront) dont la caractéristique essentielle est d'être légère en termes de volume de données à transmettre, en étant par exemple constituée d'un simple texte introductif, c'est-à-dire très rapidement chargeable. La figure 2 illustre l'élément El affiché dans la zone Zl après avoir été chargé. L'affichage de cet élément El est effectuée dans la zone Zl afin de pouvoir recouvrir par la suite l'affichage de certains éléments de la page interactive (et plus précisément l'élément E2) quand ceux-ci seront chargés. On va maintenant décrire un certain nombre de détails de mise en oeuvre concrète de l'invention. Section 1- Stabilité de l'affichage de l'élément El La durée de chargement cumulée des éléments E2 et E5 destinés à constituer la page P n'étant pas exactement prévisible, et par ailleurs la durée nécessaire à l'examen complet par l'utilisateur du contenu de l'élément El - c'est-à-dire la durée de lecture du texte qu'il contient - étant dépendante des capacités et de l'attention de l'utilisateur, il est avantageux que l'élément El reste affiché jusqu'à que l'utilisateur l'ôte de sa propre initiative. Il est en effet désagréable pour l'utilisateur de se voir tout à coup privé d'un texte il est en train de lire. L'approche adoptée, qui va maintenant être décrite plus en détail en référence à la figure 3, est la suivante : dès la fin du chargement des éléments E2 et E5 initialement nécessaires à l'exécution de la page interactive P, tout ou partie de la zone Zl dans laquelle doit être affiché l'élément El sert de zone sensible , de manière à ce que, quand le pointeur d'une souris (ou tout autre périphérique d'entrée de la machine constituant un dispositif de pointage) entre dans cette zone Zl (et sans qu'un clic de souris ne soit nécessaire), l'affichage de l'élément El est automatiquement remplacé par celui de l'élément E2. On observera ici que l'on peut équiper la machine de moyens (bouton, fenêtre de dialogue ou autre) permettant alors à l'utilisateur de déclarer le cas échéant que par la suite, il ne souhaite plus voir l'élément El affiché. Ce moyen peut par exemple être un sous-élément d'interactivité dans E2 ou El. Section 2- Ré-affichage de l'élément El Sauf indication contraire explicitement donnée par l'utilisateur comme indiqué ci-dessus, on prévoit alors que l'utilisateur puisse retrouver ultérieurement l'élément El de sa propre initiative et le plus facilement possible, par exemple dans le cas où il l'aurait ôté par erreur. Or, après le remplacement de l'élément El par l'élément E2, puisque l'élément E2 doit offrir à l'utilisateur toutes ses propres possibilités d'interactivité (liens hypertexte, etc. ) dans la zone d'affichage Zl, il est avantageux que cette zone Zl ne serve pas à déclencher l'opération inverse, c'est-à-dire le remplacement de l'élément E2 par l'élément El. Pour satisfaire à cette contrainte, et comme illustré sur la figure 4, au moment où l'élément E2 est affiché, on prévoit que tout ou partie de la zone d'affichage Z2 dans laquelle est affiché l'élément E5 devienne à son tour zone sensible ; l'élément El pourra ainsi être ré-affiché dès la détection de l'entrée du pointeur dans cette zone. Toutefois, dès que l'élément El a été de nouveau affiché, il faut que l'élément E5 offre toutes ses propres possibilités d'interactivité. C'est alors, comme précédemment, tout ou partie de la zone Z1 (contenant alors l'élément El) qui redevient zone sensible. Ceci est illustré sur la figure 5. Les comportements des figures 4 et 5 peuvent, dans la présente forme de réalisation, être enchaînés à l'infini, aussi longtemps que l'utilisateur n'a pas appelé d'autres pages. Bien évidemment, tant E2 que El peuvent aussi posséder des sous-éléments d'interaction, constituant d'autres zones sensibles, pour respectivement amener et enlever l'élément El. On va maintenant décrire en détail différents déroulements du procédé selon l'invention. Cas 1 : Le pointeur de la souris se trouve initialement dans la zone Z2 Il s'agit du cas où, au moment où les éléments nécessaires à l'exécution initiale de la page interactive P sont finis d'être chargés, le pointeur de la souris se trouve dans la zone d'affichage qui ne contient pas l'élément El. Le déroulement du procédé est alors le suivant : - l'élément Elest chargé et affiché en premier, et reste affiché tant que les éléments nécessaires à l'exécution initiale de la page interactive P (à savoir les éléments E2 et E5) ne sont pas encore chargés ; - l'élément El reste affiché, même après chargement des éléments E2 et E5, tant que le pointeur actionné par la souris n'effectue pas une entrée dans la zone d'affichage Zl contenant l'élément El ; - c'est seulement lors d'une telle entrée qu'il est remplacé par les éléments E2 et E5 ; - au cas où le pointeur est ensuite amené dans la zone d'affichage Z2 qui ne contient pas l'élément E2, l'élément El est affiché à nouveau (E2 peut rester affiché ou pas). Cette séquence est présentée dans le diagramme de la figure 6. Cas 2 : Le pointeur de la souris se trouve initialement dans la zone Z1 Il s'agit du cas où, au moment où les éléments E2 et E5 nécessaires à l'exécution initiale de la page interactive P ont été chargés, le pointeur de la souris se trouve dans la zone d'affichage Z1 qui contient l'élément El. Dans ce cas l'élément El reste affiché aussi longtemps que le pointeur n'est pas sorti de la zone Zl, puis à nouveau entré dans celle-ci ; c'est seulement dans ce dernier cas que l'élément El est remplacé par les éléments E2 et E5 sur l'écran d'affichage. Cette séquence est présentée dans le diagramme de la figure 7. Approche dite de streaming Bien entendu, dans tous les cas, les éléments E2 et E5 de la page interactive P pourront être transmis dans une approche dite de streaming , approche classique dans laquelle des éléments d'une page sont affichés et exécutés avant que la page soit entièrement chargée. Il n'est en effet pas nécessaire d'attendre que la totalité de ces éléments de la page soient chargés pour activer la ou les zones sensibles . On va présenter ci-après une approche de streaming pour l'élément E1, qui dans le présent exemple est constitué par deux sous-éléments E 1.1et E 1.2. Plutôt que d'attendre la fin du chargement complet de l'élément El, les parties distinctes E1.1 et E1.2 de l'élément El(qui peuvent être par exemple principalement du texte) peuvent être chargées et affichées successivement, dans l'ordre de lecture. Le principe d'affichage des éléments en fonction des déplacements du pointeur de la souris peut rester identique, comme le présente le schéma de la figure 8. En variante, le comportement des différentes parties de l'élément El peuvent être dissociées, selon les règles énoncées ci-dessous et décrites en référence aux figures 9 à 12, sur lesquelles chaque fenêtre a pour but de montrer d'une part les nouveaux éléments affichés en réaction à l'action de déplacement du pointeur de la souris présentée dans la fenêtre immédiatement précédente, le cas échéant, d'autre part une nouvelle action de déplacement de la souris dont l'effet est montré dans la fenêtre suivante, le cas échéant : Règle 1 Il s'agit ici d'un simple rappel du principe déjà énoncé dans le paragraphe Cas 2 : Le pointeur de la souris se trouve initialement dans Z1 : Dans le cas où, au moment de la fin du chargement des éléments E2 et E5 de la page interactive P, le pointeur de la souris se trouve dans la zone Z1, les déplacements du pointeur n'ont pas d'effet tant que le pointeur n'est pas amené en dehors de la zone Zl (c'est-à-dire introduit dans la zone Z2) puis retourné ensuite dans la zone Z1. Ceci est illustré sur la figure 9. Règle 2 Le déplacement du pointeur de la souris, de la zone Z2 à la zone Zl, déclenche le remplacement de l'affichage du seul sous-élément touché par le sous-élément correspondant de la page interactive. Dans l'exemple illustré sur la figure 10, l'entrée du pointeur dans la région affectée au sous-élément E1.1 de l'élément Elprovoquera son remplacement par un sous-élément E2. 1 de l'élément E2, tandis que l'autre sous-élément E1.2 de l'élément El restera intact. Règle 3 Cette règle aborde la réversibilité du comportement défini par la règle 2 : le pointeur revient ensuite dans la zone Z2, même en étant passé par d'autres régions entre-temps, mais à condition d'avoir automatiquement défait les remplacements causés entre-temps, l'affichage de l'élément E2. 1 est remplacé par celui de l'élément E1.1. Ceci est illustré sur la figure 10. Les schémas des figures 11 et 12 présentent d'autres exemples de mise en #uvre de la réversibilité, tels que décrits ci-dessous : Règle Le déplacement du pointeur de la souris de la région occupée par le sous-élément E2. 1 à la région occupée par le sous-élément E1.2 déclenche le remplacement de l'affichage du sous- élément E1.2 par celui du sous-élément correspondant E2. 2 de la page interactive. Règle 5 Cette règle décrit une forme de réversibilité de la règle 4 : le pointeur retourne de la région du sous-élément E2. 2 à à la région du sous-élément E2. 1, même en étant passé par d'autres régions entre-temps mais à condition d'avoir automatiquement défait les remplacements causés entre-temps, l'affichage du sous-élément E2. 2 est remplacé par celui du sous-élément E1.2. Ceci est illustré sur la figure 11. Le schéma de la figure 12 présente une variante de mise en #uvre de la règle 5. Supposons qu'après le parcours suivant du pointeur de la souris : Z2 # E1.1(qui devient E2.1) -E1.2 (qui devient E2.2) le pointeur de la souris soit amené de la région occupée par le sous-élément E2. 2 jusque dans la zone Z2. Ceci, du fait qu'il ne s'agit pas un retour au sens de la Règle 3, n'engendre pas le remplacement du sous-élément E2. 2 par le sous-élément E 1.2. Règle 6 Cette règle consiste à rendre l'opération ci-dessus réversible : si le pointeur retourne de la zone Z2 à la région occupée par le sous-élément E2. 2, même en étant passé par d'autres zones entre-temps mais à condition d'avoir automatiquement défait les remplacements causés entre- temps et si le retour s'effectue avant un seuil temporel donné, l'opération est considérée comme étant défaite. Ceci est illustré sur la figure 12. Cette forme de réalisation permet avantageusement de ne plus appeler les sous-éléments constituant l'élément initial El lorsqu'une période de temps prédéterminée s'est écoulée pendant laquelle l'utilisateur est resté sur les sous-éléments de l'élément E2, ce qui est révélateur par exemple d'un début de travail de l'utilisateur sur l'élément E2. Section 3 - Exemples d'applications du présent chapitre Dans le cadre d'applications Internet ou autres, le procédé selon l'invention peut être complété par exemple par des éléments présentés dans le diagramme de la figure 13. Les informations portés par les éléments qui y sont représentés sont par exemple les suivantes : Elément El : texte (et le cas échéant image et/ou son, etc) introductif ou d'accueil, l'essentiel étant que sont chargement soit relativement rapide comparativement aux éléments E2 et E5 (constituant par exemple la page principale du site) ; Elément E3, occupant initialement la zone Z2 : par exemple un message au type Prière de patienter ; la page interactive est en train d'être chargée ; Elément E4, remplaçant l'élément E3 dans la zone Z2 : par exemple un message du type Le chargement minimal de la page interactive est terminé ; Elément E2 : la partie de la page principale occupant la zone Z 1 ; Elément E5 : la partie de la page principale occupant la zone Z2. L'homme du métier saura aisément mettre en #uvre l'invention dans une machine par exemple du type ordinateur personnel (au standard PC , MacOS (marque déposée), etc. ), comportant un processeur, des mémoires, et entrées/sorties, un écran d'affichage et une liaison avec un serveur délocalisé, ceci par exemple par programmation de routines appropriées en liaison avec le protocole de chargement des éléments depuis le serveur, sachant notamment que - la définition de zones sensibles pour un pointeur de souris ou analogue - la détection de la présence du pointeur dans ces zones, - la détection de fin de chargement de différentes pages HTML ou de leurs éléments individuels (textes, images, sons, etc.) constituent des outils classiques à disposition des développeurs. On peut par ailleurs apporter de nombreuses variantes à la présente invention. En premier lieu, on peut prévoir que la région dans laquelle va s'afficher l'élément initial El ne soit pas superposée exactement à la région dans laquelle va s'afficher l'élément E2 de la page principale. En particulier, la région occupée par l'élément El peut être plus petite que la région (zone Zl) dans laquelle s'affichera, dans les conditions définies plus haut, l'élément E2. Dans ce cas, la partie de la zone Zl non recouverte par la région occupée par l'élément El peut par exemple rester vierge aussi longtemps que l'élément E2 n'est pas affiché. Dans cette hypothèse, c'est avantageusement l'entrée du pointeur de la souris dans la seule région occupée par l'élément El qui provoquera le remplacement de l'élément El par l'élément E2. La région occupée par l' élément Elpeut aussi être plus grande que la région (zone Zl) dans laquelle s'affichera l'élément E2. Selon une autre variante, on peut prévoir que le rappel de l'affichage de l'élément El en lieu et place de l'élément E2 s'effectue non pas en amenant le pointeur de la souris dans la zone Z2, mais par toute autre action et notamment : - en amenant le pointeur de la souris (avec le cas échéant la nécessité d'un clic) dans un bouton, onglet, etc. affiché au voisinage de l'élément E2 lorsque ce dernier est affiché (ou encore appartenant à l'élément E2) ; - par appui sur une touche spécifique du clavier de la machine, - etc. On peut par ailleurs prévoir que les différents sous-éléments de l'élément initial El soient contigus ou non contigus. Au surplus, on peut recourir à différentes techniques de déplacement d'éléments pour retirer El de la zone d'affichage Zl (ou de la ou des régions qu'il occupe dans cette zone, le cas échéant) avec un effet visuel donné pour l'utilisateur. En particulier, on peut prévoir une translation horizontale ou verticale progressive de la représentation de l'élément El vers l'extérieur de l'écran. Egalement, on peut prévoir que l'élément El, après avoir été initialement affiché, soit recouvert par certains sous-éléments (boutons, etc. ) appartenant à l'élément E2 en cours de chargement (cas par exemple d'un chargement de E2 en streaming ). l'élément El est donc en quelque sorte en sandwich entre certains sous-éléments de l'élément E2 (ceux qui resteront invisibles jusqu'à ce que l'élément El soit ôté) et d'autres sous-éléments de l'élément E2 qui vont se comporter comme indiqué ci-dessus. Dans ce cas, la disparition de l'élément El lors de l'entrée du pointeur dans la zone associée, lorsqu'elle se fait par translation vers l'extérieur de l'écran de la représentation à l'écran dudit élément, est avantageusement effectuée en laissant immobiles le ou les sous-éléments de l'élément E2 alors visibles à l'écran. On peut enfin prévoir que l'élément El affiché initialement contienne des sous- éléments d'interactivité (liens vers l'autres pages, boutons déclenchant des actions, etc. ). Dans ce cas, on prévoit avantageusement que ces sous-éléments soient actifs (c'est-à-dire actionnables par pointeur de souris notamment) au moins pendant la période au cours de laquelle l'élément E2 est en cours de chargement, et que ces sous-éléments deviennent inactifs dès le moment où l'entrée du pointeur dans la zone de l'élément El doit provoquer la disparition de cet élément. En effet, les sous-éléments d'interactivité en question ne sont alors plus atteignables. On va maintenant décrire en référence aux figures 14 à 24 une généralisation de la présente invention telle que décrite ci-dessus. On se place tout d'abord dans le situation où l'on souhaite visualiser deux pages (par exemple des pages HTML) dans une seule fenêtre d'affichage. Pour bien faire comprendre cet aspect de l'invention, on va considérer que ces deux pages sont dans deux plans différents, la page P1du plan supérieur recouvrant partiellement la page P2 du plan inférieur, en étant entièrement visible dans la fenêtre de visualisation (dont la taille est ici légèrement supérieure à celle de la page P2), comme illustré sur la figure 14. La page P1 du plan supérieur peut également occuper une position décalée ; recouvre encore partiellement la page P2, mais n'est visible que partiellement, marginalement, comme l'illustre la figure 15. Dans cette forme de réalisation, on prévoit en outre une pince virtuelle qui peut fixer ensemble les deux pages, comme on le détaillera plus loin, et ce dans une ou l'autre de leurs deux positions mutuelles. Cette pince est schématisée par PC sur les figures 16 et 17. En vue en plan, l'utilisateur peut ainsi distinguer quatre zones Z11, Z12, Z 13 et Z 14 dans sa fenêtre d'affichage, comme le présente la figure 18. La zone Z11 est une zone qui n'est jamais couverte par la page P1 du plan supérieur. La zone Z11 contient donc en permanence la partie correspondante de la page P2 du plan inférieur. La zone Z12 est la zone couverte par la page P1 du plan supérieur quand celle-ci n'est pas décalée, c'est-à-dire quand elle occupe la position illustrée sur la figure 14. Et lorsque la page P1 du plan supérieur est décalée (situation de la figure 15), la zone Z12 présente la partie correspondante de la page P2 du plan inférieur, cette page occupant alors la somme des zones 211 et 212. La zone Z13 est la zone occupée par la pince, qui peut être symbolisée graphiquement de toute façon appropriée. Enfin la zone Z14 est une zone qui est couverte par la page Pl du plan supérieur quelle que soit la position de cette dernière. Nous allons maintenant présenter les différents états possibles du système et les transitions possibles entre ces états, ces dernières étant la conséquence des actions de l'utilisateur. Les états sont définis par : # la position de la page du plan supérieur (c'est-à-dire décalée ou non décalée) # les positions possibles d'un pointeur de souris par rapport aux différentes zones, # l'état de la pince PC (ouverte ou fermée). La figure 19 présente les deux positions possibles de la page Pl du plan supérieur. La figure 20 présente un exemple d'état du système, pour lequel est spécifié un ensemble de régions sensibles réagissant à l'arrivée dans celles-ci du pointeur de la souris, la position de la page du plan supérieur et l'état de la pince. Dans l'exemple de la figure 20, les régions grisées (ici les zones Z12 et Z13) désignent des endroits où la présence du pointeur n'a pas d'effet sur le système, tandis que les régions blanches (ici les zones Zl 1 et Z14) désignent des régions pour lesquelles l'entrée du pointeur dans l'une de celles-ci provoque une action, comme on le détaillera plus loin. Le comportement du système est présenté dans la figure 21 sous la forme d'un diagramme d'états-transitions, qui illustre les différentes manipulations des pages P1et P2 dans leurs plans respectifs. Le système fait en sorte que la page P1du plan supérieur ne soit remplacée par la page P2 du plan inférieur (une fois que cette dernière a été chargée à partir d'un serveur, le cas échéant) que seulement sur action implicite de l'utilisateur, et ceci de manière très intuitive. Contrairement aux procédés de streaming , l'utilisateur ne sera ainsi pas surpris de voir remplacée la page qu'il est justement en train d'examiner. Ainsi, quand la page du plan inférieur est le cas échéant chargée : - si le pointeur de la souris se trouve dans la zone Z11, le fait de l'amener dans la zone Z12 - si le pointeur se trouve dans l'une des zones Z12, Z13 et Z14, le fait de l'amener dans la zone Z1 1 puis de nouveau dans la zone Z12 aura comme conséquence de décaler la page P1du plan supérieur. Ensuite, l'utilisateur pourra provoquer le mouvement inverse de la page P1du plan supérieur (c'est-à-dire la ramener dans la zone Z12) : - soit en ramenant le pointeur de la souris dans la zone Z11, - soit en ramenant le pointeur de la souris dans la zone Z 14. Ce double choix offert à l'utilisateur présente un avantage important : - le premier choix permet d'utiliser les moyens d'interactivité (boutons, etc. ) contenus dans la page P2 du plan inférieur dans la zone Z1 1, - le deuxième choix permet d'utiliser les moyens d'interactivité contenus dans la page P1 du plan supérieur dans la zone Z12. Le fait de serrer la pince PC (par exemple par un simple clic de souris dans la zone dédiée Z13) a pour effet d'éviter de décaler la page du plan supérieur à la suite des manipulations indiquées ci-dessus. En d'autres termes, le processus de décalage et de retour de la page P1 est alors neutralisé, et les positions mutuelles des pages P1et P2 (que ce soit avec la page P1 décalée ou la page P1non décalée) sont figées. Cette neutralisation peut être supprimée avantageusement en cliquant à nouveau dans la zone Z13 pour desserrer la pince PC. On notera que les différents états et les différentes transitions illustrés sur la figure 21 peuvent être complétés le cas échéant par d'autres états et d'autres transitions, notamment lorsqu'il existe dans la fenêtre, à l'extérieur des zones Z11 à Z14, une zone de marge qui peut être utilisée, par exemple, pour passer de la zone Z11 à l'une des zones Z13 ou Z14, ou réciproquement, sans passer par la zone Z12 qui les sépare. Le système décrit ci-dessus en référence aux figures 14 à 22 peut être étendu pour gérer plus de deux plans superposés. Ainsi l'on a illustré sur les figures 23 à 26 une page P2 de plan inférieur qui est fixe, et deux pages P1 et P1' de niveaux respectivement supérieur et intermédiaire, qui peuvent individuellement adopter une position non décalée (pleinement visible) ou décalée. La pince PC est ici commune aux trois pages, et peut donc occuper une zone graphique unique. En supplément de la pince, un moyen graphique de solidarisation des plans adjacents pris deux à deux peut être mis en #uvre. Quand ce moyen est activé, les deux plans qu'il relie se déplacent ensemble. Le système décrit en référence aux figures 14 à 26 peut ici encore avantageusement être mis en oeuvre dans le cadre d'applications sur l'Internet, dans lesquelles les pages mettent un temps significatif à être chargées. La page PIdu plan supérieur pourra être chargée en premier et faire patienter l'utilisateur pendant que la page P2 du plan inférieur se charge. De même, l'affichage des pages Pl et/ou P2 peut permettre de faire patienter l'utilisateur pendant le chargement d'une autre page P3, encore plus inférieure selon la présentation adoptée ici, et ainsi de suite. Enfin, dans les différentes formes de réalisation de l'invention, on peut prévoir une page Pl sensiblement plus petite que la page P2, auquel cas les zones d'affichage occupées par la page P1 dans ses deux positions respectives sont disjointes. On va maintenant décrire en référence aux figures 27 à 31 un procédé de gestion de l'affichage de fenêtres d'un système d'exploitation notamment lors d'opérations de glisser-déposer. La figure 27 illustre une première fenêtre FI qui recouvre partiellement une seconde fenêtre F2 (peu importe ici que la fenêtre qui se trouve sur le dessus soit active ou non). On a illustré sur la figure 28 un pointeur (ou curseur) PT de souris qui se trouve sur un objet 01 (tel qu'un dossier ou document) visible dans la fenêtre FI. L'appui par l'utilisateur d'un bouton de la souris permet, de façon connue en soi, de saisir cet objet en vue d'une opération, également connue en soi, de glisser-déposer . Sur la figure 29, le pointeur Pl accompagné de l'objet 01 parcourt un trajet (flèche fl) de la fenêtre F1 vers la partie visible de la fenêtre F2, en franchissant donc le bord (gauche en l'occurrence) de la fenêtre F1, sans lâcher le bouton de la souris. Sur la figure 30, le mouvement du pointeur PT accompagné de l'objet 01 atteint à nouveau, par un mouvement inverse (flèche f2), le bord de la fenêtre Fl préalablement franchi. Ce phénomène provoque, dans le présent exemple de réalisation, la mise en arrière-plan de la fenêtre F1par rapport à la fenêtre F2. L'entièreté de la fenêtre F2 devient donc visible, et l'utilisateur peut donc librement choisir lequel, parmi les objets visibles dans toute la fenêtre F2, celui des objets (objet désigné par 02) sur lequel il va déposer l'objet 01. Ceci est illustré par la figure 31. Selon une variante, on peut prévoir que lors du mouvement du pointeur selon la flèche f2, la fenêtre F1se déplace, de préférence selon le même mouvement que le pointeur PT, pour ainsi progressivement dégager la fenêtre F2. D'autres variantes sont bien entendu possibles, et notamment : - le système effectue une signalisation auprès de l'utilisateur lors de l'atteinte par le pointeur du bord de la première fenêtre ; cette signalisation peut être choisie dans le groupe comprenant une signalisation visuelle, une signalisation sonore et une signalisation tactile telle qu'un retour de force au sein d'un périphérique d'entrée manuel qui commande ledit pointeur ; - la fenêtre FI peut passer automatiquement en arrière-plan de la fenêtre F2 dès que le pointeur PT muni de l'objet 01 a séjourné dans la zone de la seconde fenêtre non recouverte par la première fenêtre pendant une durée supérieure à un seuil prédéterminé ; - la fenêtre FI peut passer automatiquement en arrière-plan de la fenêtre F2 lorsqu'une touche d'un clavier du poste informatique est actionnée, ou encore par commande vocale ; - la mise en arrière-plan ou le déplacement de la fenêtre FIpour dégager la fenêtre F2 peut être réversible, par exemple en effectuant un déplacement inverse du pointeur après son mouvement selon la flèche f2. Bien entendu, l'homme du métier saura effectuer les adaptations nécessaires dans le cas où il faut gérer l'affichage de plusieurs fenêtres superposées. ** * Chapitre II - Création de liens (Figures 32 à 84) Selon un autre aspect de l'invention, on va maintenant décrire un système permettant à l'utilisateur de créer des liens hypertexte (que l'on appellera dans la suite liens ajoutés ) entre des pages qu'il découvre au gré de sa navigation sur l'Internet. Un but de ce système est que chaque utilisateur ajoute ses propres liens dans la masse d'informations disponible sur l'Internet. La figure 32 illustre ce concept, chaque point noir représentant une page et chaque trait séparant deux points noirs représentant un lien ajouté. Concrètement, l'utilisateur met en place de nouveaux liens au cours même de sa navigation, ces liens ajoutés étant destinés à l'aider dans sa navigation dans le futur. Il navigue ainsi de manière pro-active . En d'autres termes, pour chaque utilisateur, l'ensemble des liens ajoutés, que l'on peut considérer comme sa toile miniature personnelle (Miniweb), s'ajoute à la toile Internet (Web) à laquelle il avait déjà accès, comme illustré sur la figure 33. A cet effet, le système est installé entre le navigateur et les sites visités, et augmente pour chaque utilisateur le réseau des liens qui sont à sa disposition pour naviguer. Pour ce faire, le système est doté de moyens de stockage des liens ajoutés. Ces moyens permettent, à chaque accès (Link) à une page à laquelle un ou plusieurs liens ajoutés ont été associés, de présenter ces derniers à l'utilisateur en supplément de ladite page. Sur un plan pratique, et comme l'illustre la figure 34, une indirection est établie vers une table (Link-Added Links) de stockage des liens ajoutés, afin d'associer ces liens ajoutés (Added Links) à cette page avant de la présenter à l'utilisateur. Le stockage des liens ajoutés peut être local (sur le poste client) ou distant (sur un serveur approprié). Dans la suite de la description, on se focalisera sur un stockage distant. En effet, dans certains des perfectionnements qui seront présentés plus loin, les liens formant les toiles miniatures personnelles de différents utilisateurs seront automatiquement comparés entre eux et des liens ajoutés pourront être communiqués d'une toile personnelle à une autre, ce qu'un stockage distant permet plus facilement de mettre en #uvre. Chaque toile personnelle peut ainsi s'enrichir de liens ajoutés provenant d'autres toiles personnelles, et proposés automatiquement par le système qui par exemple possède en outre des moyens pour détecter que leurs utilisateurs respectifs partagent les mêmes centres d'intérêt. Par ailleurs, chaque utilisateur peut se constituer un cercle de relations (d'amis) proposées par le système suite à la détection de centres d'intérêts communs. La suite de la description est structurée de la manière suivante : On présentera d'abord le système qui permet à un utilisateur de créer des liens ajoutés et de les retrouver ultérieurement (lors des accès aux pages auxquelles ils ont été associés). Ceci est décrit dans la section Créer et retrouver des liens ajoutés . On présentera ensuite un perfectionnement du système consistant à combiner des liens ajoutés avec une approche de stockage de ces liens dans une structure hiérarchique de répertoires et sous-répertoires (c'est-à-dire en intégration avec l'approche classique des systèmes de mémorisation de liens favoris , signets , ou bookmarks ou encore scrapbook selon la terminologie anglo-saxonne). Ceci sera décrit dans la section Création de liens ajoutés dans des Répertoires . On présentera ensuite un perfectionnement du système classique de marque-pages, qui consiste à rendre les marque-pages contextuels. On présentera ensuite un perfectionnement du système permettant aux utilisateurs de publier (ou mettre à disposition d'un groupe restreint) au moins un sous-ensemble des liens ajoutés de leur toile personnelle. Ces liens ajoutés pourront être visualisés directement au moyen d'un navigateur Internet standard. Alternativement, ces liens ajoutés pourront être consultés avec le système et enrichir la toile personnelle de l'utilisateur qui les consulte. Ceci est décrit dans la section Publication de liens ajoutés . On présentera ensuite un perfectionnement qui permet au système de suggérer automatiquement aux utilisateurs des liens ajoutés provenant d'autres utilisateurs dont les centres d'intérêt sont proches. Ceci est décrit dans la section Détection de Répertoires Proches . On présentera ensuite une architecture qui permet à l'éditeur ou l'administrateur d'un site Internet ( Webmaster en terminologie anglo-saxonne) de proposer des liens ajoutés aux utilisateurs du système de manière personnalisée. Ceci est décrit dans la section Suggestion de liens ajoutés par le Webmaster . On présentera enfin un système permettant de simuler la propagation d'un nouveau lien ajouté parmi les utilisateurs du système sur l'Internet et de calculer le volume de l'audience probable. Ceci est décrit dans la section Calcul de l'Audience . On présentera ensuite un perfectionnement du système permettant à l'utilisateur de publier (ou mettre à disposition d'un groupe restreint) au moins un sous-ensemble des répertoires de sa toile personnelle. Ces répertoires peuvent être visualisés directement au moyen d'un navigateur standard. Alternativement, ces répertoires peuvent être consultés avec le système et enrichir la toile personnelle de l'utilisateur qui les consulte. Ceci est décrit dans la section Publication de Répertoires . On présentera ensuite un perfectionnement du système permettant à l'utilisateur de stocker (en local ou sur un serveur) non seulement un lien mais aussi une copie figée d'une page. Ceci est décrit dans la section Liens en mode Gelé . On décrira ensuite un perfectionnement qui, dans le cadre du système présenté jusque là, permet de publier des pages qui ont été restructurées pour présenter des liens directement à l'intérieur d'elles-mêmes, l'utilisateur pouvant supprimer ces liens ou en ajouter d'autres. Pour ce faire, les pages contiennent un ou plusieurs contenants dans lesquels sont présentés des contenus qui peuvent eux-mêmes contenir d'autres contenants récursivement. Ceci est décrit dans la section Contenants et contenus . En intégrant les concepts présentés jusque là (liens ajoutés associés aux pages et liens dans des contenants inclus dans des pages) et en les illustrant au moyen d'un exemple, on récapitulera ensuite les fonctionnalités du système global et on les complétera par quelques perfectionnements. Ceci est décrit dans la section Proposition de Répertoires Spécialistes et Voisins . On présentera ensuite 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éréssés par de mêmes contenus et se trouvant dans une situation de complémentarité. Ceci est décrit dans la section Attributs relatifs à l'acceptation . On présentera ensuite un perfectionnement qui permet aux pages restructurées de présenter des contenus de manière personnalisée , c'est à dire en fonction des centres d'intérêts de l'utilisateur. Ceci est décrit dans la section Pages Personnalisées . Section 1 - Créer et retrouver des liens ajoutés La Figure 35 illustre le principe selon lequel, en conséquence d'un accès par l'utilisateur à une page p1 via l'Internet, le système lui présente automatiquement un certain nombre de liens ajoutés, en l'occurrence sous forme de symboles graphiques, vers des pages p2, p3 et p4 qu'il avait associées à la page pl au cours de navigations précédentes. Motivation Les liens ajoutés sont créés par l'utilisateur dans le but d'établir des relations entre des pages qui l'intéressent. Les liens ajoutés représentent des relations pertinentes entre ces pages ; une page liée à une autre page est intéressante dans le contexte de ladite autre page (et optionnellement, dans le sens inverse également). Pour l'utilisateur, l'ensemble des liens ajoutés constitue donc un réseau de relations supplémentaires entre pages qui l'intéressent les unes par rapport aux autres, comme l'illustrent les figures 36a, 36b et 36c qui illustrent pour les figures 36a et 36b, deux réseaux de liens entre un certain nombre de pages, et pour la figure 36c, le réseau aggloméré desdits liens. A partir d'une page ou d'un ensemble de pages sélectionné, le système permet à l'utilisateur de naviguer vers des pages qui y sont reliées. Le réseau de liens ajoutés constitue ainsi pour l'utilisateur un réseau de navigation personnel selon son propre schéma mental et lui permet de retrouver plus facilement les éléments d'information qu'il avait déjà repérés. Créer des liens ajoutés L'approche des plans coulissants décrite dans la première partie de la présente description est particulièrement favorable à l'établissement de liens ajoutés par la technique, classique en soi, du glisser-déposer . L'utilisateur peut sélectionner une page ou un élément (ou zone graphique qui la représente) qui se trouve dans un plan, la glisser et la déposer dans une autre page (ou zone graphique qui la représente) qui se trouve dans un autre plan, afin d'établir un lien ajouté entre ces deux pages. Cette approche est à comparer avec l'approche qui consisterait à glisser-déposer des pages entre des fenêtres différentes de l'outil de navigation, qui se recouvrent partiellement et qui empêchent donc de visualiser les pages entièrement. L'avantage de l'approche par plans coulissants est de permettre, au cours même du processus de glisserdéposer (c'est-à-dire sans lâcher le doigt sur le bouton de la souris), de visualiser le contenu des plans (les pages et leurs liens ajoutés) à tour de rôle, par simple mouvement de la souris, comme décrit précédemment en référence notamment à la figure 26. On comprend également que, selon une variante, cette technique de glisser-déposer avec révélation des zones d'affichage en second plan sur lesquelles se dirige le curseur au cours même de l'opération peut être généralisée au cas où ces zones d'affichage sont des fenêtres d'un systèmes d'exploitation classique tel que Windows ou MacOS (marques déposées). Plus précisément, on prévoit dans ce cas qu'une fenêtre située en second plan passe en premier plan quand le curseur pousse la fenêtre qui était en premier plan en arrivant contre l'un de ses bords. La figure 37 présente un exemple, de création de liens ajoutés entre pages, en tirant des liens entre les objets graphiques les représentant (situées à gauche des pages), la pince décrite plus haut étant active et bloquant le mouvement des plans. Le bas de la figure 37 illustre le cas particulier de création de liens ajoutés (par glisserdéposer d'objets graphiques) entre différentes instances du système, ouvertes simultanément par l'utilisateur sur le poste client. Les mouvements de souris qui permettent de tirer des liens ajoutés entre les pages P6 et P7 illustrent la technique décrite précédemment qui consiste à amener le pointeur de la souris à l'extérieur de la fenêtre contenant la page P6 puis le faire revenir en direction de cette même fenêtre afin de la faire passer en arrière-plan de la fenêtre de la page P7. Bien évidemment, chaque plan peut être supprimé ou minimisé (de manière à ce que sa partie visible prenne le moins de place possible) au moyen de clic sur un bouton (ceci n'est pas illustré dans les figures). Bien que la figure 37 ne le montre pas, des objets graphiques à l'intérieur des pages peuvent aussi être glissés-déposés, soit entre eux, soit vers des zones ou objets graphiques représentant les pages. Dans certains cas, comme on le verra plus loin, les objets graphiques situés à l'extérieur des pages, et représentant des contenus de pages, peuvent aussi être glissés-déposés à l'intérieur de pages. La figure 38 représente la disposition des plans coulissants quand le plan supérieur est décalé vers la droite. La figure 39 représente la disposition des plans coulissants quand tous les plans, sauf le plan le plus inférieur, sont décalés. Comme déjà décrit, la transition (d'une des dispositions de plans coulissants à une autre) se fait de façon incrémentale, au moyen de simple mouvements de la souris, la pince décrite plus haut étant débloquée. On notera ici que, pour simplifier les manipulations, l'état de la pince peut être inversé par exemple en pressant sur la barre d'espace ou une autre touche du clavier du poste client. Selon une variante, non représentée, la pince peut être déplacée sur un rail et il ne bloque que les plans situés à sa gauche. En d'autres termes, selon la position de la pince, les plans qui ne sont pas visibles à gauche de la pince sont bloqués et ceux qui sont à sa droite peuvent être décalés. Selon une autre variante, on peut prévoir des pinces sélectivement activées et désactivées entre deux pages adjacentes, de manière à ce que ces deux pages soient toujours, dans le cadre du processus de déplacement de plans, traitées de la même façon. On notera également ici que c'est le fait que la pince soit à l'état actif qui permet de tirer des liens ajoutés entre les pages (par glisser-déposer d'objets graphiques les représentant), sans entraîner le déplacement des plans tel que décrit. Selon une autre forme de réalisation, les zones graphiques qui représentent des pages peuvent se trouver sur d'autres plans que ceux qui présentent les pages. La figure 40 présente ainsi une configuration où les liens ajoutés de chaque page sont sur un ou plusieurs plans adjacents à ladite page. Les liens ajoutés peuvent aussi avantageusement être vues sous forme de vignettes comme des papillons collés sur les pages et déplaçables par l'utilisateur à souhait à l'aide de la souris. Selon une variante avantageuse, on peut disposer ces vignettes dans des zones vierges de la page qui auraient pu être utilisées par exemple pour afficher des bandeaux publicitaires. Les liens ajoutés par l'utilisateur par glisser-déposer (ou le cas échéant manuellement à l'aide du clavier ou par des clics de souris), sont stockés dans le système par exemple sous forme d'une table TABLE, comme l'illustre la figure 41. Dans la suite, nous adoptons l'hypothèse (optionnelle) selon laquelle les liens ajoutés sur une page entraînent la création de liens inverses sur les pages pointées par ces liens ajoutés (bidirectionalité des liens). Ainsi, comme l'illustre la figure 42, en conséquence de la création des liens ajoutés de p2, p3 et p4 sur la page pl, un lien ajouté pl s'ajoute automatiquement sur les pages p2, p3 et p4. La création de liens ajoutés s'effectue quand l'utilisateur repère une relation entre différentes pages qu'il découvre au gré de sa navigation en suivant des liens hypertexte ou en se déplaçant à l'intérieur de grandes pages ou de mondes virtuels en trois 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 ou autre miniaturisation de la page ou la scène 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). Les moyens de stockage des liens ajoutés sont avantageusement mis en oeuvre de manière distante (sur un serveur), comme l'illustre la figure 43. L'utilisateur ajoute et/ou supprime des liens ajoutés sur le poste client et ces manipulations sont répercutées sur le serveur, les communications se faisant par exemple par l'intermédiaire d'un Fournisseur d'Accès à l'Internet. Section 2 - Retrouver les liens ajoutés L'affichage de la page avec ses liens ajoutés peut être préparé sur le poste client, dans une architecture schématisée par le diagramme de la figure 44, ou sur le poste serveur, dans une architecture schématisée par le diagramme de la figure 45. On notera que les deux architectures sont adaptées à un fonctionnement selon le protocole HTTP par exemple. Dans le cas de l'architecture de la figure 44, la requête ou lien Link de l'utilisateur est communiquée par le poste client, tant au serveur de la page demandée qu'au serveur où ont été stockés les liens ajoutés. En retour, avant présentation à l'utilisateur, les liens ajoutés fournis par le deuxième serveur sont graphiquement combinés, par le poste client, avec la page fournie par le premier serveur, et sont présentés conjointement à cette page. Dans le cas de l'architecture de la figure 45, la requête ou lien de l'utilisateur est communiquée par le poste client, uniquement au serveur où ont été stockés les liens ajoutés. Ce serveur se charge de retransmettre la requête au serveur de la page demandée pour recevoir cette page. En retour, les liens ajoutés sont ajoutés à la page et le tout constitue la réponse à la requête de l'utilisateur. La combinaison graphique des liens ajoutés avec la page peut être effectuée sur le serveur ou sur le poste client. Section 3 - Création de liens ajoutés dans des Répertoires On connaît déjà dans l'état de la technique le concept dit de marque-page ou signet qui permet à un individu de mémoriser des liens vers ses pages favorites sur la Toile, un tel concept étant présent dans les navigateurs Internet courants. Ces derniers permettent de ranger les liens mémorisés dans des répertoires qui peuvent former une structure arborescente de répertoires et de sous-répertoires. L'établissement d'une toile personnelle (réseau personnel de navigation qui s'ajoute à la Toile) en créant (par glisser-déposer ou manuellement) des liens ajoutés directement sur des pages comme on l'a décrit dans la section précédente, est complémentaire à ces moyens classiques de rangement de liens dans des répertoires (constituant généralement des catégories personnelles de l'internaute). En effet : - l'utilisateur peut ranger dans un répertoire non seulement un lien (vers une page), mais aussi un lien ajouté (entre deux pages). - les liens ajoutés peuvent ainsi être contextuels : un lien ajouté associé à une première page (ou plus exactement, associé à un lien vers une première page) et pointant sur une deuxième page peut exister dans le cadre d'un répertoire donné qui contient un lien vers cette première page sans exister dans un autre répertoire qui pourtant contient aussi le lien vers ladite la première page. Par exemple, dans le répertoire mes boissons favorites sur la page coca (marque déposée) peut se trouver un lien ajouté vers la page pepsi (marque déposée) alors que dans le répertoire mes styles de management préférés sur la même page coca peut ne pas se trouver de lien ajouté vers la page pepsi . (Voir l'exemple à la fin de cette section et la figure 51). (Toutes les marques citées dans le présent mémoire sont des Marques Déposées de leurs titulaires respectifs, notamment coca , pepsi , perrier et hp ). Dans les choix de conception adoptés dans toute la suite de la description : - chaque lien ajouté appartient à un répertoire et un seul : un répertoire courant existe toujours, et c'est dans ce répertoire que les liens vers des pages et leurs liens ajoutés sont insérés par défaut ; si aucun répertoire n'est sélectionné par l'utilisateur pour être le répertoire courant, un premier répertoire courant lui est fourni par défaut quand il accède à une page et lui associe un premier lien ajouté. - la création d'un lien ajouté dans un répertoire donné engendre la création du lien ajouté inverse dans le même répertoire (s'il n'y existe pas déjà). Cette règle impose l'existence, dans le même répertoire, du lien vers la page pointée par le lien ajouté ; dans le cas où il n'existe pas, il y est automatiquement inséré ; ceci est illustré par l'exemple de la figure 46). - l'utilisateur peut sélectionner plusieurs répertoires comme étant répertoires courants ; les liens ajoutés visualisés pour une page courante sont alors constitués par l'union des liens ajoutés situés dans ces répertoires ; un nouveau lien ajouté inséré l'est dans chacun de ces répertoires ; enfin on verra dans la section Détection de Répertoires Proches que la recherche de répertoires proches se fera également sur la base de l'union des liens ajoutés situés dans ces répertoires. L'utilisateur peut effectuer les actions suivantes : - insérer ou supprimer, dans un répertoire, un lien vers une page : * pour insérer une page, une des méthodes possibles est la suivante : l'utilisateur choisit un répertoire courant (ou plusieurs, voir l'explication du paragraphe précédent), ou reste dans le répertoire par défaut (qui est considéré comme répertoire courant), et accède à une page dont le lien sera automatiquement rangé dans ce (s) courant(s). * pour supprimer une page, l'utilisateur sélectionne la page en question et actionne la commande supprimer (par exemple par la touche Suppr du clavier). - créer un lien ajouté : * soit il crée manuellement un lien ajouté sur une page (typiquement en tapant son adresse URL au clavier), * soit il utilise la technique du glisser-déposer : à partir d'une première page, il tire dans une deuxième page un lien ajouté qui pointera vers la première page. - déplacer ou copier une ou plusieurs pages d'un répertoire à un autre : * soit, manuellement, il choisit les pages à déplacer ou copier, soit il utilise la technique de glisser-déposer ; on notera qu'en fait, l'utilisateur déplace ou copie des liens vers des pages, même s'il croit déplacer les pages elles-mêmes. Dans la suite de la description, pour simplifier la lecture et décrire ce que l'utilisateur croit faire , nous utiliserons parfois le mot page au lieu de lien vers une page . Ainsi l'on dira déplacer une page (ou copier une page ) en lieu et place de déplacer un lien vers une page ( copier un lien vers une page ). On dira aussi une page possède un lien ajouté au lieu de dire à un lien vers une page est associé un lien ajouté , ou encore lien ajouté sur une page au lieu de lien ajouté associé à un lien vers une page . De plus, lien vers une page est un raccourci pour lien vers une page ou vers un élément contenu dans une page . Prenons un exemple: L'utilisateur a créé deux répertoires, libellés respectivement Drinks (pour mes boissons favorites ) et Mgt (pour styles de management ). Il a aussi à sa disposition un répertoire par défaut, libellé Buffer (pour tampon ) qui est créé automatiquement par le système. Selon l'approche classique de mémorisation des marque-pages, l'utilisateur insère le lien www. coca.com ( coca ) dans le répertoire Drinks. Il insère aussi le lien www.hp.com ( hp ) dans le répertoire Mgt. Dans le cadre du répertoire courant qui en l'occurrence est Buffer (par défaut), l'utilisateur accède via la Toile à la page www.pepsi.com ( pepsi ). A partir de coca (qui se trouve dans Drinks) il tire (par glisser-déposer) un lien ajouté sur la page pepsi (voir figure 46). Ce lien ajouté sur la page Pepsi va être www.coca.com. Comme, pour satisfaire l'hypothèse de conception mentionnée précédemment, un lien ajouté inverse doit être créé dans le même répertoire, la page coca doit y être introduite avec un lien ajouté www.pepsi.com. En résultat, les pages pepsi et coca se trouvent tous les deux dans Buffer, chacun ayant un lien ajouté sur l'autre. En effet, le lien sur la page coca a dû être dupliqué dans Buffer pour permettre la création du lien ajouté inverse (de coca vers pepsi). La figure 46 illustre cet exemple. L'interface homme-machine permettant ces opérations peut par exemple être celle schématisée dans les figures 46 à 51. L'utilisateur peut, par glisser-déposer, copier ou déplacer une page vers un autre répertoire. L'utilisateur peut aussi copier ou déplacer un ensemble de pages d'un répertoire à un autre. Plusieurs cas de commande au système sont possibles : 1. soit ceci entraîne le déplacement ou la copie des liens vers ces pages, sans leurs liens ajoutés. (Voir figure 47) ; 2. soit ceci entraîne le déplacement ou la copie des liens vers ces pages, avec tous les liens ajoutés existant entre elles ; le déplacement n'est possible que pour les pages qui n'ont pas de liens ajoutés avec des pages externes à l'ensemble déplacé (les autres pages de l'ensemble sont copiés) ; voir figure 47 ; 3. soit ceci entraîne le déplacement ou la copie des liens vers ces pages, avec tous les liens ajoutés entre elles ou avec d'autres pages du même répertoire ; voir figure 48 ; En poursuivant le même exemple, l'utilisateur déplace la page coca du répertoire Buffer vers le répertoire Drinks ; si l'on se trouve dans le premier ou deuxième cas de commande au système, la page coca se trouvant déjà dans Drinks, cette opération n'a aucun effet. Ceci est illustré par la figure 47. Dans un autre cas de figure, l'utilisateur voudrait ranger dans le répertoire Drinks tous les liens ajoutés de la page coca. Si l'on se trouve dans le troisième cas de commande au système, en résultat du glisser-déposer de coca (qui se trouve dans Buffer) vers le répertoire Drinks, la page pepsi se retrouve également dans Drinks et le lien ajouté entre pepsi et coca est reproduit dans Drinks. L'utilisateur pourrait ensuite supprimer du répertoire Buffer les pages pepsi et coca (avec tous les liens ajoutés entre elles) ; deux opérations sont illustrées sur la figure 48. On notera que pepsi (ou coca) n'aurait pas pu être supprimé si une troisième page perrier (marque déposée) se trouvait dans le même répertoire Buffer et avait un lien ajouté sur pepsi ou sur coca), à moins que cette troisième page perrier ne fut supprimée dans la même action. Ceci est illustré par la figure 49. Si l'on se trouve dans le deuxième cas de commande au système, l'utilisateur peut directement déplacer l'ensemble des liens pepsi et coca vers le répertoire Drinks, ainsi que les liens ajoutés entre eux. Aucune page externe à l'ensemble supprimé n'ayant un lien ajouté vers coca, cette page est alors supprimé d'office. Ceci est illustré sur la figure 50. Poursuivons l'exemple : l'utilisateur, qui pense que les styles de management des sociétés coca et hp (marques déposées) méritent d'être mis en relation, tire par glisser-déposer un lien ajouté sur la page hp à partir de la page coca. Ceci est illustré à la figure 51. La création du lien ajouté de hp vers coca entraîne la création du lien ajouté inverse de coca vers hp, les deux liens ajoutés se trouvant dans le répertoire Mgt (où se trouve la destination du glisser-déposer). Bien que l'opération effectuée ne consiste pas explicitement en un déplacement ou une copie de page, elle implique la copie de la page coca dans le répertoire Mgt (puisque les deux extrémités de tout lien ajouté doivent se trouver dans un même répertoire) . Section 4 - Marque-pages contextuels Rappelons que le système classique de marque-pages (déjà mentionné au début de la section précédente) permet à l'utilisateur de ranger dans un répertoire un lien sur (ou une copie de) la page courante visualisée, dans le cas où il veut mémoriser ledit lien. De plus, les navigateurs modernes offrent l'option d'afficher, dans une sous-fenêtre adjacente à celle contenant la page visualisée, la structure arborescente de répertoires de marque-pages et les marque-pages (liens ou copies mémorisés) qu'ils contiennent. Cette option d'affichage des liens mémorisés, simultanément à la page accédée par l'utilisateur, peut être perfectionnée en rendant contextuel l'affichage des répertoires de liens mémorisés et des liens (ou copies) mémorisés eux-mêmes. En effet, plutôt que de présenter la structure des répertoires et les liens qu'ils contiennent, de manière indépendante de la navigation de l'utilisateur, le système peut directement : - pointer sur les répertoires contenant déjà le lien sur la page courante visualisée, - et présenter leurs contenus respectifs. Ainsi, l'utilisateur n'a pas à aller chercher, dans ses répertoires, les liens (sur les pages qui l'avaient intéressé) mémorisés qui se trouvent être dans le contexte de la page courante, puisqu'il les a automatiquement à sa disposition. Dans une mise en #uvre pratique, le système présente ces répertoires (contenant la page courante) dans la zone présentant les liens ajoutés associés à la page courante en leur donnant une apparence différente (l'icône représentant un répertoire ou une page d'un répertoire qui n'est pas associé par un lien ajouté à la page courante est différente de l'icône représentant une page associée par lien ajouté). Ceci est schématisé dans la figure 52 qui illustre l'affichage des répertoires dans lesquels est rangé la page courante, automatiquement, simultanément à l'affichage de la page courante. L'utilisateur peut, par un simple clic sur un bouton (par exemple sur la barre comportant un triangle sur la figure 52), visualiser le contenu de ces répertoires et retrouver ainsi les autres pages qu'il avait rangées ensemble dans ces répertoires. Selon un détail de mise en #uvre, dans le cas où la page en question n'est rangée que dans un seul répertoire, les autres pages dudit répertoire (si elles ne sont pas trop nombreuses) peuvent être affichées directement, sans même nécessiter un clic, pour offrir ainsi un accès contextuel aux liens mémorisés de manière encore plus directe. L'utilisateur pourra cliquer directement sur la présentation graphique représentant un répertoire, par exemple une icône représentant un dossier (r2 sur la figure 52) pour ouvrir une nouvelle page présentant le répertoire r2 avec tout son contenu (les sous-répertoires et les pages qu'il contient). Bien évidemment, la présentation de la figure 52 peut être remplacée par une présentation classique d'arbre comme celle que l'on trouve dans les systèmes de marque-pages existants. Une fonction analogue concerne l'affichage des liens Ajoutés associés à une page courante. Il s'agit de pouvoir naviguer au moyen de liens Ajoutés de deuxième rang . La figure 53 illustre un exemple de mise en #uvre de cette approche. En cliquant sur une zone graphique particulière d'un lien Ajouté p3 associé à la page p1, l'utilisateur peut voir également les liens Ajoutés (p31, p32 et p33) qui sont associés à la page p3 alors que c'est la page pl qui est couramment visualisée (et non la page p3). Bien évidemment, cette approche peut être généralisée (récursivement) pour l'affichage de liens Affichés de rangs supérieurs à 2. On observera en outre que chacune des présentations graphiques représentant un lien mémorisé ou un lien ajouté (par exemple une vignette représentant la page sous forme miniaturisée) peut être accessoirement dotée d'un signe qui indique que la page pointée a été mise à jour, le cas échéant, depuis la dernière visite de l'utilisateur. Ceci constitue une invitation à aller consulter à nouveau ladite page. En outre, ce même signe peut figurer sur la représentation graphique de chaque répertoire dont au moins l'une des pages a été mise à jour. Section 5 - Publication de liens ajoutés Un perfectionnement du système consiste à permettre de publier les liens ajoutés que l'on a associés à une page. Par publier, on entend le fait de les mettre à la disposition du public ou d'un groupe déterminé d'utilisateurs (qui pourront y accéder par exemple en donnant un mot de passe). Le système permet deux cas d'accès aux liens ajoutés publiés : - les liens ajoutés publiés peuvent être visualisés directement au moyen d'un navigateur Internet standard, - ou les liens ajoutés publiés être consultés au moyen de l'interface cliente du système et enrichir la toile personnelle de l'utilisateur qui les consulte. Visualisation directe au moyen d'un navigateur standard Dans le cas d'une visualisation directe au moyen d'un navigateur standard, un premier utilisateur visualise par des moyens standard une page publiée par un deuxième utilisateur sur la Toile, ladite page possédant des liens ajoutés associés à une autre page. Cette visualisation peut être le fruit d'un accès ou d'une réception : - le premier utilisateur peut accéder via la Toile à une page présentant les liens ajoutés publiée par le deuxième utilisateur, de manière classique, en utilisant son navigateur Internet standard et en communiquant l'adresse URL de la page, - le premier utilisateur peut recevoir une page présentant les liens ajoutés, publiée par le deuxième utilisateur, de manière classique par courrier électronique. La page à laquelle il a été accédé via la Toile ou reçue par courrier électronique comporte des champs permettant au premier utilisateur de s'identifier pour le cas où il voudrait consulter les liens ajoutés au moyen du système. Il s'agit donc d'une invitation à utiliser le système, dont les avantages principaux sont : - de permettre de mémoriser les liens ajoutés dans son espace personnel sur un serveur et de les retrouver automatiquement , et - de recevoir automatiquement des suggestions de nouveaux liens ajoutés à partir de tiers. Un exemple schématique de cette invitation en est illustré à la figure 54. Consultation au moyen du système Dans le cas d'une consultation au moyen du système, lorsqu'un premier utilisateur accède, pour une page donnée, aux liens ajoutés chez un deuxième utilisateur, ces liens ajoutés s'ajoutent à 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 un deuxième utilisateur est 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 répertoires appartenant à des deuxièmes utilisateurs lui sont proposées, comme l'illustre la figure 55a. 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 ; ceci est décrit en détail plus loin dans la section Suggestion de liens ajoutés par l'administrateur du site ; 2. la deuxième liste ( voisins d'intérêt ) a pour objet de présenter au premier utilisateur les répertoires 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 toiles personnelles des utilisateurs ; ceci est décrit plus loin dans la section Détection de Répertoires Proches ). 3. la troisième liste ( copains ) contient des répertoires choisis par le premier utilisateur (par exemple, des répertoires appartenant aux toiles personnelles d'amis, collègues, experts, etc.). Selon une variante, peut s'ajouter aux trois listes ci-dessus une quatrième liste des répertoires appartenant au premier utilisateur. Dans le premier cas présenté plus haut (visualisation directe au moyen d'un navigateur standard), le pseudonyme du deuxième utilisateur qui est l'émetteur des liens ajoutés reçus par le premier utilisateur - ou du répertoire contenant ces liens ajoutés (on notera ici qu'il peut également s'agir d'un autre répertoire 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 répertoires sélectionnés dans ces trois listes. On peut ainsi considérer que l'utilisateur visite ces répertoires. 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 répertoires 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 luimême ajoutés, de manière à ce qu'il puisse sélectivement les accepter et les refuser. Dans ce but, les liens ajoutés peuvent se trouver dans un parmi plusieurs modes différents: Suggéré , Accepté , Refus et Gelé (ce dernier mode étant décrit plus loin dans la section Liens en mode Gelé ). On donnera plus loin dans le chapitre III une description plus complète de la mise en #uvre technique de ces modes. 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 autre répertoire du premier utilisateur), sont au départ chez le premier utilisateur en mode Suggéré . Suite à une action de l'utilisateur, chaque lien ajouté en mode Suggéré peut passer à 1 un parmi les autres modes. L'interface homme-machine permettant ceci est schématisée à la figure 55b. A cet effet, les moyens de stockage associent aux liens ajoutés un attribut Mode qui peut prendre comme valeur les modes déjà mentionnés à l'exception de Suggéré (c'est-à-dire, l'une parmi trois valeurs : Accepté, Refusé, Gelé). La figure 56 présente un diagramme de classe pour les liens ajoutés, selon la représentation standard UML ( Unified Modeling Language ) mettant en évidence l'attribut Mode des liens ajoutés. Un lien ajouté en mode Suggéré chez un premier utilisateur n'existe que pendant la visite des liens ajoutés (pour la page en question) chez un deuxième utilisateur (ou dans un autre répertoire du premier utilisateur). Il n'est pas affiché en dehors de cette visite. Rappelons que cette visite se fait dès que et tant que un ou plusieurs répertoire(s) est (sont) sélectionné(s) dans l'une des listes (Spécialistes, Voisins, Copains). Un lien ajouté en mode Suggéré n'est pas stocké dans l'espace de stockage personnel du premier utilisateur car, à chaque nouvelle visite, il est recréé à partir du lien ajouté correspondant stocké chez le deuxième utilisateur, ou encore dans l'autre répertoire du premier utilisateur. *Le passage d'un lien ajouté du mode Suggéré au mode Refusé a pour effet de filtrer automatiquement ledit lien ajouté lors des accès ultérieurs à l'ensemble des liens ajoutés stockés dans l'espace mémoire du deuxième utilisateur, ou dans un autre répertoire du premier utilisateur, pour la même page. Le passage au mode Accepté signifie que l'utilisateur valide le lien ajouté qui est en mode Suggéré. Cette action a pour effet : 1. de stocker ledit lien ajouté dans son espace de stockage personnel, de manière à ce qu'il lui soit présenté à nouveau avec chaque nouvelle présentation de la page à laquelle ledit lien ajouté est associé ; cette présentation a lieu même si ledit lien ajouté a été supprimé à la source (chez le deuxième utilisateur, ou dans l'autre répertoire du premier utilisateur) - ceci par opposition aux liens ajoutés en mode Suggéré qui ne sont plus présentés dès le moment où ils sont supprimés chez le deuxième utilisateur ; en outre, cette présentation a lieu même si la source (à savoir le deuxième utilisateur ou l'autre répertoire du premier utilisateur) n'est plus sélectionnée (a été décochée). 2. si le répertoire dans lequel ledit lien ajouté est rangé, est publié, de publier d'office (sauf instruction contraire de la part de l'utilisateur) ledit lien ajouté - ceci par opposition aux liens ajoutés en mode Suggéré qui eux ne seront pas publiés. L'insertion (manuelle ou par glisser-déposer) d'un lien ajouté sur une page entraîne d'office sa mise en mode Accepté (puisque l'utilisateur l'a inséré lui-même). Section 6 - Détection de Répertoires Proches Présentation générale Le système détecte pour l'utilisateur l'existence d'autres utilisateurs qui partagent ses intérêts (et ses goûts) par rapport à une page courante qu'il 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, le système sélectionne les deuxièmes utilisateurs les plus proches , c'est-à-dire ayant, dans leur réseau de liens ajoutés publiés, d'une part ladite page, et d'autre part, autour de ladite page, l'ensemble le plus grand de liens ajoutés en commun avec le premier utilisateur. Pour chacun des deuxièmes utilisateurs sélectionnés par le système, les liens ajoutés associés à ladite page qui ne figurent pas chez le premier utilisateur sont suggérés à ce dernier. En variante, la sélection des deuxièmes utilisateurs proches peut se faire par rapport à un ensemble de pages sélectionnées par le premier utilisateur, plutôt que par rapport à une seule page. On va décrire dans la suite le procédé de sélection à partir d'une seule page, l'homme de métier saura adapter cette méthode au cas de plusieurs pages. Avantages La recherche des deuxièmes utilisateurs s'effectue de manière focalisée ; elle ne s'effectue pas en fonction de leur profil global d'intérêts (vis-à-vis du profil global d'intérêts du premier utilisateur). Ceci constitue un avantage tant au niveau de la pertinence du résultat que des performances d'exécution. Au niveau de la pertinence du résultat, l'avantage de la focalisation est de pouvoir 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, 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é, d'une part n'est pas dilué dans la masse des éléments qui sont en commun globalement, et d'autre part peut être relativisé par rapport à la taille du domaine du contexte courant. Pour focaliser les recherches de profils voisins, l'état de la technique connue consiste à partitionner les éléments des profils selon des catégories adoptées par l'ensemble des utilisateurs, qui permettent de les classer globalement ou par rapport à des attributs qui les caractérisent. On spécifie ainsi leur appartenance aux domaines respectifs pris en compte lors des recherches, ce qui permet 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écessite 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. L'avantage essentiel du procédé selon cet aspect de la présente invention est de 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 sélection peut se faire sur la base d'une recherche en accès direct grâce à une structure de données (telle qu'un fichier inversé) qui permette 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. 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 procédé 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, on décrira donc l'approche consistant à sélectionner des répertoires plutôt que des utilisateurs. Comme déjà indiqué pour le cas de la recherche des utilisateurs les plus proches, la sélection des répertoires les plus proches peut également 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és. On notera à cet égard que les liens Ajoutés à partir desquels est lancée la sélection sont ceux du répertoire courant (ou ceux de l'ensemble des répertoires courants sélectionnés par l'utilisateur, comme décrit dans la section Création de liens Ajoutés dans des Répertoires ). La figure 57 schématise les deux types d'exécution de requête d'accès aux données (dans le cas où les données sont rangées dans des tables relationnelles) : - l'accès direct aux liens Ajoutés à partir : - d'une ou plusieurs pages, - d'un utilisateur, - dans un (ou plusieurs) répertoires ; - l'accès direct aux utilisateurs et leurs répertoires à partir : - d'une (ou plusieurs) nages. - et de ses liens ajoutés (obtenus par une requête du premier type). Rappelons que le premier type de requête est celui permettant les fonctionnalités Retrouver des liens Ajoutés décrites plus haut, alors que le deuxième type de requête est celle de Détection de Répertoires Proches , objet de la présente section. 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 55a. 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 en association avec la page courante (conformément à la description de la section précédente). Le système peut aussi offrir à l'utilisateur des moyens de tenter de se mettre en relation - par des moyens de communication synchrone sur Internet tels que la messagerie simultanée, la visioconférence, etc. - avec les utilisateurs possédant ces répertoires qui seraient en ligne en même temps que l'utilisateur. En effet, dans les deux types d'architecture client-serveur représentés respectivement sur les figures 44 et 45, les requêtes que les utilisateurs forment au moyen de leur navigateur, sont communiquées au serveur dans lequel est exécuté le système. Ce dernier est donc capable de savoir si les utilisateurs en question sont en ligne et si on peut communiquer avec eux. L'utilisateur peut aussi se mettre en relation par communication asynchrone, notamment par courrier électronique ou dans le cadre de forums de discussion, avec ces utilisateurs proches (que lui fait découvrir le système), même s'ils ne sont pas en ligne en même temps. On notera à cet égard, que grâce aux moyens déjà mentionnés de sélection en accès direct d'utilisateurs à partir de pages qui les intéressent (en plus d'une structure de chemin d'accès direct aux pages à partir d'utilisateurs et répertoires) le système est apte à construire, avec de très bonnes performances, des communautés d'utilisateurs partageant des mêmes centres d'intérêts. Les sujets de discussion créés sont ceux pour lesquels un ensemble de pages de taille suffisante a intéressé un grand nombre d'utilisateurs. Ces derniers sont alors invités à participer à un forum de discussion ayant comme thème cet ensemble de pages. On va maintenant décrire la méthode de calcul de proximité. 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 encore 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 propose à l'utilisateur ces répertoires dans l'ordre de leur proximité. La proximité est 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 58 illustre la détermination de la proximité au niveau 1. Au niveau 2, la proximité est également fonction du nombre de liens ajoutés communs associés aux pages reliées à la page courante par lien ajouté, comme l'illustre la figure 59. Au niveau n, la proximité est 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. Proximité transitive On va décrire ci-après un perfectionnement du procédé de calcul de proximité entre deux répertoires décrit plus haut. 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 en prenant en compte cette anticipation. Ceci peut se faire par deux approches différentes : - soit par simulation prédictive : La simulation prédictive prend en compte la probabilité d'acceptation (telle que décrite plus loin) des futures suggestions de liens ajoutés, dans les répertoires proches du répertoire courant de l'utilisateur. Le procédé de simulation prédictive consiste à simuler la propagation de liens ajoutés, à partir de répertoires à priori non proches du répertoire courant, vers des répertoires proches du répertoire courant. Suite à la propagation (simulée) d'un lien ajouté à partir de chaque répertoire non proche (vers un répertoire proche), un coefficient de probabilité d'acceptation (décrit plus loin) lié à ce répertoire non proche est associé audit lien ajouté. La proximité peut alors être affinée en tenant compte des nouveaux liens ajoutés (introduits par la simulation) pondérés par leur coefficient de probabilité d'acceptation. Le calcul de proximité peut être affiné progressivement, en prenant en compte des niveaux de plus en plus indirects. En effet, la simulation prédictive peut se faire à des profondeurs d'indirection de plus en plus grandes : ainsi un lien ajouté peut être propagé (par simulation) dans un répertoire proche du répertoire proche en question, avant d'arriver dans ce dernier, et ainsi de suite. Pour chaque nouveau répertoire, le système applique au lien ajouté le coefficient de probabilité d'acceptation associé au répertoire d'où il a été puisé. A l'arrivée dans le répertoire proche en question, les liens ajoutés (suggérés par simulation) ont un coefficient de probabilité d'acceptation qui représente la composition des probabilités d'acceptation dans les différents répertoires où ils sont passés. Optionnellement, l'utilisateur peut paramétrer le système pour lui demander de lui suggérer directement les liens ajoutés propagés par simulation dans le répertoire proche (bien que ces liens ajoutés ne soient pas encore acceptés par le possesseur du répertoire proche). De manière progressivement plus indirecte, l'utilisateur peut demander au système de lui suggérer directement les liens ajoutés propagés par simulation dans les répertoires proches d'un répertoire proche, et ainsi de suite. Lors des propagations d'un répertoire à l'autre, les coefficients de probabilité d'acceptation sont composés et les suggestions peuvent être effectuées dans l'ordre de ces coefficients. - soit selon l'approche décrite ci-dessous et appelée calcul de proximité transitive et qui offre l'avantage d'une plus grande rapidité de calcul. Considérons trois répertoires R1,R2 et R3. La proximité transitive de R3 pour RI est fonction du minimum entre la proximité de R2 pour RI et la proximité de R3 pour R2 . Le principe sous-jacent est, en effet, que dans une chaîne de propagations potentielles de liens ajoutés, la proximité transitive est fonction de la proximité du maillon le plus faible de la chaîne. A la valeur obtenue (en prenant le minimum des proximités), on doit aussi appliquer la composition des coefficients de probabilité d'acceptation des répertoires respectifs (acceptation de R2 par RI et de R3 par R2). Un exemple est illustré sur la figure 60 : - la proximité de R2 pour RI est de 2 ; en effet les liens ajoutés pointant sur les pages p2 et p3 sont en commun ; - la proximité de R3 pour R2 est de 1 (p5 seul est en commun) ; il en découle que la Proximité Transitive de R3 pour RI est de 1 (le minimum entre 2 et 1), alors que la proximité de R3 pour RI n'est que de 0 (aucun lien ajouté en commun). Bien évidemment, la proximité transitive peut aussi être calculée dans une chaîne plus longue de propagations potentielles, en prenant le minimum des proximités entre les répertoires pris séquentiellement dans ladite chaîne et en lui appliquant la composition des coefficients de probabilité d'acceptation existant pour tous les maillons de la chaîne. Coefficient de probabilité d'acceptation La détermination de la probabilité d'acceptation, dans un premier répertoire, d'un lien ajouté suggéré provenant d'un deuxième répertoire peut se baser sur l'historique des acceptations de liens ajoutés suggérés à partir de ce deuxième répertoire. Dans ce sens, chaque premier répertoire maintient un compteur pour chaque deuxième répertoire à partir duquel il a reçu des suggestions dans le passé. Bien entendu, ce compteur peut être maintenu pendant une durée limitée dans le temps. La valeur de ce compteur représente le coefficient de probabilité d'acceptation. Le coefficient de probabilité d'acceptation est fonction du nombre de liens ajoutés acceptés (en mode normal ou en mode gelé) moins le nombre de liens ajoutés refusés rapporté au nombre (total) de liens ajoutés suggérés. Ce procédé peut comporter diverses sophistications que saura mettre en #uvre l'homme du métier, et notamment une pondération permettant de donner un poids plus fort aux acceptations/refus plus récents. Pour un nouveau répertoire, c'est-à-dire à partir duquel aucun lien ajouté n'avait été suggéré dans le passé vers le répertoire courant de l'utilisateur, le système peut se baser sur un répertoire intermédiaire (ayant un historique dans le répertoire courant et le nouveau répertoire ayant un historique chez lui) pour déterminer la probabilité d'acceptation. Ceci s'effectue selon l'approche suivante : Si un répertoire RI jouit d'un fort coefficient de probabilité d'acceptation (CO-1) auprès d'un répertoire RO, et qu'un répertoire R2 a un fort coefficient de probabilité d'acceptation (CI-2) auprès du répertoire RI, alors, par transitivité, R2 aura un fort coefficient de probabilité d'acceptation (CO-2) auprès du répertoire RO. Plus précisément, la valeur CO-1 reflète le degré de confiance que le possesseur du répertoire RO accorde au contenu du répertoire RI. En effet, puisqu'en général le possesseur du répertoire RO accepte les suggestions provenant du répertoire RI, il accorde un degré de confiance relativement fort à la validité de l'acte d'acceptation dans le répertoire RI. En d'autres termes, le possesseur du répertoire RO considère que le possesseur du répertoire RI a un bonjugement en matière d'acceptation et de refus dans ledit répertoire RI. Or il se trouve que le possesseur du répertoire RI a accepté dans ce répertoire une grande partie des suggestions provenant du répertoire R2 (c'est-à-dire que la valeur CI-2 est élevée). Puisque son jugement est bon aux yeux du possesseur du répertoire RO, le système peut conclure que le possesseur du répertoire RO va probablement aussi accepter les suggestions provenant du répertoire R2. Par le même raisonnement, si la valeur CO-1 est forte et si la valeur CI-2 est faible, alors, le système peut conclure que la valeur CO-2 sera faible. Bien évidemment, la profondeur de la transitivité (le nombre des intermédiaires) peut être plus grande : le système peut se baser sur plusieurs intermédiaires qui se sont fortement validés dans le passé (de préférence le passé récent - voir plus haut à propos de la pondération) pour prédire qu'un nouveau répertoire sera probablement validé ou pas. Mais, bien évidemment, la fiabilité du coefficient obtenu baissera avec la profondeur de la transitivité. On a déjà mentionné que la détection de répertoires proches permet de présenter ces répertoires à l'utilisateur dans la deuxième liste (intitulée voisins d'intérêt ) illustrée de manière schématique dans la figure 55a. Le coefficient de probabilité d'acceptation est un indicateur qui est présenté avec chacun de ces répertoires (il peut par exemple être intitulé statistiques d'acceptation ). L'utilisateur préférera cocher des répertoires qui ont ce coefficient le plus élevé possible. Section 7 - Suggestion de liens ajoutés par l'administrateur d'un site Présentation L'administrateur d'un site ( Webmaster selon la terminologie anglo-saxonne) spécifie, dans le code source de la page à laquelle accède un utilisateur, ou encore dans une table contenue dans un serveur approprié et dont la clé est l'adresse de ladite page, l'ensemble des adresses des répertoires (dits Spécialistes ) qui peuvent être proposés à l'utilisateur dans la première liste de la figure 55a. Les deux étapes suivantes peuvent être mises en #uvre dans l'exploitation de ces répertoires (répertoires candidats) pour un utilisateur donné : 1. En première étape, le système ne retient parmi les répertoires candidats que ceux qui sont les plus proches du répertoire courant (au sens de la section précédente Détection de Répertoires Proches ). Toutefois, cette approche n'est valide que si la page à laquelle l'utilisateur a accédé n'est pas nouvelle pour celui-ci, et que l'utilisateur lui avait déjà associé des liens ajoutés, de manière à ce que le système puisse les comparer avec ceux figurant dans chacun des répertoires candidats spécifiés par l'administrateur (pour déterminer dans quelle mesure ce répertoire est proche, et ne retenir ainsi que les répertoires candidats les plus proches). Si, au contraire, la page à laquelle l'utilisateur accède est nouvelle pour lui, le système peut, optionnellement, tenter tout de même de sélectionner des répertoires candidats proches, en comparant les liens ajoutés qui se trouvent dans le répertoire courant de l'utilisateur (ces liens ajoutés n'étant pas associés avec la page courante, puisque celle-ci est nouvelle, mais à d'autres pages) avec les liens ajoutés des répertoires candidats, en partant de pages situées à des niveaux progressivement plus éloignés de la page courante dans les répertoires candidats. En cas d'échec, le système peut proposer les premiers répertoires spécifiés par l'administrateur du site comme devant être présentés par défaut. 2. Le système ne retient, dans les répertoires choisis en première étape, que les liens ajoutés les plus avantageux selon un ensemble de critères de pertinence dont le poids relatif peut être réglé par l'administrateur du site. A partir des répertoires Spécialistes candidats (et/ou des répertoires proches voisins d'intérêt ), le système peut aussi synthétiser un premier répertoire spécialiste de manière personnalisée et le proposer à l'utilisateur par défaut. Le contenu de ce nouveau répertoire est créé en regroupant des liens ajoutés sélectionnés dans les répertoires candidats, qui à priori sont potentiellement les plus pertinents pour l'utilisateur. En relation avec chaque lien ajouté, l'administrateur peut spécifier : - la manière dont ledit lien ajouté va être graphiquement présenté avec la page courante ; - et la manière dont le lien ajouté inverse sera graphiquement présenté quand la page vers laquelle pointe ledit lien ajouté pointe va être visualisée. Répertoires de la liste intitulée Spécialistes Le document source d'une page à laquelle accède l'utilisateur (par exemple une page écrite en langage HTML) peut contenir, parmi les données non affichées à l'écran, l'adresse d'un premier répertoire (contenant des liens ajoutés) à proposer par défaut à l'utilisateur. Cette adresse (composée par exemple du pseudonyme de l'utilisateur et du chemin du répertoire que l'administrateur du site a choisis) est utilisée par le système pour être présentée en première position dans la première liste ( Spécialistes ) de la figure 55a. Cette adresse est cochée (sélectionnée) par défaut par le système, ce qui signifie que l'utilisateur est implicitement considéré comme souhaitant se faire suggérer les liens ajoutés du répertoire en question dans sa propre liste de liens ajoutés (conformément à la description faite dans la section Publication de liens ajoutés ). Dans le document source, l'administrateur peut aussi spécifier des adresses supplémentaires de répertoires d'autres spécialistes. Celles-ci serviront d'éléments optionnels dans la première liste ( Spécialistes) de répertoires proposés à l'utilisateur, mais ne seront pas cochées par défaut. Alternativement, ces adresses de répertoires spécialistes, au lieu d'être notées dans le document source de la page à laquelle accède l'utilisateur, peuvent être stockées sur un serveur dans une table qui fournit la correspondance entre l'adresse de la page et les adresses des répertoires Spécialistes qui lui sont attribués. Dans le cas où ledit serveur est aussi le serveur de liens ajoutés pour l'utilisateur courant, cette alternative permet d'éviter un allerretour supplémentaire sur le serveur de liens ajoutés dans le cas de l'architecture de la figure 44. Sélection parmi les répertoires candidats Le nombre d'adresses de répertoires Spécialistes (spécifiées par l'administrateur) peut être bien plus élevé que le nombre de répertoires qui seront effectivement présentés à l'utilisateur. Un nombre maximal de répertoires à présenter peut être fixé par l'administrateur et/ou par l'utilisateur. Comme déjà mentionné brièvement dans la présentation faite plus haut, parmi les répertoires candidats, le système choisit les répertoires les plus proches de l'utilisateur. Ceci s'effectue : - soit directement selon la technique décrite plus haut dans la section Détection de Répertoires Proches , - soit selon une extension de cette technique, appelé Proximité Décalée , que l'on va maintenant décrire. Proximité Décalée Dans le cas où la page courante (visualisée par l'utilisateur) : - ne possède aucun lien ajouté (notamment parce que l'utilisateur y accède pour la première fois dans son répertoire courant) - ou n'a pas suffisamment de liens ajoutés en commun avec aucun des répertoires candidats(par rapport à un critère quantitatif fixé lors du paramétrage du système), le système, n'ayant pas la possibilité de détecter (par le procédé décrit dans la section Détection de Répertoires Proches ), parmi les répertoires candidats, les répertoires les plus proches , sélectionne les répertoires candidats par les étapes suivantes : a. le système retient les répertoires candidats offrant le plus grand nombre de pages d'éloignement de niveau 1 (c'est-à-dire des pages pointées par des liens ajoutés associés à la page courante) qui soient en commun, b. pour chacune des pages d'éloignement de niveau 1 qui sont en commun, le système calcule la Proximité (tel que décrit dans la section Détection de Répertoires Proches ) en partant de ces pages. La Proximité Décalée pour le répertoire candidat est fonction des Proximités ainsi déterminées. Au final, le système choisit les répertoires candidats offrant les valeurs les plus élevées de proximité Décalée déterminées comme décrit ci-dessus. Dans le cas où le résultat de la recherche du point a. n'est pas suffisamment satisfaisant, le système peut éventuellement rechercher, dans le répertoire courant, des pages situées à des niveaux progressifs d'éloignement dans les répertoires candidats (Proximité Décalée d'éloignement > 1). Au point b. , le niveau de profondeur de recherche de Proximité peut éventuellement être augmenté ou diminué (le cas de recherche le moins coûteux en ressources informatiques étant celui avec une profondeur de niveau 0, c'est-à-dire en court-circuitant le point b. ). La figure 61 illustre la détermination de proximité décalée d'éloignement 1 pour un répertoire candidat. Dans cet exemple, le système trouve, dans le répertoire courant de l'utilisateur : - deux pages en commun (p1et p2), - pour la page pl du répertoire candidat, une valeur de proximité égale à deux liens ajoutés sur trois ; et pour la page p2, une valeur de proximité égale à un lien ajouté sur deux. On notera que cette technique de calcul de proximité décalée à partir d'un niveau progressif d'éloignement en partant de la page courante peut également être utilisée de manière générale pour rechercher des répertoires proches (notamment parmi un ensemble d'utilisateurs), en complément de la technique de calcul de proximité décrite dans la section Détection de Répertoires Proches . La figure 62 illustre ainsi la détermination de proximité décalée d'éloignement 1 d'un répertoire B par rapport à une page courante pO dans un Répertoire A. On observe que dans cet exemple, la détermination de proximité tel que décrite dans la section Détection de Répertoires Proches ) aurait échoué puisque la page pO n'existe pas dans le répertoire B. Sélectionparmi les liens ajoutés Les liens ajoutés contenus dans les répertoires candidats sélectionnés (c'est-à-dire les Spécialistes proposés dans la première liste de la figure 55a) peuvent comporter bien plus de liens ajoutés (en mode Accepté ou Gelé ) que ceux qui seront suggérés aux utilisateurs. En effet, le système est apte à sélectionner les liens ajoutés les plus pertinents pour chaque utilisateur qui les recevra. Ainsi la suggestion de liens ajoutés se fait de manière personnalisée . La sélection est effectuée par exemple en fonction d'un ou plusieurs des critères suivants (sélectionnés notamment en fonction des ressources qu'ils nécessitent à priori pour leur mise en #uvre): - l'intérêt potentiel du lien ajouté en question (dit lien ajouté candidat ) pour l'utilisateur : comme déjà mentionné dans la section Création de liens ajoutés dans des Répertoires , les liens ajoutés sont bidirectionnels, c'est-à-dire qu'un lien ajouté associé à une page Pl et pointant sur une page P2 implique (dès qu'il est Accepté) la création du lien ajouté associé à la page P2 et pointant sur la page P1 ; @ est donc dans 1 intérêt de i administrateur au site de suggérer un lien ajouté sur une page P2 potentiellement la plus intéressante possible, puisque * plus la page P2 est intéressante, plus l'utilisateur va la consulter ; * et à chaque fois qu'il va la consulter, le lien ajouté pointant sur la page P1 va y figurer et va ainsi inciter l'utilisateur à aller consulter ladite page P1. Pour satisfaire à ce critère particulier, le système a notamment la possibilité d'analyser si le lien ajouté candidat avait été accepté ou gelé dans des répertoires proches du répertoire courant de l'utilisateur. Pour ce faire, et comme l'illustre la figure 63, le système recherche des répertoires (répertoire proche candidat) possédant : * la page courante (à noter que, du fait que la page courante est nouvelle pour l'utilisateur, aucun lien ajouté n'y est encore associé) ; * le lien ajouté candidat associé à la page courante, en mode accepté ou gelé, * et le répertoire de l'utilisateur ayant une forte valeur de proximité décalée d'éloignement 1 (ou progressivement plus si nécessaire) par rapport au répertoire proche candidat en partant de la page courante. - le fait que l'utilisateur avait déjà reçu la page vers laquelle pointe le lien ajouté candidat (s'il ne s'agit pas d'une nouvelle page pour lui) dans le répertoire courant, et le fait qu'en outre la page pointée par le lien ajouté candidat est déjà bien ancrée dans le répertoire courant (dans le sens où l'utilisateur a une probabilité relativement forte de la consulter en navigant d'une page a l'autre du répertoire), étant donné que plus l'utilisateur accédera à la page pointée par le lien ajouté, plus il verra le lien ajouté inverse qui l'incitera à aller revisiter la page courante (voir cependant le troisième sous-critère ci-dessous qui consiste à fixer un seuil supérieur au nombre de liens ajoutés préexistants) ; la propriété d'ancrage est mesurée en comptant dans le répertoire courant le nombre de liens ajoutés qui pointent sur la page en question (ou plus simplement, puisque les liens ajoutés sont bidirectionnels, en comptant les liens ajoutés associés à la page en question). - dans quelle mesure l'utilisateur avait déjà accepté ou gelé cette page (ou au contraire, combien de fois il l'avait laissée en mode suggéré ou il l'avait refusée) : si l'utilisateur avait déjà reçu cette page (pointée par le lien ajouté candidat) dans le répertoire courant, et si de plus il l'avait acceptée (ou gelée), ceci indique que cette page l'intéresse et qu'elle sera donc probablement à nouveau acceptée en tant que lien ajouté de la page courante ; il est donc plus avantageux de choisir le lien ajouté pointant sur cette page plutôt qu'un lien ajouté pointant sur une page nouvelle pour l'utilisateur ; en revanche, si l'utilisateur avait déjà reçu cette page mais depuis ce moment il l'a laissée en mode suggéré, ou, à fortiori, il l'a refusée, le système préférera ne pas la choisir, car le lien ajouté candidat a relativement moins de chances d'être accepté par l'utilisateur. - le nombre de liens ajoutés couramment associés à la page pointée par le lien ajouté candidat : si, dans le répertoire courant de l'utilisateur, une multitude de liens ajoutés sont déjà associés à la page pointée par le lien ajouté candidat, le lien ajouté inverse au lien ajouté candidat sera noyé dans cette multitude et n'aura pas l'effet d'incitation souhaité ; il n'est donc pas toujours avantageux de choisir un lien ajouté candidat dont la page vers laquelle il pointe possède déjà de trop nombreux liens ajoutés dans le répertoire de l'utilisateur (on notera que ce sous-critère est l'inverse du critère d'ancrage ; il doit être utilisé pour fixer un seuil qu'il ne faut pas dépasser) ; l'administrateur indique alors avantageusement, avec chaque répertoire spécialiste (qu'il spécifie par exemple dans la partie non affichée du document source de la page, ou encore dans une table sur le serveur, comme décrit plus haut) : * le nombre maximum de liens ajoutés à suggérer (voir plus haut), étant rappelé que l'utilisateur aussi peut contraindre ce nombre ; * le poids relatif à donner à chacun des critères (c'est-à-dire la formule d'agrégation pondérée des critères) décrits ci-dessus, ainsi qu'éventuellement des indications sur les heuristiques à mettre en #uvre dans leur prise en compte (il s'agit notamment d'éviter les critères qui consommeraient trop de ressources). Suggestion directe dans le Répertoire par défaut Le système peut synthétiser et proposer des liens ajoutés à partir : - des répertoires Spécialistes et/ou - des répertoires proches déterminés automatiquement par le système et présenter les liens ajoutés obtenus à partir de ces répertoires (répertoires candidats) par exemple à travers le premier répertoire de la première liste de la figure 5 5 a, qui est proposé à l'utilisateur par défaut. Ce premier répertoire est ainsi synthétisé de manière différente pour chaque utilisateur. Pour ce faire, dans les répertoires candidats, le système choisit les liens ajoutés : - qui pointent sur une page, * alors que cette page est déjà existante et a été acceptée (ou gelée) un nombre de fois suffisant dans le répertoire courant de l'utilisateur * ou qui s'est avérée être intéressante chez un nombre suffisant d'utilisateurs voisins d'intérêt (ou plus exactement, qui fut acceptée ou gelée dans un nombre suffisant de répertoires proches), - et optionnellement, qui pointent sur une page pour laquelle la Proximité Décalée Cumulée d'éloignement 1 (à partir de la page courante), obtenue en additionnant les Proximités Décalées d'éloignement 1 dans les répertoires candidats, soit la plus grande possible. Présentation graphique Avec chaque lien ajouté, l'administrateur du site peut spécifier sous quelle forme, avec quelle image et à quelle position de la page courante, le lien ajouté devra être posé, la présentation pouvant être par exemple : - sur le bord de la page (dans une liste de vignettes ), - sur la page (comme une affichette adhésive), ou sous la forme d'une petite icône située sur la page qui se transforme en une telle affichette au passage de la souris, - ou encore dans des régions de la page qui étaient prévues pour contenir de la publicité. L'administrateur peut aussi spécifier ces paramètres de présentation graphique pour le lien ajouté inverse (qui sera affiché sur la page vers laquelle pointe le lien ajouté en question). En particulier, l'administrateur peut souhaiter expressément spécifier à quelle position ou dans quelle région, sur la page vers laquelle pointe le lien ajouté en question, sera appliquée la représentation graphique du lien ajouté inverse. C'est en effet par ce moyen qu'il pourra mieux inciter l'utilisateur à venir consulter sa propre page (la page courante). Son audience dépendra donc en partie de la position (ainsi que l'apparence graphique) du lien ajouté inverse. La figure 64 illustre la présentation graphique d'un lien ajouté inverse sur une page (sous forme d'affichette). Une page pl a un lien ajouté sur une page p2 qui est déjà très encombrée d'une multitude de liens ajoutés présentés graphiquement sous forme de vignettes (dans une liste verticale). Sur la page p2, le lien ajouté inverse pointant sur pl n'est pas présentée comme une vignette de plus, mais sous forme d'une affichette directement sur le contenu de la page. La représentation graphique du lien ajouté inverse peut aussi être automatiquement inséré dans une région qui normalement aurait dû contenir de la publicité. L'administrateur espère par là attirer l'attention de l'internaute. Section 8 - Calcul automatique de prévision d'Audience Le service offert par le système, consistant à permettre à l'administrateur d'inciter l'utilisateur à cliquer sur un lien ajouté inverse (pointant sur la page publiée par ledit administrateur) : - peut être proposé (fonction de devis ) au moyen d'un calcul de prévision d'audience ; - peut être facturé (fonction facturation ) pour le service effectivement rendu, sur la base : * de l'audience de la page à laquelle est associé le lien ajouté inverse (le nombre de fois que la page p2 de la figure 64 est vue par les utilisateurs du système), * des clics effectifs, c'est-à-dire en fonction du nombre de clics effectivement réalisés sur les liens ajoutés inverses. En effet, non seulement, un lien ajouté inverse incite directement l'utilisateur à accéder à la page vers laquelle il pointe (en l'occurrence la page pl de la figure 64), mais en outre, les liens ajoutés de la page (p2) à laquelle le lien ajouté inverse est associé peuvent être publiés (voir la section Publication de liens ajoutés ) et être ainsi propagés d'un utilisateur à l'autre. Dans ce schéma de propagation, seul les liens ajoutés inverses acceptés par un utilisateur seront suggérés aux utilisateurs qui sont en l'aval dans la chaîne de propagation. La prévision d'audience peut être effectuée avantageusement en appliquant le coefficient de probabilité d'acceptation qui tient compte du comportement des utilisateurs (tel que décrit plus haut dans la section Détection de Répertoires Proches ). Section 9 - Publication de Répertoires Un perfectionnement du système consiste à permettre à l'utilisateur de publier (ou mettre à la disposition d'un groupe restreint) au moins un sous-ensemble des répertoires de sa toile personnelle. De la même manière que dans l'approche décrite plus haut dans la section Publication de liens Ajoutés , les liens vers des pages contenus dans un répertoire publié pourront être visualisés : - directement au moyen d'un navigateur standard (par exemple suite à la réception d'un email) ; - ou au moyen du système. Le répertoire consulté par l'utilisateur au moyen du système devient son répertoire courant. II peut s'agir d'un de ses propres répertoires ou d'un répertoire publié par un autre utilisateur. L'utilisateur peut manuellement insérer de nouveaux liens dans ce répertoire. L'utilisateur qui visualise le contenu d'un répertoire au moyen du système, peut également enrichir ce contenu en se faisant suggérer des liens à partir d'autres répertoires qui lui sont proposes aans les listes spécialistes , voisins a intérêt , et copains (comme pour le cas des liens Ajoutés). Ces trois listes sont rappelées ci-dessous : 1. Les répertoires Spécialistes sont ceux proposés par l'administrateur du site, et celui-ci peut proposer à l'utilisateur un nombre de répertoires Spécialistes (candidats) plus grand que le nombre de répertoires qui seront présentés dans cette première liste. Le système sélectionne : - d'abord les répertoires spécifiés comme devant être présentés par défaut (s'il en existe), - ensuite, au fur et à mesure de l'acceptation de liens par l'utilisateur (l'acceptation est décrite plus loin dans cette section) dans le répertoire courant, le système sélectionne les répertoires dont les liens sont les plus voisins possibles des liens couramment déjà acceptés (ou gelés) par l'utilisateur. Pour ce faire, le système choisit essentiellement les répertoires contenant le plus de liens en commun avec l'ensemble de liens acceptés (ou gelés) par l'utilisateur au moment courant. Un répertoire Spécialiste peut contenir un nombre de liens supérieur au nombre de liens qui seront suggérés à l'utilisateur. Le système sélectionne alors de préférence les liens associés par le plus grand nombre de liens ajoutés (dans le répertoire Spécialiste candidat) avec des liens qui (dans le répertoire courant) sont déjà acceptés. Bien évidemment, ne seront suggérés à l'utilisateur que les liens qui ne figurent pas déjà dans le répertoire courant. 2. Les répertoires de Voisins d'intérêt sont déterminés automatiquement par le système. Ce sont: - soit des répertoires proches et de même catégorie, qui sont déterminés en amenant le système à sélectionner, parmi les répertoires de même catégorie, ceux qui contiennent le plus de liens en commun avec les liens acceptés (ou gelés) par l'utilisateur. - soit des répertoires contenant le plus de liens en commun avec des liens acceptés (ou gelés) dans le répertoire courant, quelles que soient leurs catégories ; cette approche peut se révéler performante si la sélection de ces répertoires peut se faire en accès direct à partir des liens contenus dans le répertoire courant (voir le type de requête schématisé sur la figure 65) ; en outre, cette approche permet d'associer des catégories aux répertoires automatiquement, car les catégories associées à chaque répertoire déterminé automatiquement sont proposées à l'utilisateur, lorsque ce dernier sélectionne ledit répertoire. Le grand avantage de ce procédé est qu'il permet aux utilisateurs d'associer aux répertoires des catégories appartenant à un vocabulaire commun (le système incite à parler un langage commun ). 3. Les répertoires Copains sont les répertoires choisis par l'utilisateur (Voir la section Publication de liens Ajoutés ). Le principe de Publication et Suggestion étant le même que pour la Publication de liens Ajoutés (voir la section Publication de liens Ajoutés ), nous ne précisons pas ici tous les détails, mais quelques particularités des liens (associés aux répertoires) par opposition aux liens ajoutés (associés aux pages). Dans l'ensemble de liens (vers des pages) qui sont contenus dans le répertoire que l'utilisateur est en train de visualiser, l'utilisateur reçoit des liens supplémentaires à partir des répertoires sélectionnés dans les trois listes sus-décrites (Spécialistes, Voisins, Copains). Comme pour les liens Ajoutés, le système peut avantageusement comporter des moyens pour sélectionner des liens sur la base de critères ( Offreur , Demandeur , etc), données par l'utilisateur ou associés au répertoire visualisé. Les liens qui sont ainsi suggérés à l'utilisateur doivent être distingués de ceux qu'il avait luimême ajoutés : il peut en effet en refuser certains. Dans ce but, les liens peuvent se trouver dans un parmi plusieurs modes différents: Suggéré , Accepté , Refusé (et Gelé , ce dernier mode étant décrit dans la section Liens en mode Gelé ). Les liens reçus par un premier utilisateur, à partir des liens publiés par un deuxième utilisateur (ou à partir d'un des répertoires 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 utilisateur permettant la mise en #uvre de ces changements de mode est schématisée sur la figure 66. Cette figure illustre également le fait que, les répertoires étant visualisés comme des pages, l'utilisateur peut leurs associer des liens ajoutés. On voit ainsi qu'au répertoire ri ont été associés (par la technique des liens ajoutés) les répertoires r2 et r3 ainsi que la page p6. Les moyens de stockage associent donc aux liens un attribut Mode qui peut prendre comme valeur : Accepté, Refusé ou Gelé. La figure 56 présentait un diagramme de classe pour les liens Ajoutés, selon la représentation standard UML ( Unified Modeling Language ), mettant en évidence l'attribut Mode des liens Ajoutés. Nous complétons cette description avec la figure 67 qui montre que les liens (vers les pages) possèdent également un attribut Mode. Cet attribut peut lui aussi prendre la valeur Accepté, Refusé ou Gelé. De plus, la classe Répertoire comporte l'attribut Catégories qui a pour fonction de permettre de comparer des répertoires de même catégorie (indépendamment des noms que les utilisateurs leur ont donné). Un lien en mode Suggéré n'existe que pendant la visite d'un répertoire sélectionné dans l'une des trois listes déjà mentionnées. Il n'est pas affiché en dehors de cette visite. Un lien en mode Suggéré n'est pas stocké dans l'espace de stockage personnel de l'utilisateur car, à chaque nouvelle visite, il est recréé à partir du lien correspondant stocké dans le répertoire source. Le passage d'un lien du mode Suggéré au mode Refusé a pour effet de filtrer automatiquement ledit lien lors des visites ultérieures. Le passage au mode Accepté signifie que l'utilisateur valide le lien qui est en mode Suggéré. Cette action a pour effet : 1. de stocker ledit lien dans son espace de stockage personnel, de manière à ce qu'il lui soit présenté à nouveau avec chaque nouvelle présentation du contenu du répertoire dans lequel ledit lien a été rangé ; cette présentation a lieu mëme si ledit lien a été supprime dans le répertoire qui en était la source) - ceci par opposition aux liens en mode Suggéré qui ne sont plus présentés dès le moment où il sont supprimés dans le répertoire source ; cette présentation a lieu même si le répertoire qui en était la source n'est plus sélectionné (a été décoché). 2. si le répertoire dans lequel ledit lien est rangé est publié, de publier ledit lien d'office (sauf instruction contraire de l'utilisateur) - ceci par opposition aux liens ajoutés en mode Suggéré qui eux ne seront pas publiés. On notera ici que l'insertion d'un lien dans un répertoire (par exemple manuellement en tapant son adresse URL ou par glisser-déposer à partir d'un autre répertoire) entraîne d'office sa mise en mode Accepté (puisque l'utilisateur l'a inséré lui-même). Une page visualisée par l'utilisateur dans le répertoire courant entraîne l'insertion du lien vers ladite page en mode Suggéré dans ledit répertoire. Il n'est donc pas stocké. Toutefois, dès qu'un lien ajouté en mode Accepté est associé à ce lien, ce dernier passe en mode Accepté et le système le stocke donc dans l'espace personnel de l'utilisateur. Section 10 - Liens en mode gelé Le passage en mode gelé signifie que : - non seulement l'utilisateur a validé le lien ajouté, mais de plus - la version courante de la page (vers laquelle pointe ledit lien ajouté au moment où la transition au mode gelé est effectuée) est stockée dans le système afin de garantir à l'utilisateur que ledit lien ajouté (aussi longtemps qu'il n'est pas supprimé) dirigera toujours l'utilisateur sur cette même version de la page dans le futur. Plus précisément, la version courante de la page en question est copiée dans un espace de stockage propre au répertoire courant de l'utilisateur, et le lien pointe maintenant vers cette version stockée. En réalité, pour optimiser la place consommée, il est avantageux que le système ne stocke qu'une seule copie de chaque version différente de page, qui sera partagée par tous les utilisateurs et tous les répertoires possédant ce lien en mode Gelé. Cette optimisation est nécessaire car une même version de page peut être pointée par des liens ajoutés associés à des pages différentes : - d'un même répertoire, - de répertoires différents d'un même utilisateur, ou encore - de répertoires d'utilisateurs différents, et par conséquent une multitude de liens ajoutés gelés pointant sur une même page peuvent exister. Lorsqu'un lien ajouté pointant sur une page est gelé, le système vérifie d'abord si la version courante de ladite page est déjà copiée, le cas échéant le système modifie ledit lien ajouté pour le faire pointer vers cette copie. Pour déterminer si une copie de la version courante de la page existe déjà ou pas : - le système mémorise dans une table, en association avec chaque lien (vers une page) pour laquelle une copie est stockée, la date et l'heure de la copie ; - dans la mesure où une copie existe pour le lien en question et où la copie est récente, le système compare le contenu de la version courante avec celui de la copie, et si les contenus sont identiques, le système évite ainsi de créer une nouvelle copie ; - alternativement, le système peut exploiter les renseignements fournis dans le document source de la page en question pour connaître sa version (et déterminer si elle est différente de la version telle que copiée). Section 11- Contenants et contenus Un va maintenant généraliser les concepts decnts dans les sections précédentes, en considérant des structures Contenants ( Containers en terminologie anglo-saxone) contenant des éléments Contenus ( Contents en terminologie anglo-saxone), à n'importe quel niveau dans la structure des informations gardées par l'utilisateur dans son espace de stockage personnel. Les différents modes d'exploitation des liens ajoutés entre pages décrits par ailleurs dans le présent chapitre pourront, en de nombreuses instances, être étendus à l'exploitation de liens situés dans des contenants inclus directement dans la structure de pages et pointant vers des contenus susceptibles d'être incorporés à la page en question. Les pages sont des documents, eux-mêmes structurées sous forme hiérarchique (par exemple : sections, paragraphes, etc. ), et auxquels est associée une spécification de présentation à l'utilisateur. Dans la suite, on va considérer des documents dont le contenu est spécifié selon la notation standard XML (abréviation de l'expression anglo-saxonne Extended Markup Language), et dont la présentation est spécifiée selon le langage XSL (abréviation de l'expression anglo-saxonne XML Stylesheet Language) ou selon un langage équivalent. Ces technologies se prêtent parfaitement à une structuration hiérarchique des informations. Toute la toile personnelle de l'utilisateur est vue comme une structure arborescente de contenus/contenants imbriqués, chaque contenu étant vu comme un document (ou fragment de document) au format XML auquel est optionnellement associée une spécification de présentation au format XSL. A chaque niveau dans cette structure d'arbre, un contenu ne peut être affiché à l'écran de l'ordinateur de manière autonome que si un document XSL lui est associé. Dans le cas inverse, le Content ancêtre le plus proche ayant un XSL est affiché par défaut. Ainsi par exemple, un répertoire est d'abord un contenu qui peut être présenté à l'utilisateur comme une page autonome, dans la mesure où un document XSL pour la présentation des répertoires lui est associé. Un répertoire a par ailleurs un et un seul contenant dont les contenus sont eux-mêmes des répertoires ou d'autres types de documents. Certains de ces documents peuvent contenir plusieurs contenants, qui eux-mêmes contiennent des contenus, et ainsi de suite. Tous les moyens décrits jusqu'ici pour les répertoires et les pages sont applicables respectivement aux contenants et contenus. Dans ce cas, notamment : - les liens (vers des pages) sont alors des liens vers des contenus ; les liens Ajoutés pointeront également sur des contenus, - et les Coefficients de Probabilité d'Acceptation introduits dans la section Détection de Répertoires Proches sont alors associés à des contenants plutôt qu'à des Répertoires. En partant du fait que l'utilisateur peut copier (ou importer ) un lien d'un répertoire à un autre, la présente section propose un système pour lui permettre d'importer n'importe quel contenu de n'importe quel contenant à un autre (à condition que le type dudit contenu ne viole pas les contraintes de type du contenant qui est censé le recevoir) à n'importe quel niveau dans la structure des informations de l'utilisateur. De même, cette extension du système a pour objet de permettre à l'utilisateur de tirer (c'est-àdire de créer par glisser-déposer) des liens ajoutés de n'importe quel contenu à n'importe quel autre contenu. Ainsi, au lieu de ne pouvoir tirer des liens ajoutés qu'entres pages, entre répertoires et d'une manière mixte entre répertoires et pages, l'utilisateur pourra tirer un lien ajouté entre un élément dans une page et une autre page considérée dans sa globalité, par exemple. Avantageusement, un lien ajouté (et notamment un lien ajouté inverse) pourra pointer sur un contenu enfoui dans une page. Dans le cas où le contenu vers lequel pointe le lien ajouté n'a pas de spécification de présentation (au format XSL) associé, le mécanisme mis en #uvre affichera le plus proche contenu parent (qui le contient) dans la hiérarchie des contenus. On introduira en outre une troisième manipulation offerte à l'utilisateur : la dérivation de contenant, selon laquelle un premier contenant dérivé d'un deuxième contenant reçoit en mode Suggéré tous les contenus du deuxième contenant (ou éventuellement une sélection de ceux-ci) qui sont en mode Accepté (ou Gelé). Cette transmission de contenus se fait en permanence, en ce sens que même les contenus qui sont acceptés dans le futur dans le deuxième contenant sont suggéré dans le premier contenant dès leur acceptation dans le deuxième contenant. Les documents que constituent les pages publiées dans les sites Internet doivent être restructurés pour permettre d'en distinguer les contenus et contenants qui les constituent. Le texte ci-dessous est un exemple simple de document en langage XML : exemple d'informations de toutes sortes exemple informations texte exemple informations texte Un exemple de feuille de style XSL, permettant d'obtenir le rendu, est présenté dans les dix paragraphes suivants. Entête de la feuille de style : Les n#uds du code source pour lesquels aucun traitement particulier n'est prévu sont copiés dans la page HTML : Les attributs du code source pour lesquels aucun traitement n'est prévu prennent les valeurs spécifiés dans le code source : Pour le tag Root, sont ajoutés un titre et un paragraphe : FAMILLE/AMITI E/ETC... Dans la rue, il y a plein de gens : La valeur de l'attribut name est inscrite en caractères gras. Si le n#ud possède un attribut id, la valeur de l'attribut est placée dans le rendu entre parenthèses : (id= ) Si le n#ud possède un attribut myfriend, la valeur de l'attribut est placée dans le rendu entre parenthèses: (ami de ) Si le n#ud possède un attribut myenemies, la valeur de l'attribut est placée dans le rendu entre parenthèses : (ennemi de ) Si un n#ud possédant un attribut name possède des sous-n#uds avec des attributs name, ces sous-n#uds sont présentés dans une liste précédé du label "Enfants :" : Enfants : Si un n#ud possédant un attribut name ne possède pas des sous-n#uds avec des attributs name, le label "Aucun enfant" est affiché : - Aucun enfant La structure de données XML est ici décomposée en un ensemble de contenants et de contenus. Ces derniers contiennent les éléments de la structure XML initiale. Dans un but de classification, les contenants peuvent optionnellement être associés à des catégories, de telle sorte que les contenus qu'ils possèdent soient classés dans cette catégorie. Sur la figure 68, dans la structure arborescente d'un document, on voit apparaître des contenants (illustrés en pointillés). La figure 69 illustre le fait qu'une telle structure permet de prendre des éléments d'un contenant pour les placer dans d'autres par le procédé importation. On décrira également un procédé de dérivation permettant de placer un contenant dans un autre, dans le but de profiter du contenu du contenant d'origine, comme schématisé par la figure 70. La figure 71 illustre le fait que ces manipulations peuvent également être effectuées d'un document à l'autre. On cherche à pouvoir, à partir de pages Internet, restructurer les informations qui s'y trouvent afin de permettre à l'utilisateur de se composer ses propres pages, et ceci à partir de contenants et de contenus qu'il trouve au cours de sa navigation. Cela implique de définir une macrostructure de contenants/contenus, et de dissocier les contenus, qui pourront ainsi être déplacés ou reproduits d'une page à l'autre. Sur cette base, les données XML d'un document de la Toile seront décomposées pour adopter la structure suivante : - un arbre de structure définissant l'imbrication des différents contenants d'information, chacun portant les références de ses contenus ; - une suite de contenus, regroupant les éléments référencés dans les contenants. Etapes de la transformation L'administrateur d'une page d'un site dispose d'un code XML initial (on reprendra l'exemple déjà présenté plus haut), qu'il désire faire partager aux utilisateurs du système . A. Création de la macrostructure Pour que le code source puisse être restructuré et stocké en évitant les redondances, l'utilisateur spécifie quels éléments sont des contenus et à quel contenant chaque contenu appartient. Ceci permet de constituer ce qu'on appelle ici la macrostructure. Les contenants sont spécifiés au moyen d'attributs. Utiliser des attributs plutôt que des balises ( tags en terminologie anglo-saxonne) offre l'avantage de ne pas modifier la structure et ainsi, notamment, de ne pas remettre en cause l'application de feuilles de style XSL. La restructuration est ainsi non intrusive . On va maintenant présenter l'application d'une méthode de spécification de contenus et contenants (en se servant de l'exemple déjà présenté plus haut) au moyen d'attributs : exemple d'informations de toutes sortes exemple informations texte exemple informations texte On notera que : - Hubert est dans un container (CONTAINERNUMBER= "1") différent de celui d' Antoine , Edouard et Raymond (CONTAINERNUMBER= "2"). - les attributs myfriend et myenemies sont des références aux n#uds de l'arbre, car ils ont été spécifiés comme tels (type idref ) par le schéma associé au code source en langage XML. Remarques : 1- La macrostructure permet de dissocier les éléments, de la structure dans laquelle ils résident. Ainsi, les éléments sont stockés de manière unique sur le serveur quel que soit le nombre de fois où ils ont été reproduits. 2- Par défaut, sans aucune intervention manuelle, la macrostructure pourrait être automatiquement calquée sur la structure du document. La granularité du partage (granularité des éléments qui peuvent être répliqués) serait alors celle des éléments du document. Mais le système serait alors lourd à manipuler pour l'utilisateur, la macrostructure serait volumineuse et les performances s'en ressentiraient. L'approche que nous présentons consiste à permettre de spécifier la macrostructure explicitement dans les documents, c'est-à-dire de choisir la granularité des contenus qui peuvent être partagés. Ainsi, lors de la spécification d'un contenu, celui-ci est, par la même occasion, localisé dans un contenant qui peut regrouper plusieurs contenus. Comme les contenus auraient pu être calqués sur la structure des éléments du document, les contenants auraient pu être calqués sur la structure des contenus (tous les contenus enfants d'un même parent auraient alors été mis dans un contenant). On a préféré ici spécifier explicitement quels contenus sont situés dans quels contenants. B. Code décomposé A partir des indications figurant dans le nouveau code source, est construite la structure décomposée, constituée d'une part par l'arbre de structure et d'autre part la suite de contenus. Dans notre exemple, l'arbre de structure est la suivante : (Container où se trouve Hubert) (Container où se trouvent Antoine, Edouard et Raymond) La suite de contenu est la suivante : exemple d'informations de toutes sortes exemple informations texte exemple informations texte Comme on peut le voir, toutes les données d'arbre de départ sont séparées dans la suite de contenus. L'arbre de structure représente l'imbrication des contenants entre eux. L'imbrication entre Root et Henri ne figure pas dans l'arbre de structure car Root et Henry sont dans le même contenu. Par contre, l'imbrication entre Anatole et Hubert , Edouard , Antoine et Raymond est reflétée dans l'arbre de structure, car Hubert , Edouard , Antoine et Raymond sont regroupés dans deux contenants différents sous Anatole . De plus, on constate que les contenants peuvent être disposés de façon bien précise dans les contenus. On parlera de positionnement. Les contenus dans lesquels se trouvent des contenants portent une balise indiquant où les contenants se trouvent (au moyen d'un numéro POSITION~CONTAINER N). Les positions dans les contenus sont utilisés dans l'arbre de structure. Chaque contenant est en effet imbriqué sous une balise POSITION~CONTAINER ayant un numéro. Ce numéro correspond à l'indication N figurant dans les contenus. Ceci est illustré sur la figure 72. Lorsque certaines balises possèdent des références à d'autres balises, cela est matérialisé dans l'arbre de structure et dans la suite de contenus au moyen de la balise POSITION~ELTREFS. La même approche que pour le positionnement des contenants est utilise. La position de références à des éléments est matérialisée dans un contenu à l'aide d'un numéro POSITION ELTREFS N, que l'on retrouve dans l'arbre de structure, dans le champ CONTENTREF correspondant. Cette indirection permet de retrouver, dans la structure arborescente de contenants, le contenu où se trouve l'élément référencé. Ceci est illustré à la figure 73. Détail de la macrostructure décomposée a. Arbre de structure 1. Balise CONTAINER Cette balise représente un contenant au sein de l'arbre de structure. Un contenant est identifié par une adresse URL dénommée SRC. Cette adresse URL est composée du nom de domaine où le contenant est archivé, et de l'identifiant local de ce contenant pour le domaine. Si plusieurs serveurs sont associés à un nom de domaine, alors ce nom de serveur est spécifié dans l'adresse URL entre le nom de domaine et l'identifiant local : SRC : DomainName/ServerName?ID Cette balise comporte également un attribut indiquant à quelle catégorie est associé le contenant. Cette catégorie est spécifiée au moyen d'une adresse URL. Un contenant est composé de plusieurs balises CONTENTREF (voir définition précise ciaprès) qui renvoient au contenu dans la succession de contenus. De plus, un contenant peut être dans un contenu à une position donnée, selon la balise POSITION~CONTAINER (définie ci-après) désignant la position à laquelle il se trouve. Par exemple : 2. Balise CONTENTREF Cette balise constitue une référence à un élément donné CONTENT de la succession de contenus. Il est identifié par un identificateur entier ID , et porte un attribut SRC qui est l'identifiant unique du contenu CONTENT référencé. La même syntaxe d'adresse URL que pour les contenants est adoptée. Les balises CONTENTREF comportent également un nom NAME : 3. Balise POSITION CONTAINER Cette balise permet de matérialiser les différentes positions où on peut trouver des contenants dans un contenu. Comme le montre l'exemple ci-après, une balise CONTENTREF peut contenir plusieurs balises POSITION~CONTAINER, c'est-à-dire que des contenants peuvent être disposés à plusieurs endroits du contenu en question. De plus, à une position donnée, il est possible de trouver plusieurs contenants, comme dans l'exemple suivant : b. Suite de contenus 1. Balise CONTENT Cette balise représente un contenu. Un contenu peut contenir une ou plusieurs balises du code source XML d'origine. Les contenus sont identifiés par un identifiant unique, et portent l'adresse URL de la catégorie à laquelle ils appartiennent, comme dans l'exemple suivant : Il se peut que certains cas conduisent à la création de contenus : (i) soit des contenus externes, à savoir un contenu qui pointe sur un autre contenu d'un hôte différent (de catégorie externe), par exemple : (ii) soit des contenus indirects, à savoir un contenu qui pointe sur un autre contenu du même hôte (mais de catégorie différente), par exemple : 2. Balise POSITION~CONTAINER Cette balise indique la position où un contenant peut être inséré dans un contenu, par exemple : 3. Balise POSITION ELTREFS Cette balise permet de matérialiser, dans le contenu, les références que certaines balises portent sur d'autres. Comme les balises POSITION CONTAINER , ils portent un attribut entier N indiquant leurs positions dans le contenu. Ils possèdent également un attribut ATTRIB qui contient le nom de l'attribut utilisé par l'auteur du code source XML pour définir la référence. Par exemple : C. Recomposition des pages de la Toile La figure 74 illustre le fait que l'internaute dispose d'un accès supplémentaire à l'information. Il peut y accéder de façon classique en se connectant sur le site source de la Toile, et il peut également y accéder via le système, qui lui permet d'interagir avec les contenants et les contenus, c'est-à-dire les organiser selon sa volonté. Le système décompose ce site en contenants/contenus (ce site doit impérativement avoir été mis par son administrateur sous la forme déjà décrite auparavant, à savoir la forme dans laquelle l'administrateur a notamment indiqué où se trouvent les contenus et contenants). Afin d'être présentées à l'internaute, les informations en sortie du système sont reconstituées et transformées à l'aide de la feuille de style XSL associée au code XML d'origine. Pour permettre la manipulation de poignées (qui permettent de désigner graphiquement des contenus, la feuille de style XSL ajoute à la volée, dans la spécification XSL d'origine, du code de présentation. Ce procédé est schématisé sur la figure 75. D. Code XML reconstitué Afin de pouvoir être présenté à l'internaute, le code XML décomposé est reconstitué. On peut ainsi lui appliquer une feuille de style XSL. Lors de la reconstitution, il est fait en sorte que les contenus et les contenants soient matérialisés pour que l'utilisateur puisse les manipuler. A cet égard, comme on va le voir par la suite, l'internaute peut sélectionner un contenu ou un contenant au moyen de poignées pour les déplacer où les mettre dans un autre document. Pour l'exemple traité jusqu'ici le code reconstitué est le suivant : Exemple d'informations de toutes sortes CATEGORY="url3"/> Exemple informations texte exemple informations texte Exemple de présentation A partir du code XML reconstitué, une page HTML de présentation est construite au moyen d'une feuille de style XSL. Dans le cadre de l'exemple présenté en introduction de cette section, la même feuille XSL est reprise, à ceci près qu'on lui a ajouté des éléments de dérivation (c'est-à-dire les poignées) permettant d'interagir avec le contenu de la page. Dans la suite, on va décrire précisément en quoi consistent ces éléments de dérivation, puis comment se passent les actions d'importation/dérivation et leur conséquence : la suggestion. A. Insertion de poignées d'importation/dérivation On définit à l'aide d'un modèle ( Template en terminologie anglo-saxonne) la transformation en langage HTML des informations de la structure qui permettent la dérivation, l'importation et l'association de liens ajoutés. Les contenants ne peuvent pas être représentés en tant que tels, car ils ne correspondent pas forcément à une enveloppe (à savoir à un objet graphique unique) vue graphiquement dans la page HTML résultante. C'est pourquoi cette transformation donne un élément graphique (élément de dérivation) pour chaque n#ud de type contenu. Cet élément de dérivation permet la gestion du glisser-déposer à la fois des contenants et des contenus. En effet, un composant BEHAVIOR (voir l'Annexe) attaché à l'élément communique alors avec le système. Le modèle précité est ajouté en fin de la page XSL afin de la surcharger efficacement et pour que les éléments de dérivation soient effectivement affichés. L'allure de ce modèle peut par exemple être la suivante : 0]"> BEHAVIOR :url(.../system.dragndrop.htc) ; this.nodeName this.setAttribute("CONTAINERID",0) L'élément DIV (introduit en 3e ligne) est un élément de dérivation auquel est associé le composant BEHAVIOR :url(.../system.dragndrop.htc) , dont l'allure est présentée en Annexe. Ce composant permet une gestion du glisser-déposer des éléments pour la dérivation de contenants qu'il communiquera au système. B. Réception de l'événement ONDERIVE Lorsque le composant BEHAVIOR déclenche l'événement ONDERIVE, par l'instruction fire("ONDERIVE",oEvent) qui se trouve dans la fonction FinishDrag (la variable oEvent étant un objet événement dans lequel sont disponibles les informations (identifiants des éléments source et cible) qui permettent la dérivation et 1'importation), le système est alors averti et réalise les actions suivantes : 1- il demande si l'utilisateur désire importer le contenu ou dériver le contenant ;. 2- il envoie la requête d'importation/dérivation ; 3- il vérifie si la page d'affichage est capable de prendre en compte la nouvelle source ; 4- il déclenche le rafraîchissement de l'affichage, de la façon suivante : a. si la page est figée, reconstruction et traitement global de la source ; b. si la page est dynamique, simple notification d'insertion de données. Dans ce cas, la page reçoit la notification. Cet événement fournit un pointeur sur un objet qui permet au script de la page de transformer cette nouvelle source (à l'aide, par exemple, de la feuille XSL qui l'a initialisée) et d'insérer le code HTML résultant dans la page. C. Manipulation de la macrostructure L'élaboration de la macrostructure de contenants/contenus permet : - de placer de nouveaux contenus dans un contenant ; on parle alors d'importation de contenus ; - de reproduire un contenant au sein d'autres contenus ; on parle alors de dérivation de contenants. Importation Supposons que l'on soit dans la situation illustrée dans la figure 76 : contenants 1 et 2 ( Container 1 et Container 2 ) sont rattachés à la catégorie 1 (symbolisé par la flèche grise). Dans le contenant 1 figure une référence au contenu 1.1( Content 1.1 ), et dans le contenant 2 figure une référence au contenu 1.2 ( Content 1.2 ) (ces références sont symbolisées par des flèches noires). Importer le contenu 1.1dans le contenant 2 revient à créer, dans ce contenant, une balise CONTENTREF qui pointe vers le contenu 1.1dans la suite de contenus. Ceci se traduit par la figure 77. Quand on importe un contenu d'une catégorie dans un contenant associé à une catégorie différente, on dit que l'importation provoque une re-catégorisation. Ceci se traduit par la création d'un contenu indirect, c'est à dire d'une balise similaire à une balise CONTENTREF mais qui s'en distingue par le fait qu'elle figure dans la suite de contenus, au sein d'une catégorie. Ceci est illustré sur la figure 78. Dans le cas où les contenus importés possèdent des contenants, ces derniers sont dérivés suivant le mécanisme décrit ci-après. Dérivation Supposons que l'on dispose de l'imbrication contenant/contenu présentée sur la figure 79. Dériver le contenant 1 revient à l'insérer dans un contenu à une certaine position . Pour ce faire, un nouveau contenant est créé dans l'arbre de structure, et pointe (c'est-à-dire possède une référence, matérialisée par une flèche grise sur le schéma de la figure 80a) vers le contenant que l'on veut dériver. Sur le serveur, la structure de données a alors la forme suivante pour la partie dérivée : - pour l'arbre de structure : - pour la suite de contenus : Comme on peut le voir sur la figure 80a, le contenant 126 ne référence aucun contenu. Il a juste une référence sur le contenant source, à savoir celui à partir duquel on a effectué la dérivation. Le chargement des données dans le contenant dérivé se fait donc via le contenant source : il s'agit ici de suggestion . Cela conduit, sur le poste client, à la disposition illustrée sur la figure 80b. Les sous-contenants sont dérivés exactement de la même manière que le premier contenant : un nouveau contenant est créé et pointe vers le sous-contenant source. La profondeur à laquelle on charge les éléments dans le contenant dérivé est fixée par un mécanisme de chargement progressif car, sinon, il pourrait se présenter des cas de boucles infinies dans le chargement. En effet, il est possible de dériver des contenants dans eux-mêmes, comme le montre la figure 81, et de créer ainsi une structure virtuellement infinie. Sans ce mécanisme, charger un contenant provoquerait alors une boucle infinie dans le cadre d'une structure réellement infinie. Cas de la superposition de contenants Comme on l'a déjà évoqué, les contenants sont insérés en des positions bien précises des contenus. Mais rien n'empêche d'insérer plusieurs contenants à une même position. On parle alors de superposition de contenants. Partons de la structure présentée dans la figure 82 (en notant que les éléments situés dans un cadre en pointillés sont considérés comme étant dans un contenant). Cela se traduit ainsi : - pour l'arbre de structure : - pour la suite de contenus : Supposons maintenant que l'on dérive le contenant 13 (celui qui contient le contenu C) dans le contenu 44 (qui correspond au contenu B) à la même position que le contenant 14 (qui contient le contenu D). La balise correspondant au contenu 44 dans la suite de contenus ne sera pas modifiée. En effet, le contenu conserve une seule position pour les contenants, même si deux contenants sont superposés sur cette position. Cette superposition se manifeste au niveau de l'arbre de structure par le fait qu'un nouveau contenant est ajouté sous la balise POSITION N=l, comme indiqué ci-dessous : Mécanisme de Suggestion de nouveaux contenus (propagation dans la macrostructure) Le fait de dériver un contenant implique qu'il est possible d'accéder aux contenus acceptés présents dans le contenant d'origine. Ces contenus sont en fait automatiquement suggérés dans les contenants dérivés au fur et à mesure de leur insertion. C'est à l'utilisateur de préciser s'il accepte ou non les suggestions, comme décrit par ailleurs. Il est à noter que seuls les contenus acceptés pourront être dérivés à leur tour. La suggestion peut ainsi se faire entre des utilisateurs différents (par exemple lorsqu'un utilisateur dérive un contenant d'un document dont il n'était pas l'auteur), mais également lorsqu'un même utilisateur dérive un contenant entre deux de ses propres documents. Lorsqu'un utilisateur dérive un contenant, il crée un nouveau contenant portant la référence du contenant source, et les contenus du contenant source qui étaient en mode Accepté y sont chargés. Ces contenus sont initialement en mode Suggéré , et l'utilisateur peut modifier leur mode. Sur le plan de la base de données contenue dans le serveur, le contenant dérivé ne contient aucune information sur les contenus suggérés. Ces informations peuvent en effet être retrouvées via la référence sur le contenant source. En revanche, sur le poste client où ce contenant a été dérivé, une balise CONTENTREF est ajoutée pour chaque contenu chargé dans ce contenant, avec un attribut MODE=SUGGESTED. Ce qui est suggéré peut être accepté ou refusé (ou encore laissé en mode suggéré). Cet éventuel changement de mode est répercuté par une mise à jour de la base de données sur le serveur, de la façon suivante : - si le contenu est accepté : une balise CONTENTREF vers ce contenu est ajoutée dans la base de données dans le contenant dérivé, avec un attribut MODE=ACCEPTED. - si le contenu est refusé : une balise CONTENTREF vers ce contenu est également ajoutée dans la base de données dans le contenant dérivé, avec un attribut MODE=REFUSED ; l'objectif dans ce cas est de noter que ce contenu ne doit pas être présenté à l'utilisateur à la prochaine connexion. La mémorisation correspondant à ces différents cas est schématisée sur la figure 83. Section 12 - Proposition de Répertoires Spécialistes et Voisins On a vu dans la section précédente que, dans le cadre d'une page à laquelle l'utilisateur accède sur la Toile par des moyens standards, peuvent se trouver des contenants, et que dans chaque contenant peuvent se trouver des liens vers des contenus. Ces liens sont ceux choisis par l'administrateur du site d'où la page est issue comme devant être présentés par défaut. Ces liens sont censés être en mode Suggéré. L'utilisateur, par l'intermédiaire du système, peut modifier leur mode, pour leur donner la valeur Accepté, Gelé ou Refusé, en accédant à cette même page avec le système. Au lieu de présenter des mêmes liens à tous les utilisateurs, la fonctionnalité de proposition de répertoires Spécialistes (déjà décrite dans les sections Publication de Liens Ajoutés et Publication de Répertoires ) permet de présenter plusieurs points de vue sur un sujet, selon une métaphore de visite des toiles personnelles de Spécialistes . Avec ladite page, l'utilisateur peut aussi recevoir des liens ajoutés (qui y ont été associés par l'administrateur du site ou par les Spécialistes qu'il aura sélectionnés). Grâce à la fonctionnalité de proposition de répertoires Spécialistes, les liens ajoutés ne seront suggérés qu'en relation avec une visite de répertoire et ne surchargeront ainsi pas la page d'emblée. Dans l'exemple que l'on prendra tout au long de cette section (voir figure 84a), pour une page sur le foie gras, des Spécialistes (ici des Chefs) différents présentent : - associés à la page, des liens ajoutés sur des vins (Sauterne) et salades (Mesclun) différents ; - à l'intérieur d'un contenant de la page, des liens sur différents types de foie gras (Canard, Oie). L'utilisateur peut alors accepter certains liens ajoutés et/ou des liens situés à l'intérieur de contenants de la page, qui lui sont ainsi suggérés. On notera que, dans ce cas, non seulement l'attribut Mode du lien ajouté mais aussi l'attribut Mode du lien dans le répertoire courant, pointant sur la page à laquelle est associé ce lien ajouté, est mis à jour à la valeur Accepté . L'acceptation remonte ainsi d'enfant à parent récursivement. Ainsi l'attribut Mode du lien pointant sur le répertoire courant, dans le répertoire qui le contient, le cas échéant, est aussi mis à jour, et ainsi de suite. Il en est de même pour les liens situés dans les contenants de la page. Toutefois, en général, l'utilisateur n'accepte pas un lien ajouté (ou un lien dans un contenant) pointant sur une page P, sans au préalable cliquer sur lui pour visualiser la page P qu'il pointe. Ensuite, si la page P l'intéresse, il l'accepte directement, sans retourner accepter le lien ajouté d'où il est venu. En d'autres termes, au lieu d'accepter le lien ajouté (ou le lien dans un contenant) pointant sur P, il accepte la page P elle-même, c'est-à-dire le lien pointant sur ladite page P dans le répertoire courant qui l'accueille. Un perfectionnement du système consiste alors à suivre le parcours de l'utilisateur qui clique sur un lien ajouté pour que, quand la page cible est acceptée, le système mette également à jour l'attribut Mode du lien ajouté par l'intermédiaire duquel il a accédé à cette page. En acceptant un lien ajouté (ou un lien situé dans un contenant de page) l'utilisateur déclare son intérêt pour les contenus vers lesquels pointent ces Liens. Son profil d'intérêt se construit ainsi progressivement, et lorsqu'il atteint un seuil de représentativité, le système peut lui proposer des répertoires proches dans la liste de répertoires Voisins d'intérêt (voir la liste Copains dans la figure 84a). Dans le cas où, comme dans l'exemple de la figure 84a, la page courante comporte non seulement des liens ajoutés (Sauterne, Mesclun), mais aussi des liens dans au moins un contenant (Canard, Oie) se trouvant dans la page, le système sélectionne des répertoires qui sont proches: - par rapport aux liens ajoutés acceptés associés à la page courante : le système sélectionne les répertoires dans lesquels se trouve la page courante ainsi qu'un grand nombre de liens ajoutés en commun, comme décrit dans la section Détection de Répertoires Proches ; - par rapport aux liens acceptés) se trouvant dans chaque container se trouvant dans la page : le système sélectionne les répertoires contenant le plus grand nombre de liens en commun avec ledit contenant, comme décrit dans la section Publication de Répertoires . On observera ici que le système peut exploiter non seulement les liens (liens ajoutés et liens dans les contenants) acceptés et gelés, mais aussi les liens refusés. Il est en effet intéressant de considérer ce que l'utilisateur n'a pas retenu dans les liens qui lui ont été proposé pour construire son profil. Le système exploite ces mêmes données (liens ajoutés et liens dans les contenants) pour ajuster les répertoires Spécialistes proposés à l'utilisateur. Ceci est décrit dans les sections Publication de Liens Ajoutés et Publication de Répertoires . En lui proposant un ensemble de répertoires proches, le système permet à l'utilisateur de visiter les toiles personnelles d'un ensemble d'autres utilisateurs, avec qui il peut par ailleurs se mettre en contact, comme déjà décrit dans le section Détection de Répertoires Proches . L'utilisateur peut cliquer sur un lien (vers contenu) dans un contenant de la page, ou sur un lien ajouté pour accéder au contenu en question. Le système lui propose alors les répertoires Spécialistes , Voisins et Copains pour ce nouveau contenu, et ainsi de suite. Enfin, l'utilisateur peut sélectionner un ensemble de liens ajoutés, ou un ensemble de liens dans un contenant, pour demander au système de lui sélectionner des répertoires proches compte-tenu de cet ensemble. L'homme du métier saura facilement étendre les procédés décrits jusqu'ici pour mettre en #uvre cette fonctionnalité. Section 13 - Attributs relatifs à l'acceptation Lors de l'acceptation (passage au mode Accepté ou Gelé) d'un contenu, l'utilisateur peut spécifier s'il y est intéressé pour l'acheter, le vendre, et/ou pour d'autres intérêts qu'il y porte le cas échéant, en fonction du type de contenu. Ces spécifications se font en donnant des valeurs à des attributs que le système prend en compte lors des sélections de répertoires (Spécialistes et Voisins) qu'il propose à l'utilisateur, ainsi que pour sélectionner le contenu de ces derniers le cas échéant (voir les sections Détection de Répertoires Proches , Suggestion de Liens Ajoutés par l'administrateur d'un site , Publication ae répertoires et rroposmon ae répertoires spécialistes et Voisins ). L'utilisateur qui accède à une page (page courante), peut spécifier des critères sur ces attributs pour restreindre l'ensemble des répertoires (Spécialistes et Voisins) qui lui sont proposés en relation avec ladite page courante. Ainsi, si par exemple il est intéressé par l'achat du produit présenté dans la page courante (ou dans un ensemble de pages qu'il sélectionne), il pourra s'intéresser sélectivement aux répertoires d'utilisateurs : - intéréssés à vendre ce produit (recherche de fournisseurs de ce produit), - ou intéréssés comme lui à acheter ce produit : il pourra ainsi se joindre au groupe d'utilisateurs intéressés par cet achat et augmenter l'influence de ce groupe pour faire baisser le prix du produit chez un fournisseur, éventuellement à l'aide d'une procédure automatisée (d'aide à l'achat groupé ) qui se déclenche quand ce critère est utilisé. Dans le premier cas l'utilisateur recevra, à partir des répertoires de vendeurs ainsi sélectionnés, des liens en mode suggéré concernant des offres particulières pour le produit présenté dans la page courante ainsi que sur d'autres produits proposés par ces vendeurs. Dans le deuxième cas, l'utilisateur bénéficiera des découvertes des autres utilisateurs (acheteurs potentiels) ayant des intérêts (et/ou goûts) proches. Rapelons que les utilisateurs du système sont anonymes et peuvent y accéder en utilisant un pseudonyme. On va maintenant décrire une mise en #uvre particulière de cet aspect de l'invention. *Seuls deux attributs sont mis en #uvre : Demandeur et Offreur . Lors de l'acceptation d'un lien, en utilisant l'interface illustrée aux figures 55b et 66 (qui notamment lui permettent de changer le mode du lien de suggéré en accepté ou en gelé ), l'utilisateur a deux cases à cocher à sa disposition, à savoir : Demandeur et Offreur . Cette configuration est illustrée schématiquement à la figure 84b. 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 lien dans la toile personnelle 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 ; voir la figure 55a) 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 de l'application d'achat groupé sus-mentionné, 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). Section 14 - Pages Personnalisées Les documents restructurés comme décrit dans la section précédente permettent de présenter, dans des contenants, des contenus sélectionnés en fonction des centres d'intérêts de l'utilisateur. On va maintenant décrire une façon dont peut être effectuée cette sélection. Rappelons tout d'abord que tout contenu accepté par l'utilisateur dans un contenant adopte la catégorie de ce contenant (comme on l'a décrit notamment plus haut dans le présent chapitre et comme on y reviendra dans le chapitre III), en plus des catégories des autres contenants dans lesquels l'utilisateur a aussi accepté ce contenu le cas échéant. Dans la mesure où le système connaît les catégories des contenants imbriqués dans un contenu 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 contenus de chacune desdites catégories, il existe d'autres catégories qui ont été attribuées par l'utilisateur à ces mêmes contenus. 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 contenu 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 contenus 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 contenus qui possèdent non seulement la catégorie guitare , mais également la catégorie objet 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 contenu appartenant à ces deux catégories simultanément, le système propose alors à l'utilisateur les contenus appartenant simplement à la catégorie guitare . Le critère supplémentaire sera ainsi pris en compte comme étant une préférence . On comprend donc que les contenus 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 contenus en question, de manière à modifier la structure XML de la page considérée si l'administrateur le juge opportun. Le procédé d'auto-épuration décrit en détail dans le chapitre suivant permettra d'automatiser, dans une certaine mesure, le filtrage des catégorisations considérées comme qualitativement mauvaises ou non fiables. * * * Chapitre III - Processus de suggestion généralisé (Figures 85 à 134) Ce chapitre vise un cadre différent pour le processus de suggestion décrit plus haut dans les dernières sections du chapitre II ainsi que différentes extensions de ce processus. Ce processus va être décrit ci-dessous à des niveaux de fonctionnalités et de sophistication croissants. On présentera d'abord (Section 1) les structures et les procédés fondamentaux de chaque niveau. La présentation de chaque niveau s'appuie sur les niveaux précédents. Dans la Section 2, on décrira les procédés annexes de filtrage par apprentissage de fiabilité de l'information. La Section 3 présente le principe de suggestions automatiques par rapprochement d'intérêts, et la section 4 présente un perfectionnement des mécanismes de suggestion automatique qui exploite l'avantage du graphe de dérivations entre utilisateurs. Ensuite sont présentés les méthodes de renforcement de l'anonymat des Utilisateurs et les modèles économiques possibles (Section 5). La Section 6 présente l'exploitation du mécanisme de dérivation/suggestion/acceptation décrit dans la première section pour la fidélisation des utilisateurs en exploitant leur fibre de collectionneur. La section 7 présente les principes d'une application concrète en XML. Section 1 - Structure etprocédé fondamentaux A. Bref rappel de la notation UML Considérons la structure hiérarchique schématisée ci-dessous : Contenant-1 Contenus Contenu-1 Contenu-2 Sous-Contenants Contenant-11 Contenus Sous-Contenants Contenant-12 Contenant 2 Cette structure hiérarchique est spécifiée sur la figure 85 des dessins qui est un diagramme de classe selon un standard connu de Modélisation Orienté-Objet, noté UML (voir en particulier UML Reference Manual - Rumbaugh, Booch, Jacobson, 1999). Il s'agit d'une structure hiérarchique arborescente d'Eléments ( Elt ), chaque Elément étant un Contenant ou un Contenu , les Contenants pouvant contenir des Eléments (ce sont leurs Sous-éléments SousElt ), tandis que les Contenus ne peuvent pas contenir d'éléments. Les Utilisateurs du système selon l'invention utilisent une telle structure arborescente d'Eléments. B. forme de réalisation de base (niveau 1) Tous les Utilisateurs du système utilisent la même structure de Contenants. Mais, dans de mêmes Contenants, chaque Utilisateur regroupe des Contenus qui peuvent être différents d'un Utilisateur à l'autre. Tous les Contenus de tous les Utilisateurs - sauf les Contenus confidentiels (voir plus loin) sont regroupés, dans leurs Contenants respectifs, dans une Base de Données Commune, notée BD , accessible par tous les Utilisateurs . On appelle ici Profil l'ensemble des Contenus d'un Utilisateur donné pour un Contenant donné. Le diagramme de classe correspondant est illustré sur la figure 86. Le système décrit ici offre pour les Utilisateurs une garantie d'anonymat : ainsi un Utilisateur ne peut pas accéder aux Profils d'un autre Utilisateur (les Profils sont confidentiels), bien qu'il puisse accéder à tous les Contenus (non confidentiels), puisqu'il peut consulter l'ensemble de la Base de Données Commune. En d'autres termes, la Base de Données Commune mémorise, dans chaque Contenant, l'union des Profils des Utilisateurs pour ce Contenant, sans permettre de distinguer les Profils euxmêmes. De là, un Utilisateur est incapable de déterminer dans quels Profils est référencé un Contenu donné auquel il accède dans la Base de Données Commune. Cette organisation est schématisée sur la figure 87. Lorsqu'un Contenu est modifié par un Utilisateur (bien entendu, à condition qu'il en ait le droit, par exemple s'il est le créateur de ce Contenu), les autres Utilisateurs, ayant ce Contenu dans leurs Profils respectifs, le voient mis à jour automatiquement dès qu'ils accèdent à la BD Commune pour la première fois postérieurement à ladite modification. L'Utilisateur peut consulter la BD Commune. Il peut s'y abonner pour être automatiquement informé des ajouts de Contenus dans certains des Contenants, de façon sélective (par exemple au moyen de la puissance d'expression d'un langage classique de requêtes à une Base de Données). Le fait d'être informé automatiquement est ce qu'on appelle un procédé de suggestion , dont on donnera davantage de détails dans la suite. On va maintenant décrire un certain nombre de fonctionnalités possibles offertes aux Utilisateurs. a) Ajout et Suppression de Contenu Direct L'Utilisateur peut choisir d'ajouter dans un de ses Profils : * des Contenus qu'il aura puisé dans le Contenant lié à ce Profil * des Contenus qu'il aura puisé dans d'autres Contenants * ou encore de nouveaux Contenus qui n'existaient dans aucun Contenant (qu'il aurait par exemple collecté par navigation sur le réseau Internet). Quelle que soit sa provenance, si un Contenu ajouté dans un Profil n'existait pas déjà dans le Contenant lié à ce Profil, il y est ajouté. Les autres Utilisateurs peuvent alors en prendre connaissance. On notera ici que, dans la pratique les Profils peuvent ne pas être directement composés de Contenus, mais de Références à ces derniers, ou encore d'un mélange de Contenus et de Références à des Contenus. La figure 88 illustre le diagramme de classe associé, qui comporte en particulier un lien entre Contenu et Référence à Contenu). Dans un Profil, un Contenu peut posséder l'un parmi trois attributs, à savoir Suggéré , Accepté ou Refusé . Un Contenu Suggéré signifie que ce Contenu est reçu dans le Profil, sans pour l'instant avoir été accepté ou refusé par l'Utilisateur qui possède ce Profil. Les Contenus étant dans cet état ne sont pas stockés de manière permanente (c'est-à-dire qu'une Référence n'est pas encore créée dans la BD de Profils). Accepter un Contenu signifie que le système crée de manière permanente une Référence à ce Contenu. Les Contenus Acceptés sont stockés dans le Profil de manière permanente. Il est ainsi à observer ici que l'acceptation au sens du présent chapitre correspond au mode Gelé décrit dans le chapitre II. Un Contenu dont la présence dans un Profil est Refusée ne peut être supprimé directement dans le Contenant (c'est-à-dire dans la Base de Données Commune, où le Contenu est réellement stocké), car ce Contenu peut auparavant avoir aussi été Suggéré ou Accepté dans un autre Profil. Il ne pourra être réellement effectivement supprimé que lorsque plus aucun un autre Profil ne contiendra une Référence à ce Contenu. En attendant, c'est l'attribut Refusé qui matérialise la suppression virtuelle voulue par un Utilisateur. La Référence ayant cet attribut est toutefois stockée de manière permanente et sert à éviter de suggérer à nouveau un Contenu qui a précédemment été Refusé . b) Références à des Contenus d'autres Contenants ou à des Contenus externes (Contenus Indirects) Dans une forme de réalisation particulière, le système peut permettre aux Utilisateurs d'insérer dans un Contenant (via leurs Profils respectifs), une Référence à un Contenu appartenant déjà à un autre Contenant. Ceci est préférable à l'insertion d'une copie de ce Contenu. Bien entendu, cette Référence ne pourra exister que tant que le Contenu référencé existe. Nous appelons cette référence Contenu Indirect , et le Contenu Référencé est appelé Contenu Direct . Avantageusement, à chaque nouvel accès à la Base de Données Commune, dans le cas où le Contenu Direct a été entre-temps modifié, l'Utilisateur voit, à travers le Contenu Indirect, ce Contenu dans sa nouvelle version. Le diagramme de classe UML associé est illustré sur la figure 89. Supprimer un Contenu Direct implique au préalable de gérer les Contenus Indirects qui lui sont liés. Ils n'auront en effet plus lieu d'exister, mais comme expliqué précédemment, ils ne pourront être effectivement supprimés que quand plus aucun Profil ne les référencera. La suppression d'un Contenu Direct consistera donc en 3 types d'actions qui ne se sont pas nécessairement exécutées immédiatement : (1) suppression, dans les Profils, des Références au Contenu Direct et aux Contenus Indirects qui lui son liés, (2) suppression de ces Contenus Indirects, (3) suppression du Contenu Direct lui-même. Un Utilisateur, qui a référencé dans son Profil un Contenu Indirect pour lequel il est averti d'une suppression prochaine, pourrait vouloir créer une copie du Contenu Direct référencé à la place du Contenu Indirect, afin de ne pas perdre l'information. Le système peut être conçu pour lui en laisser la possibilité. Les Contenus Indirects peuvent aussi constituer des références à des contenus externes au système, et notamment des liens vers des éléments trouvés sur l'Internet. Le système comporte alors des moyens de mise à jour (ou gestion des erreurs d'accès) en cas de suppression des contenus externes. c) Popularité d'une catégorisation Le fait d'insérer un Contenu dans un certain Contenant (via un Profil) revient à le catégoriser . Un Contenant est en effet censé regrouper des Contenus de même catégorie. Différents Utilisateurs peuvent classer un même Contenu dans des Contenants différents, de manière directe (en en faisant une copie) ou au moyen d'une indirection (Contenu Indirect). On appelle ici Popularité le nombre de fois qu'un Contenu se retrouve dans des Profils associés à un même Contenant, ou plus généralement une variable représentative de ce nombre. Dans le cas où l'Utilisateur hésite entre deux catégorisations possibles, il préférera en général le Contenant le plus populaire, afin de parler le même langage que le plus grand nombre d'Utilisateurs et de bénéficier ainsi de services de rapprochement de profils et d'autres avantages tels qu'on les décrira dans la suite. L'avantage essentiel de cette forme de réalisation de base de l'invention peut être résumé par ce qui suit, en référence à la figure 90 : - tout d'abord, un Utilisateur A, pour ses besoins propres de catégorisation et mémorisation d'informations (ceci est une incitation suffisante), va au fil du temps ajouter à son propre Profil A de nouveaux Contenus, dans des Contenants représentant des catégories partagées ; - par le fait qu'il utilise ces Contenants, l'Utilisateur parle le même langage que les autres Utilisateurs et bénéficie ainsi d'avantages supplémentaires (tel que la suggestion automatique d'informations par rapprochements de profils, etc, décrits dans les sections suivantes) en échange du fait qu'il contribue à la BD Commune - la BD Commune est ainsi alimentée de manière automatique et transparente, et un autre Utilisateur B peut la consulter ou être automatiquement et spontanément renseigné sur son enrichissement ; - chaque Utilisateur peut être dans la situation A ou B ; - le fait qu'un Utilisateur contribue à la Base de Données Commune ne le prive pas de sa privauté car il peut rester anonyme ; - enfin le modèle économique permet de rétribuer ceux qui contribuent plus à la BD Commune qu'ils ne consultent, et de sanctionner l'inverse. De façon encore plus résumée, l'avantage individuel de pouvoir organiser l'information (découverte par chacun), selon des catégories partagées est une incitation qui pousse chaque Utilisateur à contribuer à une BD qui est commune à tous les Utilisateurs. C. Premier perfectionnement (niveau 2) Selon ce premier perfectionnement, tous les Profils ne sont pas nécessairement confidentiels. Nous distinguons les Utilisateurs qui veulent publier certains de leurs Profils (ou un ou plusieurs sous-ensembles de leurs Profils) a l'intention des autres (ou de certains autres), par opposition aux Utilisateurs qui n'utilisent le système que pour leur organisation personnelle d'informations. Plus exactement, nous distinguons les Profils (ou sous-ensembles de Profil) qui sont publiés à l'ensemble (ou à un sous-ensemble) des autres Utilisateurs et les nommons Profil Non Confidentiel . On va maintenant décrire un certain nombre de fonctionnalités autorisées par ce perfectionnement. a) Le concept de Dérivation Les Utilisateurs peuvent Dériver un Profil Non Confidentiel, c'est-à-dire l'importer et l'utiliser comme étant leur propre Profil (Confidentiel ou pas) et en enlever ou y ajouter des Contenus. On entend par là que les Contenus Ajoutés (ou Acceptés) dans le Profil source sont automatiquement Suggérés dans le Profil dérivé et que l'Utilisateur de ce dernier peut ainsi en Accepter tout ou partie. Par en enlever on entend que l'Utilisateur peut Refuser certains Contenus Suggérés. Finalement, l'Utilisateur peut aussi Ajouter : * des Références à des Contenus, ou * des Références à des Références se trouvant dans d'autres Profils. Les nouveaux Contenus (Directs ou Indirects) sont alors ajoutés dans la BD Commune dans le Contenant lié au Profil dérivé, s'il n'y figuraient pas déjà. Un diagramme de classe relatif à la structure d'un tel système de dérivation de Profils est illustré sur la figure 91 des dessins. Un observe qu'un Profil uenve et Non Confidentiel peut etre aenve a son tour par un autre Utilisateur. Les Références entre Profils peuvent donc se faire en cascade pour aboutir finalement aux Contenus dans la Base de Données Commune. Optionnellement, un Profil Dérivé peut être fusionné avec un Profil déjà existant (que ce dernier soit lui-même Dérivé ou non) et adopter le Contenant de ce dernier. En résultat, un Profil peut ainsi être dérivé de plusieurs Profils. b) Lien Profil-Contenu Une même Référence peut en même temps être dans l'état Ajouté dans un Profil et dans l'état Refusé dans un autre Profil. On doit alors introduire un objet intermédiaire Lien ProfilContenu (ou lien) pour spécifier cet état. Ainsi, une même Référence peut avoir un lien ajouté avec un Profil et un lien Suggéré avec un autre Profil. L'état d'un lien Profil-Contenu peut être Suggéré , Refusé , Ajouté ou Retiré . Ceci sera précisé plus loin. c) Archive On peut également introduire une fonction d' Archive de Profil , qui sert d'étape intermédiaire avant la suppression effective d'une Référence dans un Profil. Une Référence R peut être Retirée dans un Profil P1 alors que dans un Profil P2 on y fait référence en mode Ajouté ou Suggéré. Dans ce cas, au moment où R est Retirée dans Pl, elle est placée dans l' Archive de Profil liée à P1et ne pourra être effectivement supprimée que lorsque plus aucun Profil n'y fera référence en mode Ajouté ou Suggéré. Autrement dit, quand un lien Profil-Contenu passe à l'état Retiré , si d'autres références existent sur la Référence en question, cette dernière se délie du Profil et se lie avec l'Archive de ce Profil, et si aucune référence n'existe sur elle, elle peut être supprimée effectivement (sous réserve de possibilité d'annulation de l'action par des méthodes traditionnelles). Ainsi un attribut compteur ae aenvanon peut erre prévu pour mémoriser le nombre de Références Suggéré ou Ajouté sur la Référence en question. La Référence peut ainsi être supprimée de l'Archive quand la valeur du Compteur de Dérivation passe à zéro. d) Procédé de Suggestion La suggestion est le procédé de communication entre Profils. Par ce procédé, les Contenus se propagent: * soit automatiquement -d'un Profil à ses Profils dérivés, - et inversément, des Profils dérivés aux Profils sources * soit manuellement , par le fait de soumettre un Contenu d'un Profil à un autre Profil. On va détailler ci-dessous ces différents modes de propagation : i) Propagation d'un Profil à ses Profils Dérivés Les Références ajoutées dans un Profil d'un Utilisateur UB , lequel Profil est dérivé par un Utilisateur UA , sont par défaut automatiquement suggérés à UA, comme l'illustre la figure 92. Le résultat de la suggestion se matérialise par un lien Suggéré Dérivé comme illustré sur la figure 93. Ce lien n'est pas rendu permanent, en ce sens qu'il n'a d'existence que sur le poste client. Dans le cas où le possesseur du Profil A accepte la suggestion du Contenu pointé par R, il n'est plus besoin de suggérer à nouveau R à chaque connexion, car une autre Référence R' pointant sur R est créée, comme le montre la figure 94. Le système utilisera alors le fait que l'état du lien Suggéré Dérivé est Consulté (le lien est stocké de manière permanente sur le serveur) pour ne pas suggérer à nouveau ce Contenu à la prochaine connexion de l'Utilisateur sur ce Profil. il) Propagation d'un Profil Dérive a son ou ses) Profil(s) sources; Les Références ajoutées dans un Profil Dérivé sont automatiquement suggérées au(x) propriétaire(s) du (des) Profil(s) d'origine. Bien entendu, ce (ou ces) derniers peu (ven)t accepter ou les refuser. Le schéma de la figure 95 illustre la communication de UB à Uc via le Profil de UA, Les Profils de UB et Uc ayant été dérivés du Profil de UA. Le résultat de la suggestion automatique du Profil B au Profil A se matérialise par un lien Suggéré, comme illustré sur la figure 96, qui n'est pas stocké de manière permanente : Dans le cas où le possesseur du Profil A accepte la Référence R, il n'est plus besoin de la suggérer à nouveau à chaque connexion, car une autre Référence R' sur R est créée. Pour le permettre, le lien Suggéré est rendu permanent. Ceci est illustré sur la figure 97. iii) Référencement (Suggestion manuelle) Par opposition aux suggestions automatiques évoquées ci-dessus, le Référencement est demandé explicitement par l'Utilisateur. Il consiste à re-catégoriser un Contenu dans un autre Contenant et entraîne la création d'un Contenu Indirect. Un lien Profil-Contenu de Suggestion de Référencement a le même comportement que les liens Profil-Contenant de Suggestion automatique (déjà évoqués ci-dessus - voir aussi plus loin les spécifications des transitions d'état). Le résultat de la suggestion de Référencement du Profil B au Profil A se matérialise par un lien Suggéré tel qu'illustré sur la figure 98, qui est rendu permanent (contrairement aux exemples précédents) : On notera ici qu'en remontant le lien de Suggestion de Référencement, on peut retrouver le Profil dans lequel le Contenu en question a été référencé. Dans le cas où le possesseur du Profil A accepte la Référence R, il n'est plus besoin de la suggérer à nouveau à chaque connexion, car une autre Référence R' pointant sur R est créée, comme illustré sur la figure 99. Note sur les types de liens Profil-Contenu Les Contenus (plus exactement des Références à des Contenus) situés dans un Profil Propre ou dans un Profil Dérivé ont des liens avec ces Profils qui peuvent être différents. Ainsi les Profils Propres peuvent avoir : * des liens Créés (liens avec de nouveaux Contenus Directs ou Indirects), * des liens Dérivés (liens avec des Contenus dérivés d'autres Profils) ou * des liens Suggérés (liens avec des Contenus qui lui ont été suggérés). Les Profils Dérivés peuvent avoir quant à eux : * des liens Créés (liens avec de nouveaux Contenus Directs ou Indirects), * des liens Dérivés (liens avec des Contenus dérivés d'autres Profils) * des liens Suggérés Dérivés (liens avec des Contenus appartenant au Profil source) ou * des liens Suggérés (liens avec des Contenus qui lui ont été suggérés). Le diagramme de classe illustrant ces différents types de liens est illustré sur la figure 100 des dessins. Note sur les Transitions des liens On va décrire ci-dessous les différentes transitions apparaissant pour des liens Créés, des liens Dérivés, des liens Suggérés et des liens Archive. a. Transitions des liens Créés (figure 101) 1. Création d'une Référence (nouveau Contenu, Contenu pris du Contenant associé ou d'un autre Contenant) 2. L'Utilisateur veut la supprimer, celle-ci est d'abord mise en Archive (ettet : lien Archive transition 1) 3. Remettre dans le Profil une Référence Retirée ( restore ) (effet : lien Archive transition 2) 4. Au cas où le Compteur de Dérivation tombe à zéro, la Référence peut être Supprimée effectivement (Supprimée aussi dans l'Archive - Transition 2) ainsi que son lien. b. Transitions des liens Dérivés (figure 102) 1. Soit une Référence est ( manuellement ) dérivée d'un autre Profil, soit une Référence suggérée est entérinée. En même temps, le lien Suggéré correspondant (le cas échéant) passe à Consulté (Transition 5). 2. L'Utilisateur peut ensuite la Retirer. Auquel cas elle est d'abord mise en Archive (lien Archive Transition 1). Le lien Suggéré correspondant (le cas échéant) reste à Consulté. 3. Restauration (retour de l'Archive). Transition 2 pour le lien Archive. 4. Au cas où le Compteur de Dérivation tombe à zéro, la Référence est supprimée effectivement et son lien l'est donc aussi (supprimée aussi dans l'Archive : Transition 2). En même temps, le lien Suggéré correspondant (le cas échéant) est supprimé (Transition 4). c. Transitions des liens Suggérés (figure 103) On notera tout d'abord que le lien Suggéré Dérivé en est un cas particulier. 1. Un Profil reçoit une Référence (un Contenu est suggéré). Le lien Suggéré dans l'état Suggéré n'est pas stocké de manière permanente, sauf dans le cas du Référencement (puisque dans ce cas la suggestion ne découle pas de la dérivation du Profil et n'est donc pas une information redondante). 2. L'Utilisateur le refuse ou l'ajoute (s'il l'ajoute : transition 1 du lien Dérivé). Le lien Suggéré est alors stocké de manière permanente (dans l'état Consulté). Le système pourra ainsi éviter de suggérer à nouveau cette Référence à la prochaine connexion 3. Restauration . Le lien stocké de manière permanente est simplement supprimé dans la BD des Profils sauf dans le cas du Référencement. L'élément pourra ainsi être suggéré à nouveau. 4. La source étant effectivement suppnmee (lien Arcmve - 2), son uen est supprime. S'il existe, le lien Dérivé correspondant effectue la Transition 4. d. Transitions des liens Archive (figure 104) 1. Référence mise en Archive (cause : transition 2 des liens Créés et Dérivés). 2. Lien Archive supprimé, soit parce que la Référence est restaurée (transition 3 des liens Créés et Dérivés), soit parce que le Compteur de Dérivation tombe à zéro (plus aucune autre Référence ne pointe sur la Référence attachée à ce lien), dans ce cas : Transition 4 pour les lien Suggéré et Dérivé ou pour le lien Créé. iv) Archivage et Restauration Partons de la situation illustrée sur la figure 105, dans laquelle un Profil A possède une Référence R' sur une Référence R d'un Profil B. Quand la référence R' est Retirée elle va en Archive, comme illustré sur la figure 106. Mais dès que plus aucune Référence ne pointe sur elle (dès que le Compteur de Dérivation de R' passe à zéro), R' peut être supprimée effectivement. Ceci est illustré sur la figure 107. Ce premier perfectionnement de la présente invention présente, outre les avantages de la forme de réalisation de base, toute une série d'avantages supplémentaires, et principalement le fait de pouvoir dériver des Profils, et donc de bénéficier de canaux de communication automatiques entre Utilisateurs. Plus précisément : - alors que dans la forme de réalisation de base, l'Utilisateur pouvait consulter les Contenants de la BD Commune et s'abonner à (être automatiquement informé de) leurs nouveaux Contenus, le premier perfectionnement permet à l'Utilisateur de consulter et de s'abonner aux Profils qu'il a dérivé. Il exploite ainsi l'expertise (de regroupement sélectif et de catégorisation d'informations) matérialisée dans ces Profils ; le schéma de la figure 92 illustre qu'un Contenu, ajouté par un Utilisateur UB, est communiqué à un Utilisateur UA automatiquement via leurs Profils respectifs, grâce au fait que le Profil de UA (Profil A) est dérivé de celui de UB (Profil B) ; autrement dit, les Références ajoutées dans un Profil d'un Utilisateur UB, lequel Profil est dérivé par un Utilisateur UA, sont par défaut automatiquement communiquées à UA. - les Références ajoutées dans un Profil Dérivé sont automatiquement suggérées au(x) propriétaire (s) du (des) Profil(s) d'origine. Au cas où ce(s) dernier(s) les valide (nt), (leurs) propre(s) Profil(s) se trouve(nt) enrichi(s) de ces Contenus, et, en vertu de ce qui précède, ces derniers sont alors automatiquement propagés aux autres Utilisateurs ayant dérivé le (s) même(s)Profil(s) et qui s'y sont abonnés. ; le schéma de la figure 95 illustre la communication de UB à UC via le Profil de UA, Les Profils de UB et UC ayant été dérivés du Profil de UA. - enfin, grâce à la fonctionnalité d'Archive, un Contenu dérivé dans un Profil reste vivant même quand le Contenu d'origine est supprimé. D. Deuxième perfectionnement (Niveau 3) Selon ce deuxième perfectionnement, les Utilisateurs ne partagent plus une structure commune de Contenants. Autrement dit, chaque Utilisateur peut avoir une structure de Contenants différente de celles des autres Utilisateurs. Ces structures de Contenants sont mémorisées dans des Bases de Données (BD) Personnelles des Utilisateurs et non dans la BD Commune, qui d'ailleurs n'existe plus en tant que telle mais en tant qu'ensemble de fichiers ( Contenants ). Dans le même esprit que ce qui précède, une BD Personnelle est composée de Références plutôt que des Contenants et Contenus eux-mêmes. En effet, pour chaque Contenant, tous les Contenus (sauf ceux qui sont confidentiels) sont mémorisés en dehors de la BD Personnelle, dans un fichier commun ( Contenant ) . Dans la BD Personnelle, les références à ces Contenus forment un Profil . Certains de ces Profils peuvent être publiés à l'ensemble ou à un sous-ensemble des autres Utilisateurs (Profils Non Confidentiels - voir plus haut). Les Profils contiennent des Sous-Profils et forment ainsi une structure arborescente illustrée sur la figure 108 (ou encore une structure de graphe), qui peut être différente d'une BD Personnelle à une autre. De manière primitive, cette structure peut être représentée par un diagramme de classe UML , comme illustré sur la figure 109. Ici encore, le système offre une garantie d'anonymat : Les Utilisateurs, pour un Contenant donné (accessible à travers un Profil de leur BD Personnelle), peuvent consulter (ou être abonné à) tous les Contenus ajoutés par les autres Utilisateurs dans ce Contenant, sans pouvoir déterminer quel Contenu figure dans quelle BD Personnelle. Ici, deux Profils associés à un même Contenant peuvent avoir une dénomination différente. On appelle Catégorie le nom d'un Profil. Comme la Catégorie d'un Contenant dépend du choix de l'Utilisateur, la classe Catégorie est associée à la classe Profil (ou en constitue un attribut) et non pas à la classe Contenant . On va maintenant décrire la façon dont l'arborescence est construite par chaque Utilisateur , c'est-à-dire la façon dont les différents Sous-Contenants sont créés dans les Profils, ainsi que l'incitation qui existe pour un Utilisateur à dériver un Profil. a) Nouveau Contenant L'Utilisateur peut librement créer un nouveau Contenant, en tant que sous-profil dans un Profil de sa BD Perso. S'il est Non Confidentiel, celui-ci donnera lieu à un nouveau fichier (Contenant-1) dans la Partie Commune, comme illustré sur la figure 110. b) Contenant déjà existant Alternativement, l'Utilisateur peut dériver un Profil Non Confidentiel d'un autre Utilisateur ou un Profil de sa propre BD Personnelle. Ce Profil est ajouté en tant que Sous-Profil dans un Profil de sa BD Personnelle qu'il a choisi (il a par exemple inséré le Profil dérivé dans ce Profil par la technique du glisser- déposer ). Les éléments (Contenus et SousProfils) que le Profil source contient sont automatiquement suggérés dans ce nouveau SousProfil. On notera ici que le fait de dériver un Profil n'engendre pas automatiquement la dérivation de toute la structure sous-jacente. Autrement dit, les Sous-Profils ne sont pas dérivés d'office, mais seulement si l'Utilisateur les ajoute explicitement. En effet, dans le cas contraire, le processus de dérivation pourrait rentrer dans une boucle infinie. c) Incitation l'Utilisateur à dériver un Profil i) Lien Profil-Profil Créé L'Utilisateur peut décider de dériver un Profil suite à sa consultation, par sa propre initiative, des Profils (non confidentiels) mis à sa disposition par les autres Utilisateurs. ii) Lien Profil-Profil Suggéré ou Dérivé Grâce au processus de suggestion descendante indiqué plus haut à propos du premier perfectionnement, les nouveaux Sous-Profils ajoutés dans un Profil Pl, duquel un Profil P2 a été dérivé, se retrouvent automatiquement dans P2, en mode suggéré. Inversement, grâce au processus de suggestion remontante, un nouveau Sous-Profil ajouté dans P2 est suggéré dans P1. Quand un nouveau Sous-Profil apparaît ainsi, l'Utilisateur peut l'ignorer (c'est le cas par défaut), le garder (l'ajouter) ou le refuser. iii) Lien Profil-Profil Référence ( Suggestion Manuelle ) Ce processus est appelé Référencement . Un Utilisateur UA peut, de sa propre initiative, suggérer une Référence RI ou un Profil P1 à un Utilisateur UB , pour qu'il soit dérivé en tant que Référence RI' ou profil P1' sous un Profil P2 (Non Confidentiel) de la BD Personnelle de UB. Ces différents liens apparaissent sur le diagramme de classe de la figure 111. Outre les avantages mentionnés plus haut à propos de la forme de réalisation de base et du premier perfectionnement (niveaux 1 et 2), ce second perfectionnement de l'invention ajoute d'autres avantages : - tout d'abord, différents Utilisateurs peuvent avoir une structure différente de Contenants ; l'Utilisateur est ainsi maître de la catégorisation de ses données et n'est pas contraint par une structure commune figée ; dans ce nouveau cadre, le système : * exploite toujours le fait que les Contenants sont partagés (avantage du niveau 1), et * permet des dérivations non seulement de Contenus mais aussi de structures arborescentes de Contenants. - ensuite, la dérivation de Profil ou de Contenu peut se faire, non seulement par l'initiative de l'Utilisateur qui dérive, mais aussi par l'initiative d'un autre Utilisateur qui souhaite que ses Profils ou Contenus soient dérivés dans un Profil externe (mécanisme de Référencement) et qui pour cela les suggèrent manuellement (par opposition aux suggestions automatiques décrites plus haut. Ce dernier avantage est considérable ; grâce au Référencement, le système peut s'étendre et voir sa Communauté d'Utilisateurs augmenter toujours plus, sans véritable risque de pollution à cause de l'introduction d'informations de mauvaise qualité. En effet, bien que de telles informations puissent effectivement être introduites dans le système, le nombre d'Utilisateurs qui y accéderont ne sera pas significatif. Car pour que l'on y accède à grande échelle, il faudrait qu'elles soient Référencées dans les Profils publics à grande audience , c'est-à-dire connus par un grand nombre d'Utilisateurs et largement consultés et/ou dérivés. Or, les propriétaires de ces Profils publics ne sont pas obligés d'accepter un Référencement suggéré par n'importe qui et peuvent le filtrer. Ils filtreront ainsi les mauvaises informations sous peine de dévaloriser leurs propres image et la confiance de leur audience . Les Utilisateurs du système jouent donc eux-mêmes le rôle de modérateurs décentralisés. Le système est ainsi auto-régulé. E. Troisième perfectionnement (niveau 4) Ce troisième perfectionnement consiste en une évolution du deuxième pour prendre en compte l'assemblage, dans un Profil d'un Utilisateur, de plusieurs ensembles de Contenus pour un même Contenant. Selon ce perfectionnement, les Profils du Niveau 3 sont remplacés par des Classeurs . Un Classeur est associé à un Contenant et contient (zéro, une ou) plusieurs Pages . Chaque Page rassemble un ensemble de Contenus. Un Classeur contient donc des Pages et des sous-classeurs. La structure arborescente est ainsi représentée sous la forme d'une hiérarchie de Classeurs , comme illustré sur la figure 112. Les classeurs, les pages et les Références peuvent être dérivés. Les liens Profil-Contenu sont remplacés par des liens Classeur-Page et Page-Contenu. L'Archive de Profil est remplacée par une Archive globale pour chaque Base de Données Personnelle. Cette structure est spécifiée par le diagramme de classe illustré sur la figure 113. Les Classeurs et les Pages (Non Confidentiels) d'une BD Personnelle peuvent être dérivés d'une autre BD Personnelle, voire d'un autre endroit de la même BD Personnelle. Les avantages des niveaux 1 à 3 subsistent ici. On va maintenant décrire une application pratique de ce troisième perfectionnement. Un Utilisateur possède un classeur de base qui lui est propre , dans lequel il peut réaliser différentes actions, et en particulier : a) Création de sous-éléments propres à l'Utilisateur L'Utilisateur constitue son Classeur de ses propres Sous-Classeurs, Pages et Calques (on décrira ces deux derniers objets dans la suite) grâce à un éditeur de documents intégré au système. b) Création de sous-éléments dérivés L'Utilisateur insère dans son Classeur des éléments récupérés dans d'autres Classeurs. c) Suppression de sous-éléments propres à l'Utilisateur L'Utilisateur supprime ses propres éléments. d) Acceptation ou Refus de sous-éléments dérivés L'Utilisateur rend visible ou non les sous-éléments implicites des éléments dérivés , c'est à dire les sous-éléments des éléments récupérés dans d'autres Classeurs. Ces informations sont stockées dans une base de données par exemple de type SQL, telle qu'illustrée sur la figure 114. On notera que les champs de référencement REFelement, REFstyle, REFcontenu sont ici des adresses de type url . Les pages vers lesquelles on pointe renvoient ainsi le code désiré, et en particulier les données de Contenu en format HTML, les données de Classeur en format XML, etc. Comme on le voit sur la figure 114, les Classeurs, Pages et Calques sont des éléments reliés hiérarchiquement par des tables Lien . leurs définitions ne se distinguent que par un attribut en moyenne (IDcontenant par un classeur, REFstyle pour une page, IDcontenu pour un calque). On va décrire ci-dessous, dans ce contexte, des exemples d'actions. a) Prologue : création d'Utilisateur Avant toute action de l'Utilisateur, il faut bien que celui-ci soit défini. Son existence est inscrite dans une table Utilisateurs , telle qu'illustrée sur la figure 115. (Remarque : à la création d'un nouvel Utilisateur, on crée également un Classeur de Base et un élément pour Archive (élément de type particulier pour stocker tous les éléments en voie de suppression, comme décrit plus haut). b) Action 1 : créationd'élément/sous- élément propre à l'Utilisateur La figure 116 illustre une structure hiérarchique de Classeurs et une Table associée, pour un Utilisateur donné (ici l'Utilisateur No. 1 appelé Demo ). Les différents éléments de la Table de la figure 116 sont propres à cet Utilisateur, en ce sens qu'ils ne font pas référence à un autre élément (le champ REFelement est toujours égal à la valeur Null , c'est-à-dire vide). On distingue les 3 types d'éléments suivants, reconnus par la valeur de la variable Type de la Table de la figure 116. i) Les Classeurs (type 1) Dans le présent exemple, les éléments Nos. 1 et 2 (c'est-à-dire dont les valeurs de IDelement sont respectivement égales à 1 et 2) sont des Classeurs appelés Demo 0 et Demo 0 1 , le Classeur No. 1 étant d'ailleurs le Classeur de Base de l'Utilisateur en question. ii) Les Pages (type 2) Dans le présent exemple, les éléments Nos. 3 et 7 sont des Pages de l'Utilisateur. iii) Les Calques (type 3) Dans ce même exemple, les éléments Nos. 4 et 5 sont des Calques de l'Utilisateur. Les liens de parentés sont inscrits dans une Table Liens , telle qu'illustrée sur la figure 117. Cette Table montre que l'élément No. 1 ( Demo 0 ) est le Parent des éléments Nos. 2 et 6 ( Demo 0 1 et Demo 0 2 ) c) Action 2 : création d'élément/sous-élément Dérivé La figure 118 montre un exemple d'une structure arborescente de classeurs incluant un Classeur Dérivé (nommé ici Aline favoris ), et de la Table associée. Un élément dérivé résulte de la récupération d'un élément par un autre Utilisateur que son concepteur original. C'est un élément propre au récupérateur auquel est ajouté une référence à l'élément original. L'exemple de la figure 118 montre que l'élément No. 9 ( Aline favoris ) est dérivé de l'élément No. 2 ( Demo 0 1 ), car la valeur de REFelement est ici égale à 2. Le Classeur No. 9 possède alors implicitement les sous-éléments du classeur No. 2 . Ces sous- éléments devront être Acceptés ou Refusés (voir plus loin action 4) pour que les Utilisateurs qui dériveront le classeur No. 9 les voient ou ne les voient pas, selon le cas. Comme dans un élément propre à l'Utilisateur , l'Utilisateur de l'élément dérivé peut ajouter ou retrancher d'autres éléments selon son choix ; ses ajouts et suppressions seront d'ailleurs suggérés par la suite à l'auteur de l'élément original. (Remarque : Lorsqu'un Utilisateur crée un élément dérivé (comme ici le Classeur Aline favoris ), le compteur de dérivation de l'élément original (variable Compteur est automatiquement incrémenté (comme ici pour le classeur demo 0 1 ). Ceci permet de savoir si la suppression de l'original est possible ou si cet original doit être mis en archive lorsque son auteur le masque. d) Action 3 : Suppressiond'éléments propres à l'Utilisateur i) Suppression d'un sous-élément propre non dérivé Considérons l'exemple où l'Utilisateur demo désire supprimer le sous-élément Demo 0 2 . D'après le Compteur de Dérivation, celui-ci n'est utilisé comme référence par personne. On peut donc supprimer le lien entre Demo 0 et Demo 0 2 , mais aussi supprimer Demo 0 et tous ses sous-éléments dont la valeur du Compteur de Dérivation est nul. Le résultat de cette suppression est illustré sur la figure 119. ii) Suppression d'un sous-élément propre dérivé au moins une fois Considérons ici l'exemple où l'Utilisateur demo désire supprimer le sous-élément Demo 02 . Or, d'après la valeur du Compteur de Dérivation, celui-ci est utilisé comme référence par un autre classeur (en l'occurrence le classeur Aline favoris ). On peut donc supprimer le lien entre Demo 0 et Demo 0 1 , mais on ne peut pas supprimer l'élément Demo 0 1 luimême. C'est pourquoi, celui-ci est alors apparenté au classeur Archive de l'Utilisateur (pour ne pas engendrer un orphelin). Il y restera jusqu'à ce que la valeur du Compteur de Dérivation tombe à zéro. La situation est illustrée sur les figures 120a à 120c. Ainsi la figure 120c montre que l'élément n 2 (Idenfant = 2) n'appartient plus vraiment à l'élément No. 1 (Idparent = 1), car son attribut Opération a la valeur zéro. Ce même élément est en revanche ajouté à l'élément archive n 12 (Idparent = 12) de l'Utilisateur, dont il devient un sous-élément. Le fait que ce sous-élément soit rattaché à un élément archive permettra de pouvoir encore le visualiser le cas échéant le restaurer à l'initiative de l'Utilisateur, comme on va le voir cidessous. iii) Restauration d'un sous-élément archive Pour restaurer un sous-élément archive , l'Utilisateur consulte l'élément archive et désigne le sous-élément à restaurer. Il suffit alors de remplacer le 0 par un + dans le lien correspondant au sous-élément. Puis on supprime le lien entre cet élément et l'élément archive . Ceci est illustré sur la figure 121. On observera que l'on pourrait mettre également en archive les éléments supprimés dont le compteur de dérivation est nul pour permettre leur restauration... Dans ce cas, la vidange se ferait de la même manière qu'avec la corbeille d'un explorateur de fichiers. Les éléments ne pourront cependant être vidangés tant que leur compteur de dérivation est non nul. e) Action 4 : Acceptation/Refus de sous-éléments implicites Les éléments dérivés possèdent implicitement les sous-éléments de l'élément original. Ainsi, à chaque ouverture de son élément dérivé, l'Utilisateur verra apparaître et disparaître des sous-éléments au gré de l'Utilisateur de l'élément original. Ainsi la figure 122 illustre le cas où un classeur n 9 Aline favoris (Idelement = 9) est dérivé d'un classeur n 2 (REFelement = 2), et possède donc implicitement les sous-éléments de ce dernier, tels que les éléments illustrés sur la figure 123, dont la variable Idparent est égale à 2. On va décrire ci-dessous comment ces sous-éléments peuvent être Acceptés ou Refusés. i) Acceptation d'un sous-élément implicite L'Utilisateur doit accepter un sous-élément implicite (sous-élément de l'original) pour ne pas risquer de le voir disparaître et pour le proposer aux Utilisateurs qui dériveront ou qui ont dérivé à leur tour l'élément dérivé (par exemple, si dans l'exemple ci-dessus un troisième Utilisateur crée un classeur dérivé du classeur n 9). L'acceptation d'un sous-élément implicite est en fait une dérivation de ce sous- élément dans le classeur dérivé. En base de données, cela revient donc à créer un classeur dérivé et à en faire un enfant de l'élément dérivé. Exemple d'acceptation du sous-classeur implicite Demo 0 Il La figure 124 illustre la création de l'élément n 15 dérivé du n 13, à savoir Demo 0 1 1 , et la figure 125 illustre la création du lien de parenté entre les éléments. L'Utilisateur exprime ainsi son intérêt à l'auteur original pour cet élément. De plus, l'auteur original pourra ainsi lui suggérer par la suite des ajouts et retranchement de sous-éléments. ii) Refus d'un sous-élément implicite L'Utilisateur doit refuser un sous-élément implicite (sous-élément de l'original) lorsqu'il ne souhaite pas le voir réapparaître à chaque ouverture de son classeur. Le refus d'un sous-élément implicite est en fait un lien de parenté spécial entre ce sous- élément et le classeur dérivé qui permet de signifier le refus. En base de données, cela revient donc à créer un lien entre l'élément dérivé et le sous-élément avec la valeur - dans le champ Operation. Exemple de refus du sous-classeur implicite Demo 0 1 2 Cet exemple particulier est illustré sur les figures 126 et 127, la figure 127 montrant la valeur - du champ Operation. L'Utilisateur exprime ainsi son désintérêt à l'auteur original pour cet élément. En outre, lorsque l'élément original est réellement supprimé, ce lien n'aura plus d'utilité et pourra donc être également supprimé. On notera ici que la gestion des classeurs et des éléments qu'ils contiennent peut se faire avantageusement selon une interface utilisateur telle qu'illustrée sur la figure 127a. Cette interface utilisateur comprend à gauche deux fenêtres ou cadres superposés Cadre1 et Cadre2, le cadre supérieur Cadre affichant une structure arborescente (par exemple du type Explorateur Windows - marque déposée de Microsoft Corp. ) du classeur de l'utilisateur, tandis que le cadre inférieur Cadre2 contient, avec le même type de représentation, le classeur d'un tiers en train d'être consulté à distance par ce même utilisateur. On peut ainsi facilement naviguer d'un Contenant à l'autre, les Contenus du cadre actif étant affichés dans un cadre plus grand Cadre3 prévu dans la partie droite de l'écran. Ces contenus (pages) sont affichés avec le style imposé par le cadre couramment choisi. Des onglets permettent également de naviguer dans la structure. Cette interface permet notamment : - d'importer à partir du classeur tiers, par la technique du glisser-déposer du cadre Cadre2 vers le cadre Cadre 1, tout ou partie des Contenants (inclus les Contenus associés) ou des contenus individuels, sachant que l'importation d'un ou de plusieurs Contenants peut impliquer une procédure d'acceptation sélective, de façon collective ou individuelle, des Contenus associés ; - de proposer au tiers, toujours par la technique du glisser-déposer, mais cette fois-ci de Cadrel vers Cadre2, tout ou partie de son propre classeur, pour mettre en #uvre la fonction décrite plus haut de suggestion manuelle ou Référencement ; - pour ce qui concerne le cadre d'affichage Cadre3, une série de boutons et/ou d'onglets est avantageusement prévue pour faire défiler les pages, changer de calque, etc.. Enfin on notera ici que les opérations d'acceptations/refus de suggestions peuvent s'effectuer dans des boîtes de dialogue spécifiques, soit lorsque l'utilisateur accède à un classeur contenant des éléments nouvellement suggérés depuis sa dernière connexion, soit lorsque l'utilisateur accède au Contenants destinés à accueillir les éléments suggérés. Par ailleurs, ces aspects de l'invention permettent : - à des fournisseurs d'informations, tels que des magazines grand public par exemple, de créer et mettre àjour leurs informations directement sur l'Internet, - aux fournisseurs d'information de fidéliser l'internaute en jouant sur sa fibre de collectionneur ; l'internaute peut en effet constituer des collections d'information dans un classeur personnel en ligne, - aux fournisseurs de produits, d'offrir des éléments de contenu décrivant leurs produits (biens ou services) : en quelques clics de souris, ils les référencent dans les magazines en ligne, communiquent ainsi leurs nouveautés et promotions et en récoltent des transactions commerciales, - aux magazines de se transformer en mini-annuaires (comme les portails ou annuaires connus aujourd'hui sur l'Internet) et de percevoir une commission sur les visites et ventes engendrées, - enfin, aux internautes de consulter les magazines et les offres de produits : ils peuvent glisser dans leur classeur personnel des éléments de contenu qu'ils retrouvent à chaque connexion, ces éléments de contenu étant mis à jour et complétés ; le fait de glisser une information dans le classeur personnel représente implicitement une " déclaration d'intérêt qui leur permet de se faire suggérer automatiquement des informations apparentées. Ainsi un nouveau magazine en ligne rejoignant un système existant pourra exploiter le trafic qui y est déjà présent. Section 2 - Auto-épuration du Système On va maintenant décrire en détail une fonction de la présente invention permettant de prendre en compte la qualité des suggestions pour aboutir, par une notion de degré de confiance , à limiter les effets de suggestions indésirables. Cette section est à rapprocher de la section Coefficients de Probabilité d'Acceptation du chapitre II. Introduction Le système met en oeuvre un double principe d'épuration. Premièrement, comme mentionné à propos de la suggestion manuelle dans la section 1 de ce même chapitre, la diffusion des informations entre Utilisateurs peut s'effectuer par Référencement d'un Profil d'un Utilisateur donné dans les Profils (Classeurs ou Pages) d'autres Utilisateurs dont il espère capter l'audience (notamment pour qu'à partir de Profils Non Confidentiels d'autres utilisateurs, le public puisse trouver les informations propres audit Utilisateur donné). Le système permet ceci de manière décentralisée. Le Référencement est une suggestion et peut donc être filtré par le destinataire, qui joue ainsi le rôle d'épurateur. Ainsi, ceux qui fournissent des informations de mauvaise qualité perdent leur crédibilité, et ont tendance à ne plus faire l'objet de dérivations vers d'autres utilisateurs. Leur audience baisse donc. Deuxièmement, le maintien du crédit qu'accorde chaque Utilisateur peut-être assisté par le système de manière automatique. Par apprentissage automatique et transparent, basé sur l'expérience, le système construit et maintient une notation de contribution révélatrice d'un "degré de confiance" que peut accorder un Utilisateur aux informations fournies par un autre Utilisateur. Ce degré de confiance peut être déterminé de manière indirecte en suivant une "chaîne" d'Utilisateurs dans laquelle chaque Utilisateur a pu déterminer le degré de confiance pour le suivant (c'est à dire par transitivité). Le degré de confiance ainsi obtenu permet de filtrer automatiquement les suggestions de contenu ayant une forte probabilité de ne pas être pertinentes. Il est important de noter ici que l'identité (ou plutôt le pseudonyme) de l'Utilisateur qui est à l'origine de la suggestion est connu du système mais pas des autres Utilisateurs. Détails duprocédé d'auto-épuration Pour chaque type d'action (accepter, refuser, déplacer, etc. ), on prévoit selon ce perfectionnement de l'invention le recours à une notation de contribution, c'est-à-dire à un système d'attribution de points positifs ou négatifs, sur la base du fait que l'Utilisateur B qui reçoit des points positifs par l'Utilisateur A augmente d'autant la confiance que lui accorde ce dernier. De même, il diminue sa confiance quand il reçoit des points négatifs. L'Utilisateur A peut ainsi automatiquement filtrer (dans ses requêtes) les suggestions faites par des Utilisateurs dont le degré de confiance est inférieur à un certain seuil. L'intérêt de cette fonction réside surtout dans le fait que l'évaluation (ou notation) se fait dans le cadre l'utilisation courante de l'outil, de manière transparente. Par exemple, suite à une requête, un Utilisateur A reçoit un Contenu suggéré par un Utilisateur C qu'il n'a pas encore eu l'occasion d'évaluer. Dans le cas où l'Utilisateur C a un degré de confiance négatif chez l'Utilisateur B, et que ce dernier a un degré de confiance positif chez l'Utilisateur A, alors, par transitivité, l'Utilisateur C obtient des points négatifs chez l'Utilisateur A. Ce dernier peut alors automatiquement filtrer les Contenus suggérés par C. En effet, l'Utilisateur A a confiance dans les suggestions faites par l'utilisateur B. Donc si l'Utilisateur B estime que les suggestions de l'Utilisateur C ne correspondent pas à ses attentes, alors l'Utilisateur A peut être confiant qu'il aurait la même opinion négative. Concrètement, cette approche peut s'appuyer sur une structure de données incluant une représentation d'un graphe de transitivité entre les différents Utilisateurs (tout en conservant leur anonymat les uns par rapport aux autres). Avantageusement, cette approche peut s'accompagner de coefficients de pondération en fonction de la longueur de la chaîne de transitivité pour une évaluation donnée, ainsi que d'autres critères et seuils divers. Par exemple, pour que l'Utilisateur A puisse se fier au jugement de l'Utilisateur B au sujet de l'Utilisateur C, le degré de confiance qu'accorde l'Utilisateur A à l'Utilisateur B doit être supérieur à un certain seuil depuis un certain temps (critère de stabilité). Ainsi le système construit automatiquement ce qu'on peut qualifier de réseau de confiance , auto-alimenté et auto-régulé, qui permet d'épurer sélectivement les suggestions inadéquates. On notera ici qu'il subsiste toutefois un risque : ainsi un Utilisateur malveillant peut s'inscrire dans le système fréquemment, avec des pseudonymes chaque fois différents, dans le but de suggérer des Contenus de mauvaise qualité. Cet Utilisateur malveillant n'étant évalué par personne au début, ses suggestions ne pourront être filtrés pendant un certain temps. Pour supprimer ce risque, on pourra filtrer les Utilisateurs récents dont le volume d'éléments suggérés n'a pas atteint un certain seuil, que l'on appelle seuil de contribution . Ce filtrage pourra aussi servir à inciter les Utilisateurs à contribuer suffisamment pour que les Contenus qu'ils suggèrent ne soient pas filtrés. Ceci incite à faire vivre le système. Le volume de contribution de chacun pourra être déterminé selon une méthode qui permette d'éviter les contributions reproduites artificiellement pour atteindre le seuil de contribution. Alternativement, le fait de s'inscrire dans le système d'échange par suggestions peut être payant, ou nominatif via un tiers de confiance qui découragerait de suggérer des Contenus sous des pseudonymes différents. Section 3 - Techniques de suggestions automatiques Introduction Les Profils, tels que décrits dans la section 1, caractérisent les Utilisateurs et peuvent ainsi être exploités en tant que profils d'intérêts (ou de goûts) que l'on confronte les uns aux autres pour en extraire des informations pertinentes et les suggérer automatiquement aux Utilisateurs. La confrontation d'un profil aux autres peut se faire individuellement (par exemple par les techniques connues de Filtrage collaboratif , de Recommandation sur la base de Contenus ), ou sur l'ensemble synthétisé des autres profils de manière compacte (par exemple par les techniques de Réseaux Bayesiens, etc.). Un apport important de cet aspect de l'invention est de tirer parti de l'ordre des Contenus dans les Profils pour améliorer les suggestions. Si l'on se place au Niveau 4 de la section 1 du présent chapitre, l'utilisateur peut ordonner les Contenus (qui sont affichés dans un certain ordre dans les pages), et les pages entre elles (l'ordre des pages est affiché sous la forme d'un classeur), en fonction de différents critères d'ordre choisis par lui-même (par exemple, critère de préférence globale, critère temporel, critère économique, critère esthétique, etc. ) ou une conjonction ordonnée de tels critères. Dans la mesure où ces critères sont partagés avec d'autres Utilisateurs, le système en déduit des profils ordonnés, améliore ainsi la pertinence des éléments recommandés, insère les éléments recommandés à leur bonne position, et peut même ordonner automatiquement des informations posées en vrac en se basant sur l'ordre adopté par les profils proches. Ces procédés sont décrits dans la section suivante. Détails des techniques de Suggestion Automatique a. Détection de profils voisins Les Contenus sont composés d'éléments (par exemple au format XML) qui ont des attributs et des éléments imbriqués. Afin de détecter, entre deux profils donnés, les Contenus qui peuvent être considérés comme pratiquement identiques , ils peuvent être analysés selon des règles qui se déclenchent à partir d'un mécanisme de reconnaissance de motifs ( pattern matching ). Un Contenant peut ainsi donner des poids différents aux attributs des éléments de ses Contenus. Un Contenu sera alors considéré comme pratiquement identique à un autre si un ensemble d'attributs suffisamment représentatif (la représentativité sera calculée en fonction de leurs poids respectifs) ont les mêmes valeurs. Ainsi, il n'est pas nécessaire que deux Utilisateurs aient dans leurs profils des Contenus exactement les mêmes pour qu'ils soient jugés proches. La proximité entre deux profils Px et Py - ordonnés selon un critère donné - est mesuré en évaluant la quantité de calques que les Utilisateurs A et B ont en commun, avec une pondération par la position de ces calques dans les profils des Utilisateurs A et B respectivement, comme illustré sur la figure 128. Pratiquement la mesure de proximité va se faire Contenu par Contenu tant que le poids marginal reste supérieur à un certain seuil. Ainsi il suffira comparer un nombre fixé d'éléments dans l'ordre correspondant au critère donné. L'Utilisateur peut aussi s'appuyer sur un certain nombre d'autres indicateurs tels que par exemple : - le pourcentage d'informations en commun, comme illustré sur la figure 129 ; - le nombre de fois qu'un même Contenu est suggéré (à partir de Profils différents). b. Insertion des Contenus suggérés qui sont acceptés Lorsqu'un Utilisateur accepte une suggestion de Contenu de la part du système de Recommandation Collaborative, le Contenu est classé au bon endroit selon chaque critère de la configuration du classeur. On va considérer, en référence à la figure 130, l'exemple suivant : supposons que pour un Contenant donné, des Utilisateurs ul et u36 ont en correspondance respectivement les pages ( xSheet ) xsA et xsB, dont les Contenus sont ordonnés chacun selon deux critères #1 et #2. Pour cette catégorie, ul et u36 sont proches au sens où ils possèdent tous les deux les Contenus c4 et c12. Le système de Recommandation Collaborative fait donc les propositions telles qu illustrées sur la ligure 1 -il, c8 etant suggere ae u36 a uiet ciétant suggere ae ul à u36. Si ces suggestions sont acceptés par chaque Utilisateurs, les Contenus sont alors insérés en accord avec les positions qu'ils occupent dans leur page d'origine. Pour le critère #1 de ul, c8 est classé par rapport aux Contenus communs à ul et u36, il est donc placé avant c4 et cl2. Bien sûr, ul est libre de replacer c8 s'il le juge mal classé en regard du critère utilisé. Un raisonnement symétrique est appliqué pour u36. Pour le critère #2, les éléments communs à xsA et xsB ne sont pas classés dans le même ordre. Plusieurs conventions sont alors possibles : celle qui semble la plus appropriée est de ne violer aucune relation établie dans le profil de départ. Ainsi, c8 doit être inséré après c12 et c4 dans xsA, et cl doit être inséré après cl2 dans xsB (bien qu'il soit avant c4 dans le profil de départ). Le résultat est illustré sur la figure 132. Une autre convention pourrait par exemple être d'insérer cl dans xsA et c8 dans xsB relativement à l'élément commun le plus proche, comme illustré sur la figure 133. L'insertion d'un Contenu, telle qu'on l'a décrite ci-dessus avec cl et c8, provoque la mise à jour des profils de ul et u36 pour les n#uds supérieurs de la taxonomie (profils agrégés). La place où le nouveau Contenu est inséré dans les profils agrégés est fonction de l'endroit où il a été classé lors de son insertion, et du critère utilisé. Ordonner les Profils automatiquement (Tri de profil par recommandation collaborative) Comme mentionné précédemment, dans un profil certains des Contenus n'ont pas été explicitement ordonnés. Dans les feuilles, à ceux-ci correspondent des onglets grisés. Pour chaque profil, les Contenus grisés qui font partie des Contenus en commun avec un profil voisin, mais dans la partition non grisée chez le voisin, sont ordonnés selon l'ordre suggéré par ce voisin. Section 4 - Graphes de dérivation Introduction Rappelons ici que le système décrit dans la section 1 du présent chapitre offre à l'Utilisateur la possibilité de (et une stimulation pour) dériver et réorganiser (ajouter, retirer, modifier, réordonner, déplacer d'un Contenant à un autre, etc. ) des éléments d'information non déclarés comme confidentiels. La stimulation vient du fait que l'Utilisateur profite ainsi de l'expertise de toute la chaîne d'Utilisateurs à l'amont c'est-à-dire à l'origine de chaque information. Le système incite donc ses Utilisateurs à l'étendre (à le faire grossir ) par dérivation, et les Utilisateurs en viennent à partager les mêmes Contenants et Contenus. Le grand avantage offert est ainsi le fait de parler le même langage , tant pour les informations elles-mêmes (Contenus) que pour leurs catégories respectives (Contenants). Or, parler un langage commun (celui-ci étant constitué par l'ensemble des Contenants et Contenus qui se trouvent dans la partie commune du système) facilite grandement la comparaison de Profils. En effet : - à partir des Contenus, on peut retrouver directement (en accès direct) les Références sur ceux-ci et les Profils qui les contiennent ; - à partir d'un Contenant associé à un Profil donné, on peut retrouver directement tous les Contenus auxquels ont accédé les Utilisateurs (et par là on peut ainsi retrouver directement les Profils qui les contiennent). De l'utilisation du système résulte donc un graphe de dérivation dynamique, dont le n#uds sont les Profils et les arcs (orientés) sont les dérivations entre Profils effectuées par les Utilisateurs. Il peut s'agir de dérivations de Profils (dérivation d'un Classeur ou d'une Page, si l'on se place au Niveau 4) ou dérivation de Contenus. L'idée essentielle de cet aspect de la présente invention est de se servir du graphe de dérivation entre Profils pour bénéficier de la localité des comparaisons à effectuer entre Profils. A ce sujet, l'interface utilisateur du système comprend avantageusement un moyen (bouton, etc. ) permettant à un utilisateur consultant un Contenant donné d'un Classeur tiers de consulter directement les contenus désignés dans l'ensemble du contenant de la partie commune qui définit cette catégorie, sans avoir ni à naviguer dans l'arborescence, ni à passer vers un portail Internet ou analogue. Comment tirerparti du graphe de dérivation entre Profils En s'appuyant sur le graphe de dérivation (qui évolue dynamiquement en cours d'exécution), chaque Profil (c'est-à-dire chaque n#ud du graphe de dérivation) maintient en mémoire une liste des voisins se trouvant dans un certain périmètre (à une distance inférieure à un seuil donné, distance mesurée en nombre d'arcs de dérivation), avec pour chaque voisin, un ensemble d'indicateurs de proximité. Les indicateurs peuvent être par exemple ceux mentionnés dans la section précédente ou tout simplement des compteurs de Contenus en commun. On peut en outre réaliser un maintien incrémental des indicateurs de proximité entre Profils : à chaque ajout et retrait de Contenu dans chaque Profil, ces indicateurs sont mis à jour chez tous les voisins dans le graphe. Par exemple, à chaque ajout de Contenu, pour chaque Profil voisin qui le posséderait aussi, le système incrémente l'indicateur compteur de Contenus en commun dans les deux Profils en question. A chaque retrait de Contenu, le système décrémente ce même compteur. Chaque Profil maintient ainsi de façon incrémentale les connaissances qu'il a de la proximité de ses voisins (anonymes bien entendu) et le système peut ainsi effectuer des suggestions automatiquement par Filtrage Collaboratif. Le seuil de distance peut par ailleurs être ajusté en cours d'exécution par une technique d'apprentissage basée sur un critère de rendement (évaluation des succès des suggestions à différentes distances). On observera ici que la présente invention permet d'éviter de recourir à des calculs extrêmement lourds de comparaison de profils par leurs contenus eux-mêmes, qui typiquement nécessitent, lorsque le nombre d'utilisateurs est important, des traitements batch de durées considérables. Section 5 - Anonymat et commerce électronique Architecture On considère ici une architecture composée de 4 classes d'ordinateurs connectés sur un réseau - au moins un poste-client (par exemple de type ordinateur personnel ou terminal de réseau),manipulé par un Utilisateur ; - au moins un serveur tiers (ST), à savoir serveur de transfert de données (ou dispositif équivalent) ou serveur de confiance ; - au moins un Serveur de Stockage (SdS) ; - éventuellement un ou plusieurs Serveurs de Fournisseurs de Produits (SFP). Les besoins de base sont les suivants : - Anonymat minimal : l'anonymat des Utilisateurs peut être directement assuré par le ou les SdS qui centralisent les éléments d'information recueillis. - Anonymat par tiers de confiance : alternativement, l'anonymat peut être réalisé par une architecture incluant un ou plusieurs serveurs supplémentaires qui sont gérés par un ou plusieurs tiers de confiance (ST) et qui sont des "passages obligés" lors des communications en consultation ou ajout d'éléments ; les adresses IP des Utilisateurs, qui consultent les éléments d'informations, sont ainsi cachées. L'identité (ou le pseudonyme) de l'Utilisateur qui ajoute un élément d'information est transformée (codée, chiffrée) par le serveur tiers, de manière différente à chaque ajout (en plus du fait que son adresse IP est cachée). La correspondance entre différentes transformations d'une même identité est connue par un ou plusieurs des serveurs tiers, ou par un ou plusieurs serveurs tiers indépendants des premiers (ce sont eux qui notamment peuvent dériver les degrés de confiance). Les serveurs tiers peuvent servir à fournir un certificat pour témoigner de la fourniture d'un élément d'information par un serveur. Ceci peut être utilisé dans le cadre de divers modèles économiques, comme on le verra plus loin. Les classeurs pourront aussi être stockés sur un serveur de stockage SdS. Dans ce cas, leurs liens sur les Contenus non-confidentiels (qui forment les profils) seront stockés sur le serveur de stockage SdS après chiffrement sur l'ordinateur personnel (ou un serveur de transfert ST). Ces liens ne pourront pas être déchiffrés par le serveur de stockage, mais seulement sur l'ordinateur personnel ou sur le serveur de transfert. Les besoins supplémentaires impliqués par le procédé de Recommandation Collaborative sont les suivants : - Anonymat minimal : L'anonymat des profils peut être assuré directement par des serveurs de stockage qui jouent aussi le rôle de serveurs de recommandation, c'est à dire qui produisent les profils, les maintiennent et les confrontent. - Anonymat par tiers de confiance : Alternativement, des serveurs de transfert peuvent avoir le rôle de produire et maintenir les profils et ensuite de les communiquer à un serveur de stockage après les avoir rendus anonymes, c'est à dire, après leur avoir associé une identité transformée (codée, chiffrée). Les serveurs de recommandation ne manipulent alors que des profils anonymes et sont incapables de déceler que deux profils appartiennent à un même Utilisateur. Pour éviter d'associer ensemble différents profils d'un Utilisateur, en reconnaissant une même adresse IP lors de leur transmission (par exemple quand manifestement il n'y a qu'un seul Utilisateur en ligne), on préférera utiliser un serveur de transfert différent par profil (autant que possible, c'est à dire dans la mesure où l'on dispose d'un nombre suffisant de serveurs de transfert. Par ailleurs, l'architecture décrite ci-dessus peut être mise à profit dans le cadre du commerce électronique par Internet, comme on va maintenant le décrire en référence à la figure 134. Ainsi cette figure montre qu'un serveur de stockage SdS contenant des Profils est capable de faire à un poste utilisateur PC des suggestions d'achat auprès du serveur d'un fournisseur SFP, ceci par l'intermédiaire d'un serveur tiers ST permettant d'assurer l'anonymat des utilisateurs au niveau des Profils. L'achat effectif d'un bien ou d'un service par l'Utilisateur auprès du serveur SFP, qui correspond à une acceptation de la suggestion, peut être prouvé par le serveur tiers ST auprès du serveur SFP par l'intermédiaire du serveur de stockage SdS, tandis que le service rendu par le serveur de stockage SdS et par le serveur tiers ST est dûment rémunéré (commission sur vente) par le serveur du fournisseur SFP (la rémunération $ du serveur tiers ST étant constituée par une fraction de la rémunération $$$ du serveur de stockage. Section 6 - Abonnements et fidélisation Selon cet autre aspect de la présente invention, il est intéressant qu'un serveur (par exemple un magazine électronique) propose de nouveaux contenus, sur une base périodique, par exemple bi-hebdomadaire. A l'issue de cette période, les contenus sont archivés comme décrit plus haut, et ne sont donc plus suggérés. De nouveaux contenus sont alors mis en place. On comprend que ceci incite fondamentalement l'utilisateur ou abonné à visiter le serveur au moins une fois dans la période de validité des contenus ajoutés (en l'espèce deux fois par semaine), ceci de façon à bénéficier de toutes les suggestions d'ajouts. Ainsi, les mécanismes de dérivation/suggestion/acceptation présentés dans ce chapitre et dans le chapitres précédents (voir le mode gelé dans le chapitre précédent) permettent d'exploiter la fibre de collectionneur de l'utilisateur. En effet, l'utilisateur qui collectionne des contenus dans un contenant est fortement incité à ne pas manquer une opportunité d'enrichir sa collection pendant qu'un contenu est encore disponible en ligne. Il veut ainsi retourner visiter le site Internet à la même fréquence que la mise à jour des contenus. L'utilisateur se trouve ainsi fidélisé. Chapitre IV - Manipulations (Figures FI à F14) Introduction On va décrire un système permettant de manipuler, notamment de reproduire d'un site à l'autre, des fragment de sources (ou documents) 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. Cette approche permet une nouvelle utilisation des contenus des sites sur la Toile. Un fragment de source XML permettant par exemple de présenter l'interface homme-machine d'un service sur la Toile peut être reproduit (ou importé) 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 (intitulé click2handle dans la suite de la description) 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. Une caractéristique du système est que les poignées et cibles sont représentés par un même objet graphique, et le fait de permettre d'insérer de nouveaux fragments dans une page, en les lâchant sur des cibles, revient par conséquent à permettre d'attraper les fragments possédant lesdits objets graphiques qui jouent le rôle de cible, pour les emporter ailleurs. Le présent système et procédé permettent ainsi avantageusement d'augmenter la visibilité des fragments présentés, en encourageant leur propagation par le fait qu'ils peuvent être très facilement reproduits de proche en proche d'une page à l'autre et d'un site à l'autre sur la Toile. Une application typique de ce procédé 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éé. Une autre application, qui est la symmétrique de celle mentionnée ci-dessus, 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. Les sources XML des pages Web sont décomposées automatiquement # en unités atomiques (indivisibles), appelées microstructures (qui correspondent aux contenus dees chapitres précédents), # et en une structure d'assemblage appelée macrostructure. Les microstructures représentent la granularité la plus fine possible pour les manipulations. En effet : # Les objets graphiques poignées et cibles permettant de glisser-déposer des fragments ne peuvent être affichées à une granularité plus fine que celle des microstructures. # Les microstructures sont atomiques : la modification d'une partie d'une microstructure entraîne la création d'une nouvelle version pour la microstructure entière. L'idée essentielle derrière les microstructures est la mise en facteur des contenus qui sont ré-utilisés dans les fragments. Chaque version d'une microstructure est mémorisée une seule fois (sauf pour des besoins de caching , pour augmenter les performances notamment, dans les cas d'accès entre différents serveurs) bien qu'elle puisse être pointée plusieurs fois par des fragments (d'une même macrostructure ou de macrostructures différentes). Ceci permet de minimiser les redondances lors des reproductions de fragments. Ainsi, non seulement les versions de fragment à mémoriser ont une granularité relativement fine, mais de plus la mise en facteur des microstructures permet d'alléger les fragments. La place mémoire prise par les documents comportant des versions multiples est ainsi minimisée. De plus, cette approche permet avantageusement de manipuler les microstructures de manière autonome, indépendamment de la gestion des fragments, en évitant ainsi toute la complexité liée au fait que ces derniers peuvent être : # composés d'une multiplicité de microstructures (et sous-fragments, voir la figure ci-après) imbriquées les unes dans les autres, # partagés entre plusieurs documents à différents niveaux d'imbrication, # avec des versions hétérogènes entre les niveaux. Ainsi, cette approche permet de # manipuler les microstructures dans le cadre de systèmes de gestion tierces tout en les mettant à contribution dans les fragments manipulés au moyen du système ; # de générer les microstructures dynamiquement, notamment à partir de bases de données, selon des règles de transformations (mapping) ; # de mémoriser des versions différentes d'une même microstructure dans le cadre de systèmes de gestion de données tierces. 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. La structure de données Chaque microstructure constitue le début d'un fragment de la source XML : fragment contient ladite microstructure ainsi que d'autres microstructures qui lui sont imbriquées le cas échéant (voir la figure FI) et qui ont alors pu être retrouvées grâce à la macrostructure. Lesdites autres microstructures sont positionnées sous des n#uds (n#uds XML) ayant un attribut récipient . Les n#uds récipients sont en général aptes à regrouper un nombre variable de fragments. En général, l'utilisateur ne reproduit pas directement une microstructure isolée, mais un fragment (la différence essentielle réside dans la mémorisation de la trace micr-ref ou fragment-ref du maillon amont dans la chaîne de reproduction - voir la section Représentation des macrostructures et microstructures ). Reproduire un fragment, par exemple d'une première source XML à une deuxième, revient à ajouter une information d'insertion dudit fragment dans la macrostructure de la deuxième source XML. Deux cas d'insertion de fragment sont possibles : Soit la version ne compte pas - le fragment inséré est destiné à être toujours présenté dans sa version la plus récente ; il n'y a alors pas besoin de copier dans la deuxième macrostructure la partie de la première macrostructure qui représente le contenu du fragment inséré (c'est-à-dire les n#uds représentant les sous-fragments), Soit la version compte - une version particulière du fragment est inséré ; les n#uds de la deuxième macrostructure représentant les sous-fragments de cette version sont alors aussi insérés dans la première macrostructure. L'auteur de la source XML ajoute des attributs de délimitation pour indiquer où se trouvent les n#uds récipients dans lesquels les utilisateurs pourront insérer des fragments. Par définition, chaque n#ud situé directement en dessous d'un n#ud récipient est un fragment. Ces attributs sont décrits à la section Attributs de délimitation . La méthode de présentation d'une source XML ainsi composée de fragments est présentée à la section Composition de feuilles de style . Le code HTML (et scripts associés) de présentation d'une source XML composé de fragments, produite notamment au moyen d'une feuille de style en XSL, est apte à associer à chaque fragment sélectionné un objet graphique distinct, permettant de distinguer les fragments entre eux et pouvant jouant un triple rôle de bouton d'édition, et de poignée et cible permettant des opérations de glisser-déposer. L'utilisateur peut ainsi avoir la possibilité d'éditer les textes, images et liens du fragment dont il active la poignée. La granularité de manipulation des fragments est en général plus grossière que celle des microstructures. Des attributs particuliers sont associés aux fragments de différents niveaux d'imbrication, pour indiquer dans quelle mesure ils sont manipulables individuellement. Ces attributs permettent ainsi de spécifier quels sont les fragments qui sont éditables en bloc, ou attrapables pour être glissé-déposé, ou encore qui permettent d'afficher un objet graphique cible du glisser-déposer permettant d'insérer un autre fragment (par exemple juste avant le fragment en question). Ces caractéristiques du logiciel de présentation sont décrits plus loin à la section Cibles et Poignées . Caractérisation du système vu de l'utilisateur Le système est d'abord caractérisé par un bouton (libellé click2handle dans la figure ciaprès) apte à changer le mode d'une page pour que, sélectivement, les présentations des fragments sélectionnés soient munies d'un objet graphique poignée (par exemple sous la forme d'un pictogramme représentant une pièce de puzzle) permettant de les attraper en vue de les reproduire dans un récipient cible dans une autre page (ou éventuellement dans la même page) au niveau (par exemple juste à gauche ou au-dessus) de la présentation d'un fragment elle-même munie d'une poignée, par un simple glisser-déposer sur cette poignée. Le système est ainsi particulièrement caractérisé en ce que le même objet graphique (celui ayant l'apparence d'une pièce de puzzle) sert de poignée et de cible et par conséquent les fragments importés par un visiteur dans une page sont eux-même importables ailleurs (dans d'autres pages, d'autres sites, ou encore dans la même page). Le principe du bouton click2handle et des Poignées/Cibles est illustré schématiquement ci-desous. Par défaut, un bouton click2handle fait partie des pages du site Web (voir figure F2). Quand l'internaute clique sur le bouton click2handle, les poignées des fragments qui peuvent être importées sont ajoutées à la page affichée (voir figure F3). *L'utilisateur peut alors attraper un des fragments pour le glisser-déposer dans une page de son propre site (voir figure F4). Au préalable, il accède à ladite page de son propre site en ajoutant /admin à l'URL (adresse Web) de cette page. Alternativement, le bouton click2handle de ladite page peut proposer à l'utilisateur de créer une version personnelle de ladite page (ou retrouver une version personnelle déjà créée le cas échéant) après avoir fourni un mot de passe. Le résultat de l'opération de glisser-déposer illustré dans la figure F4 est présenté à la figure F5. Gestion des macrostructures et microstructures La représentation des sources XML sur un ou plusieurs serveurs est décrite dans la section Représentation des macrostructures et microstructures . Le traitement des différentes opérations de copie, modification et suppression de fragments est décrit à la section Opérations sur les fragments . La modification d'un fragment engendre une modification directe, ou (dans le cas où la version compte) une suggestion de modification, dans les fragments qui y étaient dérivés. De même la modification d'une microstructure entraîne la modification directe, ou (dans le cas où la version compte) une suggestion de modification, dans les fragments qui l'ont importés. Ceci est décrit à la section Mécanismes de propagation de versions et de suggestion . Enfin, le cas particulier d'un fragment construit à partir d'une page HTML classique est décrit à la section Importation de fragments en HTML . Dans cette section est aussi décrite une extension générale a la structure de données permettant de mémoriser des résultats de traitement (tel que la miniaturisation d'une page HTML) avant fourniture à la feuille de style XSL pour éviter de les recalculer à chaque accès. Section Attributs de délimitation Prenons comme exemple la source XML (ou document) suivante : Nouvelles créations du célèbre couturier Femand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Pour en distinguer les fragments, on fournit ce document au système après avoir ajouté un attribut mix-recipient sur le n#ud qui est le parent dedits fragments. Noter que dans tous les exemples que nous prendrons, les attributs propres au système seront préfixés par mix- . Dans le présent exemple, les deux noeuds ( Short Bunias et Chemisier argent ) deviennent des fragments suite à l'ajout de cet attribut sur le n#ud qui est leur parent : En retour, le système (sur platforml.net en l'occurence) remplacera cet attribut par un attribut plus détaillé ( mix-recipent-number ) qui spécifie la position du récipient en question dans la microstructure dans laquelle il se trouve, ainsi que d'autres attributs, notamment les identifiants des fragments, qui vont s'avérer utile dans la construction de la présentation d'affichage (qui est décrite dans les deux sections suivantes) : Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@Iemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Noter que les annotations ajoutées ont exclusivement la forme d'attribut. Cette approche offre l'avantage crucial de ne pas modifier la structure d'imbrication des n#uds. Section Composition de feuilles de style A chaque fragment peut être associé # un premier attribut mix-micrlocalstyle-src spécifiant la source de la feuille de style (dite locale ) qui a été choisie par l'auteur de la microstructure de tête dudit fragment, # un deuxième attribut mix-fragmentlocalstyle-src spécifiant la source de la feuille de style locale, pour ledit fragment, choisie par son propriétaire, # et un troisième attribut mix-localstyle-preferred qui figure dans le cas où le propriétaire dudit fragment préfère appliquer le style local de la microstructure de tête dudit fragment ( mix-localstyle-preferred = "micr" ) ou celui dudit fragment ( mix- localstyle-preferred = "fragment" ). Dans le cas où aucun style local n'est préféré, 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. Lors de l'application des feuilles de style et d'autres programmes de transformation le cas échéant (décrits plus loin), le système transforme en XHTML le document sauf tous les fragments qui ont l'attribut mix-local-style-preferred avec une valeur spécifiée ("micr" ou "fragment"). Ces derniers sont copiés tel quel 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-local-style-preferred 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. Pour illustrer ce procédé, reprenons l'exemple du couturier Fernand Durand et précisons ces attributs de style: mix-document-src="http://platforml.net/share?doc-id=d2150" mix-content-src="http://platforml.net/share?id=c3215640" mix-micrlocalstyle-src="http://somewhere.com/stylel.xsf" mix-localstyle-preferred="micr" > Nouvelles créations du célèbre couturier fernand Durand. durand fernand fd@lemail.com mix-content-src="http://platformi.net/share?id=c3215641" m ix-fragmentlocalstyle-src= "http://foo.com/style-produit-l.xsl" mix-localstyle-preferred="fragment" > Short Bunias 590Frs Laine vierge à 100% mix-micrlocalstyle-src="http://foo.com/style-produit-l.xsl" > Chemisier argent 790Frs Soie de Chine, légère et douce Les feuilles de styles en XSL utilisées par les applications d'affichage sont, par exemple, les suivantes : # http://somewhere.com/style1.xsl : Catalogue : Les produits du catalogues : Les produits du catalogues : nom : Le catalogue Observer les deux derniers templates (propres au langage XSL) qui ont pour effet de recopier mot à mot les n#uds pour lesquels l'attribut mix-localstyle-preferred a la valeur micr ou fragment pour les laisser aux passages suivants. Ainsi, l'application d'affichage récupérera d'abord le code XML suivant : Le catalogue Catalogue : Les produits du catalogues : Nouvelles créations du célèbre couturier fernand Durand. mix-fragmentlocalstyle-src="http://foo.com/style-produit-i.xsl" mix-localstyle-preferred="fragment" > Short Bunias 590Frs Laine vierge à 100% nom : Chemisier argent Ensuite, l'application d'affichage effectue un deuxième passage sur le document. Elle sélectionne le n#ud produit et lui applique la feuille de style http://foo.com/style- produit-l.xsl dont le code est par exemple le suivant : # http://foo.com/style-produit-l.xsl : left nom : prix : (TTC) description : Le produit miracle preferred='fragment' $or$ ancestor(*/@mix-localstyle-preferred[text()='micr'$or$text()=1fragment'])"> On obtient ainsi finalement le document HTML suivant : Le catalogue Catalogue : Les produits du catalogues : Nouvelles créations du célèbre couturier fernand Durand. nom : Short Bunias prix : 590Frs (TTC) description :Laine vierge à 100% nom : Chemisier argent Section Cibles et Poignées La construction de la présentation d'affichage en mode manipulation s'effectue en fonction des attributs possédés par les n#uds récipients et les n#uds fragments. Les n#uds récipient possèdent un attribut mix-recipient-accessgrain dont la valeur indique si de nouveaux fragments peuvent y être insérés par le propriétaire du document ou par un visiteur . Les n#uds fragments possèdent un attribut mix-fragment-accessgrain qui permet de distinguer ceux d'entre eux qui sont manipulables et pour quelles types de manipulations ils le sont. Par défaut, le fragment n'est pas manipulable individuellement, cependant il pourra l'être au sein d'un fragment ancêtre qui est manipulable le cas échéant. Dans le cas où ledit attribut à la valeur private , seul le propriétaire du document pourra le manipuler en édition et insertion, reproduction ou déplacement. Un seul et même objet graphique jouera le rôle de bouton d'édition (pour le cas du clic), de cible d'insertion et de poignée pour attraper le fragment et l'emmener ailleurs (cas du glisser-déposer). Dans le cas où ledit attribut a la valeur public , le fragment est aussi exportable par un visiteur ; une poignée lui sera présentée, cependant un visiteur ne pourra pas l'éditer. Dans le cas où en plus le n#ud parent possède l'attribut mix-recipient-accessgrain ayant la valeur public , ladite poignée servira aussi de cible pour le visiteur public. Les feuilles de style, en langage XSL, génèrent des scripts appelant les fonctions pré-établies (et définies une fois pour toutes dans l'entête de la page Web générée) qui dessinent les boutons "poignées-cibles". Pour ce faire des blocs tels que les suivants sont insérés dans les templates (en terminologie XSL) pour transformer les n#uds fragments : gbxDraw( ' ', ' ', ' ' ...); gbxDrawInsert( ' ', ' ', 'produit', 'urn:glassbox-document-2' ); Le premier bloc est apte à introduire dans la page HTML une fonction gbxDraw() qui permet d'insérer dans l'affichage un bouton poignée-cible. Cette fonction prend en paramètres 1. La référence du fragment à éditer (il s'agit de la valeur de l'attribut "mix-fragment-src" présenté plus loin) qui pourra notamment être retransmise aux fonctions gbxEdit() ou gbxInsert() (présentées plus bas) 2. La version du fragment et la version la plus récente à la source (il s'agit de la valeur de l'attribut "mix-sourcefragment-version" présentée plus loin) qui permet de dessiner différement la poignée s'il faut suggérer une nouvelle version Le deuxième template sert à introduire la fonction "gbxDrawInsert()" qui permet d'insérer dans l'affichage une cible d'insertion après le dernier fragment d'un récipient. Cette fonction prend en paramètres : 1. La référence du récipient cible (il s'agit de la valeur de l'attribut "mix-recipient-number" présenté plus loin) 2. La référence du fragment contenant le récipient (la valeur de l'attribut "mix-fragment-src" du premier "ancêtre" du noeud récipient ayant cet attribut) 3. Le référence du fragment à insérer 4. Le référence du fragment à la suite duquel il faut insérer. Les boutons "poignées-cibles" appellent la fonctionnalité d'édition d'un fragment au moyen d'une fonction "gbxEdit()" qui appelle un service qui traite le fragment pour le présenter en un formulaire de saisie. Cette fonction prend la référence du fragment à éditer (il s'agit de la valeur de l'attribut "mix-fragment-src"). Elles mettent également en #uvre la fonctionnalité d'insertion ou de création d'un fragment au moyen d'une fonction "gbxInsert ()". Celle-ci prend en paramètres : 1. La référence du récipient cible ("mix-recipient-number") 2. La référence du fragment contenant le récipient 3. Le référence du fragment à insérer (à défault, la fonction donne un fragment vierge) 4. Le référence du fragment à la suite duquel il faut insérer (à défault, le service insérera en dernière position). Appliquons ce procédé à l'exemple suivant : mix-frag mentlocalstyle-src="http//plateform 1. net/xs] 1. xsl" mix-localstyle-preferred="fragment" > Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce mix- fragmentlocalstyle- src="http//plateform1. net/xsl2.xsl" mix-localstyle-preferred="fragment" >Pour les soirées décontractées Pour les week-ends Mode "normal" : Le fragment catalogue sera transformé dans le code HTML suivant : Catalogue : Nouvelles créations du célèbre couturier Fernand Durand Les produits du catalogue : Short Bunias Chemisier argent (pour les soirées décontractées) (pour les week-ends) Mode "manipulation" : (l'internaute veut voir les "poignées-cibles") Le fragment catalogue sera transformé dans le code HTML suivant : gbxDraw('http://platform1.net/share?id=1', '0,0', 'public') Catalogue : Nouvelles créations du célèbre couturier Fernand Durand. Les produits du catalogue : Short Bunias gbxDraw('http://platform1.net/share?id=2', ", 'private') Chemisier argent (pour les soirées décontractées) (pour les week-ends) gbxDrawInsert('http://platform1.net/share?id=2', '1', 'conseil', 'urn:document-l') Si l'internaute est identifié en tant que propriétaire du document, en tenant compte du fait que l'attribut "mix-fragment-accessgrain" du noeud "catalogue" est "private", le système traduira le fragment catalogue de la façon suivante : gbxDraw('http://platform1.net/share?id=0', '0,0', 'private') Catalogue : Nouvelles créations du célèbre couturier Fernand Durand. Les produits du catalogue : gbxDraw('http://platform1.net/share?id=1', '0,1', 'public') Short Bunias gbxDraw('http://platforml.net/share?id=2', ", 'public') Chemisier argent gbxDraw('http://platform1.net/share?id=50', ", 'public') (pour les soirées décontractées) (pour les week-ends) gbxDrawInsert('http://platform1.net/share?id=2', '1', 'conseil', 'urn:document-l') gbxDrawInsert('http://platform l.net/share?id =0', '1', 'produit', urn:document-1') La figure F6 présente schématiquement, dans un diagramme de collaboration (en notation UML, Unified Modelling Language ) trois écrans et deux composants (services Web). Le scénario présenté comprend trois ensembles d'interactions avec l'utilisateur qui utilisent ces composants. Ces interactions sont les suivantes : 1. Basculer l'affichage du mode normal au mode manipulation 1.1. En retour, le système présente à l'utilisateur la page HTML en mode manipulation 2. L'utilisateur a cliqué sur un bouton d'édition associé à un fragment 2. 1. En retour, le système présente à l'utilisateur un éditeur assemblé automatiquement en fonction du contenu du fragment à éditer 3. L'utilisateur a cliqué sur un bouton permettant de sauvegarder les résultats de l'édition 3.1. Ces résultats sont transmis au service Micr (comme décrit plus loin) 3. 1.1. Le service Micr transmet la requête au service Macr pour mise à jour de la macrostructure du document 3. 2. (et 3. 3) Le service raffraîchit le contenu de la présentation en mode manipulation ; Alternativement (en 3. 2' et 3. 3') si la sauvegarde a été demandée (en 3) dans une fenêtre séparée, le système renvoie un OK à l'utilisateur, rafraîchit le contenu de la présentation en mode manipulation ( opener.reload() ), puis ferme la fenêtre d'édition ( close() ) 4. Reproduire un fragment d'un endroit à un autre par un glisser-déposer. Section Représentation des macrostructures et microstructures Reprenons l'exemple la source XML, reproduite ci-dessous, auquel on avait ajouté un attribut mix-recipient="true" sur le n#ud pour indiquer que ce noeud constitue un récipient de fragments : Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Avant de pouvoir retourner le document avec des attributs supplémentaires, comme il l'a été décrit à la section Attributs de délimitation , la plateforme a décomposé le document original en une macrostructure et trois microstructures, et seulement ensuite les a recomposés pour obtenir ledit document. Le but de la présente section est de décrire l'architecture du système qui met en #uvre ce procédé et de dévoiler la représentation (en XML) des éléments décomposés en interne dans le système. Le résultat du procédéde de décomposition est illustré ci-dessous. Les microstructures sont les suivantes : [...] Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce [...] Observer dans la première microstructure l'attribut mix-recipient-number= "0" qui indique qu'à cette position des fragments pourront être imbriqués. Ce numéro "0" est utilisé ci- dessous dans la macrostructure pour faire le joint avec cette microstructure. La macrostructure du document, qui sert à représenter l'imbrication des fragments qui chacun pointe sur une microstructure, est la suivante : Observer les n#uds mix :ref-versions qui permettent de regrouper plusieurs versions d'un fragment. Le "diagramme de collaboration (en notation UML) de la figure F7 illustre le procédé au moyen d'un scénario d'utilisation et décrit le fait que la décomposition est réalisée par deux composants (ou services) - Micr et Macr - qui dans cet exemple sont respectivement installés sur un Serveur Web et un serveur dédié au système appelé Serveur Mix . Ces deux composants sont pilotés par une application (ici une page ASP+ ) faisant appel au service Micr qui lui-même fait appel au service Macr. L'application, en appelant la méthode PutXMLDoc() du service Micr , ordonne l'enregistrement des trois microstructures du document sur le Serveur Web, et sa macrostructure sur le Serveur Mix . Le client peut retrouver son document au moyen du procédé décrit dans le diagramme de collaboration de la figure F8. L'application (la page ASP+) appelle la méthode GetXMLDoc() du service Micr qui lui retourne alors le document XML suivant qu'il a pu recomposer à partir de la macrostructure du document et des trois microstructures sus-mentionnées : Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Section Opérations sur les fragments On va décrire successivement les cas de création d'un nouveau fragment, l'importation d'un fragment distant et la modification d'un fragment. Le poste client apporte des modifications (ici : ajout d'un noeud produit ) et renvoie cette source à l'application : Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Pull Orange 1590Frs Cachemire à 99% L'application peut réaliser les modifications de la façon décrite dans le diagramme de collaboration de la figure F10. En appelant la méthode PutXMLDoc() du service Micr , l'application enregistre la nouvelle microstructure du document sur le Serveur Web, et met à jour la macrostructure sur le Serveur Mix . La nouvelle version de la macrostructure est la suivante : Alternativement, le procédé pourrait être celui de la figure F10. La page ASP+, sachant quel est le récipient dans lequel on ajoute le nouveau fragment, lance la mise-à-jour directement. Cas de l'importation : Le client veut insérer dans son document un n#ud provenant d'une autre plateforme Mix : Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com Short Bunias 590Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Pull Orange 1590Frs Cachemire à 99% Dans cet exemple, le fragment importé réside dans d'autres serveurs : un serveur Web n 2 contient la microstructure et un serveur Mix n 2 contient la macrostructure qui pointe sur cette dernière. L'application peut réaliser l'importation au moyen d'un appel PutXMLDoc comme décrit dans le diagramme de collaboration de la figure FI 1 : Alternativement, l'insertion du fragment importé peut être directement (ou via le service Micr comme dans la figure ci-dessous) commandé au service Macr qui gère la macrostructure. Cas de modification d'un fragment existant : Le client peut modifier un n#ud d'un document XML, par exemple modifier le prix du Short Bunias : Nouvelles créations du célèbre couturier Fernand Durand. Durand Fernand fd@lemail.com .//platforml.net/share?id=54"> Short Bunias 690Frs Laine vierge à 100% Chemisier argent 790Frs Soie de Chine, légère et douce Pull Orange 1590Frs Cachemire à 99% Une nouvelle version de la microstructure est alors créée, par exemple comme décrit dans le diagramme de collaboration de la figure F13. Dans une autre configuration, certains services Micr peuvent être dans un Serveur Mix au lieu de se trouver dans un serveur Web. Un exemple très simple de ce cas de figure est illustré dans le diagramme de collaboration de la figure ci-dessous. Section Mécanismes depropagation de versions et de suggestion Les microstructures et les fragments peuvent avoir des numéro de version pour permettre d'accéder à une version déterminée malgré leur évolution. Dans un document dans sa forme brute, on peut préciser la version d'une microstructure dans l'attribut mix-micr-src et la version d'un fragment dans l'attribut mix-fragment-src. On va illustrer ci-dessous le cas d'une version précisée pour un fragment : mix-fragment-src="http://platforml.netyshare?id=3215640&v=0"> [...] [...] Dans cet exemple, on importe un fragment produit qui est disponible à l'adresse http://platform2.net/share?id=1825473&v=1 . A cette adresse on peut trouver : [...] [...] La macrostructure du document qui importe donc ce fragment à sa version 1 est la suivante . Noter qu'en local, c'est la version 0 d'un fragment qui va être créé. [...] Le document recomposé est le suivant : mix-f ragment-src="http://platform 1 . net/share?id =3215640&v=0"> [...] [...] On remarquera deux modifications apportées par le système : 1. le fragment est maintenant celui contenu dans la propre macrostructure du document, la version indiquée est celle de ce dernier et non pas la version du fragment à la source de l'importation ; 2. un attribut mix-sourcefragment-version (ou mix-sourcemicr-version dans le cas de l'importation d'une microstructure) a été ajouté ; cet attribut a 2 valeurs, le numéro de la version importée et le numéro de la version la plus récente. Dès que le fragment (dont la version compte ) est modifié sur le poste client, par exemple en y insérant un sous-fragment, les sous-fragments du fragment importé sont reproduit dans la macrostructure et les modifications sont insérées par la suite sous forme d'ajout de version. Comme l'ancienne version d'un fragment (ou sous-fragment) modifié peut être utilisé par un autre document, on ne peut pas la supprimer directement. Un compteur d'importation y est attaché, et elle n'est supprimé que quand ce compteur passe à zéro (après la décrémentation provoquée par la suppression de la dernière référence). De même, un compteur d'importation est associé aux microstructures et une ancienne version d'une microstructure ne peut être supprimée qu'à partir du moment où il n'existe plus de référence sur elle. La figure ci-dessous illustre l'ajout d'une version du fragment en question dans la macrostructure. Pour cette nouvelle macrostructure, le document recomposé est le même à l'exception de la nouvelle version du n#ud : [...] [...] Dans le cas où la version compte , les attributs mix-sourcefragment-version et mixsourcemicr-version (dans le cas de l'importation d'une microstructure), par le fait qu'elles ont 2 valeurs (le numéro de la version importée et le numéro de la version la plus récente) permettent de suggérer la version la plus récente quand elle est différente de la version (volontairement précisée) qui avait est importée. Section Importation de fragments en HTML Au moment de l'accès à ladite page HTML, cette dernière est soit directement traduite en XHTML afin d'être compatible avec le système d'affichage basé sur les feuilles de style, soit une autre transformation est lancée au préalable : il peut par exemple être nécessaire de la miniaturiser pour la faire rentrer dans l'espace d'affichage disponible. Noter qu'un fragment XHTML n'a pas de n#ud ayant un attribut récipient et ne servira donc pas à accueillir des sous-fragments. Si la version compte, la version en XHTML de la page est sauvegardée sous la forme d'une microstructure. L'utilisateur peut directement importer, sous un n#ud récipient, n'importe quelle page HTML du Web. Par défaut, aucune microstructure en XML n'est mémorisée pour ladite page HTML, et c'est son URL qui est inséré dans la macrostructure. Dans l'exemple ci-dessous nous avons deux pages Web www.sitel.com et www. site2.com qui ont été importés. Deux transformations ont été spécifiées pour la présentation de la deuxième page : Web service (il s'agit par exemple de laminiaturiser pour la faire rentrer dans l'espace d'affichage disponible) et une feuille de style XSL. Mes pages préférées Durand Fernand fd#lemail.com La décomposition de ce document résulte en la macrostructure suivante: params='doc,date', values='##mix-fragment-src,##DATE'; http//plateform1. net/html-thumbnails.xsl" localstyle-preferred="fragment"> La seule microstructure qui ait été mémorisée est la suivante : Mes pages préférées durand fernand fd@lemail.com En effet, aucune version n'ayant été spécifiée, les deux pages HTML sont destinées à être retrouvées directement de leurs sources. Alternativement, un fragment HTML pourrait être mémorisé sous forme de microstructure de la manière suivante : ... ... (tout le code xhtml de la page www. site2.com ) Le document recomposé est le suivant : mi x- mi crloca [style- src ='http//pl ateform 1. net/xsl 1. xsl" mix-localstyle-preferred="micr" > Mes pages préférées Durand Fernand fd#lemail.com mix-fragmentlocalstyle-src="http//plateforml.net/xhtml-raw.xsr mix-localstyle-preferred="fragment" > ... (tout le code xhtml de la page www.sitel.com ) ... (tout le code xhtml de la page www. site2.com ) Le résultat des différentes transformations d'un fragment sont mémorisé dans un cache dans le cas où l'attribut mix-localstyle-cached est déclaré pour ledit fragment dans le document. Un fragmenta macrostructure contiendra alors une référence au cache, au moyen d'un n#ud Bien entendu, la présente invention n'est nullement limitée aux formes de réalisations décrites et représentées, mais l'homme du métier saura y apporter toute variante ou modification conforme à son esprit. En particulier, les caractéristiques de l'invention énoncées dans les différents chapitres et les différentes sections de ces chapitres peuvent être combinées de manières très diverses. REVENDICATIONS 1. 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. 2. Système selon la revendication 1, 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. 3. Système selon l'une des revendications 1 et 2, 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. 4. Système selon la revendication 3, 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. 5. Système selon l'une des revendications 1 à 4, 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. 6. Système selon la revendication 5, 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. 7. Système selon l'une des revendications 1 à 6, 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. 8. Système selon les revendications 6 et 7 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. 9. Système selon la revendication 8, 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é. 10. Système selon la revendication 9, 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. 11. Système selon l'une des revendications 1 à 10, 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. 12. Système selon l'une des revendications 1 à 10, 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. 13. Système selon l'une des revendications 1 à 12, caractérisé en ce que lesdits éléments activables sont constitués par des représentations miniaturisées des pages d'origine correspondantes. 14. Système selon l'une des revendications 1 à 13, 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. 15. Système selon la revendication 14, 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. 16. Système selon la revendication 1, 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. 17. 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. 18. Procédé selon la revendication 17, 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. 19. Procédé selon l'une des revendications 17 et 18, 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. 20. Procédé selon l'une des revendications 17 à 19, 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. 21. Procédé selon l'une des revendications 17 à 19, 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. 22. Procédé selon l'une des revendications 20 et 21, caractérisé en ce que les moyens de mémorisation sont contenus dans un serveur accessible par réseau à partir du poste client. 23. Procédé selon l'une des revendications 17 à 22, 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. 24. Procédé selon les revendication 23 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é. 25. Procédé selon la revendication 24, 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é. 26. Procédé selon la revendication 25, 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. 27. Procédé selon l'une des revendications 17 à 26, 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. 28. Procédé selon l'une des revendications 17 à 26, 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. 29. Procédé selon l'une des revendications 17 à 28, caractérisé en ce que lesdits éléments activables sont constitués par des représentations miniaturisées des pages d'origine correspondantes. 30. Procédé selon l'une des revendications 17 à 29, 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. 31. Procédé selon l'une des revendications 17 à 30, 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. 32. Procédé selon la revendication 17, 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.