La recherche par tag, complément indissociable de la recherche sur le contenu
En marge de ma présentation des Microformats samedi au BarCamp Paris, j’exposais les raisons qui me faisaient voir la recherche par tag comme un complément indissociable de la recherche sur le contenu.
Les tags
Les tags sont parmi les plus répandus parmi la grande famille des Microformats. Un tag est un lien hypertexte contenant un mot clé servant à donner un sens sémantique à un contenu quel qu’il soit : texte, image, vidéo…
Les tags se présentent sous la forme suivante :
<a href="http://t37.net/tags/toto" rel="tag">toto</a>
Le lien contenu dans le tag peut pointer soit vers une source faisant autorité dans le domaine indiqué dans le mot clé – ici toto – soit vers une page interne du site regroupant l’ensemble des media auquel se trouve associé ce tag, soit vers un moteur de recherche de tags, comme Technorati ou Necctar afin de lister l’ensemble des sites ayant publié un media utilisant le tag correspondant.
Un tag n’est pas
– Une catégorie, même s’il s’y apparente. Une catégorie implique une relation hiérarchique du contenu à un ensemble plus grand. Le tag pointe vers un concept auquel se rapporte un contenu donné de manière significative.
– Un meta tag.
Il existe deux différences fondamentales entre les meta tags utilisés dans les années 90 et le microformat rel-tag :
- Là où les meta tags étaient des données contenues dans l’en-tête de la page et s’appliquaient à la page entière, les tags s’appliquent à n’importe quel contenu, et il est possible d’en placer autant que souhaité n’importe où dans une même page (dans des endroits significatifs).
- Les meta tags étaient des données invisibles contenues dans l’en-tête des. Le microformat rel-tag doit obligatoirement apparaître sur la page.
À noter que techcrunch ne respecte pas cette norme en appliquant undisplay: none;à ses tags sur la page principale.
Notre manière d’envisager le Web a profondément changé
En douze ans, notre manière de concevoir le web a profondément changé. Nous avons tenté d’appliquer un modèle connu – la forme imprimée, avec ses hiérarchies, ses codes et ses limites – à quelque chose de totalement nouveau, inconnu et pas forcément adapté au premier – le web, avec la notion d’hypertexte qui vient bouleverser ce que nous connaissions jusqu’alors. Le résultat : beaucoup d’erreurs et de tâtonnements pour faire de http quelque chose pour lequel il n’était pas vraiment fait.
Notre manière d’envisager le web passa ainsi par trois phases :
Le modèle de référence a d’abord été le site ; souvent mono thématique, contenant peu de pages, et d’une interactivité rien de moins que limitée – PHP n’existait pas et il fallait coder ses CGI en C – le concept d’hypertexte y était tout sauf exploité. La principale préoccupation des happy fews ayant pignon sur web était d’afficher leur présence.
Aux alentours de 1997, la première bulle Internet change radicalement la donne. Le modèle de référence pour envisager le contenu se fait plus précis, et se recentre du site vers la page. On doit cette mutation à l’apparition des “portails” : des pages uniques sensées permettre un accès à l’ensemble de la connaissance humaine (j’exagère à peine). L’important : parler – souvent mal et de manière incomplète sur un fond de présentation aussi claire qu’un tunnel de métro un jour de grève des électriciens – de tout ce qui concerne peu ou prou les activités de l’entreprise.
L’obligation de présence sur le Web se double alors d’une obligation d’omniscience et d’exhaustivité, et les pages “en construction” sont légion sur les sites en production.
Depuis 2001, les choses évoluent doucement dans le bon sens, même s’il reste encore énormément de progrès à faire. Le modèle de référence passe de la page au contenu en lui-même : article, photo, vidéo, le support compte moins que le message qu’il tente de faire passer. Le Web devient “social”, et la pertinence d’un contenu n’est plus seulement fonction de celui qui l’a publié, mais aussi du retour des utilisateurs, même si une certaine idolâtrie en faveur de certaines entreprises ou de certains groupements biaise parfois le jugement de certains (W3C, Micrsoft, Google…) De nombreux sites fonctionnant sur les modèles sociaux – les amis de mes amis sont mes amis – (Orkut, MySpace, Digg) ou communautaires (Wikipedia, wikis en géneral) éclosent un peu partout et connaissent un succès phénomenal.
La quantité croissante de contenu disponible et l’émiettement de celui-ci entre des sources souvent inexactes et dissonantes, voire discordantes, chaque jour un peu plus nombreuses entraînent un problème de rapport signal / bruit particulièrement disproportionné. Pour rappel, le rapport signal / bruit est le différentiel entre la quantité et la disponibilité d’informations pertinentes et les informations parasites sur un sujet donné. La vitesse et la densité de propagation des informations parasites sont fonction de l’importance sociale de l’émetteur et d’un facteur de diffusion de la nouveauté – surtout si elle est sensationnelle – particulièrement important sur Internet.
Peu à peu, la nécessité d’un Web sémantique se fait jour dans les esprits, et les tout premiers Microformats apparaissent dans le courant de l’année 2005 : XFN (XML Friends Network, successeur du défunt FOAF, Friend Of A Friend) qui permet de faire une cartographie sociale des liens hypertextes, rel-nofollow comme une parade le spam sur le système de ranking de Google, avec le désastre final que l’on sait, et surtout rel-tag qui permet de qualifier très précisément ce à qui se rapporte un contenu.
Quelques limites de la recherche sur le contenu
Il existe de nombreuses limites à la recherche sur le contenu telle qu’elles est pratiquée aujourd’hui par les acteurs du marché, nous évoquerons les deux principales :
la recherche sur le contenu peut manquer de pertinence.
Un article sur un sujet donné publié par un site Internet au “pagerank” élevé risque de passer devant un article publié par un site faisant vraiment autorité dans le domaine, mais moins bien classé par les moteurs de recherche. Il est ainsi – à titre d’exemple – anormal qu’un site obtienne les seconds et sixième rangs sur Google pour les recherches sur “grosse bite” et “belle bite” avec des photos de… bittes d’amarrage à la légende plus que douteuse (et une belle faute de français que je n’avais pas remarquée en légendant les photos au passage).
La recherche sur le contenu ne prend pas le sens en compte.
Le fait que que j’effectue une recherche sur “vache” implique soit que je cherche des contenus sur les vaches, soit que je cherche des contenus contenant le mot vache. Certes, dans ce cas précis, j’ai peu de chances de me tromper, mais la richesse d’une langue est telle que je ne peux être certain de tomber juste à 100%. Si cela se trouve, l’article le plus pertinent concernant les vaches ne contient pas une seule fois ce mot précis.
La recherche sur le contenu n’est pas polyglotte.
On rejoint là la limitation sur la prise en compte du sens : prendre en compte la traduction mot à mot de la requête de recherche n’implique pas une prise en compte du sens réel de l’expression dans la langue de destination. La recherche sur le contenu ne peut donc retourner des résultats dans des langues différentes sans un énorme risque d’erreur, d’autant plus que le langage employé sur le Web se rapproche plus du langage parlé que de la langue écrite. À titre d’exemple, “avoir un Polichinelle dans le tiroir” signifie “être enceinte” en français, tandis que “to have a puppet in the drawer” signifie simplement “avoir un polichinelle dans le tiroir”.
Les apports de la recherche par tags
La recherche par tags permet de pallier au problème du sens.
Si le sens d’un contenu (texte, image, vidéo) est compréhensible par un être humain, il ne l’est pas par une machine. Le fossé se creuse encore plus quand il s’agit de paraboles, d’allégories ou de métaphores. Les thématiques générales de l’article sont contenues dans les tags bien plus que dans le contenu. À titre d’exemple, un article sur le cancer du pis chez la noiraude afghane peut ne pas utiliser une seule fois le mot “vache”. Pourtant, il paraîtrait normal de le marquer avec le tag “vache”.
La recherche par tags apporte un surcroît non négligeable de précision.
À ce jours, mon blog personnel contient un peu plus de 1500 billets regroupés dans seulement une quinzaine de catégories. On se heurte à un double problème : soit je reste dans cette configuration, et les catégories perdent en pertinence et précision, soit je rajoute un nombre conséquent de catégories et celles-ci perdent toute leur signification.
La recherche par tags permet d’utiliser au maximum le concept d’hypertexte.
Le tag renvoie soit vers un moteur de recherches de tags, qui renverra l’utilisateur vers une liste d’articles contenant le même tag, soit vers une page interne répertoriant la liste des média contenant le même tag, et éventuellement une liste de tags liés, soit vers un site faisant référence dans le domaine du tag. Il est ainsi possible de naviguer simplement au fil d’informations pertinentes ou dérivées.
Les limites de la recherche par tags
J’ai beau être un fervent apôtre de la recherche par tags et d’une mauvaise foi légendaire, je ne peux pas ne pas lui reconnaître des limites évidentes (à la recherche par tags, pas à ma mauvaise foi).
La recherche par tags implique que les utilisateurs soient intelligents.
La recherche par tags implique que tous les contenus soient taggés, et ce de manière intelligente. Elle implique notamment une honnêteté sans faille de la part de l’auteur du contenu qui ne devra y apposer que des tags correspondant véritablement à sa publication. Autant dire que je n’y crois pas, même dans mes rêves les plus fous.
Les tags ne sont pas généralisés.
Relativement nouveau, le système de tags est relativement peu répandu dans les contenus publiés aujourd’hui sur le Web, et totalement absent de ceux publiés durant les 12 dernières années. Au point que le moteur de recherche Technorati considère les catégories des blogs comme des tags afin de gonfler artificiellement la quantité d’informations disponible. Il s’agit d’ailleurs d’une utilisation abusive et erronée du rel-tag : la catégorie est un élément englobant le média concerné et ses pairs de manière peu précise avec une approche hiérarchique tandis que le tag renvoie vers des contenus sémantiquement semblables avec une approche hypertexte.
La recherche par tags est nécessaire mais pas suffisante.
La réussite d’une recherche par tags implique que l’utilisateur saisisse le bon tag dans le formulaire de recherche, et qu’il veuille effectivement faire une recherche sur ce tag. En un mot, elle nécessite que le moteur de recherche comprenne les objectifs de l’utilisateur au moment de sa recherche. L’utilisation d’un nuage de tags liés (tags similaires au tag recherché, soit parce que le plus souvent associés à celui-ci dans des billets connexes soit parce que contenus dans les billets sur lesquels pointent le lien du tag) ne peut apporter une précision de 100% quand à l’utilisation de synonymes. C’est tout le problème du Perl : There is more than one way to do it (ceci est un troll assumé).
Le (X)HTML n’est pas sémantique par nature.
De par sa raison d’être, le (X)HTML ne devrait s’occuper que de l’affichage d’un contenu sans prendre en compte le rendu d’aucune manière que ce soit. Pareillement, le (X)HTML est totalement ignorant du sens du contenu qu’il doit afficher. Deux “écoles” de pensée s’opposent à ce sujet : celle qui pense que le (X)HTML ne peut et ne doit pas être sémantique, et les ayatollahs d’un Web sémantique (dont je fais partie) qui pensent qu’il faut reprendre le Web aux machines pour le restituer à l’être humain, quitte à dénaturer un peu le balisage puisque celui-ci a la gentillesse de nous en offrir les moyens (“rel=”, “ref=” et “class=”) sans entraîner d’incompatibilité avec l’existent.
Les tags n’empêchent pas la triche au “pagerank”.
Tant que la pertinence et l’importance d’un site seront – entre autres – fonction du nombre de liens entrants, la triche au “pagerank” continuera. Il devient aujourd’hui nécessaire d’élaborer un autre système de calcul du “pagerank” en prenant en compte les données sémantiques contenues dans les tags, sans pour autant abandonner les autres critères actuellement utilisés. Il en résultera un besoin plus important de ressources, mais au prix d’un rapport signal / bruit moindre, et donc d’une pertinence améliorée.
Commentaires
Trackbacks
Les trackbacks sont fermés pour cause de spam.
-
Comme annoncé un peu plus tôt, je serai bien au quatrième BarCamp Paris qui se tiendra samedi 16 septembre à partir de 14 heures dans les locaux de Mandriva au 43 rue d’Aboukir, dans le deuxième arrondissement de Paris. J’y parler...
Passionné d'informatique depuis l'âge de six ans, je travaille en tant que responsable qualité chez blueKiwi Software, éditeur spécialiste des outils collaboratifs en entreprise. Ma double formation en sciences politiques et en informatique me permet de porter un regard particulier sur les problématiques abordées par mon poste.
TiBlond about 11 hours later:
Ha un nouveau template :)
Damien B about 16 hours later:
“Le (X)HTML n’est pas sémantique par nature.”
Ca demande à être précisé, parce que là on sombre dans la désinformation (ce qui n’est pas anormal pour un article sur les microformats, mais je m’égare). Le HTML a toujours eu une sémantique, peut-être mal précisée, mal encadrée, de faible portée, mais elle était présente. Ne voir dans le HTML qu’un rôle de présentation c’est quand même nier l’existence de 3/4 des balises. La sémantique du HTML commence dès sa deuxième balise : head. Donc, soit tu es un peu plus clair sur cette absence de sémantique intrinsèque à (X)HTML, au besoin en redéfinissant “sémantique” (“ensemble des aspects du système logique relatifs aux notions de satisfaction et de vérité” me dit le TLFi), soit je rajoute cet article dans mon cimetière personnel des arbres virtuels sacrifiés sur l’autel des microformats.
Dernier point, ce n’est pas parce qu’un clan a enterré FOAF que FOAF est mort !
grima about 17 hours later:
Beaucoup moins pompeux, mais beaucoup plus clair.
Et il me semble évident que le XHTML ne se rapporte pas au sens du contenu. Evidemment le XHTML posséde une sémantique propre, mais elle n’est d’aucun rapport avec celle du contenu du document.
Damien B about 22 hours later:
”> sémantique (adjectif) Qui a rapport à la signification, au sens”
Oui, quand on se place dans un contexte linguistique, ce qui n’est pas le cas.
Le HTML, qui est quand même on le rappelle une grammaire SGML, est structurant, et en ce sens, elle a un rapport avec le contenu du document, qui est structuré (quand ça n’est pas dévoyé), selon cette grammaire. Evidemment, on peut tout à fait trouver que cette structuration n’est pas adaptée à ce qu’on veut faire du web, mais cela n’est pas pour ça que l’aspect sémantique est absent. Quand tu fais un DL/DT/DD, tes DD satisfont à une relation de description vis-à-vis du DT qui précède : si on nie cet aspect là, effectivement on ne peut que se retrouver dans un camp d’ayatollahs.
Frederic de Villamil 1 day later:
Damien : tu le dis toi même, le HTML est structurant, et non signifiant.
Il donne des indications précieuses sur la manière dont un document Web est agencé, et même sur le type de documents liés, mais je ne crois pas qu’il soit porteur de sens. Même si on peut dire qu’une succession de balises HTML a du sens (je ne vais pas mettre une liste à puces sans déclarer une liste ordonnée ou non avant), je ne pense pas qu’on puisse dire qu’elle soit porteuse de sens.
(Il est tôt, je suis mort, alors si ce n’est pas clair, dites le moi, je détaillerai. Mais après un bon café.)
JS 2 days later:
Certaines balises ont quand même du sens et en donnent au document : head , body, title, h1, etc…
Non seulement elles structurent le document mais donne un sens qui pour les 3 premières par exemple est écris en toute lettre dans le nom de la balise.
Après oui, si on utilise que des span et div ça a beaucoup moins de sens…
JS 2 days later:
Bon, et la prochaine fois je formate mon commentaire avec du html…
<a href="http://xtof.viabloga.com rel="nofollow">Christophe Ducamp</a> 2 days later:
Bonjour Frédéric, nous nous sommes croisés rapidement au BarCampParis et même si je n’ai pu assister à ta présentation et ne suis pas non plus programmeur, je me suis laissé convaincre des microformats par Chris Messina. J’aimerais bien à l’occasion pouvoir reparler avec toi et savoir comment aider pour reprendre les travaux de localisation que tu as amorcé sur le wiki. J’ai commencé quelques brouillons sur le CraoWiki ici mais aurai besoin de correcteurs. A titre personnel, j’aimerais tout particulièrement explorer les “formats-wiki”. Pour finir, as-tu laissé une trace de ta présentation quelque part ? Bonne journée.
Damien B 7 days later:
Imaginons que l’on fasse un microformat pour… une liste de définitions. Ce qui dans un contexte XML pur serait tout à fait normal. Dans ce cas-là tu me dirais que le microformat est signifiant, mais que DL/DT/DD ne l’est pas ?
Raphael 8 days later:
Effectivement, h1, head, body sont structurant, mais très peu porteurs de sens. Quid de img ou embed ?
Ce qui est frappant avec cette notion de microformats, c’est qu’elle ouvre conceptuellement pas mal de possibilités.
Le problème actuel lié par exemple à l’utilisation du flash pour lire de la vidéo, c’est qu’il y a aucun moyen pour détecter le but final du swf servant de tête de lecture. Comme on ne peut pas charger un flv (le format du flash video) sans être appelé via un swf (déclaré via les balises embed et param), il y a clairement une rupture de déclaration et d’attribution, ce qui est moins problématique avec les images (balise img claire et formats statiques - jpg/png/gif). De plus, Google permet un tri par taille et donc une séparation claire des images utilisées pour l’interface du site (microformat possible: type=interface) des images illustratives (microformat possible:type=document). Ce qu’il faudrait pouvoir ajouter avant un embed, c’est simplement une balise déclarant
Je ne sais pas si c’est possible en l’occurence, mais j’imagine que cela a déjà été imaginé par le W3C ou autre groupe de travail. De toute façon, cela concerne effectivement essentiellement les bigs players comme yahoo ou google qui, de part leurs sites Richmedia (Flickr, Googlemaps, Yahoo Video, Google Video), peuvent faire évoluer le marché et pousser les agences et développeurs à modifier leurs méthodes de déclaration et “sémantisation”.
Raphael 8 days later:
ooups, désolé, j’ai utilisé des balises d’exemples qui existent et le commentaire a donc tronqué mon exemple.
“…Ce qu’il faudrait pouvoir ajouter avant un embed, c’est simplement une balise déclarant < content rel=video > < / content > . Je ne sais pas si c’est possible…”
Frederic de Villamil 8 days later:
Raphael : l’exemple que tu donnes là me semble parfaitement correspondre à ce pourquoi les tags ont été créés en fait.
Ce qui nous intéresse n’est pas la nature du .swf (vidéo, jeu), mais plutôt le contenu diffusé (et dans ce cas vidéo et jeu correspondent en tant que tag). Tout comme le cas de l’image en tant que partie du site : ce qui importe n’est pas tant sa place dans le site mais ce qu’elle représente : lieu, occasion… donc un tag.
Trop de trucs dans le html tue le html ©
Raphael 8 days later:
J’ai écrit un billet complémentaire à ton billet, Frédéric.
Comprendre les tags
Cette approche temps-réel, si chère aux médias classiques, est essentielle pour tous. Technorati ne fait hélas pas le poids actuellement pour répondre comme il se doit à toutes les possibilités ouvertes, tout comme l’utilisation de meta-données est également sujette à une certaine réserve. Que fait Google pour les tags ? Rien actuellement et c’est bien dommage. Ce serait pourtant la plus légitime plateforme pour permettre des recherches via tag sur:
Là où Google ferait fort, c’est qu’il pourrait mettre l’intelligence de son moteur pour offrir une vue des tags existants d’un site donnée (site-related) et pourquoi pas, permettre un tagging externe (meta de nouveau) des différents objets via une interface Google, tout comme ils ont créé un outil pour indexer les pages (sitemapping via un xml statique ou dynamique).
En attendant que Google offre l’impossible, certains sites comme Newsvine ont pris les devants et poussent la recherche de contenu de leurs sites via tags, sans aucun lien avec Technorati.
Nous avons eu l’occasion d’effectuer une étude pour l’école des Beaux-Arts à Genève. Voici comment une école pourrait offrir une vision plus transversale et versatile de l’ensemble des ses composants. Il va de soit que ceci s’applique également à une école moins visuelle.
Raphael 8 days later:
C’est vrai. Mais je remarque deux choses: les tags “en dur” et les tags dynamiques.
En dur: Ceux qui sont inclus dans une page html et qui sont cachés pour l’utilisateur. Un fichier Flash est dans la plupart des cas inséré manuellement via dreamweaver. Sur cette même page, qui est généralement tout en Flash, on se trouve à des kilomètres de champs de saisie pour du tagging. Macromedia-Adobe a fait un petit progrès en donnant accès à deux champs de saisie pour indiquer le titre et une description de l’objet. A ma connaissance, ces données sont embeddées à l’objet et non-visibles dans le html ce qui est regrettable. Donc c’est à Adobe de faire l’effort d’intégrer dans cette phase de création html “automatisable” des tags cachés et pourquoi pas, des tags visibles. Adobe, possédant un format de plus en plus important pour la distribution des vidéos (youtube, google video, myspace), ils auraient certainement tout à gagner à pousser le tagging vers une plateforme propriétaire, avec un ping similaire à technorati, mais orienté richmedia, non articles.
En dynamique: Ce qui est dangereux, c’est que ces tags sont liés à des bases de données, non à l’objet lui-même (sauf blogger qui génère des pages statiques). Par contre, à l’inverse, cela permet d’ouvrir des possibilités à un point tel que nous n’en avons pas encore connaissance. Le futur est devant nous et il est brillant, complexe, mais brillant.
Pour résumé, nous avons quatre niveaux de tags:
Il reste maintenant plus qu’à créer des tags liés aux champs d’exploitation de l’objet www, broadcast, radio, print ou mobile ou réel.
Yehaa.
Raphael 8 days later:
Pour info, ton site est apparemment pas compatible cocomment.com.
molhokwai about 1 year later:
hummm… Le débat sur l’XHTML ou une autre technologie pour les implémenter est purement technique… Et le “pagerank” tel qu’il est n’aurait pas vraiment de sens dans un web sémantique…
Et si un système de normalisation des tags se crée, se met en place et est adopté par la communauté, les tags deviendraient la clé de voûte, au sens le plus pur du terme, du web sémantique et social… Pas encore communautaire…
Donc, entièrement d’accord sur le fait que les limites de la recherche par tag soient essentiellement humaines, puisqu’il ne tient qu’à nous d’harmoniser l’outil…