On 23/09/11 18:19, Tim Harsch wrote:
Thanks Andy, I have additional questions now. I've now checked out
Fuseki-0.2.1-SNAPSHOT from maven and ran tests with it. The behavior I noticed
in Fuseki-0.2.0 continues. I configured it to run with a TDB database (which
has many named graphs in it) and if I attempt to use FROM/FROM NAMED in a query
passed in I get:
"Error 400: Query may not include a dataset description (FROM/FROM NAMED)"
It should work so that needs fixing.
A quick hack workaround is remove the check :-) in
SPARQL_QueryDataset.validateQuery
and it works for me. The only reason not to do this as a complete fix
is that it means different things to different storage layers. Maybe
it' needs to be an option in the config file (per service) but I'm not
rushing to add lots of options as it all gets confusing.
Which is what led me to giving Joseki a spin, cause the last I thought heard
from the mail list was that support of FROM/FROM NAMED in Fuseki is TBD (sorry
don't know where I read it, I may be in error). I think it gets rejected by
the servlets.
So I'm confused by your response about Joseki, when you say "the one case of having
FROM-web loading AND a fixed dataset isn't supported on the same service endpoint".
I am attempting to allow changing the graph the query executed on
through FROM/FROM NAMED, but I do not wish RDF datasets pulled from the
web. Which I think is this:
joseki:allowExplicitDataset "true"^^xsd:boolean ;
joseki:allowWebLoading "false"^^xsd:boolean ;
I would expect "the one case of having FROM-web loading AND a fixed dataset isn't
supported on the same service endpoint" to look like this config
joseki:allowExplicitDataset "false"^^xsd:boolean ;
joseki:allowWebLoading "true"^^xsd:boolean ;
The problem is that Joseki does all the FROM processing; it overrides
the storage layer processing that might happen. The design predates (by
a long time)
This is just one of the several reasons why I started Fuseki as a
redesign of Joseki. New capabilities (SPARQL Graph Store Protocol),
less need for arbitrary processors, better balance of responsibilities.
Andy
