Re: Possible new issue: Things with and without identity?

Am Dienstag den, 10. September 2002, um 15:40, schrieb Al Gilman:

>
> At 08:09 AM 2002-09-10, Stefan Eissing wrote:
>
>> Am Dienstag den, 10. September 2002, um 11:43, schrieb Roy T. 
>> Fielding:
>>
>>>
>>> On Monday, September 9, 2002, at 08:44  PM, Miles Sabin wrote:
>>>> A discussion point from the rest-discuss list which is probably 
>>>> better
>>>> dealt with here,
>>>>
>>>>   http://groups.yahoo.com/group/rest-discuss/message/2465
>>>>
>>>> At issue is the first sentence of the informal definition of 
>>>> resource in
>>>> RFC 2396 1.1,
>>>>
>>>>   A resource can be anything that has identity.
>>>>
>>>> "that has identity" is redundant because *everything* has 
>>>> identity in
>>>> the only reasonably straightforward understanding of identity, 
>>>> ie. the
>>>> logical truth in all but the most obscure formal systems that,
>>>>
>>>>   (Vx) x = x
>>>
>>> No, that is not the only reasonably straightforward understanding of
>>> identity.  That is the specific mathematical axiom of identity 
>>> and not
>>> identity itself.  We already had that discussion on www-tag.
>>>
>>> Everything does not have identity.  "Everything" includes both 
>>> things that
>>> have been identified and those that have not yet been identified.
>>> Something
>>> only becomes a resource after it has been identified, but not 
>>> necessarily
>>> by a URI.
>>>
>>> The definition is correct as it stands.
>>
>> Maybe as an add-on to this:
>>
>> WebDAV working group decided to call a URL without a resource
>> (e.g. 404 on GET) an "unmapped URL".
>>
>> In that context, one could call a resource without URI a
>> "unmapped resource".
>>
>> So instead of going metaphysical with names and identity, it
>> maybe makes more sense of talking about *the* mapping
>> between the set of resources R and the set of names N
>> and define properties of this mapping M.
>
> Here you have assumed the point that I was attempting to
> correct.  You assume that the category of resources are
> a point set, and that URIs operate within this point set.
>
> URIs operate within a set of communicative gestures we
> term 'reference' and not all of them deal in the identity
> properties of things, or in persistently entified 'things'
> at all.

I never talked about 'things' but resources as used
in uniform resource identifier. If a resource is a file
on my computer, my last google query or the set of all
quantum states of all particles of this universe one
thousand years from now is besides the point. Just
by talking about it, I can give it a name, without
even knowing what it (exactly) is.

As was clarified in the "denumerable" thread, the set
of *all* URIs (ever to be) is as mighty as the set of
all rational numbers, but not more. If you call those
sets "point sets", well fine.

Now, the set URIs operate on (or the set of whatever
they "identify", be it files, things or communicative
gestures) is certainly far greater than the set
of rational numbers. I do not know what it is - I just
called it R.

>
>> M: R -> N
>>
>> M is neither injective, nor surjective, that is
>>   there are (many ;) x in R without n in N so that M(x) = n
>>   there are n in N without x in R, so that M(x) = n
>>
>> and as stated before: |R| > |N|
>>
>> Of interest to RFC 2396 is the subset of names which are uniform
>> and follow a specific syntax. Let's call the set of such names
>> U. So what RFC 2396 describes is which elements of N are
>> also elements of U. Elements of U are called URI.
>
> This all sounds nice, but it it unreal.  URIs are not all names.
>
> URIs are used (search and data: URLs) to refer by characteristics 
> that do
> not qualify as names.

In what way do they not qualify? A data: uri holds its own content,
but it is still a valid name for that octet string. A google search
URL is a name for a certain query in googles database. The 
representation
returned will very over time, but that does not matter.

> In the particular case of a search URL, there is no persistent 
> thing.  The
> 'representation of the resource' received is a thing but the 'resource
> identified in the request' is not.

I wonder now, what a "persistent" thing is. You keep spinning off new
terms in wonderful English prose, but they mean less and less.

The goal of my last mail is a *definition* of what "identity" in 
the acronym
URI is or how it can be interpreted.

As far as I can tell, you have two issues with that definition:

1. resources is an insufficient name for what URIs try to address.

2. the defined mapping between resources and URIs does not
    have the same properties as people usually associate with
    "naming".

Point 1 is, for me, a play on words. If we call it resources or
things or whatever, I don't care. I just chose resources as it
is used in URI.

Point 2 has more substance. If the defined mapping does not
have the properties you think it should have, then please let
us come up with a better definition.

>> [...]
>> So, if we restrict RFC 2396 to only talk about the mapping of
>> URI to resource and defining that "having identity" in RFC 2396
>> means that such a mapping exists (established by whomever),
>> do we then get rid of the metaphysical issues?
>
> You do the web a disservice to dismiss the architectural issue as
> 'metaphysical.'  It is very computational and economic and hence bears
> importantly on how we frame our axioms for the Web.

I see discussions on circular definitions and very slow progress
on what web architecture is. If we cannot define, in careful terms,
what an URI is good for, then the whole web architecture does not
need to be written down. It then just is what people do.

> The social process of denomination is not sustainably scalable to 
> where the
> web is going, because it is
>
> a) costly
> b) unnecessary

I proposed neither a unique, nor a centralized mapping of URIs. I said
that "having idenity" means that such a mapping exists. More, the beauty
of URIs and the Web is that the mapping can be done by anyone, if he
or she follows certain rules, as for example being authority for
a DNS subtree in the http: scheme. And that may be done even better
by future URI schemes which we cannot even think of now.

//Stefan

Received on Tuesday, 10 September 2002 12:06:06 UTC