Re: Very slow SPARQL query on TDB
Hi Andy,
I've good response time now with the SPARQL request fixed by Milorad.
Nevertheless, I will focus on the TDB Optimizer soon and also upgrade Jena
to the last release (my current release is 2.10.1)
Thank you for your help.
Sincerely,
Laurent.
On Wed, Jan 28, 2015 at 7:44 PM, Andy Seaborne a...@apache.org wrote:
On 28/01/15 18:34, Milorad Tosic wrote:
Hi Laurent,
I would give a try to a different sequencing in the query. For example:
PREFIX base:http://www.telemis.com/PREFIX rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#PREFIX XMLS:
http://www.w3.org/2001/XMLSchema#
SELECT ?x{ ?image base:sopInstanceUID 1.2.840.113564.10656621.
201302121438403281.1003000225002^^XMLS:string . ?image a base:Image .
?seq ?p ?image . ?x base:images ?seq .
?x a base:ImageAnnotation ; base:deleted false .
}
Though, it may or may not help.
Regards,Milorad
From: Laurent Rucquoy laurent.rucq...@telemis.com
To: users@jena.apache.org
Sent: Wednesday, January 28, 2015 6:13 PM
Subject: Very slow SPARQL query on TDB
Hello,
I have a Java application which implements an object model persisted
through JenaBean in my Jena TDB (see the attached image of the classes
diagram).
The request to retrieve an ImageAnnotation resource from the ID of a
linked Image is very slow.Here is a typical SPARQL query used (more than
40s to get the result):
PREFIX base:http://www.telemis.com/PREFIX rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#PREFIX XMLS:
http://www.w3.org/2001/XMLSchema#
SELECT ?x{ ?x a base:ImageAnnotation ; base:deleted false ; base:images
?seq . ?seq ?p ?image . ?image a base:Image . ?image base:sopInstanceUID
1.2.840.113564.10656621.201302121438403281.1003000225002^^XMLS:string
.}
Can you help me to find what I'm doing wrong ?
Thank you in advance.
Sincerely,Laurent
Which version of TDB? 2.11.2 had possibly related fixes.
https://issues.apache.org/jira/browse/JENA-685
If you do take Milorad suggestion, also put in a none.opt file to stop
TDB reordering your improved order into a worse one.
http://jena.apache.org/documentation/tdb/optimizer.
html#choosing-the-optimizer-strategy
Andy
PS Attachments don't come through this list.
--
*Laurent Rucquoy*
RD Engineer
Telemis http://www.telemis.com
*Extending Human Life*
*** NEW ADDRESS ***
Avenue Athéna 2
1348 Louvain-la-Neuve
Belgium
laurent.rucq...@telemis.com
Tel: +32 (0) 10 47 14 39
Fax: +32 (0) 10 48 00 20
Re: Very slow SPARQL query on TDB
Hi Milorad,
Your suggestion solved my performance problem: the fixed SPARQL query took
less than 1s to get the result !
Thank you very much for your efficient support.
Sincerely,
Laurent.
On Wed, Jan 28, 2015 at 7:34 PM, Milorad Tosic mbto...@yahoo.com.invalid
wrote:
Hi Laurent,
I would give a try to a different sequencing in the query. For example:
PREFIX base:http://www.telemis.com/PREFIX rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#PREFIX XMLS:
http://www.w3.org/2001/XMLSchema#
SELECT ?x{ ?image base:sopInstanceUID
1.2.840.113564.10656621.201302121438403281.1003000225002^^XMLS:string .
?image a base:Image . ?seq ?p ?image . ?x base:images ?seq .
?x a base:ImageAnnotation ; base:deleted false .
}
Though, it may or may not help.
Regards,Milorad
From: Laurent Rucquoy laurent.rucq...@telemis.com
To: users@jena.apache.org
Sent: Wednesday, January 28, 2015 6:13 PM
Subject: Very slow SPARQL query on TDB
Hello,
I have a Java application which implements an object model persisted
through JenaBean in my Jena TDB (see the attached image of the classes
diagram).
The request to retrieve an ImageAnnotation resource from the ID of a
linked Image is very slow.Here is a typical SPARQL query used (more than
40s to get the result):
PREFIX base:http://www.telemis.com/PREFIX rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#PREFIX XMLS:
http://www.w3.org/2001/XMLSchema#
SELECT ?x{ ?x a base:ImageAnnotation ; base:deleted false ; base:images
?seq . ?seq ?p ?image . ?image a base:Image . ?image base:sopInstanceUID
1.2.840.113564.10656621.201302121438403281.1003000225002^^XMLS:string .}
Can you help me to find what I'm doing wrong ?
Thank you in advance.
Sincerely,Laurent
--
*Laurent Rucquoy*
RD Engineer
Telemis http://www.telemis.com
*Extending Human Life*
*** NEW ADDRESS ***
Avenue Athéna 2
1348 Louvain-la-Neuve
Belgium
laurent.rucq...@telemis.com
Tel: +32 (0) 10 47 14 39
Fax: +32 (0) 10 48 00 20
Fuseki2 : artifact rename
Thank you to everyone who has been using Fuseki2 and provide feedback. It has been has very important and resulted in Fuseki2 moving to non-beta faster than I could have hoped for. As a project, Jena maven artifacts of the form apache-jena* are considered to be the major points for picking up binaries. We keep them stable even if the artifacts structured for development change. We have two currently: apache-jena - the binary distribution of the libraries apache-jena-libs - the maven dependency target for picking up the libraries and now we are adding: apache-jena-fuseki - renamed jena-fuseki-dist for the distribution binary (zip and tar.gz) of fuseki-server.jar and fuseki.war. Please use this new name instead, if you were using the old name. The other artifact names for Fuseki2 remain the same. Andy
Re: Forward RETE and redundant deduction
Hi Dave, my answers and comments are in the following. It’s good to talk about RETE engines :-) Le 28 janv. 2015 à 19:33, Dave Reynolds dave.e.reyno...@gmail.com a écrit : On 28/01/15 14:06, Christophe FAGOT [intactile DESIGN] wrote: Hi Andy, thanks for your answer, and I’m ok for the graph being a set of triples, it is the (very good) reason explaining why only one triple is produced. But the reasoner is not in forward model. It is a forward-RETE model, which means that the forward rules have to work incrementally, allowing to add and remove triples and maintaining the consistency of the model. So in the case described by Sébastien, the forward-RETE model should not remove the inferred triple since another rule has its body terms still validated. At least, this last rule should have been fired in order to indicate it that the triple which was not created previously (because it was still in the graph) is going to be removed, so this last rule should produce it again. The RETE engine stops once a triple has been deduced by one route. If you attempt to track each possible route by which a triple could be deduced and reference count them all then you will get a combinatoric explosion in numbers of possible deduction paths and performance plummets (which is why naive truth maintenance never worked out). You don’t need to track each possible route to maintain the truth. In a previous company Sébastien and I created a home-made RETE engine, and simple counters stored with triples are enough to maintain the truth of the graph. The counter is increased each time a triple is redundantly added, and decreased when the triple is asked to be removed. The triple is really removed from the graph when its counter is at 0. So, no combinatoric explosion. The Jena engine works around this by not attempting to handle removals incrementally at all. A remove is supposed to mark the model as needing a new prepare stage and the entire deduction process is run from scratch again the next time you query the model. So, if I well understand what you say, the RETE Engine is monotonic and maintain the truth when adding some triples, but it’s not the case when triples are removed. Am I true? If, when removing a triple, we want to maintain the truth in a graph managed by the RETE engine, we have to do as if the engine was a classical forward one and require a new « prepare » stage (meaning the removing of the whole previous inferences). Am I true on this point too ? If what I write is true, I now fully understand what you wrote to me in the past about the removal into the RETE engine :-D That certainly used to work and I can't see why Sébastien's case would fail, though I don't see the code by which the results are getting accessed. I'm not in a position to test it from here. It fails if, for whatever reason depending on the software you are developing, you can’t remove the whole infered triples each time you remove a single one.And it’s our case :-( But whatever, having your explanations is good for us to understand if and where we can patch the current Jena RETE engine (and dependencies), or if we have to deal with it by our side. Chris. Dave Chris. Christophe FAGOT, PhD RESPONSABLE RD INFORMATIQUE intactile DESIGN Création d’interfaces + subtiles +33 (0)4 67 52 88 61 +33 (0)9 50 12 05 66 20 rue du carré du roi 34000 MONTPELLIER France www.intactile.com http://intactile.com/ Hugh MacLeod : It's not what the software does, it's what the user does Les informations contenues dans cet email et ses documents attachés sont confidentielles. Elles sont exclusivement adressées aux destinataires explicitement désignés ci-dessus et ne peuvent être divulguées sans consentement de son auteur. Si vous n'êtes pas le destinataire de cet email vous ne devez pas employer, révéler, distribuer, copier, imprimer ou transmettre le contenu de cet email et devez le détruire immédiatement. Le 28 janv. 2015 à 12:17, Andy Seaborne a...@apache.org a écrit : (Dave is not around at the moment so I'll try to answer some parts of your question ...) On 28/01/15 10:28, Sébastien Boulet [intactile DESIGN] wrote: Hello, I have two rules which could produce the same triple: String rules = [r1: (?a eg:p ?b) - (?a, eg:q, ?b)] + [r2: (?a eg:r ?b) - (?a, eg:q, ?b)]; i have configured a GenericRuleReasoner in FORWARD_RETE mode. GenericRuleReasoner reasoner = new GenericRuleReasoner(Rule.parseRules(rules)); reasoner.setMode(GenericRuleReasoner.FORWARD_RETE); InfModel model = ModelFactory.createInfModel(reasoner, ModelFactory.createDefaultModel()); When a triple satisfy the first rule and another triple satisfy the second rule: Resource subject = model.createResource(); Property predicateP = model.getProperty(urn:x-hp:eg/p); Literal
Configuration for apache jdbc
Hey all ! I just want to know that is this possible that to use jdbc instead of tdb in apache fuseki ? If yes Then Please tell me How can I use/config jdbc in apache fuseki ? Thanks in advance.
Re: Configuration for apache jdbc
On 29/01/15 10:46, Nauman Ramzan wrote: Hey all ! I just want to know that is this possible that to use jdbc instead of tdb in apache fuseki ? If yes Then Please tell me How can I use/config jdbc in apache fuseki ? Thanks in advance. See SDB. Given your previous emails about Virtuoso, have you asked them if they have an assembler? Jena provides the general framework - assemblers are the extension point to bring in other systems which their own unique features. The expectation is that the system-specific extension code is provided by that system. Andy
Re: Very slow SPARQL query on TDB
On 29/01/15 11:05, Laurent Rucquoy wrote:
Hi Andy,
I've good response time now with the SPARQL request fixed by Milorad.
Nevertheless, I will focus on the TDB Optimizer soon and also upgrade Jena
to the last release (my current release is 2.10.1)
Thank you for your help.
Glad you've got it working.
2.11.2+ should effectively do what Milorad suggests - it should pick
image base:sopInstanceUID
1.2.840.113564.10656621.201302121438403281.1003000225002^^XMLS:string .
as the first triple pattern to evaluate.
The bug was that it would choose
?x a base:ImageAnnotation ;
and that is somewhat less selective.
Andy
Sincerely,
Laurent.
On Wed, Jan 28, 2015 at 7:44 PM, Andy Seaborne a...@apache.org wrote:
On 28/01/15 18:34, Milorad Tosic wrote:
Hi Laurent,
I would give a try to a different sequencing in the query. For example:
PREFIX base:http://www.telemis.com/PREFIX rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#PREFIX XMLS:
http://www.w3.org/2001/XMLSchema#
SELECT ?x{ ?image base:sopInstanceUID 1.2.840.113564.10656621.
201302121438403281.1003000225002^^XMLS:string . ?image a base:Image .
?seq ?p ?image . ?x base:images ?seq .
?x a base:ImageAnnotation ; base:deleted false .
}
Though, it may or may not help.
Regards,Milorad
From: Laurent Rucquoy laurent.rucq...@telemis.com
To: users@jena.apache.org
Sent: Wednesday, January 28, 2015 6:13 PM
Subject: Very slow SPARQL query on TDB
Hello,
I have a Java application which implements an object model persisted
through JenaBean in my Jena TDB (see the attached image of the classes
diagram).
The request to retrieve an ImageAnnotation resource from the ID of a
linked Image is very slow.Here is a typical SPARQL query used (more than
40s to get the result):
PREFIX base:http://www.telemis.com/PREFIX rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#PREFIX XMLS:
http://www.w3.org/2001/XMLSchema#
SELECT ?x{ ?x a base:ImageAnnotation ; base:deleted false ; base:images
?seq . ?seq ?p ?image . ?image a base:Image . ?image base:sopInstanceUID
1.2.840.113564.10656621.201302121438403281.1003000225002^^XMLS:string
.}
Can you help me to find what I'm doing wrong ?
Thank you in advance.
Sincerely,Laurent
Which version of TDB? 2.11.2 had possibly related fixes.
https://issues.apache.org/jira/browse/JENA-685
If you do take Milorad suggestion, also put in a none.opt file to stop
TDB reordering your improved order into a worse one.
http://jena.apache.org/documentation/tdb/optimizer.
html#choosing-the-optimizer-strategy
Andy
PS Attachments don't come through this list.
RE: Configuration for apache jdbc
Here is something that might help. A project that I am involved with uses SDB on the backend as the default triple store (though that is going to change soon to TDB). I have package up an instance of fuseki (based on 1.1) that has a configuration for connecting to the SDB, a few example queries and a start-up script. If yo look at this page: https://wiki.duraspace.org/display/VIVO/Setting+up+a+VIVO+SPARQL+Endpoint you can find a sample assembler file and a download link for a version of fuseki with works with SDB (note, the configuration uses a read-only dataset). -Original Message- From: Andy Seaborne [mailto:a...@apache.org] Sent: Thursday, January 29, 2015 6:01 AM To: users@jena.apache.org Subject: Re: Configuration for apache jdbc On 29/01/15 10:46, Nauman Ramzan wrote: Hey all ! I just want to know that is this possible that to use jdbc instead of tdb in apache fuseki ? If yes Then Please tell me How can I use/config jdbc in apache fuseki ? Thanks in advance. See SDB. Given your previous emails about Virtuoso, have you asked them if they have an assembler? Jena provides the general framework - assemblers are the extension point to bring in other systems which their own unique features. The expectation is that the system-specific extension code is provided by that system. Andy
Re: Clear Graph using Model api
Assuming you just want to delete it from your remote store completely then call deleteModel() on your DatasetAccessor instance, this avoids the need for a local load of the graph first Rob On 29/01/2015 06:11, Trevor Donaldson tmdona...@gmail.com wrote: Whoops, answered my own question. model.removeAll(). My bad. On Thu, Jan 29, 2015 at 9:09 AM, Trevor Donaldson tmdona...@gmail.com wrote: Is there an easy way to clear the entire graph using DatasetAccessor / Model in the Jena Api? I would like to clear a graph without iterating over all nodes in a graph. Thanks.
Re: Clear Graph using Model api
Whoops, answered my own question. model.removeAll(). My bad. On Thu, Jan 29, 2015 at 9:09 AM, Trevor Donaldson tmdona...@gmail.com wrote: Is there an easy way to clear the entire graph using DatasetAccessor / Model in the Jena Api? I would like to clear a graph without iterating over all nodes in a graph. Thanks.
Clear Graph using Model api
Is there an easy way to clear the entire graph using DatasetAccessor / Model in the Jena Api? I would like to clear a graph without iterating over all nodes in a graph. Thanks.
