I was convinced that sparql-fastlane wasa laready an issue, but it doesn't seem to.
Thanks for adding the issues. Reto On Fri, Mar 18, 2011 at 12:08 PM, Olivier Grisel <[email protected]> wrote: > Hi Reto, > > Thanks for your reply, > > >> Ok thanks for your reply. Security and locking checks apart, making > >> the jena sparql engine able to fetch a TdbDataset instead of the > >> generic TcDataset wrapper would require to introduce a new dependency > >> between rdf.jena.tdb.storage and rdf.jena.sparql one way or another, > >> maybe moving the TcDataset class as an interface in the > >> rdf.jena.commons instead to avoid cyclic or unwanted dependencies. > > > > No there must not be such a dependency. The solution I think should > rougly > > look like this: TcProvider can Implement an additional Subinterface (say > > SparqlTcProvider) allowing to pass Sparql-queries to them. If a sparql > query > > affects only graphs provided by the same SparqTcProvider the the query is > > forwarded to that provider, otherwise the current process aplies. > > Understood, I opened this: > > https://issues.apache.org/jira/browse/CLEREZZA-466 > > >> Also it would be great to have support for fined grained support for > >> default and named graph in SPARQL queries with named graph mapped to > >> the Clerezza graph ids used by the TcProvider. In jena this seem to be > >> provided by: > >> > >> http://www.openjena.org/wiki/TDB/DynamicDatasets > >> > >> I wonder if this compatible with the current directory structure > >> implied by the TdbTcProvider#getMGraph implementation. > > > > I agree. Possibly changes in tdb.storage are needed. > > Ok this improvement is tracked separately here: > > https://issues.apache.org/jira/browse/CLEREZZA-467 > > I won't probably have time to work on this in the short term but other > Stanbol developers might need earlier than myself. I will tell them to > submit patches to those two issues if needed. > > -- > Olivier >
