Re: IRIs

> 
> Michael Kifer wrote:
> >> Michael Kifer wrote:
> >>> Thanks. I think this answers my question.
> >>> My concern was that there might be an IRI, x, such that its encoding as a URI,
> >>> f(x), is not equivalent to x *as an IRI*.
> >>> You seems to be saying that this is not possible.
> >> Sandro's Kanji example illustrates that this is possible. If an IRI i 
> >> isn't itself a URI then the URI encoding of it must be different. Unless 
> >> you specify some normalization f(i) and i are different.
> > 
> > Of course they are different. I was talking of them being *equivalent*.
> 
> RFC3987 uses the term "different" as the negation of "equivalent":
> 
> [[[ (Section 5.1)
>     For this reason, determination
>     of equivalence or difference of IRIs is based on string comparison,
>     perhaps augmented by reference to additional rules provided by URI
>     scheme definitions.  We use the terms "different" and "equivalent" to
>     describe the possible outcomes of such comparisons, but there are
>     many application-dependent versions of equivalence.
> ]]]
> 
> and goes on to say:
> 
> [[[
>     Applications using IRIs as identity tokens with no relationship to a
>     protocol MUST use the Simple String Comparison (see section 5.3.1).
> ]]]
> 
> I claim RIF usage, like RDF usage, would fall under this clause and so 
> we would not specify any additional normalization step or RIF-specific 
> notion of equivalence. Hence the properties described in Jeremy's 
> semi-parallel email apply.

OK. But it wasn't clear to me from Sandro's email that encoded URIs when
viewed as IRIs are non-equivalent to the original. I think he said just the
opposite. And so did Jeremy as far as I understand.

In any case, are you proposing that if we have an IRI, x, and its encoded
form, enc(x), then x and enc(x) would be allowed to point to different
resources? I am slightly uncomfortable with this, but could live with it.


	--michael