- From: Nathan <nathan@webr3.org>
- Date: Mon, 15 Mar 2010 01:03:19 +0000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: www-tag@w3.org, ietf-http-wg@w3.org
Roy T. Fielding wrote: > On Mar 14, 2010, at 10:17 AM, Nathan wrote: > >> Here is the full problem and solution I'd like to use: >> >> I'm stuck with Linked Data, which is tied to the http scheme > > No, it isn't, unless you mean the data you happen to be using > is only identified by http scheme URIs. > >> and >> has a constraint that the http scheme URIs we use as identifiers must be >> dereferenced via http. > > Are you making this up? No known system that I am aware > of has that limitation. I think I worded it wrong, duly noted - I was referring to the case where data is only identified using http scheme URIs and the assumption that I should/must provide lookup (at this time) via dereferencing using an http get, primarily because nobody else is talking about another way of looking up those identifiers (that I am aware of). >> The only way is forwards from what I can tell. >> >> As I see it (within the http scheme of uris), a resource is a conceptual >> map to anything; that anything either has a representation that can be >> sent via http or does not. In the case where it does not, the concept >> maps to an "empty set" of representations. > > Not really, no. HTTP provides an interface for interacting with > resources by way of making a request with a standard method upon > a request-target that is a URI (with various parts scattered about > for historical reasons). HTTP provides that interface for URIs > of any scheme. Naturally, the native "http" scheme is most popular > for this purpose because it maximizes the HTTP interface without > requiring additional name services beyond hostname resolution (DNS). > > The GET method, when applied to any resource, means get me a > current representation of the identified resource. HTTP doesn't > need to say how it is possible for the server to know or obtain > such a representation -- it simply does or does not do so. noted and thanks for clarifying; I'd made that mental mistake of binding HTTP to the http scheme. >> With regards the above this calls for the usage of only 4 http status >> codes (from what I can tell, certainly I could get by with them), as >> follows: >> >> 204 No Content (in the case of GET), resource which maps to an empty set >> / does not have a representation of its own that can be transferred by >> the server over HTTP and no other resource is known which describes the >> requested resource. > > No, 204 means no content is the reply. It is never used with GET. > 404 means there is no current representation (i.e., not found). that wipes out that option then! is there even such a thing as found but with no description? i feel there is but now questioning. somebody else suggested a 303 which resolves to a 404 - would that work? >> 301 Moved Permanently, The requested resource has been assigned a new >> permanent URI and any future references to this resource SHOULD use one >> of the returned URIs. Clients with link editing capabilities ought to >> automatically re-link references to the request-target to one or more of >> the new references returned by the server >> >> 303 See Other, indicates that the requested resource does not have a >> representation of its own that can be transferred by the server over >> HTTP, and additionally specifies a resource which may provide >> information about the requested resource. > > Yes, when used in response to GET. > >> 410 Gone, The requested resource is no longer available at the server >> and no forwarding address is known. This condition is expected to be >> considered permanent. Clients with link editing capabilities SHOULD >> delete references to the request-target after user approval. >> >> All of these codes are there already and do the job perfectly (imho), >> and the others do not matter with regards linked data since we aren't >> dealing with things which have a representation / entity. > > Well, then you aren't using linked data. I don't know what you > are doing, but it is almost certainly wrong to say that data has > no representation, and the whole point of linked data is to > link the data via representations. agreed, really I just want a way to "reserve" a resource/uri unambiguously. >> additionally, it may be worth noting that I'm not doing any "content >> negotiation" with a 303 See Other, rather I'm doing any required content >> negotiation on the second resource, the one pointed do by the Location >> header; personally I find it cleaner to keep a distinction between >> resources with a representation and those without, and view content >> negotiation in response to a request on a resource with no >> representation as a cross cutting concern, hence dually seperated. > > Agreed. > >> I am aware this would be a refinement to the resolution of httpRange-14, >> have done vast amounts of research on this (more than I expected) and in >> reality I'm just a developer who is blocked on a project and I just need >> some kind person from IETF/W3C (pref TAG) to say this doesn't conflict >> with the architecture of the world wide web or conflict with HTTP/REST. >> >> Which means, somebody like Larry, or Roy, Tim etc; or even Jonathan Rees >> as this very much ties in with the work on >> http://www.w3.org/2001/tag/awwsw/http-semantics-report.html > > Good luck with that. The semantics report postulates a theory > of existence for resources that simply does not matter to HTTP, > and hence will be irrelevant to any real system you might build > using HTTP aside from a closed-world graph theorem prover. > > Even the REST notion of a discontinuous conceptual mapping function, > which says exactly the same thing as the "correspondences" > discussion in only four words, is merely an attempt to explain > reality to a formalist, not make a formal restriction on reality. > >> I'm really stuck here, and it's having real effects on my daily >> life at home - I need to get this project finished and the above is the >> only realistic solution after all my hunting; I'm trying so hard to do >> things by the book :( > > Implement it first, using what works, and then tell the TAG > what the theory should be. > > Cheers, > > Roy T. Fielding <http://roy.gbiv.com/> > Chief Scientist, Day Software <http://www.day.com/> Thanks Roy, will try and get something working properly; facing many challenges and hence all the feedback requests. as a side note; does anybody have any suggestions for looking up data with something like tdb uris? if there is a better way than just using http scheme to dereference, even to be used in addition to http scheme uri's, I'd be most interested - obviously keen not to have all the data I ever produce bound to http scheme uri's only for looking up to get more info etc. Many Regards, Nathan
Received on Monday, 15 March 2010 01:04:07 UTC