> I have no personal experience with this approach yet, so it will > need some exploration. But using named graphs sounds like the best > way to make use of the native SPARQL optimizations for SDB (and TDB).
I haven't looked at exactly how the optimizations work. Might the SDB and TDB models be even faster than purely in-memory models? On Dec 23, 2009, at 2:03 AM, Holger Knublauch wrote: >> >>> - 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); > > Yes, because the QueryWrapper holds the Jena Queries in pre-compiled > form. Assuming your rules don't change at run-time, it's enough to > compute this once. > >> >> >>> - 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? > > Yes, I guess so because the SPIN rule engine will need to walk the > class hierarchy to figure out which rules to fire. > >> 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. > > I have no personal experience with this approach yet, so it will > need some exploration. But using named graphs sounds like the best > way to make use of the native SPARQL optimizations for SDB (and TDB). > > 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.
