Andy,
Thanks for the reply.
By forward chain the data when loaded, I assume you mean manually doing
so on the client side before inserting?
I think the use case follows the general parameters you outline below.
The primary things really are just subClass and subProperty; I believe
those are the only elements that we're depending on now. The schema is
small, on the order of 50 classes. I will check out the linked project.
Thanks!
--Dave--
On 3/6/2016 11:28 AM, Andy Seaborne wrote:
On 01/03/16 19:20, Dave Kolas wrote:
Hi there,
I'm currently using Fuseki to host a number of RDF datasets. If one
wants basic RDFS inference around a graph with good query performance,
what is the suggested configuration?
I'm currently using a:
<http://jena.hpl.hp.com/2003/RDFSExptRuleReasoner>
wrapped around a TDB graph and dataset. However, this seems to (a)
dramatically increase the memory requirements and (b) destroy the query
optimizer. Is there a different way to configure things to get RDFS
inference and better performance? I don't actually have the need to
track / eliminate inferred statements, so it would be ok to just forward
chain on insertion into the same store.
Thanks,
--Dave--
Hi Dave,
In the current codebase the only two options are using there in-memory
reasoner or forward-chaining the data when it is is loaded. A
combination, whereby some inferences are done ahead of time and others
done via the in-memory reasoner at runtime is possible - I don't know
how much memory that saves though and it still might do bad things to
optimization.
Adding some support for RDFS to TDB would make a lot of sense.
I had a go with [1].
To scope that, could you give some background on your RDFS needs here,
which as which parts of RDFS you use (and RDFS++ - all the single
property inferences such as symmetric properties) and whether the
assumption below fit your usage:
1/ It expands the subclass and subproperty chains once at startup so
there is no path following at query time, just one hope for rdf:type.
?x rdf:type :C
==>
?x rdf:type ?X. ?X rdfs:"transitiveSubClassOf" :C .
2/ The schema is small - the workspace is in memory.
3/ The schema is fixed - any change would need to rebuild the sub*
data structures but also ...
4/ schema and data are separate (this is not a core assumption; I
wanted) to be be sure that worked well.
5/ No "messing with the furniture" i.e sub-properties of
rdfs:subClassOf, rdfs:subPropertyOf, rdf:type don't trigger inference.
I don't think it is fundamental in the design.
Andy
[1]
https://github.com/afs/jena-inf-engine
