Re: [TF-PP] IRI and base URIs

Ah, that's a good point, it hand't occurred to me that it was being done in the parser, though that's obviously true.

Wouldn't be a problem for us either, but it could well be for some.

- Steve

On 2010-05-27, at 14:01, Andy Seaborne wrote:

> 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
>>>>> 
>>>> 
>> 

-- 
Steve Harris, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Thursday, 27 May 2010 14:20:07 UTC