HTTPURIUseCaseMatrix
See also TagIssue57Home
This table was created on the whiteboard at the TAG meeting 2012-04-04, and elaborated subsequently.
Use Case Matrix
The matrix records how well various cases fare under various proposals.
The proposals are defined in TagIssue57Responses. The use cases which are A-F columns are detailed in HTTPURIUseCases:
- L. Treatment of legacy RDF (cannot change message or content)
- A. Refer to naive document (can't change content)
- B. Refer to document from within
- C. Refer to subject of document from within (2xx a MUST)
- D. Refer to subject of document (single round trip a MUST)
- E. Ontology of hashless URIs (provisioning negotiable)
- J. Naive linked data with 200, hosting service
- K. Aggregation (interoperability)
- H. Monotonicity
- M. HTTP consistency
- N. Reconciling incompatible uses (polysemy)
| Proposal | Changes if accept | L | A | B | C | D | E | J | K | H | M | N |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status quo, no change | Fix OGP et al., persuade NLI signers | . | . | . | fail | fail | . | fail | . | . | . | ? |
| Parallel properties | Public relations | . | . | . | ? | ? | . | ? | . | . | . | ? |
| Publish redirect rules | Persuade people to deploy rules | . | . | . | fail | . | . | fail | . | . | . | ? |
| New HTTP 2xx status code | Persuade people to deploy new code | . | . | . | . | . | . | fail | . | . | . | ? |
| Content unless opt-out, Proposal 25 | Document: header | . | . | . | . | . | . | fail | . | fail | fail | fail |
| Content unless opt-out, look for contradiction | Assert non-content (how?) | . | . | . | . | . | . | . | . | fail | fail | fail |
| Retract HR14a; no default rule | Retool RDF: [ :contentURI "http:// ... " ]; | fail | X | fail | fail | fail | fail | fail | . | . | ? | . |
| No Longer Implies (describedby needed) | Retool RDF: [ :contentURI "http:// ... " ]; | fail | X | . | . | . | . | . | . | . | fail | ? |
| Choose based on context (graph) | Details on 'markers' for choice | ? | ? | . | . | . | . | . | fail | ? | fail | . |
| Punning - choose based on property details | Change the RDF model theory? | ? | . | . | . | . | . | . | . | ? | ? | ? |
| Always content, pre-HR14b, "just say hash" | Remove 303 (??) | fail | . | . | fail | fail | fail | fail | . | . | . | . |
| RDF uses http: URIs inappropriately | New URI scheme | fail | . | . | fail | fail | fail | ? | . | . | . | . |
| RDF uses URIs inappropriately | Change RDF | fail | ? | ? | fail | fail | fail | ? | ? | ? | . | . |
Key:
- . = easily satisfied as is, or with allowed change
- fail = no way to satisfy use case given constraints
- X = inconvenient, must use [:contentUri "U"] or similar
- ? = requires more analysis, or for more details to be nailed down
Filling this out has required a number of judgment calls. I am prepared to explain my assessments but not prepared to answer, ahead of time, every question that might arise. Let me know if you want something explained.
Perhaps the row that will raise the most eyebrows is the set of 'fails' under 'retract'. The point here is that it if nothing can be assumed about the meaning that a receiver cooperating with the proposal gives a hashless URI in RDF, then it doesn't make sense for senders to use that URI in new documents. Worse, there is no specification in place to explain what past uses of the URI meant. It does not help to say that retraction paves the way for some future agreement; to get something reliable you have to write down what the agreement is - and that means "some agreement", not "no agreement".
-JAR