If you’re following the TAG discussion
regarding the httpRange-14 issue,
you’re probably aware of the two (at least I think and hope it’s
just two) positions about this; either http URIs without a fragment identifier
can identify anything, or they can identify “documents”, aka “information
resources”, aka “cyc:ConceptualWork”s. I’m unapologetically in the “anything”
camp.
As this debate has flared up every few months in some forum for the past
several years, I thought a bit about some of the implications of my position,
and whether there was anything there that hadn’t yet been said. I came up
with a couple.
First, in general, who’s to say that any string can’t identify any
thing? My name is “Mark”, and that name identifies me; not globally uniquely
of course, but I don’t think anybody would claim that it wasn’t an
identifier. So as an identifier, it would be really nice to be able to
ask a HTTP proxy for a representation of me using that identifier, e.g.
GET Mark HTTP/1.0
Accept: image/jpeg, text/html
The only reason that isn’t possible, of course, is that HTTP accepts
URIs on the request line, not arbitrary words. This is because URIs have more
structure than your typical word such that a machine can extract out all
the information it needs in order to retrieve a representation via late
binding.
So assuming we all agree that “Mark” is an identifier for me, then we
should all expect that the request above would return a representation of
me. Why then, should our model of how this works be any different if I use
“http://www.markbaker.ca” as the identifier for me in that request? My
name is not “Mark#him”.
Second, it appears to me that adding a layer of indirection in the
form of having a URI-with-no-frag identify “ConceptualWork about <subject>”
rather than just having it identify the subject, removes the ability for
state changes to be made. Consider my canonical “Web
services are broken” example of a lightbulb; we have a URI that identifies
the lightbulb, GET returns a representation of it to us, we toggle the
“on/off” part of that representation, and then PUT it back to that same
URI. In that example, there exists a perfectly reasonable expectation on
the part of the client that PUT would change the state of the lightbulb
(assuming the history of representations returned via GET was consistent
with the URI identifying the bulb). Adopting the “http URIs identify
cyc:ConceptualWorks” position would appear to force PUT to mean “write a
new version of the ConceptualWork”, with no way to model actually changing
the state of the lightbulb. Not good!
Note that this example was sort of similar to
Roy’s
POST/robot example, but using PUT instead of POST. I find PUT superior
to POST for examples like this, because it’s easier for most people to
understand what PUT does. But the principle is the same.
So to sum up, if it walks like a duck, and quacks like a duck, it’s
probably not a ConceptualWork about a duck.