- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Thu, 27 May 2010 12:08:52 +0100
- To: Steve Harris <steve.harris@garlik.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
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. 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(<>)) Andy > > - 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 11:09:23 UTC