You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2015/10/02 12:39:26 UTC
Re: Jena rule engine on top of non-memory model
On 30/09/15 16:19, Dave Reynolds wrote:
> On 30/09/15 16:02, Zak Mc Kracken wrote:
>> On 30/09/2015 13:38, Dave Reynolds wrote:
>>>
>>> The backward chaining engine will only store data if you explicitly
>>> ask it to via the table() directive. If you don't table any goals then
>>> the space use shouldn't grow over time - there will be some
>>> intermediate state while a query is running but it doesn't load
>>> everything into memory.
>>>
>>> Performance, however, might not be good. The issue is that the rule
>>> engines operate at the low level of triple patterns. So running a
>>> SPARQL query over a rule engine over TDB means that the TDB will only
>>> see triples patterns one at a time with no chance do its own
>>> optimizations.
>>>
>>> The only way to find out if the performance is usable for the kind of
>>> queries you have in mind is to give it a try.
>>>
>>> Dave
>>>
>> Thank you very much Dave,
>>
>> I guess there isn't another pipeline to overcome this possible issue too.
>
> Nothing built into Jena I'm afraid.
>
> Dave
I have been looking at adding some RDFS++ level support to TDB directly.
This is unfinished, unprioritized work-in-progress.
Zak - which inferences are you interested in? You mentioned symmetry
and transitivity - any others>? For transitivity, is that for
rdfs:subClassOf/subPropertyOf or for your own properties?
The approach I am looking at is "compiling" transitivity of
subClassOf/subPropertyOf when starting up to avoid chasing chains at
query time. Otherwise, the process is catching access patterns
x type T
=>
x type S . S subClassof* T
=>
x type S . S flatenedSubClassof T
Knowing what features you are interested in would help working out the
useful and computationally viable (for a database) options.
Andy
Re: Jena rule engine on top of non-memory model
Posted by Dave Reynolds <da...@gmail.com>.
Hi Marco,
If you are only using backward rules and have no tabling then it won't
be fetching everything in memory. Depending on your rules and queries it
may a lot of TDB queries and might be slow :)
The way I'd suggest debugging this is to create a small test case as a
java program - no assembler, no fuseki, just your TDB image and your
rules. That way you can control exactly what's going on and work out if
the rule engine approach is usable for you. Then, if that's looking
promising sort out the details of assembler configuration.
Dave
On 25/10/15 19:22, Zak Mc Kracken wrote:
> Thanks Dave,
>
> I've tried that and that didn't work too. Sounds like it tries to fetch
> everything in memory anyway. I'm using only backward rules.
>
> Best,
> Marco.
>
>
> On 22/10/2015 20:14, Dave Reynolds wrote:
>>
>> The documentation isn't very clear and I'm not fully familiar with how
>> the assembler works for rules. You might do best debug via configuring
>> in java and then shift to trying to express the layout in assembler.
>>
>> However, going by the RDFS vocabulary described in the documentation I
>> think you want something more like:
>>
>> <#infGraph> rdf:type ja:InfModel ;
>> ja:reasoner [
>> ja:reasonerURL <http://jena.hpl.hp.com/2003/GenericRuleReasoner> ;
>> ja:rules [ ja:rulesFrom <file:custom.rules> ]
>> ];
>> ja:baseModel <#baseGraph> .
>>
>> If your rules are written using backward rule notation then the
>> default "Hybrid" model will be fine, only the backward engine will be
>> used. If you write your rules as if they were forward inference but
>> want them to run backward then you would need to set the reasoner
>> mode. Which can be done but would have to work out the syntax.
>>
>> Dave
>>
>
Re: Jena rule engine on top of non-memory model
Posted by Zak Mc Kracken <za...@yahoo.it>.
Thanks Dave,
I've tried that and that didn't work too. Sounds like it tries to fetch
everything in memory anyway. I'm using only backward rules.
Best,
Marco.
On 22/10/2015 20:14, Dave Reynolds wrote:
>
> The documentation isn't very clear and I'm not fully familiar with how
> the assembler works for rules. You might do best debug via configuring
> in java and then shift to trying to express the layout in assembler.
>
> However, going by the RDFS vocabulary described in the documentation I
> think you want something more like:
>
> <#infGraph> rdf:type ja:InfModel ;
> ja:reasoner [
> ja:reasonerURL <http://jena.hpl.hp.com/2003/GenericRuleReasoner> ;
> ja:rules [ ja:rulesFrom <file:custom.rules> ]
> ];
> ja:baseModel <#baseGraph> .
>
> If your rules are written using backward rule notation then the
> default "Hybrid" model will be fine, only the backward engine will be
> used. If you write your rules as if they were forward inference but
> want them to run backward then you would need to set the reasoner
> mode. Which can be done but would have to work out the syntax.
>
> Dave
>
Re: Jena rule engine on top of non-memory model
Posted by Dave Reynolds <da...@gmail.com>.
On 14/10/15 13:01, Zak Mc Kracken wrote:
> So far, I've experimented with Fuseki and using this in its configuration:
>> <#infGraph> rdf:type ja:InfModel ;
>> #the rules directory is in the "run" directory
>> ja:reasoner [ ja:rulesFrom <file:custom.rules> ; ] ;
>> ja:baseModel <#baseGraph> .
>>
>> <#baseGraph> rdf:type tdb:GraphTDB;
>> tdb:location "test_custom_rules_tdb/db" .
>
> But I suspect it's not configuring the InfModel the way I want (probably
> it's taking the hybrid reasoner, which loads everything in memory), and,
> honestly, the Fuseky/Assembler documentation doesn't help much in tuning
> the InfModel configuration. Any help on this?
The documentation isn't very clear and I'm not fully familiar with how
the assembler works for rules. You might do best debug via configuring
in java and then shift to trying to express the layout in assembler.
However, going by the RDFS vocabulary described in the documentation I
think you want something more like:
<#infGraph> rdf:type ja:InfModel ;
ja:reasoner [
ja:reasonerURL <http://jena.hpl.hp.com/2003/GenericRuleReasoner> ;
ja:rules [ ja:rulesFrom <file:custom.rules> ]
];
ja:baseModel <#baseGraph> .
If your rules are written using backward rule notation then the default
"Hybrid" model will be fine, only the backward engine will be used. If
you write your rules as if they were forward inference but want them to
run backward then you would need to set the reasoner mode. Which can be
done but would have to work out the syntax.
Dave
Re: Jena rule engine on top of non-memory model
Posted by Zak Mc Kracken <za...@yahoo.it>.
Hi Andy, sorry for my late reply,
Basically, I need owl:sameAs entailments, and I don't even need to
consider all usual inference rules, because I'm able to create a dataset
that contains only 'star' triples, i.e., I can identify all sets of
equivalence classes in a sameAs-induced partition and, for each set of
resources that are sameAs-related one each other, I can store statements
like: x0 sameAs ?y, where x0 is a common element in the equivalence class.
In other words, there is no chain and the only rules needed to entail
all possible inferences should be:
- (?x, ?x) # Actually I'm willing to give up with this, cause it's
obvious and I don't expect queries like this
- (?y, ?x) <- { ( ?x, ?y ) }
- (?x, ?y) <- { (?center, ?x ), (?center, ?y) } # we have only stars,
this is enough to capture transitivity
I realise that using the 'mini' reasoner (the minimum that supports
owl:sameAs, according to documentation) shouldn't change the performance
much (given the shape of my dataset), however I have a large dataset and
I don't want it fully loaded in memory, I'd like inferences to be made
dynamically (in backward-chain fashion) over TDB.
So far, I've experimented with Fuseki and using this in its configuration:
> <#infGraph> rdf:type ja:InfModel ;
> #the rules directory is in the "run" directory
> ja:reasoner [ ja:rulesFrom <file:custom.rules> ; ] ;
> ja:baseModel <#baseGraph> .
>
> <#baseGraph> rdf:type tdb:GraphTDB;
> tdb:location "test_custom_rules_tdb/db" .
But I suspect it's not configuring the InfModel the way I want (probably
it's taking the hybrid reasoner, which loads everything in memory), and,
honestly, the Fuseky/Assembler documentation doesn't help much in tuning
the InfModel configuration. Any help on this?
Thank you in advance,
Marco.
On 02/10/2015 11:39, Andy Seaborne wrote:
>
> I have been looking at adding some RDFS++ level support to TDB
> directly. This is unfinished, unprioritized work-in-progress.
>
> Zak - which inferences are you interested in? You mentioned symmetry
> and transitivity - any others>? For transitivity, is that for
> rdfs:subClassOf/subPropertyOf or for your own properties?
>
> The approach I am looking at is "compiling" transitivity of
> subClassOf/subPropertyOf when starting up to avoid chasing chains at
> query time. Otherwise, the process is catching access patterns
>
> x type T
> =>
> x type S . S subClassof* T
> =>
> x type S . S flatenedSubClassof T
>
> Knowing what features you are interested in would help working out the
> useful and computationally viable (for a database) options.
>
> Andy
>
>