Un moteur de transformation RDF basé sur SPARQL

Le Web Sémantique permettra aux applications de communiquer entre elles plus facilement et plus efficacement, en limitant les formats d’échanges, en explicitant la sémantique des informations, en les rendant publiques, réutilisables, etc.

Mais soyons honnêtes, d’un point de vue pragmatique, nous n’y sommes pas encore (et ce n’est pas faute d’évangélisation de notre part !) même si on sent les choses bouger; l’échange de données entre les applications est toujours limité par :

  • la syntaxe des fichiers : le plus souvent du XML, mais combien de fois avons-nous encore à traiter des fichiers textes, des feuilles excel, des dump de base de données ?
  • leur grammaire : quand les fichiers sont en XML, combien n’ont pas de DTD explicite ? et même lorsqu’elle l’est, il existe de toutes façons autant de formats propriétaires qu’il y a de propriétaires… RDF est là pour remédier à ce problème (encore que le problème de sa sérialisation reste entier), et commence à gagner en visibilité;
  • leur sémantique : même en étant optimiste et en supposant que deux applications A et B du même domaine sachent respectivement exporter et importer du RDF, quelle est ma chance qu’elles s’appuient sur la même ontologie ? quand bien même elle partagerait la même ontologie, quelle est mon pourcentage de chance qu’elles l’implémentent de la même façon et avec le même degré de complétude ?

Bref, il nous faut souvent des outils pour arriver « à faire rentrer des trucs carrés dans des trous ronds », ou plutôt « à changer le truc carré en rond pour qu’il puisse rentrer » (*). Si l’on s’arrête au niveau syntaxique et si l’on reste dans le monde XML, ce genre d’outil à un nom : c’est une feuille de style XSL, qui fait schématiquement ça :

XML rond et carré

La feuille de style sait passer du format XML carré au format de XML rond.

Maintenant, y a-t-il des outils ou des technologies pour faire la même chose au niveau du RDF ? c’est-à-dire pour passer d’une grammaire RDF carrée à une grammaire RDF ronde :

rdf rond et carré

Autrement dit, quel est l’équivalent des XSL au niveau du RDF ? je ne vois pas bien; il y a bien des moteurs d’inférence, mais ils ont plutôt pour but de créer de la nouvelle connaissance à l’intérieur d’un même modèle, pas de passer d’un modèle carré à un modèle rond. Qu’est-ce qui peut me faire passer les informations basées sur l’ontologie carrée à des informations basées sur l’ontologie ronde ?…

Partant du principe qu’il y a un vide à ce niveau (mais je serais heureux d’apprendre le contraire), je me propose de le remplir; avec du SPARQL. En effet, le SPARQL permet de requêter du RDF; et non seulement de le requêter, mais encore de construire à partir de celui-ci un autre morceau de graphe. Par exemple, la requête SPARQL suivante :

CONSTRUCT { ?c http://www.cercle.fr/ontology#forme http://www.cercle.fr/ontology#Cercle }
WHERE { ?c http://www.square.com/ontology#shape http://www.square.com/ontology#Circle }

Nous ferait passer d’un RDF qui déclare sa propriété « shape » avec une valeur « Circle » à un RDF qui déclare une propriété « forme » avec la valeur « cercle »; nous permettant ainsi, moyennant un moteur pour l’executer, de passer d’une sémantique à une autre. C’est ce que nous verrons au prochain numéro, avec des exemples d’applications possibles.

—-

(*) : « Well, I suggest you gentlemen invent a way to put a square peg in a round hole. Rapidly. » Les cinéphiles auront reconnu le film « Appollo 13 ».

16 Responses to Un moteur de transformation RDF basé sur SPARQL

  1. bruno dit :

    Effectivement SPARQL peut jouer le rôle d’unification d’ontologies. Par contre il y a un endroit que je trouve pas très clair dans ton post : tu dis qu’avec RDF c’est génial, on est plus limité par la grammaire comme on l’est avec XML où il y a une multitute de DTD. Mais l’ontologie est au RDF ce que la DTD est au XML… non? D’ailleurs dans ta comparaison avec les carrés et les ronds tu compares DTD et ontologies en disant pour passer d’une DTD à une autre tu utilises XSL et pour passer d’une ontologie à une autre tu utilises SPARQL : donc grammaires et ontologies même combat?

    Ca à part, un aure point : SPARQL a beau permettre d’unifier les vocabulaires, on retombe toujours sur le même problème : pour paraphraser ce post http://www.christian-faure.net/2007/10/31/comment-nettoyer-les-ecuries-daugias/trackback/ , “Si tu as de la merde en bas, t’auras de la merde en haut” : c’est toujours le bordel pour unifier sur la valeur des propriétés. Si dans un graph1 j’ai une propriété vocab1:country avec comme valeur « USA » et dans un graph2 une propriété vocab2:country avec comme valeur « United States » , SPARQL me permet de dire que vocab1:country=vocab2:country mais je ne vais pas pouvoir joindre pour autant mes graphs sans une bidouille.

  2. bruno dit :

    Une dernière question que je me pose : SPARQL permet de joindre des sources de données hétérogènes facilement. Un retour sur une comparaison avec XQuery, un petit exemple? 😉

  3. Oui, c’était bien ce que je voulais dire : l’ontologie est au RDF ce que la DTD est au XML, d’où la volontaire similitude entre les 2 schémas. Alors oui, ontologie et DTD même combat, sauf que la DTD, c’est pour la syntaxe, et l’ontologie, pour la sémantique (et ce indépendamment de la syntaxe sous-jacente).

    Maintenant, l’unification de « USA » et « United States » ne revient pas vraiment à traiter de la merde (puisque ces deux libellés sont corrects, si l’on exclu la remarque des puristes qui diront qu’il manque le « … of America », mais bref.); là il s’agit plus d’une problématique d’_unification du référentiel_, et ça ne peut se faire que via un référentiel où l’on a dit que « USA », « United States » et « United States of America » désignait la même chose. Ce référentiel va aller alimenter les outils de text mining et va aider à construire les requêtes SPARQL de rapprochement. D’où l’utilité du référentiel dans les problématiques web 2.0 (et le bonjour à CF au passage).
    Maintenant, si on voulait traiter des libellés avec des fotes d’orthographe, là oui, on pourrait se poser la question de comment faire. Ceci dit, dans le monde RDF, l’idée est que tout soit le plus normé et identifié possible, alors la question se pose : doit-on supposer qu’on puisse traiter du RDF non seulement avec des resources enregistrées comme des chaines de caractères, mais également pouvant parfois être mal orthographiées ?

    Je ne suis pas suffisamment familier avec XQuery pour pouvoir faire un lien avec SPARQL – mais si vous avez un éclairage, il est le bienvenu ici !

    Thomas

  4. bruno dit :

    « …Alors oui, ontologie et DTD même combat, sauf que la DTD, c’est pour la syntaxe, et l’ontologie, pour la sémantique (et ce indépendamment de la syntaxe sous-jacente)… » : La DTD apporte aussi une sémantique pour moi…. Les tags XML apporte une sémantique… Bref toujours pas clair pour moi ce paragraphe. Mais bon je chipote certainement… Mais c’est pour ça que je ne comprends la phrase où il est dit que RDF est la pour remédier au pb de la grammaire…

    « …à il s’agit plus d’une problématique d’_unification du référentiel… » : on est bien d’accord… ce problème est récurrent…. pas de recette miracle.

    « …Ceci dit, dans le monde RDF, l’idée est que tout soit le plus normé et identifié possible,.. » : oui mais la grande majorité des sources de données ne sont pas RDF, loin de là. On est dans un monde où pour voir ces concepts de sémantisation émerger, il faut travailler avec des source de données legacy (SGBDR,…) et les abstraire par une vue RDF. C’est pour ça que je trouve fort intéressants les produits qui font ce mapping (D2RQ, etc…)

    « …Je ne suis pas suffisamment familier avec XQuery pour pouvoir faire un lien avec SPARQL – mais si vous avez un éclairage, il est le bienvenu ici !… » : non justement… 😦 ou alors pas suffisant d’où ma question. Je cherche notamment à savoir si l’avantage de SPARQL pour faire des jointures en est vraiment un par rapport à XQuery… Mais peut que l’avantage de SPARQL réside dans ce cas ailleurs.

  5. « La DTD apporte aussi une sémantique pour moi…. Les tags XML apporte une sémantique… »

    -> Oui, mais leur sémantique est implicite, nulle part on n’écrit qu’un tag qui s’appelerai <personne> contient le nom d’une personne

    « Mais c’est pour ça que je ne comprends la phrase où il est dit que RDF est la pour remédier au pb de la grammaire… »

    -> c’est vrai, ce n’est pas clair. Il vaut mieux lire « RDF + OWL sont là pour remédier à ce problème… »

    « oui mais la grande majorité des sources de données ne sont pas RDF, loin de là. On est dans un monde où pour voir ces concepts de sémantisation émerger, il faut travailler avec des source de données legacy (SGBDR,…) et les abstraire par une vue RDF. C’est pour ça que je trouve fort intéressants les produits qui font ce mapping (D2RQ, etc…) »

    -> tout à fait d’accord là dessus – D2RQ, ca à l’air intéressant ça. Notre approche consiste plutôt à traiter les contenus non-structurés pour les intégrer dans des bases RDF (avec des mécanismes de mapping), plutôt que de faire le mapping au moment de la requête.

  6. bruno dit :

    « Oui, mais leur sémantique est implicite, nulle part on n’écrit qu’un tag qui s’appelerai contient le nom d’une personne »

    => ah. et c’est pas la même chose avec un vocabulaire RDF style FOAF? Foaf:name qui t’as dit que c’était le nom d’une personne? Enfin si quelqu’un te l’as dit, mais cette information n’est pas dans le prefixe , pas plus qu’elle n’est dans le tag . Libre à moi de mettre n’importe quoi . Je vois pas en quoi OWL apporte plus de sémantique que une DTD? Si je te dis que pour décrire le réseau social de mon entreprise, tu dois le faire en utilisant cette DTD, je te donne autant d’infomation que si tu me dis que je dois utiliser cette ontologie non? Ok je t’impose un format de sérialisation (XML) alors que toi non, mais c’est tout. La sémantique n’est pas plus forte avec OWL que une DTD tu ne penses pas?

  7. « Je vois pas en quoi OWL apporte plus de sémantique que une DTD? Si je te dis que pour décrire le réseau social de mon entreprise, tu dois le faire en utilisant cette DTD, je te donne autant d’infomation que si tu me dis que je dois utiliser cette ontologie non? »

    => L’ontologie, vue comme un contrat social, mets d’accord plusieurs parties sur les messages qu’elles s’échangent. De ce point de vue, il n’y a rien de nouveau par rapport au fait de se mettre d’accord sur une DTD d’échange, ou de se mettre d’accord sur les séquences d’octets d’un fichier binaire. Dans ces trois cas, on se met d’accord sur quelque chose à échanger.

    « Ok je t’impose un format de sérialisation (XML) alors que toi non, mais c’est tout. La sémantique n’est pas plus forte avec OWL que une DTD tu ne penses pas? »

    => L’ontologie propose une modélisation indépendamment d’une sérialisation. L’ontologie permet de se coupler avec des outils de raisonnement pour inférer de nouvelles connaissances. La couche RDF/OWL modélise des graphes sémantiques abstraits, ce qui me permet de faire des opérations directement sur le graphe sans me soucier de la sérialisation, comme supprimer des arcs ou des resources, fusionner plusieurs graphes RDF en un seul (via des API comme Sesame), etc. cf la littérature sur le sujet et la fameuse « pyramide des technologies » du web.
    => Il ne faut pas confondre « sémantique » et « expressivité du langage ». L’expressivité de OWL et de XML Schema – je pense, mais peut-être m’avance-je un peu – est sans doute équivalente (alors que les DTD sont plus limitées en terme d’expressivité). Seulement, ces 2 langages ne se placent pas sur le même plan : l’un (XML schema), définit une structure de fichier d’échange, l’autre (OWL) définit une structure de connaissance (qui se traduit effectivement par une/plusieurs sérialisation(s) de fichier d’échange, mais l’intérêt de OWL va justement au-delà de ça, cf § précédent).
    => Maintenant, qu’appelle-t-on sémantique ? La sémantique est-elle dans les données ou dans l’interprétation qu’on en fait ?

  8. bernard dit :

    « La sémantique est-elle dans les données ou dans l’interprétation qu’on en fait ? »
    Bien sûr, la sémantique apparait uniquement dans un contexte d’interprétation. Et les données ne sont finalement que des données, comme je l’ai écrit ailleurs il y a quelque temps[1]. Essayez d’utiliser votre numéro de carte de crédit dans un pays sans banque…
    Cela dit, on a quand même avec la pile RDF-OWL une notion de sémantique formelle, c’est-à-dire pas seulement la notion de données valides par rapport à un schéma, mais comme le dit Thomas, de données cohérentes ou non, d’inférence, de classification automatique etc. Bref on passe du niveau valide/invalide par rapport à un schéma au niveau vrai/faux dans un contexte, cohérent/incohérent.
    Ce qui est aussi très important, c’est la généricité du modèle de graphe RDF qui permet de fusionner ou requêter des données sans savoir a priori à quelle ontologie elles sont conformes.

    [1]http://universimmedia.blogspot.com/2007/04/journey-to-data-mountains_24.html

  9. bruno dit :

    « Cela dit, on a quand même avec la pile RDF-OWL une notion de sémantique formelle, c’est-à-dire pas seulement la notion de données valides par rapport à un schéma, mais comme le dit Thomas, de données cohérentes ou non, d’inférence, de classification automatique etc. Bref on passe du niveau valide/invalide par rapport à un schéma au niveau vrai/faux dans un contexte, cohérent/incohérent. »
    => mouai…
    vous êtes en train de justifier RDF/OWL par les applications (le contexte) qui est autour… Rien n’empecherait d’avoir de l’inférence, de la classification sur du XML. Si on en revient aux fondamentaux, en se débarassant de la sérialisation : est ce qu’un graphe est plus puissant qu’un arbre. Est ce que la différence réside là? Pour moi, une ontologie ou un schéma définissent une sémantique…. Ok, je pense que XQuery lie peut être de trop près dans une requête la sémantique à la syntaxe XML du document cible, de même qu’un langage de règles sur des sources XML serait peut être trop lié à la structure (XML) des documents sources. Mais quand on y pense le pb c’est pas XML dont on parle. C’est une structure en arbre non? Ce que vous voyez dans vos requêtes , vos documents, c’est cette structure hierarchique très apparente en XML? non? Un graphe est mieux qu’on arbre? Plus simple à manipuler? Bref quand vous parlez de sémantique beaucoup plus explicite, il me semble que vos arguments ne parlent que de graphes et d’arbres… Bref je suis pas convaincu. Ne vous braquez pas, je ne suis pas contre RDF/Sparql au contraire. C’est plus simple à manipuler à conceptualiser on est d’accord. Mais cette sémantique ,…, est elle vraiment plus forte? Si elle est plus forte que par les applications qui se sont construites autour, et qui sont absentes autour d’XML, ok c’est une bonne raison, mais … ca me laisse un goût amer. Il faut bien qu’il y ait des standards mais je préfère quand ils s’établissent parce que conceptuellement c’est plus beau… je suis clair?

    « Ce qui est aussi très important, c’est la généricité du modèle de graphe RDF qui permet de fusionner ou requêter des données sans savoir a priori à quelle ontologie elles sont conformes. » => quoi?? fusionner peut être mais requêter et à fortiori joindre alors là j’ai un sérieux doute. A part si pour vous une requête c’est tout récupérer sans aucune contraintes? Dans la moindre requête SPARQL cohérente, il y aura un prédicat de précisé, et donc la notion d’ontologie est obligatoirement connue.

  10. bruno dit :

    autre version :
    si conceptuellement je peux faire la même chose en XML et RDF, le seul avantage réside dans les outils qui vont exploiter ces données. Si, parmi ces outils, on prend le langage de requêtes, si une requêtes SPARQL n’est pas plus simple (entre autres) qu’une requête XQuery, alors quoi? ca veut dire que je pourrais bâtir les mêmes applications à partir de ces outils dans n’importe quelle techno. Dans ce cas, on en est réduit à justifier une techno par une autre seulement par la « hype » qui est autour?!? Je sais que ce n’est pas le cas pour RDF, mais je n’arrive pas à voir la justification dans vos réponses.

  11. bruno dit :

    un exemple autour de la recherche:
    j’ai 2 sources de données une en XML et l’autre une BD.
    La première contient les chiens et leurs propriétaires, la deuxième contient les propriétaires et leurs adresses. Je veux une requête qui va me retouner les chiens et leurs adresses. Je prends la piste sémantique, j’abstrait mes deux sources en XML, je taggue mes données avec des balises, ca leur donne une sémantique. 2 sources de données, 2 DTD. Je fais une requête XQuery, j’obtiens des résultats conforme à une 3ième DTD, une 3ième sémantique. Vous faîtes la même chose en remplaçant, XML par RDF, XQuery par SParql et DTD par ontologie. C’est plus simple? Le premier cas était pas possible , moins valable, moins adapté, que le second? Pourquoi? J’ai parlé de sémantique, de partage de données, d’ouverture, dans les 2 scénarios. Je suis pas suffisament ouvert c’est ça? Alors on en revient à mon doute sur la justification par l’adoption…

  12. Bon, décidément cette discussion promet d’aller au fond des choses…

    « vous êtes en train de justifier RDF/OWL par les applications (le contexte) qui est autour… »

    => Non, relisez mon post original, je dis qu’il me semble manquer l’équivalent d’une techno de transformation XSLT dans le monde RDF.

    « Rien n’empecherait d’avoir de l’inférence, de la classification sur du XML. »

    => bien sûr, tout comme rien n’empecherait d’avoir de l’inférence sur de simples chaines de caractères ou sur de simples séquences d’octets si ca nous amusait. Le point est que OWL (puisque c’est de OWL qu’il s’agit) a _prévu_ nativement un support pour l’inférence dans la norme, en se basant sur les ensembles et la logique du premier ordre. Ce qui permet à des moteurs d’inférence de manger du RDF et du OWL et d’inférer de nouvelles informations. XML ne prévoit pas ce support.

    « Il faut bien qu’il y ait des standards mais je préfère quand ils s’établissent parce que conceptuellement c’est plus beau… je suis clair? »

    => c’est le point de RDF, qui normalise une structure de graphe _abstraite_, encore une fois indépendemment de la sérialisation. C’est conceptuellement « un cran au-dessus » de XML. Mais RDF seul est très « bas niveau », et très générique. Pris seul (sans OWL), c’est « juste » un formalisme de représentation de graphes.

    « à part si pour vous une requête c’est tout récupérer sans aucune contraintes? Dans la moindre requête SPARQL cohérente, il y aura un prédicat de précisé, et donc la notion d’ontologie est obligatoirement connue. »

    => Non : RDF tout seul (sans OWL, sans ontologie) manipule des prédicats et des URIs. Je peux traiter et interroger des graphes RDF sur certains prédicats, sans que de mon côté je ne manipule d’ontologie, ni sans connaître l’ontologie à laquelle se conforme le graphe RDF.

  13. « ca veut dire que je pourrais bâtir les mêmes applications à partir de ces outils dans n’importe quelle techno. Dans ce cas, on en est réduit à justifier une techno par une autre seulement par la “hype” qui est autour?!? Je sais que ce n’est pas le cas pour RDF, mais je n’arrive pas à voir la justification dans vos réponses. »

    => J’essaie de résumer les choses :

    – RDF formalise la façon d’exprimer des graphes conceptuels. Il n’a pas de sérialisation canonique (ce qui pose un certains nombre de problèmes). Son avantage sur XML est qu’il est indépendant de la sérialisation.
    – Donc, de ce point de vue, vous pourriez effectivement « bâtir les mêmes applications à partir de ces outils dans n’importe quelle techno ». Si je peux m’avancer sur un exemple : si vous aviez un fichier de configuration pour une application (tout à fait propriétaire à votre application, et que vous n’avez pas à échanger avec le monde extérieur), et que vous deviez parser, lire et éventuellement écrire ce fichier, vous pourriez très bien le faire en XML + Xpath/XQuery ou en RDF + SPARQL; à part que XML vous force à sérialiser d’une façon canonique, ca ne ferait pas de différences.
    – Maintenant, OWL exprime des contraintes et des règles sur un graphe RDF. Pour continuer sur l’exemple, si vous aviez une ontologie qui décrivait ces contraintes pour votre fichier de configuration, cela permettrait à un moteur d’inférence de calculer la valeur de certaines propriétés en fonction d’autres, ou à un moteur de règles de pouvoir contrôler si votre fichier est cohérent.

  14. « Je prends la piste sémantique, j’abstrait mes deux sources en XML, je taggue mes données avec des balises, ca leur donne une sémantique. »

    => C’est important de comprendre que cela ne leur donne une sémantique (un sens) que parce que vous êtes capable de comprendre ce que signifie, ce que représente, la DTD (« La sémantique apparait uniquement dans un contexte d’interprétation »). Le locuteur chinois avec qui vous devriez échanger ce flux XML en serait-il capable ? un OWL aurait par exemple permis de manipuler des concepts, et d’y accrocher des traductions dans différentes langues. Le nomade saharien, pour qui la notion d’adresse n’a pas de sens, en serait-il capable ? un OWL aurait par exemple permis d’exprimer votre ontologie par rapport à son ontologie, en disant que « adresse », hé bien, c’est comme l’endroit d’un campement de caravane, mais avec une durée illimitée… (désolé pour l’exemple stupide).

    « Vous faîtes la même chose en remplaçant, XML par RDF, XQuery par SParql et DTD par ontologie. C’est plus simple? »

    => Non, compte-tenu du niveau de maturation des outils, ce serait plus compliqué.

    « Le premier cas était pas possible , moins valable, moins adapté, que le second? Pourquoi? »

    => Pas du tout.

    « J’ai parlé de sémantique, de partage de données, d’ouverture, dans les 2 scénarios. Je suis pas suffisament ouvert c’est ça? »

    => Pas du tout. Il s’agit cependant de clarifier ce qu’est une sémantique. Et il ne s’agit pas de jeter XML à la poubelle, mais de comprendre les différences entre le monde XML et le monde RDF.

  15. […] le contenu de Wikipédia avec SPARQL Pour prolonger le débat récent entre Thomas et Bruno sur RDF et XML, un petit exemple illustrant le fait que SPARQL permet de […]

  16. […] moteur de transformation RDF basé sur SPARQL (2) [la suite du billet précédent sur le manque d’outil pour effectuer des transformations sur un graphe RDF, et la pertinence […]