Date: 2013-01-03 16:16:19
From: Erik.Boye@statnett.no
Hi,
We are in the process of establishing an infrastructure for storing and querying power system network models based on OWLIM and Sesame. We need to track different versions of the power system network model (at the same time), and thought could be achieved using named graphs: One named graph per version of the power system network model.
The queries that are performed on the power system network model heavily depends on OWLIM inference. With only one named graph in the repository, all works fine. But when there are more than one named graph in the repository, and queries need to be restricted to a specific named graph, our queries fail:
To restrict the queries to a specific named graph the following Sesame API method is used:
ContextAwareConnection#setReadContexts(URI[])
The problem seems to be related to the fact that statements inferred by OWLIM are stored in the unnamed graph (default context), and therefore not included when restricting the queries to a specific named graph. Is this the expected behavior? If yes, why? And does anyone have a suggestion for a workaround, except from the obvious one: separation on the repository level?
Best regards,
Erik

asked 03 Apr '13, 12:11

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%


Date: 2013-01-09 08:29:36
From: barry.bishop@ontotext.com
Hi Erik,
OWLIM computes inferences at load time (forward chaining rule-based 
inference) and considers triples from any named graph (context) as input 
to the reasoner. The decision to put inferred triples into the default 
graph is really down to the fact that there is no other sensible place 
to put them.
For example, if a triple in context A and a triple in context B leads to 
the inference of a new triple, should it go in context A, context B or 
somewhere else? It is purely because inferred statements are computed as 
a result of triples in many contexts that it is just simpler to put them 
in the default context.
I hope this makes sense,
barry
link

answered 03 Apr '13, 12:12

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%

Date: 2013-01-04 09:47:36
From: Ken.Wenzel@iwu.fraunhofer.de
Hi Erik,
in addition to your specific named graphs, you also need to include the default context (with a null URI) when
executing your query. This ensures that the inferred triples can also be read.
Unfortunately, at the moment it is not possible to retrieve only those triples which are inferred from a
certain combination of named graphs. I also think that it is difficult, if not impossible, to implement this
on top of a forward chaining reasoner since it would require to store tons of provenance information.
A backward chaining reasoner may be better suited for this usage scenario.
Virtuoso provides a mechanism called rule sets. These rule sets are associated with a URI (e.g., <urn:ruleset1>) and
are based on RDFS/OWL descriptions retrieved from a combination of named graphs (e.g. <urn:graph1>, <urn:graph2>, ...).
When executing a SPARQL query a rule set can be selected with a Virtuoso specific SPARQL extension:
define input:inference '<urn:ruleset1>'
select ?s where { ?s ?p ?o }
Afaik, Virtuoso's rule sets are implemented by using query rewriting.
Maybe, OWLIM can implement something comparable for its forward chaining approach?
For example, the user may specify multiple rule sets and associated named graphs for the inferred triples:
<urn:graph1>, <urn:graph2>, ... => <urn:graph-inferred-with-ruleset1>
Now, OWLIM's reasoner is executed for each rule set (and combination of named graphs) instead of using
only one global reasoner.
I don't know if this approach is scalable since it would produce many duplicated inferred triples and
also may lead to many reasoner runs if a named graph is changed that takes part in multiple rule sets.
Another approach can be that OWLIM uses some sort of filtering to exclude those inferred triples
where not at least one asserted triple within the queried named graphs exists that mentions its subject,
predicate or object.
I've simulated this approach by using SPARQL filters but it tends to be rather slow with OWLIM SE:
select ?o where {
?s ?p ?o
filter (!bound(?o) || isLiteral(?o) || exists {
graph ?g {  { ?o ?p1 ?o1  } union { ?s2 ?o ?o2 } union { ?s3 ?o3 ?o }  }
}
}
Note: "!bound(?o)"  is not required in this query - I've just included it to demonstrate the generic case.
Best regards,
Ken
link

answered 03 Apr '13, 12:11

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%

Date: 2013-01-07 14:17:38
From: barry.bishop@ontotext.com
Hi Ken, Erik,
To reiterate what Ken mentioned, there is no standard place to put 
inferred statements and OWLIM simply adds these to the default graph.
If restricting the execution of certain methods to specific named graphs 
(contexts) only is required, then it will be necessary to include the 
default graph. Note that at present OWLIM does not compute inferences at 
query time, so the default graph can include inferred statements 
produced from explicit statements not present in the selects contexts.
For selecting the named graph, please see the Sesame javadoc:
http://www.openrdf.org/doc/sesame2/api/org/openrdf/repository/RepositoryConnection.html
This explains how to select the default graph. I believe it is possible 
to pass something like the following to the vararg parameter for 
contexts: new URI[] {context1, null, context2} - where 'null' represents 
the default graph. However, if this fails, then with OWLIM-SE it might 
be possible to use the special URI for inferred statements: 
<http://www.ontotext.com/implicit>
I hope this helps,
barry
link

answered 03 Apr '13, 12:11

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%

From: Erik.Boye@statnett.no
Hi Ken, Barry,
Thank you so much for your answers to my question. Including the default context by supplying null (in a addition to the URI of the specific named graph) to setReadContexts-method solves my immediate issue. But as Barry is pointing out, "the default graph can include inferred statements produced from explicit statements not present in the selects contexts", but this is currently not an issue for my current usage.
Just out of curiosity:  What would be wrong if OWLIM produced inferred statements in the same context as the explicit statement? How/why would that be wrong?
Regards,
Erik
link

answered 03 Apr '13, 12:12

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×261
×242
×18

Asked: 03 Apr '13, 12:11

Seen: 4,915 times

Last updated: 26 May, 00:52

powered by BitNami OSQA