Please justify/explain all edits to this page, in your "edit summary" text.
<sandro> Present: Evan, msmith, mschnei, haase, zhe, sandro, ruttenberg, ian, boris, pfps, Miroslav, Achille, JonathanRees, Jie <sandro> Remote: rob, bijan, uli, Carsten, Deborah, Karen 12:49:29 <RRSAgent> RRSAgent has joined #owl 12:49:29 <RRSAgent> logging to http://www.w3.org/2008/07/28-owl-irc 12:49:35 <pfps> zakim, this is owl 12:49:35 <Zakim> pfps, I see SW_OWL()8:00AM in the schedule but not yet started. Perhaps you mean "this will be owl". 12:49:47 <pfps> zakim, this will be owl 12:49:47 <Zakim> ok, pfps; I see SW_OWL()8:00AM scheduled to start 49 minutes ago 12:55:08 <pfps> zakim, who is on the phone 12:55:08 <Zakim> I don't understand 'who is on the phone', pfps 12:55:37 <IanH> IanH has joined #owl 12:56:29 <IanH> RRSAgent, make records public 12:58:35 <Zakim> SW_OWL()8:00AM has now started 12:58:37 <Zakim> + +1.617.253.aaaa 12:59:31 <bparsia> bparsia has joined #owl 13:00:12 <m_schnei> m_schnei has joined #owl 13:00:46 <Zakim> +??P7 13:00:50 <bparsia> zakim, ??p7 is me 13:00:50 <Zakim> +bparsia; got it 13:00:53 <bparsia> zakim, mute me 13:00:53 <Zakim> bparsia should now be muted 13:01:01 <ekw> ekw has joined #owl 13:01:21 <bparsia> omit: I'm in 13:01:24 <bparsia> zakim, unmute me 13:01:24 <Zakim> bparsia should no longer be muted 13:01:50 <bparsia> zakim, mute me 13:01:50 <Zakim> bparsia should now be muted 13:03:12 <bmotik> bmotik has joined #owl 13:03:26 <pfps> ScribeNick: pfps 13:04:16 <pha> pha has joined #owl 13:06:22 <pfps> Topic: Welcome, local arrangements, introductions (9-9:15) 13:11:10 <pfps> alanr: dinner possibilities - black sheep / elephant walk 13:12:08 <pfps> alanr: elephant by acclamation 13:12:45 <pfps> alanr: other local arrangements? 13:12:57 <pfps> alanr: leaving times 13:13:21 <pfps> pfps: 5ish 13:13:34 <sandro> peter -- taxi south station 5ish 13:13:49 <alanr> alanr has joined #owl 13:13:53 <sandro> evan, michael -- taxi to airport 5ish 13:14:03 <msmith> msmith has joined #owl 13:14:35 <Zhe> Zhe has joined #owl 13:15:41 <pfps> alanr: scribing? 13:16:10 <pfps> datatype session - m_schneider 13:16:17 <pfps> annotations - boris 13:16:27 <pfps> profiles - evan 13:17:42 <pfps> omit: introductions 13:18:07 <IanH> q? 13:20:49 <bijan> omit: Fine 13:21:19 <bijan> zakim, unmute me 13:21:19 <Zakim> sorry, bijan, I do not know which phone connection belongs to you 13:21:26 <sandro> zakim, who is on the call? 13:21:26 <Zakim> On the phone I see +1.617.253.aaaa, bparsia (muted) 13:21:40 <bparsia> zakim, unmute me 13:21:40 <Zakim> bparsia should no longer be muted 13:21:48 <alanr> alanr has joined #owl 13:21:54 <bparsia> zakim, mute me 13:21:54 <Zakim> bparsia should now be muted 13:22:43 <pfps> alanr: schedule change - move datatypes earlier - no complaints voiced 13:22:44 <sandro> Jie is missing 13:23:03 <pfps> alanr: we may start on datatypes early 13:23:23 <pfps> alanr: karen meyers may come for discussion on profile names 13:23:41 <pfps> alanr: tomorrow's schedule is on tomorrow 13:24:14 <pfps> Topic: Roadmap, Publication Schedule 13:24:25 <pfps> alanr presents some slides 13:24:35 <pfps> alanr: where are we (in schedule) 13:24:57 <pfps> alanr: 9.5 months in 13:25:07 <pfps> alanr: when can we do last call (on what documents) 13:25:59 <pfps> alanr: try for last call decision on core documents at next F2F (late Oct) 13:26:11 <pfps> alanr: last call documents published immediately after 13:26:24 <bparsia> For the record, I've delayed working on the primer (a bit) in order to let the core documents to settle. I could synch or I could stagger its last call. (Requirement document will need some primer lovin' as well.) 13:26:51 <pfps> ianh: we want review before F2F so the F2F would be a vote on the documents as reviewed 13:27:16 <pfps> sandro: last call means that we have closed all relevant issues 13:27:47 <pfps> sandro: we could have multiple possibilities ready beforehand 13:28:14 <pfps> ianh: why not beforehand? 13:28:26 <pfps> sandro: some issues may need a final F2F discussion 13:28:41 <pfps> m_schneider: sounds realistic 13:28:56 <bparsia> xml syntax too, would be nice 13:29:11 <pfps> alanr: core documents = syntax, semantics, full semantics, RDF mapping, profiles 13:29:36 <pfps> alanr: goal try to close issues on these by F2F4 13:29:49 <pfps> alanr: full semantics - try for WD in 3 weeks 13:30:50 <bparsia> q+ 13:30:50 <pfps> alanr: requirements - try for first WD in 4 weeks 13:31:09 <pfps> alanr: quick guide - try for first WD in ? weeks 13:31:28 <bparsia> q- 13:31:37 <pfps> alanr: WD for other documents if there is significant change 13:31:51 <pfps> alanr: this means syntax (at least) 13:32:10 <pfps> msmith: what about test document 13:32:38 <pfps> alanr: need to come up with estimate - need time in F2F (45min?) 13:32:44 <pfps> msmith: 45 min seems OK 13:33:20 <pfps> alanr: any comments? 13:33:30 <pfps> sandro: this requires rapid progress 13:33:48 <pfps> alanr: we may be "over the hump" on many thorny issues 13:34:02 <Achille> Achille has joined #owl 13:34:13 <pfps> ianh: there are a few sticky issues that have been hanging around 13:34:32 <pfps> ianh: if we succeed on progressing in these then we should be OK 13:34:50 <pfps> alanr: there is writing involved (e.g., in profile) 13:35:19 <pfps> ianh: we need to have WG members who can do review step up and do it 13:35:52 <pfps> m_schneider: what does LC mean? 13:36:09 <pfps> ianh: LC documents mean that we think the document is done 13:36:29 <bparsia> LC documents mean we think the *technical design* is done 13:36:34 <bparsia> Editorial changes post LC are fine 13:37:01 <pfps> sandro: polishing can be done after LC, particularly in response to comments 13:37:13 <bparsia> Example of kosher LC change: We change all the examples in the syntax document. Or we reorganize it 13:37:36 <pfps> m_schneider: LC for profiles can be without polish 13:37:46 <bparsia> Example of nonkoser LC change: We change floats from being non-disjoint to disjoint with owl:number 13:38:01 <bparsia> (Where kosher means doesn't require another LC round.) 13:38:03 <pfps> alanr: this is possible, but not desirable, we should try for readable documents 13:38:28 <pfps> msmith: some polish can be contentious 13:38:35 <bparsia> q+ 13:39:02 <pfps> ianh: polishing after LC should be in response to comments - other polish is not desirable 13:39:35 <pfps> m_schneider: this means that feature freeze is end of September 13:39:45 <sandro> q? 13:39:45 <pfps> ianh: yes, but we may be close 13:39:56 <bparsia> zakim, unmute me 13:39:56 <Zakim> bparsia should no longer be muted 13:40:39 <pfps> bparsia: what triggers a return to LC - editorial change is generally not a problem 13:41:02 <pfps> alanr: what is grounds for objection - let's try not to push the envelope 13:41:26 <bparsia> zakim, mute me 13:41:26 <Zakim> bparsia should now be muted 13:41:27 <pfps> bparsia: let's do our best, but significant delay into LC for editorial work is not desirable 13:41:39 <Rinke> Rinke has joined #owl 13:41:41 <pfps> m_schneider: what are the stages of recommendation 13:41:55 <pfps> alanr: closer to the end, more people look at us 13:42:05 <pfps> sandro: LC = we are done, everyone look at it 13:42:10 <bparsia> Getting to CR will update the implementations. We want that sooner rather than later 13:42:19 <pfps> sandro: CR = people should do implementations 13:42:34 <pfps> sandro: PR = waiting for stamp of approval 13:42:53 <pfps> sandro: R = stamped, signed, sealed, and DONE 13:42:57 <bparsia> We can waste enormous amounts of time painting the bikeshed, i.e., debating but not interestingly improving things. I'd rather not burn people out, more :) 13:43:41 <pfps> alanr: now switch to datatypes (early) 13:44:02 <pfps> Topic: Datatypes 13:44:17 <pfps> alanr: what is the current status? 13:44:40 <pfps> alanr: last teleconference had quite a bit of consensus 13:44:59 <bparsia> omit: Is there still talking? 13:45:04 <pfps> alanr: see http://www.w3.org/2007/OWL/meeting/2008-07-16#Normative_datatypes 13:45:08 <bparsia> omit: Ok, there we are 13:45:52 <pfps> see also http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0306.html 13:46:01 <bparsia> This is number+ right? 13:46:10 <bparsia> Floats not integer 13:46:38 <pfps> alanr: number+ is reals plus NaN, +inf, -inf, +0, -0 13:47:19 <pfps> evan: the mapping from lexical to value appears to be missing 13:47:55 <pfps> boris: value space is the thing, lexical space is how they are written 13:48:10 <pfps> evan: but what is the mapping? 13:48:45 <pfps> alanr: see functions and relation documents - there are coercion functions there - just use these as appropriate 13:49:01 <pfps> alanr: thus we have a value space of the number line 13:49:29 <pfps> evan: but how is the mapping defined 13:50:09 <pfps> alanr: we are mixing a bit, xsd:integer is both on the lexical and value sides 13:50:43 <pfps> boris: RDF literals are string (e.g., 123) and URI (e.g., xsd:integer) 13:51:01 <rob> rob has joined #owl 13:51:02 <pfps> boris: but this URI is *not* the datatype! 13:51:29 <pfps> alanr: can we have a better presentation? 13:51:35 <Zakim> +??P3 13:51:37 <pfps> boris: be explicit 13:51:47 <pfps> ianh: we have to go this way because of RDF 13:52:15 <IanH> zakim, who is here? 13:52:15 <Zakim> On the phone I see +1.617.253.aaaa, bparsia (muted), ??P3 13:52:16 <Zakim> On IRC I see rob, Rinke, Achille, alanr, Zhe, msmith, pha, bmotik, ekw, m_schnei, bparsia, IanH, RRSAgent, Zakim, pfps, ewallace, sandro, trackbot 13:52:36 <pfps> alanr: can we have all value spaces in owl: and lexical spaces in xsd: 13:52:50 <IanH> Is it the case that ??P3 is you Rob? 13:53:08 <IanH> yes 13:53:27 <IanH> Uli -- are you on the phone? 13:53:34 <sandro> q? 13:53:42 <bparsia> q- 13:54:02 <pfps> jonathan: worry about losing information from RDF to OWL 13:54:05 <Zakim> +??P4 13:54:17 <rob> zakim, =??P4 is me 13:54:17 <Zakim> sorry, rob, I do not recognize a party named '=??P4' 13:54:29 <rob> zakim, +??P4 is me 13:54:29 <Zakim> sorry, rob, I do not recognize a party named '+??P4' 13:54:35 <IanH> zakim, ??P4 is rob 13:54:35 <Zakim> +rob; got it 13:54:36 <uli> uli has joined #owl 13:54:38 <pfps> boris: just need to say how to interpret URI as a constant URI and URI as a value space 13:54:45 <rob> zakim, mute me 13:54:45 <Zakim> rob should now be muted 13:54:48 <bparsia> What's the worry about losing information please? 13:54:48 <IanH> zakim, who is here? 13:54:48 <Zakim> On the phone I see +1.617.253.aaaa, bparsia (muted), ??P3, rob (muted) 13:54:49 <Zakim> On IRC I see uli, rob, Rinke, Achille, alanr, Zhe, msmith, pha, bmotik, ekw, m_schnei, bparsia, IanH, RRSAgent, Zakim, pfps, ewallace, sandro, trackbot 13:54:54 <Carsten> Carsten has joined #owl 13:55:06 <pfps> sandro: datatype is a triple - we need to point to the explicit bit of this 13:55:11 <uli> zakim, ??P3 is me 13:55:11 <Zakim> +uli; got it 13:55:14 <uli> q- 13:55:26 <IanH> ack ??P3 13:55:36 <pfps> boris: yes, the document can be structured in this way 13:55:39 <IanH> q? 13:56:09 <pfps> achille: what is relationship between owl: value spaces and xsd: value spaces 13:56:25 <baojie> baojie has joined #owl 13:56:39 <pfps> achille: should we be clearer in comparison with xsd 13:56:54 <sandro> q? 13:57:00 <pfps> achille: if we diverge from xsd we need to be very clear where and how 13:57:16 <bparsia> So this isn't too hard, right? xsd:decimal value space is a subset of OWL number's value space, so is xsd:float, etc. 13:57:17 <bparsia> ? 13:57:57 <sandro> pfps: We use the TERM "value space" the same as XSD does, but we have a DIFFERENT value space than XML Schema does, for some datatypes. 13:58:04 <pfps> alanr: we have a different set of value spaces 13:58:23 <sandro> s/Peter/pfps/ 13:58:35 <sandro> q? 13:58:37 <pfps> boris: we are very close to how they do it 13:58:41 <rob> I'm having trouble hearing, but I don't see why OWL should use XSD at *all* for its "value spaces". 13:59:17 <IanH> Uli -- we can hear you 13:59:29 <IanH> Or we could until someone muted you 13:59:41 <pfps> boris: we work differently from xsd - xsd is about transmission we are about use 14:00:38 <rob> q+ 14:00:54 <pfps> achille: we need to be careful - we are changing value spaces 14:01:18 <pfps> achille: we want to be able to use DB and XSD stuff 14:01:36 <pfps> ianh: we need to separate discussion of technical design and discussion of terminology 14:02:02 <rob> q- 14:02:25 <pfps> ianh: any problems with underlying technical design 14:02:50 <rob> q+ 14:03:03 <pfps> msmith: not sure whether technical or terminology - we have value spaces that encompass xsd, right 14:03:24 <rob> q- 14:03:27 <pfps> ianh: this is a communication issue 14:03:37 <sandro> q? 14:04:04 <pfps> m_schneider: what are the differences between xsd and owl? 14:04:18 <rob> zakim, unmute me 14:04:18 <Zakim> rob should no longer be muted 14:04:19 <pfps> sandro: is there an incompatibility? 14:04:29 <rob> q+ 14:05:01 <sandro> sandro: I want to know what incompatibilities there are before deciding whether the design is okay. 14:05:25 <pfps> rob: xsd is just a serialization, we need something more conceptual 14:06:07 <sandro> Alan: in xsd, "2"^^int and "2"^^float are distinct. But in OWL we want them to be the same. 14:06:10 <sandro> q? 14:06:18 <pfps> alanr: xsd has disjoint value spaces (e.g., "2"^^xsd:integer and "2.0"^xsd:float) we don't 14:06:36 <pfps> boris: differences - owl:number+ is a new value space 14:06:50 <sandro> boris: (1) We have owl:number as a super value space. (2) XML schema has float disjoint from double disjount from number. 14:07:11 <pfps> boris: differences - disjointness of integer, float, double (xsd yes, owl no) 14:07:32 <pfps> boris: query in xml schema may diverge from us 14:07:38 <sandro> boris: So the same query in XML schema will give fewer answers -- since it wont know "5"^^float and "5"^^double are the same number. 14:07:39 <pfps> boris: that's it 14:08:18 <pfps> rob: rationale for xsd is serialization thus disjointness 14:08:27 <bparsia> I believe that double and float is disjoint in order to type functions in xpath and xquery 14:08:41 <sandro> rob: XS needs this distinction. If it has a 5, it has to know whether to serialize our "5"^^float or "5"^^double. But this isn't to constrain other specs/apps. 14:08:55 <pfps> rob: new spec says that use of xsd can do what is needed 14:08:56 <rob> zakim, mute me 14:08:56 <Zakim> rob should now be muted 14:09:10 <sandro> q? 14:09:12 <bparsia> q+ 14:09:14 <sandro> ack rob 14:09:16 <rob> q- 14:09:27 <rob> zakim, mute me 14:09:28 <Zakim> rob should now be muted 14:09:32 <jar> jar has joined #owl 14:09:47 <rob> zakim, who is on the phone 14:09:47 <Zakim> I don't understand 'who is on the phone', rob 14:10:05 <IanH> zakim, who is on the phone? 14:10:05 <Zakim> On the phone I see +1.617.253.aaaa, bparsia (muted), uli (muted), rob (muted) 14:10:05 <sandro> Achille: At IBM we'll need to be very clear about the story on these datatypes between OWL and XS 14:10:06 <pfps> achille: my concern is how to sell this (within IBM) - divergences in querying, migration paths 14:10:32 <m_schnei> Achille: IBM has big investments in XML 14:10:49 <bparsia> queue? 14:11:30 <pfps> boris: xquery is a huge spec - type casting might be built in 14:11:44 <bparsia> http://www.w3.org/TR/xquery/#id-type-promotion-and-operator-mapping 14:11:49 <pfps> boris: xquery is syntactic - so it needs type coercion 14:11:59 <pfps> boris: owl is semantic - things are either the same or different 14:12:06 <sandro> boris: there is no such thing as type coercion in OWL. The model theory says the values are the same or are different. 14:12:09 <bparsia> zakim, ack me 14:12:09 <Zakim> unmuting bparsia 14:12:10 <Zakim> I see no one on the speaker queue 14:12:15 <sandro> ack bparsia 14:12:20 <pfps> achille: OK, communication is important, though 14:12:50 <sandro> bparsia: look at MathML here. It might be better to borrow from them -- more about Math than about Data. 14:12:59 <pfps> bparsia: could we use a different terminology (e.g., MathML)? 14:13:27 <msmith> I think that I found the relevant bit from xquery http://www.w3.org/TR/xquery/#id-value-comparisons 14:13:30 <pfps> bparsia: maybe we could use mathml:real, for example 14:14:23 <pfps> achille: I can check the relationship between xquery and owl 14:14:30 <bparsia> I didn't understand the comment about "lack of type coercion" in owl 14:14:53 <bparsia> We can easily have operators that "coerce" (i.e., predicates with union types as arguments) 14:15:10 <sandro> q? 14:15:22 <pfps> m_schneider: two differences - owl:number+ is a new value space, non-disjointness of integer, float, double 14:16:23 <rob> That sounds like a procedural description of our proposed semantics. 14:16:24 <pfps> boris: section 3.5.1 of xquery - type coercion - seems to be wrong for our purposes 14:16:25 <msmith> type promotion in xquery http://www.w3.org/TR/xquery/#dt-type-promotion 14:16:44 <sandro> ACTION: Achille to develop list of possible conflicts between XML Schema datatypes and OWL datatypes with valuespace reasoning 14:16:45 <trackbot> Created ACTION-172 - Develop list of possible conflicts between XML Schema datatypes and OWL datatypes with valuespace reasoning [on Achille Fokoue - due 2008-08-04]. 14:17:28 <pfps> boris: if owl has disjoint integer and float, then you can't have a float value for a property whose range is integer 14:17:32 <bparsia> zakim, mute me 14:17:32 <Zakim> bparsia should now be muted 14:17:42 <pfps> jonathan: what about union types? 14:18:16 <sandro> jrees: I think you can make it work by having valuespace as pair, and semantics are in operator, like in many programming languages. I'm not saying this would be a good way to do things. 14:18:37 <pfps> boris: example - range of P is xsd:float - foo has a value for P that belongs to xsd:integer - this is a contradiction 14:19:03 <pfps> boris: if float and integer are disjoint 14:19:32 <sandro> jrees: Is it a requirement that this is consistent: "range xsd:float" and a value which is "5"^^int ? 14:19:41 <sandro> (general sense of yes.) 14:19:44 <pfps> alanr: thus the integer 5 should be the same as "5.0"^^xsd:float 14:20:05 <rob> I'd still very much prefer if users couldn't say "range xsd:float" 14:20:31 <sandro> +1 rob 14:20:31 <pfps> [considerable discussion] 14:20:54 <pfps> alanr: xquery promotion is to float - this may not be the same as the owl proposal 14:20:54 <jar> I heard: It is a requirement that "5"^^xsd:integer has type [not sure what the "has type" predicate is] xsd:float 14:20:59 <rob> I don't understand the notion "equal as floats" 14:22:05 <pfps> boris: IEEE comparison of floats and doubles is done as if they were exact real numbers 14:22:16 <msmith> sandro, http://www.w3.org/2007/OWL/wiki/TestCase:Datatype-Primitive-Disjointness-001 14:22:28 <rob> from IEEE 7.5.4 section 5.7 : It shall be possible to compare floating-point numbers in all supported formats, even if the operands’ formats differ. 14:22:28 <rob> Comparisons are exact and never overflow nor underflow. 14:22:45 <rob> </quote> 14:22:56 <pfps> achille: run this through some code 14:23:35 <pfps> achille: galax is a reference implementation 14:23:39 <sandro> ACTION: Alan to investigate Boris' IEEE reference, re linking floating point to real numbers 14:23:39 <trackbot> Created ACTION-173 - Investigate Boris' IEEE reference, re linking floating point to real numbers [on Alan Ruttenberg - due 2008-08-04]. 14:23:49 <pfps> alanr: things to check - owl:number+ - we seem to be OK 14:24:12 <pfps> alanr: minimum conformance - 64 bit integer - decimal - something that looks OK 14:24:19 <rob> q+ 14:24:37 <pfps> alanr: float and double are currently real ranges 14:24:46 <rob> zakim, unmute me 14:24:46 <Zakim> rob should no longer be muted 14:24:47 <IanH> q? 14:24:50 <pfps> alanr: internationalized strings 14:25:07 <rob> zakim, mute me 14:25:07 <Zakim> rob should now be muted 14:25:09 <rob> q- 14:25:18 <pfps> rob: the issue is whether xsd:float is a value space 14:25:25 <jar> My point was: There are two coherent designs, and maybe a choice has been made between then (I am coming into the middle of the conversation). In one design, the float/integer distinction is lost via the interpretation function - models don't distinguish them. The other coherent design would be to preserve the float/integer distinction in the interpretation function somehow, and then lose... 14:25:26 <jar> ...the distinction in the comparison predicates (etc.). I just want to make sure everyone understands the consequences of this choice. 14:25:45 <pfps> alanr: boolean and hexdecimal 14:25:50 <pfps> alanr: date/time 14:26:38 <pfps> alanr: issues - Issue87, Issue71, Issue127, Issue132, floats 14:26:52 <sandro> q? 14:27:14 <pfps> m_schneider: why the change from owl:real to owl:number? 14:27:21 <pfps> boris: people liked it 14:27:29 <pfps> m_schneider: but what about complex numbers, then? 14:27:37 <sandro> m_schnei: The term "owl:number" misled me into thinking I could use it as a base for Complex Numbers 14:28:03 <pfps> alanr: MEETING ISSUE - owl:number vs owl:real 14:28:21 <Zhe> maybe owl:realNumber? 14:28:47 <bparsia> what's going on? 14:28:52 <pfps> alanr: use of xsd:float - as datatype name, as separate from other numbers 14:28:59 <sandro> Ian: Can we use xs:float is a class in restrictions, and if we use it what does it mean? 14:29:04 <m_schnei> my point was, that implementors might want to decide to support reasoning with different kinds of numbers, such as complex numbers or quaternions, and owl:number(+) would make a good abstract base for all possible number classes 14:29:24 <pfps> msmith: if we use it, then it should mean the same as in xsd - i.e., discrete 14:29:53 <rob> "using as a base" works the opposite the way in OWL it does in other languages: in other languages you build up, but in OWL you only trim down. 14:29:58 <pfps> alanr: thus not make xsd:float required 14:29:59 <sandro> msmith: If we use xs:float it should have the same semantics as in XS -- discrete reals, plus the extras. But that's hard to implement, so don't require it. 14:30:15 <pfps> boris: the documents have to be careful then 14:30:20 <IanH> q? 14:30:42 <rob> +1 to not allowing "range xsd:float", for example. 14:30:45 <sandro> boris: That's fine. We're supporing xs:float types for constants, but not for ranges. 14:31:36 <sandro> msmith: I have an issue with wanting to be able to implement xs:float ranges -- is my implementation allowed to do that? 14:31:37 <pfps> alanr: straw poll - is xsd:float an OWL datatype 14:31:39 <bparsia> +0 waiting to investigate how often it appears in practice 14:31:41 <sandro> Alan: let's come back to that. 14:31:44 <pfps> msmith: no 14:31:52 <rob> horribly confusing, and non-conformant with XSchema... 14:31:54 <pfps> boris: but would anyone see a difference? 14:32:19 <bparsia> http://swoogle.umbc.edu/index.php?option=com_frontpage&service=search&queryType=search_swd_ontology&searchStart=1&searchString=float 14:32:24 <pfps> msmith: choosing xsd:float is a choice - why did someone do it 14:32:35 <pfps> ianh: is there an example 14:33:08 <sandro> q? 14:33:16 <pfps> m_schneider: perhaps xsd:float was used to allow more values (due to implementation limitations) 14:33:27 <pfps> boris: value space of xsd:integer is all integers 14:33:46 <pfps> boris: some implementations might not support arbitrarily large constants 14:34:10 <bparsia> Another example: http://www.biopax.org/release/biopax-level2.owl 14:34:12 <pfps> boris: xsd says that minimal conformance requires support for integers that fit into 64 bits 14:34:18 <bparsia> But floatiness doesn't seem interesting 14:34:20 <sandro> boris: yes, the value space for integer and decimal are infinite, but we only want to require folks to implement certain size constants. 14:34:52 <sandro> alan: XMLS and OWL may have different conformance clauses. 14:35:04 <pfps> jonathan: in scientific computing float means "can be represented (exactly) as a float" 14:35:27 <sandro> jrees: No one in scientific computing would say sqrt(2) is float. 14:35:44 <pfps> ianh: we need to be careful to keep constants (and minimal conformance) and value spaces separate 14:35:45 <sandro> q? 14:36:00 <rob> q+ 14:36:22 <pfps> boris: sqrt(2) is not a float - we can approximate it, though 14:37:06 <pfps> msmith: suppose I use small numbers and I store them as floats - I may want to know whether there is a float between two others (that are close) 14:37:20 <m_schnei> scribe assist - I talked about xsd:decimal, not xsd:float 14:37:24 <rob> zakim, unmute me 14:37:24 <Zakim> rob should no longer be muted 14:37:29 <pfps> alanr: in the proposal sqrt(2) is in float 14:38:07 <bparsia> q+ 14:38:10 <pfps> rob: "can't tell the difference now" is a suspect argument - extensions may expose the differences 14:38:13 <bparsia> (to reply to owl) 14:38:15 <sandro> RRSAgent, pointer? 14:38:15 <RRSAgent> See http://www.w3.org/2008/07/28-owl-irc#T14-38-15 14:38:23 <rob> zakim, mute me 14:38:23 <Zakim> rob should now be muted 14:38:30 <rob> q- 14:39:02 <pfps> ianh: everyone seems to be OK with xsd:float as a datatype, so what is the point of this discussion 14:39:51 <pfps> ianh: people who are interested in the edge conditions of float already understand the issues and that it is a bad idea to depend on them 14:40:16 <bparsia> zakim, unmute me 14:40:16 <Zakim> bparsia should no longer be muted 14:40:18 <bparsia> <owl:DatatypeProperty rdf:ID="Price"> 14:40:18 <bparsia> <rdfs:domain rdf:resource="#PurchasedItem"/> 14:40:18 <bparsia> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> 14:40:18 <bparsia> </owl:DatatypeProperty> 14:40:23 <bparsia> http://www.dayf.de/2004/owl/order.owl 14:40:25 <pfps> jonathan: floats are reliably used in scientific computing 14:40:38 <bparsia> can we use the queue, in general? 14:40:48 <bparsia> It's hard to know where I am on the queue 14:40:53 <rob> yes, bijan---everybody uses floats in those things now because it's allowed. 14:41:13 <uli> \me guesses that Peter and Rob are close to the microphone and Alan is far away? 14:41:13 <pfps> ianh: can we handle this under RDF repairs? 14:41:15 <bparsia> rob, I'm just gathering examples. That's pretty clearly a silly one 14:41:29 <bparsia> From the point of view of "OOO, IEEE float" 14:41:41 <sandro> q? 14:41:43 <sandro> ack bparsia 14:41:48 <IanH> q? 14:42:45 <pfps> bparsia: examples of xsd:float in Swoogle in Tboxes - there is a fair bit, but no used for floatiness 14:43:30 <pfps> bparsia: we could have owl:IEEEfloat for those who need floatiness 14:43:32 <rob> But why include xsd:float as a value space which doesn't mean what its name implies? 14:44:00 <bparsia> I don't know what you mean "include as a value space". I mean it to be a sub thing of owl number 14:44:07 <pfps> boris: it is easier to say that float is on both sides 14:44:09 <bparsia> I.e., as sugar for a bounded real 14:44:12 <bparsia> er. number 14:44:17 <rob> zakim, unmute me 14:44:17 <Zakim> rob should no longer be muted 14:44:17 <pfps> msmith: why not use xsd:decimal 14:44:24 <IanH> q? 14:44:25 <pfps> boris: because people use xsd:float 14:44:33 <rob> zakim, mute me 14:44:33 <Zakim> rob should now be muted 14:44:47 <uli> before the break: is there an updated agenda? 14:44:49 <pfps> msmith: but they might want the floatiness 14:45:09 <bparsia> The people who "are using floatiness" are likely in a better position to be "screwed" than others :) 14:45:46 <rob> But there's no evidence that anybody is using the floatiness... 14:46:05 <bparsia> rob, I agree, I'm just saying that it probably wouldn't matter 14:46:14 <pfps> ScribeNick: m_schneider 14:46:32 <uli> ...does anybody have an updated agenda? 14:46:35 <uli> Alan, Ian? 14:46:35 <bparsia> They hypothetical floaters would presumably be so sophisticated that they could handle a break ok 14:46:43 <rob> Allowing some "owl value spaces" which are xsd names and mean the xsd value space, and some which are xsd names but don't mean the xsd value space, is terribl terrible design. 14:47:15 <uli> zakim, unmute me 14:47:15 <Zakim> uli should no longer be muted 14:47:18 <rob> And it's the easiest thing to patch in legacy ontologies---it's entirely clear what needs to be fixed. 14:48:22 <uli> zakim, mute me 14:48:22 <Zakim> uli should now be muted 14:48:29 <rob> should we have a phone pow-wow without the boston crowd? 14:48:30 <ekw> Agenda is http://www.w3.org/2007/OWL/wiki/F2F3_Agenda 14:49:02 <uli> thanks, evan. I was just wondering whether it was up to date 14:49:15 <uli> since the datatype discussion started much earlier than planned 14:49:45 <uli> s/evan/?? who is ekw? 14:51:03 <Zakim> -rob 14:51:20 <Zakim> -uli 14:52:57 <rob> rob has joined #owl 14:53:07 <sandro> rob, bparsia, uli are participating remotely 14:58:28 <pfps> rrsagent, pointer? 14:58:28 <RRSAgent> See http://www.w3.org/2008/07/28-owl-irc#T14-58-28 14:58:44 <rob> are we re-starting? 14:58:59 <sandro> no, rob 15:14:22 <sandro> scribe: m_schnei 15:15:08 <Zakim> +??P18 15:15:16 <uli> zakim, ??P18 is me 15:15:16 <Zakim> +uli; got it 15:15:20 <uli> zakim, mute me 15:15:20 <Zakim> uli should now be muted 15:15:25 <alanr> http://www.w3.org/TR/xpath-functions/#casting-to-numerics 15:16:05 <m_schnei> alanr: 10 more minutes on floats, and afterwards other types 15:16:44 <m_schnei> alanr: option legacy: lots of people using floats 15:17:22 <m_schnei> boris: mike trys to convince me that discrete xsd:float is not too difficult 15:17:42 <m_schnei> boris: if it works well and efficient, I'll be happy with it 15:17:55 <m_schnei> alanr: asks what implementors think 15:18:06 <m_schnei> zhe: would like that 15:18:12 <sandro> rob, you there? 15:18:21 <m_schnei> achille: would like it too 15:18:46 <m_schnei> msmith: big problem is determining how many floats are between two given floats 15:19:03 <Zakim> +rob 15:19:10 <rob> zakim, mute me 15:19:10 <Zakim> rob should now be muted 15:19:38 <m_schnei> alanr: other option for floats is the "high road" 15:19:39 <sandro> ack rob 15:19:43 <rob> zakim, unmute me 15:19:43 <Zakim> rob was not muted, rob 15:20:10 <m_schnei> alanr: (to rob) there are three implementors who are happy with floats as discrete set 15:20:42 <m_schnei> ian: we are reinterpreting floats as a set of discrete points 15:21:00 <m_schnei> rob: that's still a crazy idea 15:21:11 <uli> +1 to Rob 15:21:24 <m_schnei> achille: because it is the same interpretation as in xsd 15:21:32 <sandro> alan: Rob, what do you think of the proposal: Floats are a value space which is discrete points in the owl:number value space (just like integers are), plus +/- inf, zero 15:21:44 <m_schnei> achille: possible to count number of floats between 15:21:59 <m_schnei> achille: would be no big issue anymore from his pov 15:22:17 <msmith> E.g., see http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm and integer comparison section 15:22:33 <m_schnei> achille: still concern that owl:number is non-discrete 15:23:02 <m_schnei> rob: it's trivial for implementations to use it in discrete way 15:23:23 <m_schnei> zhe: has seen ontologies using float, should not be disallowed 15:23:40 <m_schnei> boris: big benefit would be that this would close the issue 15:23:42 <bparsia> +1 boris 15:23:53 <Zakim> +Carsten 15:24:01 <sandro> q? 15:24:03 <Carsten> hi all 15:24:06 <sandro> q+rob 15:24:11 <Carsten> zakim, mute me 15:24:11 <Zakim> Carsten should now be muted 15:24:24 <bparsia> +1 again to boris 15:24:29 <m_schnei> boris: want's to simply explicitly list the allowed datatypes 15:24:58 <sandro> boris: People might want to say range is float, so it's known it can be stored in 32 bits. 15:25:03 <m_schnei> boris: xsd:float would simply refer to ieee definition of float 15:25:04 <sandro> ack rob 15:26:02 <m_schnei> alanr: you are the last one against 15:26:08 <m_schnei> alanr: to rob 15:26:14 <uli> q+ 15:27:15 <IanH> q? 15:27:54 <pfps> if we make the value space of xsd:float discrete, then we should make it disoint from owl:number 15:27:58 <uli> zakim, unmute me 15:27:58 <Zakim> uli should no longer be muted 15:28:08 <Carsten> same here 15:28:46 <m_schnei> uli: asks about performance problems with discrete floats 15:28:49 <bparsia> It's no worse than integers. 15:29:05 <m_schnei> uli: additional problem, having all these numbers available 15:29:32 <m_schnei> boris: if you know that your datarange is large, you don't have a problem [FIXME] 15:29:36 <bparsia> 1+ 15:29:37 <bparsia> er 15:29:39 <bparsia> q+ 15:29:48 <m_schnei> uli: concerns about unimplementable 15:30:03 <rob> q+ to repeat his very first arguments... 15:30:11 <Carsten> though this may "typically" be true, you still need to check for it in a reasoner 15:30:35 <uli> zakim, mute me 15:30:36 <Zakim> uli should now be muted 15:31:05 <msmith> uli, the primary change, I believe is that Boris has been convinced the counting the number of floats between endpoints is easy 15:31:08 <bparsia> (My point was that we can express discrete floats with our given integer facets) 15:31:10 <alanr> q? 15:31:13 <alanr> ack uli 15:31:17 <Carsten> to me, that was never really the point 15:31:21 <m_schnei> ian: uli, piece you are missing is that computing that number of numbers between two numbers is actually easy to compute 15:31:22 <uli> zakim, unmute me 15:31:22 <Zakim> uli was not muted, uli 15:31:26 <rob> never really the point to me, ether 15:31:32 <alanr> ack bparsia 15:31:34 <bparsia> zakim, unmute me 15:31:34 <Zakim> bparsia was not muted, bparsia 15:31:36 <uli> zakim, mute me 15:31:36 <Zakim> uli should now be muted 15:31:39 <IanH> q? 15:32:01 <alanr> ack rob 15:32:01 <Zakim> rob, you wanted to repeat his very first arguments... 15:32:07 <bparsia> zakim, mute me 15:32:07 <Zakim> bparsia should now be muted 15:32:08 <uli> but we had unbounded integers! 15:32:09 <sandro> Ian: We thought it was hard to handle discrete floats, but now we think it's the same as handling ints. 15:32:17 <Carsten> +10! 15:32:26 <rob> zakim, mute me 15:32:26 <Zakim> rob should now be muted 15:32:26 <sandro> Rob: using xs:float as a value space is not what any user wants. 15:32:26 <m_schnei> rob: xsd:float as a value space is not what people want 15:32:38 <msmith> bijan: you can mirror the discreteness of floating point numbers using a datarange on xsd:integer 15:32:39 <m_schnei> alanr: going to vote now 15:32:48 <uli> Ian, I don't think this is true: integers are unbounded?! 15:33:03 <bparsia> uli, you can create a derived type which is bounded 15:33:14 <Carsten> uli, but there are facets 15:33:16 <uli> sure - but then I have done it 15:33:26 <bparsia> I.e., 5 < & >1 15:33:29 <rob> discrete floats completely breaks linear inequations... 15:33:32 <uli> I understand 15:33:36 <msmith> but, also, you had to choose xsd:float 15:33:40 <uli> but then it's up to the user 15:33:41 <m_schnei> baojie: can we compare each pair of numbers from two types? 15:33:45 <rob> (because many many ontologies will use xsd:float when they just mean number) 15:33:50 <bparsia> Right, so in terms of the underlying impelmentation it's no harder.. 15:33:51 <sandro> PROPOSED: The value space of xs:float will be a subset of the value space of owl:numberplus (real numbers plus +/- inf, +/- zero, NaN). It would be discrete points in that space, like xs:integer. 15:33:52 <msmith> you wouldn't use floats for inequations, you'd use the reals 15:33:53 <uli> whereas float comes with this *unexpectedly* 15:33:57 <bmotik> +1 Oxford 15:34:01 <baojie> +1 RPI 15:34:13 <msmith> +1 C&P 15:34:16 <m_schnei> +1 FZI 15:34:20 <ekw> +1 NIST 15:34:22 <Achille> +1 IBM 15:34:23 <pfps> -0 Bell Labs 15:34:25 <Zhe> +1 ORACLE 15:34:26 <sandro> +1 W3C 15:34:43 <Carsten> -1 (illegal vote) 15:34:52 <jar> +1 Science Commons 15:35:03 <sandro> (Carsten isn't currently a WG member) 15:35:12 <bparsia> One sec 15:35:17 <Carsten> but (still) working on it 15:35:29 <uli> 0 manchester 15:35:40 <sandro> RESOLVED: The value space of xs:float will be a subset of the value space of owl:numberplus (real numbers plus +/- inf, +/- zero, NaN). It would be discrete points in that space, like xs:integer. 15:36:00 <m_schnei> Topic: Rationals 15:36:38 <m_schnei> alanr: as i understand, the proposal is about rational *constants* 15:37:37 <m_schnei> boris: from a presentability pov, better to look at a type from its value space 15:37:45 <alanr> q? 15:38:21 <IanH> q? 15:38:29 <m_schnei> ian: more relaxed point of view, may exist types with overlapping value spaces 15:38:45 <alanr> q? 15:39:08 <rob> it's far easier than having a float value space 15:39:12 <msmith> msmith: rational constants are useful, I don't believe value space is 15:39:22 <m_schnei> alanr: adding rational numbers would bring problems in comparing with other types 15:39:35 <m_schnei> alanr: that's an implementors problem 15:39:52 <m_schnei> alanr: in particular if the other type is float 15:40:20 <m_schnei> alanr: how do you say that the rational and the float is exactly the same number 15:41:12 <m_schnei> msmith: ready to do this 15:42:03 <m_schnei> boris: rational seems to have a natural place in the hierarchy starting with owl:number 15:42:18 <m_schnei> boris: bigger issue is supporting rational constants 15:42:42 <IanH> q? 15:43:17 <uli> Boris, is this "I know it's difficult" or "I don't know yet how to do it fast"? 15:43:21 <bparsia> To express all the rationals using decimal notation requires infinite expansion 15:43:34 <m_schnei> m_schnei: rational coresponds to decimals 15:43:40 <m_schnei> boris: wrong 15:43:45 <IanH> q? 15:44:00 <m_schnei> boris: not every rational can be represented as decimal, eg. 1/3 15:45:19 <m_schnei> boris: thought that rational were easily implementable, but after yesterday's (?) discussion he is not sure anymore 15:46:11 <rob> how is implementability the issue? 15:46:14 <IanH> Achille: need restriction; even then not sure if we would implement 15:46:18 <alanr> q? 15:46:22 <bparsia> We like rationals 15:46:28 <m_schnei> zhe: not sure if implementable by oracle, which uses a number type, perhaps not compatible with owl:rational 15:46:28 <uli> yes, we really do 15:46:31 <bparsia> Uli has a burning desire to write 1/3 in ontologies 15:46:42 <bparsia> constants,I think 15:46:56 <bparsia> But we wouldn't mind datatypes 15:47:04 <Zhe> it is a bit hard for relational DB to implement rational 15:47:13 <Zhe> may not worth the effort 15:47:28 <uli> Zhe, your DB wouldn't need to implement it? 15:47:42 <Zhe> uli. we might skip this one 15:47:58 <m_schnei> alanr: couple of implementors say rational may be problematic, but there is also desire 15:48:03 <m_schnei> ian: straw poll 15:48:11 <rob> q+ 15:48:18 <IanH> q? 15:48:56 <rob> zakim, unmute me 15:48:56 <Zakim> rob should no longer be muted 15:49:02 <m_schnei> baojie: no use cases found for rational in wiki 15:49:25 <rob> zakim, mute me 15:49:25 <Zakim> rob should now be muted 15:49:28 <rob> q- 15:49:33 <Carsten> not strange at all: they had a completely different application in mind 15:49:36 <m_schnei> rob: strange that owl group sais that xsd group did bad job [FIXME] 15:49:53 <bparsia> That's a weird thing for rob to say given all his pangyrics about how xml schema numbers/value spaces are not what owl wants ;) 15:50:14 <rob> XSD isn't a spec about value spaces---it's about writing down numbers. 15:50:32 <sandro> alan: let's postpone Rationals to be part of n-ary. 15:50:34 <m_schnei> msmith: owl being an ontology langugage, it makes sense to have exact, not approx definitions 15:51:01 <m_schnei> alanr: what is most important topic? 15:51:08 <m_schnei> alanr: nary? noone 15:51:17 <m_schnei> alanr: datetime? few 15:51:24 <m_schnei> alanr: communication: several 15:51:28 <sandro> Topic: Communication 15:51:31 <alanr> q? 15:51:45 <bparsia> XSD is not about writing down numbers in a mathematical sense; that's seems mathml. OWL, as you argued, is much more about value space, ergo, it's not *weird* to argue that the xsd way of writing numbers down may be insufficient. You may disagree, but its' not weird 15:51:54 <IanH> Boris on presentation. Interesting. 15:52:13 <m_schnei> boris: in datatype section 4.2 we say for each datatype what its lexical space, its value space is 15:53:02 <m_schnei> boris: when two constants are structurally the same 15:53:30 <m_schnei> boris: whether implementations are allowed to simplify lexical reps 15:53:50 <IanH> Achille: constant = lexical representation 15:53:55 <sandro> Achille: Boris, when you say "constant" you mean "lexical representation" right? Boris: Yes,. 15:54:39 <IanH> q? 15:54:52 <m_schnei> msmith: main question about structural sameness 15:55:12 <m_schnei> boris: we have structural equivalence on virtually everything 15:56:02 <m_schnei> boris: always saying something like these two expressions are structurally different, but they are equivalent 15:56:12 <m_schnei> boris: e.g. 2.0 to 2 15:56:32 <m_schnei> boris: we should at least say something about this 15:57:06 <m_schnei> alanr: what about rounded floats? 15:57:22 <m_schnei> boris: one can have the same float after it gets rounded 15:58:03 <m_schnei> boris: should be clear that if you do this than you change the ontology 15:58:30 <m_schnei> boris: if this is really critical to an implementation, this should not be done 15:59:12 <m_schnei> alanr: we should always distinguish between "xsd value space" and "owl value space" 16:00:23 <m_schnei> ian: we should better talk about "interpretations of types" 16:00:31 <alanr> q? 16:00:52 <m_schnei> boris: first, let's rename "constant" to "literal" 16:01:03 <sandro> boris: Let's go ahead and rename "constant" to "literal". 16:01:09 <m_schnei> boris: constant always refers to the lexical part 16:01:42 <m_schnei> boris: distinguish between "constant and its interpretation" and "data type and its interpretatoin" 16:02:04 <sandro> PROPOSED: Close ISSUE-132 by replacing "constant" with "literal". 16:02:09 <bmotik> +1 Oxford 16:02:12 <Achille> +1 IBM 16:02:14 <sandro> +1 W3C 16:02:17 <pfps> +1 Bell Labs 16:02:19 <Zhe> +1 ORACLE 16:02:20 <m_schnei> +1 FZI 16:02:26 <jar> +1 Science Commons 16:02:29 <uli> +1 Manchester 16:02:46 <ekw> +1 NIST 16:03:04 <sandro> RESOLVED: Close ISSUE-132 by replacing "constant" with "literal". 16:03:57 <m_schnei> Boris: let's say instead of "data value" better "interpretation of a literal" 16:04:18 <bmotik> PROPOSED: Rename data value -> constant intermretation and value space -> Datatype interpretation 16:04:44 <bmotik> PROPOSED: Rename data value -> literal interpretation and value space -> Datatype interpretation 16:05:00 <uli> q+ 16:05:48 <uli> zakim, unmute me 16:05:48 <Zakim> uli should no longer be muted 16:05:54 <IanH> q? 16:06:06 <alanr> ack uli 16:06:18 <uli> zakim, mute me 16:06:18 <Zakim> uli should now be muted 16:06:26 <bmotik> something like: Rename data value -> literal interpretation and value space -> Datatype interpretation 16:07:40 <sandro> But the basic idea is "data value" -> "interpretation of literal" 16:07:50 <sandro> (silent agreement by meeting) 16:08:05 <sandro> And instead of "value space" -> "interpretation of a datatype" 16:08:23 <m_schnei> Topic: datetime 16:09:17 <m_schnei> alanr: problem with different time types is that they are not always comparable 16:09:34 <m_schnei> alanr: for example when different timezones are involved 16:09:56 <m_schnei> alanr: other problem is the ordering 16:10:32 <m_schnei> baojie: in many cases, users do not completely specify all components of a time 16:11:23 <alanr> q? 16:11:26 <m_schnei> baojie: we should allow users to specify less information 16:11:43 <m_schnei> baojie: not a good idea to have utc as a default timezone 16:11:55 <m_schnei> baojie: we should allow time periods 16:12:42 <m_schnei> alanr: what does "monday" denote? 16:13:17 <m_schnei> boris: the way xsd deals with this is horrible, means all mondays 16:14:06 <bmotik> bmotik: If we go away from XML Schema, we can have a simpler way of referring to Monday 16:14:33 <bmotik> bmotik: We could have daysOfTheWeek datatype whose interpretation contains exactly seven values 16:14:52 <bmotik> bmotik: Then, Monday really refers just to one value in the interpretation 16:15:01 <m_schnei> ian: don't let's invent our own datatype 16:15:14 <bparsia> http://www.hydracen.com/dx/iso8601.htm 16:15:15 <m_schnei> pfps: what's with the 15th of a month 16:15:27 <bparsia> http://en.wikipedia.org/wiki/ISO_8601 16:15:51 <m_schnei> alanr: proposes to regard time as a timeline 16:16:46 <m_schnei> alanr: problem with non-timezoned: any default timezone might be wrong 16:17:23 <m_schnei> alanr: 6 o'clock might be right in your timezone, but is different elsewhere 16:18:30 <m_schnei> boris: supporting recurring finite types is not a problem 16:18:31 <bmotik_> bmotik_ has joined #owl 16:18:46 <bparsia> q+ 16:18:52 <m_schnei> boris: what operations do we want on time dates 16:19:48 <sandro> Boris: Is midnight Jan 1 in the UK the same thing as 1am Jan 1 in Berlin ? 16:19:56 <sandro> Alan: surveys room, 9 people say yes.... 16:20:08 <uli> Alan, what was the question? 16:20:18 <uli> ...I couldn't understand it 16:20:23 <bmotik_> bmotik_ has joined #owl 16:20:27 <sandro> uli, Boris' question. 16:20:34 <uli> thanks, Sandro 16:20:45 <m_schnei> boris: identity problem is key 16:21:51 <m_schnei> boris: assumption is that one can map every time to a point on the same time line 16:22:23 <m_schnei> pfps: xsd timeline is not compact 16:22:38 <sandro> boris: Even if those two things are different, there could still be operators which operate on them. 16:22:45 <m_schnei> boris: if you tick one sec on the xsd timeline, it may be two secs 16:22:57 <alanr> q+ 16:23:00 <sandro> (leap seconds representation mess.) 16:23:14 <bparsia> zakim, unmute me 16:23:14 <Zakim> bparsia should no longer be muted 16:23:31 <m_schnei> bijan: are we on the tuple model? 16:23:35 <bparsia> zakim, mute me 16:23:35 <Zakim> bparsia should now be muted 16:24:08 <sandro> septuplets? 16:24:10 <m_schnei> alanr: what about the leap seconds? 16:24:43 <m_schnei> alanr: if we handle leaps, than the time ordering might change, problem for reasoning 16:24:43 <sandro> alan: If we handle leap-seconds, then some of our inferences will have to change when more leap-seconds are defined. 16:26:07 <alanr> ack alanr 16:26:10 <m_schnei> evan: talks "this monday" as a time, not about "every monday" 16:26:13 <bparsia> q- 16:26:37 <m_schnei> boris: what would be the interpretation of xsd:datetime? 16:27:02 <sandro> boris: timeline needs to be seconds since some famous point in time. 16:27:18 <m_schnei> baojie: what about non-christian time (russia, etc) 16:28:36 <m_schnei> pfps: what about daylight savings? 16:29:34 <m_schnei> ian: was under the impression that there was already a semi-aggreement 16:29:48 <sandro> ian: Time on timeline as our interpretation space, and then simple time constants. 16:29:53 <m_schnei> ian: that we here only have to talk about what constants, etc 16:30:10 <uli> +1 to Ian 16:30:22 <m_schnei> ian: things seem now just to complicated 16:30:45 <bparsia> Origin -- "As a point of interest, ISO 8601 fixes a reference calendar date to the Gregorian calendar of 1875-05-20 as the date the Convention du Mètre was signed in Paris." 16:30:50 <m_schnei> ian: let's just talk about constants, and what point on the timeline they denote [FIXME] 16:30:50 <bparsia> +10 to ian 16:31:00 <pfps> +1 to ian 16:31:24 <sandro> Cute, Bijan 16:31:48 <m_schnei> alan: first thing is question, do we have time points or intervals 16:32:20 <m_schnei> ian: time is still point, represented by eg decimal 16:32:44 <m_schnei> pfps: we have continuous timeline, and specify time points on it 16:32:53 <jar> jar has joined #owl 16:33:30 <sandro> pfps: the timezone and year have to be present, and then the succeeding parts in the tuple .... 16:33:46 <m_schnei> pfps: xsd says "1999" is *end* of "1999", which seems wrong to him 16:33:51 <bparsia> Didn't hear all of level 0 16:34:21 <m_schnei> pfps: pointer is XSD LC document 16:34:30 <sandro> PROPOSED: We're have a time-on-timeline interpretation of times, with XS date times as literals uses for naming points on that timeline. 16:34:54 <sandro> PROPOSED: We'll have a time-on-timeline interpretation of times, with XS date times as literals uses for naming points on that timeline. 16:35:03 <pfps> XML Schema datatypes current WD http://www.w3.org/TR/xmlschema11-2/ 16:35:04 <m_schnei> ewallace: the way peter cited interpretation of a year would be a bad idea 16:35:31 <sandro> PROPOSED: We'll have a time-on-timeline interpretation of times, with XS date times as literals uses for naming points on that timeline (where the XS time is unambiguous -- it must have a timezone). 16:35:31 <ekw> +1 16:35:33 <msmith> +1 16:35:46 <bparsia> zakim, unmute me 16:35:46 <Zakim> bparsia should no longer be muted 16:35:46 <baojie> +1 16:36:06 <IanH> +1 16:36:07 <msmith> not all parts, just top down 16:36:08 <Zhe> +1 16:36:21 <sandro> PROPOSED: We'll have a time-on-timeline interpretation of times, with XS date times as literals uses for naming points on that timeline (where the XS time is unambiguous -- it must have a timezone). This is a minimum -- we may do more. 16:36:24 <baojie> redraw my vote 16:36:26 <baojie> 0 16:36:46 <Deborah> dlm has joined #owl 16:36:47 <uli> +1 16:36:52 <bparsia> +1 16:37:13 <sandro> Alan: next we can discuss what to do if there isn't a timezone, etc. 16:37:29 <sandro> Ian: This is sugar for a clone of reals. 16:37:30 <bparsia> zakim, mute me 16:37:30 <Zakim> bparsia should now be muted 16:38:14 <sandro> pfps: so tz=ET,year=2008 ===> the time that 2008 starts in Eastern Time. 16:39:25 <sandro> msmith: It's gotta be from the top down -- that's been worked out. gyear stuff. We just need to say timezone. 16:40:15 <sandro> PROPOSED: We'll have a time-on-timeline interpretation of times, with XS date times as literals uses for naming points on that timeline (where the XS time is unambiguous -- it must have a timezone). This is a minimum -- we may do more. 16:40:29 <pfps> +1 Bell Labs 16:40:31 <bmotik> +1 Oxford 16:40:33 <sandro> +1 W3C 16:40:38 <baojie> +1 RPI 16:40:40 <Zhe> +1 ORACLE 16:40:41 <Achille> +1 IBM 16:40:42 <m_schnei> +1 FZI 16:40:43 <ekw> +1 NIST 16:40:46 <jar> +1 Science Commons 16:40:51 <bparsia> one sec 16:40:56 <msmith> +1 C&P 16:41:10 <uli> +1 Manchester 16:41:28 <sandro> RESOLVED: We'll have a time-on-timeline interpretation of times, with XS date times as literals uses for naming points on that timeline (where the XS time is unambiguous -- it must have a timezone). This is a minimum -- we may do more. 16:41:46 <m_schnei> alanr: next question is what todo with timezones 16:42:53 <m_schnei> msmith: would like to interprete a year as an interval, not a point 16:44:00 <bparsia> What's the proposal under discussion? 16:44:17 <m_schnei> boris: xsd interprets a year as a set of timepoints 16:44:42 <sandro> Alan: The proposal is to use a lexical gYear as a way to specific a faceted value of owl:time 16:44:45 <m_schnei> pha: gyear is a set of years 16:44:50 <m_schnei> boris: and what is a year? 16:45:14 <m_schnei> ian: getting too complicated, we should think to not support it 16:45:15 <uli> +1 to Ian 16:45:46 <msmith> I am basing this view on http://www.w3.org/TR/xmlschema11-2/#gYear 16:45:47 <m_schnei> alanr: let's take this out of the discussion 16:45:56 <sandro> Subtopic: how to handle times without timezones 16:46:05 <m_schnei> alanr: next not-timezoned types 16:46:12 <bparsia> q+ 16:46:24 <m_schnei> alanr: what does a not-timezoned value mean 16:46:46 <m_schnei> baojie: you can not compare two values without timezone 16:47:14 <sandro> I think non-zoned-times should be erroneous..... 16:47:27 <uli> +1 to sandro 16:47:34 <bparsia> +1 to sandro 16:47:35 <bparsia> zakim, ack me 16:47:35 <Zakim> unmuting bparsia 16:47:36 <sandro> ack bparsia 16:47:37 <Zakim> I see no one on the speaker queue 16:48:19 <bparsia> zakim, mute me 16:48:19 <Zakim> bparsia should now be muted 16:48:22 <m_schnei> bijan: whatever we decide is wrong for some people, so let's ever have a time zone 16:48:28 <Deborah> for my applications, if i can say this time point is within a time range (and i am willing to put a time zone on it), i can make things work 16:49:08 <bparsia> There are some uses of gyear on swoogle: 16:49:08 <bparsia> http://swoogle.umbc.edu/index.php?option=com_swoogle_service&service=cache&view=raw&url=http%3A%2F%2Fspire.umbc.edu%2Fontologies%2FSpireEcoConcepts.owl 16:49:13 <bparsia> <owl:DatatypeProperty rdf:ID="publicationYear"> 16:49:13 <bparsia> <rdfs:domain rdf:resource="#Study"/> 16:49:13 <bparsia> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#gYear"/> 16:49:14 <bparsia> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/> 16:49:14 <bparsia> </owl:DatatypeProperty> 16:49:42 <baojie> my proposal: treat not-timezoned time as an interval of 24 hours 16:50:03 <sandro> jar: think about what you're going to tell people to do with publication dates like "2003". Is that 2003-01-01 00:00:01 UTC ... or what? 16:50:12 <Deborah> uli - that is what my applications do - but i think that is up to the application layer 16:50:46 <uli> dlm, this is ok as well: either defaulting or adding upon load... 16:50:51 <m_schnei> boris: problem, if something is a FunctionalProperty, and one of the values does not have a timezone, then we have a problem 16:51:48 <m_schnei> pha: question, is it already decided if owl 2 will have to be compatible with xsd 16:52:17 <IanH> pha: compatible with xsd 1 or 1.1? 16:52:32 <sandro> alan: proposals -- (1) "put them on UTC", (2) "put them on a different time line", (3) "reject as error" 16:53:07 <Deborah> vote no for (3) 16:53:14 <m_schnei> sandro: we cannot say "compatible with 1.1", since it's not a rec yet 16:53:28 <jar> you could cite a particular draft of 1.1 16:53:39 <sandro> sandro: we shouldn't decide to rely on 1.1 yet, since they might stall and we don't want to wait for them. 16:53:55 <sandro> no, jar, you can't cite a working draft in a normative reference. 16:54:29 <jar> oh well. 16:54:31 <m_schnei> boris: discussion about UTC [scribe didn't get it] 16:54:33 <Carsten> goodbye from this timezone. Have to leave. 16:54:35 <sandro> dlm, what's your problem with reject-as-error? 16:54:46 <Zakim> -Carsten 16:55:16 <sandro> msmith: leave it to tools to convert to UTC or local time zone. 16:55:23 <m_schnei> msmith: not reject-as-error, but implementations may clean it up 16:55:31 <Deborah> was just thinking of bijan's point - i retract my objection. what i do not want is for people not to be able to use owl if they are working with relative readings and they do not know the time zone. 16:55:48 <m_schnei> msmith: automatic-UTC would be against XSD 16:55:50 <sandro> sandro: I'd object to "no-time-zone" == "UTC". 16:55:54 <Deborah> i suppose they could work with an application layer putting in a place holder utc for this and then updat later if required. 16:56:02 <uli> 1 or 3 are equally fine with me 16:56:10 <uli> Sandro, why? 16:56:17 <sandro> pfps: "Tools MAY do sometihng reasonable, adding a time zone, with a warning" 16:56:29 <bparsia> I like 3 16:56:39 <uli> I like 1 and 3 16:56:51 <uli> ...and I like Peter's suggestion 16:57:14 <pfps> PROPOSAL: datetime literals with missing timezones are not in the syntax; tools MAY insert a timezone, but SHOULD produce a warning if they do so 16:57:18 <bmotik> +1 Oxford 16:57:20 <Achille> +1 IBM 16:57:26 <pfps> +1 Bell Labs 16:57:28 <baojie> -1 16:57:33 <ekw> +1 16:57:37 <sandro> +1 W3C 16:57:41 <msmith> +1 C&P 16:57:42 <uli> +1 Manchester 16:57:58 <m_schnei> 0 FZI 16:58:15 <Zhe> +0.5 ORACLE 16:58:40 <jar> +0.5 Science Commons to make the total integral 16:59:23 <Zakim> -uli 16:59:30 <Zakim> -bparsia 16:59:38 <bparsia> zakim, bijan 16:59:38 <Zakim> I don't understand 'bijan', bparsia 16:59:40 <bparsia> er 16:59:41 <Zakim> -rob 16:59:54 <Deborah> note sure what a half vote exactly means but that seems to capture it for me 17:04:10 <uli> anybody still there? 17:04:26 <uli> will we do n-ary after lunch or annotations? 17:04:56 <uli> alan, are you still there? 17:15:17 <pha> pha has joined #owl 17:20:12 <ekw> ekw has joined #owl 17:31:57 <uli> thanks, Peter ;) 17:47:22 <ekw> ekw has joined #owl 17:58:35 <ekw_> ekw_ has joined #owl 18:02:53 <m_schnei> ian: we have to decide whether to proceed on datatypes 18:03:08 <m_schnei> alanr: n-aries 18:04:10 <Zakim> +??P3 18:04:12 <Zakim> -??P3 18:04:12 <Zakim> +??P3 18:04:15 <m_schnei> ian: jie, what is the reason why you said "no" in the straw poll 18:04:17 <bijan> zakim, ??p3 is me 18:04:17 <Zakim> +bijan; got it 18:04:22 <bijan> zakim, mute me 18:04:22 <Zakim> bijan should now be muted 18:04:36 <Zakim> +??P9 18:04:40 <m_schnei> jie: my proposal is to support partial time types 18:04:42 <pfps> ScribeNick: bmotik 18:05:01 <bmotik> Topic: Handling of time zones in xsd:dateTime 18:05:02 <bmotik> baojie: A constant wihtout a time zone is a range, not a value 18:05:16 <m_schnei> baojie: missing time zone is syntactic sugar for continuous interval 18:05:34 <bijan> What continuous interval? 18:05:48 <baojie> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0421.html 18:06:04 <uli> ? same question as bijan 18:06:42 <bijan> I'm against this 18:06:52 <bijan> I think 18:06:57 <uli> me to - we have an intervall being a default for a time point? 18:07:07 <bijan> We have to *introduce* intervals? 18:07:38 <bmotik> Achille: This seems confusing 18:07:49 <bmotik> Achille: This makes the value space of xsd:dateTime confusing 18:07:55 <bijan> This, again, can be handled by preprocessors 18:08:08 <bmotik> Achille: The value space of xsd:dateTime would contain both points and sets of points 18:08:15 <pfps> so two values from the same file like <today,1pm> <today,2pm> are non-comparable? 18:08:37 <uli> sure, if they come from different files? 18:08:52 <bmotik> msmith: Saying hasValue("some time without a time zone") would give you a range of values rather than a single value 18:09:39 <bmotik> bijan: This is not an imporvement over the existing proposal 18:09:43 <bmotik> The analogy to integer intervals is broken because for integer intervals, you are using them for data ranges, not data values 18:10:01 <bmotik> bijan: The existing proposal already allows you to do some reasonable stuff with missing time zones 18:10:24 <bmotik> baojie: Fully specified values should be specified as values 18:10:41 <bmotik> baojie: Partially specified values should be interpreted as a range 18:10:51 <bijan> For example, on throwing a syntax error, a tool can say, "You've not given a time zone. Either supply on or insert the following expression which covays that you don't know." 18:11:02 <bmotik> IanH: But then you get into the "every Monday" case 18:11:11 <bmotik> baojie: Interval is the most important 18:11:34 <bmotik> m_schnei: Test case: we have the time 20:11; what does it mean? 18:12:25 <bmotik> baojie: I am not clear about this either 18:13:17 <bmotik> baojie: My proposal doesn't address this case 18:13:42 <bmotik> baojie: It addresses only top-down partially specified time dates and the interpretation is the interval 18:14:07 <bmotik> baojie: So just "July" is not allowed; you could say something like "July 2007" 18:14:48 <bmotik> Achille: For that kind of duration we already have in XML Schema gYearMonth. 18:14:59 <bmotik> Achille: These are completely different datatypes 18:15:21 <bmotik> Achille: These specify durations, not time points (which is the main thing that we describe using xsd:dateTime) 18:16:28 <bmotik> Achille: We would be thus inventing a new datatype 18:16:50 <bmotik> IanH: This is not a legal xsd:dateTime value in XML Schema 18:17:09 <bmotik> IanH: If we want to do that, we should use the appropriate datatypes from XML Schema 18:18:10 <bmotik> alanr: It seems that we are confusing the problem of partially specified date-times from the problem of interpreting missing time zones 18:18:58 <bmotik> alanr: We might interpret missing time zones as being existentially quantified 18:19:12 <bmotik> IanH: My feeling is that all this sounds pretty horrible and messy 18:19:20 <bmotik> IanH: Implementors feedback? 18:19:59 <bmotik> sandro: From a user's perspective, if I don't put time zone in, I'm being lazy and I shouldn't be surprised if I am getting a wrong answer 18:20:17 <bmotik> baojie: What if the time zone information is lost? 18:20:31 <bmotik> sandro: Then the computer has to ask me and fill in the missing time zone 18:20:42 <bijan> If time zone inforamtion is lost, someone has to make a choice and that's application dependent 18:20:46 <bijan> Perahps I'm happy defaulting to UTC 18:20:52 <bmotik> baojie: The tool should be responsible for checking for a missing time zone 18:20:52 <bijan> perhaps I'm happy defaulting to my time zone 18:21:01 <bijan> Perhaps I'm happy adding an interval 18:21:35 <bmotik> baojie: I need to rethink this 18:21:51 <bmotik> IanH: We can try to have a new vote by the end of the F2F 18:22:42 <bmotik> Zhe: Oracle will always attach the session time zone to date-time literals that miss the time zone 18:23:01 <bmotik> Zhe: You can always set the session time zone programmatically 18:23:28 <bmotik> m_schnei: Oracle never compares date-times with time zone with date-times without time zones, right? 18:23:33 <bmotik> Zhe: Right 18:24:00 <bmotik> Topic: Annotations 18:24:01 <bmotik> IanH: We will come back to nary later (as time permits) 18:24:35 <bmotik> IanH: There is a basic proposal for annotations on the table plus an extension 18:25:00 <bmotik> alanr: The idea of the added proposal was to allow for separate reasoning with annotations 18:25:36 <bmotik> IanH: So this is an extension of Bijan's proposal allowing for serialization of Bijan's proposal plus annotations on annotations 18:25:47 <bmotik> pfps: But this is missing BLOBs 18:27:37 <bijan> Blobs exists to avoid having to name axioms 18:30:47 <bmotik> alanr: The essential idea is that there is two separate reasoning spaces for reasoning 18:30:57 <bmotik> alanr: The domain space and the annotation space 18:31:04 <bmotik> alanr: No interaction without it 18:31:18 <bmotik> alanr: Bijan supported an abstract syntax for it 18:32:01 <bmotik> IanH: Before we go through the proposal, I'd like to see what we think of annotations in general 18:32:22 <bmotik> IanH: Do we think that the basic idea of rich annotation spaces is a good idea and do we want to have it in OWL? 18:32:46 <bmotik> m_schnei: The idea that we want to have some processing on annotations is a good idea, but seems out of scope of this WG 18:32:51 <uli> I have heard Alan Rector and others require richer annotations a lot (annotation axioms, annotating annotations) 18:33:08 <bijan> Why and how is it out of the scope of OWL? What was the reasoning for that? 18:33:25 <bmotik> msmith: I disagree. There are lots of ontologies that contain annotation property hierarchies and this proposal would allow us to accept more of those. 18:33:36 <Zhe> Mike, could you give an example or a pointer? 18:33:37 <bijan> Dublin Core is the most common, zhe 18:33:38 <bijan> And just recently: http://www.w3.org/mid/D98C2F92-76A0-441F-BF8B-D901DF12A73B@cyganiak.deD901DF12A73B@cyganiak.de 18:33:39 <bmotik> bijan: I didn't understand the scope argument 18:33:58 <bmotik> bijan: People building large ontologies often want to have complex annotations 18:34:37 <bmotik> Zhe: Can you give an example of annotation property hierarchies? 18:34:41 <bmotik> alanr: SKOS, FOAF 18:36:13 <msmith> skos at http://www.w3.org/2004/02/skos/vocabs creates subproperties of rdfs:label 18:36:55 <bijan> subproperties of rdfs:label are common for reasons given: http://www.w3.org/mid/3394C7CF-B080-45AD-AE7C-B498FC6C8B3E@cs.man.ac.ukB498FC6C8B3E@cs.man.ac.uk 18:34:50 <bmotik> alanr: In OWL we can't handle such things 18:35:48 <bmotik> bmotik: If this turns out to be something simple, than OK; if this turns to be complex, than this may be out of scope 18:36:08 <bmotik> alanr: I tried to define what is the bare minimum of the functionality 18:36:26 <bmotik> alanr: My proposal is somewhat simpler than Bijan's 18:36:58 <bmotik> alanr: I tried to reduce the complexity of the proposal 18:37:30 <bmotik> bijan: The complexity is all in the RDF serialization. 18:37:53 <bmotik> bijan: All of these things are rather easy in all other linear syntaxes 18:38:06 <bmotik> bijan: The multiple file proposal adds a complication 18:38:58 <bmotik> IanH: Alan's proposal is based on your proposal, but simplified. 18:39:13 <bmotik> IanH: Is that a simplification too far from your point of view? 18:39:23 <bmotik> IanH: Do you think that Alan's simplification might be enough? 18:39:36 <bmotik> bijan: I didn't solve the nesting of annotations in my proposal 18:40:44 <bmotik> alanr: It might be possible to take the second blob from the other file and put it into the first file 18:40:51 <bmotik> alanr: as a literal. 18:41:16 <Deborah> i would use the ability to be able to annotate annotations - I need that in my explanation / inference web work 18:41:25 <bmotik> alanr: If we don't go to rich annotations, I'd like to go back and put certain things into the spec so that we have some of that functionality 18:41:58 <bmotik> bijan: Putting things into one big literal is much worse than having lots of small literals 18:42:22 <bijan> It's on the proposal page 18:42:39 <bmotik> bmotik: Could someone specify the use cases and present an overview of the two proposals? 18:43:47 <bmotik> alanr: I'm taking inspiration from Boris's et al. paper and from Bijan's proposal 18:44:16 <bmotik> alanr: I didn't include from Boris's proposal the reified versions of axioms 18:44:32 <bmotik> alanr: From Bijan's, I used the idea of multiple annotation spaces 18:45:38 <bmotik> alanr: presents http://www.w3.org/2007/OWL/wiki/Annotation_system_2 18:45:49 <bmotik> boris: alan, can you give an example 18:46:25 <bmotik> alanr: we have a single document 18:47:22 <bmotik> alanr: we have all the axioms, and a few more things 18:48:11 <bmotik> alanr: ... the annotation stuff goes then in the second document 18:48:37 <bmotik> boris: what should be put in the structural spec 18:49:34 <bmotik> alanr: reasoning about the second document's content doesn't affect / isn't affected by the content of the first 18:50:46 <bmotik> alanr: also, we can have types/parts of e.g. properties, which do not have any affect on the first document 18:51:12 <bmotik> alanr: ... e.g. we want data properties 18:52:06 <bmotik> alanr: we also need to make clear which ontology is annotated by the annotation space, so we need refer the name of the first document [FIXME] 18:52:13 <bmotik> IanH: This is starting to sound scary 18:52:16 <bijan> I get scared at the naming bit; this makes hand authoring nearly impossible 18:53:08 <bmotik> m_schnei: In the second document, you actually have assertions such as "This proporty is a data property" 18:53:29 <bmotik> m_schnei: So there actually is some OWL semantics in the second document; however, this doesn't affect the first document 18:56:54 <bmotik> m_schnei: This might have problems in OWL Full 19:01:52 <bmotik> alanr: (completes his description of the proposal) 19:02:25 <bmotik> bijan: If we simplify the proposal to the degree that Alan talked about, we then can use multiple literas inside one XML file 19:02:33 <bmotik> bijan: This significantly simplifies serialization 19:03:01 <bmotik> bijan: If we're going to simplify, we can simplify it like that 19:03:33 <bmotik> bijan: We don't have the right kind of stuff in RDF 19:03:53 <bmotik> bijan: We might specify things for other syntaxes and wait for RDF until they extend the language 19:04:20 <bmotik> bijan: such as named graphs 19:04:52 <bmotik> bijan: We might provide a decent target for RDF people as to what they might want to taget 19:06:26 <bmotik> bmotik: What is the use case? 19:06:52 <bmotik> bmotik: If we want to say sub-annotation-property-of, why don't we do just that? 19:07:06 <bmotik> pfps: Bijan's proposal is concrete but there is no serialization yet 19:07:45 <bmotik> alanr: My proposal says how things get fed into reasoners 19:08:04 <bmotik> pfps: Bijan's proposal says that you can use any reasoner to interpret the ontology 19:08:24 <bmotik> pfps: Bijan's proposal conceptually creates a new document and reasons only over that 19:08:55 <bmotik> IanH: Bijan seems to agree that his proposal is difficult to serialize 19:09:03 <bmotik> pfps: Multiple annotation spaces make this tricky 19:09:18 <bmotik> Bijan: In some sense you can do it. 19:09:27 <bmotik> Bijan: I don't think it is uglier than this proposal. 19:10:05 <bmotik> Bijan: I don't understand the advantage of Alan's proposal other than it says that he has two files which makes it clear that they are interpreted separately 19:10:25 <bmotik> Bijan: Whatever we do with RDF, it'll be unpleasant. 19:11:10 <bmotik> m_schnei: We might allow for some syntax (subannotation property) without saying what the semantics is 19:11:12 <bijan> And would we have trouble with punning? 19:11:16 <bmotik> alanr: We care about semantics 19:11:50 <bmotik> IanH: If we factor in the time line, all of this sounds completely infeasible to me 19:11:54 <bijan> I'm happy to propose an rdf serialization 19:12:08 <bmotik> IanH: It sounds compleicated, we don't understand it precisely, the serialization is complex... 19:12:35 <bmotik> sandro: Bijan suggested that we might go with the proposal and forget about the serialization for the moment 19:13:18 <bmotik> sandro: How much of this would be simpler if we didn't try to fit things into the same document? 19:13:24 <bmotik> alanr: It seems much simpler to it 19:13:57 <bmotik> IanH: I heard during the presentation that people were really confused 19:14:24 <bmotik> sandro: Maybe we should try for you to explain this to one or two people first... 19:14:41 <uli> perhaps we could see whether people want rich annotations with semantics at all? 19:15:07 <bmotik> pfps: I pointed out some things that I didn't understand 19:15:08 <uli> and how much not having a pretty rdf serialization would matter 19:15:42 <uli> Boris, we pointed to skos and foaf. More concrete than this? 19:16:00 <uli> plus annotation on annotations? 19:16:08 <uli> simple would be beautiful, Boris! 19:16:28 <bmotik> alanr: I came up with a mixed proposal 19:16:39 <bmotik> alanr: There are use cases, that's clear 19:16:46 <bmotik> bijan: I have a proposal 19:17:06 <bmotik> bijan: I would try to capture as much as possible of Alan's proposal in one file 19:17:46 <uli> plus some transitivity 19:18:03 <bmotik> bmotik: I'd like to understand what reasoning we need to do 19:18:28 <bmotik> alanr: I want not to aggravate users by leaving out the annotations 19:18:31 <uli> +1 to alanr that richer annotations are really important 19:18:58 <IanH> getting finished is also important! 19:19:17 <uli> yes, Ian 19:19:11 <bmotik> m_schnei: In SKOS, it has been said 50 times that it is an OWL Full language 19:19:30 <bmotik> m_schnei: If we can change OWL such that SKOS falls into OWL-DL, that'd be a success 19:20:35 <bmotik> IanH: I see that annotations are importat, but this is supposed to be a part of the core spec 19:20:47 <bmotik> IanH: We didn't get very far with this in 9 months 19:21:09 <bmotik> alanr: We didn't make sure that there is a concrete proposal for this in due time 19:21:22 <pha> from http://www.w3.org/TR/2008/WD-skos-reference-20080609/ : "skos:prefLabel, skos:altLabel and skos:hiddenLabel are each instances of owl:DatatypeProperty." 19:21:49 <uli> Boris, does this give us annotations of annotations? 19:22:08 <bmotik> bmotik: I have a simple proposal 19:22:35 <bmotik> bmotik: Just extend OWL DL with simple types of axioms about annotation properties 19:22:46 <bmotik> msmith: Bijan's proposal is much more elaborate 19:23:12 <bmotik> pfps: I have a proposal for serializing annotations on annotations 19:23:33 <bmotik> alanr: Do we have a semantics for annotations? 19:23:41 <bmotik> pfps: No semantics 19:24:22 <bmotik> pfps: Two things are missing in Bijan's proposal 19:24:43 <bmotik> pfps: 1) Multiple annotation spaces --> Use reification 19:26:03 <bmotik> pfps: 2) cut down rich annotations: single annotation space, syntax for annotations is OWL, semantics of annotations is OWL, pragmatics of annotations is mayIgnore 19:26:04 <bmotik> jar: It seems to me that it is not clear what the requirements are 19:26:18 <bmotik> IanH: There is some document that describes use cases 19:26:53 <bmotik> alanr: Many use cases were floating around 19:27:10 <bmotik> alanr: Manchester people then came up with a proposal 19:27:25 <bmotik> alanr: This gives you all of OWL 19:28:38 <bmotik> bmotik: We always meant this to be something that tools would do 19:28:58 <bmotik> IanH: There are four people who have proposals 19:29:09 <bmotik> IanH: Bijan is offering an XML serializaion 19:29:16 <bmotik> Bijan: No 19:29:26 <bmotik> Bijan: I would offer an RDF serialization as well 19:29:43 <bmotik> IanH: When? 19:29:47 <bmotik> Bijan: Next week 19:29:51 <bmotik> IanH: If not? 19:30:00 <bmotik> Bijan: I'll burn in the 4th circle of hell 19:30:24 <bmotik> alanr: If Bijan and Peter have a way of fixing my proposal, I'm fine with it 19:30:41 <bmotik> IanH: Is Peter's proposal the same as Bijan's? 19:30:48 <msmith> action bijan to provide an rdf serialization for his rich annotation proposal 19:30:48 <trackbot> Created ACTION-174 - Provide an rdf serialization for his rich annotation proposal [on Bijan Parsia - due 2008-08-04]. 19:30:50 <bmotik> pfps: I believe that it is 19:31:21 <jar> Alanr, you want something that meet "the" goals, but what if they meet someone else's goals, and then don't meet yours? That's why I ask where the goals are written down. 19:31:50 <bmotik> pfps: The UUIDs in Alan's proposal have nonstandard semantics 19:32:12 <bmotik> alanr: This is meant to be just an abbreviation 19:32:25 <bmotik> pfps: We haven't seen a hint of how this interacts with the rest of the world 19:32:57 <bmotik> alanr: In m(O) they are interpreted as ... (missed the end, sorry!) 19:34:37 <bmotik> Bijan: I am not sure what is the nonstandardness Peter is referring to 19:34:53 <bmotik> Bijan: Are we constructing and deconstructing a URI? 19:35:07 <bmotik> alanr: We are just giving a name to blank nodes 19:35:18 <bmotik> alanr: THere is no deconstruction 19:35:47 <bmotik> Bijan: How do I round-trip an ontology? What happens to these URIs? 19:35:57 <bmotik> alanr: I haven't looked at how this gets serialized to XML 19:36:26 <bmotik> Bijan: If I load an ontology into a triple store and I delet the axiom from a domain, what happens to an annotation? 19:36:46 <bmotik> alanr: Without extra tooling, you can destroy things 19:37:41 <bmotik> bmotik: I don't understand Bijan's proposal 19:38:59 <bmotik> bijan: Each annotation space is a separate domain 19:39:31 <uli> 'projection' is the magic word? 19:39:58 <uli> query different projections separately 19:41:15 <bmotik> msmith: You might want to name the annotation spaces for extensions 19:41:47 <bmotik> IanH: How do we go forward? 19:42:11 <bmotik> alanr: Bijan and Peter might work towards a proposal, and I might document my proposal more clearly 19:43:09 <bmotik> alanr: If there is no proposal for rich annotations, then I'd like to start working on alternatives immediately 19:43:40 <bijan> Sure 19:43:54 <bijan> Me too 19:44:03 <bijan> Peter speaks words of wisdom 19:44:17 <bmotik> IanH: If Bijan and Peter don't produce something in two week, we ditch the proposal? 19:45:01 <bmotik> pfps: OK 19:45:11 <bmotik> IanH: Alan's going to work on a simplified proposal? 19:45:35 <bmotik> IanH: Who thinks that rich annotations are really needed and doable and that we should decide now to do something? 19:46:15 <bmotik> alanr: Mike, what do you think? 19:46:17 <sandro> Ian: Should we direct Alan to rich annotation, or push him to do some less-general but not "rich annotations" direction? 19:46:33 <bmotik> msmith: I'm confident in Bijan and Peter 19:46:47 <bmotik> IanH: It seems futile to be working on two propsals 19:47:19 <bmotik> IanH: It seems more useful for Alan to scope out what would be an alternative 19:48:00 <bmotik> IanH: Action on us to scope out a proposal in two and a half weeks? Two wednesdays from next wednesday? 19:48:16 <bmotik> IanH: In a fortnight we'll have a discussion at a teleconf. 19:50:24 <sandro> http://www.w3.org/2007/OWL/wiki/Chatlog_2008-07-28 19:50:43 <Zakim> -dlm 19:51:06 <bijan> Is there a break? 19:51:11 <bijan> OR just garbledness 19:51:56 <sandro> Topic: Afternoon Break 19:52:25 <Zakim> -bijan 19:58:46 <baojie> baojie has joined #owl 20:03:04 <ekw_> ekw_ has joined #owl 20:10:29 <ekw_> ekw_ has joined #owl 20:10:50 <ekw> scribenick:ekw 20:12:19 <ekw> topic: Profiles 20:20:16 <IanH> We are *really* about to restart 20:21:45 <ekw> subtopic: Marketing viewpoint on profile names 20:21:46 <ekw> summary:Discussion with Karen Myers from W3C 20:21:50 <sandro> zakim, who is on the call 20:21:50 <Zakim> I don't understand 'who is on the call', sandro 20:21:53 <sandro> zakim, who is on the call? 20:21:53 <Zakim> On the phone I see +1.617.253.aaaa 20:22:06 <sandro> zakim, aaaa is Meeting_Room 20:22:06 <Zakim> +Meeting_Room; got it 20:22:51 <Zakim> +Karen 20:22:53 <Zakim> -Karen 20:22:53 <Zakim> +Karen 20:23:06 <Karen> Karen has joined #owl 20:23:30 <jar> jar has joined #owl 20:23:38 <ekw> alan: we have several profiles of OWL but we haven't reached agreement on names 20:23:55 <ekw> alan: we thought we bounce them off you and get your take 20:24:13 <ekw> karen: there are many different types of names and many architectures for names 20:24:52 <ekw> ... concept names, descriptive names, monagrams, alphanumeric, acronym, geographic 20:25:06 <sandro> concept names, "apple" 20:25:06 <sandro> monograms "bwm" 20:25:06 <sandro> descriptive "autozone" 20:25:06 <sandro> made-up-words, xerox 20:25:06 <sandro> alphanumeric, "c4" 20:25:27 <ekw> ... to think in terms of an architecture: 20:25:28 <ekw> ... Do you always want a primary reference like OWL2? 20:25:54 <ekw> karen: but you are adding other terms like fragments 20:26:11 <ekw> alan: we settled on "profile" 20:26:20 <ekw> alan: so this is resolved 20:26:47 <sandro> (speaker is Ian Horrocks, co-chair) 20:26:56 <ekw> ian: we have a language called owl DL 20:27:17 <ekw> ... the name OWL DL comes from DL standing for description logic 20:27:32 <ekw> ... and several of these profiles are subsets of OWL DL 20:27:57 <ekw> ... but the language as a whole can be used in different ways 20:28:30 <ekw> ... we wanted some subsets that are easier to reason with 20:29:11 <ekw> ian: another fragment is meant to address data in databases 20:29:28 <ekw> ... and another called OWL R for rules 20:29:59 <ekw> alan: we tried some single letter names 20:30:22 <ekw> ... but there was a desire to keep more of the names we had before 20:30:25 <baojie> baojie has joined #owl 20:30:45 <ekw> alan: partially we are doing with legacy names and the desire to keep them 20:31:27 <ekw> karen: before we go to a solution, acronyms aren't the best route when putting multiple such names together 20:31:51 <ekw> ... if you think about your descriptive structure, why not use a short descriptive name 20:32:26 <ekw> msmith: when we try to do that we run into problems with DL Lite 20:32:59 <ekw> ian: there is a contention between OWL rules people and OWL Lite as to which is the database profile 20:33:15 <ekw> ian: so talking about DBs is kind of ruled out 20:33:52 <ekw> msmith: it may not have been clear that we expect users to choose among profiles 20:34:39 <ekw> karen: we can't use the more generic categories, are there other dimensions we could follow? 20:35:02 <ekw> alan: EL++ lets you say less but lets you reason with lots of classes 20:35:12 <ekw> ... and has polynomial complexity 20:35:27 <ekw> ... OWL R is not particularly controversial 20:35:58 <ekw> sandro: looking at the competitive advantages they are all defensive about what they can't do 20:36:18 <ekw> ... there must be somethings that you really wouldn't want to use each profile for 20:36:46 <ekw> karen: you want to choose something memorable; people want to get it and remember it 20:37:13 <ekw> alan: the closest contenders are the single letter names 20:37:21 <ekw> karen: are you open to being creative? 20:37:40 <ekw> karen: are you open to doing barn owl, snowy owl, etc 20:37:52 <ekw> sandro: too whimsical 20:38:07 <ekw> ian: what about OWL SQL? 20:38:28 <baojie> baojie has joined #owl 20:38:47 <ekw> karen: could you add another qualifier? 20:39:49 <ekw> sandro: how about talking about guaranteed response time? 20:40:11 <ekw> sandro: the problem is the differences are so subtle 20:40:33 <ekw> ian: each group doesn't want to lose a competitive advantage 20:41:09 <ekw> msmith: we could make up a word, like car makers often do for model names 20:41:37 <ekw> karen: going back over the notes, seeing things like polynomial complexity 20:42:11 <ekw> mschnei: OWL T, OWL D and OWL R 20:42:32 <ekw> alan: could we just give them numbers? 20:43:07 <ekw> ian: if we really went with single letter names would it be so bad? 20:43:27 <m_schnei> However, OWL-D is similar to OWL-DL :( 20:43:39 <ekw> karen: the challenge is that it would be hard for people to remember the differences among single letter names 20:43:58 <ekw> sandro: we are leaving out OWL Full and OWL DL names from this discussion 20:44:26 <ekw> ian: OWL RDF would have been a better name for OWL Full 20:44:55 <m_schnei> "OWL RDF" instead of "OWL Full" would get my vote 20:45:00 <Karen> KM: likes looking for words like "reference" 20:45:06 <ekw> alan: we've been discussing this a long time, not sensing a lot of energy on this 20:45:26 <ekw> alan: another name for DL Lite would be OWL Table 20:46:11 <ekw> ian: I always end up going for the single letter designations at the end of these discussions 20:46:36 <m_schnei> "DB", "RL", "EL" 20:46:38 <ekw> alan: there was some push back to a previous suggestion to have some names 2 letters 20:47:05 <ekw> alan: who would find 1 letter names objectionable? 20:47:18 <Karen> +1 establish the guidelines you want 20:47:30 <ekw> sandro: I don't like that, I would like it to work well with OWL DL 20:48:18 <ekw> sandro: where the profiles are subsets, we could exploit that for ordering 20:48:39 <ekw> karen: one of the things about naming is that it comes to you in the middle of the night 20:48:56 <ekw> karen: let people think about it 20:48:57 <Zakim> -Karen 20:50:16 <sandro> ACTION: Sandro report back on names frameworks, naming options 20:50:16 <trackbot> Created ACTION-175 - Report back on names frameworks, naming options [on Sandro Hawke - due 2008-08-04]. 20:50:17 <ekw> See http://www.w3.org/2007/OWL/wiki/Profile_Names for the result of that action. 20:50:41 <sandro> Ian: EL and DL sounds very similar 20:50:42 <sandro> Zhe: DL-E, DL-R, ...? 20:50:46 <ekw> subtopic: OWL-R proposals 20:51:14 <ekw> alan: issue 131 about unifying OWL R DL and OWL R Full profiles 20:51:31 <baojie> q+ 20:53:30 <ekw> zhe: Ivan wants the set of rules to be part of RDF 20:53:52 <ekw> ian: I thought we came to some reasonable agreement in email about this 20:54:43 <ekw> achille: ian said that the only compliance is acheived if you can handle owl full 20:55:02 <sandro> q+ 20:56:06 <Achille> Achille has joined #owl 20:56:12 <sandro> q+ to double check that this means I can't use my OWL-R reasoner to find out what your OWL-R reasoner will produce. It producing or not-producing a trouble says nothing about if yours will. 20:56:54 <ekw> jie: my concern is OWL R or OWL R DL will be compatible with RDF 20:57:01 <ekw> ian: it will be 20:58:17 <sandro> Ian: I am not sure if OWL-R is a superset of RDFS. 20:58:23 <sandro> Boris: I think it is. 20:58:34 <ekw> ian: the rule set came from the OWL Prime implementation 20:58:53 <sandro> Zhe: some of the trivial stuff like S P O |= P type Property is not in there, on purpose. 20:58:57 <ekw> bmotik: for what we really care about, we are compliant 20:59:55 <ekw> sandro: this is about us not having an upper limit on the entailments from the semantics 21:00:16 <baojie> baojie has joined #owl 21:00:27 <ekw> sandro: the fact that a particular triple comes back on my query gives me no idea if it should come back on your query 21:00:57 <bijan> bijan has joined #owl 21:01:01 <ekw> ian: the idea is not to create to big a burden on implementations 21:01:16 <ekw> ian: to be honest unification doesn't affect this 21:01:33 <sandro> Ian: it's a tradeoff -- we could do it either way, but to detect (and prohibit) the extra stuff could be very expensive. 21:02:23 <bmotik_> bmotik_ has joined #owl 21:02:33 <sandro> sandro: I want cross-platform portability between different OWL-R systems. 21:02:36 <ekw> mschnei: there is an upper bound on possible entailments 21:02:52 <ekw> ... I can't just produce everything, there was this restriction 21:03:01 <ekw> ... for me this doesn't help much 21:03:13 <ekw> ... I ask for an RDFS conformant reasoner 21:03:22 <ekw> ... I get more than just the base, 21:03:57 <ekw> ... if I ask if this is really RDFS conformant, then I get what is really a PD* reasoner 21:04:31 <ekw> mschnei: I might get more than what I ask for 21:04:59 <ekw> msmith: in terms of interop, the best we can expect is the same response for the same inputs 21:05:07 <ekw> ... not arbitrary inputs 21:07:50 <ekw> mschnei: I am completely indifferent in how my reasoner behaves wrt to the syntactic spec 21:08:06 <ekw> mschnei: I just care about the rules 21:08:34 <ekw> bmotik: you are approaching this from a testing point of view 21:09:45 <ekw> bmotik: from a POV of users i think it is good if we can get syntactic guarantees 21:10:11 <ekw> bmotik: in OWL Full you can't completely do this, but we should get as close to that as possible 21:10:28 <ekw> ... you can handle more of OWL full by extending your set of rules 21:10:38 <ekw> ian: it is not a restriction 21:10:58 <ekw> alan: I am trying to get what criteria michael is looking for 21:11:36 <ekw> alan: are you uncomfortable because this does something that an OWL Full reasoner does? 21:12:05 <ekw> mschnei: I want OWL R to be a monotonic extension to RDFS 21:12:32 <ekw> ... I don't want only a part of it, why are the axiomatic triples left out? 21:12:51 <ekw> ... the second thing is ... what is compliant or not 21:13:04 <ekw> ... for me this is in terms of this rule set 21:13:30 <ekw> ... when you have a black box and implement these rules, the inferences should always be the same 21:14:02 <ekw> alan: there should be a compliance rule that says exactly the RDF triples that should be produced 21:14:20 <ekw> alan: sandro - was this your discomfort too? 21:14:46 <ekw> zhe: we are always going to provide an API for users. 21:15:08 <ekw> ... presumably this API will just run this ruleset, we can always do more. 21:15:40 <ekw> ... an option can reject RDF graphs that don't match the fragment. 21:16:00 <ekw> alan: wrt the axiomatic triple issue is there a problem 21:16:25 <ekw> ian: the infinite triple issue is a problem with this, Alt and Bag 21:16:39 <ekw> mschnei: this is just an annoyance 21:16:54 <ekw> boris: axiomatic triples no problem 21:17:24 <ekw> boris: we are ready have an infinite set of rules and we will have an infinite set of triples 21:17:48 <ekw> boris: so the implementation has already to look into the ontology and handle it 21:18:13 <ekw> alan: now the second issue 21:19:02 <ekw> boris: this is not what the users want 21:19:20 <ekw> boris: you find an ontology on the web, the question is how to interpret this 21:19:38 <ekw> alan: multiple conformance levels 21:19:48 <ekw> alan: strict mode means this for testing 21:20:08 <ekw> boris: I think the difference is what happens in the case you have an RDF graph 21:20:23 <ekw> ... that falls outside of this syntactic fragment 21:20:41 <ekw> ... you are trying to explain what these ontologies on the web mean 21:21:11 <ekw> sandro: owl intended profile is a band aid, if we can avoid it great 21:22:04 <ekw> boris: suppose you have an ont that claim it is intended OWL R but it has components outside of its fragment 21:22:24 <ekw> ian: this will cause the OWL R Full reason to produce unsound results 21:23:15 <ekw> msmith: why isn't this a burden on the tool vendor, if he is going to extend its behavior outside the fragment? 21:23:54 <ekw> ian: apart from these wrinkles, owl DL and OWL full are aligned with respect to these entailments 21:24:25 <ekw> sandro: I am hearing the tools are going to do best effort 21:25:28 <ekw> achille: to try to understand 21:25:58 <ekw> ... my confusion comes from two normative features: syntactic restriction and owl rules 21:26:35 <ekw> ... in owl full, if you go beyond it that is the end of the story 21:26:52 <ekw> alan: there are some who are very focused on the rules 21:27:10 <ekw> ... and other who think of the rules as that's just how you do it 21:27:38 <ekw> ian: what boris said before, this rules thing, isn't it coming from the perspective of the implementers? 21:28:14 <ekw> ian: do they really expect the users to look at this complicated rule set and understand the language? 21:28:52 <ekw> zhe: the user wants you to produce something they expect, they don't care if you produce more 21:29:28 <ekw> zhe: they only care about the completeness of the results that they are interested in 21:29:52 <ekw> zhe: for instances in info integration, they only care that an individual is sameAs another 21:32:14 <ekw> boris: there is a certain set of graphs for which you can get entailments from the OWL R rules 21:32:42 <ekw> alan: but really users want to use graphs outside of your fragment 21:33:08 <ekw> ian: they are outside the fragement where you can say its guaranteed that everything will work OK 21:33:29 <ekw> achille: why impose this constraint only on this fragment 21:34:00 <ekw> boris: because the other fragments are simply syntactic fragments 21:35:22 <ekw> boris: what we wanted to do was to say if you get more than OWL R, go with OWL Full semantics 21:38:08 <ekw> mschnei: what I think I have heard several times is the rules are an implmentation 21:38:42 <ekw> ... for me rules are the perfect specification, 21:39:10 <ekw> ... I think its true that people on care about things they expect, 21:39:27 <ekw> ... but you don't want to get everything. 21:40:00 <ekw> mschnei: for me what OWL R from the beginning was to be an extension to RDFS that does more 21:40:17 <ekw> alan: is there such a thing as strict mode? 21:40:45 <ekw> alan: if an OWL DL ontology itself is outside OWL R 21:41:16 <ekw> ... if you give this to an OWL R reasoner built on the rule set it will do one thing 21:41:35 <ekw> ... if you give it to an OWL DL reasoner it would do something else 21:41:55 <ekw> mschnei: what's the problem? 21:42:23 <ekw> boris: to the point about ruleset being a good spec, I agree 21:43:34 <ekw> boris: if you now use this form of semantics after we have created the others, it just defines a 3rd different semantics 21:43:42 <ekw> ... and this is not good 21:43:50 <sandro> Alan: Is it a good idea to say that there is an OWL-R strict mode? I want to survey the room 21:44:14 <sandro> Ian: Is it a good idea to introduce a third semantics? That's how I'd phrase it! You're really saying we'd have a third semantics. 21:44:30 <ekw> ian: w/strict mode you are really saying we are creating a 3rd semantics 21:45:32 <sandro> sandro: from the user community perspective, it's a seventh semantics (because there is also RDFS, etc, RDF semantics) 21:45:41 <sandro> Ian: Same syntax, different semantics. 21:46:04 <ekw> achille: I want to go back to whether we are or not going with a strict mode 21:46:32 <ekw> ... if we go back to two sublanguages, the strict mode for OWL R DL would work pretty well 21:46:59 <ekw> ... now it seems to me that merging OWL Rs creates more confusion 21:47:19 <m_schnei> I first thought, when hearing "third semantics" that a third *system* of semantics is meant, but it's only a, well third semantics, ok 21:47:35 <bijan> If OWL-R isn't a syntactic subset, then some RDF graphs will have 3 semantics! 21:47:38 <bijan> (Or 4!) 21:47:41 <ekw> alan: I think that we understand the question in both forms 21:48:06 <ekw> ... can we get a sense from people what the room thinks? 21:48:29 <m_schnei> bijan, we can have a complete stack of RDFS extensions :) 21:48:30 <bmotik> subsubtopic: Strawpoll on having new OWL semantics defined by a rule set 21:48:43 <bmotik> STRAWPOLL: Do we think it is a good idea to introduce a new semantics for OWL defined by a rule set / have an OWL-R strict mode? 21:48:46 <bmotik> -1000 21:48:50 <pfps> -1000 21:48:51 <Achille> -1 21:48:53 <m_schnei> +1 21:48:57 <IanH> -1 21:48:57 <msmith> -1 21:48:58 <pha> -1 21:48:58 <baojie> -1 21:49:00 <bijan> -bmotik*pfps 21:49:06 <sandro> +0.2 21:49:12 <Zhe> +0 21:49:15 <ekw> +0 21:49:27 <alanr> 0 21:50:51 <ekw> mschnei: I need to check with 21:51:05 <ekw> ... FZI about what they think 21:51:48 <ekw> alan: Michael - can you go back to your organization and find out where you stand? 21:53:11 <ekw> subtopic: signalling semantics 21:53:46 <sandro> Ian: Tell Users: If you intend OWL Full semantics, then include some specific bit (which we'll provide) of vacuous OWL full. 21:53:49 <ekw> ian: instead of specifying intended semantics, we advise people in the spec 21:54:10 <sandro> alan: eg: owl:Thing owl:sameAs owl:Thing 21:54:11 <ekw> ian: if they intend the OWL Full semantics always include these triples 21:54:52 <sandro> sandro: owl:sameAs owl:sameAs owl:sameAs 21:48:30 <pfps> subsubtopic: Strawpoll on signaling semantics 21:56:49 <pfps> STRAWPOLL: The way to signal that an OWL ontology should be interpreted as OWL Full is to include a triple that takes the ontology out of OWL DL, namely owl:sameAs owl:sameAs owl:sameAs 21:56:51 <bmotik> +1 21:56:57 <pfps> +1.1 21:56:58 <Achille> +1 21:57:01 <sandro> +1 21:57:03 <Zhe> +1 (sounds hacky though) 21:57:04 <pha> +1 21:57:05 <m_schnei> +1 (why not?) 21:57:07 <bijan> +1 21:57:08 <ekw> +1 21:57:15 <msmith> +1 21:57:58 <IanH> +1 21:58:17 <baojie> +1 21:58:29 <ekw> We are done for the day! 22:01:16 <sandro> http://maps.google.com/maps?f=d&hl=en&geocode=&saddr=32+vassar+st,+cambridge,+ma&daddr=900+Beacon+Street,+Boston,+MA+02215&sll=42.35368,-71.101215&sspn=0.019441,0.042315&doflg=ptm&ie=UTF8&ll=42.354136,-71.097636&spn=0.019441,0.042315&z=15 22:01:32 <sandro> 900 Beacon Street, Boston, MA 02215 22:05:01 <Zakim> disconnecting the lone participant, Meeting_Room, in SW_OWL()8:00AM 22:05:03 <Zakim> SW_OWL()8:00AM has ended 22:05:04 <Zakim> Attendees were +1.617.253.aaaa, bparsia, rob, uli, Carsten, bijan, dlm, Meeting_Room, Karen 22:14:15 <alanr> alanr has joined #owl 22:22:04 <alanr> alanr has joined #owl