Hi Andy So my approach certainly works as far as constructing a dataset goes but it still doesn't do what I wanted it to do. The problem is that it goes away and builds a fresh dataset from scratch based on the URIs that get passed to it. So when I tested it against TDB I find that whenever I specify a FROM/FROM NAMED I get the wrong results because it builds the dataset by loading the
What I want it to do is to pull out the graphs to be used from the underlying storage but I have no idea whether that is in any way possible? Perhaps you can enlighten me on this because I can't see any obvious way of doing this in code. If this is not possible then we're stuck with just disabling the error thrown when FROM/FROM NAMED is specified and hoping that the underlying store supports this feature somehow but certainly TDB appears to ignore it entirely. Cheers, Rob -----Original Message----- From: Andy Seaborne [mailto:[email protected]] On Behalf Of Andy Seaborne Sent: Monday, November 07, 2011 2:44 PM To: [email protected] Subject: Re: Adding FROM/FROM NAMED support to Fuseki? Hi Rob, Re: FROM/FROM NAMED processing With TDB, the dataset for the query still matters because FROM/FROM NAMED are used to select the graphs out of the dataset. The TDB query engine still needs to know what the base dataset is. What's more the dataset is used when deciding the correct query execution factory. So the Fuseki changes, if the store is TDB, is just not to check but still configure the server with a dataset. (sorry - I haven't had the chance to try this out - if you do try, please let us know). What might need adding, depending on your expected usage is translating protocol parameters default-graph-uri and named-graph-uri into FROM/FROM NAMED for query. If an engine doesn't handle dataset descriptions, it should complain (although it might ignore it). If you want to force FROM/FROM NAMED even though there is an underlying datasets, then maybe adding a wrapper query engine that takes queries, does whatever processing you want (security masking maybe) and passes the corrected query down to TDB. > Also how would you suggest handling the second case where we have > some FROM NAMED clauses but no FROM clauses i.e. the default graph > remains unchanged. How exactly do we construct a dataset that > expresses that? Re: real default graph In SPARQL, if there is a dataset description, then it's a complete description. If there is a FROM NAMED but no FROM then the default is empty. You can name the real one with <urn:x-arq:DefaultGraph> Andy > Hi All > > Following up on a previous discussion by colleague Tim had (http://mail-archives.apache.org/mod_mbox/incubator-jena-users/201102.mbox/%[email protected]%3E) with regards to adding FROM/FROM NAMED support to Fuseki. > > We need this for our own work so are willing to do the coding and submit it to the project as a patch we'd just appreciated some guidance on how best to implement this. > > It is easy to find where to turn off the automatic error messages for use of a FROM/FROM NAMED clause as that just requires commenting out a couple of lines of code in SPARQL_QueryDataset in the validateQuery() method. What we are struggling to understand is how we can actually get the dataset to change, there is a decideDataset() method which would seem to be the obvious place to make changes to the dataset and this is what we have so far: > > @Override > protected Dataset decideDataset(HttpActionQuery action, Query query, String queryStringLog) > { > if (query.hasDatasetDescription()) > { > if (query.getGraphURIs().size()> 0) > { > return DatasetFactory.create(query.getGraphURIs(), query.getNamedGraphURIs(), null, null); > } > else > { > //TODO: How do we create a dataset that preserves the known default graph and just adds the named graphs? > errorBadRequest("Query with FROM NAMED without any FROM clauses not yet supported"); > return null; > } > } > else > { > return DatasetFactory.create(action.dsg) ; > } > } > > Are we on the right lines here or is this not an appropriate place/way to achieve this? > > Also how would you suggest handling the second case where we have some FROM NAMED clauses but no FROM clauses i.e. the default graph remains unchanged. How exactly do we construct a dataset that expresses that? > > Thanks, > > Rob Vesse >
