HTTPURIUseCaseMatrix

From W3C Wiki
Revision as of 17:00, 12 June 2012 by Jrees (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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)
ProposalChanges 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 inappropriatelyNew URI scheme fail . . fail fail fail  ? . . . .
RDF uses URIs inappropriatelyChange 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