14:05:14 <RRSAgent> RRSAgent has joined #owl
14:05:14 <RRSAgent> logging to http://www.w3.org/2009/02/23-owl-irc
14:05:34 <IanH> IanH has changed the topic to: http://www.w3.org/2007/OWL/wiki/F2F5_Agenda
14:06:11 <IanH> Zakim, this will be owlwg
14:06:11 <Zakim> ok, IanH; I see SW_OWL(F2F)8:00AM scheduled to start 66 minutes ago
14:06:44 <pfps> pfps has joined #owl
14:06:51 <msmith> msmith has joined #owl
14:07:07 <IanH> ScribeNick: pfps
14:07:24 <IanH> RRSAgent, make records public
14:07:54 <baojie> baojie has joined #OWL
14:09:30 <MarkusK_> Editing wiki tables made easy: http://simile.mit.edu/wiki/Wiki_Table_Editor
14:10:49 <sandro> sandro has joined #owl
14:11:18 <pfps> Topic: Admin
14:11:35 <IanH> zakim, who is here?
14:11:35 <Zakim> SW_OWL(F2F)8:00AM has not yet started, IanH
14:11:36 <Zakim> On IRC I see sandro, baojie, msmith, pfps, RRSAgent, Zakim, IanH, bmotik, MarkusK_, ivan, trackbot
14:11:46 <bmotik> ZAkim, this will be owl
14:11:46 <Zakim> ok, bmotik, I see SW_OWL(F2F)8:00AM already started
14:11:59 <pfps> SubTopic: Roll Call
14:12:00 <IanH> zakim, who is here?
14:12:00 <Zakim> On the phone I see MIT346
14:12:01 <Zakim> On IRC I see sandro, baojie, msmith, pfps, RRSAgent, Zakim, IanH, bmotik, MarkusK_, ivan, trackbot
14:12:21 <pfps> SubTopic: Agenda (and amendments)
14:12:47 <pfps> ian: is the agenda OK?
14:13:03 <pfps> ivan: wait while I project the agenda on the screen
14:13:12 <sandro> sandro has joined #owl
14:14:33 <Christine> Christine has joined #owl
14:14:38 <pfps> ian: sessions are carved up by topic
14:14:56 <pfps> ian: we put in a special session to fill the time until everyone arrives
14:15:48 <schneid> schneid has joined #owl
14:15:53 <pfps> ian: sessions - today - intro, presentation (intro, naming), datatypes, profiles
14:16:31 <pfps> ivan: we should do contentious things here
14:17:03 <pfps> ian: ok
14:17:19 <pfps> ian: extra comments - 62,63,64 will be slotted in as appropriate
14:17:38 <pfps> ivan: tq comments?
14:17:52 <pfps> ian: split into technical and non-technical
14:18:07 <pfps> ivan: but still needs to be considered as required
14:18:12 <sandro> RRSAgent, pointer?
14:18:12 <RRSAgent> See http://www.w3.org/2009/02/23-owl-irc#T14-18-12
14:18:23 <ewallace> ewallace has joined #owl
14:18:25 <pfps> ian: ok, we'll look at them as appropriate
14:19:01 <pfps> sandro: what if we get ahead?
14:19:22 <pfps> ian: then we can move forward (and start early as well)
14:19:35 <Zakim> +??P3
14:19:38 <Zakim> -MIT346
14:19:39 <Zakim> +MIT346
14:19:48 <pfps> Subtopic: Roadmap and Schedule Review
14:19:51 <MarkusK_> http://www.w3.org/2007/OWL/wiki/Timeline
14:20:21 <Christine> zakim, ??P3 is Christine
14:20:21 <Zakim> +Christine; got it
14:20:28 <pfps> Ian: we are running behind the schedule from charter
14:20:35 <pfps> ivan: as expected
14:20:45 <Zakim> +Evan_Wallace
14:21:26 <pfps> ian: we will need a charter extension
14:21:36 <pfps> sandro: we will need a new timeline
14:21:42 <pfps> ian: do it now?
14:22:02 <pfps> ivan: wait until we know more, like whether we need a new LC
14:22:17 <pfps> ian: we probably need a new LC
14:22:28 <pfps> sandro: maybe not
14:22:55 <pfps> boris: will we need a changes since LC section
14:23:17 <pfps> ian: we'll think about it
14:23:22 <pfps> ian: hi Alan
14:24:14 <pfps> sandro: a new LC is needed particularly if previously happy people might become unhappy
14:24:52 <pfps> sandro: let's do a quick schedule review
14:25:39 <pfps> sandro: an optimistic schedule would end up in September
14:25:52 <pfps> ivan: ask for December
14:26:24 <pfps> ian: timeline for September, ask for December
14:27:41 <pfps> alan: what problems?  implementation
14:27:50 <pfps> pfps: Oxford implementation?
14:27:53 <pfps> ian: complete
14:28:07 <pfps> ivan: how long should CR be 
14:28:22 <pfps> ian: we should have multiple implementations soon
14:28:50 <pfps> alan: let's have a poll to see if could be problems
14:29:38 <pfps> sandro: we can be done by December
14:29:56 <pfps> ian: the work will expand to fill the time
14:30:52 <pfps> schneid: if we address all possible comments we will be here till 20xx
14:30:55 <sandro> zakim, who is on the phone?
14:30:55 <Zakim> On the phone I see MIT346, Christine, Evan_Wallace
14:31:15 <pfps> ian: we need to set a reasonable time line to keep people on board
14:31:22 <Achille> Achille has joined #owl
14:31:31 <Zhe> Zhe has joined #owl
14:31:58 <Zakim> +[IBM]
14:32:02 <pfps> alan: still worry about cutting too soon
14:32:12 <Achille> Zakim, IBM is me
14:32:12 <Zakim> +Achille; got it
14:32:54 <pfps> sandro: who is willing to continue till December
14:33:05 <pfps> ian: I'm ok with december, but I want earlier
14:33:31 <pfps> ian: September is OK
14:33:39 <pfps> boris: I prefer earlier
14:33:52 <pfps> pfps: September is good, but December is OK
14:34:03 <pfps> general agreement in the room
14:34:12 <sandro> PROPOSED: Let's PLEASE be done in September, but we can hang in through December if really necessary.
14:34:27 <pfps> +1 (ALU)
14:34:32 <ivan> +1
14:34:34 <schneid> +1
14:34:35 <Zhe> +1 
14:34:36 <bmotik> +1
14:34:37 <Achille> +1 (IBM)
14:34:38 <sandro> PROPOSED: Let's PLEASE be done in September, but we can hang in through December if really necessary.    Let's ask for a charter extenstion through 31 December.
14:34:45 <sandro> Alan: +1
14:34:45 <ewallace> +1 (NIST)
14:34:48 <msmith> +1
14:34:51 <sandro> +1
14:35:12 <baojie> +1
14:35:21 <MarkusK_> +1
14:35:22 <pfps> zakim, who is on the phone?
14:35:22 <Zakim> On the phone I see MIT346, Christine, Evan_Wallace, Achille
14:35:54 <Christine> don't see a proposal on irc
14:36:04 <Christine> don't see a proposal on irc
14:36:07 <sandro> repeating:
14:36:09 <sandro> PROPOSED: Let's PLEASE be done in September, but we can hang in through December if really necessary.    Let's ask for a charter extenstion through 31 December.
14:36:46 <sandro> RESOLVED: Let's PLEASE be done in September, but we can hang in through December if really necessary.    Let's ask for a charter extension through 31 December.
14:36:53 <Christine> irc stopped at <pfps> ian: September is OK
14:37:27 <IanH> zakim, who is here?
14:37:27 <Zakim> On the phone I see MIT346, Christine, Evan_Wallace, Achille
14:37:29 <Zakim> On IRC I see Zhe, Achille, ewallace, schneid, Christine, sandro, baojie, msmith, pfps, RRSAgent, Zakim, IanH, bmotik, MarkusK_, ivan, trackbot
14:38:42 <pfps> Christine: +1
14:39:12 <pfps> pfps: scribes for other sessions
14:40:05 <pfps> schneid:  I'll do datatypes
14:40:15 <pfps> boris:  I'll do philosophy
14:40:20 <msmith> I will scribe today LC Comments: presentation
14:41:57 <pfps> zhe: I'll do test cases
14:42:28 <pfps> ian: all sessions have scribes - see updated agenda
14:42:52 <sandro> http://www.w3.org/People/Sandro/webcam
14:43:46 <pfps> Topic: Presentation
14:44:03 <pfps> ian and alan arrange for a trade - alan's Mac dongle for Ian's CV
14:45:25 <pfps> SubTopic: introduction/roadmap
14:45:45 <pfps> ian: we have a candidate introduction document
14:46:41 <pfps> see http://www.w3.org/2007/OWL/wiki/Introduction
14:47:43 <Zhe> I will scribe the last session tomorrow
14:47:44 <cgolbrei> cgolbrei has joined #owl
14:47:50 <pfps> Ian: this is an introduction for a single document containing the core normative stuff
14:47:52 <bmotik> I'll scribe tomorrow 11:15 - 11:45 
14:48:09 <baojie> Jie on Day 2 09:00 - 10:45 LC Comments: Technical 
14:48:43 <pfps> ian: i.e., syntax, semantics times 2, rdf mapping, profiles, conformance
14:49:26 <pfps> ian: presentation documents - primer, NFR, QRG
14:49:48 <pfps> Ian: other syntaxes- XML, Manchester
14:50:34 <pfps> Alan: this came from Ivan's suggestion - except core didn't include profiles
14:51:12 <pfps> Alan: profiles isn't quite as central, and has garnered debate
14:51:50 <schneid> Question, who is scribing "Remaining Issues" section (tomorrow, 14:00) ?
14:52:18 <pfps> Ivan: the core doc is related to A&AS
14:52:56 <pfps> msmith: wasn't OWL Lite defined in S&AS
14:53:16 <pfps> Ivan: yes, but profiles is bigger than just the DL/Lite distinction
14:53:43 <pfps> Boris: OWL 1 core doc had different editors 
14:54:12 <ewallace> Sandro memory is consistent with mine
14:54:36 <pfps> Sandro: OWL 1 had 6 documents - one recommendation
14:54:39 <ewallace> Two normative documents S & AS and Test
14:54:50 <pfps> Ivan: one of these documents had the core spec
14:55:03 <pfps> Ian: let's not get sidetracked by what was done
14:55:30 <pfps> Boris: I see the need for some glue document, I like the introduction just produced
14:55:45 <sandro> q+
14:56:25 <IanH> q?
14:56:26 <pfps> Boris: I like the document roadmap
14:56:36 <pfps> Ivan: do we keep together or split?
14:57:01 <sandro> q-
14:57:07 <alanr> alanr has joined #owl
14:57:55 <pfps> pfps: OWL 1 document set caused problems - ref was non-normative but is often treated as if it is
14:58:03 <sandro> Peter: I don't think we should do what OWL 1 did.   It caused too many problems.    People treated Reference as normative, when it wasn't meant to be.
14:58:17 <pfps> ian: what can we do
14:58:21 <sandro> Peter: The document should state explicitely at the beginning that they are non normative.
14:58:24 <alanr> q?
14:58:29 <pfps> pfps: documents should state that they are non-normative
14:58:50 <pfps> sandro: I like this, but we should number the parts
14:59:05 <pfps> sandro: use optional 
14:59:29 <pfps> ian: this doesn't capture the distinction - people used guide and ref as normative
14:59:49 <pfps> sandro: our titles are better - i.e., not "reference"
14:59:52 <IanH> q?
14:59:58 <pfps> boris: I don't care about one document
15:00:19 <pfps> boris: I care about the structure of the documents
15:00:26 <pfps> ivan: call them parts
15:00:48 <pfps> ian: we need to figure out how to do this
15:01:30 <pfps> alan: address normative vs non-normative in the introduction and signal in other places
15:02:29 <pfps> jie: RPI is interested in removing profiles from rec track to remove potential problems
15:02:33 <sandro> PRESENT: Ian, Boris, Smith, Zhe, Peter, Jie, Ivan, mschnei, markus, sandro, alan
15:03:03 <pfps> ian: let's do general principles first
15:03:15 <pfps> ian: the book is the core stuff other docs are separate
15:03:46 <pfps> alan: goal of the book is that there is a core part of OWL other docs are not core
15:03:59 <IanH> q?
15:04:19 <pfps> alan: core reorganization might also help with complaints about profiles
15:05:23 <pfps> ivan: my idea was three recommendations - core book, profiles, test cases
15:05:48 <pfps> ivan: perhaps put conformance (and test cases?) into book
15:05:55 <alanr> ian, boris, sandro, peter
15:06:13 <alanr> peter, sandro, boris, michael
15:07:13 <pfps> pfps: the core is structure (not syntax, just like RDF) plus semantics
15:07:43 <pfps> sandro: recommendation and normative is misleading
15:08:20 <pfps> sandro: there are core parts, other parts, presentation stuff
15:08:28 <pfps> sandro: conformance then is in the core
15:08:29 <alanr> Alan thinks optionality isn't clearly defined, in Sandro's discussion.
15:08:44 <alanr> michael, ivan, zhe
15:09:43 <pfps> boris: I prefer introduction plus document set - not book - i.e., status quo (more or less)
15:09:52 <cgolbrei> +q
15:10:44 <bmotik> bmotik has joined #owl
15:10:46 <pfps> schneid: conformance has lots of references to profiles so it would have to be split up in a core
15:10:52 <alanr> mike, ivan, zhe, christine
15:11:04 <pfps> msmith: I agree with boris - introduction plus document set
15:11:21 <IanH> q?
15:11:38 <alanr> q+
15:11:45 <pfps> ivan: I'm OK with separate document set
15:12:13 <pfps> ivan: we might have to split conformance and test cases
15:12:22 <pfps> boris: test cases are also important
15:12:52 <pfps> zhe: oracle wants profiles on rec track
15:13:04 <sandro> (Dropped webcam size, to reduce lag.)
15:13:08 <alanr> ack christine
15:13:09 <Achille> q+
15:13:16 <IanH> q?
15:13:16 <sandro> (refresh might be necessary)
15:13:18 <alanr> ack cgolbrei
15:13:29 <pfps> christine: I don't like the book idea
15:13:43 <pfps> christine: we do need to determine core documents 
15:13:55 <pfps> christine: we need to worry about where profiles goes
15:14:08 <pfps> christine: we need to worry about normative / non-normative
15:14:30 <IanH> q?
15:14:39 <pfps> christine: I don't like stress on normative / non-normative in introduction
15:14:53 <pfps> christine: why are we talking about rec-track status
15:15:23 <pfps> ivan: we need to rediscuss rec-track status because of LC comments
15:15:56 <pfps> ivan: we need to be clear on how things fit together to help people determine how OWL fits into SW
15:16:17 <cgolbrei> +q
15:16:18 <pfps> ian: this session addresses LC comments on this point
15:16:59 <pfps> alan: i like the book idea - we have too many documents - some people don't read them
15:17:12 <pfps> alan: fewer documents are easier to read
15:17:22 <IanH> q?
15:17:36 <pfps> alan: I would like three documents (or four)
15:17:37 <IanH> ack alanr
15:17:45 <alanr> q+ sandro
15:18:10 <pfps> Achille: the introduction will help a lot on how to read 
15:18:21 <pfps> Achille: profiles is important to IBM
15:18:52 <pfps> Achille: we want SW to scale - profiles shows how
15:19:10 <IanH> q?
15:19:10 <pfps> Achille: profiles should thus be rec track
15:19:16 <alanr> ack Achille
15:19:17 <ivan> ack Achille 
15:19:45 <pfps> Christine: we have to clarify and respond to issues
15:19:57 <pfps> Christine: but I don't see a connection to rec-track status
15:20:10 <pfps> Christine: profiles should be in core
15:20:15 <alanr> q?
15:20:19 <alanr> ack cgolbrei
15:20:21 <IanH> q?
15:20:22 <alanr> ack sandro
15:20:31 <IanH> q+schneid
15:20:39 <pfps> Sandro: I'm opposed to the core idea
15:20:48 <alanr> q+ boris
15:21:12 <pfps> Sandro: grouping into three would be an improvement but the core doc will be very big and bring in lots of stuff
15:21:24 <IanH> q?
15:21:26 <pfps> ian: core would be about 150 pages
15:21:28 <IanH> q?
15:21:43 <Zhe> we can use smaller font
15:21:49 <alanr> q+ to respond to sandro ("too hard in book")
15:22:13 <alanr> q+ peter
15:22:15 <pfps> sandro: our best bet is to make a good roadmap so that people only need to read the stuff they need
15:22:20 <ivan> ack schneid 
15:22:49 <pfps> schneid: I don't see how collecting into one book helps - the roadmap is sufficient
15:23:05 <IanH> q?
15:23:06 <pfps> ian: what does "the book" mean 
15:23:09 <cgolbrei> proposed reading guide at http://www.w3.org/2007/OWL/wiki/LC_Responses/IH2#Set_of_Documents
15:23:18 <IanH> q?
15:23:37 <alanr> q+ mike
15:23:43 <alanr> q+ ivan
15:24:06 <ivan> q+
15:24:39 <pfps> the scribe is confused as to what recommendation means
15:24:40 <ivan> ivan-
15:24:57 <sandro> ivan: 1 rec == 1 entry on TR page, one URI for the whole thing.
15:25:07 <pfps> Ivan: recommendation = TR
15:25:42 <sandro> ivan: in OWL 1, each CHAPTER has it's own URI, because there's a table of contents.    that's the model I have in mind.
15:25:43 <pfps> ivan: OWL S&AS = 1 recommendation = one TR, but chapters each have separate URIs
15:26:10 <IanH> q?
15:26:15 <sandro> ivan: I want one URI for OWL 2, which people can use as the reference for the whole thing.
15:26:31 <ewallace> I always disliked the compound structure of the OWL1 S & AS
15:26:46 <IanH> ack boris
15:26:59 <pfps> boris: we need one document as an entry point
15:27:26 <alanr> alan: liked smaller numbers of TRs - feel it is more appealing to new people coming in
15:27:30 <IanH> q?
15:27:35 <pfps> boris: I would much be able to cite individual parts as separate documents
15:27:37 <pfps> q-
15:27:45 <pfps> ack peter
15:27:48 <ivan> q-
15:28:12 <pfps> ian: let's start to move forward
15:28:18 <pfps> msmith: I agree with Boris
15:28:36 <sandro> mike: two axes:   normativity and core-vs-optional
15:28:49 <pfps> msmith: keep straight: normative vs optional
15:28:53 <IanH> q?
15:28:54 <alanr> q- alan
15:28:58 <pfps> msmith: there can be an optional normative document
15:28:58 <sandro> mike: "normative description of how to support optional component"
15:28:58 <alanr> ack mike
15:29:51 <pfps> ian: what is the book - the book could be an intro TR that points to the other documents?
15:30:05 <pfps> ian: would the other documents be separate TRs
15:30:21 <MarkusK_> q+
15:30:22 <pfps> sandro: only one TR - the intro
15:30:38 <Rinke> Rinke has joined #owl
15:30:40 <pfps> ivan: yes, the other documents are real things
15:30:42 <sandro> sandro: Ah!   I get it now.      This (introduction) might be the ONLY thing on the TR page.
15:31:09 <pfps> ian: it would be good to have the intro document first in searching
15:31:39 <pfps> alan: three documents?
15:32:10 <pfps> ivan: originally, yes - book was the core - others were separate TRs
15:32:41 <pfps> alan: one TR puts everything in one basket
15:33:00 <pfps> ian: if we make this be one recommendation then a vote against profiles is a vote against the whole
15:33:27 <pfps> sandro: we could revise (take out profiles) and redo
15:33:53 <pfps> marcus: I like one TR - what about the other documents
15:34:11 <sandro> sandro: it's like papers collected into a volume -- you can cite the whole thing, or the parts.
15:34:23 <cgolbrei> what about UF doc ? in that basket ?
15:34:27 <pfps> ivan: they still would be citable
15:34:31 <alanr> yes
15:34:35 <alanr> to christine
15:34:54 <alanr> q?
15:34:57 <IanH> q?
15:34:59 <pfps> msmith: what about deciding what goes in a small book and what doesn't
15:35:00 <alanr> ack Markus_K
15:35:12 <alanr> ack MarkusK_
15:35:31 <pfps> msmith: what about the OWL page at W3C? doesn't this serve the same purpose
15:35:39 <msmith> this page: http://www.w3.org/2004/OWL/
15:35:48 <pfps> markus: an entry point isn't really normative
15:36:22 <pfps> ian: where is the fight about profiles translate into the 1 TR setting
15:36:42 <pfps> ivan: if it is part of the book then it is rec-track
15:36:50 <alanr> q+ zhe
15:37:09 <alanr> q+ alan (to mention that some of these are not recs and so this would be a change)
15:37:12 <pfps> sandro: one TR is somewhat orthogonal to the rest of the discussion
15:37:18 <schneid> q+
15:37:19 <MarkusK_> MarkusK_ has joined #owl
15:37:24 <pfps> sandro: small editorial change (but large process change)
15:37:27 <alanr> q+ alanr to mention that some of these are not recs and so this would be a change
15:37:33 <Rinke> Rinke has joined #owl
15:37:41 <pfps> sandro: everything becomes part of the REC (or off in some odd corner)
15:38:08 <alanr> q+ pfps
15:38:09 <IanH> q?
15:38:14 <ivan> ack Zhe 
15:38:25 <pfps> sandro: if the roadmap is good enough then everything should be OK
15:38:37 <IanH> q?
15:38:39 <pfps> zhe: what does it take to kick profiles out
15:39:20 <alanr> q+ jie
15:39:26 <IanH> q?
15:39:27 <pfps> ivan: one vote against that isn't overcome 
15:39:52 <pfps> sandro: but votes against are overcome fairly often
15:40:18 <pfps> ivan: we don't want votes against anyway, as it complicates the process
15:40:19 <IanH> q?
15:40:30 <IanH> ack schneid
15:40:37 <sandro> Ian: Yes, Sandro, then the "Profiles" status debate turns into a debate over how Profiles is presented in the Roadmap
15:41:05 <pfps> schneid: there were several LC comments asking for an introduction, but they didn't ask for a single TR
15:41:25 <pfps> ian: there was considerable confusion as to what OWL 2 was
15:41:31 <pfps> ian: we need to address that
15:41:33 <sandro> Ian: it's not just the people who said the spec was confused; it's that some people were clearly confused by the spec.
15:41:35 <IanH> q?
15:41:55 <msmith> +1 to schneid
15:41:58 <pfps> schneid: can we then ask the WG if just an introduction is OK
15:42:05 <pfps> q-
15:42:13 <pfps> q+
15:42:28 <pfps> alan: I'm concerned that this makes everything a REC
15:42:39 <schneid> schneid: proposes to straw poll on question whether WG believes that roadmap is sufficient to satisfy the existing LC comments
15:42:50 <pfps> alan: e.g., Manchester syntax
15:42:58 <pfps> ivan: who said that
15:43:07 <pfps> sandro: it falls out of the proposal
15:43:18 <sandro> sandro: Right -- if there's ONE TR then mter, etc, become Rec Track,
15:43:34 <pfps> alan: if we have a core document then we can still point to the other parts
15:43:46 <IanH> q?
15:43:46 <sandro> w+
15:43:47 <pfps> alan: this would help with the comments
15:43:48 <sandro> q+
15:43:52 <alanr> ack alanr
15:43:53 <Zakim> alanr, you wanted to mention that some of these are not recs and so this would be a change
15:43:55 <IanH> ack alanr
15:43:58 <ivan> ack alanr 
15:44:05 <ivan> ack jie
15:45:05 <pfps> jie: what would be the titles of the documents
15:45:15 <IanH> q?
15:45:21 <pfps> ivan: the core would be "OWL 2 Language"; the others stay the same
15:45:33 <IanH> ack pfps
15:45:33 <ivan> ack pfps 
15:45:48 <cgolbrei> and NF&R as well etc.
15:45:50 <baojie> q+
15:45:53 <pfps> pfps: if we have a single TR then Manchester should be part of it
15:46:16 <pfps> sandro: one TR for the rec-track parts
15:46:19 <IanH> q?
15:46:29 <pfps> sandro: intro points to everything
15:46:45 <pfps> msmith: what are the advantages to a single TR
15:47:20 <schneid> I think a single TR would be an OWL Too Full ;-)
15:47:28 <pfps> ivan: single TR is not essential - essential is good roadmap
15:47:41 <pfps> ivan: only the core stuff should be REC, others not
15:47:44 <pfps> pfps: +1
15:48:22 <pfps> ivan: there is some dissention on what should be REC
15:48:32 <pfps> Topic: Coffee Break
15:48:45 <cgolbrei> remind objections not having others as rec
15:49:47 <Zakim> -Evan_Wallace
15:51:45 <Zakim> -Christine
16:03:06 <christine> christine has joined #owl
16:07:00 <msmith> scribenick: msmith
16:07:12 <alanr> alanr has joined #owl
16:07:17 <msmith> topic: LC Comments: Presentation
16:07:36 <IanH> Remote participants: we are starting again
16:08:07 <pfps> subtopic: introduction/roadmap
16:08:16 <msmith> alanr: seems that people like the idea of a roadmap. correct?
16:08:43 <msmith> ivan: we did not look at all of the introduction document
16:08:44 <IanH> q?
16:08:52 <IanH> ack sandro
16:08:57 <IanH> ack baojie
16:09:00 <IanH> q?
16:09:11 <msmith> alanr: can we agree that it is a good entrypoint
16:09:21 <msmith> ... I'm hearing that it does well.
16:10:03 <msmith> alanr: I suggest a strawpoll as in ... "leave the same number of TRs as now"
16:10:19 <msmith> schneid: is this in every document
16:10:24 <msmith> alanr: yes.
16:10:33 <IanH> q?
16:10:43 <msmith> ivan: I had not considered it in every document, until now
16:11:02 <msmith> pfps: I intended it to be in the preamble of every document
16:11:18 <IanH> q?
16:11:18 <msmith> alanr: ok, we can agree we like the text somewhere
16:11:46 <msmith> pfps: we could have another doc called introduction
16:12:01 <msmith> alanr: so, consolidating vs. many TRs?
16:12:21 <Zakim> +??P12
16:12:33 <pfps> option 1: OWL 2 S&AS plus other documents
16:12:41 <pfps> option 2: one TR to rule them all
16:12:44 <msmith> alanr: there were different options, one TR, several, with different groupings, many (as now)
16:12:46 <christine> zakim, ??P12 is christine
16:12:46 <Zakim> +christine; got it
16:13:10 <pfps> option 3: eleven+ TRs (plus maybe introduction)
16:13:40 <msmith> pfps: option 2 is a single TR with multiple sections
16:14:04 <msmith> alanr: some consolidation vs. separate documents
16:14:36 <msmith> pfps: the alternatives are not fined enough for me to express a preference
16:15:27 <Rinke> Rinke has joined #owl
16:15:55 <alanr> 1) Some sort of consolidation in the number of technical reports is appealing
16:16:06 <alanr> 2) I want to leave all the documents as separate TRs as they are now
16:16:11 <alanr> STRAW POLL
16:16:19 <bmotik> 0
16:16:20 <msmith> msmith: 2
16:16:21 <schneid> 2
16:16:21 <pfps> 2
16:16:22 <ivan> 1
16:16:25 <alanr> 1
16:16:26 <christine> one ambiguous please clarify
16:16:29 <baojie> 0
16:16:29 <sandro> 1
16:16:31 <Zhe> 1
16:16:32 <MarkusK_> 0
16:16:37 <Rinke> 0
16:16:50 <IanH> 2
16:16:50 <Zakim> +Evan_Wallace
16:17:21 <Achille> 0
16:18:23 <msmith> alanr: we will attempt to provide finer grained alternatives
16:18:58 <ewallace> core + <what>?
16:20:07 <christine> numbered list at http://www.w3.org/2007/OWL/wiki/LC_Responses/IH2#Set_of_Documents
16:20:59 <christine> could you write the poll using the numbers please ?
16:25:20 <msmith> alanr: criteria, political considerations, user manageability, and sensibility 
16:25:21 <IanH> 1) Leave all documents separate as they are, but add introduction
16:25:21 <IanH> 2) Single TR with at least syntax, semantics (2), mapping, conformance, profiles(?), test(?); rest of the documents stay as is
16:25:21 <IanH> 3) One TR for everything
16:25:21 <IanH> 4) Single TR with syntax and semantics (2)
16:25:22 <IanH> 5) Three TRs as per roadmap (core, user facing, optional)
16:26:02 <msmith> ivan: (with others) can we express preferences?
16:26:29 <alanr> STRAW POLL
16:26:37 <alanr> Allocate 3 points to vote with
16:27:12 <alanr> e.g. 2 points for proposal 1, 1 point for proposal 2 => 1,1,2
16:27:13 <christine> does 3 means one TR each or one single TR with all within?
16:27:26 <bmotik> 1,1, 3
16:27:28 <baojie> 1, 1, 5 
16:27:30 <msmith> msmith: 1,1,1
16:27:33 <Achille> 1, 1, 1
16:27:35 <pfps> 1,1,3
16:27:35 <schneid> 1) 1) 1)
16:27:36 <Zhe> 1,1,1
16:27:51 <alanr> 2,2,2
16:27:53 <MarkusK_> 1,1,1
16:27:59 <ewallace> 1,1,1
16:28:18 <ivan> 1,2
16:28:25 <IanH> 1,2,5
16:28:32 <sandro> 1,3,3
16:29:07 <christine> 1,1,1
16:29:27 <alanr> 1 wins
16:29:33 <alanr> straw poll
16:30:36 <msmith> alanr: so, moving forward with this result, how do we organize the introduction and roadmap text?
16:31:48 <alanr> q+
16:32:26 <msmith> ivan: I would like a person to come to this document and see how things fit together
16:32:50 <msmith> alanr: suggestion to include a section on how to read normativity vs non-normative
16:33:14 <msmith> msmith: non-normative == informative in many contexts, I think of it that way
16:33:42 <sandro> http://www.w3.org/2007/OWL/wiki/Roadmap
16:33:42 <msmith> alanr: the roadmap should exist in each of the documents
16:34:35 <msmith> sandro: this is an alternative presentation that is more visually obvious
16:35:38 <sandro> sandro: Part numbers are very important for some of us, eg me.
16:35:42 <msmith> alanr: this is orthogonal to rec track status
16:36:33 <msmith> alanr: we agree on an intro tr with the roadmap and other content.  we agree to have some form of roadmap in each document.
16:36:50 <msmith> ianh: i'd like pointer to intro in each document
16:37:17 <msmith> alanr: can we agree to take to list for the rest?
16:38:35 <msmith> msmith: required/optional is dependent on context.  e.g., to a ql reasoner implementator, profiles is not optional
16:39:01 <msmith> pfps: I suggest core and *nothing*
16:39:41 <msmith> there appears to be general agreement
16:40:20 <msmith> alanr: what about conformance?  I think it is core
16:40:41 <msmith> ivan: we should change the name of C&T
16:41:40 <msmith> ianh: can we call it just "Conformance"?
16:41:46 <schneid> schneid: the test cases are actually about conformance, so "conformance" is fine by me
16:41:48 <msmith> sandro: reload, changes made
16:42:43 <pfps> pfps has joined #owl
16:43:16 <msmith> ivan: we need to decide status of introduction document
16:43:47 <msmith> pfps: I believe we need to discuss status of other documents as well
16:43:58 <msmith> alanr: we will take that later
16:44:42 <alanr> Resolved: 1) We will add an introduction as TR. 2) We will repeat set of documents in each of the other documents 3) Documents are specified according to categories in http://www.w3.org/2007/OWL/wiki/Roadmap
16:45:23 <pfps> s/set of documents/document roadmap/
16:46:13 <alanr> + We will respond to LC comments (at least) 10, 42, 49, 56(partial) 54, 29, 34a, 27, 26a, 37 explaining this.
16:47:36 <alanr> + We will respond to LC comments (at least) 10, 42, 49, 56(partial), 29 (partial) , 34a , 27 explaining this.
16:47:39 <msmith> there is discussion about which LC comments this addresses
16:48:53 <alanr> PROPOSED: 1) We will add an introduction as TR. 2) We will repeat set of documents(as listed in Roadmap) in each of the other documents 3) Documents are specified according to categories in http://www.w3.org/2007/OWL/wiki/Roadmap. We will respond to LC comments (at least) 10, 42, 49, 56(partial), 29 (partial) , 34a , 27 explaining this.
16:49:25 <christine> +q
16:49:30 <alanr> ack alanr
16:49:32 <alanr> ack christine
16:49:41 <alanr> go ahead christine
16:50:09 <msmith> msmith: I want it to be clear that the introduction is in-progress and will be treated as such in any LC comments
16:50:22 <msmith> christine: I would like to add some content to introduction
16:50:30 <schneid> q+
16:50:47 <alanr> ack schneid
16:51:01 <msmith> ... so we're voting without the text being fixed
16:51:05 <msmith> alanr: yes
16:51:14 <pfps> +1 ALU
16:51:15 <sandro> +1
16:51:17 <msmith> schneid: rec status of introduction is unresolved
16:51:17 <alanr> +1 SC
16:51:20 <bmotik> +1
16:51:21 <Zhe> +1
16:51:22 <schneid> +1
16:51:22 <MarkusK_> +1 FZI
16:51:24 <Achille> +1 
16:51:30 <msmith> +1 
16:51:32 <ivan> 1
16:51:43 <ewallace> +1 NIST
16:51:45 <baojie> +1
16:52:20 <christine> 0
16:52:25 <alanr> RESOLVED:1) We will add an introduction as TR. 2) We will repeat set of documents(as listed in Roadmap) in each of the other documents 3) Documents are specified according to categories in http://www.w3.org/2007/OWL/wiki/Roadmap. We will respond to LC comments (at least) 10, 42, 49, 56(partial), 29 (partial) , 34a , 27 explaining this.
16:52:52 <msmith> subtopic: Naming
16:53:18 <sandro> http://www.w3.org/2007/OWL/meeting/2008-12-10#resolution_1
16:54:15 <msmith> alanr: the only one pending is the new Introduction
16:54:33 <sandro> http://www.w3.org/2007/OWL/meeting/2009-01-14#resolution_2    (manchester)
16:54:54 <alanr> q?
16:55:01 <msmith> schneid: I am concerned that there will be too much process for TR
16:56:06 <msmith> alanr: can we have a pointer to non-rec track document in a rec track doc?
16:56:10 <msmith> sandro: yes, that is fine
16:56:12 <pfps> +1 to msmith
16:56:33 <msmith> msmith: it should be rec due to definitions it will contain and as indicator of amount of review
16:57:07 <msmith> sandro: it being rec track will help from a citation standpoint
16:57:29 <sandro> "RESOLVED: Quick Reference Guide, New Features and Rationale, Primer will all be Recommendation Track. Not making any decision on Manchester Syntax or Data Range Extension at this point. ←"
16:58:07 <msmith> schneid: I change my opinion based on compelling arguments
16:58:10 <sandro> sandro: Yes, the whole WG is behind everything except Manchester Syntax.
16:58:12 <alanr> RESOLVED: The "introduction document" will be a recommendation.
16:58:16 <alanr> nope!
16:58:23 <alanr> PROPOSED: The "introduction document" will be a recommendation
16:58:25 <pfps> +1 ALU
16:58:28 <sandro> +1
16:58:31 <MarkusK_> +1 FZI
16:58:31 <ivan> 0
16:58:33 <bmotik> +1
16:58:33 <msmith> +1
16:58:34 <alanr> +1
16:58:35 <schneid> +1
16:58:39 <baojie> +1
16:58:41 <Zhe> +1
16:58:41 <ewallace> +1
16:58:43 <Achille> +1 (IBM)
16:59:18 <alanr> RESOLVED: The "introduction document" will be a recommendation
16:59:55 <pfps> subtopic: naming
17:00:17 <msmith> scribe note, previous content and votes are not in subtopic: naming
17:00:39 <pfps> http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0006.html
17:00:45 <cgolbrei> cgolbrei has joined #owl
17:00:52 <msmith> alanr: please review this link now
17:02:49 <msmith> msmith: this, if adopted, will require changes in the test section of the conformance document
17:03:23 <sandro> Ian: The intent here is to try to talk about "OWL 2" wherever possible, and only drop into "OWL 2 DL", etc, when absolutely necessary.
17:03:26 <msmith> ianh: yes, there are many areas not listed in the email that need change
17:03:28 <alanr> q?
17:05:18 <msmith> alanr: I anticipate problems determining where we are talking about OWL 2 Full and where we are not.  In particular, because any RDF graph is an OWL 2 Full document
17:06:22 <msmith> pfps: the structural spec could represent every rdf graph by making them property assertions
17:06:57 <msmith> ivan: if I look at the functional syntax does it define OWL 2 DL or OWL?
17:07:38 <msmith> bmotik is preparing to whiteboard
17:08:18 <sandro> webcam restarted for watching Boris.     http://www.w3.org/People/Sandro/webcam
17:08:33 <msmith> bmotik: we may be able to find a way to represent any graph in the structural specification
17:09:42 <msmith> ivan: if there is some way to characterize the RDF graphs that cannot be put into the structure, can we provide that characterization
17:10:55 <msmith> alanr: if we go this route, we will need to verify that we cover a usefully complete amount of graphs
17:11:16 <msmith> bmotik: at some point this is not possible
17:12:42 <msmith> schneid: if we drop global restrictions from syntax and go down to property assertions, then we could go to URI URI URI and could build RDF graphs
17:13:52 <msmith> alanr: would we have a mapping problem here
17:14:03 <msmith> pfps: no.
17:14:56 <msmith> bmotik: we could modify the structural spec to have only these 2 restrictions, (1) well formed literals (2) all datatypes are in the datatype map of the tool
17:16:00 <msmith> then, the forward RDF mapping would produce RDF graphs, to which RDF semantics could be applied
17:16:32 <msmith> schneid: how far to we get with just the forward mapping?
17:17:13 <alanr> q?
17:17:18 <msmith> ivan: can one characterize the rdf graphs for which the rdf -> structural mapping fails?
17:18:28 <msmith> ian: the reason we have the doc is that it is too difficult to produce a simple characterization
17:19:19 <msmith> alanr: there are more than just sensible restrictions in the structural syntax, some a restrictions for reasoners.  e.g., property chains must be object property only
17:19:36 <alanr> q?
17:19:39 <alanr> q+ ivan
17:19:41 <alanr> q+ pfps
17:19:46 <alanr> q+ schneid
17:19:58 <msmith> schneid: it is very difficult to characterize.  e.g., see the lc comment on naming data ranges
17:20:06 <alanr> q+ ian
17:20:10 <alanr> ack schneid
17:20:23 <msmith> ivan: we are talking about structural syntax, not dl.
17:20:27 <alanr> q+ mike
17:20:46 <alanr> q+ alanr
17:20:59 <msmith> ... whether or not the structural syntax can provide a useful amount of owl full.
17:21:05 <alanr> ack ivan
17:21:13 <Zhe> Zhe has joined #owl
17:21:21 <alanr> ack pfps
17:21:39 <msmith> pfps: I think Boris' approach (so far) can reasonably cover most RDF graphs.
17:22:15 <msmith> ... this works without a complete backwards mapping.
17:22:36 <alanr> ack ian
17:22:55 <msmith> alanr: the proposal is that the forward mapping works for much more, the reverse mapping works just for graphs satisfying DL constraints
17:23:12 <Zakim> -Achille
17:23:28 <msmith> ianh: I believe this started as a presentation proposal, not a technical proposal
17:23:53 <msmith> q-
17:23:57 <msmith> q- mike
17:24:05 <sandro> Ian: The idea here was to say that The Structural Spec applies to OWL Full in so far as the OWL Full makes sense in the structural spec
17:24:41 <msmith> ivan: if I take ontology that is almost DL, but isn't because I've used reserved keywords, will it work?
17:24:54 <alanr> ack pfps
17:24:57 <sandro> ian: We're trying to say the Structure Spec, as is, is relevant to both the DL and Full views.
17:25:05 <msmith> ianh: it may, but do you need a complete specification for this case?
17:25:48 <msmith> alanr: ian's description differs from my understanding.  I'd like to say that we only say OWL 2 when it applies to OWL DL and OWL Full.
17:26:00 <msmith> ianh: that's another thing
17:26:10 <sandro> Alan: The alternative is to say that we never say OWL 2 unless what we're saying is absolutely and perfectly true for OWL 2 Full (and OWL 2 DL).
17:26:19 <alanr> q?
17:26:22 <alanr> ack alanr
17:26:53 <msmith> bmotik: there are multiple ontologies that might produce the same RDF graph.
17:27:44 <msmith> ... if you impose the "dl" restrictions: role separation, declarations, class/datatype separation, (these are most important)
17:27:55 <msmith> ... (these do not include the global restrictions)
17:28:09 <msmith> ... restricted vocabulary can go in above group (important)
17:28:36 <msmith> ... then you can go through RDF mapping in both directions
17:29:14 <alanr> q+ ivan
17:29:48 <msmith> ... (aside) direct semantics can be applied without restrictions -- i.e., directly to the structural specification
17:30:20 <msmith> msmith: does this mean the current mapping?
17:30:35 <msmith> bmotik: yes. which is why the important restrictions are in place
17:31:30 <alanr> q+
17:31:34 <alanr> ack ivan
17:32:00 <msmith> ivan: the restrictions in the syntax doc can be categorized into 2 layers.  1 that ensures bi-directional mapping (put is less than constraints of DL), 2 that contains additional constraints
17:32:17 <msmith> ivan: which level is vocab restriction on?
17:33:44 <Zakim> +[IBM]
17:33:55 <Achille> Zakim. IBM is me
17:34:05 <msmith> alanr: this worries me.  it is confusing.  it seems simpler to just audit the current documents use of OWL
17:34:39 <msmith> bmotik: we can't do that because there is OWL structural spec which isn't necessarily DL or Full
17:34:54 <sandro> Alan: I don't think unifying DL and Full like this proposes will help anyone.
17:36:01 <msmith> pfps: trouble with audit is the choice of what is OWL 2.  I.e., how does one address statements just about the OWL 2 structure?
17:36:42 <msmith> ... a constrained reading means that any reference in OWL 2 Syntax to OWL 2 must be changed to OWL 2 DL
17:37:10 <msmith> my concern was about some that are overly global
17:38:45 <msmith> alanr: this can be addressed in a reasonable way on a case by case basis
17:38:59 <msmith> bmotik: the structures need to be OWL 2 in general, or remain DL specific
17:39:17 <schneid> q+
17:39:55 <msmith> ianh provides an example of the problem from the syntax document
17:40:39 <sandro> alan: Option 1 -- make structure spec bigger, to include OWL FUll to some degree.  This is risky
17:40:55 <msmith> alanr: two issues exist. one approach makes the structural syntax much larger than originally intended, which adds risk. second approach is to take a case by case basis
17:41:05 <msmith> bmotik: I don't believe second approach is possible
17:41:15 <sandro> alan: Option 2 -- just audit and edit the spec to change "OWL 2" to "OWL 2 DL" a lot.
17:41:41 <msmith> pfps: from birth of OWL, defining characteristic was ability to specify useful semantics.
17:42:00 <msmith> ... OWL 2 clarifies that more explicitly
17:42:42 <msmith> alanr: I recognize there is a large community for which DL constraints are not needed.
17:43:06 <msmith> ... I don't want to argue with them about the sensibility of their cases
17:43:29 <msmith> pfps: (with bmotik) we agree then, the structure is what's important
17:43:56 <msmith> sandro: I'm concerned that this is a big change.  can you address that?
17:44:20 <msmith> pfps: alternative (close audit of terminology use) will not really address people's concern
17:44:39 <sandro> peter: "The structures defined here are what counts for OWL.   That's what matters."
17:44:41 <msmith> ... to really address we need to say that what really matters in OWL is the structural syntax
17:45:54 <msmith> ... and OWL 2 Full can be defined using structural syntax with some slight constraints (well formed literals + datatypes in map + facets belong to dt)
17:46:15 <msmith> ianh: I don't think the proposed changes by bmotik are that complicated
17:46:39 <msmith> ... in principle, the restrictions now listed together in syntax 3 could be grouped
17:47:18 <msmith> ... the first level would be needed to produce reasonable RDF graphs
17:47:35 <schneid> q-
17:47:40 <msmith> ... the second level would be needed to map from RDF graphs
17:47:53 <msmith> ... the last level is needed for decidability
17:48:36 <schneid> q+
17:48:56 <msmith> ... the proposal also requires and audit of restrictions as they appear in document, to clarify what "level" of restriction is present
17:49:33 <msmith> pfps: so, the proposal is what alanr wants, with additional characterization of what the restriction types are 
17:49:46 <IanH> q?
17:49:52 <IanH> ack alna
17:49:56 <IanH> ack an
17:50:00 <IanH> ack alanr
17:50:38 <alanr> q?
17:50:40 <sandro> Peter: say "These are the Semantically Interesting Constructs of OWL 2." and then Syntax applies to everyone
17:50:41 <alanr> ack schneid
17:50:42 <msmith> ... I'm willing to do this to placate concerns expressed in some LC comments about the OWL Full disposition in OWL 2
17:50:48 <sandro> Alan: That seems like dangerous wording.
17:50:51 <IanH> ack schneid
17:50:54 <IanH> q?
17:53:01 <pfps> zakim, who is on the phone?
17:53:01 <Zakim> On the phone I see MIT346, christine, Evan_Wallace, [IBM]
17:53:19 <msmith> schneid: if someone from RDF field asks me what a cardinality restriction is, then I can't answer him because the RDF semantics doesn't have this concept structurally.  so in this case, I would tell someone to look at the RDF mapping to see how it is represented in the Structural Syntax.
17:54:05 <msmith> alanr: the problem is if the reverse mapping is ambiguous
17:54:16 <alanr> q?
17:54:19 <schneid> schneid: and I would tell such a guy that this will "pretty well, but not quite perfectly" tell you the story
17:54:24 <msmith> ... I'm not sure this approach works generally, but I'm willing to see
17:55:38 <msmith> ianh: the original proposal was presentational, and addressed mschneid's question.  the problem is that we get to the point where we argue about the corner cases where dl and rdf semantics are different
17:56:20 <msmith> alanr: I'm concerned that there is a different level of specificity provided to dl and rdf communities
17:56:22 <schneid> schneid: problem with RDF Semantics / OWL Full is: it does not really talk about structure, but says roughly: "If this set of assertions is semantically true, then that other thing is semanticaly true, too". This will hardly be understood by any RDF guy. 
17:57:05 <msmith> pfps: this is not the case, because we're not talking about the nuance in semantics, we're talking about user facing level
17:57:30 <alanr> q?
17:57:36 <christine> christine has joined #owl
17:58:09 <msmith> ianh: it may be that it makes sense to partition restrictions like this, but I don't think we need to worry about the exact specification of where this works and does not
17:58:50 <msmith> pfps: the worry is about making an explicit *claim* about the relationship.
18:02:00 <msmith> ivan: an approach, in the syntax doc, we do what ian suggested -- clearly state which restrictions are needed for DL. second, in the rdf mapping document we introduce the constraints for mapping to/from RDF graphs.  third, all examples in syntax doc should be available in RDF syntax.
18:02:37 <msmith> ianh: pt 3 in email includes an audit of references to OWL 2, etc.
18:02:52 <msmith> alanr: we just needed to clarify what audit was needed
18:03:09 <Zakim> -[IBM]
18:03:12 <msmith> bmotik: we should discuss ivan's third bit later.
18:04:16 <msmith> bmotik: another issue is status of functional style syntax, since it does not correspond 1:1 with structural syntax
18:04:43 <msmith> msmith: as pointed out in LC comment from Matthew Horridge
18:05:00 <bijan> bijan has joined #owl
18:05:33 <msmith> end of session, some discussion of dinner plans
18:06:06 <Zakim> -Evan_Wallace
18:06:09 <msmith> re-convene for next session at 2PM
18:06:31 <bijan> I'm sorry, but I won't be able to call in tonight...sick spouse
18:06:49 <bijan> I'll try to be on irc from home and check in from time to time
18:07:20 <Zakim> -christine
18:07:36 <bijan> I care about: 1) datatype disjointness, strongly (I want it), and 2) named datatypes, I think we should have 'em in.
18:08:02 <bijan> 3) I'm against harmonizing the total set of datatypes with RIF if that means pruning
18:21:59 <Rinke> Rinke has joined #owl
18:33:40 <bmotik_> bmotik_ has joined #owl
18:44:30 <uli> uli has joined #owl
18:49:27 <Achille> Achille has joined #owl
18:50:11 <Zakim> +[IBM]
18:50:41 <Achille> zakim, IBM is me
18:50:41 <Zakim> +Achille; got it
18:53:27 <Zhe> Zhe has joined #owl
18:54:48 <schneid> schneid has joined #owl
18:56:03 <zwu2> zwu2 has joined #owl
18:57:34 <Zhe1> Zhe1 has joined #owl
19:00:35 <baojie> baojie has joined #OWL
19:00:35 <bijan> bijan has joined #owl
19:01:12 <MarkusK_> skribenick: schneid
19:01:24 <MarkusK_> scribenick: schneid
19:01:30 <alanr> alanr has joined #owl
19:01:47 <schneid> ivan: we interrupted boris before lunch w.r.t. functional syntax
19:02:32 <schneid> boris: in Structural Spec, speparate between "core" structural aspects and additional constraints leading to OWL 2 DL
19:02:58 <schneid> boris: we can concentrate on section 3, because restrictions are listed there
19:03:30 <schneid> boris: structural spec allows to go to functional syntax, but there's no way back
19:03:37 <schneid> borsk
19:03:41 <msmith> lc comment http://lists.w3.org/Archives/Public/public-owl-comments/2009Feb/0005.html
19:04:36 <schneid> boris: proposal is to go back to what we had earlier (typed syntax), but only to functional syntax
19:04:53 <schneid> boris: would be restricted to the terminals of the grammar of the language
19:05:10 <schneid> ian: would be completely equivalent to the structural spec
19:05:18 <schneid> alanr: why do we care
19:05:39 <bijan> Point of info: I'm told by Matthew that he won't implement a parser in the OWL API for the untyped functional syntax (though probably still a serializer). 
19:05:44 <bijan> FWIW
19:05:57 <Zakim> +Evan_Wallace
19:06:12 <bijan> That point only matters if you want the OWL API to parse FS and don't want to write the parser yourself.
19:06:12 <schneid> alanr: we can import type declarations from other files
19:06:46 <schneid> boris: nothing changes in the structure
19:07:22 <schneid> ian: if you have untyped stuff in RDF graph, what will happen?
19:07:25 <christine> christine has joined #owl
19:07:59 <schneid> boris: still not allowed, reverse mapping keeps untouched
19:09:06 <schneid> ivan: this is only for using the functional syntax that is not DL
19:09:36 <schneid> ivan: difference is that I currently have to follow all the restrictions
19:11:11 <schneid> alanr: what happens with an untyped subclassing triple in RDF?
19:11:21 <schneid> pfps: will not be reverse mapped
19:12:29 <schneid> ivan: understands boris, if i can represent something in functional syntax (without additional restrictions), then it adheres to the structural spec of OWL 2
19:13:19 <schneid> ivan: this makes functional syntax into just a complete serialization of the structural spec (UML)
19:14:00 <schneid> alanr: still concerns with importing of files
19:15:46 <schneid> alanr: asks people whether they feel that it is a good idea
19:15:58 <bijan> Feel what?
19:16:05 <schneid> MarkusK_: ok
19:16:22 <bijan> I'm sorry, I can't call in without disturbing my (very ill) spouse, so I have to be consulted via IRC
19:16:29 <schneid> schneid: not quite clear on the details, but sounds like a progress compared to current situation
19:16:35 <bijan> What?
19:17:38 <bijan> What's the potentially good idea we're discussing?
19:17:48 <IanH> Full typing
19:18:26 <bijan> I think it's a very good idea :)
19:19:52 <schneid> ivan: is it a problem that a property chain ends with a data property?
19:20:16 <alanr> Alan is concerned with restrictions that are built in to the syntax, and that such cases will be listed along with the rest of the restrictions or fixes so that they are removed.
19:20:31 <schneid> boris: we need to extend the structural spec for this
19:20:48 <Zakim> +??P9
19:20:50 <bijan> Property chains ending...whugah?
19:20:59 <schneid> boris: I can in a first step put in EdNotes about this, and then we can see how we treat this
19:21:08 <ivan> bijan, ending with a datatype property
19:21:31 <bijan> I understand that, I just don't understand the relevance
19:21:31 <christine> zakim, +??P9 is christine
19:21:31 <Zakim> sorry, christine, I do not recognize a party named '+??P9'
19:21:46 <christine> zakim, ??P9 is christine
19:21:46 <Zakim> +christine; got it
19:21:50 <schneid> ian: prefers to add informal notes of the form: "this restriction is needed for DL, but this can be relaxed in Full"
19:22:07 <alanr> q?
19:22:26 <IanH> q?
19:22:30 <schneid> msmith: would change a lot in the functional syntax, may be problem for current users
19:22:39 <christine> is the topics DL or full typing ?
19:22:52 <bijan> full typing, it seems
19:23:03 <schneid> boris: probably few people use it currently, and big stake holder Mathew would love to see the change
19:23:53 <bijan> I reiterate: FS parsing will not happen by Manchester in the OWL API with the current untypedness
19:24:04 <christine> any comment to my email reply to Boris ?
19:24:39 <schneid> mschneid: sees a lot of parallel discussion on the IRC
19:24:57 <schneid> s/mschneid/schneid/ :)
19:25:22 <alanr> PROPOSED: We will basically follow Ian and Ivan's proposal, with the approach that Boris has discussed, including at least noting of cases where the syntax adds restrictions that are effectively DL.
19:25:43 <alanr> http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0006.html
19:26:33 <bijan> Are we voting?
19:26:37 <uli> ?
19:26:41 <bmotik> +1
19:26:47 <bijan> +1
19:26:47 <alanr> still working on the wording
19:26:51 <ewallace> 0
19:27:45 <christine> 0 (not explicit remotely)
19:27:49 <ivan> 1
19:28:38 <pfps> LC comment 58 http://lists.w3.org/Archives/Public/public-owl-comments/2009Feb/0005.html
19:28:40 <alanr> soon to be PROPOSED: We will basically follow Ian and Ivan's proposal, with the approach that Boris has discussed, including at least noting of cases where the syntax adds restrictions that are effectively DL.  http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0006.html. To address LC comment 58, Functional syntax will have terminals strongly typed but such changes will not effect parsing or semantics.
19:28:57 <Achille> 0 (not explicit remotely, and did not attend the whole presentation)
19:29:12 <alanr> still waiting for approval of wording.
19:29:44 <alanr> PROPOSED: We will basically follow Ian and Ivan's proposal, with the approach that Boris has discussed, including at least noting of cases where the syntax adds restrictions that are effectively DL.  http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0006.html. To address LC comment 58, Functional syntax will have terminals strongly typed but such changes will not effect parsing or semantics.
19:29:47 <alanr> vote now
19:29:47 <bmotik> +1
19:29:49 <ivan> 1
19:29:55 <Zhe1> +1
19:29:55 <alanr> 0
19:29:55 <MarkusK_> +1
19:29:56 <pfps> +1 ALU
19:29:56 <bijan> +1
19:29:58 <uli> +1
19:29:58 <baojie> 0
19:30:09 <IanH> +1
19:30:10 <msmith> +1
19:30:16 <sandro> +1
19:30:17 <schneid> >0 (but still unclear about all the ramifications)
19:30:26 <ewallace> 0
19:30:43 <alanr> RESOLVED: We will basically follow Ian and Ivan's proposal, with the approach that Boris has discussed, including at least noting of cases where the syntax adds restrictions that are effectively DL.  http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0006.html. To address LC comment 58, Functional syntax will have terminals strongly typed but such changes will not effect parsing or semantics.
19:31:23 <schneid> ian: notes that we did not yet treated LC 48, 29
19:31:49 <schneid> ... in the "Presentation" section of the Agenda
19:34:15 <schneid> alanr: 48 is is also about having more RDF/XML in documents (Structural Spec?)
19:34:30 <schneid> ivan: no need to have triples in the Direct Semantics, for example
19:34:42 <bijan> I hope we aren't too keen on RDF/XML
19:34:51 <bijan> I guess I don't necessarily mind it
19:35:08 <bijan> But it is rather cumbersome to say the least
19:35:08 <schneid> boris: not opposed to have it in the structural spec, but will perhaps become a mess
19:35:43 <bijan> I mean, not all the RDF documents use RDF/XML!
19:36:10 <schneid> sandro: maybe button for examples which optionally gives RDF
19:36:30 <schneid> sandro: may be in different window
19:37:01 <bijan> I'm working on some layouts
19:37:01 <schneid> pfps: ecstatic with popups
19:39:05 <schneid> boris: should these syntaxes be switchable
19:39:23 <schneid> ivan: prefers approach in primer: global switching on/off of syntaxes
19:40:30 <schneid> boris: would prefer ntriples over RDF/XML
19:40:43 <schneid> ivan: would be happy with turtle
19:42:36 <schneid> schneid: special handling of lists, proposes to follow RDF Mapping
19:42:56 <schneid> boris: yes, lets have it the same as in Mapping
19:43:21 <bijan> I wonder if we should get too fine grained here
19:43:28 <bijan> There's some experimentation that must be done
19:43:32 <schneid> ivan: makes sense to follow RDF mapping
19:45:07 <alanr> soon to be PROPOSED: Include RDF syntax for examples in Syntax using the same syntax in Mapping, in order to respond to syntax presentation issues in 29 and 48
19:46:16 <alanr> PROPOSED: Include RDF syntax for examples in Syntax using the same syntax in Mapping, in order to respond to syntax presentation issues in 29 and 48
19:46:16 <bijan> I might oppose this
19:46:21 <bmotik> +1
19:46:22 <bijan> -1
19:46:30 <alanr> bijan, please explain
19:46:47 <bijan> I'm a bit concerned about being too specific in the editing
19:46:59 <bijan> What if that syntax turns to be less owrable than turtle?
19:47:12 <bijan> Can we make that advisory?
19:47:30 <alanr> we discussed making it editor choice and this is what Boris chose...
19:47:45 <bijan> I'm actually an editor of that document as well :)
19:48:05 <pfps> pfps has joined #owl
19:48:06 <alanr> one moment please
19:48:25 <bijan> (If it's editors choice, why must we spec it in the proposal?)
19:48:33 <alanr> we're talking about it now
19:49:04 <schneid> schneid: RDF-Based Semantics document also has triples, at least in examples, so I would like to have it consistent with the rest of the documents
19:49:35 <schneid> ivan: syntax in Mapping is very close to turtle
19:49:48 <alanr> PROPOSED: Include RDF syntax for examples in Syntax n order to respond to syntax presentation issues in 29 and 48
19:49:54 <bijan> +1
19:49:57 <schneid> ivan: do we use turtle
19:49:57 <alanr> +1
19:50:00 <bmotik> +1
19:50:01 <msmith> +1
19:50:02 <MarkusK_> +1
19:50:05 <IanH> +1
19:50:07 <Zhe1> +1
19:50:08 <schneid> +1
19:50:08 <baojie> 0 (+1)
19:50:14 <baojie> +1
19:50:20 <ivan> +1
19:50:25 <pfps> -0.epsilon
19:50:32 <sandro> +1
19:50:33 <alanr> +1 .
19:51:17 <Achille> +1
19:51:24 <schneid> ian: these were tricky things, and I think that we did a pretty good job
19:51:38 <sandro> http://www.w3.org/2007/OWL/wiki/Chatlog_2009-02-23
19:52:05 <schneid> Topic: Datatypes
19:53:04 <schneid> ian: we are starting with what was in the context of RIF coordination
19:53:31 <IanH> q?
19:53:32 <schneid> SubTopic: Disjointness
19:53:48 <schneid> ivan: we have two different issues with disjointness
19:54:32 <schneid> ivan: we have already feedback from implementers saying what we have today is an implementation nightmare (independent of RIF discussion)
19:54:47 <schneid> ivan: this alone is a reason to go with disjointness
19:55:03 <bijan> +1 to ivan
19:55:18 <schneid> ivan: boris and c&p say this
19:55:27 <schneid> msmith: no, we did not really say this
19:55:34 <bijan> I say it!
19:55:35 <schneid> ivan: at least bijan says
19:56:14 <bijan> I'll add as well that we have some evidence that infinite character sets are bad (from Birte)
19:56:48 <IanH> q?
19:56:56 <schneid> alanr: refers to RIF argument that they need disjointness because of RIF operators
19:57:20 <schneid> ian: can we leave rif aside , and decide as a WG what we want?
19:57:57 <schneid> ian: whatever we hear as CR feedback will be feedback from an implementer
19:58:25 <schneid> ian: there are people in the wg who changed their view on disjointness
19:58:28 <msmith> msmith: (clarifying previous scribe) we didn't say anything about implementation experience with Pellet, since we haven't done it.
19:58:37 <bijan> I'll point to to past work by SWBP: http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values-differ
19:58:41 <schneid> alanr: would like to learn about the details on the technical problems
19:58:45 <bijan> (Past pellet had disjointness.)
19:59:02 <msmith> yes, yes, and still does
19:59:28 <schneid> boris: comparing of float and decimal is sort of hard
19:59:29 <MarkusK_> q+
19:59:41 <IanH> q?
19:59:51 <IanH> ack MarkusK_
19:59:54 <ewallace> and double
19:59:57 <schneid> boris: inefficient, nightmare, (many other negative words)
20:00:10 <IanH> zakim, MarkusK_ is Markus
20:00:11 <Zakim> sorry, IanH, I do not recognize a party named 'MarkusK_'
20:00:20 <schneid> markus: is this a problem with double and float?
20:00:25 <IanH> zakim, Markus is MarkusK_
20:00:25 <Zakim> sorry, IanH, I do not recognize a party named 'Markus'
20:00:38 <schneid> boris: double/float is not such a big problem probably
20:01:02 <schneid> boris: but trouble pops up with rationals
20:01:34 <schneid> alanr: what about comparing rationals to decimals?
20:02:05 <IanH> q?
20:02:08 <schneid> boris: marginally easier, but not really easy
20:02:18 <schneid> ian: confused where we are standing
20:02:31 <ewallace> I thought we had a sense of the group at last telecon to have disjointness
20:02:34 <bijan> I also think making them disjoint makes the whole picture cleaner and more inline with common expectation. It's what people expect from XML Schema, and it's justifiable. Float and Double are very specific types and it's reasonable to view them this way
20:02:35 <IanH> q?
20:03:06 <schneid> ian: looks like that most of the group is not against the change to disjointness
20:04:01 <schneid> zhe: we are normalizing into a common datatype, would like to /not/ having them disjoint
20:04:26 <IanH> q?
20:05:09 <schneid> boris: floats can become very large, and it would take a lot of memory to normalize it into a number
20:05:44 <schneid> scribe is uncertain about validity about his scribing
20:06:28 <MarkusK_> q+
20:06:29 <schneid> ian: different people think that is difficult, other think not difficult, does not take us anywhere
20:06:33 <IanH> q?
20:06:57 <IanH> ack MarkusK_
20:07:26 <schneid> markus: would it just be possible to make non-disjointness optional?
20:07:50 <IanH> q?
20:07:56 <schneid> markus: (correction) about optionality of problematic datatypes (float, etc)
20:08:08 <IanH> q?
20:08:44 <MarkusK_> markus: would it be possible ot keep common value spaces, but make support for floa, double optional for implementations
20:08:55 <MarkusK_> s /floa/float/
20:09:09 <IanH> q?
20:09:41 <schneid> zhe: we have a database, we have to support this, and to handle this
20:09:53 <IanH> q?
20:10:43 <schneid> ivan: question, what would it mean for oracle implementation if we change to disjointness
20:10:54 <alanr> http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
20:10:54 <schneid> zhe: would be lot of work
20:11:10 <IanH> q?
20:11:36 <IanH> q?
20:12:41 <IanH> q?
20:13:00 <bijan> btw, I believe jena supports the disjointness: http://jena.cvs.sourceforge.net/viewvc/jena/jena2/src/com/hp/hpl/jena/datatypes/xsd/impl/
20:13:10 <IanH> q?
20:13:35 <bijan> I'm havign some time locating the precise code
20:13:44 <schneid> schneid: we have different stakes, we should really consider to decide about optionality
20:13:48 <IanH> q?
20:14:16 <schneid> ivan: we had float in OWL 1
20:14:18 <msmith> @bijan, yes. jena is disjoint.  jeremy authored the note that suggested disjointness
20:14:24 <IanH> q?
20:14:26 <schneid> ian: no, not mandatory
20:14:30 <bijan> That was my suspicion
20:15:06 <alanr> XML schema speaks both ways: The ·value space· of float contains the non-zero numbers  m × 2e
20:15:14 <alanr> The ·value space· of decimal is the set of numbers that can be
20:15:15 <alanr> obtained by dividing an integer by a non-negative power of ten, i.e.,
20:15:15 <alanr> expressible as i / 10n where i and n are integers and n ≥ 0
20:15:20 <alanr> "set of numbers"
20:15:27 <IanH> q?
20:15:33 <alanr> not disjoint by the english descriptions
20:16:03 <bijan> the ·value space·s of all ·primitive· datatypes are disjoint (they do not share any values)
20:16:12 <bijan> http://www.w3.org/TR/xmlschema-2/#equal
20:16:24 <IanH> q?
20:16:42 <bijan> float, double, and decimal are all primitive datatypes
20:16:43 <alanr> http://www.w3.org/TR/xquery-operators/#func-numeric-equal
20:16:50 <alanr> they are all comparable
20:16:58 <schneid> schneid: what are ramifications if people simply ignore disjointness
20:17:07 <bijan> Higher level functions are no relevant
20:17:08 <bijan> not
20:17:13 <schneid> boris: non-conformance, test cases will be answered wrongly
20:17:13 <bijan> I can always wrap a coercion
20:17:22 <bijan> compare("1.0",1)
20:17:32 <bijan> If my compare function parses the first, it can compare them
20:17:45 <IanH> q?
20:17:56 <msmith> the test case http://km.aifb.uni-karlsruhe.de/projects/owltests/index.php/Datatype-Float-Discrete-002 will change from consistent to inconsistent
20:18:02 <IanH> q?
20:18:11 <bijan> It's hard to see how the schema document is ambiguous about the disjointness of the value spaces
20:18:32 <schneid> ian: would WG people positively object to optionality
20:18:43 <bijan> It's hard to evaluate an argument that starts by appealing to the definition in the schema spec then jumps to a different operator in a different spec
20:19:00 <IanH> q?
20:19:04 <schneid> zhe: would be ok
20:19:11 <bijan> How does optionality solve anything?
20:19:19 <bijan> Are they going to be, in optional, disjoint or not?
20:19:20 <schneid> pfps: i don't think wouldn't get a away with this
20:19:24 <bijan> We still have to answer that question
20:19:32 <bijan> Or we'll have conflicting implemetnations
20:19:43 <IanH> q?
20:20:10 <schneid> ivan: what do we know about owl 1?
20:20:38 <bijan> The SWBP document said disjointness
20:20:46 <bijan> Pellet implemented disjointness, as did Jena
20:20:51 <IanH> q?
20:20:53 <schneid> msmith: old pellet used disjointness
20:21:02 <schneid> ivan: any example for non-disjointness?
20:21:05 <bijan> FaCT++ did not, neither did Cerebra (on feedback from users)
20:21:33 <schneid> pfps: would be non-conformant, since owl 1 says, /if/ xsd datatypes are used, /then/ disjoint
20:21:51 <IanH> q?
20:22:19 <bijan> OWL 2 would be, to my knowledge, the first w3c semantic web rec or note that made them non-disjoint (fwiw)
20:22:32 <ewallace> http://www.w3.org/TR/xmlschema-2/ in not a Recommendation?
20:22:44 <schneid> boris: this is a guess work now, we don't know
20:23:03 <bijan> ewallace: that says they are disjoint
20:23:06 <IanH> q?
20:24:19 <schneid> ivan: rif people tell me that for their implementations they need disjointness, but I don't want to solve rif's problems
20:24:31 <schneid> ian: we should really leaf rif out of this
20:24:52 <bijan> (And what if we intend to combine RIF like rules, a la dl safe swrl rules and owl?)
20:25:01 <IanH> q?
20:25:37 <schneid> markus: i'm not clear wheter we discussion general disjointness (all datatypes), or only about certain datatypes
20:25:47 <schneid> alanr: it's about following XSD
20:25:52 <IanH> q?
20:26:10 <MarkusK_> I think it fits into that picture http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
20:26:32 <pfps> pfps has joined #owl
20:26:36 <MarkusK_> (owl:real simply being above the xsd:decimal-stack)
20:26:42 <IanH> q?
20:27:08 <IanH> q?
20:27:18 <baojie> q+
20:28:06 <ivan> ack baojie 
20:28:08 <MarkusK_> markus: So is it true to say that we are in any case intending to keep xsd:decimal below owl_rational and owl:real, so that only the disjointness of float and double from owl:real is discussed?
20:28:13 <MarkusK_> boris: yes
20:28:18 <bijan> yes
20:29:31 <schneid> zhe: conversion between datatypes in RDB section is well developed 
20:30:17 <IanH> q?
20:31:02 <schneid> zhe: I'm not saying that its impossible to make them disjoint, my concerns are about much effort
20:31:19 <schneid> pfps: how many people are using floats in ontologies?
20:31:52 <IanH> q?
20:32:31 <MarkusK_> q+
20:32:33 <schneid> alanr: science community use floats regularly
20:33:04 <IanH> q?
20:33:33 <ewallace> decimal better than float!
20:33:35 <IanH> q?
20:33:43 <schneid> pfps: in programming languages, there are problems with floats
20:34:01 <IanH> q?
20:34:07 <IanH> ack MarkusK_
20:34:26 <IanH> q?
20:35:00 <schneid> markus: i wonder why the fact that many people use floats should be an argument for non-disjointness
20:35:30 <schneid> markus: what about facets?
20:36:09 <IanH> q?
20:36:25 <IanH> q?
20:36:30 <MarkusK_> alan: facets could not use comparisons to decimals for floats
20:36:58 <MarkusK_> markus: but you still could use facets by using floats exclusively
20:37:19 <MarkusK_> alan: yes, but I think it is conceptually less clean to have disjoint number value spaces
20:38:05 <schneid> ian: it's strawpoll time on the question whether to have disjointness or not
20:39:08 <IanH> STRAWPOLL: double, float and owl:real should be pairwise disjoint
20:39:14 <bmotik> +0.7
20:39:18 <alanr> -1
20:39:22 <baojie> +1
20:39:26 <MarkusK_> +0.5e0
20:39:26 <pfps> +0.7E0
20:39:28 <sandro> +0.333333
20:39:29 <msmith> +1
20:39:29 <ewallace> +1
20:39:37 <Achille> +1
20:39:39 <schneid> +epsilon
20:39:40 <ivan> +1
20:39:44 <Zhe1> -1
20:40:43 <ewallace> Should we consider this with required/optional?
20:40:49 <schneid> ian: ask alanr and zhe whether they will object
20:41:08 <bijan> +1
20:41:58 <IanH> STRAWPOLL: double, float and owl:real should be share a single value space as per current spec
20:42:01 <schneid> alanr: has to consult with his institutes
20:42:03 <alanr> +1
20:42:06 <bmotik> -0.7
20:42:08 <bijan> -1
20:42:12 <MarkusK_> -0.5
20:42:13 <sandro> -0
20:42:14 <ivan> -1
20:42:19 <pfps> -1
20:42:20 <Achille> -0.5
20:42:21 <ewallace> -.5
20:42:24 <baojie> -1
20:42:28 <msmith> -1
20:42:33 <schneid> zhe: will consult within oracle
20:42:39 <Zhe1> +1
20:43:08 <schneid> 0 - (my original answer)
20:43:58 <schneid> boris: would not object to non-disjointness
20:44:08 <schneid> pfps: would not object
20:44:24 <schneid> ivan: compatibility with rif is important for ivan
20:44:27 <IanH> The people who just voted -1 (i.e., against single value space), would you "lie in the road" if we decide on single value space?
20:44:37 <bijan> It's possible
20:44:49 <bmotik> I wouldn't lie in the road
20:44:54 <bijan> Obviously, as with everyone, I would have to consult
20:45:13 <schneid> ivan: it's my job to help on compatibility
20:45:38 <schneid> ivan: needs to see what RIF is saying about this
20:45:58 <bijan> I think it's an easy thing to do that 1) adds compatibility with the past, 2) adds compatibile or perceived compatibility with RIF
20:46:07 <bijan> and 3) has merit on its own
20:46:17 <bijan> (disjointness that is)
20:46:44 <bijan> Non-disjointness may have independent merit, but it doesn't ahve the other two
20:47:06 <schneid> ian: we now have to wait for people to consult with their organizations and working groups
20:47:38 <IanH> q?
20:47:45 <bijan> The primary merit for either disjointness and non-disjointnes doesn't seem overwhelming, esp. to the other side. I've heard (pro disjointness) "concpetually cleaner" and "easier for our implementation"
20:47:49 <msmith> ivan: (and alanr) it is possible that RIF will change their mind and prefer non-disjointness
20:48:27 <schneid> alanr: there will also problems with rif on n-ary datatypes
20:48:50 <bijan> I would argue that disjointness is at least equiclean and has the advantage of ensure that people *don't* just use it as a funny syntax for decimals and rather easy to implement
20:49:44 <schneid> ian: can people please go and consult, so that we can have a formal vote in some time from now
20:50:16 <IanH> q?
20:50:31 <schneid> ivan: some technical issues from jos and alan have to be resolved
20:51:05 <IanH> q?
20:51:27 <IanH> q?
20:51:30 <schneid> ivan: we should give rif group the the chance to think about our current position
20:53:01 <schneid> msmith: it's unclear whether there are ramifications for the profiles
20:53:34 <schneid> ian: realizes that we are already deep in coffee break time
20:54:55 <schneid> ian: we settle on that we will have formal vote on this disjointness issue at 11th of March
20:55:12 <schneid> ian: resolved: we will have formal vote on this disjointness issue at 11th of March
20:55:32 <schneid> RESOLVED: we will have formal vote on this disjointness issue at 11th of March
21:08:24 <sandro> ...test...
21:13:38 <alanr> "0.20000000298023223876953125000000000000000000000000000"
21:16:17 <MarkusK_> scribenick: MarkusK_
21:16:37 <MarkusK_> topic: OWL/RIF datatypes
21:17:03 <MarkusK_> http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0027.html and http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0032.html
21:18:01 <MarkusK_> alanr: what the comments say is that owl:real and owl:rational should not be supported
21:18:08 <MarkusK_> ian: is that an option for us?
21:18:13 <bijan> -1
21:18:17 <MarkusK_> ivan: rational was still pending
21:18:28 <MarkusK_> pfps: there are many use cases, including recipes
21:18:42 <MarkusK_> ... US people use "1/3 cups" of flour
21:18:52 <IanH> q?
21:19:05 <MarkusK_> ivan: I understodd that the RIF group is looking at rational numbers
21:19:24 <MarkusK_> mike: is it a problem for us if they do not support reals and rationals?
21:19:37 <bijan> I'll note that a surprising number of calculators, both web based and downloadable support rationals (internally
21:19:41 <MarkusK_> ian: well, we would then accept some incompatibility
21:19:59 <MarkusK_> boris: they have other datatypes as well, which we do not have
21:19:59 <bijan> E.g., http://www.google.co.uk/search?hl=en&q=%281%2F3%29*3&btnG=Google+Search&meta=
21:20:08 <MarkusK_> ... for example, there is xsd:duration
21:20:31 <MarkusK_> alanr: so we do not mention these types in our table of incompatibilities yet?
21:20:37 <MarkusK_> boris: no
21:21:01 <MarkusK_> ian: we could fall back to fudging
21:21:09 <IanH> q?
21:21:17 <MarkusK_> ... stating that we support "essentially the same datatypes"
21:21:29 <MarkusK_> ian: what are we going to do hten?
21:21:31 <IanH> q?
21:21:43 <MarkusK_> ... shall we wait for RIF?
21:21:46 <IanH> q?
21:21:48 <pfps> alan: just say no
21:21:50 <bijan> I still don't understand the argument pro supporting the same datatypes...aligning datatypes as far as reasonable, yes, same set..whahaugh?
21:21:52 <pfps> +1 to alan
21:22:01 <MarkusK_> ivan: who is currently taking care of this issue?
21:22:22 <bijan> I mean, I don't see the prima facie case...and I spent some time with Chris Welty on the rif list
21:22:43 <MarkusK_> boris: there are arguments for the datatypes we support
21:22:48 <bijan> AFAICT, it's just "it would be ridiculous not to make them the same", but that didn't seem very plausible to me
21:22:51 <MarkusK_> ... they are used in ontologies
21:23:19 <MarkusK_> ... our list is based on what I considered to be implementable in a reasonable way
21:23:26 <IanH> q?
21:23:34 <MarkusK_> ... our additional datatypes are generally easy to implement, hence they were included
21:23:46 <MarkusK_> ... e.g. xsd:NCName and xsd:NMTOKEN
21:24:03 <IanH> q?
21:24:31 <schneid> q+
21:24:40 <bijan> http://www.open-std.org/jtc1/sc34old/repository/0392.htm
21:25:23 <MarkusK_> ivan: could we just state than that we keep the current restrictions of supported datatypes, and leave it to RIF to make a decision on what to do?
21:25:56 <IanH> q?
21:26:00 <IanH> ack schneid
21:26:32 <MarkusK_> boris: our current set of datatypes comprises the XSD types we understand plus some additional OWL types, and the XSD types are partly interpreted in a specific way (disjointness)
21:26:42 <bijan> http://www.xml.com/lpt/a/1006
21:26:52 <MarkusK_> schneid: any mandatory datatype is a burden to implementors
21:27:01 <bijan> (these are pro-rational screeds :))
21:27:07 <MarkusK_> ... so we should rather require less than more
21:27:24 <IanH> q?
21:27:42 <MarkusK_> mike: as an implementor, I don't think the burden is very big
21:27:46 <Zakim> -christine
21:27:48 <msmith> msmith: many of the mandatory types become syntactic shorthand.  See http://www.w3.org/TR/xmlschema11-2/#built-in-datatypes
21:28:15 <MarkusK_> sandro: do we agree that OWL supports all of XSD except the "ill-defined" ones
21:28:23 <bijan> I think naming types deriveable from the core ones with facets is a minimal burden
21:28:49 <bijan> (Over supporting the core ones with facets alone)
21:28:49 <MarkusK_> pfps: well, the datatypes must be suitable for OWL
21:29:06 <MarkusK_> boris: the problem is also related to some facets
21:29:07 <IanH> q?
21:29:20 <MarkusK_> ... some of those must be adjusted to be manageable in OWL implementations
21:29:37 <MarkusK_> ian: the question now is what our answer is going to be
21:29:58 <IanH> q?
21:29:59 <MarkusK_> sandro: I think it would be rational to state that we support and why
21:30:17 <MarkusK_> ... we should just find some more objective criteria to explain what we support
21:30:36 <MarkusK_> alanr: some datatypes could indeed be supported, but are just very hard to implement
21:30:56 <MarkusK_> ... so referring to use cases and our judgement of what is reasonable might be the best we can do
21:31:17 <MarkusK_> boris: I think our selection of the sensible types is rather valid
21:31:36 <MarkusK_> ... the issue is rather that there are so many types, and people are not familiar with all of them
21:32:19 <MarkusK_> mike: the SemWeb Best Practices WG has produced notes regarding the datatypes that should be supported
21:32:25 <MarkusK_> ... is that relevant for us?
21:32:33 <IanH> q?
21:32:39 <MarkusK_> ivan: well, there are published notes, but the group does not exist anymore
21:32:56 <MarkusK_> ... we may or may not refer to the result of that group to strengthen our case
21:33:06 <MarkusK_> ... this might be a clear and polite thing to say to RIF
21:33:19 <MarkusK_> ... but I do not know what datatypes the group actually suggests
21:33:34 <MarkusK_> mike: I have no idea, I was thinking about some future list
21:33:47 <MarkusK_> ... but apparently we are the only ones currently dealing with the problem
21:34:30 <MarkusK_> boris: there are some further datatypes that RIF has and we do not, e.g. octets and anyURI
21:34:44 <IanH> q?
21:35:15 <MarkusK_> ... I looked at all datatypes in 1.0 spec and took all datatypes where I could make sense of
21:35:43 <MarkusK_> ... one could have another look at the 1.1 spec, but otherwise I think my selection is pretty maximal
21:35:57 <MarkusK_> sandro: did we not recently remove a datatype because of RIF input?
21:36:05 <IanH> q?
21:36:12 <MarkusK_> boris: this was because I misinterpreted the value space there
21:36:31 <MarkusK_> ivan: who is the Boris of the RIF group, i.e. the person who selected the types?
21:36:37 <MarkusK_> sandro: it was pretty ad hoc
21:36:56 <MarkusK_> ... the suppoted types emerged in discussions, initial lists were pretty short
21:37:01 <IanH> q?
21:37:14 <MarkusK_> ivan: is it true that we are a superset of RIF regarding the XSD types?
21:37:29 <MarkusK_> boris: RIF also supports types from XQuery
21:37:36 <MarkusK_> ... the duration types are an example
21:38:33 <MarkusK_> ivan: if we say that we currently support a superset of what RIF has, plus rational etc, then there is no reason for us to reduce this if we have good arguments
21:39:08 <MarkusK_> schneid: our reason for having a special version of dataTime was to require a single point on the time line, right?
21:39:11 <MarkusK_> ian: yes
21:39:44 <MarkusK_> ian: it seems we have a fairly clear story for the choices we made regarding the types we support
21:39:53 <MarkusK_> ... we could refine this via email to create a response
21:40:32 <msmith> the duration dts in question: http://www.w3.org/TR/xpath-functions/#duration-subtypes
21:40:43 <MarkusK_> ivan: it would be good ta argue that we do essentially have a superset
21:40:53 <MarkusK_> ... of datatypes
21:41:09 <MarkusK_> boris: types like date, which RIF supports and OWL does not, are interval types
21:41:19 <IanH> q?
21:41:26 <MarkusK_> ... these are less problematic in RIF, but potentially very hard in OWL
21:42:24 <MarkusK_> ... One possible solution would be to look at the XSD spec (incl. XQuery) together with RIF, and deciced which datatypes both of us can support
21:42:28 <IanH> q?
21:42:33 <MarkusK_> ... and then stick strictly to the spec in what we support
21:42:41 <MarkusK_> ... including things like disjointness
21:43:08 <MarkusK_> ... this is something that I think could indeed be useful: a common list that is aligned with XML Schema
21:43:16 <MarkusK_> ian: so you suggest to negotiate with RIF?
21:43:40 <MarkusK_> boris: we agree on a set of formal criteria, which I think are not so different for both groups
21:43:49 <bijan> I don't want to forever align with RIF...RIF has different goals and needs
21:43:58 <MarkusK_> ... this would be the only approaach that would make sense to me
21:44:14 <MarkusK_> ... if we cannot achieve this, then we should not invest more time in discussing this
21:44:34 <bijan> RIF and OWL have fundamentally different missions
21:44:37 <MarkusK_> ian: but this would require more time, and it is unclear if we can achieve consensus with RIF
21:44:45 <bijan> It's not clear to me that they would align
21:44:53 <MarkusK_> ivan: but sandro said that RIF was rather ad hoc
21:45:02 <MarkusK_> sandro: yes, but very implementation specific
21:45:29 <bijan> For RIF I can see maximalist and minimalist arguments (maximalist: we do interchange so we should handle as much as possible; minimalist: we do interchange so we should go for widespread LCD)
21:45:35 <MarkusK_> ian: in any case it would be a big negotiation that is needed there, and I do not see a large benefit in doing this
21:45:59 <MarkusK_> ... in particular since we can already claim, vaguely, that we support "essentially" the same datatypes
21:46:30 <MarkusK_> boris lists the datatypes that OWL has and that we do not
21:47:18 <MarkusK_> boris lists the types that RIF supports and that we do not (mostly date and time related)
21:47:47 <MarkusK_> ian: I will try to phrase a proposal
21:49:58 <IanH> PROPOSED: in response to LC comments 22 & 25 we state our reasons for supporting the datatypes we support and offer to work with RIF to define a set of "Web compatible" datatypes supported by both OWL and RIF, i.e., the intersection of OWL and RIF supported datatypes
21:50:04 <pfps> +1 ALU
21:50:05 <sandro> +0
21:50:05 <alanr> +1
21:50:08 <ivan> 0
21:50:14 <bmotik> +1
21:50:18 <MarkusK_> markus: +1
21:50:19 <IanH> +1
21:50:19 <ewallace> +1 NIST
21:50:20 <schneid> 0
21:50:24 <Achille> 0
21:50:26 <bijan> +1 except for the "web compatible" stuff
21:50:26 <baojie> +1
21:50:39 <msmith> +1
21:50:56 <bijan> I don't understand the "offer" part
21:51:17 <IanH> RESOLVED: in response to LC comments 22 & 25 we state our reasons for supporting the datatypes we support and offer to work with RIF to define a set of "Web compatible" datatypes supported by both OWL and RIF, i.e., the intersection of OWL and RIF supported datatypes
21:51:18 <Zhe1> +0
21:51:36 <MarkusK_> ian: great, so we are done, unfortunately, there is more on datatypes
21:51:58 <MarkusK_> topic: supported OWL RL datatypes
21:52:59 <MarkusK_> http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0022.html and http://lists.w3.org/Archives/Public/public-owl-wg/2009Jan/0083.html
21:53:36 <MarkusK_> zhe: my comment (43) is that we do not want owl:rational
21:53:55 <MarkusK_> ian: and Jos (20) suggested to have all datatypes in RL
21:54:23 <MarkusK_> boris: from a reasoning point of view, there is indeed no good reason to exclude datatypes
21:54:24 <IanH> q?
21:54:30 <MarkusK_> ... that was an error on my side
21:54:48 <IanH> q?
21:54:49 <MarkusK_> pfps: so nobody argues against having all XSD datatypes in RL
21:55:03 <MarkusK_> ivan: in the case of RL, easy implementability was an important requirement
21:55:07 <bijan> I'll note that the profile leaves out other things...why not this
21:55:20 <IanH> You can look at Ivan for a while!
21:55:25 <MarkusK_> ... hence adding new datatypes should be done with care, the argumentation should not just be that it is technically possible
21:55:35 <MarkusK_> a+
21:55:38 <bijan> Implementatiosn can always support more (OWL RL+, we're studlier than oracle!!!)
21:55:38 <MarkusK_> q+
21:55:38 <IanH> q?
21:56:25 <MarkusK_> boris: what is currently out of RL is already only part of the OWL types, it appears that adding more datatypes might be easy in many cases
21:56:41 <MarkusK_> ... some of the missing types are very similar to the ones included already
21:56:56 <MarkusK_> ivan: but it might be that some are indeed hard to implement, esp. float and double
21:57:05 <IanH> q?
21:58:03 <MarkusK_> boris: ok, let's put those aside, but boolean and language should not be specifically excluded
21:58:24 <pfps> +1 to alan (if xsd:float is not in RL, then it is optional)
21:58:40 <MarkusK_> markus: I agree with boris, but maybe some of the problematic datatypes could be optional for RL, esp. rational?
21:58:44 <bijan> I don't understand that
21:58:49 <bijan> What does that mean?
21:59:27 <alanr> Alan said: We allow xml schema types that we have in OWL DL, into RL, but not more
22:00:03 <MarkusK_> pfps: I agree with alan here
22:00:41 <MarkusK_> zhe: from Oracle's perspective, adding positiveInteger etc. is not hard at all, but owl:rational does not fit to the current architecture at all
22:00:52 <MarkusK_> boris: how about xsd:boolena and xsd:language?
22:00:58 <MarkusK_> zhe: these should be ok
22:01:23 <IanH> q?
22:01:32 <IanH> ack MarkusK_
22:01:39 <MarkusK_> pfps: so there is a rationale for removing owl:rational and putting in boolean and language
22:01:49 <MarkusK_> ... so float and double remain the problematic types
22:02:14 <MarkusK_> mike: it would be useful to find a common denominator for all forward chaing rule systems
22:02:16 <IanH> q?
22:02:39 <msmith> mike: ... and the common demoninator is likely to be very small (e.g., integer and string)
22:03:20 <bijan> +1 to just integer and string
22:03:27 <MarkusK_> ian: so if float and double are not disjoint, Oracle would like to support them in RL, and if they are disjoint you wold not want them in?
22:03:29 <MarkusK_> zeh: yes
22:03:37 <MarkusK_> s /zeh/zhe/
22:03:59 <MarkusK_> ian: would you still be concerned with those issues if float and double would not be mandated by RL?
22:04:11 <MarkusK_> zhe: yes, because we still would like to support them anyway
22:04:20 <bijan> Ok, that's a bit strange...I wouldn't have thought disjointness would be such a problem for the architecture...still have to track originating dataypes...
22:04:25 <IanH> q?
22:04:27 <MarkusK_> ian: ok, so this is not a way to solve the disjointness issue ...
22:04:46 <pfps> implementing disjoint float/double should be possible with an integrated number system by tagging them specially (so they are different from untagged numbers)
22:04:49 <Zhe1> Zhe1 has joined #owl
22:04:58 <IanH> q?
22:05:03 <MarkusK_> ivan: my implementation of RL is not a forward chaining engine, I build upon an RDF environment
22:05:17 <MarkusK_> ... so I have all datatypes supported by that RDF environment
22:05:18 <Zhe1> test
22:05:41 <MarkusK_> sandro: the only datatype reasoning required in RL is comparison of values, right?
22:06:05 <MarkusK_> pfps: well, you also must support the canonical presentation of literals
22:06:28 <MarkusK_> sandor: ah, so even strictly disjoint datatypes have some implementation burden
22:07:03 <bijan> qua user, I'd be a bit concerned if my implementation normalized away all my datatypes
22:07:06 <MarkusK_> schneid: the datatypes in RDF are only a very restricted
22:07:11 <msmith> from rdf, http://www.w3.org/TR/rdf-mt/#dtype_interp
22:07:18 <MarkusK_> ... only XMLLiteral is required, others are just mentioned
22:07:30 <MarkusK_> ian: so just going for RDF datatypes would really be too little
22:07:56 <IanH> q?
22:08:28 <MarkusK_> boris: we are currently discussing the solution of adding boolean and language, removing rational, and maybe float and double?
22:08:39 <MarkusK_> ian: well some people thought that this could be too much already
22:08:51 <MarkusK_> ivan: I did not mean to say this really
22:09:00 <IanH> q?
22:09:12 <Zakim> -Achille
22:09:24 <MarkusK_> sandro: I guess we would not want RL to have any datatypes that RIF does not have
22:09:38 <MarkusK_> ... since a forward chaining RIF implementation is desirable
22:10:14 <MarkusK_> ... so maybe we should in this case ask RIF to supply us with a list of datatypes that RL should have
22:10:39 <MarkusK_> boris: I think that this is again requiring us to wait for RIF
22:10:48 <MarkusK_> ... then we might again need to negotiate with RIF
22:10:59 <MarkusK_> ... did we not already discuss this issue?
22:11:28 <MarkusK_> sandro: well, I just suggested a process, we do not need to negotiate
22:11:51 <MarkusK_> alanr: why do we not go for a real simple set of datatypes, like suggested by Mike?
22:12:04 <MarkusK_> ... and the rest could be optional
22:12:29 <bijan> (/me presumes for OWL RL only)
22:12:42 <MarkusK_> right
22:12:57 <bijan> Sounds ok to me
22:13:02 <sandro> sandro: (I suggest we simply defer to RIF for the expertise on which datatypes are easy to support on forward-chaining rule engines.)
22:13:28 <MarkusK_> michael: comparing the datatypes in the profiles, they seem to be the same
22:13:35 <MarkusK_> boris: yes, it is the same
22:13:46 <IanH> q?
22:14:19 <MarkusK_> michael: then when restricting the types of RL, would we not create a strange situation?
22:14:23 <IanH> q?
22:14:35 <MarkusK_> ... we would need to argue why RL has only so few types
22:14:53 <MarkusK_> mike: it fits to the idea of having RL as a profile that is very easy to implement
22:15:03 <IanH> q?
22:15:08 <bijan> And maximally compatible with RDF systems
22:15:17 <MarkusK_> boris: I do not think that any of the types discussed now are very hard to implement, besides float and double
22:15:30 <bijan> RDF datatypes are minimal, so support across stores vary
22:15:41 <bijan> OWL RL is both for rule engines *and* for RDF engines
22:15:48 <bijan> So we pick maximal compat with rdf engines
22:15:51 <MarkusK_> ... as Sandro said, RIF chose their types in a rather ad hoc way, so maybe it is not useful to base our types on their current list
22:15:54 <IanH> q?
22:16:06 <bijan> With a note saying the extra ones are relatively easy to implement in rule systems
22:16:10 <msmith> from the (out-of-date) rif draft http://www.w3.org/TR/rif-dtb/#Primitive_Datatypes
22:16:56 <MarkusK_> ivan: Dave Reynolds did go through the issue of implementing RL in RIF
22:17:09 <MarkusK_> ... he did do that on paper, and found some problems
22:17:09 <IanH> q?
22:17:15 <MarkusK_> ... related to datatypes
22:18:14 <MarkusK_> ian: when wanting RIF to support RL, we would restrict RL to include at most the types supported by RIF, not at least those types
22:18:31 <MarkusK_> ... this might be a question we can ask RIF
22:18:45 <MarkusK_> sandro: I can try to phrase the question
22:19:11 <MarkusK_> ... essentially, the question would be: "Can you support equality comparisons for this type?"
22:19:17 <sandro> "Do you have a compelling reason you can't implement an equality comparison on datatype literals of this type"
22:20:11 <bijan> I don't like this dynamic, myself. RIF is a different beast.
22:20:19 <bijan> What's the material harm in this variance?
22:20:30 <MarkusK_> alan: so the response would be that we agree to take out of RL the datatypes that they do not support
22:20:54 <sandro> Bijan, that RIF implementations don't get OWL-RL reasoning for free.   That's the cost of OWL-RL having a datatype that's not mandated in RIF.
22:20:56 <MarkusK_> ian: but 20 asks for extension, so we should include at least the datatypes that both RIF and OWL support
22:21:11 <MarkusK_> boris: then nothing is to do, we already have this
22:21:16 <bijan> They'll get a partial implementation for free
22:21:28 <MarkusK_> ... I note that neither comment 20 nor comment 43 came from the RIF group
22:21:34 <bijan> Such an implementation is almost certainly an inadqueate toy *anyway*
22:21:41 <bijan> Not sure why we should optimize for that
22:21:53 <bijan> (And it's not for free if they have to implement stuff)
22:22:09 <sandro> what would they have to implement, Bijan?
22:22:20 <MarkusK_> pfps: so the answer to Jos (20) is that we do not increase the datatypes in RL for fear of not having those extra types supported in RIF
22:22:35 <bijan> Well the choice is we trim back our types or force rifs to implement some
22:22:47 <bijan> you "do you have a compelling reason..."
22:22:49 <bijan> your
22:23:07 <MarkusK_> ian: right, we do not want to add any more since this might make implementation more difficult for rule engines
22:23:40 <MarkusK_> alan: yes, let us state that RIF does not include any additional datatypes that we could include into RL
22:24:08 <MarkusK_> ian: we could then have Sandro probe whether there are any additional datatypes that RIF would be willing to support
22:24:10 <bijan> I understand, but I don't like it :) I don't see great harm in keeping extra datatypes even if rif folks say, 'Our compelling reason is that we don't feel like it"
22:24:44 <MarkusK_> ... in particular, Sandro should find out which datatypes we should definitely not add to RL
22:25:04 <sandro> ACTION: sandro talk to RIF to see what datatypes in OWL must not be in OWL-RL.
22:25:04 <trackbot> Created ACTION-292 - Talk to RIF to see what datatypes in OWL must not be in OWL-RL. [on Sandro Hawke - due 2009-03-02].
22:25:12 <MarkusK_> ... this would include datatypes currently in RL, and other OWL datatypes that we might decide on adding to RL later on
22:25:46 <MarkusK_> alan: is there someone from Oracle on RIF?
22:25:54 <MarkusK_> zhe: yes, Gary Halmark is
22:26:19 <MarkusK_> alan: then we can say that we support positiveInteger in RL if RIF wants that
22:26:54 <MarkusK_> boris: I object, we should not have positiveInteger when we do not have negativeInteger!
22:27:12 <MarkusK_> ... it would be crazy to allow for that asymetry in our design
22:27:38 <MarkusK_> ... it is clear that we do not increase the implementation burden by many of the types that we could add
22:27:52 <MarkusK_> ian: but we need to make a response to Jos now, first
22:28:35 <MarkusK_> boris: the only datatype that we would exclude in this case, besides float, double, rational, is xsd:boolean
22:28:48 <MarkusK_> ... there is no good reason to not support this
22:29:10 <CGI507> CGI507 has joined #owl
22:29:18 <MarkusK_> ... we should answer to Jos by answering all types that are clearly not problematic, and discuss RIF separately
22:29:30 <CGI507> Zakim, CGI507 is me
22:29:30 <Zakim> sorry, CGI507, I do not recognize a party named 'CGI507'
22:29:53 <Zhe> Zhe has joined #owl
22:29:56 <MarkusK_> ... let us just all of them -- everything that is currently not there -- and then discuss later which others should be removed
22:30:20 <MarkusK_> ian: but zhe objects to rational
22:31:14 <MarkusK_> ian: we should not tell Jos that we include datatypes that we plan to remove soon later
22:31:29 <MarkusK_> ... we can tell him that others are currently under discussion for other reasons
22:31:51 <MarkusK_> ... thereafter, we can reply to Zhe by stating that we will not include rational
22:32:02 <MarkusK_> ... since it is not easy to implement
22:32:17 <MarkusK_> boris: well, rather that it is not implemented in current implementaitons
22:32:46 <MarkusK_> ian: I will formulate a proposal ...
22:34:05 <MarkusK_> s /let us just all/let us just add all/
22:34:15 <IanH> PROPOSED: OWL RL datatypes will be all OWL datatypes except rational & real (due to lack of implementations). The decision on supporting double and float will be deferred pending the decision on disjointness of numeric datatypes.
22:34:18 <bmotik> +1
22:34:21 <MarkusK_> +1
22:34:23 <pfps> +1 ALU
22:34:25 <IanH> +1
22:34:27 <msmith> +1
22:34:28 <MarkusK_> markus: +1
22:34:32 <Zhe> +1
22:34:38 <pfps> this answers 20 and 43b
22:34:38 <baojie> +1
22:34:44 <schneid> 0
22:34:51 <bijan> +1
22:34:56 <MarkusK_> ian: is there currently someone in charge of making the respoense?
22:35:12 <MarkusK_> boris: I cna take 20
22:35:22 <MarkusK_> pfps: I will take 43
22:35:24 <IanH> RESOLVED: OWL RL datatypes will be all OWL datatypes except rational & real (due to lack of implementations). The decision on supporting double and float will be deferred pending the decision on disjointness of numeric datatypes.
22:37:06 <MarkusK_> ian: I would like to check now that all responses decided on this morning are actually prepared by someone, we may need some actions
22:38:04 <MarkusK_> ian: response to 42?
22:38:10 <MarkusK_> ivan: I will take it
22:38:23 <MarkusK_> action: ivan to prepare a reply to comment 42
22:38:23 <trackbot> Created ACTION-293 - Prepare a reply to comment 42 [on Ivan Herman - due 2009-03-02].
22:38:40 <MarkusK_> ian: then you can also do 49; it is basically the same thing
22:38:45 <MarkusK_> action: ivan to prepare a reply to comment 49
22:38:45 <trackbot> Created ACTION-294 - Prepare a reply to comment 49 [on Ivan Herman - due 2009-03-02].
22:39:47 <MarkusK_> action: boris to prepare a reply to comment 20
22:39:47 <trackbot> Created ACTION-295 - Prepare a reply to comment 20 [on Boris Motik - due 2009-03-02].
22:39:56 <MarkusK_> action: pfps to prepare a reply to comment 43b
22:39:56 <trackbot> Created ACTION-296 - Prepare a reply to comment 43b [on Peter Patel-Schneider - due 2009-03-02].
22:40:33 <MarkusK_> ian: for the naming-related comments, we should first implement the changes in the documents
22:40:43 <MarkusK_> ... so we do not need an action there now
22:40:54 <MarkusK_> ... who is taking 24?
22:41:36 <MarkusK_> ivan: we are waiting for 2 weeks there to get feedback from RIF, so there is no action
22:41:44 <MarkusK_> ian: 22 and 25 could be responded to
22:41:54 <MarkusK_> action: pfps to prepare a reply to comment 22 and 25
22:41:54 <trackbot> Created ACTION-297 - Prepare a reply to comment 22 and 25 [on Peter Patel-Schneider - due 2009-03-02].
22:42:32 <MarkusK_> sandro: it might be good to refer to the open discussion on RL there
22:44:36 <MarkusK_> <The wiki table was edited, all numbers changed ... >
22:45:18 <MarkusK_> ivan: a purely administrative issue: we decided this afternoon to publish another recommendation
22:45:32 <MarkusK_> ... so it should probably be part o fthe next round of last calls
22:45:49 <MarkusK_> ... but this may require us to publish some first public working draft soon
22:46:42 <MarkusK_> ... then we need to decide on a title for the document
22:46:55 <MarkusK_> ian: the proposal was to call it "Overview"
22:48:04 <MarkusK_> ian: a potential problem is that there was an "Overview" in OWL 1, and what we plan is rather different
22:48:15 <MarkusK_> ivan: yes, we should not call it like this then
22:48:37 <ewallace> Why not just call it Introduction?
22:49:17 <MarkusK_> mike: it might be good to not have any editor on the Overview document
22:49:27 <MarkusK_> ... since this will be a very prominent document
22:49:33 <MarkusK_> sandro: that might not be possible
22:50:01 <MarkusK_> boris: maybe the union of the editors of all other documents
22:50:22 <MarkusK_> pfps: the team, W3C contacts plusWG chairs could be editors there
22:50:33 <MarkusK_> michael: how about calling it "Roadmap"?
22:50:50 <MarkusK_> ian: it might be a little bit too long for a roadmap
22:50:55 <MarkusK_> sandro: README
22:50:59 <MarkusK_> pfps: I like this
22:51:06 <MarkusK_> sandro: no, nobody reads the readme
22:51:33 <MarkusK_> mike: "Guide" would also be problematic, since there is an OWL guide already
22:51:49 <MarkusK_> ian: the problem might not be the same as with overview
22:52:17 <MarkusK_> sandro: we should stickk with Overview
22:52:32 <MarkusK_> ian: I agree that this is a good name as such
22:52:48 <MarkusK_> ivan: I would not like to have this discussion started, because the name was already used
22:53:17 <MarkusK_> sandro: "Document overview"
22:53:37 <MarkusK_> ... or "Overview of documents"
22:53:48 <MarkusK_> ian: I prefer the former
22:54:02 <MarkusK_> pfps: I like Document Overview
22:54:45 <MarkusK_> <ian moves the Introduction page on the wiki>
22:55:12 <MarkusK_> http://www.w3.org/2007/OWL/wiki/Document_Overview
22:55:40 <MarkusK_> alan: for now, let us be optimistic that we can use "OWL Working Group" as an editor
22:56:03 <MarkusK_> ivan: I am not sure is this is possible, we will see
22:56:45 <IanH> q?
22:56:47 <MarkusK_> sandro: we now can get a short name for the document in W3C space
22:57:11 <MarkusK_> ... I note that we can use "overview" since the OWL 1 Overview used "features"
22:57:31 <MarkusK_> topic: Other
22:57:42 <MarkusK_> ian: the first of those (50) was already killed
22:57:59 <MarkusK_> s /50/51/
22:58:33 <MarkusK_> ian: for 46 we decided that there will be hook that implementations can use to extend on this feature
22:58:56 <MarkusK_> mike: yes, the response is that we will not have a rec track document on n-ary datatype predicates
22:59:19 <MarkusK_> alan: but allowing arbitrary extensions would introduce incompatibilities
22:59:45 <MarkusK_> mike: but the note on predicates now does cover only a restricted set of predicates
22:59:47 <ewallace> Where is the response to the Named  User Defined Datatype issue?
23:00:10 <MarkusK_> alan: I think we should not repond pointing to the hook and the related note, but simply by saying we run out of time
23:00:29 <MarkusK_> ian: yes, stating that we do not have the time to do it might be a good replay
23:00:34 <MarkusK_> s /replay/reply/
23:00:43 <sandro> sandro has joined #owl
23:00:55 <ewallace> LC 51 part 3
23:00:55 <MarkusK_> ian: but there was another comment regarding n-ary extensions, coming from TopQuadrant
23:01:28 <MarkusK_> ... and our answer there was that the pointed out aspect of the documents was not a bug but a hook for n-ary predicates
23:01:44 <MarkusK_> ... it would be strange to not mention this in the response to 46 then
23:02:10 <MarkusK_> alan: but there could be problems pointing to the hook in this case
23:02:47 <MarkusK_> ian: I suggest to mention the hook in the response, but to explain that they are a feature at risk that could be removed in the final spec
23:03:22 <MarkusK_> ... pointing out that it is at risk then should also be done in the reply to TopQuadrant
23:03:25 <bijan> Why are they at risk?
23:03:31 <bijan> WHen were they made at risk?
23:03:58 <MarkusK_> ian: the "at risk" statement was from alan, I think
23:04:01 <schneid> schneid: hooks have precedence in the rdf semantics: there is a framework for specifying datatype maps, but only a single datatype is specified mandatorily, and only due to historic reasons
23:04:11 <MarkusK_> ... but there is indeed a note now
23:04:18 <bijan> They are not currently listed as at risk
23:04:20 <sandro> Bijan, where is the note?
23:04:21 <alanr> Bijan, where is the note about n-ary?
23:04:21 <MarkusK_> ian: bijan, where is the note?
23:04:24 <bijan> (the hooks)
23:04:27 <MarkusK_> (yes)
23:04:35 <pfps> bijan -  *where* is the note??
23:04:38 <bijan> http://www.w3.org/2007/OWL/wiki/Data_Range_Extension:_Linear_Equations
23:04:53 <MarkusK_> ian: so it is fully fleshed out, waiting for us to be published as a note
23:05:03 <bijan> Not quite, few small bits
23:05:07 <MarkusK_> ... so maybe it is not at risk after all
23:05:18 <bijan> A few days of work but yeah, we could go for a WD soon
23:05:20 <bijan> THen a note
23:05:35 <bijan> WD tomorrow actually
23:05:52 <MarkusK_> mike: the n-ary predicates then are similar to datatype maps: extension points ot the language
23:06:09 <MarkusK_> ian: in any case, it seems that this is not at risk
23:06:25 <MarkusK_> ... so the responses could be done as suggested, but without saying that it is at risk
23:06:51 <MarkusK_> ian: cutting off this discussion, can we go forward with the responses?
23:06:56 <bijan> I would oppose saying that the hooks are at risk. They aren't, at the moment
23:07:08 <MarkusK_> alan: I do not agree to do the responses now
23:07:25 <MarkusK_> ... the hook is not meant to be for arbitrary extensions!
23:07:45 <bijan> ? Its not meant for adding dl safe rules, yes
23:07:51 <bijan> But there are other nary predicates
23:07:56 <bijan> e.g., non linear equations
23:08:04 <MarkusK_> ian: but we can reply to TopQuadrand stating that it is not a bug but an extension point
23:08:10 <bijan> +1
23:08:35 <MarkusK_> ian: we are out of time
23:09:34 <bijan> I also note that we will, for certain, have new datatypes
23:09:38 <MarkusK_> -- End of session --
23:09:40 <bijan> Quantities are coming
23:12:43 <ewallace> Bye
23:12:56 <Zakim> -Evan_Wallace
23:14:00 <ewallace> Looking forward to Quantities
23:17:57 <Zakim> disconnecting the lone participant, MIT346, in SW_OWL(F2F)8:00AM
23:17:59 <Zakim> SW_OWL(F2F)8:00AM has ended
23:18:00 <Zakim> Attendees were MIT346, Christine, Evan_Wallace, Achille
23:26:53 <alanr> alanr has joined #owl
23:43:58 <IanH> IanH has joined #owl
23:48:29 <IanH_> IanH_ has joined #owl