RE: Qualities of URLs and resources

Every concept is referenceable, so your definition would
make the term "resource" a synonym for the term "concept".
This makes the term "resource" useless, since
the term "concept" is well defined, and adding a synonym
for it does not buy us anything.

An alternative definition is that a resource is a function
that can be associated with a URI, where the input to this
function is a method name, a request URI, a list of headers,
and a request body, and the output is a list of headers and
a response body.  (I pretty much copied this definition from
one of your earlier posts, so I make no claim of originality
here).

In this alternative definition, all sorts of concepts are not
resources ... in particular, a method name is not a resource,
a header is not a resource, a request or response body is not
a resource, and a URI is not a resource.

I believe this alternative definition is far more useful for
defining a binding protocol.  I'm willing to use some other
term for this alternative concept, if it is important to reserve
"resource" as a synonym for "concept", but my impression is
that this alternative definition is the more commonly accepted
one.

Cheers,
Geoff

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU]
> Sent: Friday, February 25, 2000 12:17 AM
> To: Clemm, Geoff
> Cc: Slein, Judith A; w3c-dist-auth@w3.org
> Subject: Re: Qualities of URLs and resources 
> 
> 
> >There are some concepts that explicitly are not resources,
> >e.g. the concept of a "URI" or the concept of a "property".
> 
> Nope.  If the concept is referenceable, it is a resource.  If you ask
> me for the URL that I was using to represent my home page in 1994,
> you are referring to a URI as a resource in itself.  All properties
> are resources -- DAV just defines a different way of accessing them
> than the old HTTP interface.  The only reason it did so is because
> some people felt that adding direct access to properties was better
> than paying for one round trip.
> 
> >Like URI's and properties, a binding is not
> >something that is identified by a URI, and is not something
> >to which you can apply requests.  Instead, a binding
> >is just a term we use to talk about how a collection 
> >resource behaves, e.g. if at time T, a collection resource has a
> >binding named "foo" to a resource with DAV:resourceid "xxx", then
> >this is just a shorthand for saying that a
> >depth:1 PROPFIND at time T on any URL that is mapped to that 
> collection
> >will return a DAV:response with a DAV:href whose value is 
> >"<that URL>/foo" and with a DAV:resourceid whose value is "xxx".
> >
> >In other words, all URI's that are mapped to that collection at time
> >T will have a member named foo, and the DAV:resourceid of that member
> >will be "xxx".
> 
> For any concept X, it is possible to create an identifier namespace
> obeying the requirements of RFC 2396 such that concept X is 
> unambiguously
> identified within the scope of the namespace's usage.  It is therefore
> possible to identify any concept with a URI, which makes it a 
> resource.
> 
> BTW, DAV:resourceid is an abomination.  It breaks the implementation
> abstraction that is at the core of the Web interface.  Telling server
> implementors to reveal that information is wrong and is completely
> unnecessary to define the protocol.
> 
> ....Roy
>

Received on Friday, 25 February 2000 09:29:17 UTC