12:49:29 RRSAgent has joined #owl 12:49:29 logging to http://www.w3.org/2008/07/28-owl-irc 12:49:35 zakim, this is owl 12:49:35 pfps, I see SW_OWL()8:00AM in the schedule but not yet started. Perhaps you mean "this will be owl". 12:49:47 zakim, this will be owl 12:49:47 ok, pfps; I see SW_OWL()8:00AM scheduled to start 49 minutes ago 12:55:08 zakim, who is on the phone 12:55:08 I don't understand 'who is on the phone', pfps 12:55:37 IanH has joined #owl 12:56:29 RRSAgent, make records public 12:58:35 SW_OWL()8:00AM has now started 12:58:37 + +1.617.253.aaaa 12:59:31 bparsia has joined #owl 13:00:12 m_schnei has joined #owl 13:00:46 +??P7 13:00:50 zakim, ??p7 is me 13:00:50 +bparsia; got it 13:00:53 zakim, mute me 13:00:53 bparsia should now be muted 13:01:01 ekw has joined #owl 13:01:21 I'm in 13:01:24 zakim, unmute me 13:01:24 bparsia should no longer be muted 13:01:50 zakim, mute me 13:01:50 bparsia should now be muted 13:03:12 bmotik has joined #owl 13:03:26 ScribeNick: pfps 13:04:16 pha has joined #owl 13:06:22 Topic: Welcome, local arrangements, introductions (9-9:15) 13:11:10 alanr: dinner possibilities - black sheep / elephant walk 13:12:08 alanr: elephant by acclamation 13:12:45 alanr: other local arrangements? 13:12:57 alanr: leaving times 13:13:21 pfps: 5ish 13:13:34 peter -- taxi south station 5ish 13:13:49 alanr has joined #owl 13:13:53 evan, michael -- taxi to airport 5ish 13:14:03 msmith has joined #owl 13:14:35 Zhe has joined #owl 13:15:41 alanr: scribing? 13:16:10 datatype session - m_schneider 13:16:17 annotations - boris 13:16:27 profiles - evan 13:17:42 introductions 13:18:07 q? 13:19:21 topic: roadmap, publication schedule 13:20:37 Present: Evan, msmith, mschnei, haase, zhe, sandro, alan, ian, boris, pfps, Miroslav 13:20:49 Fine 13:21:19 zakim, unmute me 13:21:19 sorry, bijan, I do not know which phone connection belongs to you 13:21:26 zakim, who is on the call? 13:21:26 On the phone I see +1.617.253.aaaa, bparsia (muted) 13:21:40 zakim, unmute me 13:21:40 bparsia should no longer be muted 13:21:48 alanr has joined #owl 13:21:54 zakim, mute me 13:21:54 bparsia should now be muted 13:22:24 Present: Evan, msmith, mschnei, haase, zhe, sandro, alan, ian, boris, pfps, Miroslav, Achille 13:22:43 alanr: schedule change - move datatypes earlier - no complaints voiced 13:22:44 missing: Jie 13:23:03 alanr: we may start on datatypes early 13:23:23 alanr: karen meyers may come for discussion on profile names 13:23:41 alanr: tomorrow's schedule is on tomorrow 13:24:14 Topic: Roadmap, Publication Schedule 13:24:25 alanr presents some slides 13:24:35 alanr: were are we (in schedule) 13:24:57 alanr: 9.5 months in 13:25:07 alanr: when can we do last call (on what documents0 13:25:59 alanr: try for last call decision on core documents at next F2F (late Oct) 13:26:11 alanr: last call documents published immediately after 13:26:24 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 ianh: we want review before F2F so the F2F would be a vote on the documents as reviewed 13:27:16 sandro: last call means that we have closed all relevant issues 13:27:47 sandro: we could have multiple possibilities ready beforehand 13:28:14 ianh: why not beforehand? 13:28:26 sandro: some issues may need a final F2F discussion 13:28:41 m_schneider: sounds realistic 13:28:56 xml syntax too, would be nice 13:29:11 alanr: core documents = syntax, semantics, full semantics, RDF mapping, profiles 13:29:36 alanr: goal try to close issues on these by F2F4 13:29:49 alanr: full semantics - try for WD in 3 weeks 13:30:50 q+ 13:30:50 alanr: requirements - try for first WD in 4 weeks 13:31:09 alanr: quick guide - try for first WD in ? weeks 13:31:28 q- 13:31:37 alanr: WD for other documents if there is significant change 13:31:51 alanr: this means syntax (at least) 13:32:10 msmith: what about test document 13:32:38 alanr: need to come up with estimate - need time in F2F (45min?) 13:32:44 msmith: 45 min seems OK 13:33:20 alanr: any comments? 13:33:30 sandro: this requires rapid progress 13:33:48 alanr: we may be "over the hump" on many thorny issues 13:34:02 Achille has joined #owl 13:34:13 ianh: there are a few sticky issues that have been hanging around 13:34:32 ianh: if we succeed on progressing in these then we should be OK 13:34:50 alanr: there is writing involved (e.g., in profile) 13:35:19 ianh: we need to have WG members who can do review step up and do it 13:35:52 m_schneider: what does LC mean? 13:36:09 ianh: LC documents mean that we think the document is done 13:36:29 LC documents mean we think the *technical design* is done 13:36:34 Editorial changes post LC are fine 13:37:01 sandro: polishing can be done after LC, particularly in response to comments 13:37:13 Example of kosher LC change: We change all the examples in the syntax document. Or we reorganize it 13:37:36 m_schneider: LC for profiles can be without polish 13:37:46 Example of nonkoser LC change: We change floats from being non-disjoint to disjoint with owl:number 13:38:01 (Where kosher means doesn't require another LC round.) 13:38:03 alanr: this is possible, but not desirable, we should try for readable documents 13:38:28 msmith: some polish can be contentious 13:38:35 q+ 13:39:02 ianh: polishing after LC should be in response to comments - other polish is not desirable 13:39:35 m_schneider: this means that feature freeze is end of September 13:39:45 q? 13:39:45 ianh: yes, but we may be close 13:39:56 zakim, unmute me 13:39:56 bparsia should no longer be muted 13:40:39 bparsia: what triggers a return to LC - editorial change is generally not a problem 13:41:02 alanr: what is grounds for objection - let's try not to push the envelope 13:41:26 zakim, mute me 13:41:26 bparsia should now be muted 13:41:27 bparsia: let's do our best, but significant delay into LC for editorial work is not desirable 13:41:39 Rinke has joined #owl 13:41:41 m_schneider: what are the stages of recommendation 13:41:55 alanr: closer to the end, more people look at us 13:42:05 sandro: LC = we are done, everyone look at it 13:42:10 Getting to CR will update the implementations. We want that sooner rather than later 13:42:19 sandro: CR = people should do implementations 13:42:34 sandro: PR = waiting for stamp of approval 13:42:52 Present: Evan, msmith, mschnei, haase, zhe, sandro, alan, ian, boris, pfps, Miroslav, Achille, JonathanRees 13:42:53 sandro: R = stamped, signed, sealed, and DONE 13:42:57 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 alanr: now switch to datatypes (early) 13:44:02 Topic: Datatypes 13:44:17 alanr: what is the current status? 13:44:40 alanr: last teleconference had quite a bit of consensus 13:44:59 Is there still talking? 13:45:04 alanr: see http://www.w3.org/2007/OWL/meeting/2008-07-16#Normative_datatypes 13:45:08 Ok, there we are 13:45:52 see also http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0306.html 13:46:01 This is number+ right? 13:46:10 Floats not integer 13:46:38 alanr: number+ is reals plus NaN, +inf, -inf, +0, -0 13:47:19 evan: the mapping from lexical to value appears to be missing 13:47:55 boris: value space is the thing, lexical space is how they are written 13:48:10 evan: but what is the mapping? 13:48:45 alanr: see functions and relation documents - there are coercion functions there - just use these as appropriate 13:49:01 alanr: thus we have a value space of the number line 13:49:29 evan: but how is the mapping defined 13:50:09 alanr: we are mixing a bit, xsd:integer is both on the lexical and value sides 13:50:43 boris: RDF literals are string (e.g., 123) and URI (e.g., xsd:integer) 13:51:01 rob has joined #owl 13:51:02 boris: but this URI is *not* the datatype! 13:51:29 alanr: can we have a better presentation? 13:51:35 +??P3 13:51:37 boris: be explicit 13:51:47 ianh: we have to go this way because of RDF 13:52:15 zakim, who is here? 13:52:15 On the phone I see +1.617.253.aaaa, bparsia (muted), ??P3 13:52:16 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 alanr: can we have all value spaces in owl: and lexical spaces in xsd: 13:52:50 Is it the case that ??P3 is you Rob? 13:53:08 yes 13:53:27 Uli -- are you on the phone? 13:53:34 q? 13:53:42 q- 13:54:02 jonathan: worry about losing information from RDF to OWL 13:54:05 +??P4 13:54:17 zakim, =??P4 is me 13:54:17 sorry, rob, I do not recognize a party named '=??P4' 13:54:29 zakim, +??P4 is me 13:54:29 sorry, rob, I do not recognize a party named '+??P4' 13:54:35 zakim, ??P4 is rob 13:54:35 +rob; got it 13:54:36 uli has joined #owl 13:54:38 boris: just need to say how to interpret URI as a constant URI and URI as a value space 13:54:45 zakim, mute me 13:54:45 rob should now be muted 13:54:48 What's the worry about losing information please? 13:54:48 zakim, who is here? 13:54:48 On the phone I see +1.617.253.aaaa, bparsia (muted), ??P3, rob (muted) 13:54:49 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 has joined #owl 13:55:06 sandro: datatype is a triple - we need to point to the explicit bit of this 13:55:11 zakim, ??P3 is me 13:55:11 +uli; got it 13:55:14 q- 13:55:26 ack ??P3 13:55:36 boris: yes, the document can be structured in this way 13:55:39 q? 13:56:09 achille: what is relationship between owl: value spaces and xsd: value spaces 13:56:25 baojie has joined #owl 13:56:39 achille: should we be clearer in comparison with xsd 13:56:51 Present: Evan, msmith, mschnei, haase, zhe, sandro, alan, ian, boris, pfps, Miroslav, Achille, JonathanRees, Jie 13:56:54 q? 13:57:00 achille: if we diverge from xsd we need to be very clear where and how 13:57:16 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 ? 13:57:57 Peter: 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 alanr: we have a different set of value spaces 13:58:23 s/Peter/pfps/ 13:58:35 q? 13:58:37 boris: we are very close to how they do it 13:58:41 I'm having trouble hearing, but I don't see why OWL should use XSD at *all* for its "value spaces". 13:59:17 Uli -- we can hear you 13:59:29 Or we could until someone muted you 13:59:41 boris: we work differently from xsd - xsd is about transmission we are about use 14:00:38 q+ 14:00:54 achille: we need to be careful - we are changing value spaces 14:01:18 achille: we want to be able to use DB and XSD stuff 14:01:36 ianh: we need to separate discussion of technical design and discussion of terminology 14:02:02 q- 14:02:25 ianh: any problems with underlying technical design 14:02:50 q+ 14:03:03 msmith: not sure whether technical or terminology - we have value spaces that encompass xsd, right 14:03:24 q- 14:03:27 ianh: this is a communication issue 14:03:37 q? 14:04:04 m_schneider: what are the differences between xsd and owl? 14:04:18 zakim, unmute me 14:04:18 rob should no longer be muted 14:04:19 sandro: is there an incompatibility? 14:04:29 q+ 14:05:01 sandro: I want to know what incompatibilities there are before deciding whether the design is okay. 14:05:25 rob: xsd is just a serialization, we need something more conceptual 14:06:07 Alan: in xsd, "2"^^int and "2"^^float are distinct. But in OWL we want them to be the same. 14:06:10 q? 14:06:18 alanr: xsd has disjoint value spaces (e.g., "2"^^xsd:integer and "2.0"^xsd:float) we don't 14:06:36 boris: differences - owl:number+ is a new value space 14:06:50 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 boris: differences - disjointness of integer, float, double (xsd yes, owl no) 14:07:32 boris: query in xml schema may diverge from us 14:07:38 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 boris: that's it 14:08:18 rob: rationale for xsd is serialization thus disjointness 14:08:27 I believe that double and float is disjoint in order to type functions in xpath and xquery 14:08:41 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 rob: new spec says that use of xsd can do what is needed 14:08:56 zakim, mute me 14:08:56 rob should now be muted 14:09:10 q? 14:09:12 q+ 14:09:14 ack rob 14:09:16 q- 14:09:27 zakim, mute me 14:09:28 rob should now be muted 14:09:32 jar has joined #owl 14:09:47 zakim, who is on the phone 14:09:47 I don't understand 'who is on the phone', rob 14:10:05 zakim, who is on the phone? 14:10:05 On the phone I see +1.617.253.aaaa, bparsia (muted), uli (muted), rob (muted) 14:10:05 Achille: At IBM we'll need to be very clear about the story on these datatypes between OWL and XS 14:10:06 achille: my concern is how to sell this (within IBM) - divergences in querying, migration paths 14:10:32 Achille: IBM has big investments in XML 14:10:49 queue? 14:11:30 boris: xquery is a huge spec - type casting might be built in 14:11:44 http://www.w3.org/TR/xquery/#id-type-promotion-and-operator-mapping 14:11:49 boris: xquery is syntactic - so it needs type coercion 14:11:59 boris: owl is semantic - things are either the same or different 14:12:06 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 zakim, ack me 14:12:09 unmuting bparsia 14:12:10 I see no one on the speaker queue 14:12:15 ack bparsia 14:12:20 achille: OK, communication is important, though 14:12:50 bparsia: look at MathML here. It might be better to borrow from them -- more about Math than about Data. 14:12:59 bparsia: could we use a different terminology (e.g., MathML)? 14:13:27 I think that I found the relevant bit from xquery http://www.w3.org/TR/xquery/#id-value-comparisons 14:13:30 bparsia: maybe we could use mathml:real, for example 14:14:23 achille: I can check the relationship between xquery and owl 14:14:30 I didn't understand the comment about "lack of type coercion" in owl 14:14:53 We can easily have operators that "coerce" (i.e., predicates with union types as arguments) 14:15:10 q? 14:15:22 m_schneider: two differences - owl:number+ is a new value space, non-disjointness of integer, float, double 14:16:23 That sounds like a procedural description of our proposed semantics. 14:16:24 boris: section 3.5.1 of xquery - type coercion - seems to be wrong for our purposes 14:16:25 type promotion in xquery http://www.w3.org/TR/xquery/#dt-type-promotion 14:16:44 ACTION: Achille to develop list of possible conflicts between XML Schema datatypes and OWL datatypes with valuespace reasoning 14:16:45 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 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 zakim, mute me 14:17:32 bparsia should now be muted 14:17:42 jonathan: what about union types? 14:18:16 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 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 boris: if float and integer are disjoint 14:19:32 jrees: Is it a requirement that this is consistent: "range xsd:float" and a value which is "5"^^int ? 14:19:41 (general sense of yes.) 14:19:44 alanr: thus the integer 5 should be the same as "5.0"^^xsd:float 14:20:05 I'd still very much prefer if users couldn't say "range xsd:float" 14:20:31 +1 rob 14:20:31 [considerable discussion] 14:20:54 alanr: xquery promotion is to float - this may not be the same as the owl proposal 14:20:54 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 I don't understand the notion "equal as floats" 14:22:05 boris: IEEE comparison of floats and doubles is done as if they were exact real numbers 14:22:16 sandro, http://www.w3.org/2007/OWL/wiki/TestCase:Datatype-Primitive-Disjointness-001 14:22:28 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 Comparisons are exact and never overflow nor underflow. 14:22:45 14:22:56 achille: run this through some code 14:23:35 achille: galax is a reference implementation 14:23:39 ACTION: Alan to investigate Boris' IEEE reference, re linking floating point to real numbers 14:23:39 Created ACTION-173 - Investigate Boris' IEEE reference, re linking floating point to real numbers [on Alan Ruttenberg - due 2008-08-04]. 14:23:49 alanr: things to check - owl:number+ - we seem to be OK 14:24:12 alanr: minimum conformance - 64 bit integer - decimal - something that looks OK 14:24:19 q+ 14:24:37 alanr: float and double are currently real ranges 14:24:46 zakim, unmute me 14:24:46 rob should no longer be muted 14:24:47 q? 14:24:50 alanr: internationalized strings 14:25:07 zakim, mute me 14:25:07 rob should now be muted 14:25:09 q- 14:25:18 rob: the issue is whether xsd:float is a value space 14:25:25 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 ...the distinction in the comparison predicates (etc.). I just want to make sure everyone understands the consequences of this choice. 14:25:45 alanr: boolean and hexdecimal 14:25:50 alanr: date/time 14:26:38 alanr: issues - Issue87, Issue71, Issue127, Issue132, floats 14:26:52 q? 14:27:14 m_schneider: why the change from owl:real to owl:number? 14:27:21 boris: people liked it 14:27:29 m_schneider: but what about complex numbers, then? 14:27:37 m_schnei: The term "owl:number" misled me into thinking I could use it as a base for Complex Numbers 14:27:55 MeetingIssue: Should it be called owl:number or owl:real or what? 14:28:03 alanr: MEETING ISSUE - owl:number vs owl:real 14:28:21 maybe owl:realNumber? 14:28:47 what's going on? 14:28:52 alanr: use of xsd:float - as datatype name, as separate from other numbers 14:28:59 Ian: Can we use xs:float is a class in restrictions, and if we use it what does it mean? 14:29:04 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 msmith: if we use it, then it should mean the same as in xsd - i.e., discrete 14:29:53 "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 alanr: thus not make xsd:float required 14:29:59 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 boris: the documents have to be careful then 14:30:20 q? 14:30:42 +1 to not allowing "range xsd:float", for example. 14:30:45 boris: That's fine. We're supporing xs:float types for constants, but not for ranges. 14:31:36 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 alanr: straw poll - is xsd:float an OWL datatype 14:31:39 +0 waiting to investigate how often it appears in practice 14:31:41 Alan: let's come back to that. 14:31:44 msmith: no 14:31:52 horribly confusing, and non-conformant with XSchema... 14:31:54 boris: but would anyone see a difference? 14:32:19 http://swoogle.umbc.edu/index.php?option=com_frontpage&service=search&queryType=search_swd_ontology&searchStart=1&searchString=float 14:32:24 msmith: choosing xsd:float is a choice - why did someone do it 14:32:35 ianh: is there an example 14:33:08 q? 14:33:16 m_schneider: perhaps xsd:float was used to allow more values (due to implementation limitations) 14:33:27 boris: value space of xsd:integer is all integers 14:33:46 boris: some implementations might not support arbitrarily large constants 14:34:10 Another example: http://www.biopax.org/release/biopax-level2.owl 14:34:12 boris: xsd says that minimal conformance requires support for integers that fit into 64 bits 14:34:18 But floatiness doesn't seem interesting 14:34:20 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 alan: XMLS and OWL may have different conformance clauses. 14:35:04 jonathan: in scientific computing float means "can be represented (exactly) as a float" 14:35:27 jrees: No one in scientific computing would say sqrt(2) is float. 14:35:44 ianh: we need to be careful to keep constants (and minimal conformance) and value spaces separate 14:35:45 q? 14:36:00 q+ 14:36:22 boris: sqrt(2) is not a float - we can approximate it, though 14:37:06 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 scribe assist - I talked about xsd:decimal, not xsd:float 14:37:24 zakim, unmute me 14:37:24 rob should no longer be muted 14:37:29 alanr: in the proposal sqrt(2) is in float 14:38:07 q+ 14:38:10 rob: "can't tell the difference now" is a suspect argument - extensions may expose the differences 14:38:13 (to reply to owl) 14:38:15 RRSAgent, pointer? 14:38:15 See http://www.w3.org/2008/07/28-owl-irc#T14-38-15 14:38:23 zakim, mute me 14:38:23 rob should now be muted 14:38:30 q- 14:39:02 ianh: everyone seems to be OK with xsd:float as a datatype, so what is the point of this discussion 14:39:51 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 zakim, unmute me 14:40:16 bparsia should no longer be muted 14:40:18 14:40:18 14:40:18 14:40:18 14:40:23 http://www.dayf.de/2004/owl/order.owl 14:40:25 jonathan: floats are reliably used in scientific computing 14:40:38 can we use the queue, in general? 14:40:48 It's hard to know where I am on the queue 14:40:53 yes, bijan---everybody uses floats in those things now because it's allowed. 14:41:13 \me guesses that Peter and Rob are close to the microphone and Alan is far away? 14:41:13 ianh: can we handle this under RDF repairs? 14:41:15 rob, I'm just gathering examples. That's pretty clearly a silly one 14:41:29 From the point of view of "OOO, IEEE float" 14:41:41 q? 14:41:43 ack bparsia 14:41:48 q? 14:42:45 bparsia: examples of xsd:float in Swoogle in Tboxes - there is a fair bit, but no used for floatiness 14:43:30 bparsia: we could have owl:IEEEfloat for those who need floatiness 14:43:32 But why include xsd:float as a value space which doesn't mean what its name implies? 14:44:00 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 boris: it is easier to say that float is on both sides 14:44:09