08:09:34 RRSAgent has joined #tagmem 08:09:34 logging to http://www.w3.org/2012/10/08-tagmem-irc 08:09:39 trackbot, start meeting 08:09:41 RRSAgent, make logs public 08:09:43 Zakim, this will be TAG 08:09:43 ok, trackbot; I see TAG_f2f()3:00AM scheduled to start 69 minutes ago 08:09:43 scribenick Ashok 08:09:44 Meeting: Technical Architecture Group Teleconference 08:09:44 Date: 08 October 2012 08:10:13 Topic Governance Framework 08:10:28 LM: There are 2 dated links 08:10:35 http://www.w3.org/2001/tag/doc/governanceFramework-2012-10-08.html 08:11:04 http://www.w3.org/2001/tag/doc/governanceFramework-2012-07-19.html 08:12:10 The earlier version is based on work I had done with some other folks re. Publishing and Linking was an example of how regulation interacts with architecture 08:12:21 ... what's the igger picture 08:12:37 s/igger/bigger/ 08:13:16 LM: I got feedback that it said too little or too much ... too short to be an intro 08:13:32 ... so I cut them them way down 08:13:53 LM: It's a short document 08:14:11 LM: Intro is similar to the P&L document 08:14:30 ... then there is an Audience section 08:14:38 ... why are we doing this 08:15:00 ... technical understanding can help legislators make better laws 08:15:17 ... detials are now just a bulleted list 08:15:30 s/detials/details/ 08:15:59 LM: 4.2 talks about where policies and technology interacts 08:18:48 NM: 2 questions ... what is the success criteria ... is it almost complete or just a table of contents of items that need to be fleshed out 08:19:07 LM: Final document should not be more than 50% larger 08:19:51 ... goal is to encourage W3C to take up other areas where there is conflict between technology and policy 08:20:36 LM: There is ongoing discussion about ITU and other bodies re. Governance ... connectivity, net neutrality, etc. 08:20:57 LM: But issues are lot broader e.g. cyberbullying 08:21:42 Wrt conflict between regulations, compare the two things linked from the following page: http://www.ed.ac.uk/schools-departments/information-services/about/policies-and-regulations/statutory-notices 08:21:48 q+ to make a suggestion 08:21:59 Ashok: Use of Social Media to mobilize opinion 08:22:36 NM: It would be good if the introduction answerred my questions 08:23:20 NM: Two questions: 1) what are the success criteria for the document? 2) is it 75% complete as it stands, or is this going to include comprehensive discussion in each area? 08:23:31 JeniT: This would be a good subject to have this as a page in the TAG space that we could link future work from 08:23:31 ack 08:23:54 LM: 1) get people thinking about the issues 2) it's maybe 75% of the size I'd expect -- it's an intro to get people thinking 08:23:57 LM: Not sure if this work fits in with what the TAG does 08:23:57 q- 08:24:18 NM: I think the document needs to more explicitly state its goals 08:24:32 ... it's a good way to broaden the discussion started by the P&L document 08:24:32 LM: OK, good point. Make sure it's in the minutes. 08:24:36 NM: Done 08:24:40 not sure it fits entirely within the TAG's remit 08:24:53 q? 08:25:15 HT: Would be good to have Daniel Dardellier come talk to us about govenance 08:25:20 the word "governance" is used with a much broader meaning than is typical in the Internet community 08:25:31 ... his perspective would be useful 08:31:09 ITU holding 1st ever "World Conference on International Telecommunications" (WCIT): http://www.itu.int/en/wcit-12/Pages/newsroom.aspx 08:31:21 December, 2012 08:32:58 LM: We could go thru the doc section by section 08:33:49 NM: I not convinced whether a document that just whets your appetite if a good idea 08:34:01 ... I'm willing to think about this 08:34:18 missing acknowledgement 08:34:58 LM: I responded to comments by contracting section 4 08:35:40 http://www.itu.int/en/wcit-12/Documents/draft-future-itrs-public.pdf 08:36:16 HT: I put a link to the ITU meeting in Dubai ... the above is their base document 08:38:06 LM: I have not addressed comment on use of word "Governance" . We are talking about a much broader set of issues 08:38:37 LM: I happy with the intro ... it has been carefully reviewed 08:38:56 Section 2 spells out the goals of the document 08:39:41 Section 3 talks abput Governance requirements constrain Architecture ... some examples would help here 08:40:13 NM: Section 4 is too brief 08:40:35 q+ 08:41:07 JeniT: Can we add pointers to other sources here? 08:41:51 NM: Need more detail in Section 4 08:43:35 Ashok: I want to see examples of where policy influences architecture and vice versa 08:44:31 LM: Started to think about jurisdictional differences in policy ... how does that influence international businesses 08:45:29 q? 08:45:44 q- 08:45:48 q- ashok 08:46:06 ... e.g. authentication, what material is illegal etc. 08:46:40 ... when we move into a position where your action on a device can have global effects 08:47:04 Wrt ITU again, and their proposed Regulation: http://www.itu.int/en/wcit-12/Documents/draft-future-itrs-public.pdf, see e.g. the first item on Page 29, which explicitly puts Internet traffic within their scope 08:47:43 LM: We need guidelines for legal dept and project managers ... responibilities are distributed 08:48:22 NM: It's a valuable area but what are we contributing 08:48:53 LM: When i showed it to people I got feedback that it was useful and we should keep working on it 08:49:26 LM: Needed to be complete ... misiing for example security 08:49:55 Tim: There has been pushback from folks saying TAG does not do Policy 08:50:18 LM: This is a bridge between the technologists and the policy folks 08:50:28 NM: Maybe a different title 08:51:15 LM: In 4.2 we talk about other documents like the P&L we may want to work on 08:51:35 Tim: What about fairness, growth 08:51:53 ... these are things goevernments worry about 08:52:20 s/goevernments/governments/ 08:52:47 Tim: What are technical properties that enable fairness 08:53:06 LM: Something about no monopolies, open markets 08:53:29 ... antitrust issues 08:54:01 NM: The P&L document is really about explaining technology for policy makers 08:54:47 LM: This is the inroductory framework and P&L is first volume 08:55:28 NM: What are the other pillars that site next to P&L 08:55:44 s/site/sit/ 08:56:59 LM: We could publish as a note and presenting it to the AC 08:57:15 NM: Should we do this with the AB? 08:58:34 Tim: Lot of interesting work on the bullted points ... these need to be mentioned 08:59:33 HT: We should focus on section 3. That's our business 09:00:51 Tim: I see the world as being a set of protocols and each protocol is a mixture of technical and social 09:01:16 http://dx.doi.org/10.1080/13691180903473814 09:01:26 ... linking to stuff involves a social aspect 09:02:00 ... breaks when people link on how to make a bomb. So we need constraints both social and technical. 09:02:57 Tim: Historically geeks and lawyers have danced around each other ... 09:03:20 ... not formed by pieces coming together 09:03:55 NM: The Web and facebook have both technical and social aspects 09:04:27 "Not long after computer scientists first began working on the technical design of the network that ultimately became known as the Internet, in 1969, they began to document their discussions, information shared, and decisions made in a series of documents known as the Internet requests for comments that is still being used for this purpose 40 years later. A comprehensive inductive reading of these documents reveals that legal and policy 09:04:27 NM: We need to fill the gaps between technology and society 09:04:27 issues were often raised or confronted in the course of resolving technical problems. In many of these instances, the technical decisions that resulted had law-like effects in the sense that they constrained or enabled the ways in which users can communicate and can access and use information over the Internet, whether or not such decisions supported or subverted legal decision-making, and whether or not legal decision-makers understood 09:04:27 the societal implications of the technical decisions that were being made. This is one of the two ways in which technical and legal decision-making have become interpenetrated. The literature on legal engagement with problems generated by the technical features of the Internet is vast. This article appears within the nascent literature on technical engagement with legal problems. It does so in an effort to contribute to the building of 09:04:33 a shared epistemic and decision-making space that involves both the technical and the legal communities." 09:05:22 Tim: Re. email the original thinking was that this was a research network and should be used only for research 09:05:57 ... when the use policy was relaxed it turned out that some issues such as spam were not addressed. 09:07:11 LM: People seem to be uncertain as to where to go with this 09:07:41 AM: Can we mention the relevant technical issues under each bullet in section 4 09:08:11 NM: We need success criteria to decided whether to go forward with this document 09:08:24 s/decided/decide/ 09:09:21 what would have to happen to this document before you would be happy to see the TAG work on it? 09:10:49 Tim: Your list here is sort of like the IETF saying you need a Security Considerations section in each RFC 09:11:25 ... with P&L we had clear example of misunderstandings re. Linking and Embedding 09:12:18 NM: Do you have what you need to move ahead? 09:12:40 LM: I need a poll on whether we should go forward with this document 09:13:16 HT: I'm very concerned about redoing work that has been done elsewhere is greater length 09:13:53 ... s/is/in/ 09:14:32 ... section 3 in scope and should be grounded by discussion with Danny Wietzner 09:15:21 PL: It's an interesting document ... agree with Henry ... maybe the W3C should concerned with this rather than the TAG 09:15:38 YL: The TAG should stick to technical matters 09:16:28 ... works on how architecture of Web impacts policy and how policy impacts Web Architecture 09:17:00 JeniT: Section 3 really useful ... good summary of areas of concern 09:17:34 ... eplain technical concepts to policy makers 09:17:44 s/eplian/explain/ 09:17:55 ... need links to existing work 09:19:06 Tim: Prefer a view where the system is designed holistically. Privacy is a property of some systems ... provides invariants on which othet 09:19:15 s/othet/other/ 09:19:22 sytems depend 09:20:14 ... Similarly, copyright, accessibily are properties of this system 09:20:48 ... As a list of things to watch out for is reasonable 09:21:14 darobin has joined #tagmem 09:21:22 ... I would not like future architecture to be done piecemeal 09:21:34 ... useful as a checklist 09:22:29 ... I'm worrying about doing architecture from this matrix ... for example accessibility be added on because some govt. wants it 09:22:57 Tim: What the document is trying to say is not very well defined. 09:23:11 s/elsewhere is/elsewhere at/ 09:23:23 Askok: What I would do is take the bullets and talk about tech areas which influence them. 09:23:28 AM: I hav mentioned: I would take the bullets, and speak of technical areas that impact security, copyright, etc. 09:23:35 …. and then find where others have talked bout these things. 09:23:44 AM: Difficult part is to find what othrs hav already done 09:23:48 … As a very practical thing to go forward with this. 09:23:55 s/grounded by/grounded in existing policy studies, start with/ 09:24:25 NM: I've expressed some concerns about the goals. Not sure, we need a document that does not stand on it's own 09:24:43 ... this is like an intro to other work we need to do 09:25:33 ... I'm reserving judgement ... perhaps you could add some technical depth 09:26:13 LM: I have got some useful feedback ... need to think about how to go further ... perhaps a blog post 09:26:51 NM: Not saying "we don't want to see this ever again" 09:27:05 LM: I will work further on the document 09:27:36 Break for 20 minutes 09:43:11 s/othrs/others/ 09:44:29 Topic: Documenting meaning of individual IRIs (ISSUE-57) 09:45:37 HT: Background http://www.w3.org/wiki/TagIssue57Proposal27/Background 09:50:45 HT: This is a starting point for the perspective Jeni, Jonathan and I have taken 09:50:58 ... it is a 20,000 foot level set 09:51:12 ... if you think its wrong we need to worry 09:51:51 HT: Distributed extensibility begets incompatible extensions 09:52:06 ... this is by design 09:53:20 ... XML does not control the tags used. You can design the meaning of the tags you use 09:54:08 ... XML has a mitigation i.e namespaces 09:54:20 LM: I need more context 09:54:51 HT: This is in aid to improving the situation re. HTTP Range-14 resolution 09:55:16 HT: We are building towards a proposal 09:55:57 ... we have 3 documents, this document, the primer and a detailed proposal 09:56:18 HT: Rec track for primer and technical document 09:58:10 "underspecification" is a value judgment, not specified as much as expected 09:59:22 HT: Sometimes, like in the case of RDF, extensions are incompatible ... usually this is not a problem 10:00:03 ... problems arise when incompatible extensions are expected to interoperate 10:00:42 disagree with 'require' in "Interoperability requires keeping track of which extension is intended." -- keeping track is one way, there are other ways 10:01:18 jar has joined #tagmem 10:01:29 HT: Obvious way is to keep track of which use is expected 10:01:52 yes, it is "one obvious way" 10:02:33 HT: Otherwise you will get incorrect conclusions 10:04:08 HT: Many ways to keep track of which extension is intended 10:06:41 HT: Proposal is to make distinctions via the immediate context 10:07:39 ... we cannot get agreement on what the URIs mean ... but we can get agreement on what the sentences mean 10:07:59 the core goal of "my statements mean what i think they mean" can't be accomplished with a universal understanding, "Everyone who can hear my sentence will think the sentence means the same thing" 10:08:40 there is no such thing as universal understanding. 10:08:42 HT: We will put the burden of identification on the meaning of properties 10:09:01 LM: Who has to agree on the meaning 10:09:06 there is no way to control what someone else understands in any situation 10:10:02 saying that agreeing on meaning of sentences instead of words is not an improvement, is a straw man 10:11:24 what another agent thinks something means is unmeasurable, undetectable, a private matter, not in the scope of any spec 10:11:34 JeniT: The crucial thing is where the URI is used ... is it referreing to the content or description of the content 10:11:45 specs only govern tests of conformance. whether an agent conforms to a given spec. 10:12:08 ... we are concerned whether an app using the URI does the right thing 10:13:08 so, masinter, "my statements mean what i think they mean" cannot be a goal 10:14:32 at least not in a spec 10:15:59 sorry for the irc-only comments, i wanted to get them written down, don't let them interrupt conversation. i couldn't get in on voice. 10:16:33 will try to restrain myself 10:18:49 JeniT: The aim of this paper is why there is confusion, mostly they don't need to care about it and when they do what they should do about it 10:20:02 ... not specific to RDF 10:20:02 ... addresses people who are writing data and what they should care about 10:20:04 timbl_ has joined #tagmem 10:20:14 ht_home has joined #tagmem 10:20:28 JeniT_ has joined #tagmem 10:20:32 masinter` has joined #tagmem 10:20:54 Jeni goes thru the document: http://www.w3.org/2001/tag/doc/uri-usage-primer-2012-10-03/ 10:21:39 The primer is at http://www.w3.org/2001/tag/doc/uri-usage-primer-2012-10-03/ 10:26:02 Tim: David Booth said that all we need to worry about is RDF ... in that RDf is creating the problem 10:27:46 that's not correct 10:27:55 the json case is interesting. 10:28:15 HT: If you write XML or JSON you always say what the URIs means 10:28:24 if we can give advice on that one, then the rdf case will follow… rdf is harder though, so start with json 10:28:25 s/means/mean/ 10:29:17 JeniT: Section 3 introduces Landing Pages which are pages about something else 10:31:06 ... they don't have to HTML. Maybe JSON or XML or RDF that describes what is it that they are talking about 10:31:58 ... sometimes the properties get mixed up ... they could apply to the page or the content 10:32:46 JeniT: If the data is about a person then it's clear what the properties refer to 10:34:24 timbl: e.g. phone number and assistant's phone number 10:35:41 Section 4 describes Data Normalization 10:36:52 Section 5 says not always possible to normalize 10:37:28 HT: People don't always normalize 10:38:21 q+ jar to In JSON, this has to do with the relation between the property value and the @id value? Or is @id just another property. 10:38:26 q? 10:38:58 http://www.iana.org/assignments/link-relations/link-relations.xml 10:39:58 based on http://tools.ietf.org/html/rfc5988 10:43:47 TBL commenting on the 'implied properties' diagram 10:44:16 Ashok has joined #tagmem 10:46:05 JeniT: 5.2 talks about when a Landing Page describes more than one thing 10:47:58 JeniT: 5.3 talks about why these distinctions are particularly important 10:49:12 ... 5.4 is about how you find the documentation 10:50:18 JeniT: 6 is about recommendations about data producers and data consumers 10:50:51 ... say what appliactions can do with URIs ... when they dereference what they can expect 10:52:12 something about appending to get URIs in various doc formats, XML, turtle, etc. 10:52:39 Discussion of namespace URIs 10:53:04 NM: namaspec names can have a fragment in the name 10:53:25 HT: Using a string which is a relative URI is deprecated 10:54:42 JeniT: 6.1.1 talks a metaformats such a RDF and says they should document how the the URIs are used 10:54:55 s/used/interpreted/ 10:55:31 don't talk about identification please. identification is not testable 10:56:22 reference is not testable. please don't use the word 10:56:37 'identification' and 'reference' have no place in normative language 10:56:43 similarly 'meaning' 10:57:11 as soon as these words are uttered, people start arguing. 10:57:15 NM: Henry said URI refers only to one thing but sometimes it refers to other things 10:57:19 just stop please. 10:57:33 ... we shall discuss in detail in the main proposal document 10:57:56 please let's not get into REST 10:58:04 please let's just talk about JSON 10:58:22 HT: Please wait till we get to Proposal 27 10:58:35 please let's get consensus on JSON first. then we can figure out what to do about REST, identification, reference, REST, meaning, etc etc. 10:59:08 NM: Need to be rigorous about terminology 10:59:14 there is NO WAY TO BE RIGOROUS ABOUT IDENTIFICATION 10:59:24 Just don't talk about! 11:00:20 I am not going to speak up. I am on the queue. I want Jeni to finish 11:00:29 JAR is channeling Wittenstein 11:00:38 Nothing, jar, is testable 11:00:53 timbl, I disagree with that. 11:01:29 No, I'm saying we can tell stories at different levels, and not use terminology that's unnecessarily ambiguous. I think I'd like to see a bit of terminology used consistently for just the REST bit of this: time varying sequence of representations, etc. We can on top of that have a set of terminology for the proposal 27 story (when used in the property (indirectly) identifies) 11:01:35 JeniT: 6.2 talks what conclusions you can draw if you are a consumer of the data 11:01:39 timbl, that is the same as saying there is no truth. 11:01:51 everything is testable, it's just that most tests give inconclusive results 11:02:24 JeniT: 6.3 talks about Publishing data 11:02:29 btw: the JSON case IS a rest case. The JSON itself, and the typical URIs it references, are typically retrieved with GET 11:02:36 ... section 6 needs more work 11:02:45 Noah, REST is not an agreed vocabulary, we don't want to depend on assuming it is 11:03:02 zakim, q? 11:03:02 I see jar on the speaker queue 11:03:26 lm: asking about link relations 11:03:35 LM: What about Link Relations, what about XMP? 11:04:08 XMP (or the doc formats that use it) is underspecified because it doesn't answer this question. 11:04:49 yes 11:04:58 LM: Link Relations would be another usecase to discuss 11:05:01 ack jar 11:05:01 jar, you wanted to In JSON, this has to do with the relation between the property value and the @id value? Or is @id just another property. 11:05:47 jar: The approach in this document is good ... it avoid trigger words that would cause us to rathole 11:06:23 ... can we get consensus on the advice and then test against various usecases ... start with JSON 11:06:40 ... RDF is complicated because it has entailment 11:06:48 ... RDF would be the final test 11:07:04 XMP uses rdf:about="" 11:07:24 So, talk about XMP first, put off RDF in general. 11:07:27 HT: We should not import terminology from REST. REST is not well specified and it woukld cause confusion 11:07:29 Let's go bottom up. 11:08:05 what you're saying doesn't even have agreed meaning 11:08:08 just testing the document about other things I think about, it looks ok 11:08:10 NM: To me this implies that what a URI implies is where it is used 11:08:15 you're not even making a point 11:08:43 stop being deep 11:09:05 we're ONLY talking about how to write specs please 11:09:18 NM: REST gives same answer where the URI is used. I'm reluctant to lose that 11:09:34 JAR: Don't go there 11:09:56 NM: I think this is an important point 11:10:22 JAR: Identification does not occur in the document 11:10:46 /me jar, you're breaking up a little 11:10:54 If the document talks about 'identification' or a function from URIs to things that would be an error in the document 11:11:38 Tim: We are taling about something over which there has been a great deal of debate and people have been burnt 11:11:49 s/taling/talking/ 11:12:16 context is always important 11:12:24 as Larry keeps saying. I agree totally 11:12:39 Tim: They are saying it depends only on the property 11:12:59 that's impossible, Noah 11:13:08 and irrelevant 11:13:19 NM: I want a function from a URI to something that is completly context independent 11:13:29 ... losing that is very deep 11:14:05 HT: We tried to do that and we failed ... others have tried and failed 11:14:33 JAR: People hav been trying to do that for 120 years and failed 11:14:40 s/hav/have/ 11:14:56 HT: We set out to solve a smaller problem 11:15:19 webarch is wrong. 11:15:34 and not the subject of this exercise 11:16:08 HT: There are different constituencies that recognize the words differently 11:16:17 q? 11:16:46 NM: I would like to see if we can reconcile with WebArch 11:17:04 "URIs identify" is patently false. Could be true (enough) in some cases. Empirically fase for http: URIs 11:17:14 s/fase/false/ 11:17:16 timbl: I want to use an analogy between classical and quantum mechanics 11:17:37 Tim: It's like classical mechanics and Quantum Mechanics 11:17:50 My procedural advice, to put off the hard questions until the easier ones are answered, is being totally ignored 11:18:47 TimBL channeling Pat Hayes ! 11:18:57 we shoulda ll channel Pay Hayes 11:19:16 s/a ll/ all/ 11:20:46 Tim: Pl. wait until they get to the end of the document 11:20:57 11:21:14 Break for lunch 11:21:20 Lunch break till 1:20 11:23:08 Larry` has joined #tagmem 11:23:09 ht has joined #tagmem 11:57:43 s/Pay H/Pat H/ 12:05:13 masinter has joined #tagmem 12:17:39 Stuart has joined #tagmem 12:18:22 how was lunch? 12:19:39 scribenick: Larry 12:19:57 Topic: Documenting meaning of individual IRIs (ISSUE-57) 12:21:13 ok. will dial 12:21:34 agenda? 12:21:46 Ashok has joined #tagmem 12:22:35 ht: this is an attempt to work out detailed RDF semantics for parallel properties 12:22:48 ht: the proposal is algebraic and succinct 12:23:35 discussing http://www.w3.org/wiki/index.php?title=TagIssue57Proposal27&oldid=61086 12:24:31 ... this is the hardest part of the problem ... 12:25:08 ... begining with a simple case initially 12:25:22 is everyone on board with this presentation or are some people going to tune out? 12:25:32 ... going to focus on disambiguation between landing page and the work 12:25:52 little point in going through this if someone is going to disagree with premises at the end 12:25:55 ... This is the crucial problem. 12:26:29 From the proposal: 12:26:31 "Claim: We'll never agree on what the disputed URIs (the GET/200 ones) identify. " 12:27:09 context is still important for sentences, larry. ack that 12:27:29 ht: we're just going to focus on what the sentences (triples) mean, without having to agree on the story 12:27:44 right 12:27:49 Just to record here what I said this morning: I want eventually >NOT< now, to make sure that we don't go too far in throwing out the fundamentally good advice in Web arch about use of URIs to (excuse the loaded term, but it's what Web Arch uses), "Identify" things. 12:27:57 s/ack that/I ack that/ 12:28:36 ... the way we're going to do this is ... (missing, something about personal context, 3 communities) 12:29:01 I don't think that means throwing out or even much changing proposal 27. I do think it means recommitting to a lot of the spirit of the good advice in Web arch, and about URIs (as, ahem, identifiers) remaining one of the three pillars of Web architecture 12:30:28 ht: now looking at the example, Scenario 12:30:47 larry, thanks for scribing. my task (later) is to convince you that i'm in complete agreement with you on everything you've said so far 12:33:00 HT: ((explains Interpretation 1, Interpretation 2, "Neutral" Interpretation)) 12:34:39 ht: OMF might be an 'information resource' or maybe not, doesn't matter 12:34:52 the "landing page" could be *either* the rep or the resource.. doesn't matter. move along. 12:35:02 red herring 12:35:32 ... but LP can be thought of, in REST turns, a resource 12:35:49 ... two functions, 'ptopic' and 'lp' 12:36:29 should say lp maps from thing described (possibly a person) to landing page 12:36:57 noah: if the LP was about a person, then OMF would be a person, and ptopic is a function from document to a person 12:37:23 ((agreement)) 12:37:50 P maps what's identified to its author. 12:38:37 noah: "URI interpreted as" confuses me 12:38:58 what 'P' identifies maps something (e.g. something that's identified by another URI) to its author 12:39:08 ht: P is a URI that appears in ... interpreted in RDF semantics 12:40:10 noah/timbl: "interpreted" is a term of art? discussion 12:40:43 ashok: Are 'has creator' and 'created by' special, or could i use other words? 12:41:12 ht: any property that is ambiguous would work as part of the setup 12:42:13 ((discussion of why moving from Moby Dick to Dickens)) 12:42:55 ht: given all of this, can we define properties where members of all three camps can say "landing page by Tomlinson, book by Dickens" 12:43:42 ht: ((reviewing chart)) 12:44:13 ht: U vs. Interpretation 1, 2, 3; P is creator property 12:46:05 ht: Now we get to the magic 12:47:06 ... "we need a Q, such that U Q T means LP is by Tomlinson, and an R, such that U R D means OMF is by Dickens 12:47:50 solving backwards, Q and R are different functions for Interpretation 1, 2, and 3 12:48:06 yes 12:49:25 noah: ((question about domain of Q and R)) 12:49:28 noah is correct, the *might* have disagreements over truth of sentences involving domains and ranges (if they don't pull this trick again when they talk about domains and ranges) 12:50:30 tbl: Q and R are different URIs; the future of data on the web relies on those two not getting overlap 12:51:01 I would say, the future of RDF interoperability, in the absence of agreement on "identification" (which has not been forthcoming 12:51:02 ht: we have a URI, we do a GET, we get a page whose author ... 12:51:04 ) 12:51:38 not "the future of data on the web" since we have seen that the JSON case doesn't rely on "identification" 12:52:35 if the web *depended* on "identification" the *present* would be in awful shape 12:52:45 ht: ((reviewing diagrams)) 12:53:42 noah: are you looking for people to understand today, or to just agree if this is the right direction 12:54:45 ht: we need the TAG to define two predicates which relate properties that apply respectively to landing pages and things denoted by landing pages, then I document Q bearing the M relation to P ? 12:55:55 noah: ... something something ... which is it? 12:56:32 jar: depends on what you mean by 'evaluate' 12:58:57 ht: Jar, do we have a name for URIs whose XX varies by community 12:59:04 jar: no. 12:59:16 jar: not really needed in RDF semantics 12:59:44 ht: this then leads to a processing model 12:59:53 noah: P is "dc:creator" 13:00:29 jar: "you might use them with hash URIs, but we decided to defer that" 13:01:14 ht: in this paper "disputed URI" is .. XXX 13:01:34 tbl: ... Q and R don't have to be hashless 13:01:45 you can think of M and N as cancellation operators. they cancel out the disagreements 13:01:46 ... when you define Q 13:02:06 ht: anyone who wants to publish interoperable properties will define them this way 13:02:33 ht: M and N are fixed URIs, they serve the documentation requirement 13:02:46 ht: it's M and N that XXX by definition 13:03:13 jar: they can't allow ... XXX ... something something .. 13:03:30 tbl: do you mean inverse? 13:03:54 noah: they take care of the fact that some communities do indirection one place and not the other 13:04:32 tbl: you're saying P is undisputed? 13:04:42 we're positing that. 13:05:14 ht: dc:creator means the author of an authorable thing is ... 13:05:32 tbl: they didn't say whether it should be like U or like Q 13:05:52 ht: if you don't do this, you have to assume they were caught in an infinite regress 13:06:15 Jeni: it would be better if you didn't use dc:creator 13:06:46 ht: p never indirects, it's always direct 13:07:05 ht: creator is always direct 13:07:22 noah: dc:creator are ok in this example 13:08:20 ht: it's crucial when we get to the tabulator, which is what any application needs to do, when you find any property declared by M to map to some direct property, you should assume there's a real landing page out there, and the... 13:08:32 ht: in the wild what you're going to find Q 13:08:45 noah: users have ot say Q 13:08:49 dc:creator might be used with hash URIs. no problem with that 13:08:58 ht: users only have to say Q if ... XXX ... 13:09:05 ht: and that's why we're not done yet 13:09:29 ht: we would like it to be the case people can use Q and R with URIs that return 303 ... 13:09:36 noah: they can't use dc:creator 13:09:49 tbl: in the schema.org world 13:10:10 jar: noah asks the interesting question if ... XXX ... 13:10:25 noah: that's what i guess and i was mixing it with branding. 13:10:50 noah: dc:creator is what people ... XXX ... that may be an impediment to adoption 13:11:09 jar: we tried to get consensus on that [???] and failed 13:11:14 noah: think about it 13:11:20 jar: we have for 10 years 13:11:36 noah: in the future people will invent Q's and R's 13:11:59 tbl: dc:creator was used since ((long time)) 13:12:10 it's only a problem when you use dc:creator with a subject written as a disputed URI. all other cases (#) are fine 13:12:27 tbl: Facebook created OGP ontology, and started to stick something in their metadata 13:12:36 and schema.org did something 13:12:38 it's been used *without transparency* - without any spec for what it means 13:13:07 tbl: ... we can keep going. if people get into namespaces, then instead of kicking 13:14:00 tbl: dc:creator applies to the page. if you want to introduce something about the subject of the thing the page is about, then that would remove the syntax 13:14:21 timbl is considering other parts of the context where the distinction could be drawn? 13:14:25 noah: their story gets better over time, in principle lllll 13:15:02 ht: if you're starting in a green field and you want to use disputed URIs, then ... all applies to the direct properties. 13:15:13 The URIs that you write in triples 13:15:45 ht: If i'm building an ontology in a greenfield, there are two classes about authoring ... i write a paragraph about what i care about 13:16:05 ht: I'm going to take about 30 yeaers ... 13:16:35 ht: i'm going to define a vocabulary that will use ... so I know .. i'll use compose... all those URIs will be in my namespace 13:16:56 ht: I want to encode so everyone can use them, so these all have to be parallel properties 13:17:18 ht: whenever i want to say about the properties ... 13:17:28 noah: is M one level or to the bottom 13:17:51 FWIW: I think we are talking about the identification of 'things' and 'descriptions of things'. The proposal on the table seems to be about creating two variants of a property, say 'creator' which we call 'topic(creator)' for speaking of a 'thing' and 'meta(creator)' for speaking about a 'description of a thing'. 13:17:54 noah: if i have a landing page that talks about another page ... 13:18:27 jar: ... the very last on the page 13:19:00 ht: my question is: can we use Q and R across the board, look at interoperability 13:19:35 ht: everyone will agree about how to write it and ... 13:19:46 ht: as it stands, we're still left ... hash URIs 13:20:02 ht: you should use the good old-fashioned direct properties. 13:20:38 ht: the rest of the document is about ... can we get tick boxes ... so that the right thing happens if you use write and use one of these so-called parallel properties 13:20:45 I guess (again FWIW) I would prefer a world in which we can speak clearly about a subject ('thing' or 'description of thing') with 'simple' propeties - but that flies in the face of the premise of the discussion (that is disputed). 13:20:52 The question at the end of the proposal27 page, is whether hash URIs interoperate with M- and N-properties. 13:21:03 ashok: if i have a hashless URI in my hand, how do I know if it is retrieval enabled 13:21:19 noah: and is that time-invarient 13:21:46 jar: the way i use the word, hashless URIs aren't .... 13:22:00 noah: are all hashless URIs retrieval enabled 13:22:22 ht: you can't tell if you'll get a 200 or a 303 13:23:04 jar: part of the continuation of this exercise.... i think larry's point that 303 and 200 shouldn't be treated separately ... legacy has .... 13:23:15 noah: so our solution is more advice? 13:23:41 ht: the story i told ... what does it mean if someone ... 13:24:05 ht: by a 303 URI, and the answer is, as far as we've gotten, it doesn't give the right answer 13:24:24 ashok: would it help if you said all hashless URIs are dsputed 13:25:13 ht: i don't think it would be useful to try to put something ... 13:25:32 ht: I think we need to switch... 13:25:39 q? 13:26:10 Meaning of sound in unknown to me 13:26:25 s/sound/the sound/ 13:27:35 jar: reiterating, for the TAG, Jeni's document is important 13:28:02 jar: how does it apply more generally ... the central TAG documents, Jeni's ... 13:28:49 ht: doesn't answer the procedural answers. We asked for proposals, and set a practice. Jeni's document doesn't meet the requirements for a proposal, does it? 13:29:12 jar: basically, it asserts agreeing what disputed URIs identified.... 13:29:31 ... you just don't, and assume, RDF and Interoperability. 13:30:13 jar: all the proposals we received ... none of these things, there's a different way out, the key issue is technical interoperability, has priority over identificaiton. 13:31:04 ht: i'm not sure jeni's document as it stands encompases all that you said, some of it is in the background, some of that is .... 13:31:36 jar: there's more work to be done, how do you apply the something and data idea where you're forced something that you're something ... 13:31:56 ht: i had scrolled down as far as processing model of.... 13:32:17 ht: Why does this work for Tim, who's a member of community 1... 13:32:42 might want to look at http://www.w3.org/2001/tag/2012/09/issue57/U at some point... 13:33:09 ht: how does it work if a member of communmity 2 passes something to someon e in community 1 ... it works because there are ... an implicit Q M ? P in the first box of the processing model 13:33:25 Tim thinks Q = P 13:33:48 tbl: Ian is identity, N is identity? 13:33:58 ht: Q and R are never identity 13:34:09 tbl: for me, n is identity 13:34:17 N P Q 13:34:23 For timbl, M is identity. For Ian, N is identity. 13:34:27 ht: how can we get the same result 13:34:47 jar: at this point you'll hve different stories 13:35:13 _:1 will be the same for Tim and Ian 13:35:28 but for different reasons for the two 13:35:48 tbl: the problem is with the tabulator, it will pull in a landing page, and conclude that there is something 13:36:01 ht: it better have access this to that 13:36:23 ?p can be dc:creator 13:36:32 tbl: for some unnamed thing _1 for some unnamed thing P 13:36:57 ?p will usually be named, doesn't matter. In the example it is 13:37:51 2 hr) ht: we haven't talked about F*. F* is the name of the thing you're composed with, it's either ID or landing page or tdb (subject owned). In your case, this is, F* is uh ... Q is ... 13:38:27 To Tim, F* is the identity 13:38:30 Time check 10 mins 13:38:50 tbl: i know there is something .... 13:39:01 we use 'Tim' and 'Ian' as standins for perceived communities 13:39:07 ht: ian has to have written this, with a value for P 13:39:11 These deduction rules work for everyone 13:39:35 tbl: the problem is Ian will create R and document R 13:40:11 jar: this only works for interoperable content 13:40:48 ht: it's the property P that is the author, somewhat oddly 13:41:02 when I write You R Dickens, what I care is that something is 13:41:48 ... in the relationship P for... 13:41:55 Jeni: they all 303 13:42:07 (We should ack that Ian is a stand-in for a point of view. We are not referring to him personally) 13:43:04 jar: if time is limited we need to talk. it just seems to me that Tim or whoever hasn't worked out the technical details 13:43:38 jar: I guess what i want is an admission ... the background sheets.... 13:44:08 ... we've something that, this has led to interoperability problems ... 13:44:19 ... in the absence identification ... 13:44:31 ... our claim that URI's identify ... 13:44:45 Noah: real problem getting enough community consensus 13:45:14 noah: sense of the room, who feels that this is.... i need to look hard ... 13:45:21 abstain 13:45:27 noah: first choice ... 6 ... 13:45:41 ashok: I want to think about it a bit 13:45:53 noah: it would be nice to come out of here with a direction 13:46:38 I want TAG agreement that the direct path to interoperability, that of agreeing on what these things identify, has failed. That failure is the entire motivation for this approach. 13:46:40 noah: first is let's assume for the moment that this is ... change propopsals and synthesize 13:47:24 stuart: will this require me to change anything 13:47:33 . RESOLUTION: The direct path to interoperability, that of agreeing on what hashless http: URIs things identify, has failed. Therefore the approach of Jeni's "URIs in Data" and proposal 27 should be pursued. 13:48:01 Jeni: 303 is OK 13:48:15 noah: if you were to come across shorthand properties ... not proven 13:48:17 There is an interesting subclass of InformationResource which is a domain of principalTopic : Document which has a single principle topic. 13:48:27 HST's take on what JAR said was his proposed resolution of the RFP exercise is: "The effect of our call for change proposals is to underscore that no consensus exists or can be reached on a story about a global unambiguous interpretation of hashless URIs. Rather than continue to pursue such consensus, we will instead seek a technical solution to the resulting interoperability problems." 13:48:35 I think 303 is fine for RDF, but agree with reservations on whether it works for the architecture overall. 13:48:37 stuart: this will be hard .... 13:48:54 tbl: worry we're build more crud on top of crud 13:49:10 s/effect of our call/outcome of our review of the responses to our call/ 13:49:14 No, we're removing crud from existing crud. 13:49:24 timbl: it's better than that because ... 13:49:49 timbl: a movement to outflank the whole issue ... talking about the subject of the thing to the thing itself 13:50:41 HT's wording is consistent with, and better than, mine. 13:50:50 ht: because the net net is to say ... i tried to capture Jonathan ... the coutcome to our review .. was to underscore what URIs globally and ambiguously identify, and we're going to stop trying 13:51:16 ht: instead we'll provide some technical advice for some interoperabilitie problems 13:51:25 Amend: hashless http: URIs 13:51:26 q? 13:51:30 q+ 13:51:36 q+ 13:52:00 ashok: when I'm starting, I have a URI, we have to ... 13:52:00 timbl: It is good to prepare also a way of making this unnecessary by allowing in HTML and maybe even hurt;le a very clear syntax for giving information about the principal topic of the document in the document, like a … element within the element, within which all metadata (links, etc) is taken to be about the subject of the page, not the page itself. 13:52:18 ht: all you have to do is faithfully realize in your processors your communities 13:52:28 Did you mean hurt;/e ==> turtle? 13:52:42 ht: the crucial thing is that you don't need to know where things come from, just trust that M and N 13:52:55 M and N are going to become concrete, you know what the data .... 13:52:56 s/hurt;le/turtle/ 13:53:06 all you need to do is trust htings with M's and N's 13:53:20 ...and the bad news is that the scribing script will probably trip over that ; 13:54:02 ht: when i find hashsless URIs... Ora ... talk about a lot... we have a certain amount of provinence information, it will be easy for you to say that i've learned that triples from this source 13:54:19 We found people wouldn't mind their Ps and Qs and just hope they like M&Ns. 13:54:26 ack next 13:55:15 LM: A substantial part of the community is trying to push us toward operational defitions of URI/URL, etc. 13:56:02 s/from this source/from this source uses a) retrieval-enabled hashless URIs, i.e. 'disputed' URIs and b) does not document them using M and N, so I'm not going to trust or use triple from it/ 13:56:04 LM: These things are recipes, grounded in , somewhat modified in . You don't need RFC 3986. You just agree a set of processing steps. 13:56:20 LM: It's a big chunk of the community, and they look to the TAG for leadership. 13:57:21 LM: I see that this is an important problem for a community, but am dismayed that it continues to take so much time. We had an agenda entry. I was hoping to get a plan for driving a "stake" into the heart of this. And now I think I see another plan for 6 months of work. 13:57:33 LM: I like the first part of the proposed resolution. 13:58:16 LM: I'll agree that the efforts to agree on interop of hashless URIs have failed. OK. Then the suggestion to pursue Jeni's solution. Not here. We have higher priorities. 13:59:14 LM: I'm not sure we need to go to this level. Besides, the diagrams in the charts are confusing, and perhaps imply that things are identified which in fact are not. 13:59:56 TBL: We have some code that works, but some that screws up. 14:00:15 LM: I have code that talks about authors, etc. It works fine without all this. Flickr is not looking for us to do this. 14:00:31 the code *doesn't* work fine. they *are* looking to us. maybe it's not our job and we should refer them elsewhere. 14:00:47 HT: Sorry, they don't interop. That may be OK with them, but they don't interop. 14:00:52 ack next 14:01:32 q+ 14:01:42 We need to say AWWW may be right as a matter of principle, and false as a matter of fact. 14:01:45 NM: I am sympathetic to a lot of what LM says 14:01:58 i think the architecture of URLs is important, but the mass of the community that needs work on URLs don't need THIS work 14:02:30 NM: I find these sessions difficult to chair -- this is, in my view, very important, and the TAG is the right place to work on it, but we are not making the kind of progress we need given its importance 14:02:34 we need work on comparison of URLs effecitvely, we need work on registerProtocolHandler and the security properties, we need work possibly on data in URLs 14:02:50 I am completely sympathetic with LM. I think the conclusion is correct, even if its justification is wrong on some of the facts. 14:02:50 NM: Why is it any more likely now than a year ago that we are converging 14:04:16 DKA has joined #tagmem 14:04:16 NM: I'm only happy with pushing this forward if we also agree to go back to AWWW and review everything we say about identity, and either revise it or re-iterate that it stands despite our new take 14:04:50 TBL: I don't think that much of that will change 14:04:51 But *I* can use a URI to identify a single thing, but have no way to coordinate with someone else whether what I use it to identify, is what someone *else* is going to use it for. 14:05:05 AWWW advice is not operational. Doesn't tell anyone how to coordinate. 14:05:24 s/our new take/our new take. There was real value in that advice, and we shouldn't throw it away/ 14:05:45 There's a serious mistake in AWWW. That should be fixed. 14:05:54 Aside: the great global graph will always evaluate 'false'. The web is inherently an inconsistent place. Robust clients will always need to take a 'sceptical' disposition - provenance is important. Provenance on the basis of request (or responding URI - content-location:) is part of the story.... but in the long run we will need more in order to live in an inherently incosistent world. 14:05:59 NM: I'd mostly like to show that most of what's in AWWW on identity is still good advice, if perhaps not completely rigorous in the edge cases. The general advice, e.g. not to identify two things with one URI, is great advice even if we don't in all case rigorously define when you have two things. 14:06:33 TBL: I'd like to see something discussing 303 wrt this proposal 14:06:55 ... Not everyone has to read it, but it needs to be done 14:07:00 q+ 14:07:48 TBL: I agree with LM that other things are important, but a community came to us and complained loudly about this issue, and we owe it to them to respond 14:08:00 A large part of the world approaches URLs entirely operationally, and the use of URLs in data as a problem of some other community than the "Web". We've accepted the deprecation of XML as not on the critical path of the Web, not on the critical path of HTML, not relevant to the majority of W3C's audience. Let's accept that for URI semantics. 14:08:43 NM: Stipulate that's all true, TBL, if we're not ever going to converge we have to agree to stop at some point 14:09:40 LM: We convened a task force on XML-HTML unification, and we concluded to allow HTML to go ahead w/o XML 14:10:07 ... This isn't the end of XML, but it's implicitly no longer on the main strategic Web path going forward 14:10:08 ack next 14:10:35 LM: Why can't we do that for URLs? 14:11:05 why don't we accept that resolving this problem isn't central to web architecture 14:11:37 JT: To wrap this, we need to go to the community, discuss background, tell the story about limits on agreeing on what URIs identify. 14:11:55 JT: I think we should pursue the primer document and take it to conclusion 14:12:13 JT: The stuff around what RDF itself does is the responsibility of the RDF working group. 14:12:45 JT: The primer is therefore something we can give to the RDF wg...at least to indicate what needs to be sorted out 14:13:11 HT: Noah completely mis-scribed that 14:13:29 jt: the work JAR has done should be given to the RDF community 14:13:40 jt: that would be my "getting out of it" strategy 14:13:52 JT: The primer makes clear that specs in general, therefore RDF in particular, must take responsibility for requiring URI documentation 14:14:02 noah: is this something we could be done with the primer in 6 months 14:14:23 JT: And then the more detailed work on proposal 27 goes to the RDF community as our contribution to elping them do that job 14:14:34 s/elping/helping/ 14:14:53 Jeni: I think the RDF community will need some guidance 14:16:14 jar: the important thing is coordination of URIs in documents ... if you're documenting something, you have to say what you mean 14:17:17 jar: It sounds like we're getting closer to being on the same page 14:17:44 jar: if you want to get communication, you need agreement on ? 14:17:46 jar: the main architectural issue is that you have to agree on meaning, not specifying... you need transparency 14:17:47 q+ 14:17:54 q- 14:17:59 ack next 14:18:00 ack next 14:18:25 LM: There's more ambiguity than use/mention. It's do you mean it now vs. forever. Do you mean just the HTML or the transcluded content. etc. 14:19:05 registries and specs are how you get transparency. that hasn't been achieved in rdf. we need to admit that. 14:19:05 q? 14:20:07 jeni: proposal is to go back to the community with the argument made in the background sectionk, to pursue over the next 6 months the publication of the primer as a recommendation, and to shelf the decision about how this applies to RDF to the RDF community 14:20:16 . go back to comty with the argument in background page. to pursue pub of primer (URIs in data as rec). to hand rdf off to rdf wg. 14:20:25 JT: Proposal: 1) go back to community with perspectiv in background section 2) publish primer as a rec in 6 month 3) move responsibility for RDF bits to RDF WG 14:20:33 Noah: except for my concern about the arch document 14:20:54 ashok: have we had any feedback in the community? 14:20:57 Arch doc is wrong or at least fatefully incomplete, and "should" be amended. that's separate 14:21:02 JEni: generally, it's ok 14:21:17 Maybe we do need to call out the difference between the two qualitatively different kinds of 'ambiguity': the lp/ptopic one, which is specific to URIs, and the whole host of hayes/booth/etc. ambiguities which arise for almost _any_ kind of referring expression. 14:21:18 q+ 14:21:45 ht: my guess is that the people paying attention... no one left standing wants to win, people just don't want to lose 14:21:58 ack next 14:22:59 timbl: I'm worried about going into the RDF working group. it's taken a long time for the three people to come to a working situation, even being on the tag... I think the danger when it hits the RDF working group, there's a tendency to go off into philosophical tangents 14:23:02 Broader coordination on URI "meaning" *would have* been good. (For new URI schemes it would be great.) It's too late for that, the space has been populated noninteroperably. 14:24:10 timbl: RDF working group comes to it from a model theory... we should push on it a bit, should we do more work before handling ... i'd like to see an example form schema.org and rdf examples 14:24:35 jeni mentioned that the primer would turn into a rec. would it make sense .... 14:27:15 (Can we push on application of RDF to the web, as Tim suggests, without doing more work? - maybe we can do this via a use case.) 14:27:48 . PROPOSAL: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intension to transition to RDF WG, all by April 1 2013 14:27:49 … I don't even want to do it as a note… I'd rather spend time with Ivan and Sandro talking through it with them 14:28:38 . PROPOSAL: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intension to transition to RDF WG, all by April 1 2013 14:29:09 JAR, not sure what you mean by "application of RDF to the web" ? 14:29:42 ht, I think I'll have to explain that later. 14:29:56 PROPOSAL: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intension to transition to RDF WG, all by April 1 2013 14:30:13 RESOLUTION: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intension to transition to RDF WG, all by April 1 2013 14:30:23 Agreed without dissent 14:30:42 RESOLUTION: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intension to transition to RDF WG, all by April 1 2013 14:30:42 14:31:19 . ACTION: Larry & others to request time at RDF working group to discuss 14:33:12 I was muted 14:53:09 DKA has joined #tagmem 15:01:27 rrsagent, pointer? 15:01:27 See http://www.w3.org/2012/10/08-tagmem-irc#T15-01-27 15:03:17 topic: TPAC 15:04:40 Noah: asked for room Monday morning & Friday afternoon 15:04:56 Noah: TAG members will probably meet? No formal TAG meeting 15:05:18 Larry, Peter, Ashok, Henry, Tim, Jenni (Only plenary day) 15:06:03 noah: couple of weeks ago, note from Jeff about joint meeting with TAG at TPAC, roughly half the tag, explore options 15:06:35 noah: does anyone wants to say about their plans 15:07:22 4 positions up for election, including Robin's 15:08:30 ashok: couple of things: should we stand up and speak about TAG work. I've offered every year for 4-5 years, but maybe situation with election 15:08:47 Jeni: Robin suggests lightning talks 15:08:47 ACTION jar with help from HT and JT to draft the TAG's response to the ISSUE-57 change proposal 15:08:48 Created ACTION-749 - With help from HT and JT to draft the TAG's response to the ISSUE-57 change proposal [on Jonathan Rees - due 2012-10-15]. 15:08:48 process initiated on 29 February 2012, based on 15:08:49 http://www.w3.org/wiki/TagIssue57Proposal27/Background and F2F minutes 15:08:50 of 8 October 2012. 15:08:56 oops. 15:08:59 multi-line 15:09:14 editing action 15:09:21 jeni: 5-minute lightning talk, this is what we're working on, these are the positions that are available 15:09:35 noah: normally been my custom make sure we have a status report 15:10:10 noah: quarterly is too frequently, i've been working on the product pages, when you give the lightning talk, tell people the web page 15:10:23 larry: ... 15:11:37 larry: two communities ... members, public. lightning talk on election 15:12:36 ht: doing lightning talk is excellent idea, pointless to ask for 15 minutes 15:13:26 jeni: half-day AC on tuesday, half-day on thursday 15:14:04 "Getting more security/network protocol/IETF experience on the TAG would also be helpful. Know any other candidates?" 15:16:05 DKA has joined #tagmem 15:16:28 s/Jenni/Jeni/ 15:17:57 "The TPAC2012-Committee is planning the day" 15:18:07 http://www.w3.org/wiki/TPAC2012-Committee 15:18:48 1) promote past work & dashboard 2) recruit volunteers 3) get feedback on documents 4) 15:18:53 http://www.w3.org/wiki/TPAC2012/SessionIdeas 15:19:20 4) hilite http://www.w3.org/2001/tag/products/ as "Dashboard" to track what TAG is doing and has done 15:19:23 HST wants to show 3 slides: Publishing and Linking; Frag-ids; Participate, review, stand for the c'ttee 15:19:25 4) solicit ideas for topics to take up 15:19:44 ok 15:20:36 http://www.w3.org/wiki/TPAC2012 15:21:00 DKA_ has joined #tagmem 15:21:30 ACTION: Noah to contact Ian about TAG participation in TPAC -- see minutes of 8 Oct late afternoon 15:21:30 Created ACTION-750 - Contact Ian about TAG participation in TPAC -- see minutes of 8 Oct late afternoon [on Noah Mendelsohn - due 2012-10-15]. 15:22:44 Convey sense that 5 mins might be right on general TAG issues 15:23:47 JT: 5 mins at plenary for everyone (Jeni) 5 mins AC (Henry or Larry) 15:26:33 topic: List for Jeff (ACTION-563) 15:26:34 ACTION-563? 15:26:34 ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F -- due 2012-11-01 -- OPEN 15:26:34 http://www.w3.org/2001/tag/group/track/actions/563 15:27:23 noah: background on tracking high priority items for Jeff 15:27:39 ACTION: Henry with help from JAR and JT to produce a publishable version of Issue57Proposal27 (http://www.w3.org/wiki/TagIssue57Proposal27), due 2012-12-31 15:27:39 Created ACTION-751 - With help from JAR and JT to produce a publishable version of Issue57Proposal27 (http://www.w3.org/wiki/TagIssue57Proposal27), due 2012-12-31 [on Henry Thompson - due 2012-10-15]. 15:27:55 trackbot, action-571 due 2012-12-31 15:27:55 ACTION-571 Write up comments on microdata and RDFa due date now 2012-12-31 15:28:03 emphasis on things Jeff wouldn't have noticed otherwise 15:28:19 trackbot, action-751 due 2012-12-31 15:28:19 ACTION-751 With help from JAR and JT to produce a publishable version of Issue57Proposal27 (http://www.w3.org/wiki/TagIssue57Proposal27), due 2012-12-31 due date now 2012-12-31 15:28:28 jeni: http 2.0 stuff 15:28:36 noah: what's the issue? 15:29:02 q+ jar to ask is 'TAG effectiveness' something to raise with Jeff? 15:29:36 larry: candidate to including working on web performance, benchmarking, HTTP performance 15:30:15 tbl: 3986 forking, URLs, registerProtocolHandler 15:30:50 Jonathan: I'll call on you...I think it may be something to disucss w/Jeff, who has already reached out. I don't think it's in THIS list, which is to alert to technical issues he's missing. 15:31:00 ack nex 15:31:05 ack next 15:31:06 jar, you wanted to ask is 'TAG effectiveness' something to raise with Jeff? 15:31:23 larry: not worth teasing out all the related issues of URL issues 15:32:04 noah: JEff's mainly on technical issues 15:32:56 LM: Red flag for me: I want to seminar on security...seems to me Web security is in crisis. Exponential growth in attacks, outpacing expertise to address. 15:33:38 s/want/went/ 15:36:26 ht: mnot observed that he thought that as apocalyptically that the security train wreck was gathering speed. The security APIs and the security architecture has been lost sight of 15:36:40 ht: there's nobody looking at security at the highest level 15:37:09 http://www.computer.org/portal/web/csdl/doi?doc=abs/html/mags/sp/2005/06/j6003.htm 15:37:19 ht: his colleague was saying "black web" and "white web", one is "credit cards are known", vs. people who can be billed 15:37:39 It was Butler Lampson, and the colors were "red" and "green" 15:38:16 Well, on the day it was zuwei, wasn't it? 15:38:24 I guess he credited Butler 15:38:51 zewei chen (of Akamai) 15:39:19 LM: I see security reviews getting lost between IETF and W3C. Attacks cross abstraction boundaries. 15:40:56 TBL: makes a least power argument that it's hard to prove properties of URIs if the specifications for URIs are procedural 15:41:05 s/procedural/imperative/ 15:41:14 tbl: if you have one group defining syntax of URLs, and another group defining a turing machine for processing, then the mismatch becomes an exposure because the groups don't agree on syntax 15:41:33 tbl: talking about "language of least power" 15:42:37 noah: also there are stuff you would tend to design during the design phase 15:43:02 noah: also things we thought were secure aren't falling apart 15:43:29 NM: are we organized to respond to threats, whether in new specs or not. 15:44:12 LM: performance is multi-level. 15:44:24 For Lampson on red and green webs, see http://research.microsoft.com/en-us/um/people/blampson/slides/accountabilityandfreedom.ppt 15:44:44 Great paper on layering and performance: http://portal.acm.org/citation.cfm?id=13677.13678 15:45:36 LM: Speculating on cloud stuff...ashok? 15:46:21 ashok: headlights thing... they wanted to do some cloud standards, and I discouraged. Cloud security is a whole different thing, there have been some interesting attacks 15:46:36 AM: Some earlier things came up, but W3C role seemed unclear to me. Cloud security is a whole different thing. Some attacks: co-locating VMs and causing buffer overflows. 15:47:37 noah: share hosting, someone running on the same machine -- one little leak, someone reinstalls your whole environment 15:48:56 ACTION-563? 15:48:56 ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F -- due 2012-11-01 -- OPEN 15:48:56 http://www.w3.org/2001/tag/group/track/actions/563 15:49:53 ACTION: Jeni to update URIs in data primer based on discussion at Tuesday F2F 15:49:53 Created ACTION-752 - Update URIs in data primer based on discussion at Tuesday F2F [on Jeni Tennison - due 2012-10-15]. 15:50:09 ACTION: Larry to do first draft of technical issues list for Jeff - Due 2012-10-22 15:50:09 Created ACTION-753 - do first draft of technical issues list for Jeff [on Larry Masinter - due 2012-10-22]. 15:52:30 rrsagent, make logs public 15:53:27 Butler Lampson's slides --- slide 16 Noites 15:53:43 s/Noites/Notes/ 15:56:00 """Red-Green is our name for the creation of two different environments for each user in which to do their computing. One environment is carefully managed to keep out attacks – code and data are only allowed if of known trusted origin – because we know that the implementation will have flaws and that ordinary users trust things that they shouldn’t. This is the “Green” environment; important data is kept in it. But because lots of work, and lots of 15:56:01 entertainment, requires accessing things on the Internet about which little is known, or is even feasible to know, regarding their trustworthiness (so it can not be carefully managed), we need to provide an environment in which this can be done – this is the “Red” environment. The Green environment backs up both environments, and when some bug or user error causes the Red environment to become corrupt, it is restored to a previous state (see the recovery 15:56:02 slide); this may entail loss of data, which is why important data is kept on the Green side, where it is less likely to be lost. Isolation between the two environments is enforced using IPsec.""" . 15:56:21 -- Butler Lapson Op.cit. 15:57:52 think: two computers connected via IP (NOT IPC or shared memory) 15:58:07 s/IP/IPsec/ 15:59:00 Time check - 3 mins 15:59:45 http://www.apps.ietf.org 16:00:17 (hmm, maybe got that s/// wrong.) 16:00:56 http://datatracker.ietf.org/ 16:03:34 adjourned for day 16:03:45 rrsagent, pointer? 16:03:45 See http://www.w3.org/2012/10/08-tagmem-irc#T16-03-45 17:59:14 Zakim has left #tagmem