You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Robert Vesse <rv...@cray.com> on 2011/11/07 18:24:36 UTC
Adding FROM/FROM NAMED support to Fuseki?
Hi All
Following up on a previous discussion by colleague Tim had (http://mail-archives.apache.org/mod_mbox/incubator-jena-users/201102.mbox/%3C4D4DB755.1060803@epimorphics.com%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
Re: Adding FROM/FROM NAMED support to Fuseki?
Posted by Andy Seaborne <an...@apache.org>.
Great, thanks - I'll look and incorporate it ASAP. If there are any
questions, I'll ask on the JIRA (JIRA comments are also sent to the
developers list).
Andy
On 10/11/11 22:20, Robert Vesse wrote:
> I now have this support working and configurable using a --from switch on the command line or ARQ.setContext(Fuseki.enableFromClauses, true) programmatically. I have submitted a patch with some tests for this as JENA-162 [1], if this can be reviewed and include in trunk ASAP we'd be extremely grateful
>
> Regards,
>
> Rob Vesse
>
> [1]: https://issues.apache.org/jira/browse/JENA-162
>
> -----Original Message-----
> From: Robert Vesse [mailto:rvesse@cray.com]
> Sent: Thursday, November 10, 2011 1:07 PM
> To: jena-users@incubator.apache.org
> Subject: RE: Adding FROM/FROM NAMED support to Fuseki?
>
> It works fine with a persistent TDB disk based dataset so I'm going to assume the changes work. I'll write up some test cases over the next few hours and then submit the patch to JIRA
>
> Does anyone have a preference whether I make this behavior configurable? i.e. add a command line switch which disables FROM/FROM NAMED support or shall I leave this up to you guys to decide at a later date?
>
> Cheers,
>
> Rob
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
> Sent: Thursday, November 10, 2011 6:17 AM
> To: jena-users@incubator.apache.org
> Subject: Re: Adding FROM/FROM NAMED support to Fuseki?
>
> On 09/11/11 19:16, Robert Vesse wrote:
>> So following this up further. I got the 0.2.1-incubating-SNAPSHOT building, made my changes to enable FROM/FROM NAMED and ran it locally via Eclipse
>>
>> I loaded the same data, in the same way using a TDB memory dataset (--mem option) like my previous email and still saw the same incorrect behavior, FROM clauses do not seem to be respected by TDB
>
> Not quite right. "--mem" creates an ARQ-based in-memory database
> unrelated to TDB. --loc triggers TDB.
>
> Try a small persistent one.
>
> (I haven't tried but --loc="--mem--" may work - it's the name of the
> in-memory location)
>
>>
>> So what I found was that I did need to also alter decideDataset() so that DynamicDatasets.dynamicDataset() will be used to create the dataset and then that exhibits the correct behavior.
>>
>> I will write up some tests for this and then go ahead and submit a patch via JIRA if that is ok?
>
> Yes - that's the new workflow.
>
> Andy
>
>>
>> Rob Vesse
RE: Adding FROM/FROM NAMED support to Fuseki?
Posted by Robert Vesse <rv...@cray.com>.
I now have this support working and configurable using a --from switch on the command line or ARQ.setContext(Fuseki.enableFromClauses, true) programmatically. I have submitted a patch with some tests for this as JENA-162 [1], if this can be reviewed and include in trunk ASAP we'd be extremely grateful
Regards,
Rob Vesse
[1]: https://issues.apache.org/jira/browse/JENA-162
-----Original Message-----
From: Robert Vesse [mailto:rvesse@cray.com]
Sent: Thursday, November 10, 2011 1:07 PM
To: jena-users@incubator.apache.org
Subject: RE: Adding FROM/FROM NAMED support to Fuseki?
It works fine with a persistent TDB disk based dataset so I'm going to assume the changes work. I'll write up some test cases over the next few hours and then submit the patch to JIRA
Does anyone have a preference whether I make this behavior configurable? i.e. add a command line switch which disables FROM/FROM NAMED support or shall I leave this up to you guys to decide at a later date?
Cheers,
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Thursday, November 10, 2011 6:17 AM
To: jena-users@incubator.apache.org
Subject: Re: Adding FROM/FROM NAMED support to Fuseki?
On 09/11/11 19:16, Robert Vesse wrote:
> So following this up further. I got the 0.2.1-incubating-SNAPSHOT building, made my changes to enable FROM/FROM NAMED and ran it locally via Eclipse
>
> I loaded the same data, in the same way using a TDB memory dataset (--mem option) like my previous email and still saw the same incorrect behavior, FROM clauses do not seem to be respected by TDB
Not quite right. "--mem" creates an ARQ-based in-memory database
unrelated to TDB. --loc triggers TDB.
Try a small persistent one.
(I haven't tried but --loc="--mem--" may work - it's the name of the
in-memory location)
>
> So what I found was that I did need to also alter decideDataset() so that DynamicDatasets.dynamicDataset() will be used to create the dataset and then that exhibits the correct behavior.
>
> I will write up some tests for this and then go ahead and submit a patch via JIRA if that is ok?
Yes - that's the new workflow.
Andy
>
> Rob Vesse
RE: Adding FROM/FROM NAMED support to Fuseki?
Posted by Robert Vesse <rv...@cray.com>.
It works fine with a persistent TDB disk based dataset so I'm going to assume the changes work. I'll write up some test cases over the next few hours and then submit the patch to JIRA
Does anyone have a preference whether I make this behavior configurable? i.e. add a command line switch which disables FROM/FROM NAMED support or shall I leave this up to you guys to decide at a later date?
Cheers,
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Thursday, November 10, 2011 6:17 AM
To: jena-users@incubator.apache.org
Subject: Re: Adding FROM/FROM NAMED support to Fuseki?
On 09/11/11 19:16, Robert Vesse wrote:
> So following this up further. I got the 0.2.1-incubating-SNAPSHOT building, made my changes to enable FROM/FROM NAMED and ran it locally via Eclipse
>
> I loaded the same data, in the same way using a TDB memory dataset (--mem option) like my previous email and still saw the same incorrect behavior, FROM clauses do not seem to be respected by TDB
Not quite right. "--mem" creates an ARQ-based in-memory database
unrelated to TDB. --loc triggers TDB.
Try a small persistent one.
(I haven't tried but --loc="--mem--" may work - it's the name of the
in-memory location)
>
> So what I found was that I did need to also alter decideDataset() so that DynamicDatasets.dynamicDataset() will be used to create the dataset and then that exhibits the correct behavior.
>
> I will write up some tests for this and then go ahead and submit a patch via JIRA if that is ok?
Yes - that's the new workflow.
Andy
>
> Rob Vesse
Re: Adding FROM/FROM NAMED support to Fuseki?
Posted by Andy Seaborne <an...@apache.org>.
On 09/11/11 19:16, Robert Vesse wrote:
> So following this up further. I got the 0.2.1-incubating-SNAPSHOT building, made my changes to enable FROM/FROM NAMED and ran it locally via Eclipse
>
> I loaded the same data, in the same way using a TDB memory dataset (--mem option) like my previous email and still saw the same incorrect behavior, FROM clauses do not seem to be respected by TDB
Not quite right. "--mem" creates an ARQ-based in-memory database
unrelated to TDB. --loc triggers TDB.
Try a small persistent one.
(I haven't tried but --loc="--mem--" may work - it's the name of the
in-memory location)
>
> So what I found was that I did need to also alter decideDataset() so that DynamicDatasets.dynamicDataset() will be used to create the dataset and then that exhibits the correct behavior.
>
> I will write up some tests for this and then go ahead and submit a patch via JIRA if that is ok?
Yes - that's the new workflow.
Andy
>
> Rob Vesse
RE: Adding FROM/FROM NAMED support to Fuseki?
Posted by Robert Vesse <rv...@cray.com>.
So following this up further. I got the 0.2.1-incubating-SNAPSHOT building, made my changes to enable FROM/FROM NAMED and ran it locally via Eclipse
I loaded the same data, in the same way using a TDB memory dataset (--mem option) like my previous email and still saw the same incorrect behavior, FROM clauses do not seem to be respected by TDB
So what I found was that I did need to also alter decideDataset() so that DynamicDatasets.dynamicDataset() will be used to create the dataset and then that exhibits the correct behavior.
I will write up some tests for this and then go ahead and submit a patch via JIRA if that is ok?
Rob Vesse
-----Original Message-----
From: Robert Vesse [mailto:rvesse@cray.com]
Sent: Wednesday, November 09, 2011 10:24 AM
To: jena-users@incubator.apache.org
Subject: RE: Adding FROM/FROM NAMED support to Fuseki?
So to follow up on this
Using the 0.2.1-SNAPSHOT even with FROM/FROM NAMED allowed TDB does not behave correctly. The only change I made to the snapshot code was to disable the error on FROM/FROM NAMED, I removed my attempts at changing the dataset in decideDataset() and left the default behavior in place.
I put a couple of triples in the default Graph and a couple in a named Graph.
Doing the following showed the triples in their correct graphs:
SELECT * WHERE { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } }
Doing the following shows just the triples in the default graph selected:
SELECT * WHERE { ?s ?p ?o }
Doing the following which I'd expect to give the triples from the named graph instead gave back the triples from the default graph:
SELECT * FROM <http://example.org/graph> WHERE { ?s ?p ?o }
Which dev branch are you talking about here? Are you talking about the 0.2.1-incubating-SNAPSHOT which for the record is really awkward to build right now as the only way to do it seems to be to check out the Trunk of each component into adjacent directories and then run mvn commands. This is kinda really clunky particularly if you do the typical thing of checking out the entire repo (or at least the component you care about) only to find it is not buildable without a specific directory structure.
I have about got this in place and building so will go ahead and test against that and see if that works for me and get back to you
Regards,
Rob Vesse
-----Original Message-----
From: Robert Vesse [mailto:rvesse@cray.com]
Sent: Wednesday, November 09, 2011 8:45 AM
To: jena-users@incubator.apache.org
Subject: RE: Adding FROM/FROM NAMED support to Fuseki?
Ok, we're working against the 0.2.0 Fuseki codebase atm so will try against the development branch and see what happens
Thanks,
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Wednesday, November 09, 2011 5:19 AM
To: jena-users@incubator.apache.org
Subject: Re: Adding FROM/FROM NAMED support to Fuseki?
On 08/11/11 23:11, Robert Vesse wrote:
> 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
"loading the" ??? URL from the web?
Fuseki does this when the request is to the general query processor (on
"/sparql" and code in SPARQL_QueryGeneral).
I commented out the code in SPARQL_QueryDataset.validateQuery which
checked for FROM/FROM NAMED. Then I made a query to a TDB dataset is
getting to TDB and triggering dynamic dataset processing.
(current development codebase)
Yes, QueryEngineTDB creates a new DatasetGraph internally but it's
rooted to the database but I'm guessing this is what you mean.
> 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.
TDB does not ignore it - see QueryEngineTDB and
DynamicDatasets.dynamicDataset.
Andy
RE: Adding FROM/FROM NAMED support to Fuseki?
Posted by Robert Vesse <rv...@cray.com>.
So to follow up on this
Using the 0.2.1-SNAPSHOT even with FROM/FROM NAMED allowed TDB does not behave correctly. The only change I made to the snapshot code was to disable the error on FROM/FROM NAMED, I removed my attempts at changing the dataset in decideDataset() and left the default behavior in place.
I put a couple of triples in the default Graph and a couple in a named Graph.
Doing the following showed the triples in their correct graphs:
SELECT * WHERE { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } }
Doing the following shows just the triples in the default graph selected:
SELECT * WHERE { ?s ?p ?o }
Doing the following which I'd expect to give the triples from the named graph instead gave back the triples from the default graph:
SELECT * FROM <http://example.org/graph> WHERE { ?s ?p ?o }
Which dev branch are you talking about here? Are you talking about the 0.2.1-incubating-SNAPSHOT which for the record is really awkward to build right now as the only way to do it seems to be to check out the Trunk of each component into adjacent directories and then run mvn commands. This is kinda really clunky particularly if you do the typical thing of checking out the entire repo (or at least the component you care about) only to find it is not buildable without a specific directory structure.
I have about got this in place and building so will go ahead and test against that and see if that works for me and get back to you
Regards,
Rob Vesse
-----Original Message-----
From: Robert Vesse [mailto:rvesse@cray.com]
Sent: Wednesday, November 09, 2011 8:45 AM
To: jena-users@incubator.apache.org
Subject: RE: Adding FROM/FROM NAMED support to Fuseki?
Ok, we're working against the 0.2.0 Fuseki codebase atm so will try against the development branch and see what happens
Thanks,
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Wednesday, November 09, 2011 5:19 AM
To: jena-users@incubator.apache.org
Subject: Re: Adding FROM/FROM NAMED support to Fuseki?
On 08/11/11 23:11, Robert Vesse wrote:
> 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
"loading the" ??? URL from the web?
Fuseki does this when the request is to the general query processor (on
"/sparql" and code in SPARQL_QueryGeneral).
I commented out the code in SPARQL_QueryDataset.validateQuery which
checked for FROM/FROM NAMED. Then I made a query to a TDB dataset is
getting to TDB and triggering dynamic dataset processing.
(current development codebase)
Yes, QueryEngineTDB creates a new DatasetGraph internally but it's
rooted to the database but I'm guessing this is what you mean.
> 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.
TDB does not ignore it - see QueryEngineTDB and
DynamicDatasets.dynamicDataset.
Andy
RE: Adding FROM/FROM NAMED support to Fuseki?
Posted by Robert Vesse <rv...@cray.com>.
Ok, we're working against the 0.2.0 Fuseki codebase atm so will try against the development branch and see what happens
Thanks,
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Wednesday, November 09, 2011 5:19 AM
To: jena-users@incubator.apache.org
Subject: Re: Adding FROM/FROM NAMED support to Fuseki?
On 08/11/11 23:11, Robert Vesse wrote:
> 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
"loading the" ??? URL from the web?
Fuseki does this when the request is to the general query processor (on
"/sparql" and code in SPARQL_QueryGeneral).
I commented out the code in SPARQL_QueryDataset.validateQuery which
checked for FROM/FROM NAMED. Then I made a query to a TDB dataset is
getting to TDB and triggering dynamic dataset processing.
(current development codebase)
Yes, QueryEngineTDB creates a new DatasetGraph internally but it's
rooted to the database but I'm guessing this is what you mean.
> 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.
TDB does not ignore it - see QueryEngineTDB and
DynamicDatasets.dynamicDataset.
Andy
Re: Adding FROM/FROM NAMED support to Fuseki?
Posted by Andy Seaborne <an...@apache.org>.
On 08/11/11 23:11, Robert Vesse wrote:
> 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
"loading the" ??? URL from the web?
Fuseki does this when the request is to the general query processor (on
"/sparql" and code in SPARQL_QueryGeneral).
I commented out the code in SPARQL_QueryDataset.validateQuery which
checked for FROM/FROM NAMED. Then I made a query to a TDB dataset is
getting to TDB and triggering dynamic dataset processing.
(current development codebase)
Yes, QueryEngineTDB creates a new DatasetGraph internally but it's
rooted to the database but I'm guessing this is what you mean.
> 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.
TDB does not ignore it - see QueryEngineTDB and
DynamicDatasets.dynamicDataset.
Andy
RE: Adding FROM/FROM NAMED support to Fuseki?
Posted by Robert Vesse <rv...@cray.com>.
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:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Monday, November 07, 2011 2:44 PM
To: jena-users@incubator.apache.org
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/%3C4D4DB755.1060803@epimorphics.com%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
>
Re: Adding FROM/FROM NAMED support to Fuseki?
Posted by Andy Seaborne <an...@apache.org>.
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/%3C4D4DB755.1060803@epimorphics.com%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
>