Hi Barry, Ken,

This is a follow-up question to this old issue.

After upgrading to OWLIM-SE version 5.5 I am no longer able to restrict the 
execution to specific named graphs (contexts). I am unable to get the inferred 
statements, so it seems like the default context is no longer included by 
supplying <null> to the setReadContext method.

I have also tried to replace <null> with http://www.ontotext.com/implicit (as 
suggested by Barry), but that does not work either.

Do you have any suggestions on how to satisfy my requirement with the newer 
version of OWLIM (and Sesame)?

Best regards,
Erik

From: Barry Bishop [mailto:barry.bis...@ontotext.com]
Sent: 7. januar 2013 14:18
To: Wenzel, Ken
Cc: Erik Boye; owlim-discussion@ontotext.com
Subject: Re: [Owlim-discussion] Inference with named graph (context)

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><http://www.ontotext.com/implicit>

I hope this helps,
barry



--

Barry Bishop

OWLIM Product Manager

Ontotext AD

Tel: +43 650 2000 237

email: barry.bis...@ontotext.com<mailto:barry.bis...@ontotext.com>

skype: bazbishop

www.ontotext.com<http://www.ontotext.com>

On 04/01/13 10:47, Wenzel, Ken wrote:
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


From: 
owlim-discussion-boun...@ontotext.com<mailto:owlim-discussion-boun...@ontotext.com>
 [mailto:owlim-discussion-boun...@ontotext.com] On Behalf Of Erik Boye
Sent: Thursday, January 03, 2013 5:16 PM
To: owlim-discussion@ontotext.com<mailto:owlim-discussion@ontotext.com>
Subject: [Owlim-discussion] Inference with named graph (context)

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




_______________________________________________

Owlim-discussion mailing list

Owlim-discussion@ontotext.com<mailto:Owlim-discussion@ontotext.com>

http://ontomail.semdata.org/cgi-bin/mailman/listinfo/owlim-discussion

_______________________________________________
Owlim-discussion mailing list
Owlim-discussion@ontotext.com
http://ontomail.semdata.org/cgi-bin/mailman/listinfo/owlim-discussion

Reply via email to