Qualities of URLs and Resources (take 2)

On Wednesday, February 9, 2000, I wrote, responding to Roy Fielding:

> Roy Fielding writes, in his post originally titled,
> "draft-ietf-webdav-binding-protocol-02"
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0125.html>:
> > > URI Mapping
> > >      A relation between an absolute URI and a resource.  For an
> > >      absolute URI U and the resource it identifies R, the URI mapping
> > >      can be thought of as (U => R).  Since a resource can represent
> > >      items that are not network retrievable, as well as those that
> > >      are, it is possible for a resource to have zero, one, or many
> > >      URI mappings. Mapping a resource to an "http" scheme URL makes
> > >      it possible to submit HTTP protocol requests to the resource
> > >      using the URL.
> >
> > Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the
> > current time, R is the resource, -R-> is a mapping function that has
> > been implemented according to the semantics of resource R), and the
range
> > is a set of values representing that resource at time t.

 *snip*

> So, using your notation, I would re-write the full mapping as:
>
>  {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm}
>
> Where UMap is the URI to resource mapping function, and RMap is
> the resource to value mapping function.  I omit time since it's really
> tangential to our discussion, assuming that the entire set of mappings
> occurs at a given time t.  In this view, the term "resource" as used in
> RFC 2396 is both the output of the UMap function, and the RMap mapping
> function, but *not* the set of values.

Having thought about this for awhile, I now see that I was using the term
"resource" in a different manner than Roy.  I had essentially been using
"resource" as the name for the set
{V1, V2, ... Vm} of values.  But, as Roy points out, a resource is an
*abstraction*, not a specific set of values, or even the mapping RMap.  This
is why he stated, on Feb. 10, 2000:

> the resource is the concept, not the representation
> of that concept and not the URI-to-representation mapping mechanism
> on the server.

That is, the abstract concept of a particular resource defines to a specific
set of values, and a specific resource mapping function.  The abstract
concept comes first, then from it are derived the values and mapping
function.

So, when Roy proposed that a binding be treated as a resource, this is an
assertion that the values and the mapping function are derived from the
definition of the binding resource.

Using Roy's notation, a resource's mapping functions and values can be
represented as:

 {U,t} -RMap-> {V1, V2, ... Vm}

A binding resource's mapping function and values can be represented as:

 {U1,t} -RMap-> {V1, V2, ... Vm}
              >  |
             /   |
         RMap    | This mapping function is derived from the
 {U2,t} /        | definition of the abstract binding resource

In this case, by definition of the binding resource, the set of values is
the same, though the mapping function is different.

But, this has the difficulty that no identifier exists for the set of
values. This identifier is useful, since it allows the construction of URL
to identifier pairs.  In cases where the set of values has only one member,
and this member can be modified with a PUT or PROPPATCH, these pairs allow a
client to determine a priori whether the effect of an action on one URL will
be visible via another. This capability is useful in a number of authoring
situations.

Previously, I wrote:

 {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm}

To express going from a URL to the set of values.  I still like this
diagram, but calling the middle item a "resource" is a mistake, since a
resource is an *abstraction*.  The middle item is really an identifier for
the set of values, what I'll term a resource implementation identifier
(RII).  That is, it does not identify the resource, only a specific
implementation of the resource in the form of the resource mapping function
RMap, and the set of values. Rewriting it yields:

                                 resource
{URI1, URI2, ... URIn} -UMap-> implementation -RMap-> {V1, V2, ... Vm}
                                identifier

                               |
  <-- affected by bindings --- | ---affected by resource's defintion -->
                               |

In this diagram, the abstract concept of the resource has been used to
define the resource mapping function, RMap, and the set of values, {V1, V2,
... Vm}, and the RII uniquely identifies this (RMap, Value set) pair. That
is, it uniquely identifies this specific implementation of the abstract
resource. A single binding can be viewed as an element of the UMap set, that
is, a specific (URI, RII) pair. Thus, the effect of the bindings
specification is to manage the UMap function, as specified as a mapping from
URIs to the RII.  By introducing the notion of the resource implementation
identifier, it is possible to introduce bindings without having to redefine
the notion of a resource, without having to break the resource abstraction
layer, and without having to introduce a new kind of resource (a binding
resource), while still providing clients with a unique identifier for the
*implementation* of the resource.

So, Roy, did I set off any mental trip wires this time? :-)

- Jim

Received on Friday, 5 May 2000 05:39:05 UTC