Re: Question about the On Linking Alternative Representations TAG Finding

Sebastien,

Please take this with a grain of salt as I'm not familiar with the  
details of your scenario, and haven't thought hard about it, but I  
would propose that a codec might either

a) generate a representation or
b) respond with a redirect to another resource.

So the implementation of the codec chooses the appropriate response,  
and in the case of b) the status code (e.g. temporary, permanent, see  
other). It should be possible to specify both local and off-site  
redirection targets.

The “simplified” 303 approach could then be modelled by having a  
resource with two codecs that both answer 303 redirects to other  
resources.

[Responses please off-list, as this discussion isn't very relevant to  
www-tag.]

Richard


On 7 Aug 2008, at 20:13, Sebastien Lambla wrote:

> Thanks for clearing those points out. I came from a pure conneg  
> background
> and always had generic resources that conneged without redirection,  
> but
> others pointed to me that because of httpRange-14, if your resource  
> is used
> as an identifier for a thing then it should always 303, which is the  
> second
> scenario you talk about.
>
> This comfort me in my dislike of 303. As an implementer of a Rest  
> framework
> to be released very shortly, I wonder what would be your advice?
>
> Currently, the system lets you map urls to resources, resources to  
> handlers
> that operate on the resource, and resources to codecs that generate  
> the
> representations for those resources.
>
> I had implemented a content negociation switch that lets you specify  
> to the
> framework what to do when dereferencing such a resource, with one
> SimpleConneg mode for content-type negociation on the generic uri,  
> and one
> with a redirect to a content-negociated url (something along the  
> lines of
> /customer(en).html).
>
> In other words, should we have one resource_not_a_document, one
> resource_generic_uri and a bunch of others specific to the variants  
> of that
> representation?
>
> I don't want to put in an open-source implementation an  
> implementation that
> is flawed in the way it maps resources.
>
> Sebastien Lambla
>
> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On  
> Behalf Of
> Richard Cyganiak
> Sent: 07 August 2008 19:30
> To: Sebastien Lambla
> Cc: T.V Raman; john.kemp@nokia.com; www-tag@w3.org; kidehen@openlinksw.com 
> ;
> tthibodeau@openlinksw.com
> Subject: Re: Question about the On Linking Alternative  
> Representations TAG
> Finding
>
>
> Sebastien,
>
> I'll try to explain below. Short summary: 303 redirects are about
> creating URIs for "things described inside documents". Content
> negotiation is about having the same document in different formats.
> The 303 approach used in the Linked Data community combines the 303
> redirects and content negotiation in a somewhat sloppy but mostly-
> harmless way.
>
> On 7 Aug 2008, at 16:04, Sebastien Lambla wrote:
>> By content negociation I took it to cover both 2616 negociation and
>> the process by which httpRange-14 hints at redirecting to an IR from
>> a resource that may or may not be an IR.
>>
>> Maybe I misunderstood the common practice of 303ing from resources
>> that are not documents as being supported by conneg, but maybe my
>> understanding has been flawed by listening to too many people's
>> opinion on httpRange-14 (as it seems everyone has one these days).
>>
>> Any enlightment would be greatly appreciated.
>
> The practice of 303-redirecting, as used by parts of the RDF
> community, is motivated by the desire to assign URIs not just (like on
> the WWW) to documents, but also to the things that are *described in
> the documents*, such as people, cities, products and so on.
>
> There was a lot of fighting about the best way to assign those URIs in
> a way that doesn't jeopardize the existing Web. In the end, some
> influential people insisted on a rule that has become the axiom now
> known as the "httpRange-14 decision":
>
>    If a resource has a representation, then it is a document. If it
> doesn't have a representation, it could be anything.
>
> From this axiom comes the requirement to have URIs that do not
> resolve to representations. In traditional, WWW-style Web
> architecture, that would be a weird idea; it's all about exchanging
> representations. But RDF people want it.
>
> So, we proposed two approaches to fulfill this requirement: the
> practice of using hash URIs (if </foaf.rdf> talks about a person, then
> that person could have the URI </foaf.rdf#me>); and 303 redirects (if
> </about/Berlin> is a document that talks about a city, then that city
> could have the URI </resource/Berlin> and 303-redirect to the  
> document).
>
> Let's ignore the hash URIs for a moment. The key to the 303 approach
> is this: It allows us to have resources that does not have a
> representation, but still continue the HTTP conversation to get to a
> document that describes the resource. So the idea is:
>
>     some_resource
>        |
>        +--303--> description_of_some_resource
>
> Now, <description_of_some_resource> could be just an RDF document; as
> you see, in its basic form, the 303 approach doesn't involve any
> content negotiation or different formats.
>
> But then, <description_of_some_resource> is a perfectly normal Web
> document, and as such it can be available in different formats,
> languages, and so on. A fairly common scenario is to have an HTML
> variant for Web browsers and an RDF variant for data browsers. If we
> follow the advice from Raman's TAG Finding, we would simply make
> <description_of_some_resource> a generic resource; and the two
> variants might be called <description_of_some_resource.rdf> and
> <description_of_some_resource.html>. If <description_of_some_resource>
> is requested, the appropriate variant is 200-returned to the client:
>
>     some_resource
>        |
>        +--303--> description_of_some_resource
>                     |
>                     +--Content-Location-->
> description_of_some_resource.{html|rdf}
>
> That's the clean and proper way of combining the 303 approach with
> content negotiation!
>
> Now, for a bunch of mostly historical reasons, people often omit the
> <description_of_some_resource> resource, and rather 303-redirect
> directly from the <some_resource> URI to
> <description_of_some_resource.rdf> or
> <description_of_some_resource.html>. So, they do not set up a generic
> resource, but rather they create two different descriptions for the
> different kinds of browsers.
>
>     some_resource
>        |
>        +--303--> description_of_some_resource.{html|rdf}
>
> In the context of the 303 approach, this is mostly harmless, because
> there is a redirect involved anyway, so this solution doesn't cause
> additional redirects and even looks a bit simpler than the previous
> one. It is now widely deployed by Linked Data publishers. The
> practical consequences of this simplification are small, I think, and
> therefore it's not really worth insisting on the "proper way" above.
> (Or maybe it is?)
>
> Unfortunate side effect: Many people got introduced to content
> negotiation through this 303 practice. Now they assume that content
> negotiation is always done with a redirect. Wrong! That would be bad
> practice outside of the specific context of 303 redirects.
>
> Finally, let me re-iterate that I prefer hash URIs over 303 URIs. They
> are easier to understand ("name something that is described inside the
> document by appending #something"), they are easier to implement, they
> do not require a redirect, they do not cause endless discussions about
> angels on pinheads etc etc...
>
> Best,
> Richard
>
>
>
>
>>
>>
>> Sebastien
>>
>>
>>
>>
>> --------------------------------------------------
>> From: "Richard Cyganiak" <richard@cyganiak.de>
>> Sent: Thursday, August 07, 2008 3:34 PM
>> To: "Sebastien Lambla" <seb@serialseb.com>
>> Cc: "T.V Raman" <raman@google.com>; <john.kemp@nokia.com>; <www-tag@w3.org
>
>>> ; <kidehen@openlinksw.com>; <tthibodeau@openlinksw.com>
>> Subject: Re: Question about the On Linking Alternative
>> Representations TAG Finding
>>
>>>
>>> Sebastien,
>>>
>>> Just a side note.
>>>
>>> Content negotiation as defined in the HTTP spec does *not* involve
>>> redirects.
>>>
>>> Content negotiation works by serving the appropriate variant
>>> directly  at the request URI, along with an optional Content-
>>> Location header  that gives a URI for the specific selected variant.
>>>
>>> There is a recent bad meme floating around, about implementing
>>> content negotiation by redirecting from one URI to another. This is
>>> not a good way of implementing content negotiation. In web
>>> applications, response time is key. Therefore, redirects should be
>>> avoided if possible.  Actual content negotiation implementations,
>>> such as mod_negotiation in  Apache, use the redirect-less approach
>>> described in the HTTP spec.
>>>
>>> (I think the meme is an unfortunate result of people getting
>>> confused  by the 303 redirects in the httpRange-14 debate. Again,
>>> content  negotiation does *not* require redirects and should be
>>> done without  when possible. The 303 approach uses redirects for a
>>> different reason.)
>>>
>>> Richard
>>>
>>>
>>>
>>> On 7 Aug 2008, at 14:39, Sebastien Lambla wrote:
>>>
>>>> So to get in context, if a generic resource redirects to a
>>>> variation with its own URL that will return a 200, hence an IR,
>>>> one argues  that conneg should still be possible from the IR to
>>>> another IR  related to the original generic resource?
>>>>
>>>> I argue that one should only allow conneg within the new scope
>>>> allowed by the IR, so that Conneg on /genericresource with accept:
>>>> application/html+xml will redirect to /genericresource.html, but
>>>> if requested as text/plain should fail. /genericresource.html
>>>> should however be able to conneg on other variables such as the
>>>> language  and may redirect to /genericresource(en).html
>>>>
>>>> In that definition there is no real generic resource, there is a
>>>> chain of resources that are more and more specialized, reducing
>>>> at  each step the range you can conneg against.
>>>>
>>>> Seb
>>>>
>>>>
>>>>
>>>> --------------------------------------------------
>>>> From: "T.V Raman" <raman@google.com>
>>>> Sent: Thursday, August 07, 2008 2:20 PM
>>>> To: <john.kemp@nokia.com>
>>>> Cc: <raman@google.com>; <richard@cyganiak.de>;
>>>> <seb@serialseb.com>; <www-tag@w3.org
>>>>> ; <kidehen@openlinksw.com>; <tthibodeau@openlinksw.com>
>>>> Subject: Re: Question about the On Linking Alternative
>>>> Representations TAG Finding
>>>>
>>>>> Correct, that is why I carefully separated out user-agents that
>>>>> send accept=*/* from other types of agents. When a user-agent
>>>>> sends out an explicit list of mime-types that it will accept for
>>>>> content negotiation I think the client and server should do full
>>>>> content negotiation as was originally intended by HTTP's content
>>>>> negotiation scheme.
>>>>>
>>>>> John Kemp (Nokia-S&S/Williamstown) writes:
>>>>>> ext T.V Raman wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> Returning to your final question, where the user-agent does
>>>>>>> content-negotiation, indicates a preference for one type, but
>>>>>>> asks by URI for the other, I would say respect the URI. I dont
>>>>>>> claim this to be *correct* in any sense, other than that I
>>>>> would
>>>>>>> break the tie this way. Reasoning: The client, by asking for a
>>>>>>> URI that directly resolves to a given representation has
>>>>>>> essentially bypassed content-negotiation.
>>>>>>
>>>>>> I think your interpretation is OK. But other servers may wish to
>>>>> respect
>>>>>> the HTTP Accept header sent in the request, rather than (or in
>>>>> addition
>>>>>> to) parsing the URI. This is server-driven negotiation, and the
>>>>> server
>>>>>> is attempting to meet the needs of its client. If the server
>>>>> feels
>>>>>> unable to adequately determine what the client wants, it may
>>>>> return an
>>>>>> HTTP 303 or 406 status code and allow the client to make a
>>>>> choice > itself.
>>>>>>
>>>>>> All of that is in the HTTP 1.1 specification. Anything other than
>>>>> HTTP
>>>>>> would presumably define a similar mechanism.
>>>>>>
>>>>>> I believe it makes sense to recommend that HTTP 1.1 content
>>>>> negotiation
>>>>>> via the HTTP Accept: header is the preferred mechanism for
>>>>> "breaking the
>>>>>> tie". If the user-agent can set the Accept header value to
>>>>> something
>>>>>> more specific than */* then it is already likely capable of
>>>>> setting the
>>>>>> _correct_ value for this header to get the content type it is
>>>>> asking > for.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> - johnk
>>>>>
>>>>> -- 
>>>>> Best Regards,
>>>>> --raman
>>>>>
>>>>> Title:  Research Scientist
>>>>> Email:  raman@google.com
>>>>> WWW:    http://emacspeak.sf.net/raman/
>>>>> Google: tv+raman
>>>>> GTalk:  raman@google.com, tv.raman.tv@gmail.com
>>>>> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
>>>>>
>>>
>
>

Received on Friday, 8 August 2008 07:59:17 UTC