tag:blogger.com,1999:blog-8288183.post3191700037974456480..comments2023-11-05T04:50:49.218-05:00Comments on Vowel Movement: Returning HTTP 303s for Semantic Web URIsAnonymoushttp://www.blogger.com/profile/16377117761292204691noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8288183.post-54122385355264861892007-10-05T09:40:00.000-04:002007-10-05T09:40:00.000-04:00I have given this a lot of thought. The temptatio...I have given this a lot of thought. The temptation to do something more interesting with the bodies of 303 responses seemed compelling on the surface. The more I thought about it, however, the more I realized that simpler is better - and more Web-like.<BR/><BR/>The reason is that (as far as I can see) there is nothing (nothing!) that one can do with an RDF body that one cannot do by redirecting to an RDF document (via the Location header). Sure, following the Location header requires another network connection and the attendant time, but it also means that the resource is properly addressable by URL.<BR/><BR/>So, I think the solution to 303 bodies is to keep them simple: A single URL in a single Location header and an auto-generated XHTML body duplicating the information in the Location header in more human friendly terms ("More information about this resource is available at URL_GOES_HERE").<BR/><BR/>However, there is still the need to properly identify non-information resources on the Semantic Web. That's where a best practice approach might come in. I suggest that any URL that returns a 303 <I>with a Location header that points to an RDF document</I> be considered a non-information resource (that is, either a physical, "real world" resource (like my car) or a conceptual resource (like the concept of a car). The RDF eventually returned from following your nose is then known to provide information about the resource in question without being confused with <I>being</I> the resource itself.<BR/><BR/>Is a 303/RDF combination adequate to describe non-information resources in general? I think so. Is a 303/RDF combination also useful for describing information resources? Yes, but I don't see any reason to impose a 303 to describe an information resource: one could jump right to some RDF.<BR/><BR/>What do others think about that?Anonymoushttps://www.blogger.com/profile/16377117761292204691noreply@blogger.comtag:blogger.com,1999:blog-8288183.post-61973764009896947382007-09-03T20:13:00.000-04:002007-09-03T20:13:00.000-04:00I'm with Tim here. I think posting anything of rel...I'm with Tim here. I think posting anything of relevance in the message body of a 303 is a bad idea. The 303 is a <EM>redirect</EM> status code, which means it <EM>points someplace else</EM>, and is not intended to deliver content back to the client.<BR/><BR/>Almost <EM>all</EM> browsers and HTTP clients automatically redirect to the Location URI. That's how redirects have always been handled, and many web sites rely on it (303-after-POST is a standard REST idiom). I don't understand why that surprises you, isn't that how HTTP redirects are supposed to work?<BR/><BR/>This means it is impossible to get at the message body of the 303 response with a standard web browser or the standard HTTP stacks in most programming languages. Thus, putting anything of interest in there is a bad idea.<BR/><BR/>The HTTP spec actually tells you quite clearly what <EM>should</EM> go into the body: A short hypertext note with a link to the Location URI. As with all redirect status codes, the purpose of this is historical: There were very old browsers that didn't support automatical redirects, and they would display the message body instead. Including that hypertext note prevented them from getting stranded. In other words, it's obsolete today, and whatever you put in there today, no user will ever see it.<BR/><BR/>So I think Tom is doing the right thing by not worrying at all about this, and just letting Apache insert its little auto-generated message.<BR/><BR/>Simply use the Location header to point to a URI where information about the resource can be found. Whatever you planned to say inside the 303 message body, just say it in the redirection target. That's the approach implemented by almost all of the datasets in the <A HREF="http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData" REL="nofollow">Linking Open Data</A> project. It's simple, it works, without any need for messing around with 303 message bodies or new headers.<BR/><BR/>To give you my answers to your questions:<BR/><BR/><STRONG>What should it contain?</STRONG> A short hypertext note with a hyperlink to the new URI(s).<BR/><BR/><STRONG>How should it be formatted?</STRONG> Don't care, in all likeliness no one will ever see it.<BR/><BR/><STRONG>Does a "short hypertext note" constrain implementations to a text/html MIME type?</STRONG> No, though it doesn't matter.<BR/><BR/><STRONG>How short is "short"?</STRONG> One sentence will do.<BR/><BR/><STRONG>Can there be more than one Location header?</STRONG> Existing HTTP implementations redirect to the first one and ignore any subsequent headers. No point in putting anything in there.<BR/><BR/><STRONG>If not, what do all the other URIs in the hypertext tell a user? Arbitrarily anything? If so, there is no limitation.</STRONG> Most likely, no user will ever see it.<BR/><BR/>That being said, I'm totally with you regarding HTTP URIs vs. DOI, INFO, LSID and friends. And I'm very much looking forward to an updated PURL that supports 303s.Unknownhttps://www.blogger.com/profile/02190484170646718345noreply@blogger.comtag:blogger.com,1999:blog-8288183.post-21602973075022977662007-08-31T13:38:00.000-04:002007-08-31T13:38:00.000-04:00I think it's a great idea to return application/rd...I think it's a great idea to return application/rdf+xml or an HTML document containing RDFa markup in the entity of a 303 response <I>if the returned content-type is consistent with the request Accept: list</I>.<BR/><BR/>If the request says that application/rdf+xml (or */*) is acceptable to the client then it seems perfectly reasonable to me to consider an RDF entity to be the specified "hypertext note" in a 303 response.<BR/><BR/>I also believe that the behaviour you note of deployed browsers automatically following 303 Location headers is but one more reason why leveraging http: URIs for meat space resources is good for users. The Location returned can be a function of the Accept value in the request, allowing the client to be referred to a specific "see other" resource that is most acceptable to it. I do agree that it would be a help to users if browsers were to indicate when the are following a 'see other', perhaps in the status bar at least. (I'd like to see browsers have a general metadata sidebar where lots of stuff, including security information, citations, and annotations could be indicated.)<BR/><BR/>As I was reading (linearly) your post, I stumbled on the phrase "referred to" in your second paragraph. To my ears, all URIs (http or otherwise) are a "reference to" something. The information resource vs. physical resource distinction is one of <I>retrievability</I>. An 'information resource' is one that can be transported across the Internet. Someday we might be able to so transport meat space resources but not yet. So, in paragraph 2 I'd have used the phrase "retrieved [by]" rather than "referred to [by]".<BR/><BR/>I agree with TimBL that the entity in a 303 response should not be considered to be directly addressable. You argue that this is the entity that is returned with a GET on a particular URI but I retort that there are even fewer promises about the repeatability of getting this entity on subsequent requests than there are on "normal" 200 responses. I take the statement in the HTTP spec that the 303 response MUST NOT be cached as supporting this claim. Imagine, if you will, what URI you'd use to refer to that 303 entity as the subject of some RDF statements. It certainly wouldn't be appropriate to use the original request URI -- that names a (perhaps meat world) resource, not the response entity. On the other hand, I think it should be perfectly fine to return "interesting" information in the 303 response. It's too valuable a place to not use for something.Ralph R. Swickhttps://www.blogger.com/profile/16302763869234798747noreply@blogger.comtag:blogger.com,1999:blog-8288183.post-40190507612858197912007-08-31T08:49:00.000-04:002007-08-31T08:49:00.000-04:00Because I am an optimist by nature and a pessimist...Because I am an optimist by nature and a pessimist by experience :)Anonymoushttps://www.blogger.com/profile/16377117761292204691noreply@blogger.comtag:blogger.com,1999:blog-8288183.post-65817089942507399012007-08-30T13:33:00.000-04:002007-08-30T13:33:00.000-04:00David,Thanks for teaching me history, though IMHO ...David,<BR/><BR/>Thanks for teaching me history, though IMHO I am perfectly aware of your role :)<BR/><BR/>I see your points and think I do understand your reasons, BUT still do not understand why the 'statement' about 'RDFa may not become a standard' should be true. I might have missed something, but can you give some hints, pointers, explanations, whatever-you-got that actually supports this?<BR/><BR/>Cheers,<BR/> Michael<BR/><BR/>PS: Keep on doing the good stuff, regardless if with or without RDFa ;)Michael Hausenblashttps://www.blogger.com/profile/14137615634083089753noreply@blogger.comtag:blogger.com,1999:blog-8288183.post-65358718758799753912007-08-30T10:40:00.000-04:002007-08-30T10:40:00.000-04:00Hi Michael,I made the statement about RDFa for the...Hi Michael,<BR/><BR/>I made the statement about RDFa for the simple reason that it is so. It was not a rant, but merely a statement of fact.<BR/><BR/>Please note that I have a long history of supporting RDFa as co-chair of the <A HREF="http://w3.org/2001/sw/BestPractices/" REL="nofollow">Semantic Web Best Practice and Deployment Working Group</A>. In fact, I defended RDFa publicly and privately during times when others thought of killing it. However, it is not yet a W3C Recommendation.<BR/><BR/>Let's say that I made the same statement about GRDDL (also a candidate for embedding RDF into hypertext 303 bodies, by the way). GRDDL is already a Proposed Rec and the Working Group looks set to move it forward shortly. It is simply farther along. That is not your fault, but it is so.<BR/><BR/>However, I do <B>not</B> think that lack of Rec status should be the only consideration. I lead an effort to create a series of RDF databases (Tucana/Kowari/Mulgara) starting five full years before RDF became a Recommendation. It is wise, though, to look at both the likelihood of Rec status happening and the likelihood of wide industry adoption before suggesting a change to a fundamental part of Web Architecture.<BR/><BR/>The bottom line is this: My team is on the verge of implementing the new PURL service and need to choose useful mechanisms for 303 bodies. We had better get it pretty close to right because we and others plan to create a huge number of PURLs in the coming months, many (most?) of which will be 303s.Anonymoushttps://www.blogger.com/profile/16377117761292204691noreply@blogger.comtag:blogger.com,1999:blog-8288183.post-85864652398358482002007-08-29T15:33:00.000-04:002007-08-29T15:33:00.000-04:00David,What leads you to the statement ' The obviou...David,<BR/><BR/>What leads you to the statement ' The obvious downside is that RDFa is not a standard (merely an Editors Draft) and may not become one.'?<BR/><BR/>1. We are on rec track [1]. Ok - we are a bit behind schedule, but it was a very aggressive one ;)<BR/>2. Currently, most parts of the syntax are stable, test cases are being approved all the time, and we have plenty of implementations available.<BR/><BR/>Please, do not rant about these issues - or at least give concrete evidence.<BR/><BR/>Cheers,<BR/>Michael<BR/><BR/>[1] http://www.w3.org/2006/07/SWD/wiki/RDFaMichael Hausenblashttps://www.blogger.com/profile/14137615634083089753noreply@blogger.com