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.