That all sounds really good, and on the surface I like the TDB/SDB combo idea.
I do have a couple questions about applying it to my specific situation.
Regarding:
> - compute the class-to-rule mapping only once (walking the
> SPIN RDF syntax expressions might be slow on a DB).
Are you talking specifically about this call in SPINInferences.run:
Map<Resource,List<QueryWrapper>> cls2Query =
SPINQueryFinder.getClass2QueryMap(queryModel, queryModel, rulePredicate, true,
initialTemplateBindings, false);
> - use named graphs to physically store all relevant
> sub-graphs in the same SDB. Then SDB can build a shared index
> for the whole union graph, which you can then query with best
> performance.
In this scenario you'd have to include all the T-Box models in the SDB store
too, right? And then they could be re-loaded from file on restart so changes
to them can be effected in the store.
Also, I was planning on saving a lot of different named A-Box graphs (not to
mention T-Box graphs) in the SDB store who's names I won't know until runtime.
But for each query I will only want specific graphs queried, not all of them.
So using <urn:x-arq:UnionGraph> I don't think will work for my case, right?
Which means I'll have to generate and insert GRAPH clauses in my queries "on
the fly". If so, I think that could get fairly complicated, but I need to look
into all the different ways named graphs can be specified within a query.
Thanks!
Jeff
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf
> Of Holger Knublauch
> Sent: Monday, December 21, 2009 6:22 AM
> To: [email protected]
> Subject: Re: [tbc-users] Re: Auto add spin subclass inferences
>
>
> On Dec 20, 2009, at 3:49 PM, Jeffrey Schmitz wrote:
>
> > Just a quick point before I look into how to use union graphs.
> >
> > The SDB backed model I was using wasn't an OntModel, it was just
> > produced by copying the OntModel into it. e.g.
> >
> > _store = SDBFactory.connectStore("sdb.ttl");
> > Model _sdbModel =
> > SDBFactory.connectNamedModel(_store, URI);
> > _sdbModel.add(ontModel)
> >
> > but it seemed to still be much slower than just using a purely in
> > memory model.
>
> Sure. Of course any DB-backed solution will be slower than an
> in-memory one. You can work around some slowness with careful
> engineering. For example,
>
> - compute the class-to-rule mapping only once (walking the
> SPIN RDF syntax expressions might be slow on a DB).
> - if there are no cycles in your rules, then the inferred
> triples can be written to an in-memory model to prevent many
> small update requests.
> - use named graphs to physically store all relevant
> sub-graphs in the same SDB. Then SDB can build a shared index
> for the whole union graph, which you can then query with best
> performance.
> - use TDB as a local cache that is mirrored with an SDB. This
> will boost performance because TDB will (esp on 64 bit) do
> smart caching so that most operations are in fact done in
> memory. You can synchronize any write operations with
> GraphListeners into the underlying SDB.
>
> >
> > Since the only reason for me to persist the inferred models
> would be
> > for debugging, I think using the memory only inference
> models (with an
> > option to make them SDB backed) may be the way to go. The drawback
> > will be that I'll have to re-generate the inference models on any
> > change to the SDB backed "base" model, right?
> >
> > So, right now I'm thinking of managing the following three
> Models (not
> > OntModels) during runtime for each "A-Box" model that needs to be
> > persisted .
> >
> > 1. A SDB backed baseModel that just contains the A-Box
> model triples
> > 2. A memory only memModel that is basically a copy of an OWL_MEM
> > OntModel based on the baseModel, with possibly some
> specially selected
> > SPIN inferences.
> > 3. A memory only infModel that is a copy of the memModel,
> plus all the
> > generalized SPIN Inferences (mainly those attached to OWL:Thing).
> >
> > Any comments on this approach?
>
> If you have partitioned your model into sufficiently small
> chunks, then you could save many small transactions by doing
> a batch copy of the whole named graph into a memory model for
> inferencing. In general though I think you may want to look
> into using TDB (in conjunction with SDB) to get the best of
> both worlds.
>
> BTW I have clarified the contract of the init method (see
> your other message). It does not require an OntModel, but any
> Model that contains the relevant triples (e.g. in a separate
> named graph).
>
> Holger
>
> --
>
> You received this message because you are subscribed to the
> Google Groups "TopBraid Composer Users" group.
> To post to this group, send email to
> [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/topbraid-composer-users?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"TopBraid Composer Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/topbraid-composer-users?hl=en.
