06:55:50 RRSAgent has joined #owl 06:55:50 logging to http://www.w3.org/2008/10/23-owl-irc 06:56:07 Zakim, this will be owlwg 06:56:07 ok, pfps; I see SW_OWL(F2F)2:30AM scheduled to start 26 minutes ago 06:56:21 RRSAgent, make records public 06:56:33 ScribeNick: pfps 06:56:36 Elisa has joined #owl 06:56:59 elisa? 06:58:12 SW_OWL(F2F)2:30AM has now started 06:58:19 +Elisa_Kendall 06:58:25 hi 07:04:19 IanH has joined #owl 07:06:56 bcueencagrau has joined #owl 07:07:07 sandro has joined #owl 07:07:35 MarkusK_ has joined #owl 07:07:40 IanH: Welcome (to ...) 07:07:51 zakim, who is here? 07:07:51 On the phone I see Elisa_Kendall 07:07:52 On IRC I see MarkusK_, sandro, bcueencagrau, IanH, Elisa, RRSAgent, Zakim, pfps, ivan, trackbot 07:08:37 wallace has joined #owl 07:10:20 PRESENT: Ian, Boris, Peter, Bernardo, Sandro, MarkusK, m_schnei, Bijan, Evan, Ivan 07:12:45 m_schnei has joined #owl 07:12:49 zakim, call Riviera_B 07:12:49 ok, sandro; the call is being made 07:12:51 +Riviera_B 07:14:09 dom has joined #owl 07:14:09 Sandro: nothing on local arrangement 07:14:30 IanH: introductions 07:14:40 ...: Hi, I'm me 07:14:42 zakim, dial Riviera_B 07:14:42 ok, ivan; the call is being made 07:14:43 +Riviera_B.a 07:15:03 dom has left #owl 07:15:31 bmotik has joined #owl 07:15:51 Observers - Henson Graves, Jeremy Carroll 07:16:09 Observers: Henson_Graves, Jeremy_Carroll 07:16:41 http://www.w3.org/2007/OWL/wiki/Timeline 07:16:42 IanH: Timeline (follow link in agenda) 07:17:13 IanH: I put a real timeine (not T0+) 07:17:38 IanH: We are about 2 months behind the scheduled time for Last Call 07:17:53 IanH: It thus would be good to move forward with due haste 07:18:43 Bijan: The schedule was designed to be aggressive (but with a bit of slack) 07:18:56 Sandro: The slack is ... two months 07:19:09 Topic: Document Status 07:19:19 Polycom: Beep 07:19:34 IanH: This section is intended as a review 07:19:45 IanH: Can the editors say the status 07:19:45 -Riviera_B.a 07:19:49 zakim, who is on the call? 07:19:49 On the phone I see Elisa_Kendall, Riviera_B 07:20:23 Boris: Syntax is up to date - there are some issues that will impact it 07:20:42 IanH: There has been internal review (for last PWD) 07:20:47 q? 07:20:55 Ivan: There has been no major external comments 07:21:03 zakim, who is here? 07:21:03 On the phone I see Elisa_Kendall, Riviera_B 07:21:04 On IRC I see bmotik, m_schnei, wallace, MarkusK_, sandro, bcueencagrau, IanH, Elisa, RRSAgent, Zakim, pfps, ivan, trackbot 07:21:09 Bijan: Does current syntax document meet Evan's needs 07:21:29 Evan: Way better than it was - usable - not great because of organization 07:22:00 Evan: Reorganization is currently for the spec/implementation, not users 07:22:15 Bijan: Not explicitly - we did have discussions on the order 07:22:29 s/Reorganization/Organization 07:22:46 Bijan: There are various organizations of reference docs in the literature 07:22:59 Boris: Currently Syntax is a *reference* document 07:23:00 Zhe has joined #owl 07:23:34 Evan: Quick Reference Guide could be used as an index 07:23:47 q? 07:24:04 Bijan: Primer can serve as another "index" 07:24:42 Bijan: Three "indexes" - ToC, QRG, Primer 07:24:50 + +1.978.692.aaaa 07:24:57 q? 07:25:05 Evan: The problem is using it as a reference 07:25:13 zakim, +1.978.692.aaaa is me 07:25:13 Evan: The ordering is wrong 07:25:13 +Zhe; got it 07:25:19 Boris: What is needed? 07:25:20 Hello Zhe! 07:25:25 zakim, mute me 07:25:25 Zhe should now be muted 07:25:28 Hi Ian! 07:25:41 q? 07:25:48 Evan: Things related to object properties grouped together 07:26:11 Boris: But what about domain axioms - they are related to both classes and object properties 07:27:41 q? 07:27:41 Christine: What is under discussion now? 07:28:09 q? 07:28:11 Bijan: We are now discussing the Syntax document - but are also pulling in relationships to other documents 07:28:47 Bijan: Old reference has informal discussions, which are not in the QRG 07:28:59 PRESENT: Ian, Boris, Peter, Bernardo, Sandro, MarkusK, m_schnei, Bijan, Evan, Christine, Rinke, Ivan 07:29:04 q? 07:29:11 IanH: A complete redesign of Syntax is a major effort 07:29:12 bmotik has joined #owl 07:29:39 Evan: A complete redesign is not in the cards 07:30:00 Evan: I'm fine with using the Quick Reference Guide as the index to Syntax. 07:30:05 q? 07:30:06 Evan: A reference index is needed - either QRG or part of the document 07:30:40 IanH: OK, syntax is in pretty good shape, modulo outstanding issues and perhaps an index 07:30:49 SubTopic: Semantics Document 07:30:59 q? 07:31:13 Boris: Similar status to syntax - up to date - outstanding issues may need changes 07:31:35 bijan has joined #owl 07:31:38 pfps: It's our contention that the Direct Semantics current correctly describes the meaning of OWL. 07:32:02 ian; Finished, modulo outstanding issues. 07:32:05 SubTopic: RDF Semantics 07:32:06 q? 07:32:15 Michael: RDF Semantics is a bit behind 07:32:18 s/ian;/ian:/ 07:32:30 Michael: There are a couple of minor things that need to be added 07:32:43 Michael: The two documents are structurally aligned 07:33:31 q? 07:33:44 Michael: Outstanding issues - correspondence theorem, test cases that exercise rdf semantics 07:33:51 m_schnei: the correspondence theorem proof still needs work. 07:34:10 Bijan: Do we believe that the theorem is correct - if so then we should be able to go to last call - if not then we need to worry 07:34:19 q? 07:34:32 Michael: I believe the theorem and that it is a good as we can get 07:34:55 bijan: Are any proof errors such that the language would have to change? 07:35:00 q? 07:35:05 m_schnei: I don't think the language will have to change. 07:35:28 Bijan: Do you think that the semantics is OK 07:35:29 Rinke has joined #owl 07:35:35 Michael: 95 per cent 07:35:56 Subtopic: Conformance and Test Cases 07:36:07 IanH: This could be more contentious 07:36:15 Ivan: We need more test cases 07:36:34 q? 07:36:42 IanH: Mike Smith wants to participate 07:37:00 Bijan: When I wanted to submit test cases the structure wasn't redy 07:37:12 Ivan: What is the experience of the OWL 1 test cases 07:37:47 Bijan: They are great, much better than before, they help a lot in checking initial part of implementation 07:38:13 q? 07:38:16 Markus: Most OWL 1 test cases have been copied over 07:38:35 Ivan: We might only need tests for the new features 07:38:49 Bijan: We could do more, but getting to the OWL 1 level is adequate 07:39:17 IanH: There was also fitting into Lite, DL, Full, so the tests need to be remarked 07:39:33 q? 07:39:44 IanH: We also probably need test cases to check the boundaries of the profiles 07:39:46 Test cases http://www.w3.org/2007/OWL/wiki/Test_cases 07:40:08 This page contains links to lists showing all test cases, by various criteria 07:40:59 Pfps: What about the status of T&C itself 07:41:09 Bijan: We will ask for tests at OWLED 07:41:22 Ivan: We need test cases ready for CR 07:41:41 Bijan: Not so - test cases could come out of CR - we need a reasonable set going in 07:41:45 q? 07:42:23 Jeremy: OWL 1 test cases lagged going into LC by two months 07:42:33 q? 07:42:55 Sandro: At some time there has to be a set of approved test cases 07:43:10 IanH: Mike Smith wants a process for approving new test cases 07:43:27 Sandro: Initially by hand, then we can use implementations to help approval process 07:43:51 Jeremy: OWL 1 document included the process for approving test cases 07:44:20 IanH: Conformance part has been approved - and has no outstanding issues 07:44:32 Subtopic: RDF Mapping 07:44:39 IanH: What about RDF Mapping? 07:45:10 Boris: Same status as Syntax and Semantics - up to date - some outstanding issues 07:45:23 q? 07:46:13 Ivan: Looking at the QRG there appear to be some mismatches between functional and RDF syntaxes 07:47:01 q? 07:47:27 Boris: There are reasons for some of the mismatches 07:47:36 q? 07:47:44 ACTION: pfps to check differences between functional and RDF syntaxes 07:47:44 Created ACTION-232 - Check differences between functional and RDF syntaxes [on Peter Patel-Schneider - due 2008-10-30]. 07:48:12 q? 07:48:19 Ivan: also XML syntax 07:48:54 Bijan: XML syntax mirrors functional syntax 07:49:04 Subtopic: XML serialization 07:49:17 schneid has joined #owl 07:50:13 q? 07:50:27 Bijan: Document is up to date - potential outstanding issues 07:50:49 Bijan: Would be nice to have a non-normative RelaxNG syntax 07:51:10 q? 07:51:26 Bijan: This would an editorial addition - non critical - could even be after last call 07:51:49 q? 07:52:20 Bijan: Issues with aspects of design - too verbose - need to check with Matt Horridge 07:52:42 IanH: There was a query from Alan related to the MOF metamodel - can we generate the syntax from the MOF? 07:53:25 What would be generated from the MOF metamodel is XMI, which is an OMG specification for XML schema interchange 07:53:32 Bijan: Not a good idea - no evidence that it would work - know that conversion to RelaxNG works 07:53:46 Bijan: MOF conversion to XML might result in an unreadable schema 07:53:58 Boris: Could end up very close 07:54:06 This could be mapped to various other surface syntaxes in an automated way 07:54:28 q? 07:54:41 Bijan: I want to see the output before I determine whether it is a good idea 07:55:02 Sandro: We can just wait until someone comes forward wanting this, and see if they're offering to do it. 07:55:24 Elisa: Lots of tools generate XML Schema from a metamodel - could be verbose 07:55:32 q+ 07:55:36 elisa: The XMI -- the automatic XML schema -- will be generated automatically by any decent UML tool -- but the XMI has extra cruft, which you'd have to map out of it. 07:55:51 q? 07:55:56 Elisa: What does the WG want to do with the result? 07:56:08 q- 07:56:35 Boris: Why do we want XMI? We then get an automatically-generated syntax 07:56:47 Boris: Depends on result of metamodel issue 07:57:17 Bijan: The question is whether this would result in a better schema. More accurate, ...? 07:57:21 Bijan: I can see point related to above claim. However, is the result a better schema? 07:57:52 Bijan: I would prefer RelaxNG but I'm not proposing to change at this point. 07:57:59 Bijan: We need to be sure of the benefit. 07:58:24 Boris: Peter Hasse sent me an automatically generated schema - it wasn't pretty. 07:58:52 Boris: Peter Hasse said that the generation can be controlled, so maybe a good schema could result 07:59:15 Boris: In any case this depends on the metamodel issue and then a benefits analysis 07:59:21 Bijan: Agree 07:59:35 IanH: Agree and also worry about timeline 07:59:45 Bijan: Can we test whether our schema matches the metamodel 08:00:09 Elisa: Yes, but I'm not up on the tools - I do know someone who knows how to do this 08:00:26 Bijan: Testing our Schema would be a good idea 08:00:47 q? 08:01:16 Elisa: This can also be a debugging tool 08:01:52 Elisa: ECLIPSE has tools that help working on ontologies 08:03:19 Evan: The tools check XMI not Schema 08:04:06 Bijan: But tools turn metamodels into XML Schema - what about doing the reverse? 08:04:31 Evan: The tools result in ugly schema 08:04:41 Bijan: So there are no recognizers? 08:04:55 wikipedia says "exchanging files between UML modeling tools using XMI is rarely possible." 08:05:18 q? 08:05:40 Boris: If we can automatically generate a nice Schema from the metamodel then we get automatic correspondence 08:05:53 (sandro, that's my personal experience as well) 08:06:25 q? 08:06:36 Bijan: Correctness (consistence) is the only benefit, I believe the schema over the metamodel 08:07:17 Sandro: If what Boris is saying works, then we get some increment to confidence 08:07:25 IanH: Not critical path 08:08:03 Rinke: There are tools that generate metamodel from XML Schema 08:08:07 Sandro: If we can generate a schema from the metamodel, then run it against all the test cases, that would be a nice validation of the metamodel. 08:08:16 IanH: Also a good idea, but not on our critical path 08:08:27 Evan: What is the canonical form of an OWL 2 ontology 08:08:51 Boris: The metamodel (but this is not completely formally defined) 08:09:33 Subtopic: Profiles 08:09:33 Boris: the metamodel -- in natural language, UML, functional syntax etc -- spread through all these bits -- that's the metamodel, and it's the canonical form. 08:09:47 Boris: Up to date - some outstanding issues 08:09:57 q? 08:10:11 Bijan: What about descriptive stuff on the various profiles? 08:10:25 IanH: I added some of this stuff - it is controversial 08:10:52 PRESENT: Ian, Boris, Peter, Bernardo, Sandro, MarkusK, m_schnei, Achille, Bijan, Evan, Christine, Rinke, Ivan 08:10:54 Ivan: Want full grammars for each profile 08:10:57 Editor's Note: This appendix will contain the full grammars of each of the profiles. The grammar will be completed when the technical work on each of the profiles has been finished. 08:11:01 q? 08:11:10 http://www.w3.org/2007/OWL/wiki/Profiles#Appendix:_Complete_Grammars_for_Profiles 08:11:17 Boris: Editorial note - will be done before Last Call - don't want to do before final changes 08:11:23 Ivan: What about Theorem 1 08:11:41 IanH: Up for discussion later 08:11:50 IanH: Some issues related to RL 08:12:00 q? 08:12:04 Subtopic: Primer 08:12:23 Bijan: I'm waiting for the other documents to stabilize 08:12:41 Bijan: I might want to change the example - traditional families might be controversial 08:13:17 Ivan: For me the example works - I propose not to change unless there are major objections 08:13:52 q? 08:14:27 Sandro: Stay biological - social is controversial 08:15:09 Ivan: Turtle examples are not nice - I will work on them 08:15:50 Bijan: I can't commit to Primer before end of year 08:16:33 Ivan: What is the status of the primer - rec track vs note - undetermined so far 08:16:49 Ivan: What about profiles in primer? 08:16:53 q? 08:17:13 Bijan: As little as possible - bulks up the primer too much 08:17:22 q? 08:17:35 Ivan: How about using the same example for all profiles? 08:17:43 Bijan: Could be a good idea 08:17:54 Ivan: Appendices? 08:18:12 Bijan: Profiles in text - non-starter - overwhelming 08:18:24 q? 08:18:26 Bijan: Profiles in appendices - better 08:18:30 Ivan: More useful 08:18:41 Bijan: Let's try one of them 08:18:45 Ivan: I'll try RL 08:19:35 Ivan I can help you if you need anything 08:19:56 q? 08:20:40 Christine: Primer is similar to Ontology Development 101, which was useful 08:23:14 q? 08:23:22 Christine: I don't like the Manchester Syntax - it is frame-like and uses "fact" - may lead to misunderstanding 08:24:29 Bijan: The Primer just uses the majorly-used syntaxes - We used Manchester syntax initially so it comes first 08:24:32 q? 08:25:33 q? 08:26:25 IanH: We will discuss status and schedule later in the F2F. 08:27:26 Bijan: There is some perspective-specific stuff in the primer (that can be removed from the presentation) 08:27:32 Latest version of the QRG (wiki) is at http://www.w3.org/2007/OWL/wiki/Quick_Reference_Guide 08:27:37 Subtopic: Quick Reference Guide: 08:28:16 pfps: Agenda has pointer to most recent version 08:28:21 q? 08:28:26 Ivan: QRG has changed tremendously 08:28:42 Elisa: Yes it did change a lot, and it changed again just recently 08:28:50 Ivan: QRG looks good 08:29:08 Elisa: We took a recommendation from pfps to reorganize 08:29:18 Elisa: Not everything is hyperlinked 08:29:29 q? 08:29:58 q+ 08:30:01 Elisa: Intent is to hyperlink everything (functional syntax, RDF syntax, etc.) 08:30:17 Elisa: Might also link to Primer 08:30:29 Elisa: Might require anchors in other documents 08:30:43 Elisa: Still want a two-page print version from this structure 08:30:59 Elisa: Also want a page for the profiles 08:31:18 I like this a lot! 08:31:36 Elisa: Examples - we might not keep them but instead link to Primer 08:31:39 q? 08:31:39 Or link to the syntax, which has examples for every feature 08:32:32 q? 08:32:56 Elisa: We want feedback on structure, later sections need more review 08:33:17 FabGandon has joined #owl 08:33:22 q? 08:33:22 Note: Old documents had a similar multi-docuoment index: http://www.w3.org/TR/owl-ref/#appA 08:33:26 But this is much nicer 08:33:35 Ivan: I like it 08:33:52 And is much better than: http://www.w3.org/TR/owl-ref/#appC 08:33:56 Ivan: What should the third column link to? 08:34:17 Elisa: We are not sure - I think semantics 08:34:30 q? 08:34:44 Ivan: Mapping document is just a table - so not good to link to it - semantics is better 08:35:44 Michael: One problem is that RDF semantics doesn't have the "syntax" 08:35:54 IanH: Semantic isn't great to link to 08:36:18 Elisa: Might link to Primer instead - we may try some things 08:36:50 q? 08:36:53 Bijan: Neither RDF mapping nor RDF semantics is useful to link to 08:36:57 ack ivan 08:37:08 Ivan: perhaps linking to primer is best 08:37:30 Bijan: Primer is not comprehensive but could serve, perhaps with minor changes 08:38:53 q? 08:39:00 Christine: QRG is most useful as initial point of contact 08:39:31 Christine: QRG is too terse 08:40:17 Christine: LInk to requirements document instead? 08:40:56 q? 08:41:09 Evan: What about linking from Recommendations to Notes 08:41:21 Ivan: Not a good idea 08:41:28 q? 08:41:29 Bijan: I don't see a problem - just need to be careful 08:41:48 Ivan: Need to refer to stable documents 08:41:55 Bijan: I like the document 08:42:18 IanH: QRG is getting close to being done, still needs work 08:42:44 Bijan: Publish as working draft at last call, even if not done 08:43:10 -Elisa_Kendall 08:43:16 Subtopic: Requirements 08:43:49 q? 08:44:17 Christine: I think that requirements is close to done - I would make changes - may need changes based on F2F discussion 08:44:37 Christine: There have been several reviews - Bijan, Jie, Elisa 08:44:48 Christine: Only Bijan had major comments 08:44:57 q? 08:45:45 Christine: Addressing Bijan's comments needs input from WG 08:46:21 Christine: There are some conflicting reviews 08:46:48 Christine: Almost all done - changes needed in response to outstanding comments 08:47:15 Christine: Major decision is whether to cut chunks out 08:47:25 Ivan: I like Section 5 08:47:59 Ivan: What does the button do? 08:48:23 Ivan: Oh, I see - 08:48:47 Evan: Need feedback on what do to with the document 08:49:02 Evan: One possibility is to split into two 08:49:04 +1 to Evan 08:50:20 Rinke: Large fraction of HCLS use cases - how about recategorizing them? 08:51:26 IanH: Need to discuss this document later 08:51:50 Christine: Suggest to move features to Quick Reference Guide 08:53:45 BREAK 09:17:18 alexandre passant 09:17:58 holger stezhorm 09:18:00 holger stenzhorl 09:18:09 scot marshall 09:18:22 s/scot/scott/ 09:18:30 Blaz 09:18:46 Rinke has joined #owl 09:18:47 Blaz Novak 09:18:58 Subtopic: Manchester Syntax 09:19:35 pfps: up to date - perhaps one or two issues that might affect it 09:20:17 pfps: there have 2.5+? reviews - one substantive comment 09:21:37 christine: what about mapping from functional to manchester? 09:21:56 pfps: responded with comment that the mapping is "trivial" - comment remains in document 09:22:07 Subtopic: Internationalized String Spec 09:22:34 Boris: Still waiting on Axel Polares for built-in functions (wanted by RIF) 09:22:41 alanr has joined #owl 09:23:58 jeremy: should refer to RDF 4647 as well as 4646 - which may result in changes 09:24:11 s/RDF/RFC/ 09:24:33 boris: what is the impact 09:24:51 jeremy: may need to change matching 09:25:06 IanH: plan / schedule reviewing? 09:25:22 Ivan: needs to be at least a WD by last call 09:25:32 Ivan: what is RIF status? 09:25:46 Sandro: waiting for Axel's changes 09:26:08 IanH: We need to wait for changes 09:26:19 Achille has joined #owl 09:26:32 I18N 09:26:39 jeremy: also review I18N 09:26:40 I18N == "Internationalization" 09:27:10 Bijan: we should push a FPWD ASAP - it blocks us 09:27:26 Bijan: What does CR mean for this? 09:28:03 pfps: if we don't care about built-ins why not push for our approval 09:28:37 Ivan: The CR criteria are the purview of the OWL WG and the RIF WG 09:29:05 Ivan: There could be different CR exit criteria from the rest of our spec 09:29:59 Boris: I sent Axel a message 09:30:15 Bijan: let's push the document even without the built ins 09:30:20 IanH: We don't need them at all 09:30:24 Ivan: RIF wants them 09:30:57 Boris: RIF thought that the old version was lopsided (as it had facets but not built-ins) 09:31:27 Boris: they may not sign off without built-ins 09:31:58 Alan: a WG can have open areas - a section with a missing bit is OK 09:32:36 Ivan: we vote to publish ASAP even if there is a missing section 09:33:13 Alan: include editor's note in FPWD 09:33:32 IanH: can we push now? 09:34:09 IanH: tomorrow we can vote on this 09:34:56 Bijan: this has come from us, and we discussed it, so we don't really need *more* review 09:35:46 Bijan: what about patent review? this means that we *need* FPWD at least 90 days before end 09:36:09 ScribeNick: bernardo 09:36:41 IanH: outstanding issues 09:36:43 Blaz has joined #owl 09:37:01 IanH: first issue, punning (Isuue 114) 09:37:29 bmotik: the issues with annotations are orthogonal to punning 09:37:48 bmotik: we will add a section on punning, where we will explain what punning is by example 09:38:28 bcuencagrau: we will explain punning as different ``views'' over the same URI 09:38:40 bmotik: there was a proposal concerning annotations 09:39:45 bmotik: annotations do not have semantics in DLs 09:40:02 bmotik: instead of attaching annotations to entities we would attach annotations to URIs 09:40:13 wallace has joined #owl 09:40:17 bmotik: this would make the mapping to RDF easier 09:40:37 q+ 09:40:44 alanr: talking of annotations as being a URI might be confusing 09:41:30 alanr: there is a connection between annotations and punning 09:41:54 ianH: could we think of this issue as a bug fix? 09:42:20 alanr: there may also be a problem with anonymous individuals and literals 09:42:49 q? 09:43:08 ack ivan 09:43:17 bmotik: the only change is that the values of annotations will change from entities to URIs 09:43:56 q+ 09:44:08 ivan: this idea of `view' over entities is irrelevant from the OWL Full point of view 09:44:57 \nick bernardo 09:45:05 1) URI not the greatest name 09:45:34 2) Explain missing individual sameAs => extensions equivalent 09:46:01 bparsia: there will be a section on punning/metamodeling 09:46:36 q? 09:46:40 ack alanr 09:47:47 alanr: we should make in the document a clear distinction between the OWL Full and DL views 09:48:05 ianH: where are we concerning this issue? 09:49:08 ianH: we are essentially fixing a bug 09:49:27 bmotik: there is an email with a proposal that already acknowledges this bug 09:49:51 bmotik: resolution would involve adding the new section and make the sall change on annotations 09:50:15 bparsia: let us resolve this issue as in Borise's proposal 09:50:47 s/Borise's/Boris's 09:50:48 IanH: modulo editorial issues we should have a clear proposal to resolve 09:51:49 http://lists.w3.org/Archives/Public/public-owl-wg/2008Oct/0048.html 09:51:55 cgolbrei has joined #owl 09:52:49 PROPOSED: resolve issue 114 as per http://lists.w3.org/Archives/Public/public-owl-wg/2008Oct/0048.html and subsequent thread 09:53:21 +1 (Oxford) 09:53:31 +1 (Oxford) 09:53:59 +1 (Manchester) 09:54:03 +1 (UvA) 09:54:06 sandro: is the resolution proposal in the email itself or in the thread? 09:54:25 Ian: There is still some editorial work to be done, which might open up related issues. 09:54:26 ianH: we have agreed that there will be some editorial issues involved 09:54:28 +1 (FZI) 09:54:30 +1 (ALU) 09:54:34 +1 (Science Commons) 09:54:34 +1 (W3C) 09:54:38 +1 (ORACLE) 09:54:45 +1 (Oxford) 09:54:46 +1 (IBM) 09:54:53 +1 (uvsq) 09:55:01 0 (NIST) 09:55:01 Zakim, who is here? 09:55:01 On the phone I see Riviera_B, Zhe (muted) 09:55:02 On IRC I see cgolbrei, wallace, Blaz, Achille, alanr, Rinke, FabGandon, schneid, bijan, bmotik, Zhe, MarkusK_, sandro, bernardo, IanH, RRSAgent, Zakim, pfps, ivan, trackbot 09:55:33 RESOLVED: resolve issue 114 as per http://lists.w3.org/Archives/Public/public-owl-wg/2008Oct/0048.html and subsequent thread 09:55:46 RRSAgent, pointer? 09:55:46 See http://www.w3.org/2008/10/23-owl-irc#T09-55-46 09:56:13 Issue 134 09:56:29 alanr: we have asked Elisa for feedback 09:56:52 Evan: speaking for Elisa. The person who was our contact is moving at the moment 09:57:18 alanr: will evan have time to look into it? 09:57:39 evan: the problem is getting to work the tools needed 09:57:45 q? 09:57:54 evan: I can talk with Peter Haase 09:58:00 q? 09:58:07 evan: Peter can provide the tool 09:58:33 alanr: first issue: what is the impact of the metamodel in the current docs? 09:58:52 ianH: we need to figure out whether we want to have it at all 09:59:15 bmotik: concerning accessibility, it is from someversion ofEclipse 09:59:36 bmotik: the diagrams are in an IBM format 09:59:47 q? 09:59:51 bmotik: the metamodel can be used to a large extent using Eclipse 10:00:34 bmotik: the metamodel is a representation of the diagrams in a machine readable, formal way 10:00:44 q? 10:01:03 bmotik: layout-related information is not part of the metamodel, but on top of it 10:01:15 bmotik: this extra stuff is in the IBM format 10:01:29 bmotik: the structure can be viewed using Eclipse 10:01:50 bmotik: Eclipse 3.4. with EMF on 10:01:59 q? 10:02:07 bmotik: it does not have a diagram capability, though 10:03:05 bparsia: if the metamodel does involve the layout information, but this is largely unimportant 10:03:18 IanH: do we need to have this as a part of the spec? 10:03:38 alanr: I would like to have a clear metamodel in a machine-readable format 10:04:14 alanr: the content of the document Met describing the metamodel has changed 10:04:22 bmotik: I disagree 10:04:25 q? 10:04:56 evan: I like to look at the diagrams 10:05:24 q+ 10:05:52 evan: the situation is not that bad. There's other tools that can be used for layout 10:06:29 q? 10:06:30 evan: we have public domain tools that allow us to look at the metamodel. A separate question is whether it conforms to MOF 10:07:21 bparsia: the way you would do it is to read the text, look at the diagrams and even click on them and get some sort of code (e.g. javascript) that represents the diagram 10:08:27 bmotik: metamodel is about connectivity 10:08:35 q? 10:08:50 bmotik: in IBM RSA you can draw the diagrams and get the metamodel on the fly 10:09:12 q? 10:09:16 ack alanr 10:09:19 bmotik: we have to insist on total MOF compliance 10:09:41 alanr: what is the benefit of having this metamodel? 10:10:10 bmotik: we want to have a very precise statement saying what is the structure of OWL 10:10:22 bmotik: this would be described by the metamodel 10:10:41 bmotik: precision is provided by the metamodel, and that alone is enough to justify it 10:10:43 ? 10:10:46 q? 10:11:07 bmtik: from a practical point of view, people could generate classes directly from the metamodel 10:11:24 bmotik: also how to transform between metamodels 10:11:37 q+ to ask a few follow questions 10:11:50 bmotik: but the important thing is to have a precise specification 10:12:08 bparsia: I am ok with the text, the metamodel would be good but not a must 10:12:26 q+ to propose it not be critical path to lc 10:12:34 bparsia: the benefit would be in people using it 10:13:16 jeremy: is the extension of the document with the machine-readable metamodel intended to be normative or informative? 10:13:25 Ianh: that is a question 10:14:09 bparsia: what we mean is that, if we have a conflict between the text and the metamodel, the metamodel wins 10:14:27 ivan: this is a lot of work, and probably not a priority 10:14:32 q? 10:14:46 +q 10:15:21 christine: I am not clear what boris means with ``precision'' 10:15:56 christine: not clear what is the real benefit 10:16:15 +1 I have good confidence in the current document 10:16:18 alanr: if it is normative, then we will have a lot of work 10:16:22 But I also think the metamodel is useful 10:16:40 alanr: I suggest it to become a note 10:17:48 ianH: nobody thinks that there is no way we shouldn't have it 10:18:45 bmotik: sometimes English introduces ambiguity. Ambiguity is bad for implementors 10:19:10 but we do have the diagrams in the syntax 10:22:10 Sandro: As long as it doesn't affect implementations, it's okay after Last Call 10:22:39 Jeremy: There is a risk to adding a new master version of the spec, after last call. 10:22:50 Bijan: Yes, it's a risk, but it's doable if necessary. 10:23:20 bmotik: one question, how bout changing ``UML'' into MOF? 10:24:41 Bernardo: If we have this formal metamodel, then what would the review consist of? Someone checking english text vs formal model? Thousands of people look at this, then send their reports to the list? 10:24:56 s/bout/about 10:25:11 Achille: the diagrams we have are supposed to play the role of the MOF metamodel 10:25:28 achille: the spac has already been carefully reviewed 10:25:54 achille: we could probably add a simple note stating the priority of the diagrams over the text 10:26:20 achile: If we do not have a formal description, I wouldn't care that much 10:26:42 IanH: so, there seems to be consensus that this is not in our critical path 10:26:54 q? 10:27:05 -q 10:27:26 MarkusK: if there is work to be done Peter Haase can contribute 10:27:53 ack alanr 10:27:53 alanr, you wanted to ask a few follow questions and to propose it not be critical path to lc 10:28:00 ack bernardo 10:28:15 bijan: we could still have it, and not lose this work 10:28:40 bparsia: whether we have it as an appendix or somewhere else doesn't really matter 10:28:40 q? 10:29:17 alanr: we could then, as Boris suggests, simply make an editorial change 10:29:50 link to MOF please ? 10:29:54 pointer to MOF on the wiki: http://www.w3.org/2007/OWL/wiki/MOF-Based_Metamodel 10:29:57 Jeremy: If they MOF is normative, then what normative documents are are needed to understand it? 10:30:02 bparsia; currently we do not have any statement saying that the diagrams have priority over the text 10:30:12 +q 10:31:05 sandro: it is a good practice to have several normative ways, because it can help identifying bugs 10:31:53 Jeremy: While the OWL1 test cases are normative, it's stated that the Semantics rules. 10:32:10 bmotik: how about changing the first sentence of Section 2.1 10:32:55 bmotik: I want to say that the diagrams are intended to define the structure of the language 10:33:22 alanr: I do not understand the difference between normative and controlling 10:34:00 alanr: the question is whethr among two normative representations, there is one that is controlling 10:34:30 bparsia: we need a controlling view for interoperability issues 10:34:42 +1 Bijan: it's best to pick a controlling normative version, so you get more interoperability. 10:34:53 Bijan: You do less harm if you have people converge. 10:35:20 Peter: if the controlling one is flat-out-broken, then people will revolt and use the other one. 10:35:23 peter: agree with bijan 10:35:53 ianH: the conclusion is that we say what is the controlling representation 10:36:07 Ian: I'm hearing that people do want to pick a controlling one. 10:36:29 ivan: we have two candidates 10:36:32 q? 10:36:47 ivan: functional + text versus diagrams 10:36:47 q= 10:36:50 queue= 10:37:14 bparsia: 1) diagrams plus english 10:37:22 2) grammar + english 10:37:28 q? 10:37:34 3) metamodel + english 10:37:56 bmotik: I agree these are the candidates 10:38:24 achille: there is an ambiguity when we talk about ``text'' 10:38:41 bparsia: this is a presentation issue 10:39:04 mschneider: diagrams plus English tells us the whole story? 10:39:28 bmotik: you could use either 1) or 2) 10:40:25 christine: what is the difference between 1) and 3)? 10:40:45 christine: what about diagrams plus grammar? 10:40:52 bmotik: this is not sufficient 10:40:52 alanr has joined #owl 10:41:05 IanH: we should have a straw poll 10:42:35 IanH: it seems that the vast majority liked 1) and 3) 10:44:29 bparsia: we should have a sentence at the beginning of the syntax doc explaining this 10:45:06 alanr: we should add information saying how to read the diagrams 10:45:50 bparsia: we need to have a pointer to the formal meaning of the diagrams 10:46:36 jeremy: there is an issue concerning people who cannot see the diagrams 10:47:09 bparsia: we should have an official resolution about the controlling text 10:47:36 proposal: the diagrams plus the supportive text are the definitive specification 10:48:32 PROPOSAL: the diagrams plus the supportive text are the definitive specification and there will be a normative reference for the diagrams 10:49:01 ROPOSAL: the diagrams plus the supportive text are the definitive specification for the language and there will be a normative reference for the diagrams 10:49:24 PROPOSAL: the diagrams plus the supportive text are the definitive specification for the language and there will be a normative reference for the diagrams 10:49:26 +1 (ALU) 10:49:29 +1 (IBM) 10:49:32 +1 (Oxford) 10:49:32 +1 (NIST) 10:49:32 +1 (Manchester) 10:49:35 +1 (Oxford) 10:49:37 +1 (ORACLE) 10:49:37 +1 (Oxford) 10:49:42 +1 (FZI) 10:49:47 0 (Science Commons) 10:49:49 +1 (UvA) 10:50:00 RESOLVED: the diagrams plus the supportive text are the definitive specification for the language and there will be a normative reference for the diagrams 10:50:01 0 10:50:18 1 10:50:30 +1 (uvsq) 10:50:50 bparsia: I already have an action for checking about accessibility 10:51:52 bparsia: finding alternative text for the diagrams that is accessibility-friendly is very hard 10:52:50 bparsia: we should have some text, because it is more useful for disabled people 10:53:58 IanH: should we move on? 10:54:19 IanH: we can skip it and it is not in our critical path for last call 10:57:19 bmotik: we could close the issue 10:57:21 Ian: could close and say it'll be a note, if anything. 10:58:17 IanH: that would mean that the MOF XML will not be included in Syntax 10:59:39 evan: I wouldn't like o close it like that 11:00:10 bparsia: if we had a great MOF, we could always revise 11:00:38 PROPOSED: Close Issue-134, saying we don't expect to have a MOF metamodel in a Rec-Track document. Maybe a Note someday. 11:00:47 +1 (Oxford) 11:00:51 1 11:00:51 +1 (UvA) 11:00:51 +1 (ALU) 11:00:53 +1 (Oxford) 11:00:54 0 (NIST) 11:00:54 0 (IBM) 11:00:55 +0 (FZI) 11:00:56 +1 (Oxford) 11:00:57 +1 (ORACLE) 11:01:03 +1 (W3C) 11:01:11 +1 (Manchester) 11:01:14 +1 11:01:37 0(uvsq) 11:01:50 RESOLVED: Close Issue-134, saying we don't expect to have a MOF metamodel in a Rec-Track document. Maybe a Note someday. 11:09:48 -Zhe 11:40:09 bmotik has joined #owl 11:51:35 Rinke has joined #owl 11:59:00 IanH has joined #owl 12:07:33 IanH_ has joined #owl 12:07:42 schneid has joined #owl 12:09:32 msmith has joined #owl 12:09:47 scribe: schneid 12:09:49 Topic: 142 12:09:54 Topic: Issue-142 12:10:28 bmotik: there are actually three issues 12:11:00 alanr: about the sketch proof of thereme 1 12:11:43 alanr has joined #owl 12:12:37 ianh: looked at proof and looked reasonable 12:13:00 alanr: proposal is to close issue 12:13:17 bparsia: i have reviewed it too, and was fine 12:13:58 Proposed: Resolve Issue 142 by Addition of a proof sketch to the profiles document 12:14:05 +1 (ALU) 12:14:17 +1 12:14:19 Achille has joined #owl 12:14:24 +1 12:14:25 wallace has joined #owl 12:14:27 +1 12:14:27 +1 12:14:29 +1 12:14:30 +1 12:14:30 +1 12:14:37 +1 12:14:38 Bijan: +1 12:14:52 0 12:15:07 RESOLVED: Resolve Issue 142 by Addition of a proof sketch to the profiles document 12:15:23 Topic: Issue-145 12:16:09 sandro: any format we publish on the web must have an own mime type 12:17:10 we have to tell the ITF 12:17:19 sandro: we have to tell the ITF 12:17:51 sandro: my example that I sent by mail was what I sent for RIF 12:18:10 ivan has joined #owl 12:18:46 alanr: so this is about OWL/XML syntax, functional syntax, and manchester syntax 12:19:18 ivan: we definitely need it for functional and manchester 12:19:24 sandro: we can use text/plain 12:21:22 alanr: another consideration is predictability 12:22:06 bijan: one cannot rely on mimetypes when one wants to disambiguate 12:22:27 W3C Process document on this: http://www.w3.org/2002/06/registering-mediatype 12:22:59 alanr: two extreme options: lowest = application/xml and text/plain, maximum is a new mime type for each 12:23:08 My e-mail on this for RIF, giving an example of how much to do: http://lists.w3.org/Archives/Public/www-archive/2008Sep/0023.html 12:24:05 bmotik has joined #owl 12:24:32 bparsia: does turtle or n3 has a mime type 12:25:25 sandro: we should have mime type iff particular syntax is intended as a definitive exchange syntax on the web (his opinion) 12:27:09 ivan: reformulate what sandro sais: if syntax rec track, then pressure on us to give mime type higher 12:27:26 alanr: let's straw poll 12:28:01 sandro: generic mime types do sort of say: "don't put this stuff on the web" 12:28:43 alanr: if a syntax isn't first class, then we shouldn't do anything about it. 12:29:44 bparsia: looks like that wg thinks that we don't have the resources to bring manchester syntax on the rec track 12:30:18 ivan: we can still decide to give mime type to manchester syntax 12:30:37 +Zhe 12:31:54 Sandro: I think we need to require all OWL implementations to parse all "first-class" serializations. 12:32:06 Sandro: Otherwise we fragment the OWL world. 12:32:56 ivan: we have mime types for RDF/XML and turtle 12:33:13 bparsia: wasn't hard to come up with converters 12:33:38 bmotik: is it realistic to require tools to support all the different syntaxes? 12:34:13 achille: not clear why is it our responsibility to give mime type to manchester syntax 12:34:55 bparsia: pfps and the wg did much of the work on the manchester draft 12:36:56 ivan: from rdf point of view, system only has to understand rdf/xml; turtle is around, but not needed to be supported officially 12:37:13 Sandro: We have a duty to tell people which syntaxes they can publish in and assume that conformant OWL consumers will understand. 12:37:26 ivan: because manchester is not rec, we cannot say that tools have to support it 12:38:07 ivan: mime type discussion should be primarily be on owl/xml, because this is on rec track 12:38:42 ivan: for functional, it has to be discussed, whether it is meant to be put into a file and send to the web, then mime too 12:39:24 can we call the question on this? 12:39:41 pfps: case of owl 1, it looks that the only normative exchange syntax was rdf/xml, but could also have been the abstract syntax 12:41:11 bparsia: in owl 2 we should not have one normative exchange syntax [fixme] 12:41:40 sandro: in owl 2, the normative exchange syntax should be rdf/xml, as in owl 1 12:43:12 sandro: if we have more than one mandatory exchange syntax, then we have a problem 12:43:51 pfps: i would at least see the functional syntax as an official syntax, and would also prefer manchester to be official 12:44:22 sandro: ... where owl/xml is allowed, using GRDDL. 12:44:55 conformant provider --- provides in a normative stynax 12:46:10 bparsia: if we would use n-triple syntax only for test cases but would say that n-triple is not an official syntax, than this would be a problem 12:47:12 sandro: if someone publishes n-triple, than he can do so, but has also to give the rdf/xml version 12:48:27 pfps: more and more people produce rdf document not in official syntax, which is a good thing 12:49:47 alanr: peter, is what you say about content negotiation? 12:51:14 alanr: let's settle on a few things: mime does not need normativity of syntax... 12:51:32 Alan: Let's do MIME types for all the syntaxes, to enable content negotiation. 12:54:07 alanr: strawpoll on mimetype or not mimetype 12:54:53 straw poll: Mime types for functional, xml, manchester syntaxes? 12:54:57 1 12:55:00 1 12:55:05 -1 12:55:09 +0.5 12:55:09 1 -- because con-neg is useful 12:55:10 pfps +1 12:55:13 +1 12:55:16 0 12:55:17 +1 12:55:20 +0 (it's perhaps a lot of work) 12:55:21 0 12:55:24 bijan: -1 12:55:36 -0 12:55:39 +1 12:56:53 alan: strong majority in favor of more mime types. 12:57:33 Hyunjeong has joined #owl 12:57:50 m_schnei: I fear that this will be a lot of work on WG 12:57:54 ivan: no, it's trivial 12:58:39 alanr: will someone of the against-voters be opt against in real vote? 12:59:18 achille: i am not comfortable, and perhaps would vote against 13:00:37 markusk: giving a functional syntax doesn't change the state of the respective syntax, but likes to see that people can distinguish between syntaxes 13:01:49 alanr: explains difference between having mime type and normativity 13:02:14 ianh: last telco, same discussion in mime types, and normativity was not a topic 13:02:22 Network? 13:02:26 achille: I am opposing the use of functional and manchester syntaxes as standard exchange formats. 13:02:53 bparsia: i have to first talk to uli before i can decide wheter opt against or not 13:04:33 pfps has joined #owl 13:04:46 ivan: it seems that unless uli formally objects, we can proceed on mime type topic 13:05:31 bparsia: uli is in favour of progress 13:06:13 alanr: what mime types? 13:06:28 ivan: obvious for OWL/XML: owl+xml 13:06:56 sandro: does OWL 1 XML syntax had mime type 13:07:02 pfps: no, no mime type 13:07:06 PROPOSAL: We will defined mime types for the functional syntax, manchester syntax, and owl syntax. The mime type for the owl syntax will be application/owl+xml 13:07:32 PROPOSAL: We will define mime types for the functional syntax, manchester syntax, and owl syntax. The mime type for the owl syntax will be application/owl+xml 13:07:50 +1 (ALU) 13:07:51 0 13:07:58 +1 (Oxford) 13:07:59 0 (IBM) 13:08:34 0 (uvsq) 13:08:46 PROPOSAL: We will define mime types for the functional syntax, manchester syntax, and owl syntax. The mime type for the owl syntax will be application/owl+xml. This does not speak to any of these being normative exchange syntaxes 13:08:48 0 (ORACLE) 13:08:51 +1 (UvA) 13:08:54 +1 (ALU) 13:08:55 +1 (Science Commons) 13:08:55 0 (NIST) 13:08:59 +1 (Oxford) 13:09:03 1 (W3C) 13:09:05 0 (IBM) 13:09:11 +1 (FZI) 13:09:54 +1 (uvsq) 13:10:16 alanr: observes that no vote from manchester 13:10:25 RESOLVED: We will define mime types for the functional syntax, manchester syntax, and owl syntax. The mime type for the owl syntax will be application/owl+xml. This does not speak to any of these being normative exchange syntaxes 13:10:27 bparsia: we have to wait for uli to object or not 13:10:40 MarkusK_ has joined #owl 13:12:02 alanr: we need people who work on the mime types 13:12:59 action: Ivan to propose mime types for functional and manchester syntaxes 13:12:59 Created ACTION-233 - Propose mime types for functional and manchester syntaxes [on Ivan Herman - due 2008-10-30]. 13:16:18 MarkusK_ has left #owl 13:16:23 MarkusK_ has joined #owl 13:17:00 Topic: Datatypes 13:17:07 SubTopic: n-ary Datatypes 13:17:22 Can we have a volunteer to scribe in the next session please. 13:18:18 msmith has joined #owl 13:18:23 bernardo has joined #owl 13:18:25 bparsia: uli want's 1/3 be representable 13:18:50 alanr: what is the connection between n-aries and rationals? 13:20:17 bparsia: xsd:decimals don't represent all possible rationals, and we want solvability, and want to write down the literals 13:21:17 bmotik: satisfiability problem is actually solved by owl:real 13:21:45 ivan_ has joined #owl 13:22:07 alanr: is "rational" issue dependent on "n-ary" issue? 13:23:03 alanr: we don't have n-aries in main spec, but could have it in a side spec. do we have this additional spec ? 13:23:18 alanr: where do we stand with n-ary spec? 13:23:55 bparsia: we have support in syntax, in semantics, stratification (3 levels) 13:24:16 alanr: (to bparsia) to you have a document? 13:24:31 bparsia: we have syntax and semantics, so essentially yes 13:25:02 alanr: we need reviewers 13:27:24 bparsia: 3 levels: plain comparison, scaled comparison, linear comparison 13:28:05 bparsia: gives examples... 13:28:21 ... plain comparsion, "h > w" 13:28:30 ... scaled comparison, "3h > w" 13:28:31 sandro has joined #owl 13:29:02 ... linear comparsion, "3h > xh + s" 13:29:27 action: Bijan to send pointer to nary specification by October 27. 13:29:27 Created ACTION-234 - Send pointer to nary specification by October 27. [on Bijan Parsia - due 2008-10-30]. 13:30:29 alanr: have to decide whether note or rec 13:32:38 cgolbrei: decision of specing or not is not only a question of quality, but also on which level should go in 13:33:48 pfps: proposes to have different vote on letting hooks in or not [fixme] 13:35:13 bparsia: this potential spec does not block any other spec, so would object, if bad review will lead to drop the hooks 13:42:07 ivan: what documents would be involved? want to have a feeling 13:42:30 bmotik: if it is integrated in one of the other documents, then in syntax 13:44:18 alanr: again, will we need the n-aries for rationals? 13:45:44 SubTopic: name of dateType 13:47:07 BREAK 13:47:09 s/dateType/dateTime 14:13:15 Rinke has joined #owl 14:13:52 ping 14:18:33 schneid has joined #owl 14:19:01 scribenick: Rinke 14:19:50 Topic: Outstanding XML issues (ISSUE-97) 14:19:58 Evan: possible agenda change for tomorrow 14:20:11 Ian: suggested by Bijan to flip the first two sessions of tomorrow 14:20:21 Ian: any problems with that? 14:20:50 achilleF has joined #owl 14:21:07 christine: apologise in advance, as I will be late 14:21:31 schneid: discussion of future work should be at the end? 14:21:55 Ian: last week's teleconf we decided that ISSUE-56 should be generalised to a broader future work issue 14:22:46 Ian: other suggestion 10-10:45 will be the last session, and bump the other sessions 14:23:08 bijan: that's great 14:23:26 IanH_: other people ok by that? 14:23:46 IanH_: moving 10-10:45 session to 16:15 14:24:03 IanH_: ok, settled. 14:24:10 IanH_: back to GRDDL discussion 14:24:21 IanH_: what to say about the GRDDL thing? 14:24:41 IanH_: we are waiting for an actual XSLT transform to materialise 14:24:55 alanr: the point is, what level of maturity we need to go to last call 14:25:15 alanr: until now things have been changing... do we have any dependency on having the GRDDL finished? 14:25:32 pfps: I suggest we put a pointer to the spec as the GRDDL thing for now 14:25:50 pfps: do whatever is (minimally) required 14:26:14 alanr: will changing the content of the GRDDL after last call cause any problems 14:26:43 sandro: there needs to be a statement saying we may do XSLT in the future, but in the meantime here's the spec that we point to in the meantime 14:27:49 bijan: this would be a change in design... anything we said about security needs to be adjusted (potential downloading of code)... pointing to the spec would not involve this. It is not merely a change in description. 14:28:11 bijan: there's a detectable impact on implementations. I 14:28:29 schneid: for a long time nothing has been discussed? 14:28:42 bijan: there has been a lot of discussion on the GRDDL group 14:29:00 schneid: if someone gets up and says I do it... would someone object? 14:29:03 bijan: yes, I would 14:29:22 IanH_: last time we pushed this issue off, to see whether the issue would solve itself 14:29:41 cgolbrei has joined #owl 14:29:46 alanr: it would be some work to do it... but if it's going to be thrown away... 14:29:55 bijan: but it's still an implementation of the transformation 14:30:38 alanr: there's a specified place in protocol where GRDDL transforms are found. That's what somebody would be doing it for 14:30:54 IanH_: what has changed since last time 14:31:56 ivan: I agree with alan, that the situation today is such that people will not really be willing to do the XSLT because (without going into the discussion on GRDDL interpretation)... the GRDDL users community, regardless of the spec, expects an XSLT transformation in that location 14:32:21 ivan: people will not invest their time in making an XSLT that 99% of the GRDDL implementations will not find 14:33:10 bijan: suggest we'll have a decision. Either party can formally object, and we'll have (the chairs?) decide in some way 14:33:31 sandro: but we cannot give a carte blanche to anyone who promises to build an XSLT 14:34:42 ivan_: If I start from the principle that someone can come up with an XSLT transformation that passes all the tests, (that we need for OWL/XML) then I would like to see that transformation to be put there and be accessible in that place. But we know that Manchester would be formally agains 14:35:23 bijan: there's nothing certain about this (e.g. if we have two, limited resources etc.) 14:35:33 IanH_: suggestions on how to resolve this? 14:35:57 alanr: we should say what we would consider to be crap and unacceptable, i.e. a call for implementation 14:36:13 IanH_: would that say anything about if it meets all the ... 14:36:34 ivan_: somehow we have to be able to say that some implementation that converts owl xml is correct 14:36:44 ivan_: this xslt transform has to pass all test cases 14:37:08 IanH_: you didn't say whether you would set a bar 'if it's beyond this level, then we'll definitely use it' 14:37:31 bijan: I'm a little confused? Did we say we would give out a call for implementations... that's unusual? 14:37:39 IanH_: no we're considering wording 14:37:45 ivan: it has happened 14:38:35 bijan: I have some qualms about that. We've put really high bars on what we included. I'm just weirded out on the special status of this thing wrt. the other parts of the spec. 14:39:00 bijan: I'm wondering why we're going down this road at all? 14:39:08 http://www.w3.org/2007/OWL/tracker/actions/145 14:39:18 sandro: We asked for volunteers (ACTION-145)... jeremy took this on 14:39:30 pfps has joined #owl 14:39:51 sandro: Its out of order to say we shoudn't ask for more implementations, because we have established precedent 14:40:11 sandro: does bijan have a problem with a call for implementations that's neutral wrt. GRDDL 14:40:23 bijan: no, I'd even contribute to that, potentially 14:40:53 pfps: I agree entirely. There's no way we can specify a bar for anything to be included 14:41:03 pfps: the bar would be incredibly high 14:41:25 sandro: cf action-145 14:41:45 alan: I don't agree. We have the test cases: if it passes the testcases we might deem it ok (that's still to decide though... just to make a point that we can set a bar) 14:42:13 alanr: we ought to say what we want or don't want, what it is trying to accomplish. If it doesn't do it, then we shouldn't do it. 14:42:13 Sandro: Let's ask for implementations, and encourage people, say it might be for GRDDL, etc, we'll publicize it as an OWL (translator) implementation, etc. 14:42:42 alanr: We did this for the nary, and I say we should do the same for a GRDDL transformation 14:43:20 IanH_: that sounds reasonable, but what we said about n-ary... is that if the n-ary thing is spec-standard, then we'll decide on whether we push to include it. If it's not good enough then we chuck it out 14:43:28 IanH_: are we happy with the same thing for grddl 14:43:48 alanr: not entirely... if it's not up to standard, it might be a note still 14:44:23 alanr: we shouldn't try to solve this on procedural grounds. 14:44:51 alanr: there are some people who think that XSLT for GRDDL transform is bad, and some who don't think it is. 14:45:27 IanH_: I propose to go forward in exactly the same way as with the nary issue. And do this call, and then decide whether this is up to spec-standard-quality, and move on from there 14:45:58 Ivan: We seem all agreed that it would be good to have the XSLT transformation. 14:46:30 ivan_: having that XSLT and try to get one is a good case. We agree on that. However, we know in advance that even if this is the bestest XSLT transformation in the whole world, then there will still be objections. This is the difference with the nary issue 14:47:03 sandro: we will have formal objections either way (no XSLT vs. XSLT) 14:47:13 FabGandon has left #owl 14:47:15 ivan_: other way out is no ref to GRDDL 14:47:23 (general outings of disagreement) 14:47:32 bijan: let's not overstate our disagreements here. 14:48:09 bijan: all this period of time, we already knew that I would have a problem with this... ever since ACTION-145 14:48:24 bijan: I don't see that the situation has changed? 14:49:01 schneid: thetwo situations are not the same. nary already a lot of work done, a very weak chance on objection. on the other side, no work done on XSLT, and large chance of objection 14:49:15 sandro: I don't understand what we're talking about. Nothing has changed since then. 14:49:25 alanr: there hasn't been a lot done because the spec is not stable 14:49:38 IanH_: I don't see how this is different from what I've been saying? 14:49:45 IanH_: we make this call, and see what comes? 14:50:07 IanH_: what;'s your alternative suggestion? I want to hear! (to alan and ivan) 14:50:45 ivan_: I don't have a clear alternative suggestion. One suggestion that you could work with (and I would be unhappy) is remove GRDDL. There is no suggestion I would be happy with. 14:51:19 alanr: grddl pointer to current syntax doc. Can we change this after we've gone for last call? 14:51:31 alanr: (add the XSLT) 14:51:51 ivan_: we could add a note that it may change to point to an XSLT 14:52:31 ivan: there is a precedent. RDF/A made it clear that if there is a proposed recommendation, through the namespace document, an xslt will be included 14:53:09 alanr: we need to enable whatever we need to enable to make sure that we do not preclude the possibility to add this later 14:53:24 PROPOSED: We keep option-97 (GRDDL XSLT) open through Last Call, not needing to make a decision until PR. 14:53:35 PROPOSED: We keep ISSUE-97 (GRDDL XSLT) open through Last Call, not needing to make a decision until PR. 14:53:36 IanH_: apparently, if we add such a note we wouldn't need to go through last call again 14:54:22 IanH_: if no one comes up with one that passes the test cases, then we don't add one (on a remark from schneid on difficulty) 14:54:30 alanr: should formulate our standards 14:55:02 PROPOSED: We keep ISSUE-97 (GRDDL XSLT) open through Last Call, not needing to make a decision until PR. We'll document this decision as necessary to keep expectations properly set, and we'll keep soliciting a suitable XSLT transform. 14:55:46 bijan: in the rdfa case they already had agreement that they *wanted* it. But here, we're not all in that situation. I guess I won't be a blocker on this, but I really ahve to ask about myself why I should agree with this (which is not process and not in my interest) 14:56:02 sandro: last call is looser than CR 14:56:21 bijan: smaller LC to ask for comments? 14:57:01 PROPOSED: We keep ISSUE-97 (GRDDL XSLT) open through this Last Call, not needing to make a decision until PR. If necessary, we'll do another Last Call for this -- and doing so won't be a reason not to accept the XSLT. We'll document this decision as necessary to keep expectations properly set, and we'll keep soliciting a suitable XSLT transform. 14:57:04 IanH_: If some xslt comes up, bijan reserves the right to 'tell us' to go back to last call 14:57:44 q? 14:57:44 alanr: we shouldnt be blasting over the web, have our requirements in place 14:57:55 alanr: first 14:58:07 bijan has joined #owl 14:58:14 PROPOSED: We keep ISSUE-97 (GRDDL XSLT) open through this Last Call, not needing to make a decision until PR. If necessary, we'll do another Last Call for this -- and doing so won't be a reason not to accept the XSLT. We'll document this decision as necessary to keep expectations properly set, and we'll keep soliciting a suitable XSLT transform. 14:58:45 IanH_: apart from the separate decision on what would constitute a satisfactory/suitable XSLT should do 14:59:02 IanH_: we don't need that in this resolution 14:59:25 pfps: the reason for requiring a second last call is that we put a pointer? 14:59:32 bijan: no, it would constitute a change 14:59:46 sandro: that's this line about sufficient documentation 15:00:45 pfps: I would like to have us decide now that our at least temporary grddl transform says "do what the spec says" 15:02:05 ivan: there is a disagreement between bijan and the WG members of the group, that yes it is allowed legally to have something in there which is not an XSLT, but the whole community expects an XSLT there. It might be correct, but nobody expects it 15:02:20 pfps: it's a recommendation. We're doing the right thing according the rec, case closed 15:02:29 ivan: we're doing it for the community 15:03:05 bijan: I do agree with you on this 15:03:29 IanH_: there's a simple thing to decide on this. Leave the GRDDL empty, or point to the spec? 15:04:04 pfps: if we're doing this for the community, as opposed to a de jure requirement. If it's not a requirement, then don't do it! 15:04:10 pfps: let's just put nothing there 15:05:25 alanr: leaving a pointer, is not what the community expects. In terms of being friendly to the community that's not the best idea. I won't object to it... but it is really a statement by some members of the OWL WG, and does not communicate what it was supposed to do. 15:05:45 alanr: put nothing there in the meantime 15:05:59 sandro: I didn't hear any objection to my proposal right? 15:06:13 PROPOSED: We keep ISSUE-97 (GRDDL XSLT) open through this Last Call, not needing to make a decision until PR. If necessary, we'll do another Last Call for this -- and doing so won't be a reason not to accept the XSLT. We'll document this decision as necessary to keep expectations properly set, and we'll keep soliciting a suitable XSLT transform. 15:06:14 sandro: we could deal with my proposal first, and then continue the discussion 15:06:21 +1 15:06:23 pfps: I'm happy to vote on the proposal 15:06:31 1 15:08:30 bijan: the proposal as it stands has a presumption that I won't go out and badmouth it. It might be good to just put our cards on the table and go ... at this moment I abstain, as I am not sure that this way of going is moving us anything closer to consensus 15:08:35 0 15:08:35 IanH_: we already accepted that 15:08:39 0 15:08:47 sandro: there's no phrasing that would improve it? 15:08:47 +1 15:08:49 bijan: no 15:08:52 0 15:08:54 +1 15:08:54 0 15:08:56 1 15:08:57 0 15:09:00 0 15:09:02 0 15:09:09 0 15:09:17 0 (uvsq) 15:09:34 0 15:09:54 bijan: there doesn't seem to be strong support on this 15:10:18 IanH_: we've got weak acceptance for this, but no objection 15:10:27 alan: so this proposal is resolved 15:10:47 RESOLVED: We keep ISSUE-97 (GRDDL XSLT) open through this Last Call, not needing to make a decision until PR. If necessary, we'll do another Last Call for this -- and doing so won't be a reason not to accept the XSLT. We'll document this decision as necessary to keep expectations properly set, and we'll keep soliciting a suitable XSLT transform. 15:11:27 bijan: I agree in general that spec worship is bad. I prefer in general to break spec-backwardscompatibility....... 15:11:29 msmith1 has joined #owl 15:11:48 bijan: if you appeal to what the grddl community wants, then that's not convincing. 15:12:09 sandro: it's too bad the GRDDL wasn't more clear on this, allowing you to be more clear in your objection 15:12:53 schneid: general question about bugs. For all recommendations there is an erratum, how do these bugfixes get into the errata. How is it created? 15:13:06 ivan_: it is the responsibility of the WG to set up a mechanism. 15:13:16 ivan_: we took into account the errata for OWL 1 15:13:51 schneid: could there not be a way out if bijan et al. fixed the loophole? 15:14:20 bijan: I would have objected. The loophole is the right way to go 15:14:26 pfps: the loophole is the right way to do 15:14:30 s/do/go 15:14:47 sandro: I'd like to understand why you think it's the right way to go. 15:15:02 alan: is it a good idea to have everyone who has an idea on how to guarantee quality on this transform put this on email 15:15:21 alan: I don't know what the bar is, I'd like to have some idea... 15:15:52 Peter: An automatic process that would produce the XSLT from our documents. 15:15:55 pfps: a provably correct automated process that would derive an XSLT transform from our documents. 15:16:00 Sandro: Yes. That would be great! 15:16:15 bijan: yes, that would be a first step 15:17:18 bijan: that would be nice... other things that would be nice is if it were software-readable. Performance is an issue... it has to have a very clear forward errata process (my early objection was that the initial version would be a default standard) 15:17:34 alan: doesn't this hold for the schema document as well? 15:18:43 bijan: we need an errata process in general. My point is that it is much less likely that an XML schema is downloaded automatically... and it does not produce any meaning. An XSLT really changes something that I put out... xml schema does checking, and I would need to explicitly invoke this 15:19:16 sandro: you say 'typical', but schema can be used to generate parse tree (?) 15:19:27 bijan: you mean the schema is at the location of namespace? 15:19:38 sandro: yes, at least dereferencable 15:19:46 bijan: I'm not sure I would support that 15:19:51 alanr has joined #owl 15:19:55 alan: issues are very helpful! Location of schema etc. 15:20:15 Also, in general, scarily, XML Schema is easier to understand 15:20:21 At least, have confidence that it is correct 15:20:23 For me at least 15:20:28 IanH_: we have some guidelines for what's good quality. No procedure for asking for the implementation 15:20:55 alanr: do we need to decide now to as a WG send out a notice to some list? 15:21:00 sando: I assume it's editorial 15:21:10 IanH_: are we done with this issue? 15:21:26 alanr: the only thing... where we going to point to the specification? 15:21:42 IanH_: point or do nothing 15:21:54 sandro, bijan, ivan, alan, pfps: not do anything 15:22:14 bijan: mention of grddl in the charter means that we still... 15:22:24 sadro: we need to specify how to deal with grddl 15:22:36 ivan: if there's a deviation from the charter, we need to document htis 15:22:46 IanH_: that's for later 15:23:06 PROPOSED: We won't use GRDDL until we figure out what we're doing with GRDDL. By charter, we'll have to figure out eventually what we're doing with GRDDL. At the namespace document was can refer to this issue.\ 15:23:10 alanr: if it turns out that the strategy is to read the spec by a program i.e. via css... class markup 15:23:15 PROPOSED: We won't use GRDDL until we figure out what we're doing with GRDDL. By charter, we'll have to figure out eventually what we're doing with GRDDL. At the namespace document was can refer to this issue.\ 15:24:34 pfps: the resolution that we might end up with is that we don't use grddl.... 15:24:56 PROPOSED: We won't use GRDDL until we figure out what we're doing with GRDDL. By charter, we'll have to figure out eventually what we're doing with GRDDL. At the namespace document, for now, was can refer to this issue. 15:25:03 PROPOSED: We won't use GRDDL until we figure out what we're doing with GRDDL. By charter, we'll have to figure out eventually what we're doing with GRDDL. At the namespace document, for now, we can refer to this issue. 15:25:31 pfps: I would prefer to say put nothing on the namespace document at all, and put our current lack of consensus elsewhere 15:26:28 sando: if there's nothing there, grddl-people who look at it will say oh my god, you're not doing grddl 15:26:37 +1 15:26:43 1 15:26:43 +1 15:26:46 +1 15:26:46 +1 15:26:49 +1 15:26:51 pfps: ok, if it has to be there (Because that's where they'll look) that's ok 15:26:51 +1 15:26:53 +1 15:26:54 +1 15:26:54 +1 15:27:30 IanH_: that seems to be resolved, more or less unanymously 15:27:31 RESOLVED: We won't use GRDDL until we figure out what we're doing with GRDDL. By charter, we'll have to figure out eventually what we're doing with GRDDL. At the namespace document, for now, we can refer to this issue. 15:27:52 ivan_: there was one discussion we had today that was postponed... should it be recorded as issue perhaps... 15:28:02 ivan_: which are the normative serialisations of owl 15:28:14 alanr: yes, open an issue 15:28:27 ivan_: rdf vs. owl xml 15:28:35 ISSUE: Which serialization of OWL are suitable as normative exchange syntaxed? 15:28:36 Created ISSUE-150 - Which serialization of OWL are suitable as normative exchange syntaxed? ; please complete additional details at http://www.w3.org/2007/OWL/tracker/issues/150/edit . 15:29:56 Bijan: I think some folks outside the group may object to any normative exchange syntax other than RDF/XML 15:30:00 bijan: there might be some tactical issues here 15:30:31 Sandro: I think GRDDL+XSLT might be enough. 15:30:38 pfps: rdf/xml is the default syntax for xml, but content providers might negotiate the exchange of other syntaxes as well 15:30:53 pfps: you have to be prepared to serve RDF/XML for any OWL 2 ontology 15:31:20 pfps: if you exchange in the FS, you use this mimetype and syntax (normatively). If you ask for XML syntax the same.... 15:31:42 PROPOSED: Close issue-150 saying RDF/XML is the normative exchange syntax for OWL 2. Systems should transmit other OWL 2 serializations only when there has been prior arrangement to use the alternative serialization (eg by HTTP Content Negotiation). 15:31:46 pfps: if you are a consumer, and you say you only want the XML syntax, the provider may say 'sorry I don't do that' 15:32:01 pfps: but if you ask for RDF/XML you have to serve it 15:32:21 bijan: MUST support RDF/XML, MAY or SHOULD the others 15:32:27 pfps: I like SHOULD 15:33:04 sandro: there's some toughness here, but the spirit ... 15:33:17 ivan: at some point in time there has to be some wordsmithing, but the intent is ok 15:34:08 pfps: The idea is: you HAVE TO serve RDF/XML, but you may provide others. 15:34:37 sandro: may even specify weights 15:34:55 ivan: you can rank what syntaxes you prefer 15:35:01 pfps: may even be completely agnostic 15:35:08 (?) 15:35:30 alanr: do we want to say something on conformance of tools to take this. 15:35:41 ivan_: every tool has to take RDF/XML 15:36:24 pfps: not quite. I could be an editor (damaged P4, that is limited to preserve roundtripping), but could still do something 15:36:54 bijan: I'm ok with this in general. If I write a tool that only consumes OWL XML... do we care? I mean, who cares? there's only so much influence we can have here 15:37:26 bijan: are we commited to having an errata later on if the facts on the ground change (e.g.Turtle becomes the defacto standard) 15:37:42 bijan: the more conformance you enforce that does not make sense, the weaker your power 15:39:04 alan: does normative RDF/XML mean that every tool must be able to exchange this syntax to be conformant? 15:39:06 ivan: yes 15:40:06 PROPOSED: Close issue-150 saying conformant OWL reasoners MUST accept rdf/xml. They MAY accept other serializations. Systems publishing OWL2 should publish it in RDF/XML; they MAY also publish in other serialzations, but should only send it by prior arrangement (eg content-negotiation). 15:40:08 bijan: I don't object, but don't think it's going to do anything useful. Any tool that is doing anything useful will do RDF/XML.... but my student won't do this as it's hard to parse 15:40:24 bijan: what vendor's mind is going to be affected by this decision 15:40:48 pfps: the rason for saying this is to tryo and diffuse the potential laying down on the ground and scream 15:40:53 s/rason/reason 15:40:57 peter: the reason for this is to diffuse the lay-down-on-the-ground-and-scream reaction. 15:40:57 s/tryo/try 15:41:21 schneid: we had normativity for RDF/XML in OWL 1 15:41:28 schneid: would it be possible not to have this in OWL 2 15:41:40 IanH_: It doesn't matter if we decide to do it... 15:41:52 bijan: If you don't want to make it non-normative, then your question is moot 15:42:08 IanH_: does the proposal as it stands capture what it should 15:42:39 wallace: it seems superfluous. It's fine, but I don't understand why this would be needed. 15:43:07 pfps: I believe it is useful because there is a community that very much want it to be 'should not' produce other syntaxes 15:43:13 peter: This is a community that wanted "SHOULD NOT" instead of "MAY". 15:43:52 pfps: original was MUST be able instead of MAY 15:44:43 alanr: it is useful to have a default... predictability is nice 15:45:27 pfps: this is not the way it should be. Suppose I'm a repository of P4 documents, mastered in DL style. And bijan is a pellet reasoner, Under the should, if bijan doesn't care, I take my FS turn it into RDF/XML and bijan does it the other way around. 15:45:58 alan: but if you have a random user, then default is easier (because you encounter all these different syntaxes) 15:46:20 bijan: if you build a crawler, you can specify what format you want to retrieve 15:47:26 ivan_: we may have the shortest-lived issue ever 15:47:37 ivan_: it wasn't even open yet 15:47:39 PROPOSED: Close issue-150 saying conformant OWL reasoners MUST accept RDF/XML. They MAY accept other serializations. Systems publishing OWL2 MUST publish it in RDF/XML if asked; they MAY also publish in other serialzations, but only by prior arrangement (eg content-negotiation). 15:47:51 s/ivan_/IanH_ 15:48:14 PROPOSED: Close issue-150 saying conformant OWL reasoners MUST accept RDF/XML. They MAY accept other serializations. Systems publishing OWL2 MUST publish it in RDF/XML if asked; they MAY also publish in other serialzations 15:48:47 s/serialzations/serializations 15:49:42 PROPOSED: Close issue-150 saying conformant OWL reasoners MUST accept RDF/XML. They MAY accept other serializations. Systems publishing OWL2 MUST publish it in RDF/XML if asked (eg with HTTP content-negotiation); they MAY also publish in other serializations. 15:50:12 PROPOSED: Close issue-150 saying conformant OWL reasoners MUST accept RDF/XML. They MAY accept other serializations. Systems publishing OWL2 MUST publish it in RDF/XML if asked (eg with HTTP content-negotiation); they MAY also publish in other serializations. 15:50:15 +1 15:50:17 +1 15:50:18 +1 15:50:20 +1 15:50:20 +1 15:50:20 1 15:50:21 +1 15:50:22 +1 15:50:22 +1 15:50:24 +1 15:50:24 +1 15:50:28 +1 15:50:30 +1 15:50:34 RESOLVED: Close issue-150 saying conformant OWL reasoners MUST accept RDF/XML. They MAY accept other serializations. Systems publishing OWL2 MUST publish it in RDF/XML if asked (eg with HTTP content-negotiation); they MAY also publish in other serializations. 15:51:02 IanH_: I think we're getting very close to the end of the session 15:51:07 ivan_: we settled everything? 15:51:11 pfps: no, not xsd datetype 15:51:12 RRSAgent, pointer? 15:51:12 See http://www.w3.org/2008/10/23-owl-irc#T15-51-12 15:51:22 IanH_: can we do something on that in the 10 minutes left? 15:51:32 pfps: I'll meet henry tomorrow to talk on this 15:51:51 ivan_: one question on the manchester syntax 15:52:06 ivan_: can I put a comment in the manchester syntax? 15:52:47 pfps: there was a discussion in webont that annotations should be comments, this was not accepted. 15:53:25 ivan: in RDF/XML I can do XML comments, in Turtle I can use the hash 15:53:31 pfps: perfectly happy to have 15:53:46 bmotik: that should be easily changed 15:54:09 bijan: caveats should be explicit 15:54:18 pfps: comments may be stripped: this should be explicitly mentioned 15:54:54 bijan: the OWL-S group used xml comments and had trouble using that. So a statement that warns people is useful 15:55:01 pfps: I think it's a good idea to add 15:55:32 IanH_: editorial for peter and bmotik 15:55:54 "whatever turtle has:" 15:56:53 IanH_: are we done? 15:57:05 sandro: comment on scribing. I've been making cleanups as we went along 15:57:24 sandro: in the wiki... topics, subtopics etc.... I wrote a script that did that realtime 15:57:38 IanH_: talking of scribing... about tomorrow 15:58:06 boris: I could scribe the session after lunch 15:58:17 IanH_: volunteers for the first session 15:58:22 wallace: I will do that 15:58:28 boris: I will go before lunch 15:59:02 achilleF: first session after lunch 15:59:19 ivan: roadmap 15:59:56 ADJOURN 15:59:59 talking about dinner. 16:00:52 Meet at hotel reception desk at 7pm 16:01:08 RRSAgent, pointer? 16:01:08 See http://www.w3.org/2008/10/23-owl-irc#T16-01-08 16:01:49 zakim, who is here? 16:01:49 On the phone I see Riviera_B, Zhe 16:01:50 On IRC I see alanr, msmith, bijan, pfps, cgolbrei, achilleF, schneid, sandro, bernardo, MarkusK_, wallace, IanH_, Zhe, RRSAgent, Zakim, trackbot 16:02:00 Zhe -- are you still there? 16:02:06 yes 16:02:24 I am not on the phone right now 16:02:51 Will you be around first thing tomorrow morning for the discussion on issue 144? 16:03:09 you mean 3am my local time :) 16:03:23 Yeah, Elisa stayed up! 16:03:28 Yes -- and I wouldn't even ask except that you were here at that time today :-) 16:03:31 You're not going to let her punk you, eh? 16:03:43 I will try 16:04:14 We could reschedule if it would help? 16:04:56 make it after 3:15am (EST) can help 16:05:34 So this would be after 9:15 am French time? 16:05:45 i think so. 16:05:57 So this is middle of the night your time? 16:06:03 yes 16:06:09 OK! 16:06:18 thanks 16:06:22 We admire your devotion! 16:06:46 I will be half asleep ... 16:06:49 Or do you have to get up at this time to feed the baby? 16:06:50 ;) 16:07:19 luckily, I don't have to... my wife takes that duty 16:07:31 Nice :-) 16:08:28 have a good dinner/night 16:08:41 Thanks -- and the same to you! 16:08:44 -Riviera_B 16:16:26 pointer 16:16:29 zakim, pointer 16:16:29 I don't understand 'pointer', alanr 16:16:33 rrsagent, pointer 16:16:33 See http://www.w3.org/2008/10/23-owl-irc#T16-16-33 16:35:00 disconnecting the lone participant, Zhe, in SW_OWL(F2F)2:30AM 16:35:03 SW_OWL(F2F)2:30AM has ended 16:35:04 Attendees were Elisa_Kendall, Riviera_B, Riviera_B.a, Zhe 16:44:29 IanH has joined #owl 18:21:22 Zakim has left #owl 20:25:03 IanH_ has joined #owl 20:26:22 Rinke has joined #owl