16:36:51 <RRSAgent> RRSAgent has joined #owl
16:36:51 <RRSAgent> logging to http://www.w3.org/2008/08/13-owl-irc
16:36:55 <Rinke> zakim, this will be owl
16:36:55 <Zakim> ok, Rinke; I see SW_OWL()1:00PM scheduled to start in 24 minutes
16:37:15 <Rinke> RRSAgent, make records public
16:38:41 <Rinke> ScribeNick: Rinke
16:47:04 <Rinke> Zakim, this will be owlwg
16:47:04 <Zakim> ok, Rinke; I see SW_OWL()1:00PM scheduled to start in 13 minutes
16:54:34 <baojie> baojie has joined #owl
16:55:04 <alanr> alanr has joined #owl
16:55:54 <calvanese> calvanese has joined #owl
16:57:34 <Zakim> SW_OWL()1:00PM has now started
16:57:41 <Zakim> +[IBM_Watson]
16:58:41 <bcuencagrau> bcuencagrau has joined #owl
16:58:45 <Zakim> +??P11
16:58:50 <Rinke> zakim, ??P11 is me
16:58:50 <Zakim> +Rinke; got it
16:58:55 <Rinke> zakim, mute me
16:58:55 <Zakim> Rinke should now be muted
16:59:25 <calvanese> zakim, mute me
16:59:25 <Zakim> sorry, calvanese, I do not know which phone connection belongs to you
16:59:34 <Zakim> +Jonathan_Rees
16:59:38 <calvanese> zakim, IBM_Watson is me
16:59:38 <Zakim> +calvanese; got it
16:59:45 <Zakim> +??P14
16:59:48 <calvanese> zakim, mute me
16:59:48 <Zakim> calvanese should now be muted
16:59:52 <bcuencagrau> Zakim, ??P14 is me
16:59:52 <Zakim> +bcuencagrau; got it
16:59:52 <alanr> zakim, Jonathan_Rees is alanr
16:59:53 <Zakim> +alanr; got it
17:00:04 <alanr> zakim, mute me
17:00:04 <Zakim> alanr should now be muted
17:00:14 <MarkusK> MarkusK has joined #owl
17:00:42 <Achille> Achille has joined #owl
17:00:52 <Zakim> +[IPcaller]
17:00:57 <uli> uli has joined #owl
17:01:05 <Zhe> Zhe has joined #owl
17:01:09 <IanH> IanH has joined #owl
17:01:31 <Zakim> +[IBM]
17:01:43 <Achille> zakim, IBM is me
17:01:43 <Zakim> +Achille; got it
17:01:46 <Zakim> +Zhe
17:01:52 <Zhe> zakim, mute me
17:01:52 <Zakim> Zhe should now be muted
17:01:54 <ivan> ivan has joined #owl
17:01:59 <Zakim> +Ian_Horrocks
17:02:04 <Zakim> +??P6
17:02:06 <alanr> Jonathan Rees is also listening in
17:02:07 <ivan> zakim, dial ivan-voip
17:02:07 <Zakim> ok, ivan; the call is being made
17:02:09 <Zakim> +Ivan
17:02:15 <uli> zakim, ??P6 is me
17:02:15 <Zakim> +uli; got it
17:02:25 <IanH> zakim, Ian_Horrocks is IanH
17:02:25 <Zakim> +IanH; got it
17:02:26 <ivan> zakim, mute me
17:02:26 <Zakim> Ivan should now be muted
17:02:38 <Zakim> +Peter_Patel-Schneider
17:02:47 <uli> zakim, mute me
17:02:47 <Zakim> uli should now be muted
17:02:56 <IanH> zakim, mute me
17:02:56 <Zakim> IanH should now be muted
17:03:08 <Zakim> + +1.202.408.aaaa
17:03:09 <Zakim> +baojie
17:03:11 <IanH> zakim, who is here?
17:03:11 <Zakim> On the phone I see calvanese (muted), Rinke (muted), alanr (muted), bcuencagrau, MarkusK, Achille, Zhe (muted), IanH (muted), uli (muted), Ivan (muted), Peter_Patel-Schneider,
17:03:15 <Zakim> ... +1.202.408.aaaa, baojie
17:03:16 <Zakim> On IRC I see ivan, IanH, Zhe, uli, Achille, MarkusK, bcuencagrau, calvanese, alanr, baojie, RRSAgent, Zakim, Rinke, pfps, sandro, trackbot
17:03:27 <jar> jar has joined #owl
17:03:35 <Zakim> - +1.202.408.aaaa
17:03:39 <alanr> zakim, unmute me
17:03:39 <Zakim> alanr should no longer be muted
17:04:08 <Zakim> + +1.202.408.aabb
17:04:23 <IanH> zakim, who is here?
17:04:23 <Zakim> On the phone I see calvanese (muted), Rinke (muted), alanr, bcuencagrau, MarkusK, Achille, Zhe (muted), IanH (muted), uli (muted), Ivan (muted), Peter_Patel-Schneider, baojie,
17:04:26 <Zakim> ... +1.202.408.aabb
17:04:27 <Zakim> On IRC I see jar, ivan, IanH, Zhe, uli, Achille, MarkusK, bcuencagrau, calvanese, alanr, baojie, RRSAgent, Zakim, Rinke, pfps, sandro, trackbot
17:04:37 <Rinke> who's aabb?
17:04:41 <Rinke> topic: admin
17:04:46 <Rinke> subtopic: roll call
17:04:47 <Zakim> - +1.202.408.aabb
17:04:48 <bcuencagrau> Zakim, mute me
17:04:48 <Zakim> bcuencagrau should now be muted
17:04:55 <Rinke> zakim, who is here?
17:04:55 <Zakim> On the phone I see calvanese (muted), Rinke (muted), alanr, bcuencagrau (muted), MarkusK, Achille, Zhe (muted), IanH (muted), uli (muted), Ivan (muted), Peter_Patel-Schneider,
17:04:58 <Zakim> ... baojie
17:04:59 <Zakim> On IRC I see jar, ivan, IanH, Zhe, uli, Achille, MarkusK, bcuencagrau, calvanese, alanr, baojie, RRSAgent, Zakim, Rinke, pfps, sandro, trackbot
17:05:06 <m_schnei> m_schnei has joined #owl
17:05:07 <alanr> zakim, who is here?
17:05:07 <Zakim> On the phone I see calvanese (muted), Rinke (muted), alanr, bcuencagrau (muted), MarkusK, Achille, Zhe (muted), IanH (muted), uli (muted), Ivan (muted), Peter_Patel-Schneider,
17:05:10 <Zakim> ... baojie
17:05:11 <Zakim> On IRC I see m_schnei, jar, ivan, IanH, Zhe, uli, Achille, MarkusK, bcuencagrau, calvanese, alanr, baojie, RRSAgent, Zakim, Rinke, pfps, sandro, trackbot
17:05:21 <Rinke> subtopic: agenda amendments
17:05:45 <Rinke> PROPOSED: Accept Previous Minutes (6 August)
17:05:53 <IanH> +1
17:05:54 <pfps> they seem acceptable tome
17:05:58 <baojie> +1
17:06:06 <Rinke> +1
17:06:09 <Rinke> RESOLVED: Accept Previous Minutes (6 August)
17:06:19 <Zakim> +??P10
17:06:19 <Rinke> subtopic: pending review actions
17:06:27 <m_schnei> zakim, ??P10 is me
17:06:27 <Zakim> +m_schnei; got it
17:06:31 <m_schnei> zakim, mute me
17:06:31 <Zakim> m_schnei should now be muted
17:06:50 <Rinke> ACTION-171, discussion later in the meeting
17:07:03 <Rinke> ACTION-176, looks done, close the action
17:07:30 <Rinke> ACTION-157, moot, close, robert stevens as ...?
17:07:37 <Rinke> ACTION-178, closed
17:07:49 <IanH> +1
17:07:54 <Rinke> ACTION-162 and ACTION-165 done per emails
17:08:00 <uli> +1
17:08:03 <Rinke> ACTION-173 
17:08:15 <Rinke> alanr: can't remember what this was
17:08:29 <Rinke> alanr: we're ok as far as datatypes go
17:08:36 <Rinke> alanr: close?
17:08:40 <Rinke> ACTION-174
17:08:57 <Rinke> alanr: peter, do you want to comment on this?
17:09:11 <Rinke> pfps: email on annotations has 90% of what's needed for Bijan's stuff
17:09:22 <Rinke> alanr: this is the annotations on annotations stuff, right?
17:09:27 <Rinke> pfps: yup
17:09:42 <Rinke> alanr: you were working with bijan on rich annotations
17:09:48 <Rinke> alanr: what's the outcome of that?
17:10:16 <Rinke> pfps: we consider ACTION-174 at least doesn't need to be done immediately as it is likely to be taken over by events
17:10:27 <Rinke> alanr: not done, anyone any comments?
17:10:32 <Rinke> topic: issues
17:11:05 <Rinke> alanr: proposed was to close ISSUE-129 without action
17:11:16 <Rinke> alanr: we're not closing off the possibility
17:11:41 <IanH> works for me
17:11:50 <Rinke> alanr: suggestions for wording?
17:12:05 <Rinke> alanr: difference between postponing vs. 'no action'?
17:12:18 <pfps> isn't this a chair kind of decision?
17:12:27 <evrensirin> evrensirin has joined #owl
17:12:46 <Rinke> alanr: I'll go for postpone
17:12:47 <Zakim> + +1.202.408.aacc
17:12:47 <alanr> PROPOSED: close Issue 129 as postponed
17:13:07 <pfps> +1
17:13:09 <Rinke> +1
17:13:11 <alanr> +1
17:13:12 <bcuencagrau> +1
17:13:16 <IanH> +1
17:13:16 <uli> +1
17:13:21 <evrensirin> +1
17:13:32 <Achille> +1
17:13:36 <alanr> RESOLVED: close Issue 129 as postponed
17:13:39 <IanH> 202.408 is back!
17:13:41 <evrensirin> +1.202.408.aacc is evrensirin
17:13:43 <Rinke> subtopic: ISSUE-135
17:13:57 <Rinke> alanr: importing rdf without ontology headers
17:13:59 <IanH> zakim, aacc is evrensirin
17:13:59 <Zakim> +evrensirin; got it
17:14:05 <m_schnei> +1 (129 as postponed)
17:14:06 <Rinke> alanr: boris had a proposed solution in email 
17:14:11 <Rinke> alanr: any comments? look good to me
17:14:18 <IanH> +1
17:14:26 <Rinke> Rinke: look good to me as well
17:14:28 <bcuencagrau> +1
17:14:30 <alanr> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0454.html
17:14:33 <uli> +1
17:14:52 <ivan> +1
17:14:59 <evrensirin> +1
17:15:00 <Zhe> +1
17:15:09 <alanr> PROPOSED: close 135 with Boris' note saying it's effectively there already
17:15:13 <Rinke> +1
17:15:17 <pfps> +1
17:15:19 <ivan> +1 (again:-)
17:15:20 <bcuencagrau> +1
17:15:21 <evrensirin> +1
17:15:21 <MarkusK> +1
17:15:22 <IanH> +1
17:15:27 <alanr> note= http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0454.html
17:15:29 <uli> +1
17:15:39 <Zhe> +1 (again)
17:15:47 <alanr> RESOLVED: close 135 with Boris' note http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0454.html
17:15:58 <Rinke> subtopic: ISSUE-104
17:16:04 <Rinke> alanr: disallowed vocabulary
17:16:22 <Rinke> alanr: I discussed this with Ian, the email ref wasn't clear enough
17:16:51 <Rinke> alanr: shouldn't we for clarity explicitly list those terms that are 'in'
17:17:07 <Rinke> alanr: use  reserved instead of disallowed vocabulary
17:17:09 <pfps> q+
17:17:14 <alanr> ack pfps
17:17:20 <Rinke> pfps: I'm going to channel Boris
17:17:40 <Rinke> pfps: should not list the disallowed vocabulary because we could get it wrong
17:18:05 <Rinke> alanr: I meant we should say the disallowed vocabulary is any term in these 4 namespaces instead of the list ...
17:18:13 <pfps> that's OK by me
17:18:14 <Rinke> alanr: we should be as explicit as we can
17:18:31 <Rinke> alanr: any comments on this?
17:18:53 <Rinke> alanr: action someone to write the list
17:19:35 <alanr> PROPOSED: Close 104 saying: Use "disallowed vocabulary" in place of "reserved vocabulary". Then list namespaces from which terms are disallowed and an explicit list of allowed terms as exceptions.
17:19:52 <pfps> q+
17:19:57 <alanr> ack pfps
17:20:19 <Rinke> pfps: in some sense, reserved sounds a bit better, but I understand being consistent with owl 1 is good
17:20:37 <Rinke> alanr: no strong objections... let's vote
17:20:40 <ivan> +1
17:20:41 <Rinke> +1
17:20:41 <pfps> +0.5 because I prefer 'reserved', but I can live with this 
17:20:44 <uli> +1
17:20:45 <MarkusK> +1
17:20:45 <IanH> +1
17:20:46 <evrensirin> +1
17:20:46 <bcuencagrau> +1
17:20:46 <Zhe> 0
17:20:47 <calvanese> +1
17:20:48 <alanr> +1
17:21:00 <alanr> fwiw, I think reserved is better word too...
17:21:23 <alanr> RESOLVED:  Close 104 saying: Use "disallowed vocabulary" in place of "reserved vocabulary". Then list namespaces from which terms are disallowed and an explicit list of allowed terms as exceptions
17:21:41 <Rinke> topic: issue discussions
17:21:47 <evrensirin> q+
17:21:56 <Rinke> alanr: start of with unique name assumptiom (ISSUE-133)
17:21:56 <alanr> ack evrensirin
17:22:29 <Rinke> evrensirin: issue is that there are two maximum subsets. In one you can use key, but then you need UNA. Or you exclude functionality and key, and you can use sameAs
17:22:35 <calvanese> q+
17:22:39 <Rinke> evrensirin: these two cannot be included in the profile at the same time
17:23:19 <Rinke> evrensirin: right now UNA is necessary for dl-lite profile (according to diego\'proposal)
17:23:38 <Rinke> evrensirin: though this is fine in DB, but in linked data use cases you don't want to make UNA
17:23:54 <Rinke> evrensirin: include neither in the profile, but allow the extension
17:24:08 <alanr> ack calvanese
17:24:10 <Rinke> evrensirin: flexible enough for both use cases, but the selection of the extension is left to the tools
17:24:43 <Rinke> calvanese: dl-lite is born in two different versions, one side having functionality and the other roles and inclusion
17:25:04 <Rinke> calvanese: we now have a language that combines both features, but relies on UNA
17:25:29 <Rinke> calvanese: having or not having UNA does not make any difference wrt inference. If you drop functionality and leave UNA in there, you still get the same answers as w/o UNA
17:25:53 <evrensirin> q+
17:25:58 <uli> q+
17:26:02 <Rinke> calvanese: having the UNA actually gives you more than not having it. It captures an intended use case. But if you want to use it in a way that includes functionality, you can use it as if it doesn't make the UNA
17:26:02 <alanr> ack evrensirin
17:26:25 <Rinke> evrensirin: but having UNA is not compatible with my use cases. Having UNA forces everybody to use the UNA even if they don't want it
17:26:28 <alanr> q+
17:26:36 <Rinke> evrensirin: It may not have any observable inferences, then why have it?
17:26:47 <Rinke> calvanese: it allows us to add functionality as well 
17:27:14 <Rinke> calvanese: other point, dl-lite was born to deal with data in databases. For that use case we believe UNA and functionality are both important
17:27:29 <Rinke> calvanese: it's important to have this feature
17:28:05 <Rinke> calvanese: rdf/triple store language users could adopt DL lite in their setting. DL -lite is within owl DL, so it doesn't have any meta-features. So it reduces its use in RDF
17:28:24 <alanr> ack uli
17:28:26 <uli> zakim, unmute me
17:28:26 <Zakim> uli was not muted, uli
17:28:29 <Rinke> calvanese: that's one reason why I would claim that the important use cases come from DB's and not in coming form RDF
17:28:46 <Rinke> uli: I was trying to see clear. I have two choices: 1) functionality + keys, needs UNA
17:29:28 <Rinke> uli: other allows us to have role hierarchies and use sameAs, is a bit more RDF-ish
17:29:41 <evrensirin> q+
17:29:48 <Rinke> uli: so it's not about whether we can drop UNA, you need to have it
17:29:48 <alanr> ack alanr
17:29:59 <Rinke> calvanese: yes, you need the UNA for functionality
17:30:06 <uli> zakim, mute me
17:30:06 <Zakim> uli should now be muted
17:30:16 <calvanese> q+
17:30:17 <Rinke> alanr: what about general compatibility. We have this principle to have the same syntax mean the same thing
17:30:37 <uli> zakim, unmute me
17:30:37 <Zakim> uli should no longer be muted
17:30:50 <Rinke> alanr: should we have some kind of global restriction that says e.g. that you need to make the una explicit by enforcing sameAs 
17:30:56 <alanr> q?
17:30:58 <uli> zakim, mute me
17:30:58 <Zakim> uli should now be muted
17:30:59 <Rinke> alanr: you allow all three, but disallow their combination
17:31:06 <alanr> ack calvanese
17:31:16 <Rinke> calvanese: you could make it, if you have a sameas then that may work
17:31:47 <alanr> o(n)
17:31:59 <Rinke> calvanese: what we need to have this fragment work in the same way than the other profiles, you need to make the uNA explicit. THis is inefficient for databases
17:32:17 <bcuencagrau> +q
17:32:18 <alanr> q+ alanr
17:32:27 <alanr> ack evrensirin
17:32:33 <Rinke> calvanese: have an implicitly represented una, this is given once you have functionality.
17:32:34 <bcuencagrau> Zakim, unmute me
17:32:34 <Zakim> bcuencagrau should no longer be muted
17:32:43 <alanr> ack bcuencagrau
17:32:52 <alanr> you folks have nicks that are too long :)
17:33:13 <alanr> ack alanr
17:33:19 <Rinke> bcuencagrau: if you make the UNA, it's a semantic condition. How would UNA work as semantic condition. Not sure how this is supposed to work
17:33:48 <Rinke> calvanese: imposing that every pair of individuals is different by enforcing assertions
17:34:04 <Rinke> alanr: we can already have a shorthand to make this
17:34:08 <alanr> q?
17:34:10 <Rinke> alanr: for sets of individuals
17:34:28 <Rinke> bcuencagrau: this is a clear set of syntax that you could interpret differently. Switch is a good idea
17:34:38 <Rinke> alanr: have a global switch
17:34:52 <alanr> q?
17:34:56 <calvanese> q+
17:34:57 <Rinke> bcuencagrau: otherwise we need to rig reasoners to recognise the profile and work under the UNA
17:35:04 <alanr> ack calvanese
17:35:04 <Rinke> alanr: could you make a suggestion?
17:35:16 <uli> q?
17:35:28 <Rinke> calvanese: I agree with bernardo, you have a valid ontology for this profile if you have that bit of syntax in there.
17:35:41 <IanH> I am worried that we are now doing language design on the fly.
17:35:55 <bcuencagrau> Zakim, mute me
17:35:55 <Zakim> bcuencagrau should now be muted
17:35:56 <evrensirin> q+
17:36:03 <Rinke> alanr: do we have a way forward, that we can stop the conversation and that the proposal comes up to generalise this
17:36:27 <Rinke> alanr: have a global restriction for functional/keys you need una
17:36:30 <alanr> ack evrensirin
17:36:50 <Rinke> evrensirin: we also want the sameas added to the profile, with the restriction that sameas cannot be used together with functional and una
17:37:02 <Rinke> alanr: we already have that from the global restriction.
17:37:13 <Rinke> evrensirin: I would like to assert that I don't get an inconsitency
17:37:23 <calvanese> q+
17:37:26 <Rinke> alanr: evrensirin do you wnat to draft a proposal with calvanese 
17:37:34 <alanr> ack calvanese
17:37:56 <Rinke> calvanese: if you add same as explicitly, you lose the computational properties (introduces recursive propagation)
17:38:03 <uli> ..but not if you don't have functionality?
17:38:04 <alanr> Action: Diego to come up with proposal for UNA + function in language by global restriction, with Mike or Evren
17:38:05 <trackbot> Created ACTION-192 - Come up with proposal for UNA + function in language by global restriction, with Mike or Evren [on Diego Calvanese - due 2008-08-20].
17:38:11 <Rinke> evrensirin: don't agree, you can preprocess the sameas assertion at the beginning
17:38:18 <alanr> q?
17:38:48 <alanr> gentlemen?
17:39:00 <Rinke> calvanese: you lose computational property nonetheless
17:39:12 <Rinke> evrensirin: but you only do it once
17:39:21 <Rinke> alanr: work this out in your conversation
17:39:29 <Rinke> subtopic: ISSUE-136
17:39:32 <m_schnei> zakim, unmute me
17:39:32 <Zakim> m_schnei should no longer be muted
17:39:39 <Rinke> alanr: m_schnei could you remind us please
17:40:04 <Rinke> m_schnei: we had in owl 1 only these different individuals, now we also have disjoint classes and properties
17:40:04 <calvanese> zakim, mute me
17:40:04 <Zakim> calvanese should now be muted
17:40:11 <uli> you sound muffled
17:40:20 <IanH> More muffled than quiet
17:40:32 <Rinke> m_schnei: we have three different n-ary axioms. 
17:40:46 <Rinke> m_schnei: in owl 1 we had only one, distinctmembers
17:41:03 <alanr> is anyone else having trouble with access to the wiki?
17:41:06 <Rinke> m_schnei: now we have owl:member for everything else, I suggest owl:member to be used for owl:allDifferent and the 
17:41:16 <evrensirin> q+
17:41:18 <Rinke> m_schnei: rest ... (?)
17:41:22 <alanr> ack evrensirin
17:41:49 <Rinke> evrensirin: I think that it would be good to have one term and combine the different things. Wouldn't it be a backwards-compatibility issue?
17:42:07 <Rinke> evrensirin: owl 1.0 would no longer be able to use rewritten axioms
17:42:12 <alanr> is that backwards or forwards compat?
17:42:16 <Rinke> evrensirin: not sure whether simplification outweighs this
17:42:29 <m_schnei> that's forward compatibility, if at all
17:42:47 <Rinke> alanr: we need to get a compatibility person, ivan?
17:42:48 <m_schnei> zakim, mute me
17:42:48 <Zakim> m_schnei should now be muted
17:42:49 <ivan> zakim, unmute me
17:42:50 <Zakim> Ivan should no longer be muted
17:42:51 <uli> zakim, mute me
17:42:51 <Zakim> uli was already muted, uli
17:43:16 <Rinke> ivan: I was looking at the old document, and owl:member is only in 1.1. I'm not sure I understand evren's problem
17:43:28 <IanH> No! only one choice - new.
17:43:42 <Rinke> alanr: you have two choices in OWL2, if it chooses the new, then ... oh
17:43:43 <m_schnei> zakim, unmute me
17:43:43 <Zakim> m_schnei should no longer be muted
17:43:51 <Rinke> alanr: m_schnei were you adding something?
17:43:52 <IanH> q+
17:43:57 <alanr> ack ian
17:43:58 <IanH> zakim, unmute me
17:43:59 <Zakim> IanH was not muted, IanH
17:44:00 <Rinke> m_schnei: adding! 
17:44:12 <evrensirin> the problem is OWL 1 tool would not be able to process an OWL 1 ontology generated by an OWL2 tool
17:44:13 <ivan> that is how I understood
17:44:13 <Rinke> m_schnei: you can also use the members property ....
17:44:14 <m_schnei> zakim, mute me
17:44:14 <Zakim> m_schnei should now be muted
17:44:52 <Rinke> IanH: what you said, alan, was that when serialising OWL 2 there would be a choice between the two options. don't think that would be the intention, and if so I strongly disagree
17:45:02 <m_schnei> +1 to deterministic. so serializing would bring *new* term, right. That's forward compatibility issue
17:45:19 <IanH> zakim, mute me
17:45:19 <Zakim> IanH should now be muted
17:45:20 <Rinke> IanH: it would be definately the case loading an ontologiy in OWL1 tool won't work
17:45:42 <Rinke> alanr: there are other examples of this, aren't there? 
17:46:06 <ivan> q+
17:46:12 <alanr> ack ivan
17:46:15 <Rinke> alanr: is the analogy correct, or is this a stronger issue?
17:47:07 <Rinke> ivan: IanH is right if the serialisation keeps to the new terminology only, however, if it uses the old vocab to stay compatible. We can use separate terms in RDF serialisation to remain compatible, and translate it back correctly to the FS
17:47:17 <m_schnei> ah yes, i did not say enything about what *must* be serialized
17:47:22 <Rinke> alanr: the old serialisation be used for the old cases, and the new be used for the new cases
17:47:35 <Rinke> ivan: if you write in rdf you have the choice of using both
17:48:00 <Rinke> ivan: indeed, if you write an OWL2 ontology in rdf, you might write something that won't work with an OWL1 environment
17:48:14 <Rinke> alanr: the action on this would be a minor change to the reverse mapping, do I have that right peter?
17:48:18 <Rinke> pfps: maybe
17:48:34 <m_schnei> right, this would only have a meaning for the reverse mapping
17:48:37 <Rinke> alanr: if it is just a change to the reverse mapping to get this done, could we get a strawpoll?
17:48:53 <ivan> +1
17:48:54 <m_schnei> 1
17:48:54 <pfps> -0.5
17:48:54 <Rinke> alanr: STRAWPOLL
17:48:56 <baojie> 0
17:48:59 <evrensirin> -0
17:48:59 <Zhe> 1
17:49:01 <Rinke> +0.5
17:49:04 <alanr> +.5
17:49:05 <uli> 0
17:49:06 <MarkusK> 0
17:49:07 <IanH> 0
17:49:09 <bcuencagrau> 0
17:49:17 <Achille> 0
17:49:41 <ivan> -1
17:49:42 <pfps> -1
17:49:42 <uli> -1
17:49:43 <evrensirin> -1
17:49:44 <Rinke> STRAWPOLL: if it's a more work, is it worth pursuing
17:49:44 <IanH> -1
17:49:46 <pfps> -1
17:49:48 <m_schnei> -1
17:49:49 <MarkusK> -1
17:49:50 <Rinke> -1
17:49:51 <alanr> -1
17:49:56 <Zhe> -01
17:49:58 <Zhe> -1
17:50:22 <IanH> Yes, Peter is willing to do that.
17:50:26 <Rinke> alanr: would somebody be willing to have a look at the mapping to see what the change would have to be? So that we can at least make a decision based on the fact
17:50:29 <Rinke> s
17:50:36 <pfps> what, me override??
17:50:45 <pfps> no
17:50:47 <Rinke> alanr: or, peter is your objection strong?
17:50:51 <m_schnei> yes
17:51:00 <m_schnei> I raised it. so I have to do it
17:51:05 <Rinke> alanr: would you be willing? m_schnei ?
17:51:13 <alanr> action: m_schnei to look into reverse mapping change for issue 136
17:51:13 <trackbot> Sorry, couldn't find user - m_schnei
17:51:24 <m_schnei> q+
17:51:29 <Rinke> action: michael to look into reverse mapping change for issue 136
17:51:29 <trackbot> Sorry, amibiguous username (more than one match) - michael
17:51:29 <trackbot> Try using a different identifier, such as family name or username (eg. msmith9, mschneid, msintek)
17:51:31 <m_schnei> q-
17:51:43 <Rinke> topic: general discussion
17:52:01 <Rinke> alanr: two subjects, we can also spend some time on OWL RL
17:52:09 <Rinke> alanr: there's some mail traffic about annotations
17:52:32 <Rinke> alanr: we have quite a reasonable amount of annotations. We have a couple of priority features, on the list as being desirable
17:52:51 <Rinke> alanr: the subproperty relations between annotation properties and domains and ranges are not supported
17:53:05 <Rinke> alanr: also important to make SKOS compatible with OWL DL (as SKOS uses these)
17:53:33 <Rinke> alanr: we have been postponing annotations until we got to the point that the generalised rich annotations aren't going to be there
17:54:08 <Rinke> alanr: one more thing, we had a discussion about this at F2F2 where it was thought that having RA's is good even if it affects the schedule
17:54:18 <Rinke> alanr: what ideas do we have for accommodating these features
17:54:18 <alanr> q?
17:54:31 <alanr> q+
17:54:45 <Rinke> alanr: put myself on the queue, offer some choices
17:55:24 <Rinke> alanr: 1) use the mapping proposal that pfps and bijan were going to do. Fairly well specified, close to being able to do this... two ontologies coming out of the same ontology document (annotaiton ontology, and main ontology)
17:55:44 <Rinke> alanr: we need new blood on this, will volunteer myself
17:56:21 <Rinke> alanr: 2) how to support just these features without the generalised annotations which I think would require .... (?) ... from people more into DL. 
17:56:52 <Rinke> alanr: global domain and range restrictions, having ... work with that
17:56:59 <Rinke> i can hear now
17:57:04 <Zhe> q+
17:57:10 <Zhe> zakim, unmute me
17:57:10 <Zakim> Zhe should no longer be muted
17:57:15 <alanr> not use annotations in restrictions
17:57:16 <pfps> q+
17:57:28 <Rinke> Zhe: isn't there another option not to spec it at all
17:57:54 <Rinke> alanr: that is a proposal that has been ... it's a very longstanding request
17:57:55 <alanr> ack alanr
17:57:58 <alanr> ack Zhe
17:58:26 <Rinke> Zhe: to us this is very complex and hard to implement this in a scalable fashion. Unlikely that we will be able to support this
17:58:28 <alanr> ack pfps
17:58:37 <pfps> +1 to Zhe
17:58:56 <Rinke> pfps: I put myself on to agree with Zhe 
17:59:18 <IanH> q+
17:59:27 <IanH> zakim, unmute me
17:59:27 <Zakim> IanH should no longer be muted
17:59:28 <alanr> ack Ian
17:59:34 <Rinke> alanr: mixed properties, if you didn't allow annotations in restrictions whether subproperties became possible (question to uli)
18:00:29 <alanr> q+ alanr
18:00:33 <alanr> ack alanr
18:00:39 <uli> q+
18:00:39 <Rinke> IanH: thinking of what Zhe said... what he said was not spec it, basically you could achieve most of what you want to achieve already with the current features. One options is not to spec it, in the sense that you do not include it in a MUST be supported part of the spec. To not force people like Zhe to implement it
18:00:59 <Rinke> alanr: that's the same strategy as with n-ary. If you're going to do it, then this is the way to do it
18:01:03 <pfps> q+
18:01:05 <uli> zakum, unmute me
18:01:06 <alanr> ack uli
18:01:11 <Rinke> alanr: not fond of this, in my experience they don't come to be
18:01:38 <alanr> Missing: Subproperties on annotations, domains and ranges of them.
18:02:27 <evrensirin> +1 for Uli
18:02:28 <Rinke> uli: we now have a large proposal that allows almost anything users have asked for. Like zhe said, we wouldn't explain what has to be done about them. This is where bijan's proposal slightly fell over. Now I'm guessing, but we could even put in there that some property could be a subproperty of an annotation property.... you'd be fine
18:02:39 <IanH> The other trouble with rich annotations is that there are *many* ways that it could be done; it's not at all clear which is the right one; there is *zero* implementation experience.
18:02:46 <Rinke> alanr: you could have an *optional* specification, but a full specification?
18:02:57 <Rinke> uli: we don't even need to spec this, it's already almost in there
18:03:09 <Zhe> q+
18:03:18 <alanr> ack pfps
18:03:19 <Rinke> alanr: if we don't spec things, they're not really there. Experience with optional... not a raging succes
18:03:24 <Rinke> uli: peter will clarify
18:03:25 <uli> zakum, mute me
18:03:51 <IanH> +1 -- as I said above
18:03:52 <alanr> We're behind
18:04:13 <uli> +1 to Peter
18:04:14 <alanr> q+
18:04:15 <Rinke> pfps: I agree with uli, it is premature to state how these things should be use. I don't see any significant usage and processing model. Why are we running so far ahead on something that is primarily a tool issue. Let's put it in the spec, and see what the tools do
18:04:18 <Rinke> +1
18:04:35 <alanr> no body *can* do it
18:04:39 <alanr> q?
18:04:40 <Rinke> pfps: nobody's doing it yet, why force it on them?
18:04:43 <alanr> Ack Zhe
18:05:03 <Rinke> Zhe: i truly agree with peter. Annotatiosn on annotations are just too complex for ordinary users.
18:05:14 <alanr> ack zhe
18:05:38 <Rinke> alanr: we're not actually talking about annotations on annotations. We're talking about features already possible in OWL RL
18:06:14 <Rinke> alanr: subproperties of annotations etc. That's more crucial: we really only need one level of annotations on annotations, but we've also got clear cases for subproperties and domain/ranges
18:06:23 <Rinke> alanr: both historically and now with SKOS
18:06:36 <alanr> q?
18:06:43 <Rinke> Zhe: for that kind of simple things, developers can do it in their applications instead of putting it in the spec.
18:07:09 <Rinke> alanr: well, I guess, don't know why this is true on this and not on other parts of the spec
18:07:15 <pfps> q+
18:07:17 <m_schnei> I just created ACTION-193: "m_schnei to look into reverse mapping change for issue 136"
18:07:19 <alanr> ack alanr
18:07:30 <Rinke> alanr: the things I'm suggesting are already going to be in OWL RL. I am proposing to have them in OWL DL
18:07:51 <Rinke> pfps: skos:comment subproperty of rdfs:label going to be in OWL RL?
18:08:16 <Rinke> Zhe: isnt RL in DL?
18:08:24 <Rinke> alanr: no, because we're talking annotation properties here
18:08:46 <Rinke> pfps: skos:prefLabel subproperty of rdfs:label going to be in OWL RL?
18:08:55 <Rinke> alanr: next subject
18:09:10 <Rinke> subtopic: conformance, warnings, errors
18:09:22 <Rinke> alanr: I guess there was some discussion on this last week
18:09:38 <Rinke> alanr: two aspects, 1) what it means to be conformant/compliant OWL RL implementation
18:09:51 <Rinke> alanr: ian responded... we haven't discussed this
18:10:04 <Rinke> alanr: 2) what to do, should there be an error, or 'it should not be the case that'
18:10:19 <Rinke> alanr: we don't have mike and bijan here who have been thinking the most about this
18:10:22 <alanr> q?
18:10:25 <Rinke> alanr: start the discussion nonetheless
18:10:32 <pfps> q-
18:10:49 <IanH> q+
18:10:54 <alanr> ack Ian
18:11:03 <Rinke> alanr: what wording would we use to say what a compliant RL implementation
18:11:15 <Rinke> IanH: you picked the hardest case now on discussion
18:11:24 <alanr> pointer?
18:11:27 <Rinke> IanH: look at existing owl test document. there's a section on conformance
18:11:38 <Rinke> IanH: on parser, fragment, profile, reasoner and so on
18:11:55 <Rinke> IanH: we need something relatively similar to that. for most of the fragments/profiles that's relatively straightforward
18:12:05 <Rinke> IanH: we can copy and paste what it says there
18:12:22 <Rinke> IanH: where should it go? And OWL RL is slightly more complicated
18:13:08 <alanr> http://www.w3.org/TR/owl-test/#scope
18:13:22 <Rinke> IanH: I'm happy to discuss...in a way if people haven't looked at the old test document, I don't know whether having a discussion is very usefull
18:13:24 <alanr> http://www.w3.org/TR/owl-test/#conformance
18:13:35 <Rinke> s/usefull/useful
18:13:47 <ivan> I think that the one, Alan
18:14:13 <Rinke> alanr: these are phrased in terms of consistency with respect to a datatype map, where the map is a variable. Is that still relevant?
18:14:31 <Rinke> IanH: we can tighten this up, because we're going into a lot more detail wrt. the datatype map
18:14:42 <Rinke> IanH: that makes things a lot easier. The flavour would still be the same
18:14:52 <Rinke> alanr: thinking of actions on getting things going
18:15:06 <Rinke> alanr: for the owl RL completeness is a different question than for owl DL
18:15:32 <Rinke> IanH: owl RL completeness, there's a discussion going on there now, not keen on saying whats 'proposed'
18:15:54 <Zhe> q+
18:16:05 <Rinke> IanH: for OWL RL there would be a conformance statement, and the OWL RL one might be a slightly different form than the others if one of the current proposals will be accepted
18:16:08 <alanr> ack Zhe
18:16:56 <Rinke> Zhe: vendor perspective. The bare minimum that we can accept, if we implement the set of rules as in the spec, we must be able to claim that we are OWL RL compliant. Independent of how we define completeness
18:17:07 <IanH> Understood -- this is the intention.
18:17:14 <uli> ...there is an ongoing discussion
18:17:15 <Rinke> alanr: anybody working on this right now? do we have any actions?
18:17:45 <Rinke> alanr: sufficient to put together a proposal to get a section started on this
18:17:50 <Rinke> IanH: I'm willing to draft a proposal
18:17:55 <Rinke> alanr: I'll action you
18:17:59 <alanr> Action: Ian to come up with a proposal for conformance
18:17:59 <trackbot> Created ACTION-194 - Come up with a proposal for conformance [on Ian Horrocks - due 2008-08-20].
18:18:18 <Rinke> IanH: don't think its' all that difficult/controversion (except perhaps the RL debate)
18:18:33 <Rinke> subtopic: ISSUE-137
18:18:42 <Rinke> alanr: any questions about it?
18:19:18 <Rinke> alanr: in owl 1 you could use rdfs:Class as long as the entity is an owl:Class somewhere in the imports closure
18:19:29 <Rinke> alanr: in owl 2 these shoul be in the *same* document.
18:19:34 <Rinke> s/shoul/should
18:20:02 <alanr> q?
18:20:05 <Rinke> alanr: the simplest repair would be to not have it be that you not have rdfs:Class triples on their own
18:20:15 <Rinke> alanr: peter is working on that
18:20:23 <Rinke> alanr: do you agree this is the simplest repair?
18:20:35 <Rinke> pfps: it's indeed a backwards compatibility issue, but not simple
18:20:56 <Rinke> alanr: what are the issues?
18:21:15 <Rinke> pfps: the whole structure of the reverse mapping works on documents, as far as I remember
18:21:21 <Rinke> pfps: let me see
18:21:30 <Rinke> pfps: dedadedadeda
18:21:34 <Rinke> pfps: diededie
18:21:36 <alanr> My proposal: Reverse mapping removes any occurrance of :foo rdf:type rdfs:Class
18:22:11 <Rinke> pfps: either the reverse mapping works on graphs (then a lot of changes) in a single document, or it works on multiple graphs in multiple documents
18:22:28 <Rinke> pfps: if it works on single documents, then major changes need to be made
18:22:34 <IanH> zakim, mute me
18:22:34 <Zakim> IanH should now be muted
18:22:35 <m_schnei> q+
18:22:39 <Rinke> alanr: what about simply removing all rdfs:Class 
18:22:40 <m_schnei> zakim, unmute me
18:22:40 <Zakim> m_schnei should no longer be muted
18:22:40 <alanr> ack m_schei
18:23:19 <Rinke> m_schnei: i didn't look at your problem. I checked the mapping some weeks ago. there's a table with reverse mapping where these rdfs:Classes exist in an old ontology. 
18:23:45 <pfps> q+
18:23:53 <alanr> ack m_schnei
18:23:56 <alanr> ack pfps
18:24:06 <Rinke> alanr: when you see (table 4) rdfs:Class and type owlClass both, then you remove the rdfsClass. I propose to change the mapping to also remove the rdfsClass if it's on its own
18:24:15 <m_schnei> zakim, mute me
18:24:15 <Zakim> m_schnei should now be muted
18:24:21 <Rinke> pfps: indeed technically easy, but whether it's the right thing to do is an entirely different manner
18:24:27 <Rinke> pfps: it's the wrong thing to do
18:24:40 <Rinke> pfps: because you might take documents .... eh... that's a good question
18:24:46 <Rinke> pfps: dudeduh
18:25:10 <Rinke> pfps: I fear that you may do fairly drastic surgery to the status of certain documents
18:25:40 <Rinke> alanr: action, to see what/how.. anytime before going to last call
18:25:56 <Rinke> alanr: we need to close it, look into it
18:26:34 <Rinke> pfps: we have looked into it, don't believe it ever occurred in existing ontologies. It's a minor backward compatibility issue that the chairs will have to mention somewhere 
18:27:05 <Rinke> alanr: let's think on this, and if you feel like looking more closely ... if not, perhaps someone else?
18:27:13 <Rinke> topic: AAB?
18:27:25 <Rinke> ADJOURNED
18:27:25 <Zhe> thanks.
18:27:28 <m_schnei> bye
18:27:29 <Zakim> -uli
18:27:29 <calvanese> bye, thank you
18:27:30 <Zakim> -alanr
18:27:30 <Zakim> -Achille
18:27:31 <Zakim> -MarkusK
18:27:32 <Zakim> -IanH
18:27:32 <Rinke> bye, thanks
18:27:33 <Zakim> -Ivan
18:27:34 <Zakim> -Zhe
18:27:36 <Zakim> -evrensirin
18:27:38 <Zakim> -Peter_Patel-Schneider
18:27:40 <Zakim> -calvanese
18:27:41 <Zakim> -Rinke
18:27:51 <calvanese> quit
18:27:53 <Zakim> -baojie
18:27:54 <alanr> Action: Alan to look in to what happens with OWL-R ruleset applied to annotation properties with subproperty axioms
18:27:54 <trackbot> Created ACTION-195 - Look in to what happens with OWL-R ruleset applied to annotation properties with subproperty axioms [on Alan Ruttenberg - due 2008-08-20].
18:28:00 <alanr> s/OWL-R/OWL-RL/
18:28:03 <calvanese> calvanese has left #owl
18:28:10 <Rinke> Rinke has joined #owl
18:28:17 <Rinke> RRSAgent, pointer?
18:28:17 <RRSAgent> See http://www.w3.org/2008/08/13-owl-irc#T18-28-17
18:28:21 <alanr> alanr has left #owl
18:28:45 <Zakim> -bcuencagrau
18:28:47 <Zakim> -m_schnei
18:28:47 <Zakim> SW_OWL()1:00PM has ended
18:28:48 <Zakim> Attendees were Rinke, calvanese, bcuencagrau, alanr, MarkusK, Achille, Zhe, Ivan, uli, IanH, Peter_Patel-Schneider, +1.202.408.aaaa, baojie, +1.202.408.aabb, m_schnei,
18:28:51 <Zakim> ... +1.202.408.aacc, evrensirin
18:32:11 <alanr> alanr has joined #owl
18:32:24 <alanr> alanr has left #owl
20:29:25 <Zakim> Zakim has left #owl