W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

Re: [TF-PP] IRI and base URIs

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Thu, 27 May 2010 14:01:10 +0100
Message-ID: <4BFE6D16.30003@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
The trouble I see is that base URI is used by the parser, but then 
execution of the query requires access to it.  That's no problem for my 
implementation (the run time has access to all the details of the query 
anyway; bit of an elephant that never forgets) but I can envisage cases 
where the function is not run in the same process as the parser.

The "<>" in IRI(CONCAT(STR(<>), "foo")) is sorted out by the parser, not 
left to the execution of the expression.

We might as well require resolution if that is what people want.  I was 
just defining the important case and leaving the rest to error (which an 
implementation can replace with what it decides to do).  I'll likely 
implement relative IRI resolution anyway.

	Andy

On 27/05/2010 12:35 PM, Steve Harris wrote:
> On 2010-05-27, at 12:08, Andy Seaborne wrote:
>>
>>
>> On 27/05/2010 11:39 AM, Steve Harris wrote:
>>> I would very much like it to be defined for IRI inputs too,
>> Yes, that's sensible.
>>
>>> As per the subject, is IRI("foo") intended to return<foo>   relative to the base, or be an error?
>>
>> Defined as error.<foo>  is not an absolute IRI.  What I don't want is making it spec-legal to generate relative IRIs when RDF s defined around absolute URIs.
>
> Agreed, but, given a query with a base URI of<http://foo.example/>, and IRI("bar"), a reasonable return value would be<http://foo.example/bar>, I have no strong feelings about whether this would be useful, but it wouldn't be especially hard to implement.
>
>> Your implementation can do different, errors are an extension point.
>>
>> (There isn't a sensible base anyway.  If the data comes from several files, there isn't necessary one base anyway.  The base of the query is accessible if really needed, and if there is one, but that can be used by the application writer anyway with str(<>))
>
> Well, something like IRI(CONCAT(STR(<>), "foo")) is not the same as determining<foo>  relative to the base URI, as the rules are somewhat complex.
>
> 4.1.1 * of SPARQL 1.0, along with RFC3986 implies that all queries have a base URI, though it could still be not possible to construct a legal URI of course.
>
> * http://www.w3.org/TR/rdf-sparql-query/#QSynIRI
>
> - Steve
>
>>> On 2010-05-27, at 10:45, Andy Seaborne wrote:
>>>
>>>> While we're in and around the subject of base URIs:
>>>>
>>>> The IRI function takes a string and produces an IRI: I propose that we define it only for valid, absolute IRIs, and anything else is an error.
>>>>
>>>> Creating relative IRIs is plain bad, albeit occasionally necessary.
>>>>
>>>> Errors in SPARQL can be replaced in an implementation by doing something but it indicates the something outside the spec.
>>>>
>>>> IRI("foo")
>>>> IRI("http://example/a space")
>>>> IRI("http://example/[]")
>>>> IRI("http://192.168.1.999/a")
>>>>
>>>> The string is not automatically %-encoded - if that's needed, then call another function to perform the operation.
>>>>
>>>> 	Andy
>>>>
>>>
>
Received on Thursday, 27 May 2010 13:01:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT