13:48:18 RRSAgent has joined #tagmem 13:48:18 logging to http://www.w3.org/2007/11/05-tagmem-irc 13:48:39 timbl has joined #tagmem 13:48:41 skw has joined #tagmem 13:49:39 I'm afraid I wil be late .. I'm on a bu boun d for harvard, t Mt Aburn cemettery 13:49:43 bus 13:50:11 Stuart has joined #tagmem 13:50:12 Stuart has joined #tagmem 13:50:26 I thought I the garage woudl look at my car, but they kep it. 13:50:49 Hi Stuart, sorry i am running late. 13:51:44 skw has joined #tagmem 13:51:45 skw has joined #tagmem 13:52:30 I miht grab a cab if we pass a suitable poit 13:52:51 stuart doesn't seem too worried 13:53:14 Stuart has joined #tagmem 13:53:15 Stuart has joined #tagmem 13:53:22 we're trying to scare up Norm too, timbl 13:53:42 Did Henry and Noah get there yet? 13:53:43 Present: SKW, HT, DC, NM, TVR, RL 13:53:50 Good 13:54:50 skw has joined #tagmem 13:54:51 skw has joined #tagmem 13:54:53 Scribe: Rhys 13:54:59 ScribeNick: Rhys 13:54:59 we had a little tracker gripe session, which went ok, I think. 13:55:23 try an ETA, timbl? 13:55:50 raman has joined #tagmem 13:56:00 15 or 40 mins 13:56:04 Start witout me 13:56:18 Stuart has joined #tagmem 13:56:18 Stuart has joined #tagmem 13:56:33 agenda review... need norm for ns8 ... 13:56:42 topic: Agenda review 13:56:59 If we stp at Mt Auburn Hospital, I'll hop out and hope they have cabs 13:57:03 DanC invites some tag input to http://www.w3.org/html/wg/nov07 , which can be done with whoever is here 13:57:23 SW: need Dave for xmlversioning-41 13:57:57 SW: Explains the meeting for this afternoon and that httpRange-14 is topic. 2pm to 4pm 13:58:04 skw has joined #tagmem 13:58:05 skw has joined #tagmem 13:58:06 HT: I'll have to timeshare for that 13:58:22 SW: xmlFunctions-34 13:58:46 HT: No new draft 13:59:09 SW: TV has an action against that. Can we have a new due date for that? 13:59:20 TVR: End of november 13:59:27 Noah has joined #tagmem 13:59:45 TVR gives end-of-Nov due date for ACTION-25 on T.V. Raman to summarize history of DTD/namespace/mimetype version practice, including XHTML, SOAP, and XSLT. 13:59:53 Present+ DO 14:00:00 SW: Updates Action 25 14:00:24 (tracker RFE: relay updates from the web interface to this channel) 14:00:53 ht has joined #tagmem 14:00:55 Stuart has joined #tagmem 14:00:55 Stuart has joined #tagmem 14:01:07 DO, DC request some meeting time to discuss the Weds URI based extensibility panel 14:01:23 SKW: 1, 3, 6 14:01:32 SW: httpRedirections-57 might be subsumed by this afternoon's meeting and Binary XML 14:01:39 Topic: URI extensibility panel 14:02:40 skw has joined #tagmem 14:02:41 skw has joined #tagmem 14:03:00 DO: somebody has requested to participate by video 14:03:05 SW: We should cover agenda items 1, 3, 6 this morning 14:03:23 several advise against trying to add video to the mix at this late stage 14:05:30 Stuart has joined #tagmem 14:05:31 Stuart has joined #tagmem 14:06:24 DO: Describes the latest state of the URI extensibility panel for Wednesday. 14:07:23 skw has joined #tagmem 14:10:03 Stuart has joined #tagmem 14:10:03 Stuart has joined #tagmem 14:10:30 Regrets: Norm for this morning 14:11:29 Tim... do you know when you're are likely to arrive. 14:11:58 skw has joined #tagmem 14:11:59 skw has joined #tagmem 14:12:11 know... or can you estimate? 14:13:57 RRSAgent, draft minutes 14:13:57 I have made the request to generate http://www.w3.org/2007/11/05-tagmem-minutes.html DanC_ 14:14:31 Stuart has joined #tagmem 14:14:31 Stuart has joined #tagmem 14:15:19 HT: There was also a proposal to give Dan some time on HTML 14:16:01 Topic: Item 6 - XML Binary binaryXML-30 ISSUE: 30 14:16:06 Present+ TimBL 14:16:34 skw has joined #tagmem 14:16:35 skw has joined #tagmem 14:16:51 DO: The summary of feedback was that I could not tell whether or not they had met the bar they set themselves 14:17:04 (I think it was: the bar we set) 14:17:57 DO: I even downloaded different JDKs and ran the test harness on my laptop, and did not see anything particularly interesting 14:18:10 DO: It was easy to get the harness working, by the way 14:18:22 (yes, always nice when results have been written up to the point that the're reproducible!) 14:18:51 DO: reviews the comments he made in his note to the TAG 14:19:04 Stuart has joined #tagmem 14:19:04 Stuart has joined #tagmem 14:20:44 timbl has joined #tagmem 14:21:11 skw has joined #tagmem 14:21:12 skw has joined #tagmem 14:23:15 NM: Generally like what it says, but it seems like it could be shorter 14:23:34 DC: I thought this too, but when I looked in detail, I couldn't see how 14:23:38 Stuart has joined #tagmem 14:23:38 Stuart has joined #tagmem 14:24:02 NM: Maybe it just needs a summary at the top 14:24:30 NM: Some of the comments need to be phrased a little differently. 14:24:40 DO: We can work on that off-line 14:25:07 SW: They produced a lot of data and measurements and seem to have done a good job 14:25:47 skw has joined #tagmem 14:25:48 skw has joined #tagmem 14:26:03 DC: The message in Dave's note is an attention getter, and it is out there now. I don't think that redrafting it now is a good use of time 14:26:15 q+ 14:26:37 SW: Just on process, should we generally publish drafts on the member list? 14:27:02 NM: It said draft at the top, so I'm less concerned about the fact that it went on the public list 14:27:52 q+ to say, again, that presumes the conclusion, and doesn't address our request. 14:27:56 HT: This response follows up the TAG's original concern. We think that EXI will happen, and the question is whether or not W3C needs to try and ensure interoperability 14:28:12 Stuart has joined #tagmem 14:28:13 Stuart has joined #tagmem 14:28:27 HT: They have come out with a consensus position, which is that EXI is worth standardising 14:28:34 q+ to mention it seems that the EXI working group seems to assume that their solution will be, for reasons other than performance, better than gzip. So they had to prove that they weren't worse than gzip, rather tahn havong to prove they were a whole lot better. 14:29:46 HT: My concern has been what this might mean for the future of XML. In the past we've said that we should deal with EXI in the same way as other character encodings. Originally came up in TP 3 years ago 14:30:14 HT: I originally was persuaded, but more recently have been less happy with this approach. I've looked at other approaches. 14:30:22 skw has joined #tagmem 14:30:23 skw has joined #tagmem 14:31:10 HT: I've looked at the true content-encoding in HTTP. SVG already does this. It describes how to serve compressed SVG. 14:31:36 HT: But now I don't think either of these is correct. I found 5 approaches in use. 14:32:23 HT: There are languages with media types. At the other end of the spectrum are general compression techniques, like gzip. These are indicated by content encoding 14:32:45 Stuart has joined #tagmem 14:32:46 Stuart has joined #tagmem 14:32:51 (HT is clearly reading from something; he will please mail it to us for the record) 14:33:09 HT: There are general purpose content transport languages, like ASN.1 and JSON. They tend to have little presence in the content type space. 14:33:48 HT: Then there are audio, video, image etc. containers that have content types, like png, jpeg, mp3, mpeg etc. 14:34:25 HT: Finally I concluded that application-specific content transfer languages, like PDF, MS word, etc. seem to be the right thing 14:34:43 q? 14:34:44 HT: PDF seems to have the right model. PDF is to PS and EXI is to XML. 14:34:56 skw has joined #tagmem 14:34:58 skw has joined #tagmem 14:35:20 Zakim has joined #tagmem 14:35:23 q+ to say ok, the PDF/postscript analogy makes sense; it suggests a marketing effort for EXI that dominates XML 14:35:31 HT: Neither the char set nor the content type are the right model because the are concerned with character sequences, but this is not the relationship that EXI has 14:35:40 q+ to mention schema-specific encodings. 14:36:21 HT: My feeling is that we should welcome this and bless it. We could say that although what you did is not what you said you were going to do but its still useful. 14:36:29 "You have done something different from what soem of us thought you were doing" 14:36:35 q? 14:36:50 ack danc 14:36:50 DanC_, you wanted to say ok, the PDF/postscript analogy makes sense; it suggests a marketing effort for EXI that dominates XML 14:36:52 HT: And as a result, although Dave's analysis is correct, it is not necessarily relevant to the current results 14:36:56 q+ to mention it seems that the EXI working group seems to assume that their solution will be, for reasons other than performance, better than gzip. So they had to prove that they weren't worse than gzip, rather tahn havong to prove they were a whole lot better. 14:37:02 q+ raman 14:37:06 HT: I conclude that we need a new media type. 14:37:45 Stuart has joined #tagmem 14:37:45 Stuart has joined #tagmem 14:37:47 DC: The relationship between PDF and PostScript is valid, but will take a marketing effort. PDF displaced PS 14:37:52 ack noah 14:37:52 Noah, you wanted to mention schema-specific encodings. 14:37:58 dorchard has joined #tagmem 14:37:58 q+ to come back on PDF analogy 14:38:38 NM: The EXI proposal had two parts. Certainly the media type covers part of this. But also, there is a schema-aware version. Not convinced that the media type applies to this latter case 14:38:46 q+ to look at .ps vs .pdf wrt big companies. 14:39:19 NM: It needs a media type, but that type doesn't encode the XML syntax. This is differnet from the non-schema aware version. 14:39:30 q? 14:39:33 SW: So there are two flavours? 14:39:39 (indeed, the schema out-of-band stuff has a very odd feel to it.) 14:40:04 skw has joined #tagmem 14:40:05 skw has joined #tagmem 14:40:08 NM: Yes, one transfers the entire info set, the other optimises the traffic by not doing that. 14:40:15 ack timbl 14:40:15 timbl, you wanted to mention it seems that the EXI working group seems to assume that their solution will be, for reasons other than performance, better than gzip. So they had to 14:40:19 ... prove that they weren't worse than gzip, rather tahn havong to prove they were a whole lot better. 14:40:43 TBL: Support Henry's analysis. The difference between the two flavours is whether or not it is self describing 14:41:01 (aha! Zakim lost its marbles.) 14:42:03 q+ To agree with Dan that the branding and marketing of this thing is crucial to understanding its impact 14:42:06 TBL: The working group felt that gzip had issues because of memory usage. My impression is that they didn't need to show that they had higher performance. 14:42:26 Stuart has joined #tagmem 14:42:27 Stuart has joined #tagmem 14:42:29 (why is it good enough to be in the ballpark? I'm lost) 14:42:31 TBL: Would like to see a scatter plot comparing performance with gzip 14:43:15 TBL: We thought they needed to show that there was an improvement in performance or compression, but it seems as though they felt that there were other trade-offs where they could show improvements 14:43:40 Noah, I'm confused by your remarks about the schema-informed stuff: "Schema-informed grammars accept all XML documents and fragments regardless of whether and how closely they match the schema. " 14:43:50 q? 14:43:51 q? 14:43:52 [from the WD: http://www.w3.org/TR/2007/WD-exi-20070716/#informedGrammars 14:43:56 ack raman 14:44:41 skw has joined #tagmem 14:44:42 skw has joined #tagmem 14:44:56 TVR: The PDF MIME type let's you hand off the content to a PDF processor. So I think that a MIME type of EXI would be the right thing 14:45:31 TVR: That would allow a processor to decompress the XML. The problem then is to work out who gets to process the results of the decompression 14:46:19 ack ht 14:46:19 ht, you wanted to come back on PDF analogy 14:46:25 TVR: The group decided that they needed something. We run the risk, if we say that they don't need this, that they will create something outside W3C. 14:46:58 Stuart has joined #tagmem 14:46:58 Stuart has joined #tagmem 14:47:02 HT: Dan pointed out the question of marketing this. I don't think this is any more of a threat to XML than is the semantic web. 14:47:23 (yes, I agree the story-telling tension is similar to the Semantic Web/XML tension.) 14:47:39 HT: Maybe the begining of this is to change the EXI acronym to be (and this isn't my suggestion) the efficient exchange of Infosets 14:48:06 (ah... so EXI is the modern FASL where XML is the modern s-expr?) 14:48:10 HT: It compresses object models, not character streams. It becomes a machine only syntax. 14:48:46 HT: The difference is that you don't hand-author postscript. However, people will continue to hand-author XML 14:49:13 q? 14:49:21 skw has joined #tagmem 14:49:22 skw has joined #tagmem 14:49:26 HT: Dan is correct, in that we will need to be careful how we position this. I've concluded that it doesn't threaten conventional pointy bracaket XML 14:49:28 q+ to test this analogy: s-expr:FASL :: XML:EXI ? 14:49:53 q+ 14:50:03 HT: People have argued that if you want to exchange structured data, you are better to create an OWL schema than an XML schema. 14:50:14 HT: This might be a similar situation. 14:50:34 q+ to protest that HT's suggestion that the sem web - xml relationship is similar ignores a huge diggerence in level 14:50:50 ack dorchard 14:50:50 dorchard, you wanted to look at .ps vs .pdf wrt big companies. 14:50:56 ack dorchard 14:51:05 SW: Summarising, I sense a possible feeling that we may want a more supportive response. I'd like to test that after draining the queue 14:51:06 (I'm not ready for a poll yet; I'm still swimming in options) 14:51:41 DO: The problem I have is that they haven't addressed my concerns. I don't know which constituents are being helped or hindered by this. 14:52:14 Stuart has joined #tagmem 14:52:15 Stuart has joined #tagmem 14:52:27 q+ to sympathize with DO's "who is the constituency?" question and to report an initial answer I'm getting: mobile carriers or something; I want to see the story, and it seems the EXI effort hasn't allocated the marketing resources 14:52:37 DO: The example of gzip being a problem on memory-constrained devices. Will that go away soon, or not? This kind of concern has not been addressed. 14:52:46 DO: I'm not u 14:53:00 s/u/yet ready to know where I stand on the issue 14:53:36 DO: The PS vs PDF issue is a good example. There are vendors who have not accepted PDF. Could we be in the same situation with this? 14:53:55 HT: I'm much happier that we have PDF than if we hadn't 14:53:59 skw has joined #tagmem 14:54:00 skw has joined #tagmem 14:54:14 TBL: I'd have been happier if PDF had been, for example, in W3C 14:54:22 q? 14:54:38 (we didn't point out the PDF/ps difference in "the rule of least power?" we should.) 14:54:44 TBL: Sometimes having 2 things can be ok. 14:54:52 ack noah 14:54:52 Noah, you wanted to agree with Dan that the branding and marketing of this thing is crucial to understanding its impact 14:55:06 and would we better to have still angle brackets than angle brackets + binary without "big vendor" support 14:55:27 NM: Expectations and positioning for this are crucial. The amount of stuff that would be affecte by this is orders of magnitude more than for postscript 14:55:33 ... view source. big. 14:56:38 NM: There has been work on optimised versions of XML from one vendor for three different situations. Suggests that one size does not necessarily fit all 14:56:50 Stuart has joined #tagmem 14:56:51 Stuart has joined #tagmem 14:57:27 NM: I haven't seen a demonstration of the proposal being able to fit all the scenarios. 14:57:33 q? 14:58:35 NM: In the web services world commercially, there is a lot of optimisation actually going on right now that might not addressed by EXI 14:59:30 skw has joined #tagmem 14:59:31 skw has joined #tagmem 14:59:33 NM: Henry pointed out that EXI is likely to happen anyway, so we should put our stamp on it. I'm ok with that as long as its positioned that it may work in some kinds of use cases 15:00:00 "they might give you a floppy disk and say 'I did it the new way.'" -- NM 15:00:14 NM: It does affect people's investment, because if people send you this stuff, you have to read it 15:00:19 (let's get that in our blog ^ ) 15:00:30 q+ to say IT IS XML! 15:00:37 NM: So the suggested name change is crucial, because it's not XML 15:00:47 ack danc 15:00:47 DanC_, you wanted to test this analogy: s-expr:FASL :: XML:EXI ? and to sympathize with DO's "who is the constituency?" question and to report an initial answer I'm getting: mobile 15:00:47 q? 15:00:50 ... carriers or something; I want to see the story, and it seems the EXI effort hasn't allocated the marketing resources 15:01:07 NM: If it is positioned as another general purpose XML it will be an issue 15:01:34 q+ to confirm that I don't know whether this will fly for the WG 15:02:05 Stuart has joined #tagmem 15:02:05 Stuart has joined #tagmem 15:02:05 DC: The constituency is unclear. People have said that mobile was the constituency, but I've not seen evidence. So if we are going to get seriously behind it, we need to understand that. 15:02:17 q? 15:02:48 q? 15:02:52 ack tim 15:02:52 timbl, you wanted to protest that HT's suggestion that the sem web - xml relationship is similar ignores a huge diggerence in level 15:03:12 NM: I don't think it solves the majority of use cases, so I would not want to see a big push behind this. If it helps prevent lots of different private compressions, then that's fine but I don't want to promote it until people understand the use cases to which it applies 15:03:33 q+ 1) it is XML; 2) we wouldn't use it for our application of binary; 3) what about non-mobile cases? 15:03:48 q+ to say 1) it is XML; 2) we wouldn't use it for our application of binary; 3) what about non-mobile cases? 15:04:05 skw has joined #tagmem 15:04:06 skw has joined #tagmem 15:04:13 q? 15:04:22 TBL: The picture that has emerged from Henry is that it is an alternative to XML. What is different is what comes out. Sometimes it is complete, and sometimes it requires context. But it is equivalent to the whole of XML rather than the semantic web 15:04:35 q+ to say 1) it is XML; 2) we wouldn't use it for our application of binary; 3) what about non-mobile cases?; 4) are there any big vendors that will do this? 15:04:56 TBL: I can't see the TAG needing to get in the way of this. 15:05:03 (apple plists are headed for sqlite, which is wonderful.) 15:05:38 TBL: The folks involved feel they need it, and as long as they don't misrepresent what it is for. 15:05:53 TBL: Agree about the MIME types 15:05:55 Stuart has joined #tagmem 15:05:55 Stuart has joined #tagmem 15:06:03 ack dor 15:06:03 dorchard, you wanted to say IT IS XML! and to say 1) it is XML; 2) we wouldn't use it for our application of binary; 3) what about non-mobile cases? and to say 1) it is XML; 2) we 15:06:07 ... wouldn't use it for our application of binary; 3) what about non-mobile cases?; 4) are there any big vendors that will do this? 15:06:45 (sqlite is wonderful. whether going from plists to SQL I'm ambivalent about) 15:07:11 DO: Henry, you said it was not XML, but it is. It's XML infoset. I feel sure it will be marketed as a replacement for XML. The danger is that there will be a tendency to diss XML 15:07:13 John Schneider is EXI's example of how your friends can be your worst enemy. . . 15:08:20 DO: Vendors tend to have internal formats used to save having to reparse as material is shipped around internally 15:08:47 skw has joined #tagmem 15:08:48 skw has joined #tagmem 15:08:59 DO: We looked at this and decided that there was no benefit to switching our internal format to EXI. 15:09:04 q+ 15:09:39 HST has always assumed that Mobile is the main client 15:09:40 DO: Are any of the big vendors going to take this up as a replacement. For example, would Adobe switch, would Nokia build this into their phones? 15:09:43 "would nokia build this into their phones?" is a very good question. 15:10:09 NM: We might, but it would probably be for engineering reasons, rather than the interoperability reasons. 15:10:42 NM: With XML, we do it because of the interoperability. Everyone else does it. 15:10:54 q+ raman 15:10:54 ack ht 15:10:55 ht, you wanted to confirm that I don't know whether this will fly for the WG 15:10:56 q+ raman 15:11:02 ack ht 15:11:25 q+ to point out that technical merits are very different from what people will use to market a given position --- I'll once again point to the html vs xhtml controversy. 15:11:31 Stuart has joined #tagmem 15:11:31 Stuart has joined #tagmem 15:13:01 HT: There is a real question about what the WG thinks it has achieved. I think that the mobile space is the one they've been eyeing. 15:14:04 skw has joined #tagmem 15:14:05 skw has joined #tagmem 15:14:24 q? 15:14:27 HT: We could frame this as a question to the group. We don't think this is a general purpose replacement for XML. It would be dangerous to promote it as a general archival format. There could be a place for this but not as a general purpose replacement for traditional XML 15:14:32 q- 15:14:39 ack raman 15:14:39 raman, you wanted to point out that technical merits are very different from what people will use to market a given position --- I'll once again point to the html vs xhtml 15:14:41 ack raman 15:14:42 ... controversy. 15:14:53 DO: I like the general thrust of what Henry says 15:15:30 Stuart has joined #tagmem 15:15:35 q+ to elaborate on the role of the TAG in the attention marketplace 15:15:36 I like the points that HT is making, and I do think there is tag agreement on that. 15:15:49 (can you write it down, DO?) 15:15:55 TVR: If there is a strong proponent of EXI then we won't be able to control attempts to market it as the alternative to XML. It could become a marketing buzzword fight 15:15:57 q? 15:15:58 q Rhys 15:18:19 RL: I'm not aware of any pressing issues in the mobile space concerned with a need for new ways of compressing XML content on the way to the device 15:18:43 RL: Typically, mobile networks are doing compression under the covers anyway. 15:18:53 NM: Are there issues of battery life> 15:19:08 q? 15:19:13 RL:I've not heard that, but maybe I'm not talking to the right people 15:19:50 ack danc 15:19:50 DanC_, you wanted to elaborate on the role of the TAG in the attention marketplace 15:20:21 DC: I'm not sure I heard Raman correctly. Did you say that if it's only a marketing issue we have nothing to say? 15:20:45 TVR: Not quite, just that we might find we don't have influence 15:20:53 DC: I think we can play a role 15:21:20 NM: We can, as the TAG, help W3C position this. 15:21:27 q? 15:21:41 DC: Also TAG members are well respected in the XML world. 15:22:28 DC: Tim, can you clarify what you said about the process? 15:23:16 TBL: We should not 'prevent' work like this progressing 15:23:45 DC: It is a decision that could be in the TAG space. It's a bet on where we think the technology is heading 15:24:10 ("mostly harmless" ;-) 15:24:42 ("mostly harmless" is my 2-word summary of NM's suggestion here. works for me.) 15:24:49 NM: I think it should come out, and from W3C, but as an interesting spec that supports some subset of use cases. It's around the edges of the stack, and is there for the people who can take advantage of it. 15:25:24 q? 15:25:26 q+ 15:25:27 NM: We need to help people understand that this is not a replacement for XML and doesn't require everyone to have a deserialiser for EXI 15:25:44 SW: What would the impact of this be on XML 15:25:47 q? 15:26:12 acj dorchard 15:26:13 q+ to think out loud about "mostly harmless"... which suggests closing this issue without further discussion, except perhaps to wish the EXI WG good luck. 15:26:15 NM: If it became pervasive it might influence how easy or hard future extensions might be 15:26:18 ack dorchard 15:27:12 DO: Overall, there is a stack of XML specifications. Maybe its getting to the stage where its no longer possible to roll out point solutions within the stack, because of interactions 15:27:44 (good point; EXI could fit into DSIG that way. hmm.) 15:27:48 DO: Maybe EXI is a kind of canonicalisation, in the example of signing XML. 15:28:03 DO: So EXI might actually help integration like this. 15:28:26 q+ to say the DSIG thought suggests adding a CR exit criterion of integration with XML sig 15:28:35 ack danc 15:28:35 DanC_, you wanted to think out loud about "mostly harmless"... which suggests closing this issue without further discussion, except perhaps to wish the EXI WG good luck. and to say 15:28:38 ... the DSIG thought suggests adding a CR exit criterion of integration with XML sig 15:28:46 NM: So that means that you'd have to freeze the EXI specification to see how well it's going to integrate with the rest of the XML stack 15:29:42 q+ to say what should the Technical Architecture Group say on this? 15:29:47 DC: So, a summary of this might be 'mostly harmless'. Dave mentioned EXI and Signature, another approach could be to add a CR criterion to make sure consistency with signature 15:30:13 q? 15:30:20 q+ 15:30:41 NM: My understanding is that there is an issue in the space of performance around canonicalisation for signature but that was not even in the EXI use cases 15:30:51 ack dorchard 15:30:51 dorchard, you wanted to say what should the Technical Architecture Group say on this? 15:31:49 DO: We've brought up a number of issues. I don't want to close this with no action. I think we should take a look at the technical proposal and to see how that affects aspects of the architecture of the web 15:32:43 TBL: Concerned that architecture for canonicalisation for signature may be wrong. The approach is based on worries that the signed version will be disrupted in transmission 15:32:46 I think there's a whole aspect of "binary" that result that is very interesting 15:33:07 Maybe have binary through more levels.. 15:33:18 TBL: The other approach is to put the signature outside the document, which might solve the canonicalisation problem 15:33:52 NM: I think the issue might be that you have to touch all the bits. 15:34:12 DO: Part of the problem is associated with extensibility and namespaces. 15:34:47 HT: Actually, the problem is that canonicalisation is underspecified. It's not a performance problem. It has been an interoperability problem. 15:35:25 HT: Canonicalisation has been trying to serve not only checksum creation, but also to be a way to compare XML documents 15:35:56 q? 15:36:33 HT: You would think that these would be the same. However, people have concluded that it would be better for a canonicalisation not to be constrained to have to produce well formed XML 15:36:55 HT: People have suggested that EXI might be a better target. 15:37:28 HT: Also people have suggested that a better approach might be to design something specifically for producing a byte stream for checksum creation 15:38:11 SW: What should our next aciton be? What do people think. 15:39:00 HT: We need to understand more about where the working group is before we can conclude what the best thing to do would be. 15:39:15 SW: Could we return to this on Friday. 15:40:15 ACTION: ht to liase with his contact in the EXI working group to get a sense of the group's current feeling 15:40:15 Created ACTION-71 - Liase with his contact in the EXI working group to get a sense of the group's current feeling [on Henry S. Thompson - due 2007-11-12]. 16:09:53 Topic: namespaceDocument-8 16:15:40 SW: Henry could you summarise where we are? 16:15:44 http://www.w3.org/2001/tag/doc/nsDocuments/ 16:16:27 HT: We discussed the draft while we were in Southampton. Feeling that it was almost complete, apart from two editorial notes 16:17:44 HT: First note: Namespaces are namespace documents, and we can return a representation from the ns URI. Other assertions are found by GRDDL/RDDL 16:17:52 Noah has joined #tagmem 16:18:33 HT: Another position is that the namespace and the document are completely and fundamentally different and so we should use 303 16:19:10 ("217 -- these are not the resources you're looking for" -- SKW) 16:20:00 HT: The third position is that sometimes puns are in everyone's interest and that we will use the same URI for both things 16:20:29 q? 16:20:58 q+ to ask for a specific example; can we talk about the usps example? or would somebody suggest another? 16:21:24 TBL: Agree with Henry that philosophically, the document and the namespace are different, but we are focussing on engineering. 16:21:27 q+ to clarify my position on difference between namespace and document 16:21:32 raman has joined #tagmem 16:22:03 HT: Tim is advocating the pun. 16:22:18 TBL: No, I'm saying that the URI is only the URI of the document. 16:22:33 q? 16:22:58 ack Noah 16:22:58 Noah, you wanted to clarify my position on difference between namespace and document 16:23:07 HT: We have a significant collection of published documents that imply that the namespace URI does not reference a document 16:23:38 I am not advocating a pun position. I amadvocating the namespace document position, which does not put any of the putative sets of names into the ontology. 16:23:59 NM: I believe that a namespace should be used as an information resource. I also believe that there is an ontological difference between this and the namespace 16:24:55 (this "french press release" story merits a blog article too.) 16:25:04 NM: Consider a press release. I access it and get it in French. I might conclude that the URI is for the press release in French. That might be the case, but it might not. This is the stuff we talked about in the generic resources finding 16:25:08 q+ raman 16:25:13 q+ 16:25:18 q- later 16:25:29 q+ to protest that thi style does not apeal to me at all 16:25:38 q-raman 16:25:43 ack timbl 16:25:43 timbl, you wanted to protest that thi style does not apeal to me at all 16:25:47 NM: The namespace URI is similar and we could apply the same approach, so there should be a URI for the generic resource. 16:26:21 DC: Could we use a specific example? 16:26:47 TBL: I want to talk about the namespace question, not the generic resources question. 16:27:04 TBL: We don't have any systems that use the concept of a namespace in their operation 16:27:40 q? 16:27:41 NM: I could create a system today that might want to ask question about the namespace, for example, what is the set of names in the namespaces 16:27:54 q+ to remind us of the difference between a namespace and a language 16:28:23 TBL: An OWL ontology allows you to get an answer to the question about what names are defined in an ontology. Why do we need another mechanism for namespaces? 16:28:51 SW: There was another use case for namespace documents, concerning other resources associated with the namespace. 16:29:35 SW: Seems as though there are two use cases here. There seem to be two sorts of characteristics for namespace documents 16:29:42 ack DanC 16:29:42 DanC_, you wanted to ask for a specific example; can we talk about the usps example? or would somebody suggest another? 16:29:59 DC: Can we pick an example to work on and walk through it? 16:30:38 HT: Let's try the post office example first. 16:32:54 raman has joined #tagmem 16:33:52 DC: There is a real ontology, and the namespace URI has a # on the end. The one in the draft does not have that. 16:34:26 HT: So does that mean that the RDDL is off? 16:36:15 HT: I'm not at all sure now that I want to assert that validation is against this document, its the elements and attributes in the namespace. 16:36:19 q? 16:37:03 HT: There is an implication that we are using the # vs. bare name when we want to distinguish between the document and the namespace 16:37:06 DC: Yes 16:37:41 q+ to talk about XML and RDF being differnet 16:37:42 HT: But the already published namespaces have the 'wrong' URI on this basis. 16:39:01 s/published namespaces/published XML language namespaces, e.g. http://www.w3.org/2001/XMLSchema,/ 16:39:33 ack ht 16:39:33 ht, you wanted to remind us of the difference between a namespace and a language 16:39:39 TBL: The RDF and XML arch are different. In RDF the ns is used to abbreviate the URIs. 16:40:05 HT: It's not namespaces that give meaning to the names that are defined in the namespace, it's the language. 16:40:18 (indeed; it's _languages_ that relate meaning to syntax, as per versioning discussion.) 16:41:11 (my tiny brain needs it projected) 16:41:53 HT: I think that for a namespace document what you want is references to other documents that contain the defintions for particular language versions, for exmple 16:41:59 s/exmple/example 16:42:21 q? 16:42:21 (I think s/a/b/ needs a / at the end) 16:42:24 ack noah 16:42:24 Noah, you wanted to talk about XML and RDF being differnet 16:42:32 s/exmple/example/ 16:42:52 NM: I don't think we've quite nailed the difference between the way that RDF and XML use namespaces 16:43:17 NM: XML ns gets you to a pair. RDF namespaces get you an expansion of a URI 16:43:22 q+ to propose a compromise, based on NM's observation 16:43:53 NM: Maybe need to be careful to distinguish the two cases. One possible issue is that one serialisation of RDF is XML 16:44:27 NM: Maybe we need to answer the questions twice, once for RDF and once for XML. 16:45:06 NM: The namespace definion from the XML namespaces document. 16:45:08 (I'm sympathetic to NM's suggestion that separate stories for XML and RDF might be worthwhile.) 16:45:47 HT: I propose to take Noah's proposal away and produce a new draft. 16:46:02 NM: Do we have the cart before the horse. 16:46:42 HT: I don't want to boil that ocean in this document. There will be differences in these two cases. 16:47:28 NM: There is a danger that you will tell the engineering story, and gloss over the interesting architectural question in the introduction 16:47:52 SW: Displays the webarch definition of namespace. 16:48:12 HT: We wrote a finding about this. 16:48:16 http://www.w3.org/2001/tag/doc/namespaceState.html 16:50:00 HT: Reads out the part of section 1 that covers the two perspectives 16:51:02 SW: The question this answered was if you add an element to a namespace should you use a different URI for it. 16:52:18 TBL: W3C has said that you can choose whether or not to use a new URI if you change a namespace 16:52:52 Action: ht to produce another draft of the namespaces document taking into account the difference between namespace usage in RDF and XML 16:52:52 Created ACTION-72 - Produce another draft of the namespaces document taking into account the difference between namespace usage in RDF and XML [on Henry S. Thompson - due 2007-11-12]. 16:53:33 scribe notes that the due date should be the end of the year. 16:53:46 So the compromise I have in mind to try is to say that we observe that the relationship between a namespace and namespace document may be understood in one of two ways, which in practice line up pretty well with the RDF and XML usages of namespaces 16:54:01 Topic: XMLVersioning-41 16:54:33 DC: NVDL is becoming increasingly important, so maybe we should do something on Action-16 16:54:38 ... to state what those two ways are, and to bless both of them in their appropriate spheres 16:56:11 SW: Action-48: Henry presented an expose of the work on modularisation 16:56:42 DO: I think Henry took an action to talk to schema 1.1 wg 16:57:59 http://www.w3.org/2001/tag/2007/10/25-minutes 16:58:44 ACTION-51 is done, then, yes? 16:59:19 SW: There has been feedback on Dave's document from Noah. 16:59:42 NM: There has been feedback from outside the TAG. We need to look at it. 17:00:41 DO: I could incorporate Noah's comments by Friday. 17:00:55 SW: How far did Noah get through the document? 17:01:18 NM: I got through most of the sections where Dave had made the main changes. 17:02:02 DC: I won't be there and would want to be there for this. 17:02:18 SW: We have the room for tomorrow morning. 17:02:57 Discussion about when to discuss this. 17:03:08 SW: 10:30 tomorrow morning 17:03:16 Tue, Nov 6 10:30am for versioning is in my calednar 17:03:30 RL: Have to give regrets for that session, have committments to MWI BP 17:06:24 SW: So we'll come back to this at 10:30 tomorrow. 17:08:32 Discussion about why there were no actions from the October 25th meeting on the modularisation work that Henry has done 17:09:20 HT: It sounds as though the XHTML 2 WG has the ball on this. I need to discuss this with Steven to judge the level of interest 17:09:42 SW: The modularisation has not been published yet has it? 17:10:04 HT: No, because I'm not sure what form it shoud be in. 17:11:35 Action: ht to contact the XHTML 2 WG about the fact that the TAG has been experimenting with modularisation 17:11:35 Created ACTION-73 - Contact the XHTML 2 WG about the fact that the TAG has been experimenting with modularisation [on Henry S. Thompson - due 2007-11-12]. 17:12:39 Topic: httpRedirections-57 ISSUE-57: 17:13:56 (I'm happy for this subgroup to start, provided (a) Alan is among the leads/chairs, and (b) TimBL can recruit another TAG member to participate. I'm not available, as much as I'd love to play.) 17:14:01 TBL: Maybe we should document what HTTP does, to try and provide a crisper definition for the semweb community. 17:14:48 TBL: The HTTP-bis group is starting up to document behaviour. Also some people would like to reinstate the link header 17:15:32 TBL: Could be dangers of incompatibility if we had different groups working in this area. 17:16:26 (-1 XG; XGs are for stuff that doesn't involve staff coordination.) 17:16:30 TBL: Would be good to discuss an appropriate way forward. Perhaps we could coopt people. Might be done in the sem web activity, perhaps as an XG or in the interest group. 17:16:40 SW: What is their main interest? 17:17:17 TBL: In terms of the interpretation of response messages, the only thing that could be used to infer interesting information is the response code. 17:18:24 TBL: telling the story that for a given method the response contains particular things that can be used in specific ways for RDF 17:18:43 TBL: There will be things that apply to multiple methods 17:19:18 q+ 17:19:28 SW: Do you see this as as document of some kind? 17:19:38 q- ht 17:19:52 TBL: Depends on where it is done. Could end up being a note for a WG or a TAG finding. 17:20:04 SW: So would that be something normative 17:20:37 q+ to re-iterate that WAI ERT has work in this area, and to note my own work in the area http://dig.csail.mit.edu/breadcrumbs/node/178 17:20:49 SW: The impression I get from sem web is that they are looking for something with normative force. 17:21:31 TBL: I'm a bit sceptical about basing any description on an ontology. I suspect that we'll end up explaining most of it in English 17:22:06 TBL: Also interesting that 303 was introduced for POST 17:22:16 q? 17:22:53 ack danc 17:22:53 DanC_, you wanted to re-iterate that WAI ERT has work in this area, and to note my own work in the area http://dig.csail.mit.edu/breadcrumbs/node/178 17:22:58 NM: Sometimes, Roy has noted a draft update to HTTP. Is there something coming 17:24:02 DC: I've been modelling HTTP in RDF for a long time. Long term interest, but I don't have time to participate 17:26:08 Discussion about what the forum for work on this sort of thing should be 17:27:01 TBL: How far did you get modelling this (HTTP caching) 17:28:23 DC: I wrote a talk on this. Shows a formal definition in LARGE for the caching model 17:30:21 raman has left #tagmem 17:31:46 http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70 17:31:49 s/LARGE/Larch/ 17:32:43 SW: Suggestion from Dan about leadership and some activity. 17:33:54 (I'm willing to take an action to talk to jonathan reese (sp?) about this) 17:34:07 TBL: Were the tech and society domain decide to pursue this, who else in the TAG would be interested in this? 17:34:43 (toe-in-the-water from SKW works for me) 17:34:54 SW: I would be interested in theory, but have to check commitments 17:35:47 trackbot-ng, status 17:36:35 NM: I'm wondering about this, but I'd have a lot to learn and I'm not convinced about the overall benefit 17:37:43 ACTION Stuart: explore TAG liason role to Subgroup to handle semantics of HTTP etc 17:37:51 ppht 17:37:57 ACTION: Stuart explore TAG liason role to Subgroup to handle semantics of HTTP etc 17:37:58 Created ACTION-74 - Explore TAG liason role to Subgroup to handle semantics of HTTP etc [on Stuart Williams - due 2007-11-12]. 17:38:47 rrsagent, make logs member-visible 17:42:17 rrsagent, make logs public 18:56:47 Stuart has joined #tagmem 19:06:48 Noah has joined #tagmem 19:07:20 ericP has joined #tagmem 19:07:26 Rhys has joined #tagmem 19:07:45 meeting: Joint meeting of W3C HCLSIG and TAG 19:07:48 timbl has joined #tagmem 19:08:29 DanC_lap has joined #tagmem 19:09:42 date: 5 Nov 2007 19:09:45 present: Alan Ruttenberg Tim Berners-Lee Rhys Lewis Jonathan Rhys David Booth Stewart Williams Eric Neumann Susie Stevens Eric Prudhommeaux Noah Mendelsohn David Orchard 19:09:55 scribe: Noah Mendelsohn 19:10:09 ht has joined #tagmem 19:10:20 s/Jonathan Rhys/Jonathan Rees/ 19:10:28 alanr has joined #tagmem 19:10:31 chair: Stewart Williams 19:10:41 dorchard has joined #tagmem 19:10:41 Norm has joined #tagmem 19:10:57 topic: Introduction to HCLS and topics of interest 19:11:43 JR: (Jonathan Rees) We are interested in HTTP Semantics, URI Resolution, meaning how do you get a definition etc. from URI, which by the way need not be an http-scheme URI. 19:12:23 JR: Is resolution deterministic 19:12:50 eneumann has joined #tagmem 19:12:53 SW: Are you interested in "information resources", "non-information resources", what's the difference, what are the definitions? etc. 19:12:58 JR: Yes, interested. 19:14:20 (aha... on the hcls list today... looking...) 19:14:24 http://sw.neurocommons.org/2007/uri-note/ 19:14:40 We are discussing http://sw.neurocommons.org/2007/uri-note/ 19:15:00 ah... "sustainable" is an interesting keyword 19:15:13 Susie has joined #tagmem 19:15:15 JR: Introducing HCLS, Science Commmons 19:15:35 -> http://www.w3.org/2001/sw/hcls/ W3C Semantic Web Health Care and Life Sciences Interest Group 19:16:13 JR: HCLS was started a little over 2 years ago, annual f2f meetings, ~48 members. Mix of academic, pharma providers. Alan and I are with Science Commons, which is a member of HCLS, but our interests are so aligned that we sometimes aren't careful which one we speak for. 19:16:59 JR: We want to make literature better connected with datasets, other journal articles, etc. Represents serious attention to the Semantic Web. 19:17:29 JR: Science Commons is a non-profit, funded (so far) by grants. Is a part of Creative Commons. Probably largest source of RDF on Web. 19:17:44 TBL: More than FOAF, DBpedia? 19:17:50 JR: Not sure. Was true earlier. 19:18:41 JR: We want to figure out how to make the Semantic Web work. 19:19:43 EN: (Eric Neumann) There's a lot of life sciences data already out there on the Web, a lot of standard terminology, but only limited use of Semantic Web and URI. We're trying in this note to get people to realize what's possible, and then to use it. A lot of groups are waiting to see what we come up with. 19:21:54 q+ to mention abstraction for lsids 19:22:03 ("insurance policy" another acknowledgement of the social side. good.) 19:22:32 JR: I want to do this now in part to give people an insurance policy that all of this stuff will really work and scale as massive deployment happens. Need a path starting from where we are. 19:23:34 JR: Before HCLS there was I3C and LSID. 19:23:51 (whoa... groundhog day... the 1st IETF WG on URIs was called IIIR I'm pretty sure, with the III expanding much like the I3C) 19:23:53 JR: LSID's have caught on mainly in smaller communities. 19:25:22 JR: The LSID work is important because it solves, or at least claims to solve, 5 problems in this space. So, that sets the bar in terms of peoples' expectations for what we need to do in a more purely http-based approach. 19:26:07 JR: We have a database of 300million triples. 19:26:26 AR: (Alan Ruttenberg) that's jointly hosted by HCLS and Science Commons. 19:26:51 TBL: How are the conversions done? One-time? 19:27:06 JR: No, it's scripted. Intended to be sustainable and repeatable. 19:27:52 JR: Some of this was demonstrated at the Banff Web Conference in May. 19:29:30 JR: Example: this plasmid was used in the research that's behind this research article. There are actually several facts in there, and we want them all to be available for query. 19:30:14 http://geneontology.org/ 19:30:39 q? 19:31:00 JR: We want RDF to be in published papers, as an alternative or supporting means of representing information. 19:31:42 AR: The goal is eventually that all scientific knowledge is available at your fingertips. Semantic Web is the only promising technology for doing it. It's a crazy, ambitious goal. 19:31:49 TBL: Is it linked data? 19:31:52 q? 19:32:03 q+ to talk about versioning, meaning and compatibility 19:32:31 AR: I don't conceptualize this as data, but rather as statements: things that are true, things that have been tried. My goal is for it to work in the tabulator, indeed sometimes better than tabulator itself can handle it now. 19:32:40 TBL: It's not linked data? 19:32:43 ack timbl 19:33:01 AR: Heading there, but some short term issues. For example, our 303's don't currently redirect to RDF. 19:33:08 TBL: SPARQL 19:33:21 AR: Yes, in fact focussing mainly on SPARQL. 19:34:15 AR: Our focus differs from tabulator's to some degree in our focus on scientific statements and the rigor with which they're made. Somewhat the difference between browsing and sending out an agent to, e.g. choose a medication for me. 19:34:25 q+ to talk about 1) versioning and 2)UrnsRegistries document 19:34:55 AR: Much of the criticism or analysis you've seen for me is motivated by the need for a greater level of accuracy than is required in browsing scenarios. 19:35:04 q? 19:35:11 AR: So accuracy of statements is very important. 19:36:36 JR: We recognize that there is a range of use cases for RDF. The spectrum runs from quick n dirty, which needs to get out quickly and me not be completely clean, to supplementary material on published articles. Similarly, the different consuming applications have a range of requirements for accuracy. We've focussed on a lot on where we see Semantic Web currently as being weakest. 19:37:29 q? 19:37:38 ack eric 19:37:38 ericP, you wanted to mention abstraction for lsids 19:37:43 (resolution?) abstractions: 19:37:43 protocol abstraction for LSIDs 19:37:43 protocol injections for fallback resolution for b0rken links 19:38:13 EP: (Eric Prudhommeaux) We have a couple of motivational abstractions in this paper. One is about protocols, discussing things like resolution. 19:38:39 EP: We also have protocol injections for fallback on how to resolve things where links are broken 19:38:45 "b0rken" intentional? 19:38:48 q? 19:38:49 q? 19:39:12 DC: You've told us a lot that I mostly agree with; are there questions? 19:39:21 DO: I'm really interested in questions of versioning. 19:40:18 AR: It's been a sore point. Everyone's wrestling with it. I could tell you what Open Biomedical Ontologies (OBO) is doing. 19:40:52 DO: We've been doing a 3 part draft on versioning in the TAG. Not done, but major pieces have been subject to repeated review. 19:41:04 AR: It would be interesting to sit down with you and go through use cases. 19:41:52 DO: Yes. The first document is a terminology document, the second focusses on forwards compatibility and what you have to do from the start to enable forwards compatibility. 19:42:16 AR: One of the first goals is to be able to say something about stability. E.g., I'd like to be able to say things like "this will stay the same forever" 19:42:33 AR: That's what you'd get to define. You'd be able to say what you mean by "the same". 19:42:57 AR: For example, part of the LSID contract is that the data portion stays the same forever. I'd like to be able to say that in RDF. 19:43:02 SW: The data portion? 19:43:18 http://www.w3.org/2006/gen/ont#FixedResource 19:43:19 JR: That which is identified stays the same. 19:43:25 AR: The metadata can change. 19:43:26 (I wrote an N3 specification of this "same bits forever" thing he's talking about...) 19:43:42 collapsefixed resource 19:43:42 Type expandloadedClass 19:43:42 Comment A resource whose representation type and content will not change under any circumstances 19:43:59 AR: I'd like to be able to say things like "This is a demo. These URIs are only guaranteed stable for 6 months" 19:44:01 "these are stable for the next 6 months, but after that, we're not promising anything" <- interesting use case 19:44:08 Draft TAG versioning terminology: http://www.w3.org/2001/tag/doc/versioning 19:44:11 q+ to ask about tradeoffs in making all this machine readable 19:44:32 q+ to point out that the concept f 'contract' sounds ike what I mean by 'protocol' 19:44:41 SW: Some of this is way above HTTP? 19:44:53 AR: You are saying things about resources accessed through HTTP. 19:44:55 Draft TAG versioning on forwards compatibility: http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies 19:45:03 SW: Do you need to find all this from HTTP headers? 19:45:19 AR: You need to find it all, but how is TBD. The Architecture Group may need to figure that out. 19:45:20 jar has joined #tagmem 19:45:41 q+ to illustrate life sci metadata 19:47:40 DO: The third part of the draft TAG finding is about evolution of XML-based languages. The 2nd related topic I wanted to ask about, and I know David Booth has looked at this, is about when and why to use http-scheme URIs. Henry Thompson and I have been working on that together. Your document says "use http URIs", but didn't see link to our draft. Curious as to why? 19:48:07 AR: I want to use http, but honestly am somewhat nervous about some of the issues. 19:48:10 q? 19:48:14 Several: We'd like to hear about that. 19:48:24 q- dorchard 19:49:21 q+ to ask about this "community interest" in recovering from 404; sounds like eminent domain 19:49:36 AR: An example of an issue is what to do when an http link "breaks". We think there's a community interest in restoring links even when the provider goes away. We've been working on standard rewrite rules for URIs to do this. We're getting concerns from LSID folks who say that the location independence they provide makes this less of a problem. 19:50:06 AR: We need metadata in lots of cases, but we're not sure you want 303 in all cases? 19:50:18 TBL: Do you mean 303 to something that would then go to 200. 19:50:26 Need to first be clear what LS means by 'metadata' 19:50:37 AR: I thought you didn't want everything to do 303, and that some people were advocating "#" 19:50:48 something like LSID that has both GET and GETMETA 19:51:04 (the 'doppleganger' is the magic of Web Architecture, to me) 19:51:06 AR: Third issue is what we call the "doppelganger" issue, which has to do with the dual role of the URI in "denoting" something and providing for access to it. 19:51:07 Henry and I are working on the URNsRegistries, and so any feedback the document and the rationale embodied in the document is very welcome. 19:51:19 q? 19:51:58 EN: Ever group needs to be clear on what they mean by metadata. Typically in life sciences, metadata is that which is not explicitly part of "that data record". Annotations are often viewed as metadata. That's to some degree historical. 19:52:54 EN: There tends to be a notion that there's a flexible part, that changes, and it sits next to a core part that needs to be understood from the start to be immutable. 19:53:47 AR: You are 1) denoting a thing and 2) getting information about it. 19:54:20 TBL: Thing? You can't publish "Eric" the person. 19:54:28 q? 19:54:30 AR: I guess we mean the minter of the URI. 19:54:31 ack eneumann 19:54:31 eneumann, you wanted to illustrate life sci metadata 19:54:38 ack Noah 19:54:38 Noah, you wanted to ask about tradeoffs in making all this machine readable 19:55:02 q- 19:55:31 q+ where we're going: TAG to understand some of the problem space. Then well before end, go meta and talk about how to cooperate going forward. 19:55:52 oops. not an irc pro. sorry zakim 19:56:05 q+ jar 19:57:19 Sometime an advantage of doing this is for agents t be able to help more .... to what extent did you expect htat t happen (?) 19:57:25 -- Noah 19:57:36 q- jar 19:57:46 NM: Curious about the cost/benefit of formalizing things like "my URI is going to get stale in 6 months because it was only for a demo". Will people write automated agents that will act on this. 19:58:10 q+ to point out that the concept f 'contract' sounds ike what I mean by 'protocol' 19:58:18 AR: Well, the LSID community finds the statement of immutability important. 19:58:23 NM: That's immutability. 19:58:37 (it's also called 'policy', I suspect; which should remind us that W3C just issued a WS-policy REC) 19:58:46 AR: And we've heard Cool URIs Don't Change. Having a way to say "I broke that rule" seems useful. 19:59:15 TBL: We in the consortium and the IETF talk a lot about protocols. When you talk about contracts, I think you mean something similar. 19:59:21 AR: I think so. 19:59:26 protocol = rules governing the way you talk (in some situation) 19:59:49 AR: There's a difference of emphasis. Historically, protocols have been somewhat rigid and unextendable. You can 19:59:55 AR: There's a difference of emphasis. Historically, protocols have been somewhat rigid and unextendable. You can't add a verb to HTTP. 20:00:02 Several: Sure you can. 20:00:26 TBL: It's perfectly reasonable to use ontologies to set out protocols, typically at a higher level than HTTP. 20:00:43 JR: There's a very close connection between definitions and protocols. 20:00:44 (indeed, RDF ontologies in the web are easier to update in a distributed way than centralized specs like HTTP, of course.) 20:01:01 JR: The protocol tells you what to do. 20:01:07 http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-01.txt 20:01:24 TBL: And the outcome. Bathroom protocol is "always use the smallest toilet paper roll, and you'll never run out of paper!" 20:01:47 AR: You should have something at the end of a URI 20:01:52 NM: It's good practice. 20:01:59 ack 20:02:01 ack danc 20:02:01 DanC_lap, you wanted to ask about this "community interest" in recovering from 404; sounds like eminent domain and to take issue with "all cases", given what Jonathan said earlier 20:02:04 ______________________ 20:02:04 ... about various levels of quality of curation and to react to "we need some guidance" with: well, you're at the leading edge; I don't think anybody has experience that you don't 20:02:06 ... have 20:02:12 q? 20:02:21 semantic web protocols end with understanding. outcome is getting the right drug prescribed. 20:02:32 DC: First thing: you said you didn't have a title, but I like the word sustainable that you have in your working title. 20:02:55 DC: I like your reference to "insurance policy", which is a use case, which is good. 20:03:16 DC: The 404 stuff sounds like emminent domain. 20:03:28 DC: Tell me about qualities of curation. 20:03:35 JR: We're still working on that. 20:03:51 DC: The Web itself scales from informal connections between a few people, up to national libraries. 20:03:57 AR: Mainly we're aiming at shared stuff. 20:04:07 DC: Be careful, a lot of important stuff is done, you know... 20:04:26 DC: You're asking for guidance...you seem to be on the leading edge yourselves. 20:04:32 JR: Who said we needed guidance. 20:04:35 q? 20:04:39 DC: He did (pointing to AR) 20:04:46 JR: We asked for help, not guidance :-). 20:04:56 ack timbl 20:04:56 timbl, you wanted to point out that the concept f 'contract' sounds ike what I mean by 'protocol' 20:05:12 TBL: I think we've gone a round of agreeing on a lot of stuff and philosophy. Maybe it's time to get more specific. How can we help. 20:05:36 AR: Say we wanted to reimplement LSIDs, with the constraint that data portions need to be unchanging while metadata changes. 20:05:51 q+ to offer TAG review of drafts, use cases, and test cases 20:06:30 JR: We could come up with our own solutions without the TAG. We'll be doing the work in any case. We want to figure out how to have the most influence, and doing this with W3C seems to promote a lot of good network effects. 20:08:03 (conversation last summer... was fun enough for a blog item...) 20:08:37 (... http://dig.csail.mit.edu/breadcrumbs/node/178 ) 20:09:25 JR: The TAG's resolution is helpful because it gives a point of reference. So, having formal TAG resolutions is helpful in getting attention for things like this. So, if we could 3 or 4 more such things, that would be useful. 20:09:49 agenda? 20:11:18 q? 20:11:31 ack danc 20:11:31 DanC_lap, you wanted to offer TAG review of drafts, use cases, and test cases 20:11:32 q+ 20:11:36 q+ 20:12:06 DC: You folks already have a W3C interest group. You can publish Notes. The TAG can comment on those. 20:12:22 EP: You can give us thumbs up or thumbs down? 20:12:27 DC: Yes, if we choose to review them. 20:12:59 AR: I think Jonathan and I seemed interested in the notion of a separate Semantic Web focus group that might work more directly with you all. 20:13:19 AR: We can both learn from you, and bring issues that might add perspective on the Semantic Web as a whoel 20:13:26 s/whoel/whole/ 20:13:39 ack alan 20:13:41 q+ to consider uris for "real-world entities": genes, species, chemicals, etc 20:13:46 AR: We'd like to see a more focussed effort by the TAG on Semantic Web. 20:13:46 ack tim 20:13:49 ack tim 20:14:37 TBL: Having other people write things, do an end of day thumbs up/thumbs down seems the wrong model. Ongoing collaboration seems better. The group seems reasonable to me. 20:15:13 q+ to get some hard work out of the way 20:15:30 TBL: A danger is failing to focus the group sufficiently narrowly. Risk is that the group tries to do everything. One way to do it would be to take the existing draft it would bound the scope. 20:15:37 AR: It's already quite broad in scope. 20:15:50 SW: Yes, that covers a lot of the hard problems. 20:16:12 AR: There are other possible concrete goals, such as reproducing what LSID wanted using http. 20:16:14 q? 20:16:45 SW: I'm attracted to trying to pick up something small. We also need to figure out what next steps will be. 20:16:47 ack Danc 20:16:53 ack danc 20:17:42 DC: Just realized that this is in some sense the same thing as Tim's call to do a group to formalize HTTP. 20:18:11 DC: I think you should set up whatever's convenient. I >really< wish I had the time to be very active in it. 20:18:20 q+ 20:18:26 TBL: This morning Dan reminded us of older work he did on formalizing HTTP in Larch. 20:18:40 http://www.w3.org/2000/Talks/www9-larch/all.htm 20:20:03 EN: Regarding Information Resource vs Non-Information Resource: there is already an infrastructure out there for naming genes, and people use it. They will all use a standard name. They pretty much agree on reference the real actual (non IR) gene. 20:20:19 EN: We could in theory, if we had a good model, map their existing work to URIs. 20:20:21 (I think the outcome of the protocol we're talking about here is that people happily use each other's names.) 20:20:38 (a little like currency) 20:20:47 (so we're designing an economy.) 20:21:07 EN: Also, the chemistry folks are proposing URIs for their compounds using info: URIs. 20:21:11 list of major trouble spots with URI note is here: http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Recommendations 20:21:43 EN: The suffixes are International Chemical Identifier strings, which has everything you need to specify the structure. 20:21:51 Someone?: It's like data: 20:22:01 AR: Not data: because it's not data. 20:22:14 TBL: Yes, but similar in that the identifier conveys that which is identified. 20:22:17 (hmm... data: sounds right in that it's like immediate mode addressing in assembler, but... hmm...) 20:23:16 NM: You said it has things like weight. What if they mis-estimated the weight. Does the identifier change? 20:23:22 EN: The ICI changes. 20:23:41 TBL: Suppose I were to get ici.org.... 20:23:43 (this sounds like one of the few reasonable uses of info: or tag: or the like.) 20:23:51 JR: They could have done that, but chose not to. 20:24:28 EN: The discussion is still ongoing. The International Union of Pure and Applied Chemistry would be involved. 20:24:40 http://www.iupac.org/inchi/ 20:24:54 q? 20:25:05 http://bio2rdf.org/geneid:15275 20:25:16 AR: Interesting to ask why they've focussed on info: 20:25:41 TBL: One of the things you could do, is grab a domain and compete. 20:26:13 JR: People don't want to compete. The id's are for the benefit of the community, not the publisher, but the community isn't organized enough to maintain the domain. 20:26:45 http://www.chemspider.com/ 20:27:30 JR: Technically this is all very easy, but getting people to trust that you'll hold a domain forever is harder. Rightly or wrongly, info: is generating that trust. 20:27:46 DC: You're trusting that nobody squats on info: 20:28:05 see also chemspider: http://www.chemspider.com/InChI=1/C17H13ClN4/c1-11-20-21-16-10-19-17(12-5-3-2-4-6-12)14-9-13(18)7-8-15(14)22(11)16/h2-9H,10H2,1H3.html 20:28:19 q? 20:28:34 q- eneu 20:28:48 alanr has joined #tagmem 20:28:48 DC: Let's drill on this. Let's say you tried to force someone to zap the list of scheme names. IETF would appoint someone else. 20:29:11 ack eneumann 20:29:53 ack eric 20:29:53 ericP, you wanted to get some hard work out of the way 20:30:29 EP: Thought I'd ask what would be the hardest thing we could try to do in the room. One would be to mesh the terms in the document with TAG's terminology. 20:30:39 SW: TAG hasn't read the document. 20:30:55 TBL: I read half the document, and the only one I objected to was "locator" 20:31:15 Zakim, ack me 20:31:15 I see jar on the speaker queue 20:31:31 JR: I just need a word for a URI has http or https, and known not to have a #. 20:31:44 NM: Is it the base for one with a #? 20:31:50 JR: No. 20:32:02 JR: I could change it to fragmentless, http URI... 20:32:43 TBL: The history is that "locator" and URL are criticised as being fragile against relocation of the resource. 20:33:09 JR: I struggle with Name vs URI. 20:34:22 q? 20:34:30 TBL: Do you have a way of pointing to metadata? 20:34:32 s/ICI/InChI 20:35:46 q? 20:37:10 JR: There's a concern that both # truncation and 303 are both heuristics in that the server you're talking to may or may not be following best practices. We'd like to have a conversation about that. If you could know whether what you're talking to does best practices, that would help. 20:37:21 q+ to talk about best practice signalling 20:37:33 SW: Can you illustrate non-determinism? 20:38:11 JR: I get a 303. I follow it. That's unpredicatble. No defined protocol, except with prior knowledge of the server. RDF may not refer to what I was asking about. 20:38:48 DC: That's like asking about not obeying the law. 20:39:18 Noah: We've been taking status code and gradually clarifying 20:39:23 q? 20:39:25 q+ 20:39:29 ack jar 20:39:34 ... also introducing new status codes to solve specific problems 20:39:40 q+ to say if, when we push on 303, we find we don't have consent of the governed, we'll have to do over 20:39:56 ... if we'd done that for this problem, i think we wouldn't be having this conversation 20:40:08 Q+ 20:40:15 q+ 20:40:26 ack Noah 20:40:26 Noah, you wanted to talk about best practice signalling 20:40:54 NM: I think this is aggravated by the fact that we've done so much in the style of clarifying use of already-deployed HTTP status codes and headers, vs. defining new ones which any reasonable person would use only in the exact way we suggest. 20:41:05 q? 20:41:12 JR: Yes, that's the crux. People have other reasons for using some of this. 20:41:40 q+ DavidB 20:41:43 q- later 20:41:49 q+ 20:41:57 ack davidb 20:42:09 DB: (David Booth) I'm intrigued at subgroup idea. Would like to know who and how. 20:42:10 ack timbl 20:42:12 TBL: I'm in. 20:42:33 q+ to nominate EricP to make a mailing list 20:42:40 TBL: But realistically time may be an issue. 20:43:00 q? 20:43:48 TBL: We were talking about protocols. I'm concerned socially and technically about a notion that we'd have a flag saying "I'm one of the subset of deployers who really implement the architecture". 20:43:57 q+ 20:44:25 TBL: The only servers sending 303's in response to GET, almost without exceptions, are doing it for semantic web reasons. 20:44:48 JR: There are other examples. 20:44:53 ack danc 20:44:53 DanC_lap, you wanted to say if, when we push on 303, we find we don't have consent of the governed, we'll have to do over and to nominate EricP to make a mailing list 20:45:10 DC: If when we push on 303, we don't have consent of governed, we have to redo 20:45:17 q+ to talk about rfc 2616 20:46:46 TBL: FOAF has a protocol. I don't see why there shouldn't be analagous protocols for Life Sciences. We need to make sure you get for free what you can from Web Arch, and what you define is consistent. 20:46:50 ack alanr 20:46:50 ack alanr 20:47:25 q+ to ask if it's harder to invent a new status code than to re-interpret 303 20:47:41 AR: The things we see in the Web Architecture aren't solid enough on the Web Architecture side. 303 says "See other", it doesn't say RDF should be there or what that RDF should be about. We need something you can rely on. We need a name for what you'd like to rely on. 20:47:49 ack Stuart 20:47:50 ack Stuart 20:47:59 SW: I was thinking "this is the Web, this is a fact of life 20:48:12 JR: But you can give names to layered protocols like GRDDL. 20:48:24 q? 20:49:03 ack Noah 20:49:03 Noah, you wanted to talk about rfc 2616 20:51:07 q+ 20:51:12 (the charter of the new HTTP WG is conservative; it's not supposed to do new features, but just to clarify.) 20:52:33 NM: If 303 really means "use this only for Semantic Web to return RDF about the redirecting resource", then RFC 2616 should say that. If 303 really means a looser "see also", then we should acknowledge that getting a 303 only leaves open the possibility that you'll get the RDF you need there. 20:53:23 q? 20:53:37 NM: That said, I also think it's crucial that the Web is a latebound, discoverable mechanism. The way you find what's out there is to interact with it. Trying to get early warning about what you'll get is just asking for hints (not always a bad thing, but I don't want to lose the ability of any HTTP resource to return any media type it likes...modulo accept headers, etc.) 20:53:50 q+ 20:54:28 q+ to say that I can imagine requirements that 303 doesn't meet, but I haven't heard them yet; what I'm hearing is a request for some feature that guarantees that noone will ever like or make a mistake 20:54:38 some amount of effort in (re)defining 303 for our special case 20:54:38 teaching your server to respond with a 303 20:54:39 if 303s conflate 200s and 401s, can we live with that 20:55:22 EP: There's some effort needed to teach serves to send 303 20:55:30 EP: There's some effort needed to teach serves to send 303's at the right times. 20:55:36 DC: Taken a long time. 20:55:55 oh... it's purl.org servers 20:56:35 EP: There's the issue of having decided to use new code vs. 303. I haven't heard any discussion of whether we needed status code or not. Seems to conflate 200 and 401s. 20:57:03 (I have a worry about OpenID's use of http 200... sorta like the hotel internet login problem.) 20:57:11 NM: (mumbles) I've always wondered whether it should have been a header. 20:57:14 EP: Yes. 20:57:39 TBL: What if you ask for all of wikipedia, which is too big. I tell you you're not allowed to have it all. 20:57:45 EP: How do I tell you all that? 20:57:48 TBL: RDF. 20:57:55 q? 20:58:01 ack me 20:58:01 ericP, you wanted to ask if it's harder to invent a new status code than to re-interpret 303 20:58:01 ack eric 20:58:05 ack alan 20:58:17 q- 20:58:40 JR: Is the only action item for me to set up a meeting with Tim and David 20:58:52 DC: I think we need a mailing list. Need a name the baby contest. 21:00:29 awwsw 21:01:13 public-awwsw 21:12:41 skw@hp.com 21:12:51 rhys@volantis.com 21:13:05 ACTION: Alan Ruttenberg to set up biweekly teleconferences on HTTP semantics to be held alternate Tues mornings starting 13 Nov. 21:13:05 Sorry, couldn't find user - Alan 21:20:37 jar@creativecommons.org 21:20:37 alanruttenberg@gmail.com 21:20:37 skw@hp.com 21:20:38 rhys@volantis.com 21:27:49 ADJOURNED 21:29:55 alanr has joined #tagmem 21:36:29 DanC_lap has joined #tagmem 22:25:36 Norm has left #tagmem 22:40:35 timbl has joined #tagmem 23:01:47 ericP has joined #tagmem 23:12:15 Zakim has left #tagmem