You can use the SPARQL federate query mechanism for something like this: https://www.w3.org/TR/sparql11-federated-query/
You would federate over a group of Fuseki instances or a single Fuseki instance with multiple TDB datasets loaded. Keep in mind that you will have to pay attention to how to shard triples into different stores to have performant query, but you would have to do that for any way of partitioning the data. Dick's Mosiac technology might be a better approach or not, depending on your use cases and comfort with the cutting edge. ajs6f > On Dec 14, 2017, at 1:19 AM, Laura Morales <[email protected]> wrote: > > Hi all, > > reading the TDB assembler doc [1], I was wondering how easy/difficult it > would be to support multiple ja:graph for a ja:namedGraph, so that a large > graph such as Wikidata could potentially be split into smaller graphs. > Alternatively, since SPARQL supports multiple FROM instructions, there could > be an option to configure "aliases" so that if the user writes "FROM > <wikidata>" this will be translated to "FROM <wikidata-store1> > <wikidata-store2> ..." where each <wikidata-storeN> is its own ja:namedGraph. > > I think this could be equivalent to tdb:unionDefaultGraph, but instead of > being a union among *all* graphs, only a union among a limited selection of > graphs. It kinda sounds easy in theory, since it seems like a particular case > of tdb:unionDefaultGraph, but... I don't know in practice if this would be > possible? > > [1] https://jena.apache.org/documentation/tdb/assembler.html
