Les petites cases

Limites du modèle relationnel et Web sémantique

Non ! ce blog n'est pas mort comme tant d'autres, mais je ne trouve tout simplement pas le temps de bloguer en ce moment. Pourtant, ce n'est pas les sujets qui manquent, d'autant que chaque jour nous apporte son lot de bonne nouvelle sur le front du Web sémantique.

Pour me faire pardonner et vous faire patienter, je vous propose le diaporama d'une communication que j'ai faite avec mon excellent collègue, Alexandre Bertails, alias betehess, alias l'homme qui résout les sudokus avec OWL, alias l'homme qui murmure à l'oreille de Pellet, à l'occasion de la conférence "Web version 2 et suivantes" dans le cadre de Solution Linux. L'objectif de cette présentation était de montrer en quoi les technologies du Web sémantique constituent des réponses à certaines limites du modèle des bases de données relationnelles et donc en quoi elles peuvent avoir leur place dans les systèmes d'information traditionnelles. Je pense que certains lecteurs de ce blog pourront ainsi mieux se rendre compte de l'apport des technologies du Web sémantique pour la gestion des données structurées.

Bonne lecture !

RDF Système d'information Sparql OWL Geekeries Linked Data — 

Commentaires

J'ai un doute sur l'avantage de fusion de la donnée et de sa structure.


Si j'ai bien compris, la forme predicat-sujet-objet permet d'empaqueter la donnée et son "type".

J'y vois deux limites :

  1. il faut bien que le type soit défini quelquepart pour savoir quoi en faire
  2. il ne faut pas que ce même type soit défini différemment chez le voisin.

Un Diktat mondial de la nomenclature des types de données est-il un prérequis à l'interopérabilité du web sémantique ?
Si non, comment s'en passer ?

Sinon deux petites remarques :

  • Slides 18 : "[Le modèle relationnel] induit les relations et n'offre pas un système claire d'identifiants"
    Le "e" à la fin de clair.
  • Et sur toute la première partie je trouve ambiguë l'utilisation du terme "relation" qui a une signification particulière quand on parle de modèle relationnel (relation=table, et pas le "lien" entre deux tables).

Tout d'abord, merci pour ta question, elle est essentielle, source de nombreuses confusions et d'incompréhensions sur le principe du Web sémantique.

En exprimant le prédicat dans le triplet, c'est-à-dire la propriété qui relie la ressource à la donnée, le triplet est indépendant et la relation entre la ressource et la donnée est clairement exprimée. Effectivement, le fait qu'un type de ressource est relié à un autre type de ressource ou à une donnée (par exemple une chaîne de caractère) doit être exprimée d'une manière ou d'une autre pour permettre aux machines de comprendre la nature de la relation. C'est précisément le rôle des vocabulaires RDF ou ontologies exprimées avec RDFS ou OWL, comme FOAF, SIOC ou Dublin Core par exemple, de définir des classes (= des types de ressources) et des propriétés (= les prédicats). Mais, dans le cas des technos du Web sémantique, la définition du vocabulaire est indépendant de l'expression du triplet, alors que dans une BDR la structure et la donnée sont définies dans un même ensemble, la base, mais en revanche, la structure et la donnée ne sont pas directement reliée, la relation au sens strict du terme (pas au sens BDR que tu rappelles à la fin de ton commentaire) est induite par l'organisation tabulaire des données.

Concernant l'impression d'un Diktat, il n'en est rien. Le Web sémantique en lui-même n'oblige pas à utiliser tel ou tel vocabulaire pour structurer les données. Il est tout à fait possible de créer son propre vocabulaire, de définir ses propres classes et ses propres propriétés. Mais, dans ce cas, l'interopérabilité ne sera garanti qu'au niveau du modèle (RDF) et non au niveau des données, c'est-à-dire qu'un outil capable de comprendre qu'une ressource de type foaf:person est une personne ne sera pas capable de comprendre qu'une ressource de type toto:personne est une personne.
Néanmoins, tout n'est pas perdu pour autant, il est, en effet, tout à fait possible d'exprimer dans le vocabulaire que ta classe toto:personne est équivalente à la classe foaf:person ou est une sous-classe de foaf:person. Dans ce cas, l'outil sera capable en analysant ton vocabulaire RDF de déduire (=de faire une inférence) que ta ressource qui est de type toto:personne est aussi du type foaf:person. Il pourra même le faire automatiquement si les URL que tu as indiqué dans ton RDF sont déréférençables, c'est-à-dire accessibles.

L'interopérabilité est donc plus souple à gérer avec le modèle RDF qu'avec le modèle XML qui impose l'utilisation stricte d'un même schéma pour gérer l'interopérabilité. Le but du Web sémantique n'est donc pas, comme le croient certains, d'imposer une vision du monde. Il offre, si on le souhaite, des mécanismes d'interopérabilité à plusieurs niveaux (le premier étant situé au niveau d'un modèle commun : RDF). Charge ensuite à chacun en fonction de sa culture, de ses données, de sa compréhension du monde d'utiliser des vocabulaires existants, c'est-à-dire de partager la même vision du monde qu'un autre groupe de personnes, ou pas.

Si cette vision sera sans doute très complexe à mettre en place au niveau du Web dans son ensemble, il est, en revanche, moins complexe (quoique...) de le mettre en place au niveau d'un SI et, ainsi, d'assurer l'interopérabilité entre des données liées et réparties entre plusieurs bases de données, ce qui est actuellement complexe à mettre en place, à moins d'en passer par des outils du type ETL ou Master data management.

Est-ce-plus clair, ainsi ? Ai-je répondu à tes interrogations ?

Merci pour les remarques. Concernant le mot "relation", je n'avais pas conscience de l'ambigüité, il nous faudra trouver un autre terme ou bien expliquer ce que nous entendons par l'utilisation de ce mot.

PS : de quel Aurélien s'agit-il ? Je n'avais pas d'adresse électronique associée :-(

Quelques petite remarque de rabat joie (même si je partage en grande partie les idées avancées dans la présentation):
  • L'évolution des données est certes plus simple avec le web sémantique, mais le principal obstacle dans ce genre de cas, même avec une base de données relationnelle, n'est pas au niveau de la couche de données mais au niveau de la couche d'applications. J'ai parfois l'impresison que le changement plus souple proposé par le web sémantique pourrait être contre-productif: là où mon application crashait si elle n'était plus adaptée, elle peut se contenter de renvoyer des résultats erronés (cette remarque est basé sur les slides 10 et 11)
  • Les liens entre les tables présentés au slide 14 sont discutables: la structure d'une base de données ne se résume pas à la représentation sous formes de tables, les contraintes et les déclarations de clés étrangères font aussi parti de la structure. Pour aller un peu plus loin, en se basant sur le slide 15, on peut faire le même reproche aux données liées par un "sameAs" dont on aurait laissé de coté l'ontologie. (Je pinaille là, car il est vrai que les choses sont quand même nettement plus explicite avec le webSem)
Dis comme ça, le commentaire sonne peut-être comme un peu trop négatif, je tiens donc à répéter que je suis globalement d'accord avec toi.

Toute critique est bonne à prendre quand elle est constructive ;-) Donc pas de problèmes.

Concernant ta première remarque, est-elle liée au fait qu'il n'y a a priori pas de vérification de contrainte d'intégrité au moment de l'indexation dans un triple store ? C'est effectivement une limite actuelle. Pour autant, il est possible avec les raisonneurs d'ajouter une couche de vérification de contraintes avant indexation. Maintenant, il est clair que cela ne résout pas tous les problèmes. On perd en contraintes ce qu'on gagne en souplesse. Par ailleurs, si les technos du semWeb permettent de diminuer l'adhérence entre la couche des données et la couche applicative (ce qui est selon moi un avantage), je me rends compte que cela déstabilise certains développeurs et demande effectivement une plus grande rigueur sur les deux couches.

Concernant ta seconde remarque, je confirme "tu pinailles" ;-) Tu le dis toi-même les contraintes et autres clés étrangères sont dans la structure. Or, si tu exportes les données de ta base, tu perds ces informations (à moins d'exporter en SQL, mais on sait ce qu'il en est de l'interopérabilité de SQL...). Avec les technos du semWeb, ces informations sont directement dans les données. Quant à l'ontologie, elle est elle-même exprimée avec le même modèle de données, soit RDF, autre avantage sur les bases de données relationnelles. Qu'en penses-tu ?

Sur le premier point, mon problème ne venait pas de l'indexation mais de la lecture. Reprenons le cas des représentants des athlètes des slides 10 et 11: j'ai un seul représentant, il est dans la table cérémonie, (ou dans un triplet adéquate P R O1) tout va bien.
Je constate maintenant que j'ai besoin de plusieurs représentants, je modifie la structure de mes tables (le schéma du slide 11), les accès à mes données de la base relationnelles sont modifiés, les tests de mes applications hurlent qu'il est temps de les modifier.
Si je veux avoir une représentation correspondante avec mes triplets, soient j'ajoute un nouveau triplet pour le nouveau représentant et mes applications ne bronchent mais risquent de ne rechercher qu'un représentant, soit j'indique que la propriété représentant doit mener à un ensemble de ressources et le comportement est le même que pour une base de données relationnelle (avec quasiment les mêmes problèmes de souplesse).
Maintenant, il y a peut-être une 3e solution qui m'échappe.

Sur le deuxième point, je suis totalement d'accord avec toi sur l'apport des ontologies par rapport aux bases de données classiques, notamment si met en perspective l'utilisation ORM basé sur ces ontologies, on obtient alors un ensemble données plus classes permettant d'utiliser ces données beaucoup plus cohérent que ce qu'on peut construire avec les bases de données relationnelles, où le lien objets/données est plus artificiel. Idem sur la facilité d'export/import avec des données du semWeb. Ce qui me gêne, c'est la phrase "La nature de la relation n'est exprimée clairement ni dans la structure, ni dans la donnée" (slide 14) qui est fausse à mon avis : avec la structure et la donnée, on recrée les liens. Le désavantage par rapport au semWeb est qu'il est justement nécessaire d'avoir la structure et les données pour retrouver la relation, là où les données du semWeb suffisent à elles même.

Je ne suis pas d'accord avec ta phrase "si [on] met en perspective l'utilisation [d'un] ORM basé sur ces ontologies, on obtient alors un ensemble données plus classes permettant d'utiliser ces données beaucoup plus cohérent que ce qu'on peut construire avec les bases de données relationnelles, où le lien objets/données est plus artificiel."

En effet, le mapping Object-Relationnel est particulièrement cohérent dans le sens où :
- une classe correspond à une relation (appelée courament "table) ;
- les champs de la relations correspondent aux variables de la classes ;
- un objet correspond exactement à une entrée dans la table.

Le modèle objet (pur) est très peu adapté à un mapping avec RDF. Autant tu retrouves la notion de classe, autant tu perds toute la capacité à modéliser des propriétés : non, les variables et/ou méthodes ne suffisent pas. Pour cela, il faudrait pouvoir manipuler les fonctions plus finement et les rendre disponibles en tant qu'objet de première classe. Je pense qu'un language comme Scala pourrait offrir ça mais surtout pas Java. Enfin, pour manipuler les contraintes, je pense que jouer avec les annotations ferait l'affaire, mais plus dans l'esprit des décorateurs de Python où il s'agit de modifier le comportement d'une méthode et non d'une classe.

C'est vrai que c'était un peu péremptoire comme affirmation. Disons que le lien entre ontologie et classe me semble plus clair que celui table / classe. Je crois que contrairement aux ORM classiques, le mapping dans le cas du semWeb n'est pas une ressource = un objet mais plutôt une ressource = plusieurs objets, en fonction du cadre de l'utilisation des ressources. Bien sûr on est loin de la représentation souple d'une ressource telle qu'on l'a en RDF. Pour revenir à la manipulation de contraintes, oui, les décorateurs en Python, ou encore les solutions d'Aspect Oriented Programming peuvent être des solutions. Cela fait remonter mes vieux fantasmes de langages orientés semWeb, où l'on pourrait associer des fonctions business à des ontologies, mais je m'égare...

Cela fait remonter mes vieux fantasmes de langages orientés semWeb, où l'on pourrait associer des fonctions business à des ontologies, mais je m'égare...

Pas tant que ça :) Car je pense que le problème est bien là. Et c'est pour ça que je regarde depuis quelques temps du côté de Scala, qui pourrait être le langage le plus adapté pour résoudre ce genre de problématique ! En plus, on garde le bénéfice des frameworks Java déjà développés et utilisés tels que Jena ou Sesame...

Marier aussi bien les aspects Objet et Fonctionnel fait réellement fantasmer. Je rêve en particulier d'une intégration aussi parfaite que celle du XML :)

L'intégration dont tu parles est intégrée dans la spécification même de Scala, et donc difficilement reproductible pour le RDF. Pour le reste, même si Scala a effectivement beaucoup d'avantage, jai du mal à saisir les avantages que tu lui trouves dans ce cas précis.

L'intégration dont tu parles est intégrée dans la spécification même de Scala, et donc difficilement reproductible pour le RDF.

Oui c'est vrai. Cela dit, ne n'est pas impossible de le faire !

Pour le reste, même si Scala a effectivement beaucoup d'avantage, jai du mal à saisir les avantages que tu lui trouves dans ce cas précis.

Il s'agit simplement du fait que les fonctions dans Scala sont des éléments de première classe, contrairement à la plupart des languages orientés objet (genre OCaml). Cela pourrait permettre de remettre sur un pied d'égalité les classes et les propriétés du monde du web sémantique.

Quelqu'un aurait-il un lien vers une version téléchargeable de cette superbe présentation ?
Merci pour votre intérêt ! Cette présentation n'est pas disponible au téléchargement à cause des droits sur les logos d'Atos Origin. Vous pouvez en revanche reproduire les slides (sans les logos ;-) ) avec mention des auteurs.