Notes from TAG discussion on 2012-06-14 - projected on whiteboard and
noodled upon - THIS IS NOT A COMMITMENT OF ANY KIND

1. JT et al present the current incarnation of the 'parallel
   properties' proposal to the TAG

   http://www.w3.org/wiki/TagIssue57Proposal26  ??

2. Procedural: proposal for what TAG members will do to move 
   the CP process forward.

. Report back to 'the community' on what we did with the input that we
  received from them.
    - 'we' = subset of the TAG
    - input = change proposals
    - impact assessement based on use cases, see matrix
        - various things we talked about, considered
    - we judged certain use cases to be important
    - this led to a short list, discussed
    - the smaller group started to develop one particular proposal
    - we think a validator would be *really* helpful

. Ideally, a short, general document (rec?) relating to use of URIs,
  which supersedes HR14, that properly constrains how (say) HTTP and
  OWL should interoperate.

. A draft (for CG input) carefully presenting a semantics of the RDF
  'parallel properties' proposal.  Note, this is not punning, it's
  consistent with RDF-MT.

. A draft (for CG input) presenting the "how to guide" for the current
  incarnation of the 'parallel properties' proposal.  Primer.

. Write a CG charter, and spin up the CG, to:

  Purpose - to solve the problem somehow, with the output of our 
  analysis (which will also talks about the other possible 
  mitigations such as 209; analysis TBD) as starting point.
  For RDF specifically, not URIs generally.

  What is level of TAG commitment to the CG?
    - provide drafts as above as starting point
    - person power as needed
    - review

  - create a place to discuss this that's not www-tag or LD
  - delve into technical details, e.g. interoperability between 200 and #
  - define some properties as needed to support the proposal
  - assess impact of this proposal on current practice, content, 
     software (e.g. tabulator, smushing) and specs
  - validator - to test the design, assess impact
  - do PR around it

----------

Notes:

HT:
We need to reassure users of the two different patterns regarding 
interoperability with the other pattern.

In an effort to "clear the underbrush", maybe propose to either remove
the 'identification / representation' rhetoric from HTTPbis, or
clearly demote it to heuristic.

Tim:
'denote' (200 URI denotes a generic resource)
'thing' (instead of 'resource')
HR14 was a badly stated question.
In AWWW, replace IR with document, resource with thing.

Note re 209: Browsing the uk.gov site in a browser is 
slow because of all the 303s.  This argues in favor of
209, but there may be other mitigations.

LM:
I would like any solution to be not linked to HTTP.
There should be a way to say that this server has not been built yet,
as part of the URI's meaning.