Web sémantique

Yahoo apporte des bananes au Web sémantique, 1ère partie

got — Mon, 26 May 2008 22:57:32 +0200

Annoncé, il y un peu plus de 2 mois, « l’écosystème de développement pour la recherche » de Yahoo est maintenant disponible sous le nom de SearchMonkey. Si, avec cette initiative, le but de Yahoo était de reprendre la main sur Google dans le domaine strict de la recherche, il me semble qu’une partie du chemin a été effectuée. Plutôt, que d’attaquer frontalement Google en mettant en œuvre de nouveaux algorithmes de recherche, par exemple, Yahoo a choisi un angle différent jusqu’alors complètement inexploité et, pourtant, oh ! combien important, à savoir la présentation des résultats.

Et, dans ce cadre, aiguillé certainement par le succès de facebook et de sa plate-forme de développement ouvert, le moteur de recherche a mis à disposition des développeurs une plate-forme pour mettre au point des applications qui agrémentent, selon la volonté des utilisateurs, les résultats de la recherche. Pour ce faire, il rend disponible les données de son index, soit les données structurées avec des microformats, RDFa et eRDF (embeded RDF, un système à peu près équivalent à RDFa) et déjà indexées, par défaut, par Yahoo, soit directement l’ensemble des données de la page Web à partir desquelles le développeur peut créer une extraction personnelle.

La plate-forme SearchMonkey comprend donc trois parties (et donc trois billets pour le présenter…) :

Une à destination des utilisateurs ;
Une à destination des développeurs ;
Une à destination des propriétaires de sites.

La partie « Utilisateurs »

Si vous possédez un compte Yahoo!, vous pouvez d’ors et déjà, après connexion, choisir et installer des résultats personnalisés à partir de la « search Gallery » mis à la disposition des utilisateurs par Yahoo.

Page d’accueil de la « Yahoo! Search Gallery »

Page de l'application Linkedin

Une fois que vous avez choisi les personnalisations que vous souhaitez utiliser, vous pouvez lancer une recherche. Si un des résultats correspond à une des pages prise en charge par une des applications, vous verrez apparaître le résultat personnalisé.

Résultat personnalisé avec Linkedin

Résultat personnalisé pour LastFM

Résultat personnalisé pour Feedbooks

En utilisant la structuration des données d'une page Web, Yahoo! ouvre avec SearchMonkey la possibilité aux utilisateurs d'être mieux renseigné sur la page donnée en résultat. Or, sans même y faire attention, nous accordons de l'importance à l'extrait mis à disposition par le moteur de recherche, avant de cliquer sur le lien. Ainsi, sans même toucher à son algorithme et, en ouvrant un peu sa plate-forme de recherche aux développeurs de tous les horizons, Yahoo améliore les résultats de la recherche. Et, grâce à quoi, je vous le donne en mille : la structuration des données avec des formats issues ou apparentées aux technologies du Web sémantique.

Dans le prochain billet, nous rentrerons dans les arcanes de la plate-forme et étudierons comment créer une nouvelle application. Pour cela, je prendrais appui sur les données encodées en RDFa sur ce blog et quelques autres. Restez branchés, nous sommes en train de vivre une période formidable !

RDFaiser votre blog, 3ème partie : l’exploitation

got — Sat, 24 May 2008 22:01:31 +0200

Si HTML permet de structurer une page Web dans une visée documentaire, RDFa permet d’en structurer, de manière indépendante, les données. Au final, RDFa ajoute donc une troisième couche aux deux existantes :

HTML pour structurer la page Web ;
CSS pour structurer la mise en forme de la page Web ;
RDFa pour structurer les données de la page Web.

Il est difficile de prévoir aujourd’hui tous les usages possibles de RDFa ; ils restent encore largement à inventer. En effet, et c’est le propre et l’intérêt des technologies du Web sémantique, la modélisation des données en RDF est indépendante des usages qui en sont faits. Malgré tout, il est d’ors et déjà possible d’identifier quelques usages.

Exploitation des données en RDFa par les moteurs de recherche

Le premier d’entre eux a fait couler beaucoup d’encres électroniques ces derniers temps. Yahoo a annoncé le support de certaines technologies du Web sémantique, dont RDFa. Dans ce cadre, les données en RDFa indexées par le moteur de recherche vont améliorer les interfaces de réponse, en renseignant mieux l’internaute. J’espère pouvoir revenir sur les possibilités ouvertes par ce support intégré à la toute nouvelle plate-forme Yahoo SearchMonkey.

De même, on peut imaginer que Yahoo se servira de la structuration des données pour améliorer la pertinence des résultats, en associant des poids différents en fonction de la propriété RDF utilisée et en exploitant le typage des liens rendu possible par RDFa.

Ajouter des fonctionnalités au navigateur

A l’image des expériences menées avec les microformats, les données en RDFa peuvent être exploitées pour ajouter des fonctionnalités aux navigateurs. Ainsi, l’extension pour Firefox, Operator, créé à la base pour les microformats, propose un support de RDFa. Il est ainsi possible de créer des scripts déclenchant des actions en exploitant les données en RDFa contenues dans la page Web. Si cela vous intéresse, j’avais mis au point quelques exemples très simples avec la précédente version.

Dans la même veine qu’Operator, il me semble tout à fait possible d’exploiter les données en RDFa avec un script Greasemonkey. A ma connaissance, il n’existe pas d’exemples, mais il serait par exemple assez simple d’adapter ce script permettant d’afficher la licence « Creative commons » de la page Web qui serait exprimé en RDFa. Il existe une multitude de possibilités et je suis sûr que votre imagination et votre science de la programmation en javascript (bien meilleure que la mienne ;-) ) pourront faire des merveilles. Les possibilités du couple Greasemonkey-RDFa relèvent, d’ailleurs, tout autant de l’usage suivant.

Agrémenter et améliorer l’expérience de navigation des internautes

En effet, dans le même ordre d’idée, plutôt que d’ajouter des fonctionnalités aux navigateurs en lui-même, il est possible d’agrémenter la navigation dans la page avec des comportements dans la page Web et/ou en proposant des informations complémentaires à partir de l’exploitation des données en RDFa.

Fuzzbot, par exemple, est une extension Firefox qui exploitent les informations en RDFa et les affichent de manière formatée à l’utilisateur. Par exemple, il est possible aujourd’hui d’afficher la photo d’une personne renseignée avec la propriété foaf:depiction.

Cela ressemble un peu à l’exemple de l’affichage de l’avatar d’un commentateur que j’avais mis au point pour ce blog et on pourrait par exemple envisager dans le cadre d’une page contenant des données en SIOC afficher les URL vers les autres commentaires effectuées par le même utilisateur sur le même blog voire sur un autre blog en interrogeant Sindice.

Enfin, à l’image du système des SmartLinks mis au point par AdaptiveBlue, il est aussi possible d’afficher des informations complémentaires d’un livre référencé par Dbpedia ou d’une chanson, d’un album ou d’un artiste référencé dans la base de Music Brainz en RDF mis au point par Yves Raymond. Dans ce cas, plutôt que d’ajouter des attributs spécifiques à Adaptive Blue qui ne sont absolument pas standards (<a bluelink="yes" bluekey="" asin="" href=""></a>, no comment !), vous ajouterez des données en RDFa qui pourront non seulement être utilisées par ce système, mais pourront être exploitées par d’autres systèmes (Ah ! la force d’une syntaxe normalisée…). Cela vous rappellera peut-être le principe de la knowledge box que j’avais mis au point, il y a quelques temps.

Améliorer l’interopérabilité et l’échange de données entre les sites Web

Les possibilités d’interopérabilité ouvertes par RDFa en constituent, à mon avis, son usage le plus prometteur. En effet, dans la mesure où RDFa offre la possibilité de structurer les données de manière indépendante de la structure en HTML de la page Web, il est alors possible de récupérer automatiquement les données d’une page Web pour les republier, les exploiter, les indexer à votre guise…

Ainsi, il serait bienvenu de revoir le principe des trackbacks en exploitant les données en RDFa, plutôt qu’un bout de RDF/XML placé en commentaire dans le code HTML. Cela éviterait certainement le spam monstrueux qui a peu à peu détruit cette fonctionnalité.

Laissez libre cours à votre imagination, je suis sûr que les usages vont apparaître peu à peu.

Smob : le Twitter version Web sémantique

got — Sat, 24 May 2008 21:06:31 +0200

Tukka Hastrup, Uldis Bojars, John Breslin et l’inévitable Alexandre Passant ont mis au point Smob, un système de micoblogging décentralisé basé sur les technologies du Web sémantique, en particulier SIOC, choix logique quand on sait que les quatre développeurs en sont des contributeurs actifs. Cette application démontre parfaitement en quoi les technologies du Web sémantique vont offrir aux utilisateurs (pour ne pas dire « utilisacteurs ») un meilleur contrôle de leurs données dans le cadre de l’écosystème mis en place par le Web 2.0.

Le principe

Smob comprend deux parties :

Le smob client permet d’éditer des « micro-billets », de les stocker dans un fichier en RDF/XML, de les afficher sur une page Web enrichie en RDFa et de choisir sur quel(s) serveur(s), dont Twitter, vous voulez éventuellement publier votre « micro-billet ». Si vous voulez vous faire une idée, le projet SIOC met à disposition un smob client anonyme.
Le smob server reçoit des micro-billets, les indexe dans un triple store RDF, offre une interface à facettes basée sur Exhibit pour les visualiser, et un sparql endpoint, soit une API standard et universelle, pour les interroger. Vous pouvez consulter le serveur de démonstration.

Par ailleurs, le smob server reconnaît automatiquement la syntaxe des Hashtags en tant que tags du « micro-billet ». Les hashtags peuvent être préfixés avec des comportements associés :

En préfixant avec « geo: » suivi d’un nom de lieu, l’interface place automatiquement le « micro-billet » sur une carte Google Maps, en utilisant le service Geonames.
En préfixant avec « dbp: » suivi d’une page de Dbpedia, l’interface crée automatiquement un lien vers la page ad hoc sur Dbpedia.

Intérêts de Smob

Smob présente de multiples avantages.

Pour l’utilisateur du Smob client, il peut ainsi archiver ses différents micro-billets dans une syntaxe pérenne, à savoir XML et encodés selon un modèle d’information standard RDF et avec un vocabulaire RDF reconnu, SIOC. L’utilisateur peut choisir sur quel serveur, y compris Twitter, il veut publier son micro-billet voire de ne le conserver qu’en local. Ainsi, il pourra varier le serveur en fonction du sujet de son micro-billet. L’utilisateur garde donc l’entière maîtrise de ses données prêtes à la portabilité. Cerise sur le gâteau, Smob exploite automatiquement votre profil FOAF et l’enrichit.

Quant au smob server, il risque de faire évoluer les usages du micro-blogging. En effet, dans la mesure où il permet une décentralisation de la publication des « micro-billets », il est, par exemple, envisageable d’installer un Smob server pour une communauté précise, c’est d’ailleurs l’idée du serveur Smob de Websemantique.org ou du sioc-project, pour ses besoins personnels, mais aussi pour un organisme quelconque, une entreprise ou institution.

Dans ce cadre, non seulement les utilisateurs pourront continuer d’utiliser leur compte Twitter, s’ils en disposent d’un, mais aussi envoyer et recevoir des micro-billets internes à l’organisme. Ainsi, cette dernière garde la maîtrise des données éditées en son sein et trouve dans ce système un nouveau canal de diffusion plus simple et plus rapide que la messagerie électronique pour certaines informations. Enfin, last but not least, l’intégration des données du/des smob server dans le SI legacy et/ou l’intranet est simplifié par SPARQL, langage de requêtes et interfaces de Web services standard.

Installer et utiliser Smob

Pour le moment, il n’existe pas de plate-forme qui proposerait des smob clients par défaut. Il faut donc disposer d’un peu d’espace (c’est très léger) sur un serveur Web sur lequel PHP 4 ou 5 est installé. Vous téléchargez ensuite le smob client (pour le moment sur le dépôt SVN, mais la première release ne devrait pas tarder). Il vous faudra aussi télécharger ARC 2 et le copier dans le répertoire ‘lib’. Il ne vous reste plus qu’à personnaliser le fichier config.php en indiquant :

L’adresse des serveurs Smob sur lesquels vous voulez éventuellement poster vos micro-billets, des exemples sont indiqués ;
l’URL de votre profil FOAF ;
l’URI qui vous représente dans votre profil FOAF, par exemple, pour moi, cette URI est <http://www.lespetitescases.net/foaf_got.rdf#GP>;
le surnom ou le nom que vous utilisez pour micro-bloguer ;
le login et mot de passe de votre compte Twitter, si vous en disposez d’un et que vous voulez y publier vos micro-billets.

Vous chargez tous les fichiers sur un serveur et le tour est joué, vous pouvez utiliser le Smob client.

Ce n’est pas beaucoup plus compliqué pour un smob server, si ce n’est que vous devrez disposer d’une base de données MySQL. Ensuite, le principe est le même : téléchargement du smob server et de ARC 2, personnalisation du fichier config.php :

La configuration de votre base de données ;
Une API key pour utiliser Google maps ;
Une API key que les utilisateurs devront indiquer dans leur fichier de configuration s’ils veulent publier sur ce smob server.

Vous chargez et c’est terminé, vous disposez d’un smob server sur lequel vous et d’autres utilisateurs, disposant, le cas échéant, de votre API key, pouvez publier vos micro-billets sur ce serveur.

Exploiter les données de Smob

Il est ensuite très simple de récupérer et d’exploiter les données issues de Smob. Smob client expose les données en RDFa sur la page d’accueil et le smob server offre un sparql endpoint permettant de le requêter et d’afficher les données sur un autre site, comme n’importe quel Web service en REST.

A titre d’exemple, j’ai mis au point un module pour drupal 5 qui permet d’afficher dans un bloc le dernier micro-billet publié sur un serveur Smob que vous paramétrez. Vous en verrez un exemple sur la barre de droite sur ce blog (rubrique "Dernier micro-billet"). CQFD : ce module est la preuve de la portabilité des données permises par les technologies du Web sémantique dans l’écosystème du Web 2.0.

En savoir plus

Quelques billets et articles sur Smob :

Le site officiel de Smob et sur Google code ;
SIOC based microblogging, par Alexandre Passant ;
Prototype for distributed / decentralised microblogging using semantics, par John Breslin ;
Microblogging : a semantic and distribued approach, par Tukka Hastrup, Uldis Bojars, John Breslin et Alexandre Passant ;
Weaving SIOC into the Web of Linked Data, communication de Richard Cyganiak, Uldis Bojars, John Breslin et Alexandre Passant présentée à LDOW 2008.

A la découverte du Web sémantique et de ses technologies

got — Sat, 03 May 2008 17:22:52 +0200

Pour vous faire patienter avant que ce blog ne reprenne un rythme normal de publication (d'ici un mois ou deux...), je vous propose une présentation du Web sémantique et de ses technologies sous la forme d'un diaporama. Il a été mis au point pour présenter le sujet à mes nouveaux collègues. J'espère qu'il pourra vous aider à mieux comprendre les buts poursuivis par le Web sémantique et ses technologies.

Bonne lecture et à bientôt !

| View | Upload your own

Du Web sémantique au web de données, 2ème partie : retour sur un des articles de Roger T. Pédauque

got — Tue, 04 Mar 2008 02:13:18 +0100

Dans un billet récent écrit à l'occasion des dix ans de XML, Jean-Michel Salaün regrettait que les pistes esquissés dans le second texte de l'initiative Roger T. Pédauque intitulé « Le texte en jeu. Permanences et transformations du document » n'aient pas été suivies. Et, pour cause me semble-t-il, si ce deuxième article, comme les deux autres d'ailleurs, apporte incontestablement des pistes de réflexion et certaines idées intéressantes, il comprend des contre-sens et des erreurs si manifestes qu'il n'est possible de s'en servir comme base de travail qu'après une critique attentive, sans compter sur le style que Jean-Michel Salaün lui-même dans le billet cité plus haut qualifie « d'un peu abscons » et que je qualifierais plus volontiers de charabia jargonnant.

A l'heure où le Web sémantique pointe avec plus de prégnance le bout de son nez, il n'est pas inutile de revenir sur ce texte, comme sur les deux autres, pour construire une nouvelle réflexion. C'était d'ailleurs leur but : susciter le débat et la réflexion, sans présager des évolutions futures et selon l'état de l'art du moment. Or, il semble bien qu'une nouvelle étape est sur le point d'être franchie, si ce n'est pas déjà le cas. A titre personnel, si, à l'époque de rédaction du texte, je n'étais pas en mesure de m'immiscer dans le débat, j'espère, aujourd'hui, pouvoir apporter ma pierre à l'édifice.

Avant d'entrer dans le vif du sujet, je voudrais rappeler, pour mémoire, que cette initiative avait été lancée par le réseau thématiques pluridisciplinaires dédié au document, le RTP-DOC d'où le pseudonyme Roger T. Pédauque pour signer les textes collectifs, placé sous le patronage de feu le département STIC du CNRS. L'objectif était de réfléchir selon une approche pluridisciplinaire à la notion de document dans le contexte des changements induits par le numérique.

1- Retour sur la notion de texte et son analyse

Si je souscris totalement à la méthodologie initiale annoncée, à savoir repartir de la notion de texte pour redéfinir le concept de document, il est erroné d'affirmer que cette notion n'a pas été étudiée par les chercheurs, en particulier les linguistes, lorsque les premières DTD ont été créés pour SGML au début des années 1990 en vue d'encoder des textes .

Il existe des références incontournables dans la littérature anglo-saxonne, à commencer par l'article fondamental de Steven DeRose, David Durand, Elli Mylonas et Allen Renear, « What is text, really ? » paru en 1990 dans la revue Journal of Computing in Higher education. Je vous engage à relire cet article, écrit au moment où l'initiative de la TEI n'en est qu'à ses balbutiements, tant il reste encore d'actualité ¹ . Les auteurs démontrent la pertinence du modèle de construction hiérarchique de la structure logique d'un texte qu'ils nomment le modèle OHCO (Ordered hierarchy of content object) et qui constitue la base des langages à balise, de SGML et, donc de XML. A travers différents exemples, ils montrent l'apport de ce modèle pour l'exploitation informatique du texte.

Évidemment, le modèle du codex imprimé est encore très présent dans les idées exposées, mais cet article dont il faut se souvenir de la date de rédaction constitue une base indéfectible et citée encore régulièrement par les spécialistes de l'encodage. Les auteurs ont précisé certaines idées dans un second article : « Refining our Notion of What Text Really Is: The Problem of Overlapping Hierarchies », revenant sur le problème bien connu de l'overlapping, problématique absente, malheureusement, de l'article de Roger.

De même, il n'est pas une présentation, formation, tutoriel sur la TEI, sans retour initial sur la notion de textes. Il suffit pour s'en convaincre de parcourir les documents mis à disposition sur le site du consortium. M'inspirant modestement de ces documents pour ma présentation de la TEI à l'ADBS, il y a quelques semaines, j'avais proposé cette définition à la notion de texte :

« Un texte est la représentation sur un support d’une construction logique de phrases formant une unité. »

Elle n'est évidemment ni complète, ni parfaite, à commencer par l'utilisation de la notion de phrase que je remplacerais par « portions d'information ». En effet, et c'est une seconde erreur de l'article de Roger, les DTD créées pour encoder le texte ne reposent pas sur le concept de phrases, mais sur un concept plus générique de divisions ou blocs d'information, la fameuse balise <div> que l'on retrouve aussi bien dans TEI, docbook que HTML et, à un niveau de granularité plus restreint, au concept de chaînes de caractères référencées (inline element), qui prend la forme de la balise <rs> et dérivés (persName, geoName, hi, emph...) dans la TEI ou <span> en HTML. L'erreur des auteurs de l'article repose, mais peut-être que je me trompe, sur l'idée que ces différentes DTD ont été construites par des linguistes. Si on ne peut nier leur apport, il ne faut pas oublier que la TEI a été créée par des chercheurs issus de toutes les disciplines des sciences humaines, que Docbook a été créé par Norm Walsh qui, aux dernières nouvelles, n'est pas linguiste, et que HTML a été créé par Tim Berners-Lee, qu'on ne présente plus.

Ainsi, si le postulat de départ est bon, l'état de l'art ne semble pas complet ² ce qui entraîne des fausses affirmations et, aussi, peut-être, une mauvaise interprétation du but et du rôle de XML dans l'exploitation informatique des textes ce que viennent, d'ailleurs, confirmer les deux problèmes suivants.

2- La fausse croyance de la prévalence du fond sur la forme

Voilà, un argument maintes fois entendu, l'utilisation de XML étant basé sur la séparation entre la structure logique du texte (désigné par les termes « fond » et « contenu » dans l'article) et sa structure physique (sa mise en forme), l'apport de la forme (mise en page, graphisme, design) à l'appréhension et à la compréhension du texte serait nié par les mécanismes d'encodage. Il existerait une prévalence implicite du fond sur la forme. Il me semble que cet argument est le signe d'une incompréhension des raisons qui ont poussé à cette séparation et d'une méconnaissance du fonctionnement concret de XML.

Repartons, si vous le voulez bien, des buts qui ont vu la mise en place de la TEI, qui constitue la première DTD pour encoder les textes et une source d'inspiration pour les suivantes. Le but initial était de partager une syntaxe et des règles communes de balisage en vue de l'échange des corpus informatisés. Cette idée est d'ailleurs toujours présente dans la TEI, puisque le guidelines a pour titre, Guidelines for Electronic text encoding and Interchange . Dans ce contexte, l'encodage de la structuration logique du texte assurait l'échange du texte dans une version facilement exploitable par des logiciels et des applications. La séparation entre structure logique et structure physique ne relève donc pas d'une quelconque posture épistémologique, mais constitue plutôt un moyen d'assurer l'échange et l'exploitation du texte encodé dans des contextes différents ³ .

Pour autant, structure logique ne signifie pas forcément que les caractéristiques physiques d'un texte ne sont pas encodées. Cela dépend tout simplement du but poursuivi et des besoins de traitement du texte. C'est d'ailleurs la raison pour laquelle j'ai conservé la notion de « support » dans ma définition du texte. La TEI offre précisément les moyens d'encoder toutes les caractéristiques physiques du texte traité, dans la mesure où ils font partie intégrante de son appréhension et méritent, à ce titre, un traitement particulier. Citons, par exemple, le changement de ligne (<lb/>), le changement de page (<pb/>), le changement de mains dans un document manuscrit (<handSchift/>), ou encore les abréviations (<abbr>) pour rester dans le registre de la paléographie.

Par ailleurs, la TEI offre avec l'attribut rend disponible pour tous les éléments la possibilité d'indiquer le rendu/la mise en forme de la portion encodée. L'attribut style joue exactement le même rôle pour HTML. De plus, toujours en HTML, toutes les pages possèdent un lien vers une feuille de style qui exprime la mise en forme de la page grâce au langage CSS, format tout aussi pérenne, ouvert et libre que XML. Ce mécanisme de lien est très clairement exprimé dans les recommandations de HTML. D'ailleurs, la montée en puissance, ces dernières années, du couple HTML-CSS est une preuve que la séparation n'est pas vécue comme un abandon de la forme, mais plutôt comme un moyen de rationaliser le développement de sites Web, d'en assurer un suivi, une maintenance et une évolution simplifiés, tout en économisant de la bande passante.

Enfin, un dernier exemple démontre l'irrecevabilité de cet argument : la mise au point récente et l'utilisation de schémas XML pour décrire les documents issus d'un traitement de texte. Dans ce cas, le fichier XML comprend des informations de mise en forme physique du texte ce qui démontre bien que cette séparation n'est pas à faire sur le contenu lui-même, mais sur la structure logique. Or, dans ce cas, la mise en forme participe de la structure logique du texte, c'est pourquoi la plupart des informations de mise en forme sont présents directement dans le fichier XML.

3- XML et la grammatisation du document

Cette connaissance approximative du rôle et du fonctionnement de XML apparaît de manière encore plus explicite dans la thèse qui sous-tend l'ensemble de l'article, à savoir les rapports entre XML et l'évolution de la grammatisation du document.

Les auteurs appliquent, à l'évolution des langages documentaires utilisant XML, le concept de « grammatisation » forgé par Sylvain Auroux, à la suite de Jacques Derrida, et qui désigne la matérialisation de « la substance d'une expression en éléments matériels discrets et manipulables ». Ce faisant, ils distinguent trois postures dans l'utilisation de la syntaxe XML marquant un contrôle de plus en plus accru du contenu du texte :

« DTD », dont le but est d'annoter et de manipuler des documents ;
« Schémas », dont le but est d'échanger des données entre applications ;
« RDF/S, Ontologies/OWL » dont le but est d'effectuer des inférences formelles sur le contenu.

Or, cette analyse pose plusieurs problèmes. En premier lieu, elle traduit une confusion de taille entre la syntaxe XML et le modèle d'encodage de l'information sous-tendu par XML, à savoir un arbre. Si les deux premières postures utilisent à fois XML en tant que syntaxe et en tant que modèle, la troisième posture a pour base le modèle de graphes, sous-tendu par l'utilisation de RDF, et peut se traduire par une syntaxe XML, mais aussi d'autres syntaxes : Turtle, N-triples ou N3.

L'information encodée grâce aux DTD et aux Schémas forme un arbre dont les nœuds sont constituées par les différents éléments ou balises utilisés. Dans le cas de RDF, l'information encodée forme un graphe, selon le schéma « sujet-prédicat-objet » et constitue un modèle plus générique d'encodage de l'information, l'arbre étant un type particulier de graphes.

Cette distinction entre modèle et syntaxe est d'autant plus importante que les deux premières postures n'ont pas le même rôle que la troisième. Les DTD et les schémas définissent un cadre ou une grammaire pour valider la structure de l'information encodée en vue de son échange et/ou d'une transformation, qui, au passage, ne pose aucun problème grâce à l'utilisation de XSL ⁴ . RDF schéma et OWL permettent de définir les relations entre différents types de ressources (document, page Web, objet, personne, concept...) pour échanger des données hétérogènes et y appliquer des inférences. Par exemple, une ontologie définie selon RDFS ou OWL permet de définir qu'une ressource de type « Personne » entretient une relation de nature « connaît » avec une autre ressource de type « Personne ». Ils ne servent en aucun cas à valider un document RDF. Ils offrent « simplement » un vocabulaire commun pour exprimer des prédicats sur des types de ressources.

De plus, la structuration d'information en XML selon un cadre défini dans une DTD ou un schéma dépend d'un contexte précis et se pense sur l'ensemble de l'information encodée. Ainsi, une même information peut être encodée de manière complètement différente tout en restant valide selon un schéma et sans que la nature du message soit différente. La structuration d'information en RDF se conçoit, quant à elle, au plus proche de la donnée elle-même dans le contenu même du message véhiculé par l'information.

De ce point de vue, le modèle exprime une idée tout à fait juste, à savoir que ces trois postures constituent une évolution dans l'exploitation de différents niveaux de granularité de l'information, pour en arriver à l'exploitation par une machine du message véhiculé par l'information. Pour autant, si les « Schémas » constituent bien une évolution des « DTD », offrant la possibilité de contrôler les types de données comme une date, une chaîne de caractères, un booléen.., la troisième posture relève d'un paradigme différent et ne peut être assimilé à une évolution, mais plutôt à un complément.

D'ailleurs, les deux aspects ont évolué de façon concomitante ces dernières années. La communauté XML a mis au point des technologies telles que Relax NG ou schematron pour mieux contrôler et valider la structure des données, offrant les outils pour vérifier ce que les auteurs nomment la « validité sémantique », tandis que la communauté RDF a amélioré les moyens de définir une ontologie avec OWL mais aussi d'autres systèmes d'organisation des connaissances, comme les thésaurus avec SKOS. De même, deux langages de requêtes spécifiques ont été développées, Xquery pour XML et SPARQL pour RDF ce qui démontre bien que les deux modèles sont différents.

Enfin, un aspect essentiel a été occulté dans cette analyse. A aucun moment, les auteurs n'introduisent le rôle joué par le protocole HTTP et le concept des URI dans cette évolution. Or, l'échange de données entre les applications n'est possible que dans la mesure où nous disposons à la fois avec XML d'une syntaxe indépendante des plates-formes et des logiciels, mais aussi d'une couche de transport, un protocole de communication commun, HTTP et dans ce réseau, un moyen normalisé d'identifier et de localiser une ressource grâce aux URI. Ainsi, XML schéma représente bien une évolution naturelle dans les outils de validation et de contrôle de l'information encodée, mais il ne saurait être dissocié de HTTP, s'il est conçu dans le cadre des échanges de données entre applications. Or, si les grands éditeurs (IBM, Sun, Microsoft, Oracle, SAP et consorts) se sont rués sur XML et en ont fait la base des architectures SOA, c'est précisément, parce que le couple HTTP+XML constituait la réponse à la problématique des middlewares et de l'EAI, très en vogue à l'époque et largement remis en cause aujourd'hui.

4- Le Web sémantique ne se limite pas aux ontologies !

La confusion évoquée précédemment provient certainement d'une mauvaise interprétation des buts poursuivis par le Web sémantique et, dans ce cadre, du rôle précis de RDF et des ontologies. De ce point de vue, cet article constitue un bon exemple des méprises dont je parlais dans un précédent billet.

Ainsi, pour les auteurs, le Web sémantique vise à « construire un métalangage, fondé sur les ontologies, représentant de façon formelle le contenu des documents qui pourra donc servir de base à des modélisations informatiques ». Or, les ontologies ne constituent pas la base du Web sémantique, mais elles y participent, constituant une des briques. C'est RDF, dont il est fait malheureusement trop peu allusion dans l'article, qui constitue la base des technologies du web sémantique. En limitant le Web sémantique aux ontologies, les auteurs ont naturellement porté le débat sur les problématiques déjà connus dans l'intelligence artificielle, à savoir, pour faire court, la dangerosité de modéliser l'ensemble des connaissances du monde selon une ontologie imposée et unique ce qui réduit inévitablement le sens porté par un texte à une interprétation. De ce point de vue, la partie intitulée « Questionner le Web sémantique » est un conglomérat de tous les fantasmes véhiculés par cette idée d'ontologie universelle.

Or, comme le rappelle James Hendler dans cette réponse à Clay Shirky, au contraire de systèmes traditionnelles de représentation de la connaissance (les bases de connaissances auxquels fait allusion l'article) centralisés et imposant de partager la même définition des concepts communs, le Web sémantique est plus flexible et n'impose pas l'utilisation d'une seule ontologie, les mécanismes étant suffisamment puissants pour introduire des inférences entre deux données qui n'utilisent pas la même ontologie. Cette puissance est offerte par le modèle de base qui sous-tend tout l'édifice du Web sémantique, à savoir RDF. Ainsi, contrairement à ce qu'affirment l'article et les tenants du concept de Web socio-sémantique, le Web sémantique n'est pas anti-social et ne dépendrait pas d'une communauté ou d'un contexte social donné et imposé.

Même si les technologies du Web sémantique offrent le moyen de représenter « de manière formelle des contenus [nda : est-ce à assimiler à la notion de texte ?] via les ontologies » en vue d'une exploitation par une machine, le but initial du Web sémantique est plutôt d'échanger à une très large échelle des données de nature hétérogènes, ce que ne permet pas XML qui impose l'utilisation de schémas identiques ou une transformation préalable, et, éventuellement, grâce aux systèmes des ontologies, d'y appliquer des mécanismes simples d'inférence. Ainsi, le Web sémantique ne s'intéresse pas directement au texte en lui-même, mais aux données qui le décrivent ou le caractérisent, ce qu'on appelle communément les métadonnées, ou à des données précises à l'intérieur du texte comme le permet RDFa.

5- Évolution du Web sémantique depuis l'écriture de l'article

L'article constitue un bon point de repère pour évaluer l'évolution du Web sémantique et son appropriation. Les différentes briques et technologies du Web sémantique sont habituellement représentées sous la forme d'un cake. Or, au gré des recherches, ce cake évolue et la dernière version est largement différente de la version proposée par l'article.

Dans cette nouvelle version, à la base, nous trouvons toujours les URI qui permettent d'identifier les ressources (sujet ou, éventuellement, objet d'un triple) et les prédicats. RDF est le modèle de base pour l'échange des données et peut éventuellement s'appuyer sur XML, dans le cas de l'utilisation de la syntaxe RDF/XML. Au-dessus, on trouve SPARQL pour effectuer des requêtes, RDFS et OWL pour définir des vocabulaires RDF, assimilables à des ontologies et RIF, un langage de définition de règles. XML schema et les namespaces ont complètement disparus du cake, englobés dans la brique XML.

De même, si, à terme, les technologies du Web sémantique devrait améliorer la recherche d'information par une meilleure caractérisation des données et des relations qu'elles entretiennent entre elles, nous savons aujourd'hui que cela n'est pas son but initial, mais plutôt une conséquence. Ainsi, à une vision top-down qui a longtemps été l'axe privilégié par les recherches sur le Web sémantique, il se substitue peu à peu, entre autres par l'écosystème initié par le Web 2.0, une approche bottom-up dans lequel ce sont les annotations portés par l'utilisateur ou les données structurés qu'ils génèrent qui sont exploitées par les technologies du Web sémantique. De ce point de vue, Dbpedia est un exemple parfait. Partant du contenu mis à disposition sur wikipedia, le projet Dbpedia vise à mettre à disposition cette masse d'informations en RDF pour une meilleure exploitation par les machines de ce gisement de données.

6- Retour sur l'exemple donnée en annexe de l'article

En annexe du document, un exemple illustre les trois postures abordés dans l'article. Malheureusement, il comprend un certain nombre d'erreurs. Ainsi, le manque de maîtrise des technologies dont il est fait preuve pourrait expliquer en partie les contre-sens de l'article.

L'exemple utilisant une DTD ne pose pas de problèmes particuliers, si ce n'est qu'il aurait mérité un balisage plus fin. Si, à première vue, le schéma semble bien défini dans le second exemple, sa déclaration est complètement fausse. Dans le cas d'un schéma, il ne faut pas utiliser de doctype, le schéma étant déclaré dans l'élément racine du fichier XML. De plus, il est obligatoire de déclarer l'espace de nom par défaut correspondant au schéma XML ce qui nous donne :

<?xml version="1.0" encoding="UTF-8"?>
<CRH 
    xmlns="http://www.rogerpedauque.fr/casclinique/ns/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.rogerpedauque.fr/casclinique/ns/ http://www.rogerpedauque.fr/casclinique/ns/casclinique.xsd">
       [...]
</CRH>

L'exemple de RDF est complètement faux et démontre une incompréhension totale de son fonctionnement : les espaces de noms ne sont pas déclarés, il met en lumière la confusion entre le modèle XML et le modèle RDF. Voici approximativement ce qu'il pourrait obtenir :

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:med="http://www.rogerpedauque.fr/casclinique/">
   <rdf:Description rdf:about="urn:hopital-toto:patient/1050">
      <med:poids>78</med:poids>
      <med:taille>169</med:taille>
      <med:tension>14-8</med:tension>
      <med:saturation>98</med:saturation>
      <med:symptome_constate rdf:resource="urn:hopital-toto:symptome/030"/>
   </rdf:Description>
   <rdf:Description rdf:about="urn:hopital-toto:symptomes/030">
      <rdfs:label>Douleurs thoraciques</rdfs:label>
      <med:maladie rdf:resource="urn:hopital-toto:maladie/100"/>
   </rdf:Description>
   <rdf:Description rdf:about="urn:hopital-toto:maladie/100">
      <rdfs:label>Péricardite</rdfs:label>
      <med:symptome rdf:resource="urn:hopital-toto:symptome/030"/>
   </rdf:Description>
</rdf:RDF>
         

En guise de conclusion

Outre les contre-sens relevés, il me semble que l'analyse et la réflexion n'ont pas été menées à son terme. C'est finalement le plus frustrant dans cet article, ses conclusions ne sont pas à la hauteur de ses ambitions. Ainsi, il n'aboutit à aucune définition concrète et simple de la notion de texte au point même que l'interrogation initiale disparaît peu à peu et, lorsqu'il aborde les pistes les plus intéressantes, il ne la poursuit pas. Or, une phrase et une idée me paraît essentiel dans cet article : « On peut se demander dans ce modèle [nda : le Web sémantique] si la notion de document a encore un sens ». Voilà, précisément, la question essentielle à se poser !

Quelques notes en passant

1Les auteurs de l'article étaient d'ailleurs pour la plupart impliqués dans l'élaboration de la TEI.

2Pour connaître certains des auteurs de l'article de Roger, je sais pertinemment qu'il connaisse parfaitement les deux articles d'Allen Renear et alii.

3Le principe est le même pour LaTeX et je ne crois pas avoir entendu cet argument le concernant, tant il tomberait très rapidement à l'eau vu le profil des développeurs originaux de ce logiciel.

4p. 22, les auteurs affirment : « en l'état actuel de la technologie, peu de langages transformationnels sont capables de garantir l'invariance de niveau 1 (le résultat ne sera pas nécessairement bien formé) et aucun ne préserve le niveau 2 [nda : la validité de l'encodage de l'information selon un schéma] », alors que XSL qui date de 1999 garantit précisément ces deux niveaux de validité...

RDFaiser votre blog, 2ème partie : la pratique

got — Sun, 24 Feb 2008 18:53:46 +0100

Dans le précédent billet, j'ai expliqué en quoi RDFa permettait de décrire la structure du message contenu dans une page Web et comment on pourrait facilement générer du RDFa à partir des données structurées dans la base de données de votre CMS. Je vous propose maintenant de passer de la théorie à la pratique.

Ce tutoriel suppose que vous connaissez XHTML et le principe de base de RDF.

1ère étape : déclarer le bon doctype.

Dans la mesure où RDFa ajoute des attributs à XHTML, le W3C a mis au point une DTD spécifique issue de XHTML et intégrant les attributs RDFa. Par conséquent, si vous voulez que vos pages soient valides, le doctype à déclarer est le suivant :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

2ème étape : choisir les vocabulaires RDF que vous aller utiliser

RDFa reposant sur RDF, il est possible et même conseillé d'utiliser des prédicats déclarés dans les vocabulaires existants. Il faut donc choisir les vocabulaires que vous allez utiliser. Dans notre cas, ce sont les suivants :

Le Dublin Core simple, vocabulaire RDF pour les prédicats de base : titre, auteur, date...
Le Dublin Core qualifié qui offre des prédicats plus précis : date de création, date de modification...
SIOC, Semantically-Interlinked Online Communities, vocabulaire permettant de décrire et de relier la production d'une communauté en ligne ;
SIOC type, vocabulaire RDF qui affine les types de contenu manipulé par SIOC ;
SKOS, vocabulaire RDF pour décrire des vocabulaires contrôlés ;
RDFS, vocabulaire RDF pour décrire une ontologie en RDF ;
XSD, qui n'est pas un vocabulaire RDF, mais le langage de description d'un XML schema et qui sert à spécifier les types de données : date, chaîne de caractères, arbre XML...

3ème étape : déclarez les espaces de noms des vocabulaires utilisés

RDFa utilise le principe des CURIEs, Compact URIs, syntaxe mis au point par le W3C pour simplifier l'écriture des URI dans le cadre de RDF suivant le principe des espaces de noms. Par exemple, ce code :

<h1 property="http://purl.org/dc/elements/1.1/title">Mon joli titre</h1>

Avec les CURIes, il donne :

<h1 xmlns:dc="http://purl.org/dc/elements/1.1/" property="dc:title">Mon joli titre</h1>

Vous remarquez qu'il est nécessaire de déclarer l'espace de nom correspondant au vocabulaire avant de l'utiliser dans la propriété.

Pour faciliter la réutilisation des vocabulaires sur l'ensemble de la page Web, il est préférable de déclarer tous les espaces de noms dans l'élément racine <html> ce qui, dans notre cas, donne :

<html
xmlns="http://www.w3.org/1999/xhtml" 
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:sioc="http://rdfs.org/sioc/ns#"
xmlns:sioctype="http://rdfs.org/sioc/types#"
xmlns:skos="http://www.w3.org/2004/02/skos/core#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#" 
xml:lang="fr">

Étant donné qu'il s'agit d'une page Web encodé en XHTML, il ne faut pas oublier de déclarer l'espace de noms par défaut correspondant et la langue principale de la page Web.

4ème étape : Structurer le billet du blog

Nous y voilà, tout est prêt à présent pour ajouter le RDFa dans le code HTML de votre template/squelette/gabarits (choisissez votre cas) correspondant au billet de votre blog. Dans les exemples ci-dessous, le code HTML est donné à titre indicatif, je ne présage pas de la structure de votre page et je vous laisse adapter en conséquence. En revanche, le RDFa est le même :

[snip]
<body>
   <!-- je déclare que cette partie du code correspond à un billet de blog, en utilisant SIOC type et que l'URL du billet correspond au sujet des triples qui vont être déclarés ensuite grâce à l'attribut about -->
   <div class="monbillet" instanceof="sioctype:BlogPost" about="http://exemple.com/urldubillet">
         
         <!-- J'indique que le billet fait partie du blog dont l'URL est déclaré avec l'attribut href-->
        <span rel="sioc:has_container" href="http://exemple.com"/>
        
          <!-- Le titre du billet. Vous remarquerez que c'est l'attribut property qui est utilisé, 
               car l'objet n'est pas une ressource, mais une chaîne de caractères-->
        <h1 id="titredemonbillet" property="dc:title">Le titre du billet</h1>
        
         <!-- Le contenu du billet-->
        <div class="textebillet" property="sioc:content">Le texte du billet</div>
        
         <p class="metadonnees">
              <!-- 
                     La date du billet. Dans ce cas, l'objet doit être sous une forme normalisée pour une exploitation automatique par les machines. L'attribut content est donc utilisé pour ne pas prendre en compte le contenu de l'élément et l'attribut datatype pour indiquer le type de données
               -->
              Billet écrit le <span property="dcterms:created" content="2008-02-24"  datatype="xsd:date">24 février 2008 – 15h15</span>
             
               <!-- l'auteur du billet Je me contente ici du strict minimum des informations. -->
              par <span rel="sioc:has_creator">
                       <span instanceof="sioc:User">
                         <span property="rdfs:label">le nom de l'auteur</span>
                       </span>
                     </span>
              
               <!-- les tags du billet. Premier cas : pas d'URI associé au tag -->
               <span rel="sioc:topic">
                      <span instanceof="skos:concept">
                            <!--L'utilisation de l'attribut content permet de faire ensuite de mettre du contenu dans la balise, comme un lien hypertexte vers la page qui contient tous les billets associés à votre tag-->
                           <span property="skos:prefLabel" content="tag">
                                 Tag
                           </span>
                      </span>
               </span>
              
               <!-- Second cas : une URI est associée au tag grâce à MOAT par exemple ;-) -->
               <span rel="sioc:topic" href="http://dbpedia.org/resource/Semantic_Web">
                      <span instanceof="skos:concept" about="http://dbpedia.org/resource/Semantic_Web">
                            <!--L'utilisation de l'attribut content permet de faire ensuite de mettre du contenu dans la balise, comme un lien hypertexte vers la page qui contient tous les billets associés à votre tag-->
                           <span property="skos:prefLabel" content="tag">
                                 Tag
                           </span>
                      </span>
               </span>
              <div class="commentaires">
                      cf. la 5ème étape
             </div>
        </p>
   </div>
</body>

5ème étape : Structurer les commentaires

La dernière étape consiste à structurer les commentaires. Ce code est à introduire à l'endroit où j'ai indiqué « cf. la 5ème étape » dans le code précédent.

<!-- Le commentaire est une réponse au billet d'où l'utilisation de la propriété SIOC « has_reply ».  Comme l'objet est une ressource, on indique son URL en valeur de l'attribut href-->
<div class="commentaire" rel="sioc:has_reply" href="http://example.com/uridubillet#idducommentaire">
    
     <!-- Indication du type de la portion d'information en utilisant SIOC types. L'attribut about indique que l'URL du    commentaire sera le sujet des triples suivants-->
    <div instanceof="sioctype:Comment" about="http://example.com/uridubillet#idducommentaire">
        <p class="metadonnees">
            Ecrit par
            <!-- Indication de l'auteur du commentaire-->
            <span rel="sioc:has_creator">
               <span instanceof="sioc:User">
                  <!-- Courriel de l'auteur du commentaire encodé en SHA1 pour éviter au robot spammeur de le récupérer -->
                  <span property="sioc:email_sha1" content="528b95cc44060ceea571d7498a9fd2c7e3ca8a4c"/>
                  <!--Nom de l'auteur du commentaire. Si vous voulez ajouter un lien vers le blog de l'auteur du commentaire, il faut utiliser l'attribut content avec comme valeur le nom du commentateur-->
                  <span property="rdfs:label">le nom de l'auteur du commentaire</span>
               </span>
            </span>
            <!-- Cf. plus haut pour la date-->
            le <span property="dcterms:created" content="2008-02-24"  datatype="xsd:date">24 février 2008 – 16h30</span>
       </p>
       <div class="textecommentaire" property="sioc:content">Texte du commentaire</div>
     </div>
</div>

Vous trouverez en fichier attaché à ce billet la page Web complète sans les commentaires.

6ème étape : Vérifier le RDF généré à partir de votre encodage en RDFa

Pour vérifier le code généré à partir de votre page Web encodé en RDFa, vous devez utiliser un extracteur. Il en existe plusieurs, mais le plus à jour et le plus simple d'utilisation est le RDFa distiller mis à disposition par le W3C. Il suffit d'indiquer l'URL de votre fichier et le système parse le code et génère le code dans la syntaxe RDF/XML. Vous pouvez comparer le résultat avec n'importe quel billet de ce blog, puisqu'il est entièrement « RDFaisé », par exemple : MOAT : donner du sens à vos tags.

Une dernière étape pourrait consister à mettre en place de la négociation de contenu pour proposer automatiquement un contenu adapté à l'agent qui requête la page : dans le cas d'un navigateur le code en XHTML+RDFa et dans le cas d'une application qui exploite le RDF le code en RDF/XML. Vous pouvez trouver un exemple sur le blog d'Ivan Herman.

Maintenant, c'est à vous de jouer. N'hésitez pas si vous avez des questions, des remarques ou des améliorations à proposer. J'essayerai d'y répondre dans la mesure de mes moyens.

Il ne reste plus qu'à exploiter ce code ce que j'aborderai dans le prochain billet, le dernier de cette série.

RDFaiser votre blog, 1ère partie : la théorie

got — Sun, 24 Feb 2008 14:15:58 +0100

HTML, de même que XHTML, permet de structurer une page Web selon les principes d'un langage à balises. Les différentes balises indiquent de manière hiérarchique le rôle joué par chaque portion d'information dans le contexte de la page Web.

Ainsi, la structure d'un document HTML, comme tout document XML, ne décrit pas le contenu/le message de la page Web, mais reflète la structure de la page Web en elle-même. C'est pourquoi il me semble erroné de parler de « sémantisation », lorsqu'on encode en HTML ou, plus généralement, en XML.

Par exemple, soient les deux portions de code HTML suivants :

<div class="contenu">
       <p class="normal">
                Le <a href="http://barcamp.org/SemanticCampParis">SemanticWeb camp</a> se déroule à Paris 
                le samedi 16 février 2008 à partir de 9h30.
        </p>
</div>

<div class="description">
         <ul>
                <li>
                        Le <strong>SemanticWeb camp</strong> se déroule à Paris 
                        le <em>samedi 16 février 2008 à partir de 9h30</em>.
                </li>
         </ul>
</div>

Ces deux bouts de code HTML ne sont pas identiques du point de vue de la structure, pourtant, du point de vue du contenu, ils délivrent la même information, le même message. Si certains pourraient y voir une limitation de XML, il n'en est rien. Ce n'est tout simplement pas son rôle.

Pourtant, pour exploiter automatiquement l'information, il pourrait être utile d'exprimer dans le code HTML la structure ou la description du message. Ainsi, même en utilisant du code HTML différent, il serait possible d'exprimer le fait que le contenu est le même et tant qu'à faire autant l'exprimer selon un modèle commun, au hasard, RDF...

C'est précisément le but de RDFa dont la dernière version vient de sortir avec le statut de Working draft au W3C. Son principe de base est le même que les microformats, à savoir ajouter dans les attributs HTML des informations sur la structure du message.

Mais, là où les microformats utilisaient les attributs de HTML normalement dévolues à la structuration de la page Web, par exemple, l'attribut « class », confondant alors structure de la page Web et structure du message de la page Web, RDFa introduit de nouveaux attributs. De même, là où les microformats imposaient une normalisation de la valeur des attributs pour structurer le message, RDFa, en s'appuyant sur RDF, permet la réutilisation de tous les vocabulaires existants, ainsi que les ressources déjà disponibles. Loin de moi, l'idée de dévaloriser les microformats, c'est un moyen très simple d'ajouter un peu de structure à une page Web, mais, au final, leurs limites sont atteintes assez rapidement.

Reprenons notre exemple précédent et ajoutons du RDFa :

<div class="contenu" instanceof="cal:Vevent">
             <p class="normal">
                     Le <a href="http://barcamp.org/SemanticCampParis"><span property="cal:summary">SemanticWeb camp</span></a> 
                     se déroule à <span property="cal:location">Paris</span> 
                     le <span property="cal:dtstart" content="20080216T0930-0100>samedi 16 février 2008 
                     à partir de 9h30</span>.
              </p>
</div>

<div class="description" instanceof="cal:Vevent">
           <ul>
                 <li>
                        <strong property="cal:summary">SemanticWeb camp</strong> se déroule à 
                        <span property="cal:location">Paris</span> le <em property="cal:dtstart" content="20080216T0930-0100>samedi 16 février 2008 à partir de 9h30</em>.
                 </li>
          </ul>
</div>

Dans cette exemple, sont décrites les informations suivantes :

La portion de code décrit un événement ;
Cet événement est le SemanticWeb Camp ;
Cet événement a lieu à Paris ;
Cet événement a lieu le Samedi 16 février 2008 à partir de 9h30 ;

Ça a l'air évident pour nous autres humains, mais ça ne l'est absolument pas pour une machine. RDFa permet donc de faciliter le travail à la machine, puisque si la structure HTML est différente, la structure du message est la même et est clairement exprimée. Il est alors possible de mettre au point des applications qui exploite cette structure. Dans des précédents billets, j'ai déjà montré deux petites expériences avec RDFa. Mais, il en existe beaucoup d'autres. Par exemple, un moteur de recherche pourrait exploiter le type de ressource indiquée dans l'attribut instanceof. Cela permettrait de raffiner les recherches. Et, à la différence de HTML 5 et ses balises <article> et <section> qui n'ont aucun sens du point de vue de la structuration d'une page Web, le couple XHTML 1 et RDFa respectent le rôle de chacun des modèles.

Mais, je vous vois venir. Vous allez me répondre que c'est très joli, mais que la syntaxe est tout de même un poil complexe. Je ne peux pas vous donner tort. Mais, entre nous, n'est-ce-pas le but du Web dynamique et des CMS de générer le code HTML ? Toutes les données d'un CMS ne sont-elles pas parfaitement structurées dans une base de données ?

De même, vous conviendrez avec moi, que mis à part pour générer les fils RSS, on n'exploite bien peu la structure de nos données. Elle ne sert finalement qu'à placer les différents blocs d'information sur la page Web. Pourquoi ne pas l'exprimer clairement dans le code via RDFa ? Il suffirait de changer les templates/squelettes/themes de votre site, en y introduisant du RDFa, et le tour est joué, on a du RDFa généré automatiquement et à peu de frais et vous contribuez facilement à la construction du Web de données.

Pour vous aider dans cette démarche et pour passer de la théorie à la pratique, rendez-vous au prochain billet.

MOAT : donner du sens à vos tags

got — Sun, 24 Feb 2008 00:26:58 +0100

La folksonomie constitue une des fonctionnalités phare du Web 2.0. Son principe est finalement très simple : permettre aux utilisateurs de décrire des ressources (billet de blog, page Web, photos, vidéos...) par des mots-clés choisis librement. Elle offre, entre autres, les avantages suivants :

Améliorer la recherche d'information dans sa collection de ressources personnelles ;
Constituer un vecteur de sérendipité ;
Donner aux autres utilisateurs une idée du contenu de sa collection de ressources ;
Faire apparaître des réseaux sociaux implicites par l'utilisation commune de tags entre différents utilisateurs.

Peu à peu, les utilisateurs se sont pris au jeu et la folie du tagging s'est emparée de tous les internautes et plus simplement des afficionados du Web 2.0.

La folksonomie est devenue un formidable outil dont les possibilités semblent, d'ailleurs, encore largement sous-exploitées. Oui, mais, voilà, la folksonomie est limitée. Le tag n'est finalement qu'une chaîne de caractères dont le sens exact est connu du seul « taggueur » qu'un autre utilisateur peut éventuellement appréhender, mais en aucun cas une machine qui se repose uniquement sur la morphologie du tag pour l'exploiter. Ainsi, la folksonomie présente les désavantages suivants :

Impossibilité d'organiser les tags entre eux sous la forme d'une taxinomie ou d'un thésaurus ;
Deux utilisateurs peuvent partager un tag identique, mais en avoir une conception différente ;
la folksonomie n'est pas multilingue, c'est à dire qu'il n'existe aujourd'hui pas de moyens pour relier le même tag exprimé en anglais et en français ;
Deux tags différents peuvent être synonymes voire identique ou presque (penser aux fautes d'orthographe), sans qu'on puisse les relier.

Ces limitations sont bien connus et il en existe certainement d'autres.

La solution à ces problèmes réside en partie dans les technologies du Web sémantique et, pour le prouver, Alexandre Passant, un des contributeurs les plus actifs de la communauté du Web sémantique en France (si ce n'est le plus actif) a mis au point une application, MOAT (Meaning of a tag), qui vise précisément à donner du sens à vos tags.

Le principe est finalement assez simple. MOAT permet d'associer à un tag une URI. Une description de la notion du tag encodée en RDF est associée à cette URI. Ainsi, le tag n'est plus seulement une chaîne de caractères, mais possède un véritable sens donnée par l'ensemble des triples RDF qui décrit la notion utilisée en tag. Par exemple, si vous taguez votre billet avec le tag « Web sémantique », vous pouvez l'associer à l'URI « http://dbpedia.org/resource/Semantic_Web » qui correspond à la description de la notion de Web sémantique dans Dbpedia. Sont ainsi résolus, entre autres, les problèmes liés à l'orthographe de la notion et à la langue, puisque les tags « Web sémantique », « Semantic Web » ou « semweb » sont reliés à la même notion via l'URI.

Mais, MOAT ne s'arrête pas là. A chaque fois que vous associez un tag à une URI, une notification est envoyée à un serveur. Ainsi, d'autres personnes peuvent à leur tour associer cette URI à leur tag et, ainsi, partager les mêmes notions. Le serveur permet aussi de centraliser l'utilisation de l'URI. Ainsi, non seulement, on peut retrouver toutes les ressources taguées avec une notion précise quelque soit le service utilisé, mais aussi faire apparaître les réseaux sociaux avec plus de certitudes, puisque les utilisateurs s'accordent via l'URI sur le sens donné à leur tag.

MOAT peut être intégré via une API dans n'importe quelle service qui offre la possibilité de taguer. Alexandre a d'ailleurs mis au point un module pour Drupal en phase de finalisation et qui permet d'associer facilement une URI à un tag en effectuant une recherche sur sindice, un moteur de recherche qui indexe les données RDF dont j'ai déjà parlé.

MOAT démontre avec brio et une relative simplicité, l'utilisateur n'ayant besoin d'aucune connaissance particulière, l'apport des technologies du Web sémantique pour le Web 2.0. Merci Alex pour cette démonstration et pour ce superbe travail !

SemWeb Camp à Paris

got — Tue, 12 Feb 2008 21:12:24 +0100

En attendant la suite de la série sur le Web sémantique (je bute sur l'écriture du prochain billet...), un billet en forme de publicité.

Samedi 16 février à partir de 9h30 aura lieu le premier SemWeb camp à Paris à la Cantine (151 rue Montmartre, dans le 2ème arrondissement de Paris), qui est, entre autres, le nouveau « quartier général » de la FING, co-organisateur de cette manifestation avec la communauté Websemantique.org. Tout le monde est évidemment le bienvenu pour partager ce que vous souhaitez (en rapport avec le Web sémantique ;-) ), comme il est de règle dans un WebCamp.

L'ambition de ce premier rendez-vous est modeste. Il s'agit essentiellement de se rencontrer, de faire connaissance et de réfléchir à l'organisation de la communauté du Web sémantique en France et d'autres manifestations du même type de plus grande envergure. Ce sera aussi l'occasion pour tous ceux qui s'intéressent au Web sémantique, du débutant au confirmé de partager et de mieux en comprendre les différentes technologies et les enjeux. Un grand merci à Olivier qui a lancé l'idée de ce rassemblement

J'espère donc que je pourrai vous y rencontrer nombreux !

Du Web sémantique au web de données, 1ère partie

got — Mon, 04 Feb 2008 00:58:18 +0100

Si le Web sémantique atteint aujourd'hui le grand public, au point que Techcrunch repris par Internet Actu se demande quelle en sera la killer application, il reste une notion souvent mal comprise, objet de méprises voire de fantasmes. Et, pour cause, le Web sémantique est à la rencontre de domaines diverses : l'intelligence artificielle, la linguistique, les sciences de l'information et le Web pour ne citer que les principaux. Cette interdisciplinarité en a constitué à la fois la force et la faiblesse. De ce point de vue, l'article de Tim Berners-Lee, Ora Lassila et Jim Hendler dans Scientific American en 2001 en est un symbole, constituant un premier essai de synthèse entre les apports des différentes disciplines. Pour passer de la théorie à la pratique, sept années auront été nécessaires. Sept années qui ont vu les usages du Web changer, les concepts se préciser, les technologies se mettre en place. Si, aujourd'hui, la synthèse semble en bonne voie d'achèvement, il me semble utile d'en étudier la genèse et l'évolution pour préciser le concept de Web sémantique et ses applications possibles.

Genèse

La première Working draft publique de RDF date du 2 octobre 1997, celle de RDF schéma du 9 avril 1998 et on retrouve dans les notes personnelles de Tim Berners-Lee une feuille de route pour le Web sémantique dont la première version date de septembre 1998.

Ce dernier texte est intéressant à plus d'un titre. Tim Berners-Lee y pose les bases de la réflexion à la fois du point de vue des objectifs, des notions et de l'architecture. Dans sa vision, l'échange des informations sur le Web ne doit pas se limiter aux humains et être accessible aux machines. C'est pourquoi l'approche du Web sémantique vise à développer des langages pour exprimer des informations dans une forme accessible aux machines. Ainsi, le Web sémantique est comparable à une base de données globale:

«The Semantic Web is a web of data, in some ways like a global database»

Pour parvenir à cette objectif, Tim Berners-Lee esquisse une architecture composée de:

Un modèle commun de déclarations d'une grande généralité qu'il souhaite minimaliste, c'est RDF (Ressource description Framework);
A l'image des DTD pour XML, une couche de schéma pour partager des cadres communs, c'est RDF schema;
Un langage de conversion pour permettre l'alignement entre les différents schémas RDF;
Une couche de logiques pour réaliser des inférences;
Un langage pour assurer l'accès aux données;
Un langage pour effectuer l'alignement de données;
Un langage de requêtes générique pour RDF qui offre les mêmes caractéristiques de base que SQL;
Un principe de signature numérique pour permettre l'identification couplé au langage d'accès aux données ¹ .

Au final, ce document correspond à quelques exceptions près au concept et à l'architecture actuelle du Web sémantique. Il est étonnant, en particulier, de retrouver l'expression «Web of data» qui est réapparu, il y a un peu plus d'un an, pour désigner le mouvement pris aujourd'hui par le Web sémantique.

Pourtant, ce n'est pas ce document qui va constituer l'acte de naissance du Web sémantique, mais l'article ² , cité plus haut, paru en 2001 dans la revue Scientific American ³ . Tim Berners-Lee y exprime une vision finalement assez proche du document précédent. Ainsi, il définit le Web sémantique comme une extension du Web qui vise à structurer les données ⁴ en vue d'en donner le sens. Des agents logiciels peuvent ainsi mieux exploiter la masse d'informations, la qualifier, la traiter et donc la rechercher. Pour compléter la vision de Berners-Lee, Ora Lassila et Jim Hendler, qui sont tous deux issus de l'intelligence artificielle, vont y ajouter les apports de leur discipline à savoir les ontologies. Cet ajout à la vision initiale va provoquer, bien involontairement de leur part, les premiers contre-sens et incompréhensions. De plus, le choix du mot «sémantique» va constituer une deuxième source de méprises et de fantasmes.

Le Web sémantique est alors associé à une chimère poursuivie par les domaines de l'intelligence artificielle et le traitement automatique des langues, à savoir la compréhension du langage naturel et l'accès à la connaissance par les machines. Or, si ces disciplines sont riches de promesses, elles comptent aussi beaucoup d'échecs ce qui leur vaut de très nombreux adversaires. Paradoxalement, ces derniers vont retrouver dans leur rejet du Web sémantique les puristes de l'intelligence artificielle et du traitement automatique des langues. Et, pour cause, tout en récupérant des concepts et des technologies issus de ces disciplines, le Web sémantique ne poursuit pas exactement le même but. Il est finalement plus modeste.

Ces contre-sens sont la preuve de l'immaturité du concept, des technologies, mais aussi des utilisateurs. Ainsi, si XML dispose, par sa filiation avec SGML, de nombreuses applications, tout ou presque est à inventer pour les technologies du Web sémantique. Pourtant, faisant fi des obstacles qui se dressent et des critiques qui se font entendre, le W3C et différentes équipes de recherche continuent de mettre en place les différentes briques technologiques esquissées dans le document de Tim Berners-Lee. Peu à peu, avec l'évolution des usages du Web et son appropriation par les utilisateurs, les concepts vont se préciser et les applications possibles vont rencontrer les besoins des utilisateurs.

La suite dans les prochains billets...

Quelques notes en passant

1. Le principe qu'il exprime dans ce paragraphe ressemble à s'y méprendre à OpenID.

2. La traduction de cet article est disponible sur le site de l'URFIST de Toulouse, http://www.urfist.cict.fr/archive/lettres/lettre28/lettre28-22.html

3. La construction de cet article est expliquée par Jim Hendler dans Dark Side of the Semantic Web, Jim Hendler, http://www.cs.umd.edu/~hendler/presentations/DarkSide.pdf

4. Différence fondamentale avec XML qui vise à encoder des textes pour en définir la structure logique.