HTTP Semantics

This is a temporary page not related to the Neurocommons project.

Two problems around curating HTTP exchanges in RDF:
 * 1) Curation at approximately one time (time-oblivious)
 * 2) Curation of several interactions occurring over time (time-aware)

For a given resource R (the one named by the target URI), an HTTP exchange says some things about it, one or more of the following:
 * 1) R exists (at this time) or didn't exist before now (created)
 * 2) R "resides at" or "is located" somewhere (now, or over an interval)
 * 3) R "has information" E, i.e. E "corresponds to" R (now, or over an interval)
 * 4) R is "described by" some other resource DR (now, or over an interval)
 * 5) possibly others

For each time-sensitive property P i.e. P(source, object, time), we will need an RDF predicate P1(source, object) for use when time is understood or not of interest, and an RDF class P2 whose members are the relationships of sources to objects over time. (You can think of these things as being statements in the sense of RDF reflection, or of being qualities inhering in the source, if you like BFO.) If x is in class P2 then x has a source and an object, and is related to times (P(source, object, some time)) and/or intervals (P(source, object, t) for all t in the interval).

Two approaches to modeling redirects A 307 B
 * 1) As HTTP says: There is a resource that resides at URI "A" at one point in time and at URI "B" at another point in time.  Thus we need an "resides at" relationship between resources and URI literals.  The URIs are logically independent of the ones used in our RDF.
 * 2) As JAR originally suggested: Use the URI in the HTTP exchange to name one resource consistently, ignore the "resides at" language in 2616, and say instead that properties one learns of B are also true of A (e.g. E corresponds to B implies E corresponds to A)

The "residence" theory would require that multiple resources can reside at the same URI at the same time. E.g. one might have distinct resources X and Y residing at URIs A and B at time t1, and then at t2 they both reside at B (due to a 307 redirect from A to B). (The resource at B can't stop residing there merely as a result of a redirect from A.) The "residence" URI is merely the place you send HTTP requests in order to learn about the resource.

The effect of these two approaches is similar, I believe, except that the "redirection" approach might require that you continue using HTTP to obtain information about the resource, while the resource-based approach lets you use any line of inference at all - you could have non-HTTP-based information about Y that thanks to a 307 could be transferred to X. (Only certain information can be transferred from Y to X, of course, see list at top of page.)

"Resides at" isn't quite the right term, since the resource in question could be one that doesn't reside anywhere (e.g. a class) - it's the description that is found via the URI, not the resource. (E.g. Dublin Core.)

Similarly if we do take redirection as a relation between resources, we can't call this "delegation" since the resource may have no ability to delegate and/or no role in the HTTP exchanges. It is the servers that delegate, to other servers, not resources.

The "speaks for" analysis suggests that HTTP resources (information resources?) are principals - entities to which utterances are attributable, or that authorize utterances, or that can be held accountable for an utterance. Then the "corresponds to" / "has information" relation is like ABLP "says": information resource says representation. If the IR speaks for some agent A, and the IR 'says' a representation, then A says the representation. But how we would come to learn that R speaks for A is unclear and probably out of scope. A priori each IR is an independent principal and no IR speaks for anyone. Clearly people come to believe that IRs speak for agents, however - this may be what home pages and certificates are for...

Whether there need to be principals that are not IRs (i.e. whether we need the IR notion at all, or can dispense with it in favor of principal) is not clear. It would be consistent to get a 200 response from a URI naming a person, if the entity were attributable to that person. But somehow we want to rule this out; why? What does such a prohibition get us?

TimBL has encouraged me to use "representation" instead of "content entity". The way I would rationalize this to myself is that the sense of "represent" is not that of a photograph representing a scene, but rather is "represent" as in representative democracy - someone who speaks on my behalf. But then a better word for the thing would be "representative".

It would be nice to be able to reason about when a content entity (representation) does not correspond to a resource. New wording proposed for HTTPbis says the server is responsible for saying what constitutes "equivalence" among the entities corresponding to a resource. Simultaneous entities must be equivalent, so an inequivalent entity will not correspond to the resource.

This is a bit unsatisfying since it doesn't suggest any way to do an audit for proper content negotiation; the server always has plausible deniability.

At the very least we should be able to define what it means for a resource to be rational: R is rational if at any given time all entities corresponding to it are mutually consistent (i.e. don't contradict one another).

The recent discussion of browser address bar suggests that servers are not reliable when they state Y speaks for X (by issuing a 307), and users are not reliable in attributing representations E to agents A (they do it too often by erroneously assuming R speaks for A).