Re: Reversing HTTP Range 14 and SemWeb Cool URIs decision

Hi Manu,

Manu Sporny wrote:
> Currently, our identifiers for long-lived resources look like this:
> 
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28#deposit
> https://mybank.example.com/accounts/3879279824#account
> https://payswarm.example.com/people/john-doe#public-key-5
> 
> However, when these identifiers were presented to our development team,
> the first question that arose was:
> 
> "Why do we need to have #deposit at the end of the deposit URL? The same
> for account? We've designed the system to be RESTful, why are we
> duplicating information in the URL?"
> 
> That is, instead of this:
> 
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28#deposit
> 
> Why not this?
> 
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28
> 
> We are designing the system to return an HTML+RDFa representation of the
> resource above when a browser hits the resource. It will contain both
> human-readable information and semantic data that is specific to the
> deposit. We are not talking about a concept that doesn't exist on the
> web. The concept only exists on the web and it's at the URL listed above.

You gave three example URIs above, assuming you mean what's implied by 
the lexical form of them, then:

 > https://payswarm.example.com/people/john-doe#public-key-5

this indicates that the URI https://payswarm.example.com/people/john-doe 
is a conceptual mapping to a set of public-keys held by a user, thus the 
resource https://payswarm.example.com/people/john-doe identifies a set 
of keys, and each individual key in that set would need it's own 
name(URI) if it were to be described.

There's no limitation as to what the URI(s) for each individual key in 
that set could be, any URI you could conceive, with or without a 
fragment, could be used as an identifier.

 > https://mybank.example.com/deposits/7f7f62ab53cc623cd28#deposit

this indicates that you only need a conceptual mapping to a single 
resource, a "deposit", as such any URI will do, for example:

- https://mybank.example.com/deposits/7f7f62ab53cc623cd28
- https://mybank.example.com/deposits/7f7f62ab53cc623cd28#deposit
- https://mybank.example.com/7f7f62ab53cc623cd28

as long as the human and machine readable descriptions are both 
consistent and describe the thing named as a "deposit", then you're fine.

and likewise for the #account URI

The main thing to remember is that if a representation achieved by 
dereferencing a URI describes more than one thing, then it's a 
conceptual mapping to that set of things, and as such each thing 
described needs it's own URI - if it only (ever) maps to a single thing 
then you're fine.


> You can't do this via HTTP 1.1:
> 
> DELETE http://example.org/foo#bar
> 
> and hope to only delete the information identified by #bar... you will
> most likely delete the entire foo resource instead. Contrast that with this:
> 
> DELETE http://example.org/people/bob/public-keys/1

Conceptually you can't "delete" a resource anyway, all you can do is 
delete an origin servers knowledge of a resource. Thus, if the two URIs:
  - http://example.org/foo#bar
  - http://example.org/foo/bar
both refer to the same resource, then a DELETE on one also "deletes" the 
other, such that, from the origin servers perspective the resource is 
now unknown (or 410 Gone).

The take away is, that even if you used the URI 
http://example.org/foo#bar to refer to the resource (say because you 
only provided a description of it as part of a set of descriptions) then 
you could still quickly define http://example.org/foo/bar to be a 
conceptual mapping to the same resource, DELETE it, and therefore have 
removed the origin servers knowledge of the resource.

All of which is IMCO of course,

Best,

Nathan

Received on Sunday, 16 January 2011 23:57:51 UTC