- From: Sebastian Schaffert <sebastian.schaffert@salzburgresearch.at>
- Date: Mon, 17 Oct 2011 14:31:50 +0200
- To: Yang Squared <yang.square@gmail.com>
- Cc: public-lod@w3.org
Dear Yang, just as a small contribution to the discussion: as posted some months ago on this mailing list [1], we are developing the "Linked Media Framework" [2], aiming to provide unified access to content and metadata as well as retrieval and updates. The LMF is "backwards compatible" with the Linked Data principles, but we had to do a small change to allow for "symmetric" updating of resources: we are using "300 Multiple Choices" as status code for the HTTP redirect. The reason is that 300 was the only sensible choice that would allow us to treat a PUT request (for updating) analogously to a GET request, as all other redirect codes either have the wrong semantics (301, 302, 304, 307) or rewrite a PUT/POST request to a GET (301-303). According to my understanding of the description of the 300 status code, the semantics are appropriate for use with Linked Data [3]: "300 Multiple Choices The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location. Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise." My question to you is whether there is a reason you do not take into account 300 redirects at all. Is there a specific reason for this? [1] http://lists.w3.org/Archives/Public/public-lod/2011May/0019.html [2] http://code.google.com/p/kiwi/ [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Greetings, Sebastian Am 17.10.2011 um 12:41 schrieb Yang Squared: > Following the HTTP-range-14 discussion, we developed a Semantic Web URIs Validator named Hyperthing which helps to publish the Linked Data. We particularly investigated what happens when we temporary and permnent redirect (e.g. 301 and 302 redirections) of a Semantic Web URI (303 and hash URI). > > http://www.hyperthing.org/ > > Hyperthing mainly functions for three purposes: > 1) It determines if the requested URI identifies a Real World Object or a Web document; > 2) It checks whether the URIs publishing method follows the W3C hash URIs and 303 URI practice; > 3) It can be used to check the validity of the chains of the redirection between the Real World Object URIs and Document URIs to prevent the data publisher mistakenly redirecting between these two kinds. (e.g. it checks against redirection which include 301, 302 and 307) > > For more information please read > > Dereferencing Cool URI for the Semantic Web: What is 200 OK on the Semantic Web? > > http://dl.dropbox.com/u/4138729/paper/dereference_iswc2011.pdf > > Any suggestion is welcome. Sebastian -- | Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at | Head of Knowledge and Media Technologies Group +43 662 2288 423 | Jakob-Haringer Strasse 5/II | A-5020 Salzburg
Received on Monday, 17 October 2011 12:32:43 UTC