18:02:56 RRSAgent has joined #tagmem 18:02:56 logging to http://www.w3.org/2005/12/20-tagmem-irc 18:03:04 Zakim, INRIA is Vincent 18:03:04 +Vincent; got it 18:03:41 +Noah_Mendelsohn 18:04:12 Agenda: http://www.w3.org/2001/tag/2005/12/20-agenda.html 18:04:18 Zakim, who is here 18:04:18 Vincent, you need to end that query with '?' 18:04:26 Chair: VQ 18:04:29 Zakim, who is here? 18:04:29 On the phone I see Ht, DanC, ??P5, Vincent, Roy, Noah_Mendelsohn 18:04:36 On IRC I see RRSAgent, Ed, Vincent, Zakim, noah_lunch, ht, DanC_g, DanC 18:04:56 +Norm 18:05:02 Zakim, P5 is Ed 18:05:02 sorry, Vincent, I do not recognize a party named 'P5' 18:05:18 Zakim, ??P5 is Ed 18:05:18 +Ed; got it 18:05:22 Topic: Administrative: take roll, review records and agenda 18:06:54 Scribe: DanC, RoyF 18:07:09 Roy has joined #tagmem 18:07:12 reminder: 27 Dec is cancelled 18:07:18 next teleconference: 3 January 2006 18:07:34 scribe for 3 Jan: NDW 18:08:00 VQ: http://www.w3.org/2001/tag/2005/12/20-agenda.html is up to 1.14 18:08:35 -> http://www.w3.org/2001/tag/2005/12/13-tagmem-minutes minutes 13 Dec 18:08:39 Norm has joined #tagmem 18:08:47 VQ: any objection to minutes of Monday 5 Dec? 18:08:58 zakim, mute me 18:08:58 Norm should now be muted 18:09:07 no objections, approved 18:10:09 s/Monday 5 Dec/13 Dec/ 18:10:32 dorchard has joined #tagmem 18:10:35 +DOrchard 18:11:12 VQ: any objection to minutes of 5-6 Dec F2F after links are made between the two days? 18:11:23 NM: I will add the links 18:11:47 VQ: will add links from agenda 18:12:11 VQ: any objections? [none] 18:12:36 Regrets: TimBL 18:12:58 Topic: Celebration 18:13:30 yeah 18:14:01 Mincemeat pies 18:14:04 DC: sad that the links are broken to Stuart's recipe 18:16:36 Topic: Issue NamespaceState-48 18:16:45 zakim, unmute me 18:16:45 Norm should no longer be muted 18:16:54 http://www.w3.org/2001/tag/doc/namespaceState.html 18:17:59 NM: agreed to do a bit of rearranging at last call -- that is done. There have been a couple question on list 18:18:15 HT: I suggest the removal of that one-sentence paragraph 18:18:24 q? 18:18:29 s/NM/NW/ 18:18:39 NW: um, okay 18:19:29 (I'm content with just striking that para, though it only postpones this discussion. It'll come up again in the course of self-describing/grounded documents.) 18:20:14 q+ to ask where Namespace-as-such is defined 18:20:58 NM: things like schema recommendations that clearly build on the definition of namespaces identifiers as two-part names, whereas others depend on xmlns producing a URI algorithm [??] 18:21:42 which paragraph? 18:21:57 Second para of the preface that begins "The terms in a..." 18:22:32 DC: It says that the names *are* two-part names, whereas in things like RDF they are defined to be a single name on purpose 18:22:56 +TimBL 18:22:57 DC: so at least a subset is single-named 18:23:38 ack ht 18:23:38 ht, you wanted to ask where Namespace-as-such is defined 18:23:58 "The terms in a namespace are two-part identifiers consisting of a namespace name (a URI) and a local name (an NCName as defined in [XML Namespaces]). Using a URI leverages the well-understood URI allocation mechanisms of [WebArch Vol 1]." 18:25:33 [[ [Definition:] An XML namespace is a collection of names, identified by a URI reference [RFC2396], which are used in XML documents as element types and attribute names. ]] 18:25:45 HT: when you say the RDF namespace consists of URIs, what recommendation do you look for that makes that definition? 18:26:41 DC: I did not say the namespace consists of URIs -- I said the terms are not two-part identifiers 18:27:26 HST finds http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabulary, which doesn't appear to constraint fragIDs in RDF node identifiers to be NCNames 18:27:55 (er... either I misspoke or I misrecorded; I did say the namespace consists of URIs; when Henry asked what W3C spec I got that from, I didn't get it from a W3C Rec) 18:28:32 NM: I can live with removing it, but, like Dan, I think we would be papering over something that we meant to say 18:28:59 timbl_ has joined #tagmem 18:29:44 http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabulary 18:29:55 RF: I don't think it can be simply removed -- there needs to be some definition of what we are talking about, and I thought that URI issues was one of the main reasons for this issue 18:30:25 DC: the Namespace rec does not define terms as two-part identifiers 18:30:54 The thing after the # has to be an NCName 18:31:33 18:31:43 q+ to say that a clean approach is to say that nopt all RDF graphs can be serialized. 18:31:50 That's the property http://example.org/?y isn't it? 18:31:54 q+ to say that a clean approach is to say that nopt all RDF graphs can be serialized in RDF/XML 18:32:47 DC: As long as the namespace creator adheres to some constrains (identifier ending in a delimiter, term names being NCName, and a flat namespace) then we have terms identified by a URI 18:32:54 zakim, mute me 18:32:54 Norm should now be muted 18:33:12 No relationship between the 3 terms: prob. an example of everyone thinking it was obvious 18:34:08 ack timbl 18:34:08 timbl_, you wanted to say that a clean approach is to say that nopt all RDF graphs can be serialized. and to say that a clean approach is to say that nopt all RDF graphs can be 18:34:11 ... serialized in RDF/XML 18:34:13 q? 18:34:34 q+ to say that while URIs may be key to web arch, the NS Rec for better or worse doesn't talk about them 18:34:42 q- 18:34:45 HT: surprised that you put so much emphasis on URIs instead of two-part names given that there are so many existing languages that have non-flat namespaces and thus do not meet that criteria 18:34:50 q+ to say that while URIs may be key to web arch, the NS Rec for better or worse doesn't talk about them 18:35:10 zakim, unmute me 18:35:10 Norm should no longer be muted 18:35:20 DC: URIs are fundamental to webarch -- that should be our goal 18:36:04 s/harder/easier/ 18:36:09 s/easier/better/ 18:36:14 TBL: The problem is that such languages are weaker with regards to Web Architecture because they are not as well grounded in the Web via URIs 18:36:36 HST suggested prog?function=foo 18:36:38 ack noah 18:36:38 noah, you wanted to say that while URIs may be key to web arch, the NS Rec for better or worse doesn't talk about them 18:37:11 :) 18:38:02 q+ to ask again about the 1-part/2-part issue 18:38:19 NM: The question is whether we should describe namespaces as written or as we wish it could have been written... 18:38:35 I have to go 18:38:39 -Norm 18:39:40 ... we are answering, in Norm's finding, an issue with limited scope and the nub of that issue is not how to define XML namespaces. This is about the mutability of namespaces. 18:40:36 NM: Norm's finding does a nice job of answering the mutability issue. Other issues should be identified and resolved in a different finding. 18:40:37 ack ht 18:40:37 ht, you wanted to ask again about the 1-part/2-part issue 18:41:10 HT: I agree with Noah 18:41:51 DC: How about if we go back and talk about striking the sentence: "The terms in a namespace are two-part identifiers consisting of a namespace name (a URI) and a local name (an NCName as defined in [XML Namespaces])." 18:43:21 Tim says having names that don't map to URIs is bad. I agree. I don't understand why that's in scope for this finding. 18:43:41 This finding is about the immutability of the set of two part names {myUri,*}. 18:43:47 Note that the local names are _always_ mappable to URIs, unless the namespace name is perverse 18:43:48 That's why the two partness is pertinent. 18:44:33 A namespace has a URI and a set of local names 18:44:38 "A namespace has a URI and a set of local names" 18:45:13 sounds good to me 18:45:21 +Noah_Mendelsohn.a 18:45:25 -Noah_Mendelsohn 18:45:28 two part names {myUri,*} violate prinicple #1 of webarch; every time we speak of them, we should remind our readers of that. 18:45:56 zakim, who is present? 18:45:56 I don't understand your question, Roy. 18:45:58 Dan, why do they violate it, if myURI is not perverse? 18:46:03 Zakim, who's on the phone? 18:46:03 On the phone I see Ht, DanC, Ed, Vincent, Roy, DOrchard, TimBL, Noah_Mendelsohn.a 18:46:11 xml:id archietctrue is for XML separate from the NS architecture. For RDF they merge. 18:46:16 zakim, Noah_mendelsohn.a is me 18:46:16 +noah; got it 18:46:39 principle #1 says Use URIs; to use two part names {myUri,*} is not to use URIs, without a mapping. 18:46:58 TBL: should we finish with this finding now, or move on? 18:47:24 I would hate to lose this finding over this. 18:47:36 We have consensus on the key point about immutability. 18:48:18 (I didn't realize we lost our editor; I was waiting for the editor to pick one of the options where no objections had been voiced) 18:49:07 Suggest we replace the mistaken para as follows: "A namespace has a namespace name (a URI) and a set of local names (NCNames as defined in [XML Namespaces]). 18:49:28 A namespace has a URI and a set of local names (each an NCName as defined in [XML Namespaces]). Using a URI leverages the well-understood URI allocation mechanisms of [WebArch Vol 1]. Languages are required to provide a mapping from the pair of the URI and NCName to a URI [WebArch Vol 1]. 18:49:30 NM: I think the paragraph is useful for framing the discussion, but not necessary for the issue discussed in the finding. I find it difficult to talk about mutability without talking about the two parts, but I can live with it. 18:49:33 q? 18:49:35 s/A namespace has/An XML Namespace has/ 18:49:37 q+ 18:49:48 ack timbl 18:50:44 ( there _is_ a way to talk about the whole thing without 2-partness; regard the 2-part names as short-hand for URIs, and talk about the foo#bar idiom, and the implications of the immutability of what foo refers to) 18:51:00 I don't object in principle to what Tim's written. I'm a bit concerned that readers will be confused: they'll say, OK, but why does this statement about URIs help me understand the next part about immutability? 18:51:10 TBL: making references about what webarch has already said is a good idea. I suggest linking back to the paragraph in webarch about terms being given URI (or an algorithm from generating a URI from the tuple) 18:51:53 DanC has changed the topic to: http://www.w3.org/2001/tag/2005/12/20-agenda.html scribe: Roy 18:52:44 DC: should we just remove the sentence or actually say what we want to say in the document. 18:53:10 I only find the following of relevance: "Good practice: QName Mapping 18:53:10 A specification in which QNames serve as resource identifiers MUST provide a mapping to URIs. 18:53:17 VQ: inclined not to make a decision without Norm, let's defer this and move on 18:53:44 Topic: Principle of Least Power 18:54:02 +1 18:54:13 http://www.w3.org/2001/tag/doc/leastPower 18:54:20 http://www.w3.org/2001/tag/doc/leastPower-2005-12-20.html 18:54:22 http://www.w3.org/2001/tag/doc/leastPower.html 18:54:35 [[ Is it a principle? Roy suggests "no". ]] I thought Roy said yes 18:54:48 I did say yes 18:55:19 ah... the bumper-sticker: [[ Good Practice: Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web. ]] 18:55:59 NM: The real exercise is to read the original and then read this document. 18:56:28 TBL: I suggest this is a good record and people can just review this document. 18:58:32 (yes, let's please elaborate on the SQL case, rather than strike it.) 18:58:50 NM: Recent changes --- comments received about Turing-completeness of SQL, with several variants of different power, which may lead to removal of SQL as an example 18:59:39 TBL: I like the SQL example because its limited power is intentional and that makes it a good example -- we should leave it in but specify which SQL (and why) 18:59:52 ... 19:00:54 (Roy, do you see a way to phrase the thesis statement as a principle?) 19:00:56 q+ to talk about Sem Web languages. 19:01:21 maybe when I am not trying to take notes 19:01:40 ok 19:02:06 q+ to say I lean toward discussing HTML separately from the SemWeb, if only for story-telling/history reasons. 19:02:11 ack timbl 19:02:11 timbl_, you wanted to talk about Sem Web languages. 19:02:30 Noah notes that Tim's concern with mixing HTML and RDF comes from his sentence "If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. " 19:03:06 (it's OWL DL that's intentionally limited. OWL full is pretty much unlimited) 19:03:40 TBL: suggests adding discussion of OWL and Rule Interchange Format and their limited expressive power, with more capable supersets available 19:04:01 TBL: also, the relationships between subset and superset languages can be particularly clear in the realm of logic 19:04:32 q+ to suggest elaborating on the word "turing complete" http://www.w3.org/MarkUp/html-spec/html-essay.html 19:04:35 ack danc 19:04:35 DanC, you wanted to say I lean toward discussing HTML separately from the SemWeb, if only for story-telling/history reasons. and to suggest elaborating on the word "turing 19:04:39 ... complete" http://www.w3.org/MarkUp/html-spec/html-essay.html 19:05:40 DC: mentions that not all readers will know about Turing completeness 19:06:39 RF: IIRC, PDF is turing complete 19:07:09 I think a reference to that paper would be in order too 19:07:10 ... or am I thinking just postscrpt? 19:07:26 s/postscrpt/postscript/ 19:07:42 In html-essay see "On Formally Unconvertable Document Formats 19:07:42 " 19:08:51 "verge on the Turing Complete (PDF), through those which are in fact Turing Complete though one is led not to use them that way (XSLT, SQL), through those that are functional and Turing complete (Haskell), to those which are unashamedly procedural (Java, Javascript, C)." 19:09:11 DC: or maybe more extensive references to definitions 19:09:48 "The reason that this distinction is essential with respect to document interchange is that extracting information from documents in "programmable" document formats is equivalent to the halting problem. That is, it is arbitrarily difficult and cannot be automated in a general fashion." 19:09:54 from danc's stuff 19:11:09 RF: I am happy to call this a principle 19:11:29 ... I was worried about the negative name, but am now happy with that as well. 19:11:31 It is couched in the imperative 19:11:45 DC: Good Practice should be rewritten as a Principle 19:12:28 I think the principle-in-a-box is critical; whether the good practice is worth the screenspace, I hesitate to judge without seeing it 19:12:53 Roy is happy with calling it PLP. 19:14:04 NM: I'll think about how to rephrase the one-sentence as a principle, and make additional prose for implication for the Web 19:15:46 NM: leaning against using RFC 2119 terms [agreed] 19:16:45 NM: Java "can't be analysed at all" is too strong. 19:16:54 Editorial: ""the attraction of being an open-ended hook into which anything can be placed" " 19:17:06 DC: should add quote about halting problem 19:18:32 ACTION: Noah to take comments and put together a next draft on PLP by mid January 19:19:02 Topic: Action Tracking 19:19:35 http://www.w3.org/2001/tag/2005/03/action-summary.html#byIA 19:21:21 VQ: this is getting hard to keep up to date. It would be helpful to have only one issues list. 19:21:47 q+ to ask whether we can scrape this information and present t it in more than one form 19:22:06 VQ: I think that now I am comfortable with maintaining the issues list and providing a view-by-issues list. 19:22:13 "Any other business" 19:22:20 DC: what about actions without an issue? 19:22:59 RF: let's put them under issue 42 19:23:46 Roy, please include a link to http://lists.w3.org/Archives/Public/www-tag/2005Dec/0114.html at the end of the discussion of namespaceState-48 above 19:24:16 s/please/remember to/ 19:25:23 s/pending/open 19:25:31 DC: and some of the issues are still assigned to former TAG members 19:26:25 http://www.w3.org/2001/tag/actions_owner.html 19:28:25 VQ: I will spend some time cleaning up the issues list to contain all the actions and reassign or abandon the old actions where necessary 19:29:12 VQ: I have updated the issues list to point to related discussions on list 19:29:47 VQ: source file is 2001/tag/issues.xml 19:30:16 -DOrchard 19:30:21 -Ed 19:30:26 -Vincent 19:30:37 VQ: Remaining agenda items will be tabled until 3rd Jan. 19:30:42 -noah 19:30:42 ADJOURN 19:30:57 rrsagent, pointer? 19:30:57 See http://www.w3.org/2005/12/20-tagmem-irc#T19-30-57 19:31:19 rrsagent, make logs world-access 19:33:22 -Roy 19:34:31 http://real.lithium.com/real/tracker?user.id=10567 19:35:22 http://www.w3.org/2005/06/tracker/ 19:48:18 -Ht 20:32:39 -TimBL 20:32:40 -DanC 20:32:42 TAG_Weekly()12:30PM has ended 20:32:43 Attendees were Ht, DanC, Roy, Vincent, Noah_Mendelsohn, Norm, Ed, DOrchard, TimBL, noah 20:33:14 timbl_ has left #tagmem 21:39:19 Zakim has left #tagmem 22:10:15 DanC, you there? 22:13:50 Dan, you there? 22:32:58 hi Noah 22:53:57 Hi, I had a CVS question 22:54:16 Henry left his minutes in www.w3.org/2005/12 22:55:09 I have for months been successfully working in www.w3.org/2001/*, but when I went to the parent to check out 2005 it claimed no such dir. Do you know if that would be a problem with team-only permissions, or is this likely to be my novices knowledge of the CVS client? 23:15:33 I think I answered in email 23:19:21 there are policy reasons that you can't write to /2005/12/ , but it could be that you're having CVS client woes too 23:32:42 OK. Thanks. I guess they must have specifically openned up /2001 for me. It's not 100% clear to me why 2001 is less secure than 2005, but there you go. 23:33:40 So, I guess we either decide to work in 2001 (which is where tag/doc is, among other things), or I'll need access to 2005. Or I can retire from clerical work :-) 23:34:14 Anyway, thanks for confirming that it may well be an access control issue. Then again, I'm surprised CVS claims it doesn't exist, rather than saying "access denied" or some such. Anyway, thanks. 23:38:13 I think you have access not to all of /2001/ but to /2001/tag/ 23:42:28 Possibly. I also have access to XML (I.e. sibling of 2001) 23:42:56 I got that when I was a schema editor. 23:43:16 No matter. As long as all this is working as designed, and I'm not too often responsible for editing things I can't get to, there's no problem. 23:43:50 It's an occasional nuissance not to be able to change permissions on IRC logs, but no worse than a nuissance. You and others have been very good about doing it for me when we forget to tell rrsagent to do it. 23:48:43 it sure sucks to know what needs to be done, and to know that everybody would be happy if you did it this one time, but to be prohibited by policy 23:50:21 It's a problem that I'm very interested in, with my research hat on. http://www.policyawareweb.org/ 23:50:21 This all seems pretty natural to me. You either need to trust people to have a lot of access to lots of things, or you wind up in these situations. It's a natural tension, and I can understand why there is reluctance to grant broader access either in this specific case, or due to the precedent set. 23:50:58 Yes, you can get much more flexible behavior with rules. 23:51:19 Then again, I'm told by those who mess with these things that rules systems tend to hold up if there are modest numbers of rules in play in any given case. 23:51:28 Too many, and nobody can figure out why the system is doing what it is. 23:51:32 Complexity of a different sort. 23:51:41 Do you find that to be true in your work on this? 23:52:41 absolutely... policies have to be understood in order to be effective 23:53:32 The point I found interesting was that there seemed to be a perception of complexity that grew much faster than linearly with the number of rules interacting. Not totally surprising, but it's apparently been a barrier to more widespread deployment of rules-based systems in commercial settings. 23:53:55 in our research work, the use cases we're working on are still pretty simple, so we don't have research results on how complex you can get before it's unmanageable. 23:53:57 Some folks in IBM tried to get me interested in working on RB systems a year or two ago, and I did just a little investigating. That was one of the points that came up. 23:54:09 Well, something to watch for. 23:54:25 quite 23:54:47 You'd like to thing that (a) you can do a lot with just a few rules and (b) even if there are lots of rules in the whole system, if you can easily prove which 5 apply in a given case you should be OK I'd think 23:56:36 I'm confident that the machine can handle lots of rules; the open question is whether the social system -- the people -- can learn them 23:57:23 Exactly. Nobody was claiming there was any nonlinearity in performance or the like, though I suppose it could be. The problem was essentially predictability and debugging. What will this new rule really do? Why could/couldn't I log on? 23:57:40 yeah 23:58:21 Well, good luck. And thanks for handling the access to the team-only stuff. See ya. 23:58:29 welcome. hasta.