Re: Uniform access to descriptions

Harry Halpin wrote:
> 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.
"A link does not given a user-agent a representation of a resource".  So 
LINK can only make sense when there is no representation, yes?  This is 
when LINK makes sense.  But not when there is both representation and LINK.
>
> 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.
Once you give user-agent an option.  You breaks the orthogonal 
specification because user have two places to look up the content.  
Also, if you implement a browser, how do you decide if a user want you 
to follow or not?
> 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.
That is not a right.  First, I didn't mean *all*.  It is choice of 
resource owner.  I didn't ask them to bind *all* in a single URI.  I am 
simply suggesting, there is an alternative design.

Second, I didn't oppose resource linking to other resource - that is a 
MIS-interpretation!  I am simply suggesting how a resource is linked to 
another resource should be put in content but the transportation protocol.
>
> 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). 
Again, that is *internal link*.  Not *external link*.
> 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.
I thought the intension is the uniformness.  If users are given too many 
options, how do we establish this uniformness. Of course, if people 
think "option" outweight *uniformness*.  I don't mind.  But just want to 
remind you that the foundation for argument LINK in UA2D has changed 
along this direction.
>
> 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
>> http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
>> http://www.flickr.com/pathayes/collections
>>
>
>

Received on Saturday, 12 April 2008 18:57:17 UTC