Comments on: HTTP RFC paraphrased for the Web of Data http://webr3.org/blog/semantic-web/http-rfc-paraphrased-for-the-web-of-data/ brain's on fire! Fri, 22 Apr 2011 00:44:37 +0100 http://wordpress.org/?v=2.9.2 hourly 1 By: John S. Erickson, Ph.D. http://webr3.org/blog/semantic-web/http-rfc-paraphrased-for-the-web-of-data/comment-page-1/#comment-237 John S. Erickson, Ph.D. Tue, 02 Mar 2010 18:36:43 +0000 http://webr3.org/blog/?p=213#comment-237 +1 on the post, Nathan! Here's a question: are GET and PUT <i>symmetrical</i>? Perhaps my question is a bit out-of-band, because the context of my question is really about the symmetry of <a href="http://www.ietf.org/rfc/rfc2295.txt" rel="nofollow">content negotiation</a>. Implicit in <a>RFC 2616 section 14</a> is the existence of a (potentially) wide variety of alternate representations that may be accessed via the HTTP/1.1 request header fields; in the world of <a href="http://linkeddata.org" rel="nofollow">linked data</a> these are useful for differentiating between <code>text/html</code>, <code>application/rdf+xml</code>, <code>text/rdf+n3</code>, etc. So maybe the heart of my question is this: in a linked data world where <a href="http://www.ietf.org/rfc/rfc2295.txt" rel="nofollow">conneg</a> is alive and well (and assumed), what should be the correct interpretation of RFC 2616's <i>(if) the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server</i>? If I can GET a resource to the resolution of a MIME type, should I not expect to PUT to that same resolution as well? Or, if during a GET the server responds with a list of <code>Alternates</i>, shouldn't I expect to PUT using any of those choices? Readers familiar with MIME-typed disseminators in the digital repository world (think: Fedora) might think of this as a question about MIME-typed "ingestors"; it is a similar issue: instead of requesting a particular manifestation of the object, this is about updating a specific manifestation (possibly updating the whole). +1 on the post, Nathan!

Here's a question: are GET and PUT symmetrical? Perhaps my question is a bit out-of-band, because the context of my question is really about the symmetry of content negotiation. Implicit in RFC 2616 section 14 is the existence of a (potentially) wide variety of alternate representations that may be accessed via the HTTP/1.1 request header fields; in the world of linked data these are useful for differentiating between text/html, application/rdf+xml, text/rdf+n3, etc.

So maybe the heart of my question is this: in a linked data world where conneg is alive and well (and assumed), what should be the correct interpretation of RFC 2616's (if) the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server? If I can GET a resource to the resolution of a MIME type, should I not expect to PUT to that same resolution as well? Or, if during a GET the server responds with a list of Alternates, shouldn't I expect to PUT using any of those choices?

Readers familiar with MIME-typed disseminators in the digital repository world (think: Fedora) might think of this as a question about MIME-typed "ingestors"; it is a similar issue: instead of requesting a particular manifestation of the object, this is about updating a specific manifestation (possibly updating the whole).

]]> By: nathan http://webr3.org/blog/semantic-web/http-rfc-paraphrased-for-the-web-of-data/comment-page-1/#comment-236 nathan Tue, 02 Mar 2010 17:57:03 +0000 http://webr3.org/blog/?p=213#comment-236 Thanks for the comments Michael :) I've added in a clarification on why I've chosen rfc 2616 over HTTPbis for this post - totally agree that it's worth linking to HTTPbis; and thinking a follow up post comparing what the two say on these details may be warrented in the near future..?! Regarding fragments and URI / URL / URIref, you're right this subject is far too complicated to simply comment on a small detail then defer to nothing, so I've removed it :p and added in a link to see your comments. ps: nice info about fragment identifiers in URIs on the Media Fragments WG! Cheers Thanks for the comments Michael :) I've added in a clarification on why I've chosen rfc 2616 over HTTPbis for this post - totally agree that it's worth linking to HTTPbis; and thinking a follow up post comparing what the two say on these details may be warrented in the near future..?!

Regarding fragments and URI / URL / URIref, you're right this subject is far too complicated to simply comment on a small detail then defer to nothing, so I've removed it :p and added in a link to see your comments.

ps: nice info about fragment identifiers in URIs on the Media Fragments WG!

Cheers

]]> By: Michael Hausenblas http://webr3.org/blog/semantic-web/http-rfc-paraphrased-for-the-web-of-data/comment-page-1/#comment-231 Michael Hausenblas Tue, 02 Mar 2010 15:38:06 +0000 http://webr3.org/blog/?p=213#comment-231 Nice post, Nathan! One thing I'm wondering, though: HTTPbis is upcoming [1] and many of the referenced pieces might have an updated wording (even fixing some bugs or clarifying things). Don't you think it would be beneficial to readily link to the respective HTTPbis documents rather than to the (soon) outdated RFC2616? Just my 2c ;) BTW, regarding fragments, oh well, IMHO this is a bit more complicated as you phrased it. It is correct that RFC2616 (from 1999) does not talk about it. But there is still the Generic URI syntax, RFC3986 [2] (from 2005) that defines what a fragment is [3], essentially deferring it to the media type at hand defining its semantics. See also my write-up in the Media Fragments WG concerning this issue [4] (not to talk about the difference between URI and URIref ;) Cheers, Michael [1] http://tools.ietf.org/wg/httpbis/ [2] http://tools.ietf.org/html/rfc3986#section-3 [3] http://tools.ietf.org/html/rfc3986#section-3.5 [4] http://www.w3.org/2008/WebVideo/Fragments/wiki/Semantics Nice post, Nathan! One thing I'm wondering, though: HTTPbis is upcoming [1] and many of the referenced pieces might have an updated wording (even fixing some bugs or clarifying things). Don't you think it would be beneficial to readily link to the respective HTTPbis documents rather than to the (soon) outdated RFC2616? Just my 2c ;)

BTW, regarding fragments, oh well, IMHO this is a bit more complicated as you phrased it. It is correct that RFC2616 (from 1999) does not talk about it. But there is still the Generic URI syntax, RFC3986 [2] (from 2005) that defines what a fragment is [3], essentially deferring it to the media type at hand defining its semantics. See also my write-up in the Media Fragments WG concerning this issue [4] (not to talk about the difference between URI and URIref ;)

Cheers,
Michael

[1] http://tools.ietf.org/wg/httpbis/
[2] http://tools.ietf.org/html/rfc3986#section-3
[3] http://tools.ietf.org/html/rfc3986#section-3.5
[4] http://www.w3.org/2008/WebVideo/Fragments/wiki/Semantics

]]>