Re: Uniform access to descriptions

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.


Received on Saturday, 12 April 2008 01:31:47 UTC