W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2006

[OK?] Re: BASE absolute IRIs

From: Eric Prud'hommeaux <eric@w3.org>
Date: Tue, 17 Jan 2006 02:44:12 -0500
To: Richard Newman <rnewman@tellme.com>
Cc: public-rdf-dawg-comments@w3.org, Benjamin Nowack <bnowack@appmosphere.com>
Message-ID: <20060117074412.GU17752@w3.org>
On Fri, Dec 09, 2005 at 04:47:27PM -0800, Richard Newman wrote:
> Hi all,
>   Firstly, an editorial erratum I just noticed in 2.1.1:
> "come from a an encapsulating..."
> =>
> "come from an encapsulating..."


>   Secondly, a thorny issue. Benjamin Nowack just raised an  
> interesting point in #swig.
>   BASE <> is a valid part of a SPARQL query (grammar productions 3,  
> 66). However:
> "The BASE keyword defines... per RFC3986..."
>   now, the cited RFC states that "A base URI must conform to the  
> <absolute-URI> syntax rule (Section 4.3)." (RFC3986, 5.1) -- i.e.,  
> if BASE is provided, it *must* be an absolute URI. If BASE is not  
> provided, then either it must be drawn from the environment as per  
> RFC3986 5.1.2, or all IRI references must be absolute.
>   So, two conclusions:
> 1.a) The grammar should state that the BASE production must yield an  
> absolute IRIref, not just an IRIref.
>   b) Mention this in the text.
> 2.   Expand 2.1.1 to suggest ways in which the environment might  
> yield a BASE IRI.
>      I suggest the following as a partial list:
>   - HTTP URI of the query service (particularly services which are  
> also URIQA-capable). E.g., if I POST a SPARQL query to
> http://example.com/sparql/
> and the query includes BASE <>, then the base IRI should be <http:// 
> example.com/sparql/>.
>   If I GET a query:
> http://example.com/sparql/?q=PREFIX...
> I would expect the same base IRI.
>   - A command-line parameter
>   - Referer or other HTTP headers
>   - Surrounding XML environments, such as SOAP envelopes
>   - Other content types with relevant headers, such as MIME  
> multipart documents.

RFC 3986 identifies the precedncee of the above list. The current
SPARQL Query text
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 a 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.
was intended to clarify how the 3986 rules would be applied to
SPARQL. The BASE directive, MIME or XML context, and GET location are
mentioned explicitly. The SPARQL language specification does not talk
about applications; would this addendum satisfy you:?
If none of the above specifies the Base URI, the default Base URI
(5.1.4, Default Base URI) is used.

RFC3986 5.1.3 is intended to apply to the address where a query was
retrieved. A query service that supplied it's own address as a Base
URI would be supplying a default Base URI per 5.1.4 . I believe that
POST URIs don't even have "Retrieval URIs" unless they POST created a
resource that came back in a Location header.

As to whether the base must be absolute, one could construct a case
where a relative BASE URI was combined with an absolute default Base
URI.  However, I expect it would less confusing if we simply specifiy
in the grammar that the BASE URI argument must be absolute. Would
adding the text
BASE URIs must be absolute.
to section A.1 IRI References address this comment?

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Tuesday, 17 January 2006 07:44:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:22 UTC