RDF

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é...

Stocker les triples

got — Sun, 25 Nov 2007 21:14:31 +0100

Dans un précédent billet, Iamhondjack notait avec justesse en commentaire qu'il ne fallait pas dissocier SPARQL et SQL de manière aussi stricte que je pouvais le faire. Il appuie son propos sur l'expérience de D2R server qui permet d'interroger une base de données relationnelles en SPARQL grâce à un mapping entre la modélisation de la base de données relationnelles et le modèle de graphe. Dans la foulée, Christian pose la question essentielle à savoir la performance et le temps de réponse.

Il semble que la question du stockage des triples RDF soit dans l'air du temps ce qui est logique, eu égard, à l'intérêt grandissant du Web of data. Ainsi, même si Tim Berners-Lee donnait déjà des premiers éléments de réponse dès 1998 dans un document intitulé Relational Databases and the Semantic Web (in Design Issues), un workshop organisé par le W3C et intitulé « RDF Access to Relational Databases » a permis de faire récemment le point sur la question. Une des conclusions de ce workshop est la nécessité de mettre au point une procédure normalisée de benchmark pour les triple store RDF sur le modèle de TPC pour les bases de données relationnelles.

Force est de constater que nous disposons que peu de recul aujourd'hui sur la question, quelques ressources traînent à droite à gauche sur le sujet :

sur le ESW wiki du W3C, on trouve une liste de triple store indiquant le nombre de triples pouvant être stocké et une liste d'articles présentant des rapports sur l'extensibilité des triple store ;
Un thésard propose les résultats d'un benchmark des moteurs SPARQL qu'il a effectué dans le cadre de sa thèse.
Dans un article très complet, l'équipe du CSAIL du MIT, à l'origine de C-store, propose une comparaison entre le stockage de RDF dans une base de données relationnelles et la solution choisie pour C-Store.
Mise à jour 26/11/2007 : Benchmarck pour AllegroGraph
Mise à jour 2/12/2007 (cf. les commentaires) : the Lehigh University Benchmark (LUBM), le benchmark pour AllegroGraph cité précédemment suit cette procédure, je vous conseille aussi la lecture de ce document qui analyse des résultats du LUBM d'Oracle, AllegroGraph, DAML DB, OpenLink Virtuoso et BigOWLIM (Via More News).

Or, il s'agit d'une question cruciale dans la perspective de l'industrialisation du modèle RDF et de la dissémination des technologies Web sémantique. Même si certaines personnes dont je fais partie pensent que le modèle relationnel atteint aujourd'hui ses limites, le modèle de graphe à la base de RDF ne pourra s'imposer que dans la mesure où il aura été prouvé que les outils permettant de l'exploiter présentent des performances supérieures. La mise au point d'un benchmark représente donc une étape essentielle.

Les benchmark devront rapidement dégager les avantages et inconvénients de chacun des trois modèles de stockage qui se dégage actuellement :

Le mapping à la volée d'une modélisation d'une base de données relationnelles et du modèle de graphe. Ce modèle est celui des outils D2R server ou SquirellRDF, par exemple.
Le stockage dans une base de données relationnelles dont la modélisation permet le stockage direct sous forme de triples, par exemple : 3store, RAP ou ARC reposant sur MySQL, Virtuoso, Sesame ou Semantic Web/RDF Library for C#/.NET
Les entrepôts qui stockent de façon native les triples RDF, par exemple : AllegroGraph, BigOWLIM qui peut être une des solutions de stockage et d'inférence pour Sesame, Oracle 11g, Mulgara. Les deux derniers n'offrent pour l'instant qu'un support limité de SPARQL.

Il semble d'ors et déjà acquis que le premier modèle ne sera pertinent que dans la phase de transition, que nous vivons aujourd'hui. En effet, il ne répond que partiellement aux besoins des utilisateurs comme l'explique cet article des développeurs de D2R server, qui sont les mêmes que Dbpedia pour lequel ils ont utilisé Virtuoso.

Naviguer et rechercher dans le Web of data

got — Sun, 11 Nov 2007 22:31:01 +0100

Preuve supplémentaire de la maturité du Web of data, nous disposons, à l'instar de son grand frère le Web, de navigateurs et de moteurs de recherche spécialisés ne requérant aucune compétence particulière.

Petite revue de détail, en commençant par les navigateurs.

A tout seigneur, tout honneur, le premier d'entre eux mis au point par Tim Berners-Lee et son équipe : Tabulator développé en Javascript (Attention, ne fonctionne qu'avec Firefox). Outre la possibilité de naviguer dans des sources en RDF, il offre un moteur SPARQL, la possibilité d'afficher les données géographiques sur une carte, les événements sur un agenda ou une frise chronologique. C'est certainement le plus complet, mais aussi le plus geeky.
Dans le même ordre d'idée et proposant des fonctionnalités à peu près équivalentes, OpenLink RDF browser, qui sert de démonstration au produit Virtuoso server qui intègre, entre autres, un RDF store et sparql end point, de l'éditeur Open link software.
Plus simple et plus accessible, Disco hyperdata Browser mis au point par l'équipe de Dbpedia (ces types ne s'arrêtent jamais). L'interface est, disons, épurée, mais efficace. Fonctionnalité intéressante, il intègre un cache qui permet de disposer de tous les triples consultés récemment par les utilisateurs pour naviguer dans les sources RDF.
Pour finir, celui qui me semble le plus prometteur : Zitgist browser mis au point par Frederik Giasson. Aussi simple que Disco, mais avec une interface très agréable.

Côté moteurs de recherche, leur mise à disposition est plus récente et ils sont encore largement expérimentaux.

Sindice est mis au point par le DERI (Digital Enterprise Research Institute). Il permet d'interroger en texte intégral les données RDF indexées, de rechercher toutes les ressources qui comporte une URI ou un sujet en donnant un prédicat et un objet. Il propose une interface REST qui permettra de relier les données distribuées. C'est évidemment une version bêta qui référence 11 millions de documents RDF dont Dbpedia, ce qui correspond à environ 981.4 million d'URIs et 3.1 milliards de triples.
Sur le même modèle, l'institut of Web science de l'université Southeast en Chine a annoncé la sortie de Falcons Object Search. Il intègre aussi une fonctionnalité de navigation et revendique 17,5 millions de ressources, mais je ne sais pas à quoi cela correspond.
Pour finir, le précurseur : Swoogle qui mériterait un petit ravalement de façade est certainement le plus spécialisé et le moins accessible, mais aussi le plus complet en termes de données. Gageons que l'Ebiquity group va nous proposer rapidement une nouvelle version.

Petite précision : ces moteurs recherchent dans les données disponibles en RDF, ils ne sont pas à confondre avec un moteur sémantique dont le but est de rechercher sur le Web, mais éventuellement en s'appuyant sur les technologies du Web sémantique pour offrir de nouvelles fonctionnalités. De ce point de vue, vous entendrez peut-être parler de True Knowledge ou de PowerSet.

Vous n'aurez à présent plus d'excuses pour consulter toutes les données RDF à notre disposition et consulter le Web of data.

Retour sur Freebase à la lumière du Web of data

got — Sun, 11 Nov 2007 18:33:52 +0100

Au mois de mars, Tim O'Reilly repris par Internet Actu définissait ainsi le but de Freebase : « Créer les synapses du cerveau global ». On y voyait les prémices de la première application concrète et accessible à tous du Web sémantique. Six mois plus tard, je vous propose d'y revenir, alors que le concept de Web of data et Dbpedia ont fait leur apparition.

Dans l'article d'Internet actu, Hubert citait Denny Vrandecic, concepteur de Semantic Mediawiki :

« Metaweb [nda : le concepteur de Freebase et par extension le logiciel qui fait tourner freebase] vient du monde des données structurées, même si la structure est ici flexible et changeante. Semantic Media Wiki vient du monde des données non structurées, qui peuvent être améliorées par quelques éléments de structure pour mettre en relation plusieurs éléments non structurés. ».

Cette analyse me paraît excellente, car elle pose tous les enjeux de Freebase et son mode de fonctionnement. Si on voulait caricaturer, je dirais que Freebase est un wiki structuré OU une base de données dont la modélisation peut changer à la demande de l'utilisateur qui peut librement saisir les données. Choisissez votre camp en fonction de votre origine : données non structurées ou données structurées.

Concrètement, Freebase est organisée sous la forme d'une taxonomie thématique (arts et divertissements, Société, Sport...). Chaque thème comprend des types de ressource (film, acteur, opera, pièce de théâtre, Personne, ville...) auxquels sont rattachés des propriétés. Ces propriétés peuvent relier une ressource à une autre ressource ou à une donnée typée (chaîne de caractères, date, nombre entier...). Si vous suivez ce blog attentivement, vous aurez reconnu le principe d'une ontologie qui présente la particularité d'une structure évolutive à la demande des utilisateurs.

Cerise sur le gâteau, Freebase propose pour gérer cette ontologie une interface très agréable, facile à manipuler et qui permet très simplement d'éditer une donnée, d'en ajouter, de relier une ressource à une autre.

Réaction immédiate : c'est génial, c'est effectivement la première application du Web sémantique ! En apparence et au premier abord, tout y est et il faut l'avouer, c'est impressionnant. Mais, à y regarder de plus près, deux problèmes se posent : l'un est technologique et l'autre est, je dirais, cognitif.

Commençons par le problème technologique. Si Freebase est structuré avec une ontologie, il n'utilise absolument aucune technologie du Web sémantique : pas de RDF, pas de OWL et encore moins de SPARQL. Et, c'est là que le bat blesse. Si je devais le classer parmi les visions du Web proposées par Christian, Freebase rentrerait dans la deuxième catégorie avec Google OpenSocial. En effet, Freebase propose une API pour accéder à ses données, mais avec un langage de requêtes « maison » le MQL (Metaweb query language) basé sur la syntaxe Json.

Conséquence de ces choix :

L'utilisateur est tributaire de Metaweb pour l'évolution de l'API (vous allez me répondre que c'est pareil pour toutes les API, c'est vrai, mais ce n'est pas une raison) ;
Le MQL est assez limité et ne permet d'interroger qu'un type de ressource à la fois, c'est dommage, alors qu'ils ont construit Freebase avec une ontologie ; c'est un peu comme acheter une Ferrari et être obligé de rouler à 130 km/h sur l'autoroute... ;
Il est impossible de lier une donnée extérieure à Freebase à une donnée de Freebase et inversement. Il fonctionne en vase clos et ne correspond pas à l'architecture distribuée et décentralisée du Web of data.

Arrêtons-nous sur ce dernier point. Le principe du Web of data/Web de données/Web sémantique est de mettre à disposition des bases de données décentralisées, dont toutes les données (aussi bien les ressources, que les propriétés) sont accessibles via une URI (et même une URL), reliées entre elles par des liens typées, décrites selon le même cadre de description (RDF), interrogeables avec le même langage de requêtes et le même protocole, c'est à dire la même API (SPARQL). Avec une architecture distribuée suivant les normes du Web sémantique, il est possible d'interroger en une requête deux bases distinctes. Au contraire, Freebase est basé sur un modèle centralisé, toutes les données doivent être dans Freebase pour y accéder et les interroger. D'ailleurs, Hubert Guillaud et Daniel Kaplan avaient repéré cet obstacle :

« la résistance des propriétaires de grandes bases de données (organismes scientifiques, entreprises, médias…) devant la perspective d’une mise en commun “profonde” de leurs informations »

Cet obstacle existe aussi avec l'architecture décentralisée du Web sémantique, mais la réticence sera peut-être moins importante dans la mesure où les organismes pourront gérer et contrôler eux-mêmes la mise à disposition de leurs données.

Le second problème tient aux conséquences de la structuration forte des données. Le système contraint la contribution de l'utilisateur qui est obligé de se conformer à la structure de la ressource. Il est possible d'ajouter des propriétés, mais ce n'est pas immédiat et le changement sera répercuté au niveau du type. De ce fait, les données sont parfaitement structurées et organisées, mais, à mon avis, nous n'atteindrons jamais la richesse de Wikipedia, dont le principe de base est la liberté totale de l'utilisateur. De ce fait, il est aussi peut-être moins agréable et enrichissant à naviguer pour un humain que Wikipedia. Freebase est plutôt fait pour les machines.

Sur ce point, il n'est pas inintéressant de faire la comparaison avec Dbpedia. Ce dernier est construit, entre autres, à partir des info-box de Wikipedia et de la catégorisation des articles. Si les données sont d'une très grande richesse, les défauts/manques de structuration de Wikipedia dûs à la liberté totale de l'utilisateur apparaissent rapidement quand vous commencez à faire des applications avec Dbpedia. J'avais déjà fait allusion à ce problème en ce qui concerne les propriétés relatives au lieu de naissance. Il m'est apparu à une autre occasion. Suite à un très beau billet d'Outils froids sur Wikipedia, j'ai voulu aller dans son sens en construisant une application exhibit listant tous les personnages de Dune ou de Star Wars à partir de Dbpedia. Malheureusement, après quelques tentatives, j'ai dû me rendre à l'évidence, il n'existait aucune catégorie qui rassemble tous les personnages de ces univers, ils étaient dispatchés et leur structure n'était pas assez stricte pour réussir à créer une application qui tienne la route. Bref, j'ai fait l'expérience que toutes personnes qui ont traité des données non structurées ont faite, à savoir la limitation des machines.

Finalement, si je devais conclure, je dirais qu'aucun des deux modèles n'est parfait et que chacun présente ses avantages et ses inconvénients. Les deux modèles doivent coexister. De plus, Freebase va s'enrichir et, avec Dbpedia, il est possible de remédier aux problèmes de structuration de Wikipedia. J'emmétrais quand même une réserve à l'égard de Freebase, il serait quand même bienvenu qu'ils changent leur architecture et qu'ils ouvrent vraiment leurs données pour les intégrer au Web of data. Je pense même qu'il en va de la pérennité de leur service.

Sparql, maillon essentiel du « Web of data »

got — Mon, 17 Sep 2007 08:43:18 +0200

Avec l'initiative Linked data dont Dbpedia est l'exemple le plus représentatif, nous disposons d'une masse de données structurées de plus en plus importantes. Peu à peu se constituent sur le Web des entrepôts de données décentralisées, mais reliées par l'utilisation de RDF et de la propriété OWL « sameAs ».

Par exemple : la notice Paris dans Dbpedia est reliée à la notice Paris dans Geonames via le triple suivant :

<rdf:Description rdf:about="http://dbpedia.org/resource/Paris">
	<owl:sameAs rdf:about="http://sws.geonames.org/2988507/"/>
</rdf:Description>

De cette façon, vous pouvez interroger de toutes les informations de Dbpedia et de Geonames sur la ressource « Paris ». Les applications sont très nombreuses, comme par exemple ma knowledge box (qui semble fonctionner cahin-caha, il faudra que je regarde cela) ou d'autres, comme le montre cet article.

Vous allez me dire : « C'est bien joli, mais quelle est la différence avec un Flick'r, un Google Maps et autres services Web 2.0 ? Ils exposent leurs données via des Web services qu'on peut aussi réutiliser pour créer des Mashup. »

C'est entièrement vrai. Il existe néanmoins une différence et elle est de taille. Dans le cas des services Web 2.0 actuels, les Web services sont certes disponibles, mais ne sont pas normalisés, il faut donc connaître les méthodes du Web services et la structure des données pour les interroger. Ce n'est pas le cas des entrepôts de données exposés en RDF, puisqu'on dispose alors d'un langage de requêtes et d'un protocole unique : le Sparql (prononcé « sparkoeule »), actuellement en cours de normalisation au W3C.

Je vous entends d'ici : « Mais, tu nous répètes à longueur de billets que RDF, c'est souple, générique et qu'on peut associer autant de propriétés qu'on veut à une ressource. Comment, dans ces conditions, peut-on connaître les propriétés utilisées dans tel ou tel entrepôt ou pour telle ou telle ressource ? »

Très bonne remarque, cher lecteur, je vois que tu suis. C'est là qu'entre en jeu toute la puissance de Sparql. On n'a pas besoin de connaître a priori la structure et le contenu des données pour pouvoir les interroger avec ce langage de requêtes. En effet, Sparql permet d'interroger n'importe quel composant d'un triple qui, je le rappelle, ont la forme Sujet-Prédicat-Objet.

Exemple : si vous voulez connaître tous les triples qui composent mon fichier FOAF, sans rien connaître a priori des ressources décrites, des propriétés utilisés ou du contenu, on effectue la requête suivante :

SELECT ?sujet ?predicat ?objet 
{
	?sujet ?predicat ?objet
}

Autre exemple : je veux connaître tous les prédicats/propriétés pour décrire la ressource Paris ou pour lesquels la ressource Paris est l'objet dans Dbpedia :

SELECT DISTINCT ?predicat
{
 	{<http://dbpedia.org/resource/Paris> ?predicat ?objet.}
 UNION {
	?sujet ?predicat <http://dbpedia.org/resource/Paris>.
	}
}

Dernier exemple : maintenant que je connais les propriétés décrivant la ressource Paris, je veux connaître toutes les personnes qui sont nés à Paris :

SELECT DISTINCT ?personne
{
 	{?personne <http://dbpedia.org/property/cityofbirth> <http://dbpedia.org/resource/Paris>.}
	UNION {
	?personne <http://dbpedia.org/property/birthPlace> <http://dbpedia.org/resource/Paris>.
	}
	UNION {
	?personne <http://dbpedia.org/property/birthplace> <http://dbpedia.org/resource/Paris>.
	}
	UNION {
	?personne <http://dbpedia.org/property/placeofbirth> <http://dbpedia.org/resource/Paris>.
	}
	UNION {
	?personne <http://dbpedia.org/property/placeOfBirth> <http://dbpedia.org/resource/Paris>.
	}
	UNION {
	?personne <http://dbpedia.org/property/placebirth> <http://dbpedia.org/resource/Paris>.
	}
	UNION {
	?personne <http://dbpedia.org/property/placeBirth> <http://dbpedia.org/resource/Paris>.
	}
}

Cet exemple montre, au passage, qu'il reste encore pas mal de travail à Dbpedia pour harmoniser les propriétés de leur entrepôt (cf. les commentaires pour plus de renseignements).

Je pense que vous avez compris le principe général. C'est une véritable avancée par rapport au système des Web services ~~et encore plus au SQL qui ne permet pas de faire une requête du type « SELECT * FROM * » (ce serait en quelque sorte un équivalent)~~ (MAJ. cf. le commentaire de Nicolas). De plus, Sparql peut renvoyer les réponses en XML selon un schéma normalisé, alors que chaque Web service définit son propre schéma XML pour répondre à une requête.

Et là, Manue me dit : « c'est comme l'OAI, tu peux savoir la structure de l'entrepôt grâce aux verbes ListMetadataFormats pour lister les schémas de métadonnées utilisées et ListSets pour lister les ensembles de l'entrepôt OAI. »

Le principe est à peu près équivalent, mais il va bien plus loin, puisque, dans le cas de Sparql, vous ne vous contentez pas de récupérer le nom du schéma de métadonnées et le lien vers sa grammaire, vous récupérez la structure complète. De même, vous n'avez pas besoin de différents verbes qui sont limités à un seul type d'actions, RDF pour exprimer les données et Sparql pour les interroger sont suffisamment puissants et génériques pour effectuer à peu près tous les types d'interrogations sur un entrepôt de données avec une seule méthode et un seul langage de requêtes.

RDF pour les nuls

got — Mon, 27 Aug 2007 19:36:22 +0200

Préambule du 27 août 2007 : à la suite d'un bon billet de David sur RDF, je voulais ajouter en commentaire la référence vers ce billet que j'avais écrit le 8 septembre 2006 ; je me suis alors aperçu qu'il n'avait pas été récupéré lors de l'import de mon ancien blog. Comme j'avais un peu la flemme de rechercher dans mes archives persos, mon sauveur se nomme Internet Archive dont le crawler salutaire avait indexé cette page. Qu'il en soit remercié. Le voici donc republié en l'état, en espérant que les commentateurs de l'époque m'excuseront le fait que je ne récupère pas leur prose ;-).

Pour vous faire apprécier pleinement toute la substantifique moelle du prochain billet, je me suis dit qu'il serait peut-être utile de réexpliquer le principe général de RDF1. Je voulais rassembler toute cela en un billet, mais ça faisait un peu long, alors j'ai séparé les choses. Donc, ceux qui ont déjà tout compris, vous pouvez attendre sagement le prochain billet (promis, il devrait arriver dans la foulée), pour ceux qui voudraient une piqûre de rappel voire plus, je vous invite à lire cet essai d'explication pédagogique de RDF (vous me direz en commentaire si ça vous paraît clair).

RDF n'est pas un langage de programmation, ni même un langage à balises permettant de structurer une information. C'est un modèle de description des données, c'est d'ailleurs le sens de l'acronyme RDF : Ressource description framework. Pour communiquer entre humains, nous disposons d'un langage que l'on qualifie de « naturel » pour le différencier avec les langages informatiques. RDF, c'est un peu l'équivalent de notre langage naturel pour permettre à des machines de communiquer entre elles.

Une grammaire

En langage naturel, pour décrire les données/choses/objets/concepts... on dispose des phrases qui sont composées de mots eux-mêmes constitués par l'agencement de sons et organisés selon une grammaire (ouf !!). En RDF, ce sont les assertions, appelés aussi déclaration dans la norme du W3C, qui jouent le rôle des phrase et qui possèdent une grammaire très simple : Sujet Prédicat Objet. En clair, faire du RDF consiste, en fait, « simplement » à écrire l'équivalent de phrases simples pour que des machines (qui sont somme toute stupides) puissent se parler et échanger des données de façon intelligente. En multipliant ces phrases, on agrège de l'information et on finit par créer des connaissances. Ces déclarations peuvent être représentées sous la forme d'un graphe. Par conséquent, le RDF est un modèle de description de données sous forme de graphes. Donc premier élément important : des phrases simples dites déclarations (statement dans la langue de Shakespeare).

Évidemment, il n'est pas possible d'exprimer toutes les informations avec des phrases simples. C'est pourquoi il existe en RDF des méthodes pour construire l'équivalent de phrases plus complexes. Mais dans le cadre de cette explication, je vous propose d'en rester là.

Une syntaxe

Pour inscrire le langage naturel sur un support en vue de son partage de façon asynchrone, nous disposons de l'écriture constituant un système graphique d'expression du langage. De la même façon, pour une machine, il est utile d'exprimer les déclarations d'une façon qu'il sera capable de comprendre. Ainsi, on inscrit les déclarations/graphes RDF selon un système graphique, une syntaxe particulière. En fait, on peut même les écrire selon plusieurs syntaxes (un peu comme si on avait plusieurs types d'alphabets différents). Il y a quatre syntaxes : XML, N3, N-triples, Turtle.

Un référentiel commun

Pour pouvoir communiquer et se comprendre, deux humains doivent utiliser un référentiel commun qui est exprimé dans un dictionnaire. C'est le même principe en RDF, sauf qu'en lieu et place du dictionnaire, nous disposons des URI qui peuvent être définis dans des vocabulaires RDF, d'autres fichiers RDF comme des ontologies ou tout simplement une page Web. Par exemple, le vocabulaire FOAF définit le concept de personne. Si, dans un fichier RDF, le sujet décrit est de type personne, je vais le définir comme tel en utilisant l'URI : http://xmlns.com/foaf/0.1/Person.

Deux types d'objets en RDF utilisent les URIs :

Une ressource qui correspond à toutes choses décrites par une expression RDF ;
une propriété qui est un aspect, une caractéristique, un attribut, ou une relation spécifique utilisée pour décrire une ressource, en clair le prédicat

Exemple : « http://lespetitescases.net (ressource/sujet) http://purl.org/dc/elements/1.1/title (propriété/prédicat) 'Les petites cases'(objet) » est une déclaration RDF qui se traduit en langage naturel par : « le site Web dont l'adresse est http://lespetitescases.net a pour titre les Petites cases ».

Comme on le voit à travers cet exemple, il est possible d'indiquer l'objet d'une déclaration par une simple chaîne de caractère. On parle alors de litéral. Ce genre de propriété est appelé propriété de type de données. Mais, il est aussi possible de faire référence en objet à une ressource, on parle alors de propriété d'objet.

Pour finir, voici un exemple compet2 :

Je cherche à décrire ce site Web en RDF en utilisant la syntaxe XML :

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="http://www.lespetitescases.net/">
    <dc:title>Les petites cases</dc:title>
    <dc:author>Gautier Poupeau</dc:author>
    <dc:subject>Web sémantique</dc:subject>
    <dc:subject>XML</dc:subject>
    <dc:subject>Digital humanities</dc:subject>
  </rdf:Description>
</rdf:RDF>

Voici la liste des assertions

Subject	Predicate	Object
http://www.lespetitescases.net/	http://purl.org/dc/elements/1.1/title	"Les petites cases"
http://www.lespetitescases.net/	http://purl.org/dc/elements/1.1/author	"Gautier Poupeau"
http://www.lespetitescases.net/	http://purl.org/dc/elements/1.1/subject	"Web sémantique"
http://www.lespetitescases.net/	http://purl.org/dc/elements/1.1/subject	"XML"
http://www.lespetitescases.net/	http://purl.org/dc/elements/1.1/subject	"Digital humanities"

J'aurais bien aimé vous proposer aussi le graphe de ces déclarations mais le RDF validator qui est censé le générer automatiquement est parfois un peu capricieux...

Quelques notes en passant

1 Zid, tu constateras avec plaisir que je suis tes conseils, je me répète ;-)

2 Cet exemple est inspiré de la présentation des résultats de le validateur RDF du W3C.

Le Web sémantique rencontre....

got — Wed, 22 Aug 2007 22:56:52 +0200

Preuve de la maturité des technologies et des standards du Web sémantique, les chercheurs et promoteurs du domaine vont à la rencontre d'autres communautés pour leur proposer de nouvelles applications, des idées, des tutoriaux, leurs expertises... Bref, des rencontres se produisent qui amènent des projets qui montrent chaque jour un peu plus la pertinence du modèle. Voici une petite sélection repérée ces derniers jours.

Le semWeb rencontre les catalogues de bibliothèques

Comme tout le monde, je suis allé voir le projet Open Library lancé par Internet Archive. Quel ne fut pas ma déception de voir qu'il n'y avait dans le projet aucune réflexion autour de la modélisation des oeuvres avec FRBR, pas de notion d'autorités, aucune relation entre les ouvrages... Bref, un bon vieux catalogue à la papa avec un formulaire de saisie bien rebutant. Quand on voit des initiatives comme Freebase (qui vient d'ouvrir à tous, je vous conseille la visite) ou des sites comme Library thing, comment peut-on encore faire des interfaces pareilles, sans même parler de Web sémantique ? Heureusement, Frédérik Giasson qui est un des développeurs de la Bibliographic ontology a pris le taureau par les cornes (pas comme moi, qui me contente de jouer à l'utilisateur grincheux...) et a contacté les promoteurs du projet pour transformer leurs données en RDF et les exposer via un Sparql endpoint. Me voilà ravi et un pas de plus entre le Web sémantique et les bibliothèques, dont la rencontre ne peut être que naturelle.

Le SemWeb rencontre les vocabulaires contrôlés

Plus qu'une rencontre, ce couple s'apparente plus à des parents. A l'occasion de DC 2007 qui aura lieu la semaine prochaine, Alistaire Miles fera un tutoriel sur les vocabulaires contrôlés dont le diaporama est déjà disponible : objectifs, retour sur investissement, construction, comparaison avec les folksonomies, publication, "skosification", extraction et alignement. Tout y est et c'est très intéressant.

Le SemWeb rencontre le multimédia

Le W3C multimedia Semantics incubator group a publié une série de rapports faisant le point sur les normes et leurs équivalents existants en RDF/OWL pour décrire des objets multimédias (son, image, vidéo). Tout y passe : EXIF, MPEG 7... Cela pourra certainement vous donner des idées pour décrire vos objets en RDF.

Le SemWeb rencontre les utilisateurs d'Excel

La syntaxe RDF/XML vous rebute, vous ne comprenez rien à Turtle ou N-Triples, mais vous êtes convaincu de l'intérêt de RDF et vous avez une pléthore de fichier excel à convertir, alors RDF123 est fait pour vous. Ce logiciel transforme les données d'un tableur en RDF et a été mis au point par Ebiquity group, déjà à l'origine de Swoogle, le moteur de recherche du Web sémantique.

Le SemWeb rencontre les moteurs de recherche

Henry Story de Sun explique dans ce billet que les requêtes des utilisateurs sur le moteur de recherche Altavista (j'avoue que je ne savais pas qu'Altavista existait toujours...) sont transformées en requête SPARQL dont les réponses au format XML ad-hoc sont transformés en XSL. Si j'ai bien compris l'intérêt de la méthode (mais je suis pas bien sûr sur ce coup-là), cela laisse entrevoir la possibilité de rendre transparent un formulaire Web pour une machine via sa modélisation en SPARQL. Cela signifie aussi qu'on pourrait interroger le moteur via le protocole Sparql et si on étendait la méthode à tous les moteurs, oui, on obtiendrait un protocole unique pour interroger tous les moteurs. Et, ensuite, on pourrait relier les réponses avec les entrepôts RDF et puis.... Ho !! là, je m'emballe, désolé...

Et, pour finir, si vous vous demandez encore ce qu'est le Web sémantique, son intérêt et vous y retrouvez entre RDF, OWL, RDFa, SPARQL et autres, je vous conseille cette introduction au Web sémantique signée Ivan Herman du W3C faite à l'occasion de DC 2007.

Et, si après tout cela, vous n'êtes pas encore convaincu que ça avance peu à peu et que le Web sémantique mérite votre attention, je ne sais que faire de plus ;-) Bonne lecture.

Le code de la knowledge box

got — Sun, 15 Jul 2007 13:15:50 +0200

Plusieurs d'entre vous m'ont demandé le code de la knowledge box. C'est avec plaisir que je vous en fais part, mais autant vous prévenir tout de suite je suis un très mauvais codeur quand il s'agit d'utiliser un langage de programmation. Merci d'avance pour votre indulgence à ce niveau ;-).

Six parties composent la knowledge box :

la classe PHP, RAP, RDF API for PHP mis au point par Chris Bizer, qui permet d'interroger le SPARQL end point de Dbpedia ;
Un script PHP qui utilise cette classe et qui rapatrie les données ;
Un script javascript très très simple pour l'AJAX ;
Un bout de code PHP à introduire dans un bloc de Drupal ;
les triples RDFa dans votre contenu ;

Pour RAP, il suffit de le télécharger et de le poser dans votre arborescence. Attention au chemin, il nous sera utile pour y faire référence dans le script PHP.

Le script PHP permet d'interroger le serveur SPARQL de Dbpedia, de construire la requête et de formater la réponse qui revient en HTML zarbi... (j'ai l'impression qu'il y a un bug à ce niveau chez Dbpedia).

<!--Le chemin vers RAP -->
define("RDFAPI_INCLUDE_DIR", "./api/");
include(RDFAPI_INCLUDE_DIR . "RdfAPI.php");
<!--Ici on récupère l'argument URI dans l'URL qui correspond à l'objet du triple RDF, par exemple, http:/dbpedia.org/resource/Tim_Berners-Lee-->
$uri=$_GET['uri'];
<!--J'instancie un appel au serveur SPARQL de Dbpedia-->
	$client = ModelFactory::getSparqlClient("http://dbpedia.org/sparql");
<!--Je demande les résultats au format XML, mais pour l'instant il semble qu'il y a un bug et c'est du HTML zarbi qui est renvoyé-->
	$client->setOutputFormat("xml");
<!--La requête en SPARQL : concrètement, je récupère le résumé en français et le lien vers la page de la wikipedia francophone-->
	$querystring = "
	PREFIX owl: >http://www.w3.org/2002/07/owl#>
	PREFIX xsd: >http://www.w3.org/2001/XMLSchema#>
	PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
	PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
	PREFIX foaf: <http://xmlns.com/foaf/0.1/>
	PREFIX dc: <http://purl.org/dc/elements/1.1/>
	PREFIX : <http://dbpedia.org/resource/>
	PREFIX dbpedia2: <http://dbpedia.org/property/>
	PREFIX dbpedia: <http://dbpedia.org/>
	PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
	SELECT ?hasValue ?wikifr
	WHERE {
	{ <".$uri."> <http://dbpedia.org/abstract> ?hasValue.
	  <".$uri."> <http://dbpedia.org/property/wikipage-fr> ?wikifr
	 }
	FILTER ( lang(?hasValue) = \"fr\" )
	}
	";
	$query = new ClientQuery();
	$query->query($querystring);
	$result = $client->query($query);
	$result="<div>".$result."</div>";
<!--Mise en forme du résultat avec un peu de XPath et simpleXML de PHP5-->
	$xml = new SimpleXMLElement($result);
	if ($xml->xpath('/div/table/tr[2]')) {
		foreach($xml->xpath('/div/table/tr[2]') as $line) {
			echo "<span>".$line->td[0]."</span><br/><a href=".$line->td[1].">En savoir plus</a>";
		}
	}
	else {
		echo "pas d'informations";
	}

Le script Javascript pour l'AJAX est ultra simple (j'ai repris le script AJAX pour débutants ;-) ). Il se contente de ramener la page Web query.php à laquelle je fais passer l'argument URI :

function objAjax(){
	var xhr = null; 
	if(window.XMLHttpRequest) // Firefox et autres
		xhr = new XMLHttpRequest(); 
	else if(window.ActiveXObject){ // Internet Explorer 
		try {
			xhr = new ActiveXObject("Msxml2.XMLHTTP");
		} catch (e) {
			xhr = new ActiveXObject("Microsoft.XMLHTTP");
		}
	}
	else { // XMLHttpRequest non supporté par le navigateur 
		alert("Votre navigateur ne supporte pas les objets XMLHTTPRequest..."); 
		xhr = false; 
	} 
	return xhr
	}
/*** Méthode qui sera appelée sur le click du bouton*/
function go(arg1){
	var xhr = objAjax()
	// On défini ce qu'on va faire quand on aura la réponse
	xhr.onreadystatechange = function(){
		if(xhr.readyState == 1) {
			document.getElementById('reponse').innerHTML="<img src='http://www.lespetitescases.net/images/spinner.gif'/>"
		}
		// On ne fait quelque chose que si on a tout reçu et que le serveur est ok
		if(xhr.readyState == 4 && xhr.status == 200){
			var reponse=xhr.responseText.replace( /\\u0*([0-9A-F]*)/g, '&#x$1;' );
			var reponse=reponse.replace(/\\n/g, '<br/>');
			document.getElementById('reponse').innerHTML=reponse;
		}
	}
	var url="http://lespetitescases.net/essai/rapi/query.php?uri="+arg1
	xhr.open("GET",url,true);
	xhr.send(null);
}

Dans Drupal (je vous laisse adapter en fonction de votre CMS), il faut créer un nouveau bloc que j'ai limité à un billet, pour l'instant, avec ce code dont l'idée est d'analyser le contenu pour trouver les attributs RDFa (dans cet exemple, je me suis contenté de l'attribut rel et de la valeur owl:sameAs) :

if (arg(0) == 'node' && is_numeric(arg(1)) && is_null(arg(2))) {
  //Je récupère l'ID du node
  $nid = (int)arg(1);
  //Je vais récupérer le corps de ce node dans la base de données MYsql	
  $sql = "SELECT title,body FROM node_revisions WHERE nid={$nid}";
  $result = db_query(db_rewrite_sql($sql));
  while ($anode = db_fetch_object($result)) {
    $content=$anode->body;
    $content="<div>".$content."</div>";
    $xml = new SimpleXMLElement($content);
    //Je fais une requête XPath pour trouver tous les noeuds qui comportent l'attribut rel avec la valeur owl:sameAs
    if ($xml->xpath('//node()[@rel="owl:sameAs"]')) {
      echo "<ul>";
	//Pour chacun de ces noeuds, je le mets en forme
      foreach($xml->xpath('//node()[@rel="owl:sameAs"]') as $triple) {
	$url=$triple['href'];
	$string=$triple;
        //Je fais l'appel au javascript en passant en argument l'URI objet.
	echo "<li><a href='#' onclick='go(\"".$url."\")'>".$triple."</a></li>";
      }
      echo "</ul><span id='reponse'></span><br/>";
    }
    else {
      echo "<p>Pas de triplets RDFa dans ce billet</p>"; 
    }
  }
}

Et pour finir, il faut introduire les triplets en RDFa dans votre contenu :

<span id="php" about="#php" rel="owl:sameAs" href="http://dbpedia.org/resource/PHP">PHP</span>

Pour retrouver l'URI, vous pouvez utiliser l'interrogation plein texte de Dbpedia avec bif:contains.

Comment améliorer cette knowledge box ? Je vois plusieurs pistes :

Amélioration du code ;-)
Permettre à l'utilisateur de rapatrier d'autres propriétés, c'est à dire paramétrer la requête SPARQL
Ne pas se limiter à Dbpedia, mais rapatrier des informations contenues dans un fichier FOAF, par exemple, ou dans un autre RDF triple Store
Afficher une carte de Yahoo Maps ou de Google Maps quand le sujet est un lieu
Et toutes vos idées...

Il n'y a pas de licences, vu la bidouille de ce code, mais vous pouvez le récupérer, l'adapter, le triturer, l'améliorer...

Bon amusement !!

PS: j'allais oublier que si quelqu'un veut traduire en anglais ce billet et le précédent, ce sera aussi avec plaisir...

Quelles sont les éléments d'une architecture documentaire ?

got — Sun, 08 Jul 2007 11:20:41 +0200

Dans une organisation, on crée et on échange de l'information. Mais on n'y accède pas de manière uniforme : selon les personnes qui veulent y accéder ou utiliser ces informations, selon leurs différentes fonctions dans l'organisation, ils auront besoin d'y accéder de manière différente, pour des besoins différents. Toutefois, l'information, elle, reste toujours la même : c'est sa présentation et son usage qui change, ce sont les différents services que l'on construit au-dessus de cette information qui doivent changer suivant les besoins.

Comme l'information ne change pas - seuls les usages qu'on en fait changent - on a intérêt à la modéliser correctement. Pour cela, en fonction des différents besoins identifiés, on va définir des types d'information et étudier leur structure de façon à pouvoir les encoder dans la syntaxe la plus appropriée, celle-ci étant indépendante des applications logicielles (au hasard, XML). Toutefois, cette information même structurée ne se suffit pas à elle-même : on a besoin de savoir comment la représenter, et pour cela on a besoin de savoir différentes choses : comment elle a été techniquement structurée, où elle est stockée, qui a le droit d'y accéder, quand et pourquoi, quel est son contenu, quelle est sa relation avec l'information voisine, etc. Tout ce contexte est indispensable à la compréhension et à la représentation de l'information et peut être englobé sous le terme de « description » ou « métadonnées » et on utilise un modèle approprié pour le structurer et l'encoder (au hasard, RDF). L'information, accompagnée de sa description, devient une ressource et il ne nous manque plus qu'un ingrédient pour pouvoir la manipuler dans le système : quelque chose qui va permettre de relier facilement l'information à sa description, des informations entre elles, des descriptions entre elles. Pour cela elles ont besoin de s'interpeller mutuellement, de se nommer, de s'adresser. Bref, il nous faut des identifiants, des URI.

Maintenant il faut bien que cette ressource serve à quelque chose. On va l'utiliser pour répondre aux besoins qu'on avait identifié au début. Ce qui nous importe ici, c'est le message qui circule entre l'utilisateur et les informations elles-mêmes. Ce message doit aussi être exprimé dans une syntaxe indépendante des applications (au hasard, XML) et être véhiculé par un protocole indépendant des applications (au hasard, HTTP). Des services ou plutôt des Web-services (qu'ils suivent le principe de SOAP ou de REST) vont ainsi être créés et, ainsi, alimentés des interfaces pour répondre aux besoins des utilisateurs

Autour de cette architecture, il est à présent possible de déployer des solutions et des interfaces. Mais, en maîtrisant le socle informationnel, vous possédez une indépendance par rapport à la solution implémentée, vous n'êtes pas contraint et si vous devez la modifier, vous garderez la maîtrise de vos données. Par ailleurs, dans ces conditions, un moteur de recherche ou un outil de text-mining s'intégreront beaucoup mieux à cet écosystème informationnel, ils profiteront de la structuration et de la description de l'information et ne seront plus des outils "verrues" et magiques, mais donneront tout leur potentiel.

Finalement, cette logique amène à se poser la question suivante : « dans un système d'information, où se situe la valeur de l'organisation, dans l'information qui le compose ou dans l'application qui manipule l'information ? »

PS : Merci à Manue qui m'a permis "d'accoucher" sans douleur de ce billet, en mettant par écrit une partie de ces quelques idées qui sont autant les miennes que les siennes.

La pelote spéciale RDFa et autres

got — Mon, 04 Jun 2007 20:31:02 +0200

Pour finir (provisoirement) avec les billets sur RDFa, je vous propose une petite pelote sur le sujet qui vous prouvera que c'est la techno qui monte et comme il faut vider l'agrégateur, j'y ajouterai deux-trois autres choses.

Pour ceux qui s'intéressent au RDFa, le site à ne pas louper : RDFa.info, tenu par Ben Adida (que je remercie au passage pour le billet et le commentaire sur ma ch'tite knowledge box), Mark Birbeck, Steven Pemberton et Michael Hausenblas. Ce blog centralise toutes les informations qui sortent à droite à gauche sur le sujet (et du coup, la principale source de cette pelote).

RDFa a fait parler de lui dans les différentes conférences dont je vous ai déjà parlé :

A Xtech 2007, Elias Torres d'IBM a fait le point sur les différentes syntaxes pour embarquer des métadonnées dans du code HTML (microformats, eRDF et RDFa) et sur le GRRDL pour les extraire dans sa communication Open data in HTML
Pour www2007, RDFa.info a relevé toutes les communications qui abordait le sujet. Je vous recommande, entre autres, la lecture du superbe tutoriel de Dan Connolly et Harry Halpin qui, en terme plus geeky qu'Elias, fait un point très complet sur les mêmes sujets et même plus : Deploying Web-scale Mash-ups by linking Microformats and the Semantic Web en deux parties.

Côté implémentation et outils, ça bouge aussi et le mois qui vient de s'écouler a été riche en annonce :

Jena, le framework java pour le Web sémantique soutenu par HP, propose un support de RDFa.
Le support de RDFa pour le langage Ruby on rails
Moins geeky, sur le site du W3C, vous trouverez des bookmarklets en javascript dont une nouvelle version vient d'être publiée et qui permettent de mettre en lumière les RDFa contenus dans une page Web et un nouvel outil qui permet de copier/coller les RDFa sous la forme de triples exprimés en RDF/XML.
Mais, l'annonce la plus importante nous vient de l'inévitable Elias Torres : le support de RDFa par l'extension firefox dédiée aux microformats : Operator. J'attends avec impatience la sortie de la prochaine version pour transférer le principe de la knowledge box sur Operator...

Comme l'a bien dit Alex dans un commentaire du billet précédent, "Reste à simplifier la publication"...

Pour alimenter les métadonnées en RDFa, on pourra compter sur le formidable élan qui est en train de se créer autour du concept de linked data. Le principe est de relier les différents entrepôts RDF, par exemple les données de DBpedia avec les données géographiques de geonames et de naviguer à travers ces différents entrepôts via des navigateurs dédiés comme Tabulator, Disco ou Open link data browser. Danny Ayers et Dan Connolly sont enthousiastes et FOAF dont une nouvelle version vient de sortir rentre dans la danse.

Pour ceux qui ne seraient pas encore convaincus par les technologies liées à RDF et qui auront le courage de lire ce billet jusque là, je vous conseille la lecture de cet interview sur le site d'ARTIST de Yann Nicolas, conservateur à l'ABES et responsable de TEF qui, à la question : « Demain, va-t-on encore évoluer vers de nouveaux standards ou l’un va-t-il s’imposer pour devenir LA norme ? », répond « Sans surprise, je mise sur RDF ».

Sinon, rien à voir, quoique... J'ai été bluffé par une expérimentation du labs de Google signalée par Tim Finin qui permet de consulter les résultats d'une recherche sous la forme d'une frise chronologique ou sur une carte. C'est encore à optimiser, mais c'est prometteur (pas le courage de faire une analyse des implications de cette innovation, d'autres s'en chargeront très bien ;-) ). Il faut l'avouer, ils sont forts quand même chez Google...