Re: Question about the On Linking Alternative Representations TAG Finding

On 5 Aug 2008, at 21:46, Booth, David (HP Software - Boston) wrote:
>> Second, it seems worth to mention terminology. The original resource
>> (at /resource in my example) is the "real" resource we are interested
>> in. It's a "generic resource" because it is available in different
>> formats. The format specific URIs identifies specific *variants*,
>> which are *representations* of this original resource. However, by
>> assigning URIs to those representations, we are turning the
>> representations into resources of their own right. (Because, by
>> definition, everything that is identified by a URI is a resource.)
>
> That is close, but not quite correct.  The format-specific URIs  
> identify related *resources*.  They do *not* identify  
> representations, even though they may well return the same kind of  
> representations when you GET from them.  In fact, a format-specific  
> URI could even return different representations in the same format  
> at different times or in response to different requests.  For  
> example, a PDF URI could return one PDF representation at one time  
> and a different PDF representation at another time.

You're right David, thanks for catching my error. The format-specific  
URIs can return different representations over time, and thus they do  
not identify one particular representation.

I think it's still correct to say that the format specific URIs  
identify different *variants* of the generic resource.

> In theory one *could* mint a URI to denote a particular  
> representation -- a representation returned in response to a  
> particular request on a particular URI at a particular time -- but  
> that is not what's being discussed in your scenario.

Yes, right.

Richard



>
>
>>
>> Third, many people have voiced this opinion: If the client indicates
>> that it does not support the format available at this URI, then HTTP
>> 406 should be sent. (This is clearly a SHOULD, not a MUST, according
>> to the language in RFC 2616.)
>>
>> Fourth, I would like to point out that the case discussed under
>> "third" does not arise if the client is a normal *Web browser*,
>> because they all have */* in their accept headers and thus indicate  
>> at
>> least *some* support for *every* format. But the case does arise with
>> other HTTP clients that do not accept */*.
>
> Good point.
>
>>
>>
>> I'm still unclear about one particular case: What should be done if a
>> client indicates support for several formats, but prefers one over  
>> the
>> others; and the URI is specific to one of the non-preferred formats?
>> Example:
>>
>>     Accept: text/html;q=1.0, application/rdf+xml;q=0.5
>>
>> This client supports HTML and RDF, but it prefers HTML over RDF.
>>
>> If /resource.rdf is accessed, what should happen? The URI is
>> specifically for the RDF variant. So we have a conflict between the
>> resource (which is available in RDF) and the preference of the  
>> browser
>> (which would rather have HTML than RDF). Should the server ignore the
>> preference and send RDF anyway?
>
> My opinion: Yes.  The user is probably testing the URI in a generic  
> browser, didn't bother to change the Accept header, and want wants  
> to see the RDF.
>
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not  
> necessarily represent the official views of HP unless explicitly so  
> stated.
>

Received on Wednesday, 6 August 2008 10:09:06 UTC