Re: TAG request: establish the relationship between URIs and Resources is many to many

> In some simple sense, this can be viewed as a situation where two URIs
> identify the same resource, with the resource identified by "latest"
> changing over time.  There is another sense in which "latest" is an 
> n'th +
> first resource.    Here are two use cases that motivate these two
> seemingly conflicting views.

No, it can't.  Each URI identifies a resource.  The resource identified
is the mapping function, not the result of that mapping, since otherwise
one of the following would have to be true:

    1) what the URI identifies is not the resource; or
    2) the author has to change the URI every time the result changes.

Since (1) is false by definition and (2) is false by demonstration,
the resource is neither the object on the server (as implemented) nor
the representation (as delivered to the user).

The mapping functions for "latest version" and "version 3" have very
distinct semantics even during the time period in which their results
overlap.  People want to link to the "latest" as it will be mapped at
link traversal time, not how it was mapped at link authoring time.

> Some use cases:
>
> * RDF should presumably be able to make separate statements about 
> version
> 3 and about latest (e.g. "the version you should read is the one
> identified by "http://example.org/mydoc.latest",
> "http://example.org/mydoc.version3 has a bug").  So, there is an 
> important
> sense in which there are two "things", which perhaps should be called
> resources.

Those are two different resources with relationships between them.

> * If I do an HTTP POST or PUT to http://example.org/mydoc.latest, the
> representations returned by GET's to version 3 (or 4) necessarily 
> change.

Eh?  Why would the server allow that?  It would violate the semantics
that were described for the version 3 and 4 URIs.  A properly 
implemented
server would either disallow PUT on latest or hide the versioning
relationship behind the interface (generate version 5 and update the
"latest" mapping).

....Roy

Received on Friday, 31 January 2003 19:25:18 UTC