- From: David Booth <david@dbooth.org>
- Date: Thu, 29 Mar 2012 13:22:53 -0400
- To: Norman Gray <norman@astro.gla.ac.uk>
- Cc: Jonathan A Rees <rees@mumble.net>, Michael Brunnbauer <brunni@netestate.de>, Tim Berners-Lee <timbl@w3.org>, public-lod community <public-lod@w3.org>
On Thu, 2012-03-29 at 01:37 +0100, Norman Gray wrote: [ . . . ] > Thus as it stands, the term 'information resource' in [1] has no > implication (beyond incidentally reiterating that the 200-retrieved > content is a (REST) representation of the resource). > > However, the point of introducing the term is, I've always taken it, > that it licenses the client to jump to some conclusions. These > conclusions aren't spelled out anywhere, but (unless you're being > whimsical) they're things like 'this is a document', or 'this is a > network thing', or 'this is not a squawking macaw which will squeeze > out of the ethernet port and crap on my keyboard'. What those > conclusions materialise as in practice surely _depends on the > application_ which is processing the resource. Exactly. And that is precisely why the UDDP Proposal use the term "information resource" but explicitly leaves its definition unconstrained: http://www.w3.org/wiki/UriDefinitionDiscoveryProtocol#2.7_Information_resource As I mentioned elsewhere, the term is not needed, and could be eliminated entirely. But it does provide a convenience for applications that wish to make additional assumptions based on an HTTP 200 response. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Thursday, 29 March 2012 17:23:18 UTC