[TF-LIB] Encoding for IRIs

fn:encode-for-uri encodes a string for use as a path segment in

"http://example/00/Weather/CA/Los%20Angeles#ocean"
==>
"http%3A%2F%2Fexample%2F00%2FWeather%2FCA%2FLos%2520Angeles%23ocean"

which as F&O puts it: "This is probably not what the user intended 
because all of the delimiters have been encoded."

Do we want to have a similar function that encodes for an IRI?

If so, we have introduced a new function - to date, the TF-LIB list is 
the functions from F&O that make sense.  We have no new functions except 
the term constructors IRI, BNODE, STRDT, STRLANG, which are fundamental. 
  Adding new functions that are practically motivated gets slightly 
tricky as to where to stop.

We could make IRI() do that but I don't think that is a good idea. 
Currently, it captures the concept of turning strings into IRIs. 
Mangling the characters may be incorrect as the app might expect to use 
the IRI it gets back in a later query to get a match, and it won't.

 Andy

This was triggered by the thread from

http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0425.html

discussing practicalities of working with some bad-IRI data.

The original question was how to ask a SPARQL query when the data contains:

<http://example.com/mylamefoafdocument`uri> a foaf:Document .
 > <http://example.com/mylamefoafdocument`uri> foaf:primaryTopic 
<http://example.com/mylamefoafdocument`uri#me> .

which is legal Turtle in the sense it bases the basic syntax grammar 
rules.  The Turtle grammar allows anything in <> except '>' and #x3E 
which is '>' encoded. The Turtle test suite has positive tests for 
Turtle documents having bad IRIs e.g. \n.

The issue for TF_LIB does not address the original question from Mischa 
but it does bring up this nearby issue.

Received on Thursday, 29 July 2010 19:22:50 UTC