Re: Uniform access to descriptions

Reading this exchange (below), I think I might be able to make 
Xiaoshu's case for him. (Xiaoshu, if I have misrepresented you at 
all, please forgive (and correct) me. But I got to this point from 
your recent emails (on and off list), so even if Im wrong, you have 
to bear some of the responsibility :-)

The central point is that now that we have the technology and ideas 
of the semantic web available, we have a wider range of ways of 
representing, and a richer notion of what words like ''metadata" 
mean. If we are willing to take fuller advantage of this new 
richness, we make available new ways to do semantic things within the 
same overall design of the pre-semantic web.

In particular,  awww:represents is a very narrow sense of 
'represents'. Perhpas we can allow a wider sense of representation 
here. The REST story was always that URIs identify resources, and 
that the http response is a representation of the resource. Nobody 
has ever been able to say what exactly counts as a 'resource'. We 
already have accepted the idea that a given resource may have many 
awww:representations, to be resolved by content negotiation.

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.

In this view, then, content negotiation is a much wider topic than it 
has traditionally been. We are dealing with a much wider notion of 
what a 'resource' is, and a much wider notion of what a 
'representation' is. Some resources have all kinds of possible 
representations. So yes, we have to be prepared to go beyond 
'accepted and expected usage'. Who would have thought otherwise?

Pat




At 7:31 PM -0600 4/11/08, Michaeljohn Clement wrote:
>Xiaoshu Wang wrote:
>>>>  We agree that there are legacy data, yes?  Let's make its URI x, whose
>>>>  owner is Joe.
>>>>  Case 1. Joe is lazy.
>>>>  Then, no LINK, no Conneg. Is this fair?
>>>>  Case 2: Joe is not lazy.
>>>>  (a) Joe makes LINK(x)=metadata.
>>>>  (b) Joes make Conneg(x)=metadata (can easily GET x Accept
>>>>  application/rdf+xml).
>>>
>>>  (b) would be wrong, because the metadata is not an alternative variant
>>>  of the resource identified by x.
>>>  
>>  Why wrong? First define metadata?  Say _:x _:b _:y.  Is this assertion
>>  metadata of _:x or _:b or _:y?  You assume it is wrong because of an
>>  arbitrary definition of metadata.
>
>I object on the basis of my sense of what conneg is for.  I don't believe
>my definition of "metadata" is relevant.
>
>Let's stipulate that GET x, for the "x" in your example, returns a PNG
>image, and that the metadata in question is some statements about that
>image, expressed in RDF.
>
>Would you not agree that the RDF represents a different resource from
>the image?
>
>Content negotiation would be an appropriate way to serve an alternative
>JPEG representation of the same resource, but to return a different
>resource would be contrary to accepted and expected usage.
>
>>  In your proposal, any RDF
>>  transformation is the metadata of an HTML, they should be put in LINK too.
>
>I'm not proposing that.  I am simply suggesting not to use conneg except
>to negotiate between different representations of the same resource.
>
>>>  Surely there may be more than one application/rdf+xml resource that
>>>  might be associated in some way with the resource identified by x,
>>>  right?  It's impossible to distinguish between these by using conneg.
>>>  
>>  This is the reason.  Perhaps it is not I who have failed to understand
>>  the <LINK> problem, it is you who have failed to understand Conneg.
>
>I don't follow your argument here, perhaps you could restate it in
>more concrete terms.
>
>>>  If the only purpose of the Link: header would be the same as the
>>>  purpose of the HTML <link rel=alternate>, then surely (b) would be
>>>  more relevant, but the Link: header can express other relations as is
>>>  being discussed here, viz "describedBy".
>>>
>>>  The only way (b) can be correct here is if the result of a GET with
>>>  Accept: application/rdf+xml is actually just a variant representation
>>>  of the same resource.
>>>  
>>  What do you mean *just* a variant?
>
>By "just a variant representation of the same resource", I mean
>specifically something that is not a representation of a completely
>different resource.
>
>>  All representations bound to the
>>  resource 'x' identifies x.
>
>They /represent/ x, I'm not sure what you mean by saying that they
>"identify" x.
>
>>  It may be of different format, different
>>  language, but they are all talking about the same resource - that is
>>  what matters.
>
>Unless the server is misconfigured, they are all representations of
>the same resource.
>
>That's why I don't understand why you think that conneg can solve the
>problem that the Link: header can solve, namely the association in an
>HTTP response message of a *different* resource with the one that has
>been accessed.
>
>Michaeljohn


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections