Warning:
This wiki has been archived and is now read-only.

Chatlog 2008-07-28

From OWL
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

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