Re: Virtuoso versus Sesame
Jean-Marc Vanel
Google, pour lequel vous avez reçu une invitation.
Il me reste à savoir si Virtuoso fait effectivement les requêtes CONSTRUCT....
Le 21 octobre 2009 14:52, Olivier Rossel <da...@datao.net> a écrit :
> Puis-je rajouter que Virtuoso n'est pas ecrit en Java, ce qui
> contraint le deploiement.
> Contrairement au NativeStore de Sesame qui s'embarque sans souci.
>
> Ceci dit, Sesame etant avant tout une API, OpenLink fournit les
> wrappers Sesame-API pour leur base RDF.
OK
http://www.openlinksw.com/dataspace/dav/wiki/Main/VirtSesame2Provider
> (ils fournissent egalement les wrappers Jena-API).
>
> En terme de stabilite et de resistance a la charge, j'aurais tendance
> a preferer un backend Virtuoso. Oracle est egalement TRES performant
> (mais infernal a deployer).
>
> 2009/10/21 Jean-Marc Vanel <jeanmar...@gmail.com>:
>> Bonjour Adrien et les autres
>>
>> J'inaugure ici une liste de courrier en Français pour les développeurs et
>> architectes intéressés par les évolutions, les choix et la feuille de route
>> des projets EulerGUI et Déductions . C'est un sous-ensemble de la liste
>> pour les évènements et sorties logicielles.
>> Si vous voyez d'autre personnes qui pourraient être intéressées, mettez-les
>> en copie d'une réponse ou suggérez-les moi.
>> Bien sûr, vous serez retirés de la liste sur demande.
>>
>> Adrien, tu as mentionné que tu préfères Virtuoso par rapport à Sesame.
>> Quelles sont les raisons ?
>>
>> Ce que j'ai constaté, c'est que la dernière version de Sesame se plante au
>> démarrage de Tomcat :
>> http://jmvanel.free.fr/computer-notes_2008.html#Trying161
>>
>> Par ailleurs avec Virtuoso, mon souci c'est que Virtuoso est derrière
>> DBpedia, et que je n'arrive pas à obtenir de réponse avec DBpedia pour une
>> requête SPARQL en mode CONSTRUCT (alors qu'une requête équivalente en mode
>> SELECT marche).
>>
>> En fait il n'y a pas que Sesame et Virtuoso.
>> Il y a les 2 backend de Jena: .
>> SDB - a SPARQL database for Jena.
>> TDB - a pure Java SPARQL database for Jena.
>> Bien sûr d'autres stockages pourraient être utilisés, comme CouchDB, une
>> base JSON, ou eXist , une base XML+XQuery.
>> Mais on se restreint aux bases RDF + requêtes SPARQL.
>>
>> --
>> Jean-Marc Vanel
>> Consulting, services, training,
>> Rule-based programming, Semantic Web
>> http://jmvanel.free.fr/
>> +33 (0)6 89 16 29 52 -- +33 (0)1 39 55 58 16
>> ( we rarely listen to voice messages, please send a mail instead )
>>
>
--
Jean-Marc Vanel
Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/
+33 (0)6 89 16 29 52 -- +33 (0)1 39 55 58 16
( we rarely listen to voice messages, please send a mail instead )
Jean-Marc Vanel
> Le 22 octobre 2009 05:14, luc peuvrier at home <lc....@orange.fr> a écrit :
>> Personellement j'essayerais de vous refourguer mon joafip !
>> Mais je n'ai pas saisi le besoin:
>
>> - une base de donnée avec interface sparql ?
> C'était le messge initial en effet.
>
>> - une persistence pour un moteur d'inference ?
> Ca peut être très intéressant aussi.
>
>> à la base joafip c'est pour gérer un data-model qui ne rentre pas en mémoire
>> via fichier, sans base de données et problème de mapping associé.
>> Pensez vous qu'une couche logiciel entre votre besoin et joafip ferait
>> l'affaire ?
>
> C'est une idée qu'on a déjà caressée, et en effet, si ça marche, ça
> peut être très utile.
>
> Un mot d'explication sur JoaFip et Luc Peuvrier.
> Luc Peuvrier est développeur de EulerGUI, dont il a fait l'analyser
> syntaxique pour N3. Mais surtout il a crée JoaFip (), un projet sans
> équivalent à ma connaissance. JoaFip prend des classes
> d'implémentation telles quelles (avec quelques restrictions quand
> même), avec des champs collections et simples. JoaFip s'interpose
> entre ces classes d'implémentation et votre application, afin de gérer
> une persistance sur fichier, et aussi le chargement et déchargement de
> la mémoire entre le fichier et les objets en mémoire.
> Par rapport à une base classique, aussi bien SQL que RDF, XMl , il y a
> aucun mapping par rapport aux objets Java, on travaille directement
> dessus.
> Pour ce qui est des requêtes, il n'a pas besoin d'une implémentation
> particulière avec JoaFip; s'il y a besoin de rechercher par rappport à
> un champ, on ajoutera dans une classe englobante la Map qui va bien.
Désolé , une faute de frappe , et le message est parti trop tôt.
Il faudrait voir si la classe
org.drools.impl.StatefulKnowledgeSessionImpl de Drools (dans
drools-core-5.0.1.jar.) se prête à fonctionner sous JoaFip. Si c'est
le cas, on peut déployer une application générée par EulerGUI avec les
règles Déductions, en utilisant directement le moteur d'inférence
actuel Drools. Il n'y aurait pas besoin d'utiliser une base RDF
"classique" comme Sesame, Virtuoso, ou Jena SDB/TDB . En effet, pour
les requêtes, on peut utiliser le moteur actuel pour les requêtes en
N3 (qui traduit N3 en langage Drools). Et JoaFip assurerait le
stockage sur disque.
Pour examiner Drools par rapport à JoaFip, le point de départ peut
être la méthode suivante de EulerGUI:
DroolsFactsLoadStore.main()
qui charge et exécute des faits et des règles indépendamment de EulerGUI;
en utilisant Drools exactement de la même manière qu' EulerGUI lui-même.
Bien sûr , ça reste utile de se connecter à des points d'accès SPARQL
(endpoints) existants. Et pour ça, Jena est déjà intégré dans
EulerGUI.
>>
>> CDT
>> Luc
>>
>> ----- Original Message ----- From: "Olivier Rossel" <da...@datao.net>
>> To: "Jean-Marc Vanel" <jeanmar...@gmail.com>
>> Cc: "Adrien Guichard" <guichar...@gmail.com>; "Cyril Hansen"
>> <cyril....@gmail.com>; "Eric Van Der Vlist" <v...@dyomedea.com>; "Etienne
>> Jacquin" <etienne...@laposte.net>; "Frédéric Jarlier"
>> <fjar...@mobileemail.vodafone.fr>; "luc peuvrier at home"
>> <lc....@orange.fr>; "Paul HOSSENLOPP" <paul.ho...@rocketmail.com>;
>> "Pierre Attar" <at...@tireme.fr>
>> Sent: Wednesday, October 21, 2009 2:52 PM
>> Subject: Re: Virtuoso versus Sesame
>>
>>
>>
>> Puis-je rajouter que Virtuoso n'est pas ecrit en Java, ce qui
>> contraint le deploiement.
>> Contrairement au NativeStore de Sesame qui s'embarque sans souci.
>>
>> Ceci dit, Sesame etant avant tout une API, OpenLink fournit les
>> wrappers Sesame-API pour leur base RDF.
Jean-Marc Vanel
http://groups.google.com/group/deductions-fr
Après discussions avec Luc, le problème ( non bloquant ) pour
intégrer un stockage comme JoaFip (http://joafip.sourceforge.net/) est
le suivant.
Supposons un cas d'utilisation de commerce électronique. On a un
catalogue de produits, et une liste clients avec leur historique
(grosse !).
JoaFip peut parfaitement charger en mémoire incrémentalement les
objets à partir d'un objet racine, mais le problème est de les virer
hors de la mémoire. Supposons qu'on cherche toutes les commandes ou
articles répondant à un certain critère. On va se retrouver avec
toutes les commandes ou articles en mémoire.
Il y a plusieurs stratégies possibles pour dégager la mémoire :
- 1. faire une pile FIFO de longueur fixe pour les objets en mémoire,
qui se vide en même temps qu'elle se remplit
- 2. plus bestial: par tranche de 10000, on vire tout sauf la racine
et l'objet courant quand on atteint la limite de 10000 objets
- 3. plus efficace: on compte les accès, et quand on atteint une
limite de 10000 objets, on vire ceux qui ont un seul accès
Il y en a encore sûrement d'autres , ca c'est un problème que toutes
les bases de données rencontrent.
Maintenant, pour implémenter ça, il faut pouvoir remplacer ou
"aspecter" (intercepter à la AOP) la classe
SingleThreadedObjectStore de Drools
(http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-core/src/main/java/org/drools/common/SingleThreadedObjectStore.java).
Et là c'est pas évident de faire ça de façon propre; Drools est un peu
touffu on va dire.
Mon opinion est que, pour tester, on peut remplacer
SingleThreadedObjectStore (après on verra avec les gens de Drools
comment faire plus propre).
Dans SingleThreadedObjectStore, les choses imporatantes se passent
autour du champ:
private ObjectHashMap assertMap;
luc peuvrier at home
J'ai regardé où est utilisé SingleThreadedObjectStore.java
cela pour mieux comprendre l'interface ObjectStore ( qui n'est pas
"javadoqué" ).
C'est vraiment l'entité qui stocke les object.
ObjectStore est une interface proche de celle d'un pattern DAO.
Pour RuleBase c'est plus délicat, il n'y a pas une nette séparation entre le
traitement (service) et les données (entité), les deux rôles sont dans la
même classe.
L'idée de l'AOP va nous lancer dans un truc énorme nécessitant une bonne
compréhension du code de Drools, et rien qu'en voyant le javadoc, et en plus
sans vision globale de l'architecture .....
Personellement je préferais que JBOSS restructure son code en ajoutant un
pattern DAO.
Comme j'ai vue dans le code Drools qu'a des endroits tout est mis dans des
tableaux en mémoire il faudrait aussi qu'ils changent la façon de faire.
----- Original Message -----
From: "Jean-Marc Vanel" <jeanmar...@gmail.com>
To: "luc peuvrier at home" <lc....@orange.fr>
Cc: "Olivier Rossel" <da...@datao.net>; "Eric Van Der Vlist"
<v...@dyomedea.com>; "Etienne Jacquin" <etienne...@laposte.net>;
Jean-Marc Vanel
à la fin du mail .
Peut-être c'est pas assez explicite:
On peut réécrire SingleThreadedObjectStore en introduisant un statégie
pour dégager la mémoire , la bestiale pour commencer (après on verra
avec les gens de Drools
comment faire plus propre).
Est-ce que c'est facile et rapide pour vous d'ajouter quelques lignes
Joafip dans SingleThreadedObjectStore pour relacher les objets, là où
assertMap est touché ?
luc peuvrier at home
Mais à quoi bon puisqu'il y a des chargement complet dans des tableaux.
Bien sure que l'on arrivera à faire quelque chose en tapant dans le code de
drool.
J'ai même une idée, inspiré de votre idée d'AOP, qui germe pour avoir un
outil ....