I don't think there are any errors here, but I do have a couple suggestions:

* Keep in mind TBL's URI Axioms, especially...

Axiom: Opacity of URIsThe only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain other information.

* As a sanity-check, consider how one would configure Apache to implement these; see e.g. Apache's docs on Content Negotiation.

* I think you over-emphasize the "user" in User Agent, but keep in mind I've been yelling at people for talking about "clicking on DOIs" for fifteen years, too! But seriously, browsers are merely "machines" operating on the user's behalf, playing their role in the HTTP transaction based on (a) hard coding, (b) configuration and (c) user response. So I think less emphasis on human interaction, perhaps a single unified user agent section, would make the discussion less confusing ;)

John

Seriously, it's great for you to stand up and make assertions like these; it's helpful to everyone!

RE Statement 1: I think you are saying that we should not rely upon, and cannot count on, "things" making assertions about themselves. The bit I might challenge you on is the relationship of various representations to the "thing" and to their "siblings."

Let me explain: I believe that it is legitimate to have a HTTP URI for a thing, and for their not to be any representations of that "resource" itself. I further believe it is legitimate to have multiple HTTP URI-named resources "related" to that thing; these can be widely varied in nature, from text/html text/pdf to application/rdf+xml to foo/barumph and the only requirement should be that they are all "plausibly" related. By "plausibly," I simply mean that there exists some predicate; it could be foo:anythingButRelated.

I think this gets to your Statement 2: conneg should be used for whatever conneg can be used for. But yes, it is expected and SHOULD be the case that any representation of RDF returned (a) should refer to the same thing and (b) should be logically consistent, or "the same RDF" as you say. Similarly, one would expect text/html and text/pdf representations to be consistent. But it is important to note that these are semantics imposed by a particular application space and not by the HTTP 1.1 specification; providers are free to do what they want, as long as they don't break the protocol. They might soon lose adopters, however...

The caveat in the paragraph above is that HTTP is stateless. One way to interpret this is, technically it is not an error if I PUT an update for a URI, immediately GET it (same content-type) and have it be different. Also, technically, it is not an error for

Finally, I respectfully disagree with what you've said about APP; I do think it applies here. I think APP is a great example of a symmetrical application of GET and PUT for given a specific content-type. No, APP doesn't say anything specifically about conneg, but that is implied by the explicit inclusion of content-types in the request headers. But I might be stretching it a bit, suggesting (beyond APP) that simply because I can GET from (e.g.) a set of alternative types, that I should expect to PUT the same variety.

I'm not sure about your point regarding PUTs to undefined URIs; as the spec says, GETs and PUTs (and DELETES) can only be requested for defined URIs, whereas POSTs are about creating resources. Perhaps I'm missing your point there.

This makes sense when the representation formats are very similar, but may not make sense for widely varying representation formats. For example, when negotiating for a graph image representation (image/png) of the same resource delivered via a text-based representation format (application/atom+xml) it is likely that not all the same data elements will be returned, but the same _meaning_ will be conveyed.

It's a subtle difference, but one that relieves developers from trying to figure out ways to send _all_ the same data in _all_ possible formats and, conversely, dismissing some representation formats as inappropriate if _all_ the data cannot be represented.

Mike: fully agree and yes "there is nothing in the HTTP protocol that addresses this" for a good reason I feel. Also noted that a URI is just a URI, any assuming what is at the end of the URI (should you look it up / request it) is frankly wrong.

Larry: fully agree, the semantic web shouldn't tie itself to HTTP. As far as I'm concerned all that matters is that we have triples in the form of ( identifier , identifier , identifier ) where each identifier can be looked up in some manner for more information about the thing it identifies.

John:
As for APP, it's fantastic and a great example of the way things should be done, but it doesn't really touch on what we're discussing above as far as I can see. To create resources you POST to the URI of a Collection and (on success) get back a URI for the Member that was created, from this point on you PUT/DELETE to the URI of a Member, it doesn't say anything (afaik?) about sending a PUT to an undefined URI. Nor does it say anything about content negotiation (on the Accept header). And just to re-afirm what I personally think, this is the way things should be done, the Atom Publishing Protocol is clear on how you handle publishing Atom, everything else is out of scope.

Everyone:
Basically I want to defer this back to all of you, my peers, I've only got 10 years behind me and not all at this level of discussion.. so here are two statements which I'd like you to respond to in some way, even if its just a "wrong" or "sounds good"

Statement One: the link between an RDF description and the thing it's descibing should always be a one way link, from RDF to thing. For Linked Data to work this must *always* be true, it's no good an HTML document linking to it's description if "London" or "Bobs Car" or even a GIF image can't.

Statement Two: With regards HTTP Linked Data, content negotiation (on the accept header) should only be used to accept the same RDF serialized as different mime/types.

Please do rip those statements to shreds; I'm very keen to have clarity on these matters.

note: all of these posts are just me learning and thinking out loud so I can get some feedback from the community as to where I'm going wrong, thus, thanks for the feedback :) it's very appreciated.

To the HTTP app-protocol, the URI identifies a "Resource." In your post here you categorize these resources into three types (hypermedia/files, services, things).

Seems that what you are really saying is that some resources are WRITE-able (your file type), others are not (service, thing). While that may be true, there is nothing in the HTTP protocol that addresses this and, to my knowledge nothing in common markup formats (XHTML, XML, HTML, RDF, etc.) that make that distinction, either.

proposed update to 2616 in httpbis committee.

Personally, I think that using content negotiation as a way of getting both a document and its metadata is a bad idea, as it ties down the abstract notion of associating access to a resource and access to "information about the resource" too tightly to the HTTP protocol.

I wish the "Semantic Web" wouldn't tie itself to HTTP; e.g., peer-to-Peer distribution doesn't have content negotiation.

Larry

See RDF 5023, esp. Section 5: Protocol Operations and Section 9: Creating and Editing Resources. In the second case, a full example of a POST is given, showing the proper specification of the content-type.

Curious if, and how, the clarification that APP provides might impact your thinking?

I've completely used the wrong term here (Stored Hypermedia) in my naivety haven't I?! The second I read your doc on Hypermedia Types I realised.

What I'm trying to refer to by Hypermedia in this case is just a "file", but the term Document implies different things to readers, obviously stored hypermedia is grossly wrong, can you suggest a better (correct and unambiguous) term for it??

Thanks :)

HTTP allows clients to share data representations. These can be data from a server or data from a client. Clients can request data representations (GET) and can send data representations (POST, PUT). They can also make requests for servers to DELETE something.

The representation format for read operations (GET) and write operations (POST, PUT) need not (often are not) symmetrical. Representations sent by clients need not contain hypermedia links to be PUT-able.

You are correct in identifying that the semantics of POST indicate a "subordinate" aspect where PUT does not. This is an important aspect and has nothing to do with representation formats.

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).

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

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