Re: Uniform access to descriptions

Darn and thanks, Pat. I wish my English is that good.

Xiaoshu

Pat Hayes wrote:
> 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
>

Received on Saturday, 12 April 2008 10:09:09 UTC