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
