Re: Injective Quality (Was: Re: URIs quack like a duck)

On Mon, May 29, 2000 at 08:54:23PM -0400, Clark C. Evans wrote:
> On Mon, 29 May 2000, Michael Mealling wrote:
> > On Mon, May 29, 2000 at 07:15:09PM -0400, Clark C. Evans wrote:
> > > The problem with URLs is that, in general, they
> > > lack this injective quality.  In other words, 
> > > I can find N distinct URLs that identify
> > > (resolve to) the same resource.
> > 
> > Just because two identifiers identify the same sequence of bits
> > doesn't mean they're equal. One may give different levels of 
> > service, policy, legal resource, jurisdiction, etc than the other.
> 
> This is a very good explanation!  However, I must say that 
> your average XML user would define the "resource" for an 
> "http:" URL as the text returned from the request.  And you 
> must admit, this does have some validity to it.   For this 
> definition, URLs do not have the injective property referred.

Huh? The average XML users is well aware of the content-negotiation
aspects of HTTP and can very easily understand that given a URI
of "http://something.com/foo" they may get text, html or xml
depending on what they ask for. People have been living with this
aspect of FTP for more than a decade....

The average user would correctly say that the text returned from
the request. But that same average user would not balk at all
with there being multiple representations of the same resource.

> > I.e. its a statement about uniform equality:
> > 
> > If uri-canonicalization-function(uri1) = uri-canonicalization-function(uri2)
> > then in ALL cases you can assume that, at that  time, the resource identified 
> > by iri1 and uri2 are equal
> > 
> > If uri-canonicalization-function(uri1) != uri-canonicalization-function(uri2)
> > then, <strong>based on that information alone</strong>, there is NO case in 
> > which you can assume the two resource are equal.
> 
> It is this second (weak) property of URIs which makes it poor 
> for namespaces.  What we desire is a much stronger version,

Ok. I'll ask this question again: are you suggesting that your desire
for a particular behavior should by its nature deny me the ability
to choose a different behavior?

> If uri-canonicalization-function(uri1) != uri-canonicalization-function(uri2)
> then, in ALL cases you can assume that, at that time, the resource identified
> by iri1 and iri2 are NOT equal.

Umm.... that's a simple restatement of my conditional...
Are you balking at the bit about "based on that information alone" bit?


> equivalently, I feel that this (very strong) property is needed...
>   
>   For all x,y in set-of-acceptable-URI,
>       (x != y) implies ( x' != y' )
>   where 
>     z' is the resource identified by the resource z.

By definition that is the case. What's the difference between that and my
statement of the equivalent? I.e. how are you defining '=' and '!='?
Bit equivalence? If so then that's silly....

Are you instead wanting to say this:

If (x != y) then (x' can never equal y' in any circumstance whatsoever)?

If so then that's called a perfect hash function and they don't exist
unless x = x'. I.e. you want the impossible. Plus, who really cares
if x' and y' might be equal according to some third part. 

> > > I am reading into your example above this
> > > injective quality.  Am I correct? 
> > 
> > Yes. As far as what you are allowed to assume based on what the
> > URI specification says once you've done the canonicalization step.
> 
> I was actually referring to URNs.  Do URNs have the *strong* 
> property described above?  If so, then perhaps the Namespace 
> spec should be updated to use URNs instead of URIs.  
> If not, then what properties do URNs have that more 
> general URIs do not?

URNs are URIs. A URN is simply a URI scheme which has the required properties
of non-reassignability and uniqueness. I.e. once a URN is bound to its
resource, at any time in the future, you MUST assume that it is still bound
to that resource.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Monday, 29 May 2000 21:26:11 UTC