owlim-discussion  

Re: [Owlim-discussion] CONSTRUCT query and total materialization

Miroslav Líška
Wed, 04 Jan 2012 15:01:32 -0800

Hi Barry,
/also let me say Happy New Semantic Year (4 minutes after new year I was loading another file to the OWLIM :)/
thank you a lot of for the example and the explanation. One last question. Does it mean that Contruct query is not intended for creating and storing inferred triples to the repository, rather it can be used only together with SELECT query? So for the storing new inferred triples It can be used only INSERT query (i.e. even Trree use this kind of materialization)? I apologize for these simple questions I do not want to bother you, I just need to understand OWLIM as most as it is possible. 

with kindest personal regards
miro

On Mon, 02 Jan 2012 13:36:12 +0100, Barry Bishop wrote:

Hi Miroslav,

HAPPY NEW YEAR!

Hmm, I see where you are going with this. I was thinking along these
lines (which is best shown by example):

Suppose we have an empty database with no inference (ruleset="empty")
and then add this raw data:

PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>

INSERT DATA {
  ex:baz rdf:type ex:Human .
  ex:Human rdfs:subClassOf ex:Mammal .
  ex:Mammal rdfs:subClassOf ex:Vertebrate .
}

Various inference rules can be simulated using the following style of
SPARQL update statements:

// rdfs9
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
INSERT
{
  GRAPH <http://inferred/rdfs9> { ?x rdf:type ?superclass }
}
WHERE
{
  ?x rdf:type ?class .
  ?class rdfs:subClassOf ?superclass .
  FILTER( ?class != ?superclass ) .
  FILTER( ?class != rdfs:Class ) .
}


// rdfs11
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
INSERT
{
  GRAPH <http://inferred/rdfs11> { ?c1 rdfs:subClassOf ?c3 }
}
WHERE
{
  ?c1 rdfs:subClassOf ?c2 .
  ?c2 rdfs:subClassOf ?c3 .

  FILTER( ?c1 != ?c2 ) .
  FILTER( ?c2 != ?c3 ) .
}


The result of running the above updates will be:

    ex:baz rdf:type ex:Mammal - in context <http://inferred/rdfs9>

and

    ex:Human rdfs:subClassOf ex:Vertebrate - in context
<http://inferred/rdfs11>

To ensure the proper closure you would need to run these updates
several times (some rules feed the output of other rules) in the case
of RDFS entailment.

In any case, this is just a suggestion. I hope it helps.

All the best,
barry


On 29/12/11 15:40, Miroslav Líška wrote:
Hi Barry, thank you for explanation, but I still cannot to use constructed triples as implicit triples (equally from the materialization point of view). Let me please refine my post.
I create a CONSTRUCT query, the workbench returns desired triples, but next when I create select query, it does not bind the constructed solutions. Thus let me please ask, whether it is possible to run a construct query (once) what can be taken as an inference process, so other users (other queries) will bind the constructed solutions like it is with implicit triples creation during loading. 

with kindest personal regards
miroslav





On Thu, 29 Dec 2011 09:01:55 +0100, Barry Bishop wrote:

Hello Miroslav,

If I understand correctly, then yes you could use this approach of
running your own SPARQL construct queries over your 'explicit' dataset 
to generate new statements and add them to the repository. To keep
them separate I suggest adding the 'inferred' statements in to their 
own context - this will make them easier to delete and recompute if
necessary.

The only downsides I can think of are:
1. If you have 'rules' that use the output of other 'rules' then you will need to repeat the execution of all your construct queries until 
you don't generate any new triples.

2. Incremental delete will not be possible - i.e. removing a single
triple will require the deletion and re-computation of all your
inferred triples.
However, if your data is relatively static then this would not be a problem. 

All the best,
barry

-- Barry Bishop
OWLIM Product Manager
Ontotext AD
Tel: +43 650 2000 237
email: barry.bis...@ontotext.com
www.ontotext.com


On 28/12/11 16:02, Miroslav Líška wrote:

Dear sirs,
since TRREE does not support SPARQL for rules definition, let me please ask whether the CONSTRUCT query can be used as equivalent approach from total materialization point of view. 

For example:
I have 1B triples and with the CONSTRUCT query I will create additional 500M of implicit triples. These implicit triples are materialized in the same way like implicit triples created in reasoning after load OWL files into repository. Thus when other user run a query this query binds the solutions created with the previous CONSTRUCT query.
Thus the question is: Is the CONSTRUCT query equivalent to reasoning process with rules from the materialization point of view? If that will be true, then this will be the perfect solution to bypass weakness of Trree reasoning that does not support SPARQL, just N3 format only. 


with kindest personal regards
miroslav


_______________________________________________
OWLIM-discussion mailing list
OWLIM-discussion@ontotext.com
http://ontotext.com/mailman/listinfo/owlim-discussion




_______________________________________________
OWLIM-discussion mailing list
OWLIM-discussion@ontotext.com
http://ontotext.com/mailman/listinfo/owlim-discussion