Denote vs. Dereference

There are probably hundreds of wiki pages dealing with the denotation / web access distinction, but the question here is not the "truth" (there probably is none), but how to present this problem in the URI note so that it leads to good advice and good practice.

Status Quo

Follow AWWW, which is a bit confused and doesn't really reflect semantic web practice.

Pat Hayes's view

To identify (for purpose of dereference) and to denote are different. The httpRange-14 resolution says that a 2xx response asserts that the relationships coincide (for a URI).

See [[/../StatusOfHttpScheme]].

JAR's view: Although this agrees with what TimBL has said, and is elegant in that it tells us exactly what a large class of URIs denote, this view conflicts with naive use of "information resource" URIs as denoting documents, blogs, etc. Can an http endpoint have an author? (Pat responds: You're nitpicking.)

Alan R's view

Endpoint is a service that may be related to the thing denoted, but isn't usually the thing denoted, even when we're talking about document-like things. The term denotes a document, and there's a service that responds to GET requests by responding with the document ("dereferences" the URI), but the service isn't the same as the document.

Problem: to be clear, we'd have to provide a definition of every URI, because there's no way a priori to tell what the relationship is between the two.

JAR's compromise

I take document-denoting terms to refer to what we want it to refer to - to what we (consensus) think the document is. This allows the possibility of server error: We can use a term to denote D, but if the server doesn't provide D at URI(D), then it is the server who is wrong, not us.

This is consistent with the view that 'web architecture' is prescriptive, not descriptive.

Types should be asserted, so that we know what kinds of promises are being made (consistent author, etc.).