Re: Uniform access to descriptions

Pat Hayes wrote:
> 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.
Why are we forgetting that a resource's meaning can be settled in part 
by "linking" rather than conneg?  A link does not given a user-agent a 
representation of a resource, but allows the user-agent to access a 
representation of a related resource. I thought that's what this whole 
argument was about.

My thinking on this point is that what a resource denotes is 
fundamentally made up by the web of representations a given resource 
allows access to. Resources can be connected either by linking, which 
is  an *option* for a user-agent to follow, or  having the user agent be 
given *direct access* to a representation, either immediately or by 
redirection, and so not optional once the user agent makes the request 
to the resource, although of course user agents can express preferences 
about what content types they would like. That's an important distinction.

Xiao seems to think *all* of the web of representations that give 
meaning to a resource should be constituted by conneg. That's clearly 
not how the present Web works. It is impossible to give meaning to a 
resource in any sort of realistic way by not allowing it to link to 
other resources. Even if one has a very wide view of conneg and 
representation, a link to a stylesheet is not a "representation of the 
same resource" but a link to another useful resource that a user agent 
may or may not want to follow.

The reason to have LINK headers in HTTP is precisely because we should 
allow linking at all levels of the stack, including both the protocol 
level (HTTP) and the representation level (rdfs:seeAlso, href). People 
may find one level easier to work with than another, and there are cases 
where it is easier for people to Link at the protocol level.

Tim and Xiao seem to disagree about how to divide up representations 
into resources, about what to allow access to via conneg and what to 
allow access to via linking. Individuals will disagree about this sort 
of thing as they just have different views of the world. What we can do 
is provide many options to allow them to link their resources to other 
resources as to figure out each other's view of the world, and a LINK 
header is just one of them. Trying to pre-optimize this by saying "You 
can never have a resource that returns JPGs and RDF through conneg" or 
by saying "You should never want to use a LINK header in the protocol" 
stack seems to be overly restrictive. I thought the whole reason the Web 
succeeded to some extent is because we let people put up information and 
link in a decentralized manner.

> 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

Received on Saturday, 12 April 2008 15:36:20 UTC