Re: Uniform access to descriptions

On Apr 11, 2008, at 11:49 PM, Pat Hayes wrote:
> Now, take that story exactly as expressed,  but let the word  
> 'identify' mean simply denote or name, and allow that the resource  
> can be something entirely unconnected to the Internet (such as,  
> say, me), and allow 'representation' to include not just the  
> awww:representation relationship between a byte stream and  
> something like an html web page, but more generally any kind of  
> representation of a thing, so that an image of me can be a  
> representation of me, and an RDF description can be another  
> representation of me, and my home page can be yet another  
> representation of me - remember, here the resource in question is  
> me, not some information resource. So, what follows from this  
> vision? Well, it means that your insistence that the RDF and a JPEG  
> image must be different resources is misplaced. Not that its false,  
> but it misses the point. Their role here is not as resources, but  
> as representations. And seen in this light, it seems quite natural  
> that one might use conneg to decide which of them is most appropriate.
> Now, of course, this is not how 'representation' has traditionally  
> been used in Webarch discussions. It is not awww:representation.  
> But it is a perfectly good usage of the word 'representation': in  
> fact, somewhat better than the traditional webarch sense, which is  
> so special and peculiar as to almost be a distortion. It requires  
> us to generalize the 'classical' webarch story to allow a broader  
> sense of 'representation' and a broader sense of 'resource' and a  
> broader sense of 'identify'. And I think Xiaoshu's main point is,  
> let us try doing that, indeed, and see what happens; and in fact,  
> one gets a coherent, rational story about how Web architecture  
> should work. It isn't the REST model any more: it generalizes it to  
> include a much wider range of possibilities. (We might call it REST+ 
> +.) It is a Web much more infused with semantics and descriptions  
> than the current Web, one which uses its own formalisms (RDF) more  
> architecturally than the current Web. In this vision, the semantic  
> Web isn't simply an application layer built on top of the pre- 
> semantic Web, but instead is something more like an architectural  
> generalization of the pre-semantic Web, with semantic technology  
> built into its very architecture all the way down.
> So, here's a typical Web transaction. A URI U identifies a resource  
> R, and when U is given to http, the Web delivers a representation S  
> of R. Typical classical case: R is a website (or a webpage or a  
> server or an http endpoint, or... but anyway, its something  
> Internettish), U+http is a route to R and S is a  
> awww:representation of R, which is typically a byte-for-byte copy  
> of a file which comprises the bulk of R.  Alternative case using  
> the more general senses: R is me, U denotes R and S is an RDF graph  
> describing R, using FOAF. Describing is one way of representing.  
> Another alternative sense: R is me, U denotes R and S is a JPEG  
> image of R. Picturing is another way of representing. Now, these  
> representations aren't awww:representations of me, of course; but  
> they couldn't possibly be, since I'm not the kind of thing that can  
> possibly have an awww:representation. So if we want to run the  
> classical story with things like me - non-information resources -  
> as R, then we must generalize the classical notion of  
> 'representation'.
> What these alternative cases have in common, and where they both  
> differ from the traditional one, is that the Web 'thing' that is  
> located by U+http and which returns the representation S simply  
> isn't mentioned. Its not part of the story at all: it's not the  
> resource, S doesn't represent it, and its not what the URI  
> identifies/denotes. Its just part of the Web machinery, a  
> computational thing whose task is to transmit S when requested to  
> do so. It has a relationship to R, of course, but rather an  
> indirect one: it is a thing that delivers representations of R,  
> using http. We might call it a storyteller for R. R might have a  
> whole lot of storytellers, each capable of telling different kinds  
> of story about R.  The classical case is where R is its own  
> storyteller. This is different from the classical REST/webarch  
> story, indeed: but then, as soon as we allow URIs to identify  
> things that can't be accessed by transmission protocols, the  
> classical story stopped working. We have to broaden our horizons.  
> But notice that it follows the same basic description as the  
> classical story, just using the terminology more broadly.

No, that is exactly the classical REST model, what I presented at  
and how I used the terminology for the first few years of being on  
the TAG.
It is why I chose the word "representation" in the first place.

What appears in the webarch spec, however, is only the subset agreed  
to by
the entire group.  Quite frankly, I got tired of hearing about how my  
of Web communication was somehow preventing the semantic web from coming
to fruition, even though this sense of resource overloading was only one
of many sources of ambiguity.  My use of it simply wasn't important.

In any case, this discussion doesn't solve any known problems.  The 303
solution to httpRange-14 solved a known problem (albeit one that was
only important to a select group of systems that assume too much).
Likewise, the Link header is a solution to many other problems where
links cannot be embedded in the representations (e.g., due to format
or ownership or integrity preservation issues).  We can't agree to a
common model for understanding Web communication because we have no
objective means for comparing models.  However, that doesn't stop us
from finding solutions that work in all models even if they aren't
strictly necessary for all of them.


Received on Tuesday, 15 April 2008 00:50:46 UTC