Emacs buffer from TAG F2F

This emacs buffer was projected at the TAG F2F of 2012-04-02, in the
session on ISSUE-57 / httpRange-14.

TOC:
  2.5 use cases
  2 architectures
  Categorization of approaches
  Visualizing consequences of choice
  Criteria for evaluating alternatives
  Decision?







[Terminology on demand]

Use cases

  Content use cases
    Metadata in a database (e.g. triple store)
    After query (e.g. SPARQL) you want to look at the content.
    What do you do, how do you look at it?
      . Ratings
      . Mashups, text mining
      . Software modules
      . Data.gov.uk - URIs for RDF content, how to load it

  URI-based structured data (Web APIs and crawling)
    Netflix - URIs identifying people, films, etc.
    'description1'

  (3rd use case 'description2' - e.g. Amazon page for book)

Trying to phrase this so it's not RDF specific...
  but ack that how URIs are interpreted in context depends on host
    language spec...
  thus this is advice to those writing specs for host languages - if
   URIs are used, use them in this way.

Two architectures - historical accident
  [On demand only: Justify this distinction]
  Document Web
    Web of documents / content
    Retrieval yields content first, might *also* be a description
    AWWW+httpRange-14
    Retrieval yields representation1
  REST
    Web of (structured data, representation2s about) things
      the content is just representations of those things
    Multiple modes: content, description1, description2, depiction, etc.
    Retrieval yields representation2, description maybe, content maybe
      depending on "application" [Roy]
[3 defs of word 'representation' 1. Tim 2. REST 3. Fiat]

Categorization of change proposals / approaches
  Fixed mode 200 case
    Content-always (Doc web) - HR14a / status quo / strengthened
    [ Always description1, etc. ] - Tore
  Variable mode (REST) 200 case - need algorithm for determining mode.
    Mode not determined "nuclear option" -
    Mode determined from server response
      Mode always explicit [hypothetical Representation-mode: header]
      Mode sometimes implicit - "sniffing" based on headers and/or content
	Content opt-out (Doc web, with description1 etc. exceptions)
	  TimBL - proposal 25 - Document: header
	  If retrieved rep. implies it's not content, then it isn't
	Content opt-in (description1, with content etc. exceptions)
	  Default is not content.
	  Is content if you do something special.
	  Prop: Off the TAG's plate - SHOULD not MUST... hasInstanceUri
	  Prop: "does not imply" (Jeni) ...	
	  ...
    Mode determined at point of use
      Content opt-out ?
      Content opt-in ?
      href="uri" mode="mode"
      [:mode-relation "uri"]
      <uri> :mode-relation "uri".
      Punning  <uri> :modeful-property value.
      <mode:uri>
    Mode determined from request
      Want-other: request header


How choice of category impacts how you would do the two use cases
  Matrix use case (3) vs. category (4?), 4 cases.

Visualize the futures: how each plays out sociotechnically
  Anarchy - different rules for different agents
  3 proposal classes

Criteria for evaluating proposals [or on demand, or not at all]

(Content-type: analogy - many points of comparison)

Decision of what to say.

Larry criteria for the story:
- without 'uri owner'
- without binding to HTTP
- without'information resource'
- RDF as context only
- persistence - [JAR: story where timeout is not implicit?]
    . story should work in archives
- equivalence of URIs not depending on equivalent of resources (?)
- touch on registry story... URNs are the only URIs that are registry-like
    (LM thinks http: is not registry-like)
- any proposal should explain how it enhances communication
    with concrete use cases, not just abstractions

Noah criteria (and implicitly for solution):
- story should touch on webarch principles
- story should touch on 'self-describing' story

HT: Solution where we have reason to think it will change behavior
  - an active alternative should have some vision of how we will get there

TBL: the specific use cases should be specifically addressed.
  position should bear on Facebook, Flickr, Dublin Core, FOAF cases

Ashok: Triage on criteria?

Received on Monday, 2 April 2012 10:20:39 UTC