Re: [proto-wd] determining the base IRI

"Seaborne, Andy" <andy.seaborne@hp.com> wrote on 02/09/2007 09:04:42 AM:

> Lee Feigenbaum wrote:
> > Hi everyone,
> > 
> > Re: ACTION: Lee to adapt text from 4.1.1 to specify how the protocol 
can 
> > contribute to the base IRI for query evaluation as per #relIRIs in the 
QL 
> > spec
> > 
> > At the end of this week's teleconference, Eric and I discussed whether 
the 
> > protocol specification should discuss how it contributes to 
determination 
> > of the base IRI used for resolving relative IRIs when 
parsing/executing a 
> > SPARQL query.
> > 
> > Currently, rq25 already contains this text in 4.1.1 Syntax for IRIs > 
> > Relative IRIs:
> > 
> > """
> > The BASE keyword defines the Base IRI used to resolve relative IRIs 
per 
> > RFC3986 section 5.1.1, "Base URI Embedded in Content". Section 5.1.2, 
> > "Base URI from the Encapsulating Entity" defines how the Base IRI may 
come 
> > from an encapsulating document, such as a SOAP envelope with an 
xml:base 
> > directive, or a mime multipart document with a Content-Location 
header. 
> > The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval 
> > URI", is the URL from which a particular SPARQL query was retrieved. 
If 
> > none of the above specifies the Base URI, the default Base URI 
(section 
> > 5.1.4, "Default Base URI") is used.
> > """
> > 
> > (Aside: Eric, can you add in the anchor point here that we discussed? 
> > #relIRIs)
> > 
> > I took a stab at editing the protocol document (not yet checked into 
CVS) 
> > and came up with something almost identical but a bit different:
> > 
> > """
> > Determining the Base IRI
> > 
> > Relative IRIs that appear in a [SPARQL] query are resolved against a 
base 
> > IRI as per [RFC3986] section 5.1, "Establishing a Base URI". If 
present in 
> > the query, the BASE keyword defines the Base IRI used to resolve 
relative 
> > IRIs per RFC3986 section 5.1.1, "Base URI Embedded in Content". 
Otherwise, 
> > Section 5.1.2, "Base URI from the Encapsulating Entity", defines how 
the 
> > Base IRI may come from an encapsulating document, such as a SOAP 
envelope 
> > with an xml:base directive. (See 2.3 SOAP Envelope. Otherwise, the 
> > "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval 
URI", is 
> > the URL of the SPARQL protocol service implementing the SparqlQuery 
> > interface. If none of the above specifies the Base URI, the default 
Base 
> > URI (section 5.1.4, "Default Base URI") is used.
> > """
> > 
> > In particular, note the difference in how to intepret 5.1.3 of RFC3986 
- 
> > the query spec. talks about the "retrieval URI" as "the URL from which 
a 
> > particular SPARQL query was retrieved" whereas (following the 
discussion 
> > with EricP) whereas the text I came up with for the protocol spec says 

> > that the "retrieval URI" corresponds to the URL of the SPARQL service 
> > endpoint. I'm not sure which is more correct (if either), but I am 
pretty 
> > sure that the two documents should agree on their recommendation for 
> > interpreting RFC3986 5.1.3.
> > 
> > thoughts?
> 
> Some thoughts:
> 
> I didn't know what a retrieval URI is so I had to look it up. 
> RFC3986 1.2.2 says:
> 
> [[
> ...
> To use that access mechanism to perform an action on the
>     URI's resource is to "dereference" the URI.
> 
> When URIs are used within information retrieval systems to identify
>     sources of information, the most common form of URI dereference is
>     "retrieval": making use of a URI in order to retrieve a
>     representation of its associated resource.
> ]]
> which seems to define the term "retrieval URI".
> 
> The resource being retrieved is the query results.
> 
> If the GET request is made to the URL:
>    <http://example/service?query=SELECT...>
> service and query, then the retrieval URI is
>    <http://example/service?query=SELECT...>

I agree with this, and note that in the cases in which the POST is being 
used, the retrieval URI then becomes
  <http://example/service>

Note that in either case, relative URIs such as </data/my-graph> are 
usable (and useful?).

Based on this reading, both the current QL text and the proposed protocol 
text on the matter are wrong. (The QL text implies that the retrieval URI 
is a URI from which the *query* is retrieved, while the proposed protocol 
text tries to say the retrieval text is the service endpoint.) The correct 
text is something about the retrieval URI as the constructed URI used to 
send a SPARQL protocol request to a SPARQL protocol service. I'll play 
with it.
 
> 5.1.3 says:
> 
> [[
> if a URI was used to retrieve the
>     representation, that URI shall be considered the base URI.
> ]]
> which to me reading gives no license to define the "retrieval URI" other 
than 
> as the query request.  I don't see how the service is the "retrieval 
URI" 
> because the query request is the resource.
> 
> 
> Earlier in 1.2.2 it says:
> [[
> URI "resolution" is the process of
>     determining an access mechanism and the appropriate parameters
>     necessary to dereference a URI; this resolution may require several
>     iterations.
> ]]
> but I don't think that "parameters" here can mean the parameters in the 
URL, 
> more external parameters like access control.  It's not the service that 
is 
> being retrieved.
> 
> It would be nice it were <http://example/service>  - I just don't 
> read it that 
> way.

You're right; but I'm not sure why <http://example/service?query=...> is 
any less useful as a BASE IRI.

> (I'd also note that both yield fairly useless URIs in the query as it is 

> unlikely the data has URIs based at service, let alone the query 
> request itself.)
> 
> YMMV

I guess MMDV :-) In these cases I was thinking of the utility of relative 
IRIs in FROM/FROM NAMED (and GRAPH), rather than in the data itself.

Lee


>    Andy
> 
> 
> 
> 
> > 
> > Lee
> > 
> > 
>

Received on Friday, 9 February 2007 14:20:35 UTC