08:20:43 RRSAgent has joined #rif 08:20:43 logging to http://www.w3.org/2008/02/21-rif-irc 08:21:26 Meeting: RIF FTF9 Feb 21 08:21:33 JeffP has joined #rif 08:21:36 Chair: Chris Welty and Christian de Sainte-Marie 08:21:46 Agenda: http://www.w3.org/2005/rules/wg/wiki/F2F9 08:21:52 Scribe: AxelPolleres 08:22:02 scribenick: AxelPolleres 08:22:52 christian: objective is finishing BLD 08:23:37 GaryHallmark has joined #rif 08:23:41 ... see agenda slides. 08:24:08 ... next objective (if time) Core, PRD. 08:24:35 ... agenda, see http://www.w3.org/2005/rules/wg/wiki/F2F9 08:27:21 Topic: Review of FLD+BLD reviews 08:29:57 ChrisW: we start wih Igor's FLD review. http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0048.html 08:31:25 Christian: XML serialization not present in the current draft. Do we want to publish without? 08:31:53 Harold: I can easily add a paragraph. 08:32:13 MichaelK: in the next draft it will be extended. 08:32:39 christian: maybe less critical, since we have XML in BLD. 08:32:56 ... but we may get back to this in the extensibility discussion. 08:33:34 Sandro: the FLD document is not the right place, since this is only about logic dialects. 08:34:00 s/place,/place for the discussion of the XML syntax/ 08:35:34 christian: comments on 2.0.2 alphabet ... done 08:35:57 ... 2.0.4 Sigantures ... done. 08:36:17 ... 2.0.5 ... done 08:36:50 JeffP has joined #rif 08:37:14 ... 2.0.6 Symbol Spaces: some discussion about why we don't support all XML schema types. 08:37:30 MichaelK: some discussion at last f2f with jos. 08:38:26 josb: we didn't discuss what "supports" means. the problem is that we haven't clear here what/how to extend the basic datatyes to the reader. 08:39:18 DaveReynolds has joined #rif 08:39:20 josb: suggest that we "support" all XML Schema types and "require" compliant engines to support a basic set. 08:40:15 sandro_ has joined #rif 08:40:18 sandro: (Can you type in your concern?) 08:41:27 Harold: How do we cross-reference to other W3C specs in general in general and in this case in XML Schema? 08:41:43 s/in XML/to XML/ 08:41:50 Uh oh, DaveReynolds.... 08:41:56 Zakim, this is RIF 08:41:56 sorry, sandro_, I do not see a conference named 'RIF' in progress or scheduled at this time 08:42:25 Dave: working on the phone line ... 08:42:26 zakim, room for 4? 08:42:27 ok, sandro_; conference Team_(rif)08:42Z scheduled with code 26631 (CONF1) for 60 minutes until 0942Z 08:42:39 DaveReynolds, us this one CONF1 for now. 08:43:13 we're dialing now. 08:43:13 Team_(rif)08:42Z has now started 08:43:20 +??P0 08:44:20 +??P1 08:44:37 Zakim, ??P1 is MeetingRoom 08:44:37 +MeetingRoom; got it 08:45:41 Jeff: Some datatypes such as duration, entity are not realy "RDF-friendly" 08:45:56 s/realy/really/ 08:46:56 ChrisW: How we came to our current list was that we wanted to suggest a core list for compliance and recommend support for all basic XML Schema types. 08:49:41 josb: general confusion types that "RIF supports" vs. " are required to be supported by inference engines" 08:50:03 Supporting an integer but not a decimal is vastly more likely! 08:50:51 MichaelK: e.g. an engine that doesn't understand integer, but decimal would be able to deal with integers. 08:51:25 q+ 08:52:53 ack DaveReynolds 08:52:58 christian: instead of making this subtle difference, would it be easier to define in geeneral that consuming engines translate datatypes in to their datatypes which have the same semantics? 08:53:36 dave: that's the implementers' business, has nothing to do with RIF compliance/compatibility 08:54:55 ... why should RIF in the spec separate what is in the engine and in the language. what is in the engine is irrelevant, if the engine has to take care of the translation. 08:55:07 (hope I got that more or less right, dave) 08:56:02 sandro: so if you support short and somebody adds 50000+50000 you are outside short, but not if you internally translate it to integer. 08:56:26 ... but if our error semantics is that it is undefined how you handle errors than it would be ok. 08:56:38 Dave: if we have builtins for testing types (isShort) then it will change the semantics. 08:57:23 MichaelK: maybe we should just delete the paragraph about what a RIF consumer engine is supposed to to about datatypes. 08:57:45 ... the idea to put it in was to simplify the job of implementers 08:58:29 josb: we don't really want to restrict the datatypes you are allowed to use, but we didn't want to impose all engine with the rif stamp to have to support all. 09:00:03 christian: want to keep the paragraph. 09:00:13 josb: also want to keep it. 09:00:49 MichaelK: RIF systems still have to support all the built-ins. 09:01:32 -1 to keeping paragraph, see my review 09:01:44 josb: the problem at the moment is the (editorial) use of the words supports, compliant, consuming, etc. needs to be clarified. 09:02:09 MiachelK: we could spell out subtypes. 09:04:00 christian: remove "compliant" but only distinguish "producing" and "consuming" engines. 09:04:44 michaelK: possibly break out datatypes in a separate document, at least keep the discussion on datatypes in one place... now scattered. 09:05:21 harold/michaelK: could be part of builtins document. 09:06:03 sandro/chrisw: Core document would make sense. 09:06:23 chrisw: paula was currently editor of builtins, but she is leaving the WG. 09:06:31 harold: I took over. 09:08:58 sandro: just say "RIF does not define semantics for xsd:Duration" 09:09:10 axel: what should now be part of core and what of extensibility? 09:09:34 PROPOSED: Move text on datatypes and symbol spaces to Core 09:09:45 What is Core? What happened to Arch? 09:10:16 PROPOSED: Move text on datatypes and symbol spaces to Core 09:10:21 Chris: What is Arch? (laugh) 09:11:03 Arch = Architecture, which was originally precisely were the menu of builtins, datatypes, core XML syntax etc were going to be defined :-) 09:11:09 s/were/where/ 09:11:28 (some discussions on how to resize font on projector... ;-) ) 09:12:21 chrisw: FLD covers a good part of what I understood was "arch" 09:12:33 ... can we extend it? 09:12:49 michaelK: easier to write something more specific. 09:13:05 csma: The reason to have datatypes and builtins in Core, not Arch, is because it's a specific thing that has to be implemented in every dialect. 09:13:05 chrisw: is there an active Core document. 09:13:18 axel: no, because we stil discuss what should be in there. 09:13:29 s/discuss/need to discuss/ 09:13:54 sandro: We need to clarify what core is actually gonna be. 09:14:39 sandro: (correction) We're getting a sense of what Core is actually going to be. BLD minus function terms, equality, and a few other things. 09:15:00 axel: What of datatypes are Core, and what are extensibility? 09:15:28 csma: The part of Datatypes that goes into Core is NOT the symbol spaces stuff (that's FLD), but the LIST OF DATATYPES goes into Core. 09:15:34 christian: definition od symbol spaces, datatypes in general belong to FLD. 09:15:51 Jos: but we don't want Core dependent on FLD! 09:16:03 ... core supported datatypes in Core. 09:16:15 RRSAgent, pointer? 09:16:15 See http://www.w3.org/2008/02/21-rif-irc#T09-16-15 09:17:46 MichaelK: nothing depends on FLD, we have XML datatypes, etc. 09:18:31 q? 09:18:33 christian: how does putting the list of datatypes in Core make core dependent on FLD. 09:19:10 ... and why is it a problem to depend on FLD, core IS a logic dialect. 09:20:20 Axel: in AnswerSet programming, they are thinking about an exchange format, I suggested they use RIF -- they said it was too complicated. 09:20:36 Chris: ACTION Axel! 09:20:52 Axel: Harold and I were thinking about it. 09:21:14 Axel: And it doesn't make sense to do it until the spec settles down. 09:21:46 Axel: This community knows their semantics, they want to see our XML syntax. 09:22:22 csma: This is like the PRD draft. They syntax is described so that people who already know their semantics can just use it. 09:22:42 csma; This is different from FLD. This is how you present the syntax of a specific dialect. 09:23:19 csma: The way the syntax is currently presented in BLD is probably a problem for the language developer, just trying to build a translator. 09:23:50 MichaelKifer: I suspect the AnswerSet critique refers to the old version of BLD that was much more complex. 09:24:22 hassan: the documents are still too dense, we need some introductory document(s) 09:24:45 sandro: not our job to explain it... others can write tutorials. 09:25:30 gary: testcases document would do a great part of that job already. 09:25:34 sandro: (it's okay for us to explain it -- but it's not a requirement on us.) 09:25:55 chrisw: it is more a question of bandwidth 09:26:18 michaelk: we definitly need an entry-point document. 09:26:26 testcases + XML content models of RIF + use cases showing examples 09:26:48 ... a tutorial (as planned by harold,axel,me) is separate from that. 09:27:18 adrian: add syntax to the use cases. 09:28:03 christian: the style of syntax presentation at the moment is not the style which developers are used to. 09:30:20 syntax can be writen as reference menu 09:30:50 like a glossary 09:31:34 The current syntax is not that precise, there are many boring details left out. A developer needs clearer presentation, with clearer and more comprehensive examples and test cases. 09:31:58 chrisw: what we are trying to achieve is a common serialization for classes of rule languages. 09:32:01 PRD style is more like a reference manual 09:32:26 ChrisW: BREAK 1/2 hour! 09:32:28 sandro has joined #rif 09:33:31 -DaveReynolds 09:47:01 disconnecting the lone participant, MeetingRoom, in Team_(rif)08:42Z 09:47:03 Team_(rif)08:42Z has ended 09:47:04 Attendees were DaveReynolds, MeetingRoom 10:04:17 DaveReynolds, tell us when you need us to call in again. 10:04:45 Scribe: GaryHallmark 10:04:53 ScribeNick: GaryHallmark 10:05:23 Topic: FLD/BLD reviews, continued 10:06:23 issue: RIF dialect can introduce new datatypes 10:07:22 spec should be clear that list of datatypes can be extended 10:07:38 chrisw: dialects must support AT LEAST the listed datatypes 10:08:39 csma: come back to this issue when discussing extensibility 10:09:16 chrisw: what is a closed rif formula (in entailment section 3.0.7)? 10:09:24 mk: no free vars 10:10:10 ... entailment defined when no free vars (or implicitly universally quantified) 10:11:25 in BLD it is an error to have free variables (there is a resolution about this) 10:11:59 "The free variables in the rule can be optionally quantified with Forall outside of the rule (i.e., Forall ?vars (head :- body)). " 10:12:01 but we can hardly restrict the BLD syntax not to contain free variables 10:14:26 trackbot-ng, list 10:14:29 action on mkifer to forbid free variables 10:14:30 ACTION: Michael to make sure that BLD requires explicit quantification 10:14:30 Sorry, amibiguous username (more than one match) - Michael 10:14:30 Try using a different identifier, such as family name or username (eg. mkifer, msintek, merdmann, uscholdm) 10:14:41 ACTION: Mkifer to make sure that BLD requires explicit quantification 10:14:41 Created ACTION-425 - Make sure that BLD requires explicit quantification [on Michael Kifer - due 2008-02-28]. 10:20:52 ACTION: Mkifer to list FLD datatype subtypes explicity 10:20:52 Created ACTION-426 - List FLD datatype subtypes explicity [on Michael Kifer - due 2008-02-28]. 10:22:43 rulesets should be explained earlier in spec because it is used to define scope of rif:local 10:24:31 ACTION: Mkifer to make sure "ruleset" is used consistently in FLD/BLD 10:24:31 Created ACTION-427 - Make sure \"ruleset\" is used consistently in FLD/BLD [on Michael Kifer - due 2008-02-28]. 10:26:26 define RIF-compliant processor 10:26:50 csma: define compliant consumer/producer 10:27:07 hassan: compliance is too strong a term 10:27:15 sandro: we do mean compliance 10:27:29 johnhall has joined #rif 10:27:42 csma: "inference engine" is out of scope of definition 10:28:05 sandro: need something specific like inference engine to define test cases 10:28:59 csma: should focus on translation, not processing 10:29:24 mkifer: compliance should go elsewhere 10:29:39 josb: define compliance at dialect level 10:30:05 mkifer: need to define generally what compliance means 10:30:36 ... but it seems out of place in FLD currently 10:31:27 mkifer: needs to be in Core 10:32:35 chrisw: realistically, will we have other docs? 10:33:32 current docs: FLD, BLD, SWC, UCR, PRD, (Core?). what else? 10:33:33 ... last call for BLD in 2-3 months 10:37:14 mkifer: move datatypes, builtins, and compliance to another doc 10:38:23 chrisw: symbol spaces stays in FLD 10:39:01 mkifer: can move symbol spaces too 10:40:13 PROPOSED: Create a new Document with provisional titles "Data Types and Builtins" 10:40:23 csma has joined #rif 10:40:26 PROPOSED: Create a new Document with provisional titles "Data Types and Builtins" 10:42:37 PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects 10:43:16 PROPOSED: Create a new Document with provisional title "RIF Vulgar" to contain elements common to all dialects 10:45:26 much discusson about possible title and content, including "RIF Core" (again!) 10:45:57 PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects 10:46:27 PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects with Harold and Axel as editors 10:46:28 Harold and Axel will edit the new document 10:47:20 RESOLVED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects with Harold and Axel as editors 10:48:15 action: axel to create DT&B document by Friday 10:48:15 Created ACTION-428 - Create DT&B document by Friday [on Axel Polleres - due 2008-02-28]. 10:48:49 action: mkifer to remove DT&B content from FLD 10:48:49 Created ACTION-429 - Remove DT&B content from FLD [on Michael Kifer - due 2008-02-28]. 10:52:46 mkifer: producer, consumer, etc. should be defined in a common place 10:54:33 ... also notion of dialects 10:56:21 ... overall processing model 10:56:58 ... need a guide (overview) of all the docs 10:57:19 csma: no time to create many new docs 10:58:53 harold: will we publish UCR? 10:59:03 sandro: can do last call on UCR 11:01:13 mkifer: I can write a 1 or 2 page overview (guide) 11:01:54 sandro: can take BLD to last call without overview info 11:02:37 ... sort of OK not to understand, as long as audience doesn't misunderstand 11:03:21 RIF Overview Document --- explaining why and how RIF is useful to people. 11:04:10 csma: "A Common XML Serialization for Rule Languages" 11:04:45 sandro: Yes, it would be very useful to have a document which technical people can be pointed to, to convince them why they should use RIF, and point them to the details they need. 11:05:27 ... sort of OK not to understand, as long as audience doesn't misunderstand 11:08:01 ...continuing with DaveR's review: primitive data types will be fixed with new resolution 11:09:22 No, but we can dial in DaveReynolds if you want. 11:09:26 GaryHallmark has joined #rif 11:09:29 zakim, room for 4? 11:09:31 ok, sandro; conference Team_(rif)11:09Z scheduled with code 26631 (CONF1) for 60 minutes until 1209Z 11:10:14 Team_(rif)11:09Z has now started 11:10:21 +??P0 11:11:36 +??P1 11:11:48 zakim, ??p1 is meeting_room 11:11:48 +meeting_room; got it 11:11:49 Zakim, ??P1 is MeetingRoom 11:11:50 I already had ??P1 as meeting_room, sandro 11:12:49 topic: BLD reviews 11:14:27 josb: need single defn of 11:14:33 ... BLD 11:15:44 csma: specialization of BLD from FLD should be appendix 11:16:29 mkifer: direct (standalone) spec should be normative 11:17:01 sandro: both can be normative 11:17:07 proposed: make "specialization of FLD" sections (of BLD) appendices 11:17:32 proposed: make "specialization of FLD" sections (of BLD) appendices, with both normative 11:19:43 proposed: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both normative 11:21:06 proposed: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both standalone and specialization normative 11:21:35 Axel: example -- many people use RDF non-normative rule-based semantics. 11:21:37 resolved: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both normative 11:21:49 correction --- 11:21:51 RESOLVED: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both standalone and specialization normative 11:22:10 csma: And that shows why they should both me normative, so if there is an error, it's the spec that is in error, not those folks and their implementation. 11:22:17 action: mkifer to move specialization sections to appendices 11:22:17 Created ACTION-430 - Move specialization sections to appendices [on Michael Kifer - due 2008-02-28]. 11:22:38 issue: xml syntax is too loosely specified 11:22:51 dave, didn't hear your input during that proposed resolution - did it address your comment??? 11:22:51 mkifer: what does loose mean? 11:23:22 Chris: yes, I was proposing the appendix/body be the other way round but the proposal is ok 11:23:22 josb: presentation to xml translation table too informal 11:23:38 csma: table is not enough 11:24:56 josb: 2 issues: want self-contained description of XML and want better translation table 11:25:15 csma: e.g. which elements are required, optional, etc. 11:25:47 mkifer: but xml schema appendix gives more info 11:26:04 csma: likes PRD style 11:26:43 EBNF is not "totally precise" !! 11:26:50 harold: ebnf is precise 11:28:36 daver: my comments critique the xml schema, too 11:30:03 Discussing http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0077.html 11:31:11 daver: most of my comments are relatively minor but are important to ensure interop 11:33:08 ... distinguish between IRIs and CURIes 11:34:30 daver: why equality in rule bodies in CORE? 11:34:48 mkifer: because it is easy if just in bodies 11:35:20 ... sugar for equal(?x ?x) 11:36:53 sandro: but what about classical negation and = ? 11:37:28 josb: datalog + classical negation => disjunctive datalog 11:37:30 Jos: IE disjunctive datalog. 11:39:38 MichaelKifer: you can define equal(?x,?x) 11:39:59 consensus is to remove equality from core to prevent problems with future extensions of core 11:40:30 if strong negation is only defined in the body you don't run into conflicts between positive and negative conclusions 11:40:51 csma: is this a real Resolution? 11:41:35 Just as it comes to my head: 11:41:47 do we want to allow unsafe rules in CORE? 11:43:40 mkifer: to prove not(equal(1,3)) you must have such a fact 11:43:46 unsafe = all variables in head must be bound by a (non-built-in) presicate in the body (if disjunction in the body additional care is needed) 11:43:55 s/unsafe/safe 11:44:30 -DaveReynolds 11:44:40 -meeting_room 11:44:41 Team_(rif)11:09Z has ended 11:44:42 Attendees were DaveReynolds, meeting_room 12:41:32 johnhall has joined #rif 12:45:23 mdean has joined #rif 12:47:13 is there a telecon dialin? Zakim didn't recognize RIFWG# 12:47:58 GaryHallmark has joined #rif 12:56:30 zakim, room for 4? 12:56:32 ok, sandro; conference Team_(rif)12:56Z scheduled with code 26631 (CONF1) for 60 minutes until 1356Z 12:56:51 Team_(rif)12:56Z has now started 12:56:58 +??P3 12:57:06 zakim, ??P3 is MeetingRoom 12:57:06 +MeetingRoom; got it 12:57:17 AxelPolleres has joined #rif 12:57:19 i'm here 12:57:25 I'm there 12:57:30 I'm not 12:57:46 josb has joined #rif 12:57:47 France makes us all existential 12:57:51 (by default) 12:57:59 mdean has joined #rif 12:58:07 mike, the code is 26631 12:59:26 mike, u there? 13:00:19 josb_ has joined #rif 13:05:01 mdean has joined #rif 13:05:11 Harold has joined #rif 13:06:20 Zakim, who is on the call? 13:06:20 On the phone I see MeetingRoom 13:06:35 mdean??? 13:07:59 csma has joined #rif 13:09:09 scribeNick: AdrianP 13:09:16 Topic: SWC 13:09:57 Jos: Explains the four different entailment regimes fro RDF integration 13:10:29 Jos: Explains difference of OWL DL and OWL Full compatibility in RIF 13:10:48 jos: OWL Full a[subckass->b] OWL DL: all b(x) :- a(x) 13:11:38 jos: So we read things with a special semantics. a[rdf:type->b] : b(a) 13:11:55 Jos: and a[p->b] : p(a,b) 13:12:20 Jos: a [p -> b]: p(a,b) 13:12:27 Jos: p might be a variable 13:12:50 Jos: Syntactically in blf frames, p could be variable. 13:12:55 s/blf/bld/ 13:13:46 zakim, who is on the phone? 13:13:46 On the phone I see MeetingRoom 13:13:54 Harold has joined #rif 13:14:06 Jos: interpretation of frames for the OWL Full compatibility workaround solution is different from the interpration in RIF FLD 13:15:26 Jos: a[p->b] <-> a[q->b] 13:15:45 Jos: i.e. q equivalent to p 13:17:14 Sandor: distinguish the different interpretations of frames in RIF FLD and OWL compatibility also syntactically 13:17:37 Jos: RDFS: a sc b 13:17:55 Jos: RIF d [type -> a] 13:18:18 Jos: q[q->d] <- x [type -> b] 13:18:38 Jos: OWL DL: you can not use this rules anymore 13:19:49 + +1.617.873.aaaa 13:20:23 zakim, aaaa is mdean 13:20:23 +mdean; got it 13:20:40 Zakim, who is on the phone? 13:20:40 On the phone I see MeetingRoom, mdean 13:21:30 Jos: In general frame syntax is incompatble from predicate syntax 13:21:50 Sandro: Expressions from OWL DL could be translated into both syntaxes 13:22:35 Sandro: How can you read it differently? 13:22:47 Jos: It is defined in the semantics 13:22:58 sandro: We need something more concrete 13:23:48 Jos: I |= a[type -> b] if I |= b(a) 13:24:00 Sandro: How can this processed in the software 13:24:45 Jos: I imagine that somewhere in the rule set it is made explicitly 13:25:34 Jeff: Why do we need to worry about rewriting a particular OWL statement 13:25:46 Jos: We don't rewrite 13:27:21 Jos: In RDFS the syntax can be frames 13:27:42 Jos: But in OWL DL they are classes 13:28:29 Jos: We want to use the same syntax for both 13:30:04 Jos: Use frame syntax as unifier 13:30:11 Jeff: but you change the semantics 13:30:38 Jeff: if you want to use different ontologies you will change the semantics 13:32:13 Sandro: So, I'm satisfied with Jos' explanation of why we need the two syntaxes and how they relate, but I think the document is going to [somehow] have to be a lot clearer here. 13:32:21 Jos: Yeah. 13:32:59 zakim, who is on the call? 13:32:59 On the phone I see MeetingRoom, mdean 13:33:38 Harold: we can use different way to write it syntactically 13:34:01 Adrian: if we are only talking about instance and subcalls we can use a typed logic syntax 13:34:49 ChrisW: the choices are binary predicate syntax or frames 13:34:51 Chris: For a user, there's an awkward choice between using frame vs predicate syntax. There's no real guidance as to whether to chose one over the other. 13:35:12 Jos: then use onyl frames with different semantic interpretation 13:35:30 Sandro: (joking) it'll be easy -- frames will be slower 13:35:44 MichaelKifer: (taking it serously) not with good indexing 13:36:04 GaryHallmark: (also seriously) Java impls may just use the VM to do it, and be faster than predicates. 13:36:51 s/subcalls/subclass 13:37:48 Jos: BLD: I |= a[b->c] if in Iframe (bI) 13:38:18 Jos: That is the semantics of BLD 13:38:32 Mikeal: Yes, it captures the meaning 13:39:10 s/Mikeal/Michael 13:41:24 Jeff: I'm in favor of a syntactical destinction instead of a different semantic interpretation of frames when using OWL DL 13:41:40 Michael: The problem is with extensions 13:42:15 Chris: What about just having this modified frame semantics in BLD? [[that's where MK said problem with extensions]] 13:44:13 MichaelKifer: we put predicates out of the domain, to be precisely like first-order-logic (even though it would be first order, anyway) 13:44:20 Michael: We wanted to stay close to first order 13:46:33 Michael: We need an explanation of frames in the OWL compatibiltiy section 13:46:50 Sandro: RIF FAQ #4: Why do you have Frames and Predicates, and why aren't they equivalent? 13:48:38 Jos: example with domain of size one. in OWL DL, it's not true that all classes are now the same. 13:50:03 Jeff: Let the users define which sort of semantics they would like to go for 13:50:37 Jeff, do I interpret you right, you said: Everything is fine except ... OWL DL? ;) 13:50:47 Jeff: There is only one semantics for OWL DL 13:51:11 ChrisW: no and OWL DL ontology can be also interpreted with OWL Full semantics 13:51:12 Chris/Jos: OWL DL has this implicit choice (are you using OWL DL or OWL Full semantics), and that carries through to RIF, when you use RIF+OWL. 13:51:34 Jess: You can specify the semantics by an additional attribute 13:51:43 s/Jess/Jeff 13:51:43 s/Jess/Jeff 13:51:47 :-) 13:52:20 Jos: Semantics is defined for the combinations 13:52:43 Jos: RIF-OWL Full; RIF-OWL DL 13:53:32 Chris: You choose by using a tool 13:53:50 Chris: You get potential different results depending which reasoner you use 13:54:35 my other meeting is about to start - i'll try to call in again tomorrow - thanks! 13:54:38 Hassan: Think of Datalog and Prolog interpreters 13:54:48 bye Mike 13:55:09 -mdean 13:55:11 Sandro: We can not solve this problems between OWL DL and OWL Full in our group 13:55:32 Chris: Next step? 13:55:36 Sandro: ... but the difference in entailments is, in practice, unimportant. 13:56:05 Jos: wether and how do we point to RDF graphs 13:56:12 Jos: which entailment regime to use 13:56:56 Axel: define imports of RDF data by using owl:import 13:57:19 Axel: option: define an RDF thing like owl:imports for importing a ruleset from inside RDF. 13:58:32 reviews to RDF/OWL compatibility documents 13:59:13 Zakim, what is the code? 13:59:13 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), sandro 14:01:01 disconnecting the lone participant, MeetingRoom, in Team_(rif)12:56Z 14:01:03 Team_(rif)12:56Z has ended 14:01:05 Attendees were MeetingRoom, +1.617.873.aaaa, mdean 14:04:06