Chatlog 2008-06-04

From OWL
Jump to: navigation, search

See original RRSAgent log and nicely formatted version.

Be sure to justify/explain all edits to this page, in your "edit summary" text.

16:52:52 <> PRESENT: bijan, Sandro, Evan_Wallace, Peter_Patel-Schneider, bmotik, uli, msmith, Elisa_Kendall, m_schnei, Achille, MarkusK, Ivan, calvanese, ratnesh, Ruttenberg, Rinke, Carsten, Zhe
16:52:52 <> CHAIR: alan
16:52:52 <RRSAgent> RRSAgent has joined #owl
16:52:52 <RRSAgent> logging to
16:53:07 <ewallace> ewallace has changed the topic to:
16:54:34 <ewallace> Zakim, this will be owlwg
16:54:34 <Zakim> ok, ewallace; I see SW_OWL()12:00PM scheduled to start 54 minutes ago

16:56:12 <Zakim> SW_OWL()12:00PM has now started

17:02:11 <Elisa> scribe: Elisa
17:02:24 <ewallace> scribeNick:Elisa
17:02:27 <bijan> Ian is on vacation
17:04:18 <Elisa> Topic: Admin
17:04:38 <alanr> zakim, who is here?
17:04:38 <Zakim> 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:42 <Zakim> ... MarkusK, ratnesh, Ivan, Sandro, Alan, ??P15
17:04:43 <Zakim> 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:52 <Elisa> Link to Agenda is
17:05:13 <Elisa> Alan: Agenda amendments: (1) we need to accept minutes of May 21
17:05:37 <Elisa> Alan: (2) on imports and versioning, Alan needs to get back to Boris on wording, thus drop that
17:05:49 <Elisa> Alan: first, previous minutes, 28 May
17:05:51 <alanr> PROPOSED: Accept Previous Minutes (28 May)
17:05:56 <alanr> +1
17:05:57 <msmith> +1 on minutes
17:06:03 <Rinke> +1
17:06:08 <pfps> +1 minutes acceptable now
17:06:19 <Elisa>
17:06:27 <ivan> +1
17:06:34 <alanr> RESOLVED: Accept Previous Minutes (28 May)
17:06:34 <uli> +1
17:06:39 <alanr> PROPOSED: Accept Previous Minutes (21 May)
17:06:47 <Elisa>
17:07:04 <Elisa> Alan: there was work to be done on these -- has anyone checked them since last week?
17:07:08 <Zakim> +Zhe
17:07:08 <pfps> +1 minutes are better than last week
17:07:09 <uli> they look better than last time I looked
17:07:19 <msmith> there appeared to be reorderings, etc.  
17:07:20 <msmith> +1
17:07:29 <Rinke> +1
17:07:29 <uli> +1
17:07:34 <ivan> 0 (was not on that meeting:-)
17:07:40 <ewallace> +1
17:07:45 <ratnesh> 0
17:07:50 <alanr> RESOLVED: Accept Previous Minutes (21 May)
17:08:18 <Elisa> Alan: Registration for F2F3 reminder
17:08:27 <Elisa> Topic: Pending Review Actions
17:08:57 <Elisa> Alan: I've modified the action to be relative to the decision taken at the F2F.
17:09:07 <Elisa> Alan: I saw a note from Michael Schneider addressing some issues
17:09:28 <bmotik> +1 to Alan
17:09:31 <Elisa> if people agree, we could say that this action is done, but 
17:09:36 <m_schnei> +1 to boris has done his job
17:09:36 <Achille> +1 to Alan
17:09:40 <Rinke> +1
17:09:42 <pfps> +1 to accepting action 131
17:09:53 <uli> +1
17:09:54 <bijan> +1
17:09:58 <Zhe> +1
17:10:01 <Achille> +1
17:10:09 <msmith> +1
17:10:16 <Elisa> but that as people review it that we would raise any issues, that we will discuss as they come up.
17:10:17 <ewallace> +1 to saying the action is done, related concerns may lead to new issues
17:10:33 <bijan> I'll push
17:10:35 <Elisa> Alan: let's consider that closed.
17:10:46 <Elisa> Alan: issue 42
17:11:14 <ewallace> issue 42 will be pushed out

17:11:22 <Elisa> m_schnei: Expect something written towards the end of the week (action 147).
17:12:11 <bijan> Primer is being rewritten to take all this into account
17:12:12 <Elisa> 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 <Elisa> Alan: Action 148 will be closed.
17:12:50 <Elisa> Alan: Action 150 continued to next week.
17:13:16 <Elisa> Alan: Another agenda amendment, Ian and I have accepted 4 more issues - we'll send email
17:13:40 <Elisa> Alan:  Issue 104 - the status of this is editorial
17:14:01 <Elisa> m_schnei: I didn't quite understand -- this issue is about to be resolved today ... difficult to see from the agenda.
17:14:31 <Elisa> Alan: When an issue is considered editorial, anyone in the wg can address it and close it when they do
17:14:56 <Elisa> m_schnei: This certainly isn't editorial -- in the old OWL 1.1 DL spec there was a complete list of URIs that were not allowed to be used, and everything that was not in the list is allowed to be used.
17:15:31 <alanr> Noted, Boris ...
17:15:51 <Elisa> m_schnei: 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 <Elisa> Alan: If you and Boris can work this out, then we can make this editorial.
17:16:33 <Elisa> m_schnei: It's a problem to make this editorial - I would not be in favor of that.
17:17:05 <Elisa> 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:20 <alanr> ack m_schnei
17:17:25 <Elisa> m_schnei: I will come up with a list of uris from the old spec that were allowed.
17:17:30 <bmotik> OK.

17:17:37 <Elisa> Alan: Let's put that on the list for discussion next week.
17:17:48 <alanr> put 104 on next week's agenda for discussion. Not editorial any more.
17:18:42 <bmotik> Yes
17:18:47 <Elisa> Alan: Should we proceed on the general discussion first, since Boris needs to leave at 2
17:18:54 <Elisa> Topic: General Discussion

17:19:35 <Elisa> 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 <Elisa> 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. 
<Elisa> ... In order to explain the details, you need to be involved in tableaux algorithms. 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 <Elisa> Alan: Does that mean it cannot be implemented using rule-based techniques?
17:21:48 <Elisa> Boris: in rule-based techniques it is much easier
17:22:04 <MarkusK> Re Boris (the problem is in existentials): this is not the case for EL++, where the existentials are also harmless
17:22:04 <Elisa> Boris: The problems arise when you get these existentially introduced individuals.
17:22:48 <Elisa> 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 <bmotik> Markus, why do you think this?
17:23:12 <Elisa> Bijan: 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, but that's always going to be the case.
17:23:29 <MarkusK> Boris, because you can compile EL++ into Datalog, and use a rule based reasoning too
17:23:38 <Elisa> Bijan: If you enumerate, or define finite subsets of individuals you may have trouble there, so I'm wondering what standard Boris thinks we need for scalability.
17:23:56 <MarkusK> ... where the compilation is trivial
17:24:08 <Elisa> Bijan: We could put a restriction on the data properties, but that seems unfortunate in this case.

17:24:45 <Elisa> 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:54 <bijan> To be precise, it is "pay as you go"
17:24:58 <bmotik> q+ to answer to Ivan
17:25:02 <Carsten> +1 to ivan
17:25:18 <Elisa> Ivan: It seems doable in OWL-R, and with some difficulty in OWL DL, but that doesn't seem a good argument.
17:25:37 <Elisa> Uli: We know the harmful and harmless cases and can distinguish them.
17:25:53 <MarkusK> +1 to Uli: there are other ways to break reasoning already
17:26:01 <Elisa> Uli: 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 <bijan> Or to rephrase it, would people prefer to have a syntactic restriction on key properties or to have potential nonscalable cases.
17:26:31 <Elisa> Alan: Perhaps it makes sense to distinguish between the two cases -- handle the easier case in the first pass, and then have a pass if possible.
17:27:10 <bijan> (It's easier to spec easy keys than easy peasy keys)
17:27:17 <Zakim> bmotik, you wanted to answer to Ivan
17:27:35 <Elisa> Uli: If we can leave it with the easy case, then the easy keys become "easy-peasy".
17:28:05 <bijan> (Right, easy keys dumb down to easy-peasy keys in e.g., owl-r)
17:28:07 <Elisa> Boris: in OWL-R both are the same -- I wasn't necessarily advocating for only easy-peasy keys.  I do believe that there is a difference, though, because of the complexity of the algorithms.  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.  The email I wrote talked about difficulties that could arise.
17:30:03 <Elisa> Bijan: We haven't had implementation experience, but you believe that the examples are going to be relatively common.
17:30:12 <Elisa> Boris: Yes
17:30:29 <Elisa> Bijan: So let's say that it turns out to be harder in that case, what's your strategy for it?
17:30:43 <pfps> if there are no implementations, then keys *have* to be dumped, right?
17:30:49 <alanr> yes
17:31:12 <Elisa> 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 <bijan> WE can always have implemetnatiosn :)
17:31:31 <alanr> do they need to be correct?
17:31:31 <ivan> pfps: actually, the usual CR exit criteria is to have 2 independent implementations for each feature...
17:31:32 <Elisa> Boris: We would have something in the language that doesn't really fit. Perhaps given the implementation we will know how to put the proper disclaimer on it.
17:32:06 <Elisa> Bijan: I still didn't quite understand the alternative to dumping keys altogether.
17:32:23 <Elisa> Boris: you could consider them DL-safe rules, or define them outside the spec.
17:32:42 <Elisa> Bijan: you do advocate dumping them from our spec and keeping them outside?
17:33:00 <Elisa> Boris: Well it depends on the results of the implementation experience, but yes.
17:33:17 <Elisa> Alan: Perhaps we should discuss this over the week and then revisit it next week.
17:33:23 <bijan> No
17:33:29 <Elisa> Alan: Would it help to have more time? I wouldn't mind having another week to figure out some way forward to putting these in the spec, perhaps at least easy-peasy keys.
17:34:13 <bmotik> +1 to Uli
17:34:48 <Elisa> 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, and I agree with Boris that we don't have other cases like that in there.

17:35:09 <uli> yes
17:35:13 <uli> yes
17:35:19 <bijan>
17:35:50 <bijan> See that uri
17:35:50 <uli> Michael, this makes trouble to define
17:35:54 <Elisa> m_schnei: I see even an easier feature, where the property versions that would be the easiest way compared to easy-peasy keys, these
17:36:09 <uli> Michael, we can't define a semantics for these - or can you? 
17:36:37 <uli> yes
17:36:41 <Elisa> 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:37:07 <Elisa> Bijan: Can I just point out that there is a pretty extensive discussion on the easy keys page
17:37:43 <Elisa> 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. I certainly don't think that removing from the whole spec is justifiable
17:37:48 <pfps> Are keys *in* OWL-R?  If not, how can they be *removed*?
17:38:01 <uli> Ivan, I don't think that this will be necessary
17:38:18 <ivan> pfps: my understanding is that it can be added to OWL-R easily
17:38:19 <Elisa> Boris: I'm not advocating a change to the semantics, or two different constructs ... 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:38:20 <alanr> peachy keys
17:38:42 <m_schnei> 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 <bijan> Deliberately so!
17:39:12 <uli> michael, indeed (see the discussion Bijan has pointed out)
17:39:38 <Elisa> Boris: it might make sense to think about how to implement it before putting it in there.  I do think in all likelihood it is implementable but if you have a million individuals then you have a million squared individuals. We should see if it really works before putting it into the spec.
17:40:55 <bijan> +1 to uli
17:40:57 <Elisa> 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. I think we can drop them far more easily than keys.
17:41:35 <Elisa> Boris: we don't see OWL DL reasoners that can handle a million individuals ... in OWL R you can - you put it into one of our reasoners, you see whether or not it can be done ... let's just do this
17:42:03 <uli> ...and bottom role is easy anyway
17:42:49 <Elisa> 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. 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. So there is always a wide balance of considerations, and no one was trying to suggest otherwise. 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 <uli> s/keyes/keys
17:44:48 <Elisa> 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 <Carsten> yes
17:45:08 <sandro> +0.5 keep top and bottom
17:45:09 <pfps> no - no strong objection from me to not including top/bottom
17:45:10 <Elisa> Alan: If you say yes then you really want them.
17:45:11 <MarkusK> +0.5 to top
17:45:16 <ivan> 0
17:45:17 <bmotik> +1 to investigate top and bottom
17:45:23 <uli> +0.3 would be a shame if we dropped them unnecessarily
17:45:25 <m_schnei> 0
17:45:29 <Rinke> +0.5 to have top
17:45:29 <Achille> 0
17:45:33 <MarkusK> (+1 to not drop something based on theoretical performance considerations)
17:46:02 <Elisa> 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:20 <Rinke> +1 MarkusK 
17:47:16 <Elisa> Alan: so I'm wondering whether we should resolve such problems by saying that we should put these things in and see what happens, or not? The advantage of putting them in is that folks have something to think about for longer.
17:47:30 <bijan> I'd prefer for things to get  into Working Drafts
17:47:43 <sandro> "at risk"
17:47:54 <uli> sounds fine
17:48:00 <Elisa> Sandro: the W3C key is to say that something is at risk, then if you take it out later you don't have to worry about the process.
17:48:11 <bijan> If something is not labeled at risk and gets pulled out, the default is to go back to last call
17:48:54 <Elisa> Boris:  I don't think that discussing this over email would be useful -- my proposal would be to implement these features and then come back and say yes this was the experience
17:49:08 <ewallace> do we have volunteers to implement?
17:49:16 <ewallace> applauds Boris as well!
17:49:31 <bijan> I'm experiementing with Top and Bottom
17:49:37 <bijan> And some easy key stuff as well
17:49:40 <Elisa> Boris: My proposal would be to postpone this for a week, 2, 3 and then see what really happens ... in my case the implementation isn't really there so it would be a month before I could come back with an answer.
17:50:00 <bijan> We can always mark them in WDs as "needing implementor feedback"
17:50:03 <Elisa> Alan: We should discuss next week whether or not we should put things that are at risk into the spec.

17:50:20 <Elisa> Topic: Issue Discussions
17:51:00 <bmotik> It's not issue 108; it's a thing that doesn't have an issue
17:51:16 <Elisa> Alan: issue 108 -- I sent out mail to the W3C space to see what was there and there seemed to be some relevant things about how we should be using the keywords (should, must)
17:51:55 <Elisa> Boris: I also looked in one of these RFCs, regarding "should" and I wasn't happy with that because it says this is optional, and I would like something more than optional
17:52:07 <bijan> SHOULD, in practice, varies in its strength
17:52:10 <alanr> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
17:52:11 <alanr>    may exist valid reasons in particular circumstances to ignore a
17:52:11 <alanr>    particular item, but the full implications must be understood and
17:52:11 <alanr>    carefully weighed before choosing a different course.
17:52:22 <alanr> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
17:52:22 <alanr>    there may exist valid reasons in particular circumstances when the
17:52:22 <alanr>    particular behavior is acceptable or even useful, but the full
17:52:22 <alanr>    implications should be understood and the case carefully weighed
17:52:23 <alanr>    before implementing any behavior described with this label.
17:52:24 <Elisa> Boris: We've been using this to say something is default ... do it like this unless you have a very good reason for not doing it.
17:52:35 <Elisa> Sandro: it doesn't mean optional ...
17:52:38 <msmith>
17:52:52 <Elisa> Boris: then I looked at a different document
17:53:34 <Elisa> Bijan: the official definition is what you were asking for, but in general, "should" can have the effect of being optional, or could have the effect of being mandatory, depending on how you read it.  If we are going to have shoulds, then we can use it as specified in the RFC -- shoulds are compatibility points.
17:53:58 <ewallace> We SHOULD use SHOULD an interpret it as Alan quoted under 3 (Boris' meaning)
17:54:22 <Elisa> Boris: as we are using it, the meaning is exactly as in the RFC, so perhaps we should repeat it. I don't think we will be using other keywords.  If you are departing from this default, you should advertize it clearly. The inventor is obliged to say what he really did there.
17:54:51 <bijan> "Warnings"
17:55:12 <sandro> +1 boris, yes we can/should require vendors to be clear about when they are exercising a SHOULD.
17:55:31 <alanr>
17:55:32 <Elisa> Alan: The only question I have is that the manuals say how to do this and make it typographically visible - is there any reason we shouldn't do that?  In the w3c manual, it says explicitly how to use them.
17:56:18 <sandro> "conformance labels"
17:56:38 <Elisa> Bijan: This idea that we should have some kind of --- from vendors we should talk about some notion of conformance, and that we could ask that warnings be given in some form or another, we haven't done any of that yet.
17:57:04 <Elisa> Alan: If you could put an issue in for this, it's distinct from what we're discussing and useful
17:57:38 <bijan> we do!
17:57:39 <Elisa> Boris: If people really depart from these things, it has to be clear that an implementation is really departing from the "should". It would be useful for the implementer to say what part of the shoulds they did not implement; if a vendor says they are compliant, they should say that they are OWL 2 compliant BUT ...
17:57:49 <sandro> I think we can require warnings.
17:59:28 <Elisa> Bijan: Among our options are conformance labels, warnings ... and we can choose what we say about these. Similar things occur in other W3C specifications - we can say that in order to conform with OWL 2 you must adhere to the shoulds.
17:59:52 <Elisa> Boris: I agree that the last thing you said is just a conformance label and I've put this into the spec.
18:00:45 <Elisa> Alan: The issue is if we are going to use "SHOULD" then we should follow the advice of the TR with respect to how we use them; if we are going to talk about conformance levels, that's an interesting and separate issue that we should put in and take up at another meeting. We also need to cite it as a reference and do the other things they say we need to do.
18:01:05 <bijan> Issue-130 has been raised

18:02:25 <Elisa> Alan: Issue 97 - We decided that we would write up a short doc about how to handle GRDDL for the OWL XML syntax; the issue is regarding who would take up this document development
18:02:30 <bijan> Ok
18:02:59 <sandro> ivan!   ivan!
18:03:01 <Elisa> Alan: Action on Bijan to write up this point of view; It would be good to have one of the W3c guys write up something on how to do this using XSLT.  I want to get someone to commit to the writing.
18:03:08 <bijan> I could do it :)
18:03:33 <bijan> I won't be at the f2f either
18:03:43 <bijan> I can write the pro case!
18:04:07 <Elisa> Alan: Ivan would you write up the first draft? On email or the wiki.
18:04:11 <Elisa> Ivan: ok

18:05:07 <alanr> action: bijan write 1/2 of GRDDL pro/con document for presentation and vote in next f2f
18:05:07 <trackbot> Created ACTION-154 - Write 1/2 of GRDDL pro/con document for presentation and vote in next f2f [on Bijan Parsia - due 2008-06-11].
18:05:31 <alanr> ivan write 1/2 of GRDDL pro/con document for presentation and vote in next f2f, Sandro to own it at F2F
18:05:48 <alanr> action: ivan write 1/2 of GRDDL pro/con document for presentation and vote in next f2f, Sandro to own it at F2F
18:05:49 <trackbot> Created ACTION-155 - Write 1/2 of GRDDL pro/con document for presentation and vote in next f2f, Sandro to own it at F2F [on Ivan Herman - due 2008-06-11].
18:06:13 <bijan> Can I get a pointer ot hte discussion last week?
18:06:16 <bijan> I'mahving trouble finding it
18:06:20 <pfps> I'm happy to talk about 124
18:06:26 <Elisa> Alan: Issue 124 - should we discuss this?

18:07:03 <alanr> agreed to
18:07:27 <Elisa> Bijan: I'm confused about what I should be writing up on GRDDL - need a little context, but it came from the discussion two weeks ago.
18:08:29 <Elisa> Sandro: The process could be that Bijan writes it, and everyone screams, or Alan writes it and everyone screams -- Sandro will provide the context to Bijan with regard to how to resolve this from the minutes two weeks ago.
18:08:32 <ivan> :-0 
18:08:58 <Elisa> Alan: we were going to have a formal vote on this ...
18:09:14 <Elisa> Bijan: so where does that leave us?
18:09:46 <Elisa> Alan: I would rather have Bijan contribute the piece he needs to create, and then have Ivan do the same with the other side 

18:09:58 <sandro> two weeks ago discussion:
18:10:05 <Elisa> Alan: Issue 124
18:10:41 <pfps> q+ to note that the "related notes" in the issue appear to be incorrect, ...

18:11:44 <alanr> peter - agree, my mistake - will fix
18:11:45 <Elisa> m_schnei: The issue is for OWL Full in the current semantics, the complement is relative to the whole domain, and the problem is that all datatypes, or all subsets of RDFSLiteral. The currently used URI for this is overloaded.

18:12:28 <Zakim> pfps, you wanted to note that the "related notes" in the issue appear to be incorrect, ...
18:12:34 <Elisa> m_schnei: There are two domains for this in OWL DL but only one domain in OWL Full
18:13:45 <m_schnei> what i am talking about here is actually a distinct issue, which just came up in the discussion of 124

18:14:13 <Elisa> Alan: Originally, when we talked about complement of datarange, when we talked about the complement of 5 integer, you got all other integers ... but then Boris said that the complement would include all other datatypes, not just integers.
18:14:37 <Elisa> m_schnei: What I propose is to just give it a strict name for this other complement.  This is different from issue 124 -- it is much easier to fix, all we need to do is provide an owl data complement uri.  This came up during the discussion of issue 124.
18:15:27 <m_schnei> m_schnei: this is an RDF mapping issue
18:15:34 <Elisa> Alan: my thought is to include this in the same issue, rather than opening another issue
18:15:38 <m_schnei> thanks, peter ;-)
18:15:44 <Elisa> Peter: Michael's solution for this is perfect

18:16:02 <Elisa> Alan: Michael, would you come up with a solution of this for our agenda for next week?
18:16:08 <Elisa> m_schnei: Yes, I'll do that

18:17:00 <Elisa> Alan: Issue 109 is a question of what namespace to use for the OWL XML schema, and whether or not it should be distinct from or the same as what we're using for the RDF/XML OWL namespace
18:17:12 <ivan>
18:17:45 <bijan> I'm not so pessimistic either
18:18:16 <bijan> Or homicide!
18:18:26 <Elisa> Ivan: I have written up some of the discussion I had yesterday with Bijan, but I am not as pessimistic about this as you are.  I tried to write down what the choice is and next week we can vote on this and people can choose between the two options.  It's not that big of a deal.
18:18:39 <Elisa> Alan: That's fine with me unless anyone has anything else to add
18:18:56 <alanr> put 109 on agenda for next week - all to read
18:19:22 <Elisa> Topic: Additional Other Business
18:19:54 <Elisa> Alan: we have a mail from a user asking about horn shiq and about why it's not in OWL ... how should we respond?
18:19:58 <bijan> hornSHIQ is a good profile!

18:20:02 <alanr>$9cd57cc0$d6807640$@com
18:20:13 <Carsten> He is within OWL2 DL
18:20:20 <Elisa> Bijan: is there any reason not to include it as one more profile?
18:20:20 <uli> ...there was "too many profiles"
18:20:31 <msmith> +1 to uli's recollection
18:20:54 <Elisa> Bijan: depending on whether you count 3 or 5 or 7, depending on how you count the full versions of the little ones ... hornSHIQ is a distinct and interesting profile, so would this open the floodgates? there is a user who wants this ... 

18:22:28 <Elisa> Carsten: If we want to consider adding this, is it interesting enough to become rec?  That's not a very strong point for adding it - we already have one data complexity profile, so I'm not really convinced.
18:22:30 <pfps> +1 to carsten
18:22:49 <Carsten> That applies to every user
18:22:51 <MarkusK> +1 to Carsten
18:23:06 <Elisa> Bijan: The other thing is that there are modeling problems that fall into hornSHIQ that are not relevant to the other data complexity profile - that's where he's coming from, otherwise i agree with you in general, but Christian was coming from both a modeling and performance perspective.
18:23:42 <Carsten> I disagree
18:23:54 <Elisa> Alan: I wonder if we should have the requirements people capture the modeling issue?
18:24:30 <uli> +1 to Carsten's recollection
18:24:35 <Elisa> Carsten: I disagree, because that something was good for modeling is not a good reason to include something - there should be an additional virtue that it has when you don't use DL full
18:24:38 <alanr> q+ to say perhaps I mispoke
18:24:39 <ivan> +1 to Carsten
18:24:43 <Zakim> alanr, you wanted to say perhaps I mispoke
18:24:56 <Carsten> ok
18:25:27 <Elisa> Alan: I meant modeling in the sense of the inference you could make from it -- and whether the use case was compelling enough and the performance gain compelling enough to consider.
18:25:35 <bijan> Well, hornSHIQ can be compiled to (potentially exponentially many) datalog rules. KAON2 shows that performance (in that case) is pretty reasonable. In that sense, it's sort ofa  "maximal" DLP
18:25:53 <Carsten> maximal in OWL*2*?
18:26:11 <bijan> So we could respond: It's unclear that hornSHIQ is a profile that will have enough implementor and user support to be a viable profile, esp. given how many fragments we already have. If you would like the WG to reconsider, could you provide some more information...
18:26:19 <bijan> Carsten, ooo, dunno
18:26:23 <Elisa> Alan: So - we have on one hand some people are saying well use OWL DL, we have too many fragments already and it isn't sufficiently compelling; the alternative would be to say we will investigate a little more and you should talk with our requirements people about it.
18:26:24 <uli> +1 to Bijan
18:26:36 <uli> Bijan's first suggestion!
18:26:37 <ivan> +1 to bijan
18:26:50 <calvanese> +1 to Bijan
18:26:52 <pfps> +1 to bijan
18:26:56 <Zhe> +1 to bijan
18:26:57 <alanr> +1
18:26:59 <Achille> +1 to bijan
18:26:59 <Elisa> Alan: I like what Bijan says - 
18:27:00 <msmith> +1
18:27:04 <Rinke> +1
18:27:04 <Carsten> +1 
18:27:05 <bijan> +1 to me
18:27:08 <MarkusK> +1
18:27:09 <ewallace> +1
18:27:20 <bijan> Chair response
18:27:28 <Elisa> Ivan: I think Alan should respond
18:27:42 <alanr> action: Alan to respond to the email along the lines Bijan suggests above
18:27:42 <trackbot> Created ACTION-156 - Respond to the email along the lines Bijan suggests above [on Alan Ruttenberg - due 2008-06-11].
18:28:17 <Elisa> Alan: last item -- Bijan brought up the issue of accessibility guidelines, and the work that needs to be done to follow those guidelines in our documents - what work needs to be done, how do we get started ...
18:28:47 <Elisa> Sandro: I know there is something to be done but don't know how much work it is
18:28:55 <Rinke>
18:29:16 <Elisa> Bijan: It's certainly the case that for our images we need to have alternate text, tables are often hard for assisted technology without additional mark-up ... there may be work to be done to make sure that the tables are good enough
18:29:21 <m_schnei> unless there is no official W3C policy on this (is there any?), are we supposed to do anything in this direction? 
18:29:39 <uli> michael, I think we should
18:29:51 <Elisa> Bijan: There are some tools that check from an accessibility point of view.
18:30:04 <bijan> ALl our javascript dumbs down well
18:30:15 <Elisa> Ivan: I don't know how extensively we use java scripting - that would require some additional explanation in the text.
18:30:37 <uli> Sandro, what does W3C normally do?
18:30:54 <Elisa> Alan: It seems like we need some research on this, and someone to review our documents ... maybe we can discuss on the chairs list how we can get additional information and get back to the group with some harder facts
18:31:13 <Elisa> Alan: AOB?
18:31:57 <alanr> action: Alan to confer with chairs list about how to get more information about what we need to do re: accessibility
18:31:57 <trackbot> Created ACTION-157 - Confer with chairs list about how to get more information about what we need to do re: accessibility [on Alan Ruttenberg - due 2008-06-11].

18:32:59 <Zakim> SW_OWL()12:00PM has ended
18:33:00 <Zakim> Attendees were bijan, Sandro, Evan_Wallace, Peter_Patel-Schneider, bmotik, uli, msmith, Elisa_Kendall, m_schnei, +1.857.362.aaaa, +39.047.101.aabb, Achille, MarkusK, Ivan,
18:33:02 <Zakim> ... calvanese, ratnesh, Alan, Rinke, +49.351.463.3.aacc, Carsten, Zhe
20:35:41 <Zakim> Zakim has left #owl