On 14/12/17 06:19, Laura Morales 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,
That's not what ja:graph is for - it is the graph, and ja:namedGraph
adds the name.
How the graph is formed is down to the part of the assembler that
ja:graph points to. I don't know of anything for partial graphs - there
are some hard parts to that.
It you split a dataset across different storage units, query will slower
because the direct execution of TDB does not apply.
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?
tdb:unionDefaultGraph is quite specific for union and quite efficient.
Have you seen the dynamic dataset feature?
Arbitrary choices of graph mean tdb:unionDefaultGraph does not apply and
a more general, and slower, execution happens.
Andy
[1] https://jena.apache.org/documentation/tdb/assembler.html
