16:52:52 RRSAgent has joined #owl 16:52:52 logging to http://www.w3.org/2008/06/04-owl-irc 16:53:07 ewallace has changed the topic to: http://www.w3.org/2007/OWL/wiki/Teleconference.2008.06.04/Agenda 16:54:34 Zakim, this will be owlwg 16:54:34 ok, ewallace; I see SW_OWL()12:00PM scheduled to start 54 minutes ago 16:55:40 54 minutes ago? 16:56:02 ratnesh has joined #owl 16:56:12 SW_OWL()12:00PM has now started 16:56:19 +??P1 16:56:23 pfps-away has joined #owl 16:56:24 zakim, I am ??p1 16:56:24 +bijan; got it 16:56:29 zakim, mute me 16:56:29 sorry, bijan, muting is not permitted when only one person is present 16:56:37 Grr. Why not? 16:56:55 +Sandro 16:57:01 sorry, bijan, I cannot answer that question when only one person is present 16:57:08 zakim, mute me 16:57:08 bijan should now be muted 16:57:12 uli has joined #owl 16:57:17 (hi...) 16:57:21 zakim, mute everyone else 16:57:21 I don't understand 'mute everyone else', bijan 16:57:26 +Evan_Wallace 16:57:27 If only.... 16:57:32 m_schnei has joined #owl 16:57:41 +Peter_Patel-Schneider 16:58:09 msmith has joined #owl 16:58:22 +??P6 16:58:28 Zakim, ??P6 is me 16:58:28 +bmotik; got it 16:58:33 Zakim, mute me 16:58:33 bmotik should now be muted 16:58:38 Elisa has joined #owl 16:58:57 +??P7 16:59:06 zakim, ??P7 is me 16:59:06 +uli; got it 16:59:10 zakim, mute me 16:59:10 uli should now be muted 16:59:16 +msmith 16:59:19 +[IPcaller] 16:59:33 +Elisa_Kendall 16:59:43 Achille has joined #owl 16:59:45 zakim, [IPcaller] is me 16:59:45 +m_schnei; got it 16:59:47 calvanese has joined #owl 16:59:51 zakim, mute me 16:59:51 m_schnei should now be muted 17:00:15 MarkusK has joined #owl 17:00:25 + +1.857.362.aaaa 17:00:27 - +1.857.362.aaaa 17:00:33 +[IBM] 17:00:47 + +39.047.101.aabb 17:00:48 +??P12 17:00:52 Zakim, IBM is Achille 17:00:52 +Achille; got it 17:01:07 +??P17 17:01:11 zakim, dial ivan-voip 17:01:11 ok, ivan; the call is being made 17:01:13 +Ivan 17:01:17 Zakim, aabb is me 17:01:17 +calvanese; got it 17:01:24 zakim, +??P17 is me 17:01:24 sorry, ratnesh, I do not recognize a party named '+??P17' 17:01:28 -Sandro 17:01:41 zakim, c??P17 is me 17:01:41 sorry, ratnesh, I do not recognize a party named 'c??P17' 17:01:44 We need a chair, eh? 17:01:50 zakim, mute me 17:01:50 calvanese should now be muted 17:01:54 zakim, ??P17 us ratnesh 17:01:54 I don't understand '??P17 us ratnesh', ivan 17:01:59 alan should be chairing? 17:01:59 ???? 17:02:10 He doesn't seem to be here,yes? 17:02:11 scribe: Elisa 17:02:15 zakim, P17 is ratnesh 17:02:15 sorry, ivan, I do not recognize a party named 'P17' 17:02:20 He's listed as chair 17:02:24 scribeNick:Elisa 17:02:26 +Sandro 17:02:27 zakim, ??P17 is ratnesh 17:02:27 Ian is on vacation 17:02:28 +ratnesh; got it 17:02:43 Rinke has joined #owl 17:02:48 I have the popular vote in non-caucus states... 17:03:19 did anybody emailed/pinged Alan? 17:03:28 He's not on skype 17:03:30 I'll swing by his office on my way. 17:03:34 +Alan 17:03:42 (never mind) 17:03:48 alanr has joined #owl 17:03:53 Carsten has joined #owl 17:03:57 ...and since he's so very dillegent, I can't imagine anything but physical injury would keep him from attending! 17:04:02 hi 17:04:10 So, sandro, stop your harshing on alan! 17:04:18 Topic: Admin 17:04:31 +??P15 17:04:38 zakim, who is here? 17:04:38 On the phone I see bijan (muted), Evan_Wallace, Peter_Patel-Schneider, bmotik (muted), uli (muted), msmith (muted), m_schnei (muted), Elisa_Kendall, Achille, calvanese (muted), 17:04:41 Zakim, ??P15 is me 17:04:42 ... MarkusK, ratnesh, Ivan, Sandro, Alan, ??P15 17:04:43 On IRC I see Carsten, alanr, Rinke, MarkusK, calvanese, Achille, Elisa, msmith, m_schnei, uli, pfps, ratnesh, RRSAgent, ewallace, Zakim, bmotik, ivan, sandro, bijan, trackbot 17:04:45 +Rinke; got it 17:04:48 a good reason to be late 17:04:52 Link to Agenda is http://www.w3.org/2007/OWL/wiki/Teleconference.2008.06.04/Agenda 17:04:56 zakim, mute me 17:04:56 Rinke should now be muted 17:05:13 Agenda amendments: (1) we need to accept minutes of May 21 17:05:37 (2) on imports and versioning, Alan needs to get back to Boris on wording, thus drop that 17:05:49 Alan: first, previous minutes, 28 May 17:05:51 PROPOSED: Accept Previous Minutes (28 May) 17:05:54 + +49.351.463.3.aacc 17:05:56 +1 17:05:57 +1 on minutes 17:06:03 +1 17:06:08 +1 minutes acceptable now 17:06:19 http://www.w3.org/2007/OWL/wiki/Teleconference.2008.05.28/Minutes 17:06:21 zakim, aacc is me 17:06:21 +Carsten; got it 17:06:25 hi 17:06:27 +1 17:06:34 RESOLVED: Accept Previous Minutes (28 May) 17:06:34 +1 17:06:39 PROPOSED: Accept Previous Minutes (21 May) 17:06:45 zakim, mute me 17:06:45 Carsten should now be muted 17:06:47 http://www.w3.org/2007/OWL/wiki/Teleconference.2008.05.21/Minutes 17:07:04 Alan: there was work to be done on these -- has anyone checked them since last week? 17:07:08 +Zhe 17:07:08 +1 minutes are better than last week 17:07:09 they look better than last time I looked 17:07:19 there appeared to be reorderings, etc. 17:07:19 Zhe has joined #owl 17:07:20 +1 17:07:29 +1 17:07:29 +1 17:07:34 0 (was not on that meeting:-) 17:07:40 +1 17:07:45 0 17:07:50 RESOLVED: Accept Previous Minutes (21 May) 17:08:18 Alan: Registration for F2F3 reminder 17:08:27 Topic: Pending Review Actions 17:08:57 Alan: I've modified the action to be relative to the decision taken at the F2F 17:09:07 I saw a note from Michael Schneider addressing some issues 17:09:28 +1 to Alan 17:09:31 if people agree, we could say that this action is done, but 17:09:36 +1 to boris has done his job 17:09:36 +1 to Alan 17:09:40 +1 17:09:42 +1 to accepting action 131 17:09:53 +1 17:09:54 +1 17:09:58 +1 17:10:01 +1 17:10:09 +1 17:10:16 but that as people review it that we would raise any issues, that we will discuss as they come up 17:10:17 +1 to saying the action is done, related concerns may lead to new issues 17:10:33 I'll push 17:10:35 let's consider that closed 17:10:44 zakim, unmute me 17:10:44 m_schnei should no longer be muted 17:10:46 Alan: issue 42 17:11:14 issue 42 will be pushed out 17:11:15 zakim, mute me 17:11:15 m_schnei should now be muted 17:11:22 Michael -- expect something written towards the end of the week (issue 147) 17:11:54 q? 17:12:11 Primer is being rewritten to take all this into account 17:12:12 Achille: I did the review - just added a reviewer note on a couple of issues; we need to adjust the primer accordingly 17:12:24 (issue 148) 17:12:34 Issue 148 will be closed 17:12:50 Alan: action 150 continued to next week 17:13:16 Alan: another agenda amendment, Ian and I have accepted 4 more issues - we'll send email 17:13:25 q+ 17:13:32 zakim, unmute me 17:13:32 m_schnei should no longer be muted 17:13:40 Alan: Issue 104 - the status of this is editorial 17:14:01 Michael: I didn't quite understand -- this issue is about to be resolved today .. difficult to see from the agenda 17:14:31 Alan: when an issue is considered editorial, anyone in the wg can address it and close it when they do 17:14:56 Michael: this certainly isn't editorial -- in the old OWL 1.1 DL spec there was a complete list of URIs that were 17:15:13 not allowed to be used, and everything that was not in the list is allowed to be used 17:15:31 noted, boris 17:15:51 in the current form, all RDF and RDFS URIs are excluded, so in particular the reification vocabulary would not allowed to be used and so this is a backwards compatibility issue 17:16:06 Alan: if you and Boris can work this out, then we can make this editorial 17:16:33 Michael: it's a problem to make this editorial - I would not be in favor of that 17:16:38 q? 17:17:05 Alan: that's enough for me to consider it an issue for discussion ... do you feel you would be comfortable to discuss it now or over email 17:17:08 q? 17:17:20 ack m_schnei 17:17:25 Michael: I will come up with a list of uris from the old spec that were allowed 17:17:30 OK. 17:17:30 q- 17:17:35 zakim, mute me 17:17:35 m_schnei should now be muted 17:17:37 Alan: let's put that on the list for discussion next week. 17:17:48 put 104 on next week's agenda for discussion. Not editorial any more 17:18:16 Topic: Issue Discussions 17:18:42 Yes 17:18:47 Alan: should we proceed on the general discussion first, since Boris needs to leave at 2 17:18:54 Topic: General Discussion 17:19:29 Zakim, unmute me 17:19:29 bmotik should no longer be muted 17:19:35 Alan: there were some concerns with easy keys, one had to do with implementation, the other had to do with being at risk since there were no implementations yet 17:20:10 Boris: so, I've been thinking about implementation -- in email I tried to explain why I don't think this is trivial and on the other hand why it might work 17:20:22 q? 17:20:26 q+ 17:20:35 q+ 17:20:48 In order to explain the details, you need to be involved in tableaux algorithms ... 17:20:50 q+ 17:20:59 ack alanr 17:21:10 For the moment I would say that this is work in progress, and then we shall see whether or not it goes into the spec 17:21:28 Alan: does that mean it cannot be implemented using rule-based techniques? 17:21:47 q+ 17:21:48 Boris: in rule-based techniques it is much easier 17:22:03 ack bijan 17:22:04 Re Boris (the problem is in existentials): this is not the case for EL++, where the existentials are also harmless 17:22:04 The problems arise when you get these existentially introduced individuals 17:22:12 zakim, unmute me 17:22:12 bijan was not muted, bijan 17:22:48 Bijan: I think we need to keep a distinction between it being easy in all cases and easy in key cases and easy for users to write properly 17:23:00 Markus, why do you thhink this? 17:23:12 so it's clear that the much easier keys, where you look for explicit data values, rather than data ranges, is going to be easier 17:23:21 but that's always going to be the case 17:23:29 Boris, because you can compiel EL++ into Datalog, and use a rule based reasoning too 17:23:38 if you enumerate, or define finite subsets of individuals you may have trouble there 17:23:53 so I'm wondering what standard Boris thinks we need for scalability 17:23:56 ... where the compilation is trivial 17:24:08 we could put a restriction on the data properties, but that seems unfortunate in this case 17:24:14 ack ivan 17:24:16 zakim, muteme 17:24:16 I don't understand 'muteme', bijan 17:24:44 zakim, mute me 17:24:44 bijan should now be muted 17:24:45 Ivan: in some ways I agree with what Bijan just said ... in some ways easy keys seems an important set of use cases 17:24:48 q+ 17:24:54 To be precise, it is "pay as you go" 17:24:58 q+ to answer to Ivan 17:25:02 +1 to ivan 17:25:03 ack uli 17:25:05 zakim, ack me 17:25:05 I see alanr, bmotik on the speaker queue 17:25:18 It seems doable in OWL-R, and with some difficulty in OWL DL, but that doesn't seem a good argument 17:25:37 Uli: we know the harmful and harmless cases and can distinguish them 17:25:49 ack alanr 17:25:53 +1 to Uli: there are other ways to break reasoning already 17:26:01 if you want to break the reasoning you can do this -- I don't see the difference between this case and other cases in OWL DL 17:26:12 Or to rephrase it, would people prefer to have a syntactic restriction on key properties or to have potential nonscalable cases. 17:26:31 Alan: perhaps it makes sense to distinguish between the two cases -- handle the easier case in the first pass 17:26:49 and then have a pass if possible 17:27:10 (It's easier to spec easy keys than easy peasy keys) 17:27:17 ack bmotik 17:27:17 bmotik, you wanted to answer to Ivan 17:27:28 zakim, mute me 17:27:28 uli should now be muted 17:27:35 Uli: If we can leave it with the easy case, then the easy keys become "easy-peasy" 17:28:02 +??P0 17:28:05 (Right, easy keys dumb down to easypeasy keys in e.g., owl-r) 17:28:05 -??P0 17:28:07 Boris: in OWL-R both are the same -- I wasn't necessarily advocating for only easy-peasy keys 17:28:25 q? 17:28:28 I do believe that there is a difference, though, because of the complexity of the algorithms 17:28:52 q+ 17:29:01 but we have had some validation of these features - snomed, galen, where we have empirically demonstrated that you can use the existing constructs and not get into problems 17:29:14 ack bijan 17:29:18 +??P0 17:29:24 zakim, ??P0 is ratnesh 17:29:24 +ratnesh; got it 17:29:33 the email I wrote talked about difficulties that could arise 17:30:03 Bijan: we haven't had implementation experience, but you believe that the examples are going to be relatively common 17:30:12 Boris: yes 17:30:29 Bijan: so let's say that it turns out to be harder in that case, what's your strategy for it 17:30:43 if there are no implementations, then keys *have* to be dumped, right? 17:30:49 yes 17:31:12 Boris: if it turns out in these typical cases where you go beyond OWL-R, then ... I would really suggest that we keep these two things separate 17:31:20 WE can always have implemetnatiosn :) 17:31:31 do they need to be correct? 17:31:31 pfps: actually, the usual CR exit criteria is to have 2 independent implementations for each feature... 17:31:32 we would have something in the language that doesnt really fit 17:31:44 q? 17:31:49 perhaps given the implementation we will know how to put the proper disclaimer on it 17:32:06 Bijan: I still didn't quite understand the alternative to dumping keys altogether 17:32:23 Boris: you could consider them DL-safe rules, or define them outside the spec 17:32:42 Bijan: you do advocate dumping them from our spec and keeping them outside 17:32:57 q+ 17:33:00 Boris: well it depends on the results of the implementation experience, but yes 17:33:17 Alan: perhaps we should discuss this over the week and then revisit it next week 17:33:23 No 17:33:29 would it help to have more time? 17:33:51 I wouldn't mind having another week to figure out some way forward to putting these in the spec, 17:33:56 q+ 17:33:56 zakim, unmute me 17:33:57 uli should no longer be muted 17:33:58 ack uli 17:34:01 perhaps at least easy-peasy keys 17:34:13 +1 to Uli 17:34:27 q+ 17:34:48 Uli: what would help to sort this out would be to see use cases, and if nobody uses datatype predicates on them, then we will know that easy keys are not more difficult than easy peasy keys, and we could check syntactically 17:34:53 ack m_schnei 17:34:54 zakim, unmute me 17:34:54 m_schnei was not muted, m_schnei 17:34:55 zakim, mute me 17:34:55 uli should now be muted 17:35:01 and I agree with Boris that we don't have other cases like that in there 17:35:09 yes 17:35:13 yes 17:35:19 http://www.w3.org/2007/OWL/wiki/Easy_Keys#Why_not_easiest_keys.3F 17:35:50 See that uri 17:35:50 Michael, this makes trouble to define 17:35:54 Michael: I see even an easier feature, where the property versions that would be the easiest way 17:36:09 Michael, we can't define a semantics for these - or can you? 17:36:12 compared to easy-peasy keys, these 17:36:35 zakim, mute me 17:36:35 m_schnei should now be muted 17:36:37 yes 17:36:38 q- 17:36:41 Boris: as long as the assertions contain constants, it isn't too bad, the issue is when you have individuals that can be interpreted in any way 17:36:44 q+ 17:36:47 zakim, unmute me 17:36:47 bijan was not muted, bijan 17:36:49 q? 17:36:52 ack bijan 17:37:00 +q 17:37:07 Bijan: can I just point out that there is a pretty extensive discussion on the easy keys page 17:37:12 ack ivan 17:37:43 Ivan: so one more thing - I can't really comment on the DL side, but I would object to removing the keys from OWL-R, where it isn't really a problem 17:37:48 Are keys *in* OWL-R? If not, how can they be *removed*? 17:37:50 ack bmotik 17:37:59 I certainly don't think that removing from the whole spec is justifiable 17:38:01 Ivan, I don't think that this will be necessary 17:38:18 pfps: my understanding is that it can be added to OWL-R easily 17:38:19 Boris: im not advocating a change to the semantics, or two different constructs 17:38:20 peachy keys 17:38:42 uli, yes you're right, this seems hard. for the variables, we have the "HU(.)" predicate, but what can we say about the "r(.,.)" ? 17:38:51 Deliberately so! 17:38:54 the semantics is ok; I do believe that there might be a reason to drop this out of owl -- they apply only to these explicitly named individuals and are much more akin to rules 17:39:12 michael, indeed (see the discussion Bijan has pointed out) 17:39:38 Boris: it might make sense to think about how to implement it before putting it in there 17:39:54 q? 17:39:57 q+ 17:40:09 ack uli 17:40:11 I do think in all likelihood it is implementable but if you have a million individuals then you have a million squared individuals 17:40:22 we should see if it really works before putting it into the spec 17:40:38 q+ 17:40:55 +1 to uli 17:40:57 Uli: in contrast to easy keys, i have seen more use cases for top and bottom property, but i haven't heard anyone shout so loudly for them as I have for keys 17:40:58 zakim, mute me 17:40:58 uli should now be muted 17:40:58 ack bmotik 17:41:07 I think we can drop them far more easily than keys 17:41:34 q+ 17:41:35 Boris: we dont see OWL DL reasoners that can handle a million individuals ... in OWL R you can ... 17:42:00 q? 17:42:03 ...and bottom role is easy anyway 17:42:04 you put it into one of our reasoners, you see whether or not it can be done ... let's just do this 17:42:04 ack bijan 17:42:06 zakim, unmute me 17:42:06 bijan was not muted, bijan 17:42:49 q+ alnr 17:42:49 Bijan: I think that Uli pointed out that in one of these cases there has been a huge battle/desire/complaints for keys, not so much for top and bottom property, so I think it's easier to drop these 17:43:20 sandro has joined #owl 17:43:21 q+ 17:43:26 there is different motivation for these, for keys it's a huge wart on the language, but we can request implementation and see what happens 17:43:46 so there is always a wide balance of considerations, and no one was trying to suggest otherwise 17:43:51 +Sandro.a 17:44:00 ack alnr 17:44:09 -Sandro 17:44:22 whether we keep this on a separate page or include them is a different issue now -- we're at the implementation stage and need to see whether or not we can do them 17:44:39 s/keyes/keys 17:44:48 Alan: would there be any strong objectors to dropping top and bottom role? do you think there isn't any reason to spend more time on them? 17:45:08 yes 17:45:08 +0.5 keep top and bottom 17:45:09 no - no strong objection from me to not including top/bottom 17:45:10 If you say yes then you really want them 17:45:11 +0.5 to top 17:45:16 0 17:45:17 +1 to investigate top and bottom 17:45:21 0 17:45:23 +0.3 ...it would be a shame if we dropped them unnecessarily 17:45:25 0 17:45:29 +0.5 to have top 17:45:29 0 17:45:33 (+1 to not drop something based on theoretical performance considerations) 17:46:02 Alan: so it's been mentioned several times, so regardless of whether we put something into the spec, we will need 2 implementations 17:46:04 zakim, who is talking? 17:46:06 -Alan 17:46:11 zakim, mute me 17:46:11 bijan should now be muted 17:46:12 oops, lost our boss 17:46:15 sandro, listening for 10 seconds I heard sound from the following: Sandro.a (24%), ratnesh (50%), Ivan (20%) 17:46:16 hang on 17:46:16 Alan went! 17:46:19 zakim, mute scary noise 17:46:19 I don't understand 'mute scary noise', bijan 17:46:20 alan is lost in the fog :-) 17:46:20 +1 MarkusK 17:46:22 Can we go as well? 17:46:25 zakim, who is talking? 17:46:27 Hello! 17:46:33 that is strange 17:46:37