- From: Erik Wilde <dret@berkeley.edu>
- Date: Wed, 16 Jan 2008 12:36:46 -0800
- To: "uri@w3.org" <uri@w3.org>
Sandro Hawke wrote: >> so i assume to discover the non-http nature of the resource >> identified by u1, there must be some content within the returned >> resource that makes that statement. logically, i see three ways how the >> non-httpness of the identified resource could be established: >> 1. string matching with a magic prefix >> 2. the 303 returned when dereferencing the uri >> 3. embedded metadata in the returned resource >> what is the official vote on these? it seems that (2) is required, but >> it cannot be sufficient given the rather general definition of 303 in >> http. would (1) be ok? or is that discouraged? i am sure that (3) is the >> w3c's favorite given its inherent rdfness, but i am wondering whether in >> this whole approach there still is a chance for non-semantic web users >> to understand the non-httpness of the resource identified by u1. > The TAG reached consensus on 15 Jun 2005 to use option 2. That is not > as "official" as a W3C Recommendation or a new IETF RFC for HTTP, but > it's what we've got. See: > http://www.w3.org/2001/tag/issues.html#httpRange-14 sorry, my question was not clear enough. if i dereference an http resource and get a 303, based on http alone, that can mean almost anything. does the tag finding chnage that to always mean that if i get a 303, it *always is* a non-http resource? http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 looks to me as if this were not the case ("the resource identified by that URI could be any resource" means it could also be an information resource, right?). so as someone getting a 303, i need some additional way of establishing the non-http nature of a resource, right? the 303 alone does not tell me enough, it only tells me that i should look for further hints to establish the nature of the resource, because it could be non-http. so (2) only lets me start, but i need more to really understand the nature of the resource. i am sure option (3) above is something the w3c likes, but it would make the non-httpness of a resource visible to semantic web agents only. option (1) above would make that easier, and most people in recent weeks seemed to favor this approach. i am curious to hear your opinion about this second step in the whole process. thanks, dret.
Received on Wednesday, 16 January 2008 20:37:28 UTC