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
