Building a ja:RDFDataset is going to build you an in-memory dataset that does not fully support transactions, which I think is why you are getting that error. In that second config you are building a bunch of TDB databases and then taking views from them to compose an in-memory dataset, which I think is probably not what you intend to do.
ajs6f > On Nov 26, 2017, at 10:55 AM, Laura Morales <[email protected]> wrote: > > What is the difference of these two scenarios? > > 1. a dataset with all "s p o g" quads loaded into the dataset, with this > configuration > > <#dataset> rdf:type tdb2:DatasetTDB2 ; > tdb2:location "TDB2" ; > tdb2:unionDefaultGraph true . > > > 2. a dataset where each graph is in its own folder, with this configuration > > <#dataset> rdf:type ja:RDFDataset ; > ja:namedGraph > [ ja:graphName <http://example.org/g1> ; > ja:graph <#g1> ] ; > ja:namedGraph > [ ja:graphName <http://example.org/g2> ; > ja:graph <#g2> ] ; > . > > <#g1> rdf:type tdb:GraphTDB2 ; > tdb2:location "DB-1" . > > <#g2> rdf:type tdb:GraphTDB2 ; > tdb2:location "DB-2" . > > > - Is there any performance hit with the second method? > - With the second method, is it still possible to have the default union > graph of all single graphs? > - I tried to query Fuseki with the second method: > - This query works: select ?g where { graph ?g {} } > - This query returns "Error 500: Not in a transaction": > select ?s from <http://example.org/g1> where { ?s ?p ?o } limit 1
