httpRange-14 emacs buffer, TAG F2F

This emacs buffer was projected at the TAG F2F on 2012-04-04



Use cases

- Metadata in triple store, SPARQL query, get URIs identifying
  documents, want to look at the content, if content is retrieved it
  is expected to have the indicated properties
    e.g. code module database

[that was JAR's, other cases continued on wiki page
http://www.w3.org/wiki/HTTPURIUseCases ]




Criteria

- TBL: Kid doing homework.

- Does it lead to interop across use cases

- Don't be irresponsible

- Should not require a 4th information source

- Unique identification (see named rule in webarch - no collisions),
  see IRC log.

- Criterion: Would DC have to rewrite its abstract model?
  What do we say when they call us up?

- Criterion: Would CC have to rewrite its CCC REL Guide?
  What do we say when they call us up?

------------

A. Left hand column of diagram is not sufficient, it does not have
information so that it can be understood - JAR has been too
telegraphic.  Readily understood.

B. Set of use cases, Tim's start, what the world looks like under each
proposal, for each example.

(use pivot tables?)

C. Impact on sender, receiver, linkee.

Three dimensional table.

--- We need this table, before we can ask the community to revise
    their proposals, & invite broader participation.

Don't expose the table until *we* have filled it in.

LM: Form a task force?  It's not a necessarily an agreed top priority.
TG would make us more effective.

1. JAR with help fills out the table of categories X use case X 3 roles.
2. *In parallel* we tell the community we are doing so.  Functional
   chars of different proposals.  They should look for that.
3. When JAR et al done, we will schedule telcon.

Received on Wednesday, 4 April 2012 14:31:16 UTC