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.