HttpRange14Requirements

DRAFT, NOT READY FOR PUBLIC REVIEW - please use talk page for discussion

Here are articulated putative requirements for amending httpRange-14, with their sources given in parentheses. (TBD: hyperlink to original sources)

I (Jonathan Rees) am using very loose language here... I know someone will complain so I plan to make this a bit more rigorous (although anyone who's been paying attention to my writings will know what I mean).

Ellipsis ... means a cumulative requirement (i.e. Z3 is met only when Z2 is as well). So the requirements in each series are strictly more challenging.

Document (or information resource) reference

T: There needs to be a theory of "on the web at a URI" adequate to support common metadata use cases such as Dublin Core, FOAF, and CC REL (JAR). [TBD: be more specific.]

T could be met by JAR's theory, so is only difficult to meet if that theory is rejected (e.g. as a result of E). Since defining a URI using a property like ir:onWebAt is not incompatible with any solution (except maybe one based on sound ontology), the analysis might be simplified by simply assuming that T is met (although it would help if everyone recognized that there is a need for it).

A0: The must be an agreed way to refer to any document/IR on the web (in the TimBL or JAR sense), even incorrect RDF documents
A1: ... using a URI (TimBL + webarch)
A2: ... that can be used with some widely available protocol to retrieve "something helpful"
A3: ... using HTTP because it's the only "widely available protocol"
A4: ... and, hmm, retrievals using the reference URI should yield retrievals of [versions of] the document/IR at original URI (automatic if original URI = reference URI)
A5: ... and, well, in particular one should refer to the document/IR at the URI using that URI, not some other one

A0 can always be met by agreeing on some blank node notation such as [ir:onWebAt "http://example/document"]. See the web metadata memo. A3 can be met using hash or 303.

URI binding via definition or description

B0: There must be agreed ways to choose a URI and provide a discoverable description/definition document for it (linked data 1)
B1: ... that can be used with some widely available protocol to retrieve "something helpful", in particular the description/definition document (linked data 2)...
B2: ... specifically hashless URIs (H Halpin/M Sporny)
B3: ... using HTTP because it's the only "widely available protocol" (linked data)
B4: ... with at most a single round trip in the usual case (G Tumarello)
B5: ... on hosting services i.e. no 303 or 209 (H Halpin/M Sporny)

B3 (and thus B0, B1, B2) is automatically met by hash and/or 303 URIs, which we take as given. The critical requirements are B4 and B5.

(Possible additional desideratum: The architecture must be easy to explain.)

Coordination between A and B

C0: For each URI that might result from either process A or B, there must be an agreed way to determine a process that might have applied (A or B). The outcome is understood without prejudice as to whether the URI might result from the other process as well (comment at talk page))
C1: ... furthermore, it must be possible for an automated agent to make this determination (JAR)
C2: ... without having to scan an entire representation, or examine more than one representation (JAR)

Since we aren't changing the way hash URIs work (right?) it suffices to consider hashless URIs in analyzing C series conformance.

D: Whenever there is an IR/document at a URI there must be a way for the agent controlling protocol behavior for that URI to also provide a description/definition of the URI/document in a different document (TAG issue 62)

The Link: header would be one way to meet this.

Principled references

E: For clarity, the convention A for referring to a document/IR needs to be based on sound ontology (Alan Ruttenberg)

F: Any reference to an IR/document in A or B is as of a date specified in the reference (Larry Masinter, tdb: / duri:)

The issue

A5, B5, and C0 together form an unsatisfiable set of requirements, as explained in the 'referential use' memo.