Cette page a démarré sur PathsInHypermedia.
Quels sont les CheminsDansHypermédia ?
La page ElémentsDeLocalité mentionne que Meatball n'a pas de "chemins" en tant que tels. Les différents SchémasIndexation sont plus comme des cartes que des chemins - un chemin est plus que simplement un lien d'un noeud A à un noeud B. Imaginez la liberté de mouvement dans un parc public et la distinction des chemins dedans. Un chemin est une structure navigationnelle, pas simplement une potentialité de navigation.
Quelques rhétoriques intéressantes sont décrites sur [les "Patterns of Hypertext"] d'[Eastgate] et démontrées sur le [Jardin Hypertexte d'Eastgate]

''Ce sont des essais merveilleux et ils suggèrent qu'avant d'aller trop loin à implémenter des Chemins dans les wikis, nous devrions faire quelque recherche empirique pour évaluer les ReprésentationsDeChemins candidates. Les différents hypertextes web pointés dans les essais devraient être de bons bancs d'essais de l'utilité des différentes approches de visualisation (par ex. GraphViz, TouchGraph ou les rendus botaniques) :
- quelles sont les approches qui se différencient le mieux des différents webs ?
- quelles approches mènent à plus d'attentes informatives (semble plus en phase avec le web étant représenté) ?
--JonSchull ''
Les DossiersEtSujets servent partiellement ce rôle, comme n'importe lesquels des SchémasIndexation de LienHorsDeLaLigne, comme le LienVisitant qui est implémenté dans PhpWiki. Mais aucun n'approche le niveau suggéré ici.
Voir aussi LienVisité pour une discussion plus approfondi de chemins construits socialement et implicitement (Hebbian learning).
Quelques exemples ==
Dans Meatball, et d'autres hypermédias fondés sur wiki, il est tout à fait possible pour les chemins d'être couchés par la communauté, tout simplement en écrivant les liens à l'intérieur des pages. Prenez l'exemple du Wiki:OneMinuteWiki, qui à un certain moment avait des liens vers le suivant dans une séquence (par ex. Wiki:OneHourWiki), et cette page ensuite qui avait un lien vers la prochaine en séquence (Wiki:OneDayWiki) et ainsi de suite. Un autre exemple serait le TourBus qui a voyagé dans l'InterWiki, s'arrêtant sur chacun d'eux avec un commentaire mineur. Ce sont des WebRings, une structure simple de chemin.
Créer des chemins comme ça est néanmoins laborieux et fragile, tout spécialement avec les chemins de rhétorique les plus intéressants.
Mon exemple hypertexte favori de contrepoint/miroir du monde est [Digital Moments de Doug Menuez]. Une galerie d'images arrangées séquentiellement avec des commentaires, avec une fonctionnalité délicieusement non évidente de contenir un monde de miroir. Pour voir ce que je veux dire, promenez-vous dans la galerie, puis recommencez à nouveau mais cette fois-ci cliquez directement sur l'une des images au lieu des liens suivant/précédent.
Un modèle suggérée d'interface / structure
J'imagine qu'il serait possible de construire une fonctionnalité dans un moteur wiki conçue pour supporter les chemins comme une structure surposée .. une page ailleurs pourrait lister les noeuds avec des commentaires optionnels et puis faciliter le voyage dans ce chemin avec le commentaire et le chemin de navigation visible sur la page elle-même, peut-être comme un titre bonus inséré en haut. Une forme de TransClusion peut-être ? Visiter les noeuds individuels, sans traverser le chemin (par ex. en suivant quelque lien au hasard) présenterait la page dans sa forme normale, peut-être avec une liste annexe en pièce-jointe des chemins visibles à partir de ce noeud.
Hmmm ... peut-être que le commentaire ne vivrait pas sur les chemins spécifiques des pages personnelles, mais à la place il existerait dans les noeuds. Est-ce que les PagesSectionnées aideraient ici ? Je pense encore que la liste de noeuds devrait être maintenue dans un espace centralisé (la page personnelle du chemin), pour faciliter une construction facile et une maintenance du chemin.
Compte tenu du fait que n'importe quel noeud peut en fait exister sur de multiples chemins, et que le chemin du commentaire pourrait être différent pour chacun, ceci affecte aussi les concepts des VuesMultiples (MultipleViews) et PointDeVue.
Il est aussi possible que n'importe quel noeud donné puisse existe sur plus d'un chemin, vraiment tout à fait possible avec un commentaire différent à chaque fois. Par exemple, le chemin peut parcourir un certain nombre de noeuds, en construisant dans le voyageur une conscience d'un espace, et puis revenir en arrière sur lui-même à un noeud antérieur pour renvoyer à nouveau au-dessus de ce noeud compte tenu de la conscience améliorée et de la compréhension du voyageur.
Cette récurrence étatique peut néanmoins prouver que c'est pénible dans l'implémentation. Ne prenons pas de l'avance sur nous-mêmes.
Idées d'Implémentation
Cookies
- Le fait de cliquer sur les liens chemins installera un "cookie" chemin indiquant sur quel chemin vous vous situez. Vous êtes toujours sur un chemin seulement.
- Au moment de visiter une page, le programme du MoteurWiki vérifie s'il fait partie du chemin que votre cookie indique.
- Si oui, le MoteurWiki ajoutera des liens "Suivant," "Précédent," et "Liste" à la barre de navigation.
- Si non, rien ne se passe. De ce fait, vous pouvez prendre des détours à partir de votre chemin en cours et revenir plus tard.
- Quand une page est affichée, un lien d'installation-du-cookie-chemin s'affichera pour chaque chemin sur laquelle est cette page. Par conséquent, vous pouvez basculer et changer de chemin au moment de regarder une page qui est sur plusieurs chemins.
args URL
Au lieu d'utiliser l'URL habituelle http://www.usemod.com/cgi-bin/mb.pl?CheminsDansHypermédia, le chemin de navigation serait http://www.usemod.com/cgi-bin/mb.pl?path=TechnologyTour&next=PathsInHypermedia&from=WikiTechnology
Les args next et from permettent un voyage bi-directionnel sur le chemin et permette même différents commentaires selon la direction sur laquelle vous voyagez.
None
Similaire aux catégories, faites-en quelque chose de distribué. En bas, ajoutez le nom du chemin, tout comme la liste des liens précédent, suivant pour chaque chemin de la page. La "liste" lien mène à un aperçu du chemin généré par une recherche sur le nom du chemin.
- Avantages
- peut être fait maintenant
- Inconvénients
- exige une édition ennuyeuse de chaque page sur le chemin
- fragile : un éditeur de page normal pourrait rompre le chemin
- le commentaire du chemin est visible pour tous les visiteurs, pas simplement ceux sur le tour bus. Les indigènes pourraient se révolter.
Frames
En utilisant soit le cookie ou la méthode des args url de navigation, les noeuds pourraient être affichés dans une frame distincte du commentaire/navigation.
- Avantages :
- n'exige pas la coopération directe du site étant navigué
- le chemin navigateur pourrait fonctionner sur un site/serveur complètement différent
- le chemin pourrait traverser beaucoup de site différents, pas simplement des wikis.
- Inconvénients
- certaines personnes sont allergiques aux frames
- quelques sites sont allergiques aux frames
Questions ouvertes
Que construirions-nous si la technologie chemin était intégrée à l'intérieur du MoteurWiki ?
Mieux à ce stade : que construirions-nous qui ne puisse être construit en ajoutant des liens clairs aux pages dans le chemin ?
- méta commentaire, comme dans la présentation powerpoint de SunirShah pour la conférence OReillyPeerToPeer. http://sunir.org/meatball/SoftSecurity/p2p2001.ppt
Si les chemins sont implémentés dans le même MoteurWiki qui fournit les noeuds, est-ce qu'une page non visité via un chemin devrait montrer ces chemins ? Peut-être qu'un chemin pourrait être conçu comme privé, où le seul moyen d'aller sur le chemin serait la page chemin de démarrage. Pensez aux tours Safari camouflés. Raffinement ultime - un chemin donné peut avoir la totalité du chemin dissimulé ou simplement des noeuds spécifiés. (mais ne le transporte pas ici ;-) (but lets not get carried away here ;-)
et maintenant quelque chose de complètement différent ...
Les slides de la conférence Hypertexte de Mark Bernstein en 2001, [Card Shark And Thespis: exotic tools for hypertext narrative] (ed: ?), sont désormais disponibles. Hautement recommandées !
"Plutôt que de créer des acteurs complexes, créons des automates simples qui disent des choses intéressantes compte. C'est du théâtre." -- MarkBernstein
Il démarre avec une simple prémisse -- au lieu de construire un hypertexte en prenant un bouquet de noeuds et en créant des liens, commencez avec tout interlié et puis retirez les liens jusqu'à ce que vous ayez quelque chose d'intéressant. Il construit un modèle où chaque noeud a deux éléments supplémentaires : contraintes et assertions. Les contraintes sont des choses qui doivent être vraies pour ce noeud pour être disponible à visiter et les assertions sont les façons dont ce noeud modifie l'environnement. Imaginez une machine état.
Ceci me rappelle un ancien projet que j'ai abandonné - un espace communautaire hypermédi, où chaque noeud était soit une personne ou un lieu dans l'espace, et la connaissance n'est seulement disponible que dans l'échange d'autre connaissance. Si vous connaissiez Bob, alors quand vous visitez la page de Jim, elle vous révélerait plus d'information, comme le meilleur endroit pour boire un café le dimanche. Connaître ça déverrouille des mystères plus profonds. La connaissance serait représentée tant par des questions et réponses et même les questions ne seraient pas ouvertes, mais dépendantes de votre connaissance contextuelle. Pensez à une aventure texte collaborative, une cryptocratie. Le visiteur occasionnel n'a pas beaucoup de pouvoir, mais la persistence à participer est gagnante.
Hebbian Learning
Et si les visiteurs du wikis étaient amenés à créer des chemins non consciemment, mais simplement en faisant ce qu'ils font maintenant : suivre les liens de page en page ? Maintenant ce serait un excellent moment pour lire le LienVisité qui construit des poids selon un processus appelé Hebbian learning sur l'idée simplement mentionnée de la LocalSiteMap idea.
Références
- http://www.enteract.com/~marc/portfolio/toursintro.htm
- Wiki:WikiWithTrails
- ZWiki:WikiPaths
- StrikiWiki:PageTrail an implementation of this idea
Contributeurs : EricScheid, SunirShah, AlexSchroeder - traduction en cours : ChristopheDucamp
PageTranslation LangueFrançaise PathsInHypermedia DossierTechnologieWiki DossierTechnologieWikiNoncommune DossierTechnologieWikiNonimplémentée DossierLien DossierNavigation