On 01/27/2013 11:01 PM, Andy Seaborne wrote:
On 27/01/13 15:30, Sarven Capadisli wrote:
Hi,

Is it possible to run a single Fuseki server with multiple TDB datasets
such that the queries span over those datasets?

The short answer is "no".

The long answer is that a union dataset could be developed that gave a
dataset view of 2+ sub-datasets.  It would not be able to push down full
queries so there are performance implications at scale but for many uses
it might be useful.

SERVICE is the nearest it gets.

(But why not use one dataset with careful named graphs?  You can use GSP
(Graph Store Protocol) to manage data which is convenient.

I am using named graphs. I understand that it can work that way, however, I find it inconvenient to drop or update graphs - and I can't say that I generally have a /good/ response rate in comparison to simply rebuilding the store. Having separate databases also makes it easier to hotswap.

For instance, a query performed at service A/query (with dataset A) may
also contain results from dataset B. And vice-versa if query performed
at service B/query.

I realize that it may be a bit too much to ask for something like this
(and probably not possible), but my idea was to use separate databases
so that I can update them independently with a lot of flexibility,
meanwhile having the SPARQL endpoint(s) see all of the data without the
need for federated queries.

What happens (= what does it mean) if both datasets have the same named
graph?

I've just tried that and it looks like it had no effect. It still showed the results from the second service.

If I use the same fuseki:name for each fuseki:Service, the last one
takes over and the query result reveals data only from its dataset.

The names have to be different.  Probably should have been a
warning/error if there is reused (patches welcome!).

Gave no warning or error.

Here is what I currently have in my TDB assembler:

https://gist.github.com/4650969

I was using the same fuseki:name in order to later have a single RewriteRule which points to the same query service e.g., http://localhost:3030/data/query to be used from different SPARQL endpoints. But I guess that's not going to happen in any case.

If you'd like me to generate a particular logging for this or force a warning/error somehow, please let me know how to go about that and I'll report back.

You'll be wanting datasets-of-datasets next!

Of course! Anything less would be uncivilized.

-Sarven

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to