Les petites cases

Stocker les triples

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 :

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 :

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.

RDF Sparql Geekeries — 

Commentaires

IMHO il manque un triple-store léger et facile à mettre en place. J'ai n'ai fais que survoler les différentes solutions listées sur ESW mais j'ai l'impression que l'on tombe à chaque fois sur un truc "bloated", complètement inutile/inutilisable dans le cadre de petites applications.
Tu es un peu dur, je te conseille de jeter un coup d'oeil à ARC ou RAP qui répondront à mon avis à tes attentes.
Yep, pour confirmer ce que dit got, un entrepôt s'installe avec RAP en une dizaines de lignes de PHP. Sinon, une lib python comme librdf propose aussi un petit moteur de stockage sur disque. Mais je pense qu'une chose importante à prendre en compte, outre les performances brutes en terme de requête, est la capacité d'inférence de ces différents entrepôts, qui est assez variables selon les approches (de rien (Boca) à la gestion de certaines propriétés OWL (Allegro) en passant par la gestion des sous-classes / sous-propriétés (3store) ). Parce que stocker du RDF "brut", c'est bien, mais avec un système capable de prendre en compte les spécificités des ontologies utilisées pour décrire ces triplets, c'est encore mieux :)
En fait les équipes qui développent des triple-stores utilisent en général le benchmark LUBM qui teste à la fois des vitesses de chargement, de requête, et leur exactitude en terme d'inférence. Dans la liste des repositories basé sur RDBMS, j'ajouterai Minerva ( http://www.springerlink.com/content/k8tnmw751g375544/ )/ SOR développé par une équipe d'IBM qui est aussi très prometteur...
@JSB : Merci pour l'indication, j'avais loupé cette référence essentielle. Concernant SOR, si vous avez plus d'informations, je suis preneur, je n'ai rien trouvé de bien probant pour le moment, sinon j'attendrais qu'IBM nous en dise plus ;-)
L'ancienne version (qui date un peu) est dispo sur alphawork : http://www.alphaworks.ibm.com/tech/semanticstk Sinon j'avais testé la dernière version sur plus de 100 millions de triple dans une utilisation assez industrielle et c'était très prometteur. Une (très) petite description sur http://www.vldb.org/conf/2007/papers/demo/p1402-lu.pdf
@JSB : Merci pour ces renseignements, n'hésite pas si tu as des nouvelles, je suis intéressé.
nous avons décris RFD dans un annuaire LDAP et nous l'avons chargé avec toute la nomenclature d'un Conseil Général. Une application JAVA reposant sur JNDI permet de la maintenir et de l'interroger. Les performances sont excellentes. Un web-services permet aux applications d'utiliser ce référentiel. Un annuaire LDAP/X.500 de type hiéarchique peut être une solution.
Bonjour, Je suis très intéressé par ce que je lis depuis quelques temps, ici ou ailleurs, sur le web sémantique. Je cherche à créer une activité professionnelle prenant la forme d'un site internet, et dans laquelle l'indexation d'images a une grande importance (en vue de permettre aux internautes de trouver celles qui leur conviennent aussi facilement que possible). Aussi, quitte à devoir passer beaucoup de temps a indexer les images (dans une base de données et non pas au sein des images elles-mêmes, je le précise), je me suis dit qu'il fallait pouvoir en tirer le maximum. Et de ce point de vue, la découverte de RDF m'a ouvert pas mal de possibilités, a fortiori lorsqu'il est structuré via une ontologie OWL en vue de permettre des inférences via SPARQL. La lecture de votre billet et de ses commentaires me conforte dans l'idée que tout cela manque encore un peu de maturité - y compris, et peut-être d'abord, ma propre compréhension des techniques sous-jaçentes et de tout ce qu'elles impliquent. Je ne suis donc pas loin de conclure que la création d'un SGBD en PHP/MySQL (ce sera au moyen du CMS Drupal 6) fera l'affaire dans un premier temps. Toutefois, j'aimerais recueillir svp vos conseils concernant la structuration d'un tel SGBD, en vue d'utiliser aussi pleinement que possible les ressources du web sémantiques un peu plus tard. Puis-je dores et déjà structurer ma BD de telle sorte qu'elle soit "owl/rdf compatible" puis, ultérieurement, pleinement interrogeable via sparql ?