On 11/06/14 15:49, Claude Warren wrote:
does the SPARQL Service recommendation say anything about this case?
Short question ... long not-really-an-answer.
"No" with caveats:-)
And SPARQL Update.
Base URI processing comes from RFC 3986, the URI spec, section 5.1. It
is a bit of a perma-thread when it comes to applying it to incoming
content (e.g. LDP does something different on POST to a container).
For a SPARQL Service request there is a base URI ... it is almost
certainly not what you want :-) as it's the whole request URL so
1/ It changes across GET and POST for the same query!
POST has no ?query=... in the URL.
2/ For GET it includes the HTTP query string, i.e. the query itself!!
../dataset/query?query=SELECT%20*%20...
so you could make <s> and <../s> do useful things but <#ref> is going to
be very, very bizarre.
The solution is "don't" at least for query.
SPARQL Update is in a better position because the base URL is a bit more
sane (always the POST case) , but it matters more for update. I think
the idea, blank sheet design asent RFGC 3986 is the base is the dataset
URL, but by RFC it is to my reading strictly the endpoint URL (in
Fuseki, "...dataset/update" not ".../dataset").
There are some people who passionately believe in relative URLs in data
and their use cases aren't all ridiculous or contorted.
SPARQL Update should behave, on INSERT DATA, in the same style as
POST/PUT of a data file. That is the one of the points of contention
because the RFC really was written for a different world.
And there is a case that the URLs should be GRAPH relative.
Andy
On Wed, Jun 11, 2014 at 12:20 PM, Rob Vesse <[email protected]> wrote:
Hi All
On behalf on my employer I reported an interesting quirk of ARQ that may be
a bug/feature depending on your point of view. You can read the full
details and developer discussion at JENA-712
(https://issues.apache.org/jira/browse/JENA-712)
Essentially given a query like the following:
SELECT * WHERE { <path/to/thing> a ?type }
ARQ internally resolves the relative URI using an implicit Base URI to
allow
the query to parse, when it serialises the query back out e.g. for
transmitting to a remote SPARQL service it omits a BASE declaration and
sends the query with the relative URIs in it. This can happen when you
either don't specify a Base URI at all or when you call
QueryFactory.create() using the overloads that take a Base URI.
In some cases this may be the desired behaviour but in others this may not
I.e. what you actually wanted to send to the remote service was the query
with the relative URI resolved into their absolute form.
There are several options for resolving this being discussed, at the very
least this behaviour will be made configurable to accommodate both use
cases
and as such we would like to hear user input on what the default behaviour
should be?
Should the default behaviour:
* Remain the same as current releases I.e. implicit base URIs are not
included in serialised SPARQL
* Change for future releases I.e. implicit base URIs are included in
serialised SPARQL
Thanks for your input,
Rob
