IRC log of tagmem on 2005-12-20

Timestamps are in UTC.

18:02:56 [RRSAgent]
RRSAgent has joined #tagmem
18:02:56 [RRSAgent]
logging to
18:03:04 [Vincent]
Zakim, INRIA is Vincent
18:03:04 [Zakim]
+Vincent; got it
18:03:41 [Zakim]
18:04:12 [DanC]
18:04:18 [Vincent]
Zakim, who is here
18:04:18 [Zakim]
Vincent, you need to end that query with '?'
18:04:26 [DanC]
Chair: VQ
18:04:29 [Vincent]
Zakim, who is here?
18:04:29 [Zakim]
On the phone I see Ht, DanC, ??P5, Vincent, Roy, Noah_Mendelsohn
18:04:36 [Zakim]
On IRC I see RRSAgent, Ed, Vincent, Zakim, noah_lunch, ht, DanC_g, DanC
18:04:56 [Zakim]
18:05:02 [Vincent]
Zakim, P5 is Ed
18:05:02 [Zakim]
sorry, Vincent, I do not recognize a party named 'P5'
18:05:18 [Vincent]
Zakim, ??P5 is Ed
18:05:18 [Zakim]
+Ed; got it
18:05:22 [DanC]
Topic: Administrative: take roll, review records and agenda
18:06:54 [DanC]
Scribe: DanC, RoyF
18:07:09 [Roy]
Roy has joined #tagmem
18:07:12 [DanC]
reminder: 27 Dec is cancelled
18:07:18 [DanC]
next teleconference: 3 January 2006
18:07:34 [DanC]
scribe for 3 Jan: NDW
18:08:00 [DanC]
VQ: is up to 1.14
18:08:35 [DanC]
-> minutes 13 Dec
18:08:39 [Norm]
Norm has joined #tagmem
18:08:47 [Roy]
VQ: any objection to minutes of Monday 5 Dec?
18:08:58 [Norm]
zakim, mute me
18:08:58 [Zakim]
Norm should now be muted
18:09:07 [Roy]
no objections, approved
18:10:09 [Roy]
s/Monday 5 Dec/13 Dec/
18:10:32 [dorchard]
dorchard has joined #tagmem
18:10:35 [Zakim]
18:11:12 [Roy]
VQ: any objection to minutes of 5-6 Dec F2F after links are made between the two days?
18:11:23 [Roy]
NM: I will add the links
18:11:47 [Roy]
VQ: will add links from agenda
18:12:11 [Roy]
VQ: any objections? [none]
18:12:36 [Roy]
Regrets: TimBL
18:12:58 [Roy]
Topic: Celebration
18:13:30 [Roy]
18:14:01 [Norm]
Mincemeat pies
18:14:04 [Roy]
DC: sad that the links are broken to Stuart's recipe
18:16:36 [Roy]
Topic: Issue NamespaceState-48
18:16:45 [Norm]
zakim, unmute me
18:16:45 [Zakim]
Norm should no longer be muted
18:16:54 [Roy]
18:17:59 [Roy]
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 [Roy]
HT: I suggest the removal of that one-sentence paragraph
18:18:24 [Vincent]
18:18:29 [Roy]
18:18:39 [Roy]
NW: um, okay
18:19:29 [DanC]
(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 [ht]
q+ to ask where Namespace-as-such is defined
18:20:58 [Roy]
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 [Roy]
which paragraph?
18:21:57 [Norm]
Second para of the preface that begins "The terms in a..."
18:22:32 [Roy]
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 [Zakim]
18:22:57 [Roy]
DC: so at least a subset is single-named
18:23:38 [Vincent]
ack ht
18:23:38 [Zakim]
ht, you wanted to ask where Namespace-as-such is defined
18:23:58 [Roy]
"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 [DanC]
[[ [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 [Roy]
HT: when you say the RDF namespace consists of URIs, what recommendation do you look for that makes that definition?
18:26:41 [Roy]
DC: I did not say the namespace consists of URIs -- I said the terms are not two-part identifiers
18:27:26 [ht]
HST finds, which doesn't appear to constraint fragIDs in RDF node identifiers to be NCNames
18:27:55 [DanC]
(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 [Roy]
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_]
timbl_ has joined #tagmem
18:29:44 [ht]
18:29:55 [Roy]
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 [Roy]
DC: the Namespace rec does not define terms as two-part identifiers
18:30:54 [Norm]
The thing after the # has to be an NCName
18:31:33 [Norm]
<x:y xmlns:x="">
18:31:43 [timbl_]
q+ to say that a clean approach is to say that nopt all RDF graphs can be serialized.
18:31:50 [Norm]
That's the property isn't it?
18:31:54 [timbl_]
q+ to say that a clean approach is to say that nopt all RDF graphs can be serialized in RDF/XML
18:32:47 [Roy]
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 [Norm]
zakim, mute me
18:32:54 [Zakim]
Norm should now be muted
18:33:12 [timbl_]
No relationship between the 3 terms: prob. an example of everyone thinking it was obvious
18:34:08 [Vincent]
ack timbl
18:34:08 [Zakim]
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 [Zakim]
... serialized in RDF/XML
18:34:13 [noah_lunch]
18:34:34 [noah_lunch]
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 [noah_lunch]
18:34:45 [Roy]
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 [noah]
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 [Norm]
zakim, unmute me
18:35:10 [Zakim]
Norm should no longer be muted
18:35:20 [Roy]
DC: URIs are fundamental to webarch -- that should be our goal
18:36:04 [Norm]
18:36:09 [Norm]
18:36:14 [Roy]
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 [ht]
HST suggested prog?function=foo
18:36:38 [Vincent]
ack noah
18:36:38 [Zakim]
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 [timbl_]
18:38:02 [ht]
q+ to ask again about the 1-part/2-part issue
18:38:19 [Roy]
NM: The question is whether we should describe namespaces as written or as we wish it could have been written...
18:38:35 [Norm]
I have to go
18:38:39 [Zakim]
18:39:40 [Roy]
... 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 [Roy]
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 [Vincent]
ack ht
18:40:37 [Zakim]
ht, you wanted to ask again about the 1-part/2-part issue
18:41:10 [Roy]
HT: I agree with Noah
18:41:51 [Roy]
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 [noah]
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 [noah]
This finding is about the immutability of the set of two part names {myUri,*}.
18:43:47 [ht]
Note that the local names are _always_ mappable to URIs, unless the namespace name is perverse
18:43:48 [noah]
That's why the two partness is pertinent.
18:44:33 [timbl_]
A namespace has a URI and a set of local names
18:44:38 [DanC]
"A namespace has a URI and a set of local names"
18:45:13 [Roy]
sounds good to me
18:45:21 [Zakim]
18:45:25 [Zakim]
18:45:28 [DanC]
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 [Roy]
zakim, who is present?
18:45:56 [Zakim]
I don't understand your question, Roy.
18:45:58 [ht]
Dan, why do they violate it, if myURI is not perverse?
18:46:03 [DanC]
Zakim, who's on the phone?
18:46:03 [Zakim]
On the phone I see Ht, DanC, Ed, Vincent, Roy, DOrchard, TimBL, Noah_Mendelsohn.a
18:46:11 [timbl_]
xml:id archietctrue is for XML separate from the NS architecture. For RDF they merge.
18:46:16 [noah]
zakim, Noah_mendelsohn.a is me
18:46:16 [Zakim]
+noah; got it
18:46:39 [DanC]
principle #1 says Use URIs; to use two part names {myUri,*} is not to use URIs, without a mapping.
18:46:58 [Roy]
TBL: should we finish with this finding now, or move on?
18:47:24 [noah]
I would hate to lose this finding over this.
18:47:36 [noah]
We have consensus on the key point about immutability.
18:48:18 [DanC]
(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 [ht]
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 [timbl_]
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 [Roy]
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 [timbl_]
18:49:35 [ht]
s/A namespace has/An XML Namespace has/
18:49:37 [timbl_]
18:49:48 [Vincent]
ack timbl
18:50:44 [DanC]
( 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 [noah]
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 [Roy]
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]
DanC has changed the topic to: scribe: Roy
18:52:44 [Roy]
DC: should we just remove the sentence or actually say what we want to say in the document.
18:53:10 [ht]
I only find the following of relevance: "Good practice: QName Mapping
18:53:10 [ht]
A specification in which QNames serve as resource identifiers MUST provide a mapping to URIs.
18:53:17 [Roy]
VQ: inclined not to make a decision without Norm, let's defer this and move on
18:53:44 [Roy]
Topic: Principle of Least Power
18:54:02 [timbl_]
18:54:13 [Roy]
18:54:20 [noah]
18:54:22 [Roy]
18:54:35 [DanC]
[[ Is it a principle? Roy suggests "no". ]] I thought Roy said yes
18:54:48 [Roy]
I did say yes
18:55:19 [DanC]
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 [Roy]
NM: The real exercise is to read the original and then read this document.
18:56:28 [Roy]
TBL: I suggest this is a good record and people can just review this document.
18:58:32 [DanC]
(yes, let's please elaborate on the SQL case, rather than strike it.)
18:58:50 [Roy]
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 [Roy]
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 [timbl_]
<footnote>... </footnote>
19:00:54 [DanC]
(Roy, do you see a way to phrase the thesis statement as a principle?)
19:00:56 [timbl_]
q+ to talk about Sem Web languages.
19:01:21 [Roy]
maybe when I am not trying to take notes
19:01:40 [DanC]
19:02:06 [DanC]
q+ to say I lean toward discussing HTML separately from the SemWeb, if only for story-telling/history reasons.
19:02:11 [Vincent]
ack timbl
19:02:11 [Zakim]
timbl_, you wanted to talk about Sem Web languages.
19:02:30 [noah]
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 [DanC]
(it's OWL DL that's intentionally limited. OWL full is pretty much unlimited)
19:03:40 [noah]
TBL: suggests adding discussion of OWL and Rule Interchange Format and their limited expressive power, with more capable supersets available
19:04:01 [noah]
TBL: also, the relationships between subset and superset languages can be particularly clear in the realm of logic
19:04:32 [DanC]
q+ to suggest elaborating on the word "turing complete"
19:04:35 [Vincent]
ack danc
19:04:35 [Zakim]
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 [Zakim]
... complete"
19:05:40 [noah]
DC: mentions that not all readers will know about Turing completeness
19:06:39 [Roy]
RF: IIRC, PDF is turing complete
19:07:09 [timbl_]
I think a reference to that paper would be in order too
19:07:10 [Roy]
... or am I thinking just postscrpt?
19:07:26 [Roy]
19:07:42 [noah]
In html-essay see "On Formally Unconvertable Document Formats
19:07:42 [noah]
19:08:51 [noah]
"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 [Roy]
DC: or maybe more extensive references to definitions
19:09:48 [timbl_]
"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 [timbl_]
from danc's stuff
19:11:09 [Roy]
RF: I am happy to call this a principle
19:11:29 [Roy]
... I was worried about the negative name, but am now happy with that as well.
19:11:31 [timbl_]
It is couched in the imperative
19:11:45 [Roy]
DC: Good Practice should be rewritten as a Principle
19:12:28 [DanC]
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 [noah]
Roy is happy with calling it PLP.
19:14:04 [Roy]
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 [Roy]
NM: leaning against using RFC 2119 terms [agreed]
19:16:45 [Roy]
NM: Java "can't be analysed at all" is too strong.
19:16:54 [noah]
Editorial: ""the attraction of being an open-ended hook into which anything can be placed" "
19:17:06 [Roy]
DC: should add quote about halting problem
19:18:32 [Roy]
ACTION: Noah to take comments and put together a next draft on PLP by mid January
19:19:02 [Roy]
Topic: Action Tracking
19:19:35 [Roy]
19:21:21 [Roy]
VQ: this is getting hard to keep up to date. It would be helpful to have only one issues list.
19:21:47 [timbl_]
q+ to ask whether we can scrape this information and present t it in more than one form
19:22:06 [Roy]
VQ: I think that now I am comfortable with maintaining the issues list and providing a view-by-issues list.
19:22:13 [timbl_]
"Any other business"
19:22:20 [Roy]
DC: what about actions without an issue?
19:22:59 [Roy]
RF: let's put them under issue 42
19:23:46 [ht]
Roy, please include a link to at the end of the discussion of namespaceState-48 above
19:24:16 [Roy]
s/please/remember to/
19:25:23 [timbl_]
19:25:31 [Roy]
DC: and some of the issues are still assigned to former TAG members
19:26:25 [DanC]
19:28:25 [Roy]
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 [Roy]
VQ: I have updated the issues list to point to related discussions on list
19:29:47 [Roy]
VQ: source file is 2001/tag/issues.xml
19:30:16 [Zakim]
19:30:21 [Zakim]
19:30:26 [Zakim]
19:30:37 [Roy]
VQ: Remaining agenda items will be tabled until 3rd Jan.
19:30:42 [Zakim]
19:30:42 [Roy]
19:30:57 [Roy]
rrsagent, pointer?
19:30:57 [RRSAgent]
19:31:19 [Roy]
rrsagent, make logs world-access
19:33:22 [Zakim]
19:34:31 [timbl_]
19:35:22 [DanC]
19:48:18 [Zakim]
20:32:39 [Zakim]
20:32:40 [Zakim]
20:32:42 [Zakim]
TAG_Weekly()12:30PM has ended
20:32:43 [Zakim]
Attendees were Ht, DanC, Roy, Vincent, Noah_Mendelsohn, Norm, Ed, DOrchard, TimBL, noah
20:33:14 [timbl_]
timbl_ has left #tagmem
21:39:19 [Zakim]
Zakim has left #tagmem
22:10:15 [noah]
DanC, you there?
22:13:50 [noah]
Dan, you there?
22:32:58 [DanC]
hi Noah
22:53:57 [noah]
Hi, I had a CVS question
22:54:16 [noah]
Henry left his minutes in
22:55:09 [noah]
I have for months been successfully working in*, 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 [DanC]
I think I answered in email
23:19:21 [DanC]
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 [noah]
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 [noah]
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 [noah]
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 [DanC]
I think you have access not to all of /2001/ but to /2001/tag/
23:42:28 [noah]
Possibly. I also have access to XML (I.e. sibling of 2001)
23:42:56 [noah]
I got that when I was a schema editor.
23:43:16 [noah]
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 [noah]
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 [DanC]
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 [DanC]
It's a problem that I'm very interested in, with my research hat on.
23:50:21 [noah]
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 [noah]
Yes, you can get much more flexible behavior with rules.
23:51:19 [noah]
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 [noah]
Too many, and nobody can figure out why the system is doing what it is.
23:51:32 [noah]
Complexity of a different sort.
23:51:41 [noah]
Do you find that to be true in your work on this?
23:52:41 [DanC]
absolutely... policies have to be understood in order to be effective
23:53:32 [noah]
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 [DanC]
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 [noah]
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 [noah]
Well, something to watch for.
23:54:25 [DanC]
23:54:47 [noah]
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 [DanC]
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 [noah]
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 [DanC]
23:58:21 [noah]
Well, good luck. And thanks for handling the access to the team-only stuff. See ya.
23:58:29 [DanC]
welcome. hasta.