RE: We don't need no stinkin' identity

At 12:01 27/04/2003 -0400, Michael Mealling wrote:

>On Sat, 2003-04-26 at 19:25, pat hayes wrote:
> > >First,
> > >>  note that the _semantics_ of a URI are not defined in
> > >>  this specification. Each URI scheme itself defines the
> > >>  relationship between URIs of that scheme and the resources
> > >>  they identify. In all known cases, that definition isn't
> > >>  enough to allow the URIs of that scheme to be used, by
> > >>  themselves, as unambiguous identifiers when trying to
> > >  > make logical assertions.
> >
> > Again, the problem is not that the logic requires unambiguity; quite
> > the reverse, in fact: it is that imposing unambiguity as a defining
> > characteristic of URIs is logically incoherent.
> >
> > Suggested modification, without the logic-bashing:
> >
> > >  What is a Resource? Can a URI be used to identify a Concept?
> >
> > >  This specification does not define the word 'resource' carefully,
> > >  nor does it define how a URI can be used to 'Identify' a
> > >  'Resource'. The _semantics_ of a URI are not defined in
> > >  this specification.  Each URI scheme itself defines the
> > >  relationship between URIs of that scheme and the resources
> > >  they identify or refer to.
> >
> > The reason for the last three words is that it doesn't make sense to
> > say that a URI identifies a *single* thing, in almost any logical
> > language. (In fact, it doesn't make much sense in any language, IMO,
> > but leave that aside for now.)
>
>Pat,
>   I think that's one of the places that we're falling down on our
>explanation. You assert that it doesn't make sense "in almost any
>logical language". And that's the point, URIs aren't _in_ a logical
>language, they exist outside all of them. URIs may be used _by_ a
>language but at that point it is incumbent on the language/system that
>uses them to define what it means concerning the things that URIs are
>allowed to identify.
>
>   As Graham has pointed out before, the problem here is that RDF, SW,
>OWL, etc have erroneously attempted to inherit RFC 2396's concept of
>Resources unmodified, and that was a severe mistake. IMHO, it is
>probably worth inserting language into the new document suggesting that
>it is extremely dangerous to simply inherit this definition of a
>Resource without some sort of system specific profile of it. Systems can
>do it but they have to be very clear that they are inherit it, not the
>other way around...
>
>   To simply inherit this documents concept of a Resource would be the
>network equivalent of simply specifying an application layer (8)
>protocol directly on top of IP, ignoring its admonitions to use things
>like TCP/UDP/ICMP, etc that constrain IP to something that is usable by
>higher layers.

I don't recall saying that which you attribute to me.   But it seems to me 
you are pushing much the same thing as Pat, in a different way.  That the 
URI spec shouldn't be committing layered logical languages to specific 
interpretations of URIs.

Where I (maybe) differ slightly from your line is that I think it's OK for 
the layered specifications to inherit the RFC2396 concept of a resource, 
but that RFC2396 should not say anything about a resource that it really 
does not need to say, so that there's less to cause problems for the 
layered specification.  Running with your example of IP, it's important 
that IP *does* specify the syntax and interpretation of the IP header, but 
that it says as little as possible about the IP payload.  One could imagine 
a (poor) specification that says the payload should start with something 
like a TCP/UDP header, providing some groundwork for most of the traffic 
that is actually conveyed by IP.  But that would be entirely unhelpful for, 
say, ICMP.

I think an important point that the URI specification probably does need to 
convey is that a resource is not the same thing as a representation of 
same.  And enough background information that protocol developers use URIs 
in sensible ways.  But beyond that, the nature of a resource should be 
constrained as little as possible by the URI spec.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Monday, 28 April 2003 10:06:12 UTC