Re: Identifying versions in draft-toomim-httpbis-versions , was: draft-toomim-httpbis-versions HTTP mapping (and WebDAV Versioning)

On 2/5/25 1:29 AM, Julian Reschke wrote:
> As I explained, a version *is* a resource. In your explanation, the URI
> for it is optional. But the fact that it *can* have a URI by definition
> means that it *is* resource. Please read the beginning of RFC 3986. 

Julian, you seem to be claiming that a version *is* a resource. But is 
it not more accurate to say that a version *can be* a resource?

Just because something *can* have a URI does not mean that the thing 
*is* a resource. My name (Michael Toomim) can have a URI constructed for 
it, like urn:toomim:Michael%20Toomim, but this does not imply that my 
name is a Resource. It is my name. Likewise, I could define multiple 
resources for my name:

    urn:toomim:Michael%20Toomim
    urn:foobar:Michael%20Toomim
    https://toomim.net/Michael%20Toomim
    https://example.com/names/Michael%20Toomim

Now we have a one-to-many mapping between my name and resources. You 
cannot say that my name is a Resource. If it's a Resource itself, then 
which Resource is it out of that list?

Similarly, in the Bank example I gave earlier, there is a many-to-many 
mapping between Versions (e.g. "transaction-1") and Resources:

    Resource:                 Version:         Value:
    https://alice.com/alice    "start"          $20
    https://bob.com/bob        "start"          $20
    https://alice.com/alice    "transaction-1"  $10
    https://bob.com/bob        "transaction-1"  $30

Now, we could also come up with many URI definitions for "transaction-1":

    https://alice.com/versions/transaction-1
    https://bob.com/versions/transaction-1

Each of those are Resources. But the version "transaction-1" itself is 
not a Resource. If it is a Resource, then which of those Resources is it?

Again, it seems like you are thinking with an Option 1 mindset while 
reading Option 2. Please try to understand the difference between mental 
model of Option 1 and Option 2.

Thanks!

Michael