00:00:23 Changhai: in foo # X X is a type, not a collection.... 00:04:28 Sandro: Is this work necessary to PRD? 00:04:56 Paul: Yes, althoug maybe we need even better access to XML (than frames allow). 00:06:15 Gary:My proposal is pretty much how our product works (jaxb style -- flash conversion). The XPath peek & poke approach would be something we'd have to hide in translation. 00:07:15 Gary: I'm not wedded to using the schema to construct names. JAXB just uses the local names. 00:07:18 ChrisW has joined #rif 00:08:01 sandro: If RIF doesn't do this, you'll need to do a non-standard version of this? 00:08:10 csma, paul, gary: yes. 00:08:51 paul: PRR dodges this issue. 00:09:09 Adrian: reaction-ruleml has a way to do something like this. 00:10:12 csma: You could re-use this work with UML instead of Schema. 00:11:18 "Using RIF with XML and Object-Oriented Data" ? 00:11:34 csma: I think we'll be content with just "Using RIF with XML" 00:13:55 additionally in a query /constraint expression language you could explicitly define closures over object relations which can not be done directly in FOL 00:14:58 csma: If you want to *really* retrieve a class and it's subclasses, you need to do it several different ways, given XMLS. 00:15:45 Way ahead suggestion: have 1 or more DSLs evaluate these approaches for embedding XML-enabled PRD in their docs, eg MISMO? 00:19:58 PROPOSED: Create a new document, something like "Using RIF with OWL", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF. 00:20:15 gah. typo of "OWL" for "XML" :-) 00:20:17 StellaMitchell has joined #rif 00:20:39 PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF. 00:20:42 zakim, who is here? 00:20:42 On the phone I see RIF_Meeting_Room, Hassan_Ait-Kaci (muted) 00:20:43 RIF_Meeting_Room has Christian, Gary, Harold, Adrian, Jos, Paul, Micheal_Kifer, Changhai, Sandro 00:20:46 On IRC I see StellaMitchell, ChrisW, Hassan, csma, PaulVincent, josb, GaryHallmark, Michael_Kifer, cke, Harold, RRSAgent, AdrianP, sandro, mdean, trackbot, Zakim 00:21:53 csma: it's important that whatever we do relies on features in current engines. and be extensible for doing stuff like more of XPath in the future. 00:21:55 +Stella_Mitchell 00:22:13 PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF. 00:23:00 i haven't been part of the discussion 00:23:12 but i would strongly object to starting new work 00:23:25 PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF. This technology is not just for use of XML data, but for using XML Schemas to communicate data models. 00:24:04 ChrisW, Gary, Paul, and the ILOG (and IBM company) folks say they have to have this for PRD to be useful. 00:24:14 s/,/-/ 00:24:59 I've heard the same argument for a lot of things in RIF 00:25:49 The alternative to starting a new doc is including it in PRD. 00:26:22 since this is useful to other dialects as well, better put it in a separate doc instead of a PRD section 00:26:58 finish the work on PRD first, then consider this for a note. But only when the existing drafts are at LC 00:27:14 no new work 00:27:18 i repeat, no new work 00:27:19 sandro: I think the risk of new-work is somewhat reduced buy having it be an independent document. 00:27:40 Also look into related work such as Schema-Aware Queries and Stylesheets (http://www.stylusstudio.com/schema_aware.html) and Schema-aware processing with XSLT (http://www.ibm.com/developerworks/xml/library/x-schemaxslt.html). 00:27:56 this has too many other implications 00:28:05 i will object 00:30:53 sandro: We could publish a VERY DRAFT WD on this, which is just the cut and paste of Gary's and CSMA's proposals, to [as csma says] let people know this kind of work is doable, so they know PRD might be useful. 00:31:41 gary: In our product, we tried an xpath thing, but ended up putting the whole document in, because it worked better for what customers wanted. 00:33:08 csma: I want to borrow XPath. 00:34:42 gary: RIF CL is already a query language, so it's kind of painful to combine it with another, like XPath. 00:34:44 csma: true. 00:34:52 BREAK until 17:00 00:35:16 -Stella_Mitchell 00:37:31 -Hassan_Ait-Kaci 01:05:02 scribenick: Michael_Kifer 01:05:12 restarting 01:06:41 CSMA: issue: forall is different in BLD and PRD 01:06:57 csma: Forall means something different in PRD from Core. It means "for each value that you can bind" ... which has the same effect. But PRD also needs the real forall...? 01:10:28 sandro: (listening to Changhai's example) You want an aggregate. if forall x... 01:10:43 +Stella_Mitchell 01:13:41 sandro: so this, in practice, needs closed world assumption, 01:13:45 jos: or negation 01:14:46 gary: we have this now in PRD via "not exists". 01:16:05 the issue seems to be "forall" outside of the rule vs. "forall" in the rule body 01:16:27 paul: "if at least 3..." 01:17:11 csma: So the forall inside the rule and outside the rule are really the same? 01:17:20 Michael_Kifer: Yes 01:17:25 Jos: Yes 01:22:05 decided that this is a non-issue 01:22:06 BLD's Forall can work over infinite sets such as {0, s(0), s(s(0)), . . .}: 01:22:11 Forall ?N ( nat(s(?N)) :- nat(?N) ) 01:22:40 Next topic, please! 01:23:01 csma: on board: 01:23:01 forall ?x ( ?x # Car) 01:23:01 if forall ?y ( ?y # Door ) 01:23:01 ?x[door->?y] and ?y[color->red] 01:23:01 then Paint It Blue 01:23:23 (all agree, the two forall as "the same", and can use the same syntax.) 01:23:52 (if the language were to support forall inside a condition.) 01:23:54 Next: issue 39, RIF should support import or inclusion of rulesets 01:23:56 http://www.w3.org/2005/rules/wg/track/issues/39 01:27:10 import is in core already. CSMA: might cause conflicts in conflict resolution strategies 01:29:06 agreed: if PRD imports with a different Res.Strat. it should ... say what happens. (one rules, or error, or something.) 01:29:20 proposed: close issue 39 01:29:33 PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time. 01:29:44 because core already has import 01:29:46 +1 01:30:12 +1 01:30:43 Michael_Kifer: i'd like includes would be including rules, not whole documents.... 01:31:05 PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 01:31:12 +1 01:31:17 ++1 01:31:27 +1 01:31:28 +++1 01:36:42 Sandro: it sounds like Core:imports wont be a pain to implement in PRD, even though it doesn't do all the fance stuff some PRD engines really want in imports. 01:38:00 csma: Import is specified in the dumb way -- without juggling priorities -- so it's not very useful in PRD. 01:38:45 +Hassan_Ait-Kaci 01:39:11 gary: Yeah, someday we'll need to specify complex ways to do import in PRD. 01:40:03 current import mechanism is too primitive for PRD. Need to expand it in the future for PRD 01:41:10 RESOLVED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). It ends up in PRD, where it's not ideal, but not really harmful. Some PRD may do a more sophisticated import at some point. 01:41:13 csma: the current import mechanism in core is acceptable, but it is not very interesting for prd. 01:41:37 s/RESOLVED/PROPOSED/ 01:42:24 PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 'Imports' ends up in PRD, where it's not ideal, but not really harmful. Some version of PRD may do a more sophisticated import at some point. 01:42:35 +1 01:42:57 Harold: when you find the better imports, propose it to the rest of RIF! 01:43:08 +1 01:43:15 +1 01:43:16 +1 01:43:16 +1 01:43:17 +1 01:43:26 +1 01:43:55 RESOLVED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 'Imports' ends up in PRD, where it's not ideal, but not really harmful. Some version of PRD may do a more sophisticated import at some point. 01:44:04 RRSAgent, pointer? 01:44:04 See http://www.w3.org/2009/01/15-rif-irc#T01-44-04 01:45:04 cke has joined #rif 01:47:00 cke has joined #rif 01:50:45 Sandro: let's put "filters" ("such that" expressions) as syntactic sugar into Core. 01:51:02 MK: bounded quantifies. 01:51:03 good idea 01:51:08 Let's not. The syntax is already complicated enough 01:52:29 Sandro: So, if we have to do a LC2 -- then we can talk about this. 01:54:19 ISSUE: Should we put bounded quantifiers into Core? (forall x such than x # C ...) (esp if we need an LC2 for BLD anyway) 01:54:32 Created ISSUE-91 - Should we put bounded quantifiers into Core? (forall x such than x # C ...) (esp if we need an LC2 for BLD anyway) ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/91/edit . 01:58:03 MK: bounded quants are not very useful in BLD, and the re-writing is a little tricky. 01:58:52 csma: Many rules are written with BQs, and people don't want to discard that optimization. Also, you need BQs for any else-clause. 01:59:28 -Stella_Mitchell 01:59:41 Forall ?X in C (h :- body) is Forall ?X (h :- body and C). 02:01:50 ADJOURN - 1 minute late 02:02:42 http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=higgins+portland&sll=37.0625,-95.677068&sspn=34.945679,58.886719&ie=UTF8&ll=45.51541,-122.680957&spn=0.001887,0.003594&z=18&iwloc=A 02:04:11 http://maps.google.com/maps?f=d&source=s_d&saddr=SW+5th+Ave&daddr=1239+SW+Broadway,+Portland,+OR+97205+(Higgins+Restaurant)&hl=en&geocode=FYaBtgId7w6w-A%3B&mra=cc&dirflg=w&sll=45.515407,-122.680786&sspn=0.001887,0.003594&ie=UTF8&z=18 02:06:48 coffee: http://maps.google.com/maps?f=d&source=s_d&saddr=45.515221,-122.679648&daddr=128+SW+3rd+Ave,+Portland,+OR+97204+(Stumptown+Coffee+Roasters)&hl=en&geocode=&mra=mi&mrsp=0&sz=15&dirflg=w&sll=45.518045,-122.676859&sspn=0.015095,0.028753&ie=UTF8&z=15 02:08:32 -Hassan_Ait-Kaci 02:09:31 -RIF_Meeting_Room 02:09:32 zakim, who is on the phone? 02:09:33 SW_RIF(F2F12)11:00AM has ended 02:09:35 Attendees were Mike_Dean, Hassan_Ait-Kaci, Christian, Gary, Harold, Adrian, Jos, Paul, Micheal_Kifer, Changhai, Sandro, Stella, +44.145.441.aaaa, DaveReynolds, +1.212.781.aabb, 02:09:39 ... LeoraMorgenstern, StellaMitchell, ChrisW, Stella_Mitchell 02:09:41 apparently SW_RIF(F2F12)11:00AM has ended, sandro 02:09:42 On IRC I see cke, ChrisW, Hassan, csma, josb, GaryHallmark, Michael_Kifer, Harold, RRSAgent, sandro, mdean, trackbot, Zakim 02:15:06 rrsagent, make record public 02:15:11 rrsagent, make minutes 02:15:11 I have made the request to generate http://www.w3.org/2009/01/15-rif-minutes.html sandro 02:47:49 sandro has joined #rif 02:57:18 sandro has joined #rif 19:04:54 RRSAgent has joined #rif 19:04:54 logging to http://www.w3.org/2009/01/15-rif-irc 19:05:03 RRSAgent, make minutes 19:05:03 I have made the request to generate http://www.w3.org/2009/01/15-rif-minutes.html sandro 19:05:42 pointer? 19:05:47 RRSAgent, pointer? 19:05:47 See http://www.w3.org/2009/01/15-rif-irc#T19-05-47 19:34:25 zakim, who is on the call? 19:34:25 On the phone I see RIF_Meeting_Room 19:34:34 RESTARTING 19:34:54 josb has joined #rif 19:35:58 scribenick: cke 19:36:12 issue-48? 19:36:12 ISSUE-48 -- Classification constructs in Core [NOT CP] -- OPEN 19:36:12 http://www.w3.org/2005/rules/wg/track/issues/48 19:36:16 apaschke has joined #rif 19:37:53 DaveReynolds has joined #rif 19:39:16 +DaveReynolds 19:39:24 Membership means: object # classname, where classname is a name of a class (correction of yesterday) 19:42:27 PROPOSED: Have # and ## in Conditions and Facts in Core. 19:43:12 -1 19:43:19 -1 19:43:25 +1 19:43:32 +1 19:43:48 DaveReynolds: I have two problems with these 19:44:12 DaveReynolds: I'd like to be able to assert these as well -- the restrictions are awkward. 19:45:00 DaveReynolds: ## is a problem because it's different from rdfs:subClassOf. I didn't object when ## went into BLD like this, because it was said it wouldn't be in core. 19:45:25 +1 to Dave as subclass tests not that interesting to PR engines... 19:45:40 DaveReynolds: I could live with # in Conditions and Facts in Core. (we already decided this.) 19:46:25 mk: What does PRD do about an rdfs:subClassOf appearing in the head of a rule? 19:47:10 Jos: as we said earlier, there's no interop between PRD and RDFS. 19:49:14 sandro: PRD's notion of classes and RDF's notion of classes will just be independent. Oh well, that's how it is. 19:51:25 PROPOSED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core. 19:51:46 Jos: Take # out of core because it's redundant with rdf:type 19:52:53 Jos - could you talk closer to a mike? 19:53:17 Jos: agree with Dave that subclass is not the same as in RDFS 19:55:11 Sandro: I'd like # and ## in core, with ## fixed to align with rdfs:subClassOf. 19:55:56 ## == subclassof and not equivalent class 19:56:04 PROPOSED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core. 19:56:11 +0 19:56:13 0 19:56:17 +1 19:56:20 +1 19:56:21 +1 19:56:21 +1 19:56:26 0 19:56:33 0 19:56:52 +??P1 19:56:54 0 19:57:55 -??P1 19:58:00 RESOLVED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core. 19:58:06 RRSAgent, pointer? 19:58:06 See http://www.w3.org/2009/01/15-rif-irc#T19-58-06 19:58:41 issue-68? 19:58:41 ISSUE-68 -- Named argument UNITERM in CORE? -- OPEN 19:58:41 http://www.w3.org/2005/rules/wg/track/issues/68 19:59:45 PROPOSED: close issue-68 with no Named-Argument Uniterms (NAU) in Core or PRD. 19:59:53 +1 19:59:56 +1 20:00:03 +1 20:00:05 0 20:01:55 I'd like to put this on the list of things to take out of BLD. 20:02:26 +1 20:02:28 0 20:03:28 0 20:03:38 0 20:03:38 RESOLVED: close issue-68 with no Named-Argument Uniterms (NAU) in Core or PRD. 20:03:41 RRSAgent, pointer? 20:03:41 See http://www.w3.org/2009/01/15-rif-irc#T20-03-41 20:03:49 action: csma remove NAU from PRD 20:03:50 Created ACTION-691 - Remove NAU from PRD [on Christian de Sainte Marie - due 2009-01-22]. 20:04:09 issue-72? 20:04:09 ISSUE-72 -- Should Core support some approximation to skolem functions? -- OPEN 20:04:09 http://www.w3.org/2005/rules/wg/track/issues/72 20:04:22 http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0245.html 20:04:37 (above link shows CLIPS example with NAU) 20:06:13 PROPOSED: Close issue-72 saying "No". (Nothing like skolem functions in Core.) 20:06:43 DaveReynolds: not happy, but I wouldnt object. 20:08:39 PROPOSED: Close issue-72 saying "No". (Nothing like skolem functions in Core.) We regret we were unable to find a good design to address this need. 20:09:32 gary: challenges with making it deterministic -- eg two new objects when rule fires twice. 20:09:59 gary: it didn't seem possible to solve in the general PRD case. 20:10:14 +0 20:10:19 PROPOSED: Close issue-72 saying "No" (Option D). (Nothing like skolem functions in Core.) We regret we were unable to find a good design to address this need. 20:10:20 0 20:10:26 0 20:10:29 0 20:10:32 0 20:10:33 1 20:10:35 +1 20:10:39 +0 20:10:39 1 20:10:43 0 20:10:51 RESOLVED: Close issue-72 saying "No" (Option D). (Nothing like skolem functions in Core.) We regret we were unable to find a good design to address this need. 20:10:55 RRSAgent, pointer? 20:10:55 See http://www.w3.org/2009/01/15-rif-irc#T20-10-55 20:11:29 issue-33? 20:11:29 ISSUE-33 -- Specification of data sources in RIF [NOT CP] -- OPEN 20:11:29 http://www.w3.org/2005/rules/wg/track/issues/33 20:11:34 with respect to named arguments in PRD, CLIPS has named arguments. Did we check with all the decendants of CLIPS, e.g. ECLiPSe, Haley Eclipse, FuzzyCLIPS, Jess, DR-Device, ... 20:13:00 PROPOSED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources will be sufficient. 20:13:31 +1 20:13:32 +1 20:13:33 Harold, Adrian - the CLIPS facts are not NAUs normally, you can pattern match on a subset of the arguments 20:13:46 PROPOSED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources, and using external builtins, will be sufficient. 20:13:55 +1 20:14:01 +1 20:14:07 1 20:14:09 +1 20:14:13 0 20:14:17 +1 20:14:27 +1 20:14:38 RESOLVED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources, and using externals, will be sufficient. 20:14:41 +1 20:14:41 RRSAgent, pointer? 20:14:41 See http://www.w3.org/2009/01/15-rif-irc#T20-14-41-1 20:15:12 issue-78? 20:15:13 ISSUE-78 -- Which to make external: ATOMIC, ATOM, or ATOM|FRAME -- OPEN 20:15:13 http://www.w3.org/2005/rules/wg/track/issues/78 20:16:24 http://www.w3.org/2005/rules/wiki/BLD#Formulas 20:16:48 csma: currently -- BLD externals can be position or na term, or a frame. later (frame) at risk. 20:17:04 csma: issue was raised because I didn;t know what an external frame was. 20:17:48 sandro: example? 20:19:55 sandro: (with help from jos) if you think of frames as a single ternary predicate, external frames are just consulting a single external ternary predicate (not related to normal frames). 20:20:18 csma: any frame can be external 20:20:36 mk: yes. it was just an oversight. #, ##, and = should be external-able. 20:20:56 mk: some kinds of = are builtin. 20:20:56 The problem is that the current external mechanism doesn't have a way to communicate which external source to consult. Especially for frames this is a problem. 20:21:34 mk: another oversight -- there should be an IRI provided for the external from, to identify the source. we don't have any place to give that. 20:21:44 csma: that's in the defn't of the external. 20:22:59 mk: when you get an RIF document, with an external frame, there should be some IRI identifying which source for external frames. 20:25:03 sandro: don't have anything external except for predicates and functions. If you want your own #, then give it your own URI name. 20:26:35 PROPOSED: The only Externals in BLD will be Predicates and Functions. No external frames, no external equality, etc. 20:27:07 PROPOSED: The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc. 20:27:11 +1 20:27:18 +1 20:27:32 PROPOSED: Close issue-78. The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc. 20:27:41 +1 20:27:46 0 20:27:47 +1 20:27:58 0 20:28:26 RESOLVED: Close issue-78. The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc. 20:28:29 RRSAgent, pointer? 20:28:29 See http://www.w3.org/2009/01/15-rif-irc#T20-28-29 20:29:28 BREAK FOR LUNCH 20:29:34 issue-48? 20:29:34 ISSUE-48 -- Classification constructs in Core [NOT CP] -- CLOSED 20:29:34 http://www.w3.org/2005/rules/wg/track/issues/48 20:29:40 issue-68? 20:29:40 ISSUE-68 -- Named argument UNITERM in CORE? -- CLOSED 20:29:40 http://www.w3.org/2005/rules/wg/track/issues/68 20:29:44 -DaveReynolds 20:29:52 issue-72? 20:29:52 ISSUE-72 -- Should Core support some approximation to skolem functions? -- CLOSED 20:29:52 http://www.w3.org/2005/rules/wg/track/issues/72 20:29:56 issue-33? 20:29:56 ISSUE-33 -- Specification of data sources in RIF [NOT CP] -- CLOSED 20:29:56 http://www.w3.org/2005/rules/wg/track/issues/33 20:30:00 issue-78? 20:30:01 ISSUE-78 -- Which to make external: ATOMIC, ATOM, or ATOM|FRAME -- CLOSED 20:30:04 http://www.w3.org/2005/rules/wg/track/issues/78 20:30:21 We restart at 13:30. 20:32:10 issue-46? 20:32:10 ISSUE-46 -- Modules in RIF [NOT CP] -- OPEN 20:32:10 http://www.w3.org/2005/rules/wg/track/issues/46 21:37:22 josb has joined #rif 21:38:01 http://www.econ.kuleuven.be/eng/fetew/medewerker/Userpage.aspx?PID=271 21:41:51 chke has joined #rif 21:41:56 issue-69? 21:41:56 ISSUE-69 -- Should there be a Core schema incldued in BLD and PRD schemata? -- OPEN 21:41:56 http://www.w3.org/2005/rules/wg/track/issues/69 21:42:17 scribenick: gary 21:42:35 +DaveReynolds 21:42:38 -RIF_Meeting_Room 21:42:39 +RIF_Meeting_Room 21:43:24 harold: specialize bld schema to arrive at core schema 21:43:37 ... should look at how to inherit core into bld 21:44:07 harold: easiest thing to do is copy BLD schema for Core, then edit it to constrain it more. then maybe look at where we can use include. 21:44:17 ... inherit means xml include 21:44:34 AdrianP has joined #rif 21:45:10 sandro: include is just an editorial change 21:46:34 sandro: who will do the modularization exercise? 21:46:59 harold: will help changhai 21:47:08 ACTION: changhai to draft modularized Core and PRD schema, coordinating with Harold on BLD Schema 21:47:08 Created ACTION-692 - Draft modularized Core and PRD schema, coordinating with Harold on BLD Schema [on Changhai Ke - due 2009-01-22]. 21:48:50 In http://www.w3.org/2005/rules/wiki/BLD#Rule_Language we have . 21:49:17 changhai: work toward a core schema and BLD and PRD schemas that include the core schema 21:49:24 Harold - is the Core schema online or on the wiki somewhere? 21:49:47 A Core schema doesn't exist yet. 21:49:53 PROPOSED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692. 21:49:59 Sorry misheard, your audio is very quiet 21:50:09 zakim, who is on the phone? 21:50:09 On the phone I see RIF_Meeting_Room, DaveReynolds 21:50:35 :-) 21:50:44 proooooojeeeeeect 21:51:08 PROPOSED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692. 21:51:25 +1 21:51:36 +1 21:51:37 +1 21:51:38 +1 21:51:39 +1 21:52:00 +1 21:52:03 1 21:52:05 +1 21:52:10 RESOLVED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692. 21:52:29 rrsagent, pointer? 21:52:29 See http://www.w3.org/2009/01/15-rif-irc#T21-52-29 21:54:24 issue-46? 21:54:24 ISSUE-46 -- Modules in RIF [NOT CP] -- OPEN 21:54:24 http://www.w3.org/2005/rules/wg/track/issues/46 21:55:53 PROPOSED: Close issue-46; no decision to make at this time. If someone produces a proposal for modules, we may consider it. 21:56:09 +1 21:56:20 +1 21:56:20 +1 21:56:26 +1 21:56:27 +1 21:56:33 +1 21:56:38 +1 21:56:40 RESOLVED: Close issue-46; no decision to make at this time. If someone produces a proposal for modules, we may consider it. 21:56:45 RRSAgent, pointer? 21:56:45 See http://www.w3.org/2009/01/15-rif-irc#T21-56-45 21:57:43 issue-50? 21:57:43 ISSUE-50 -- Semantic metadata -- OPEN 21:57:43 http://www.w3.org/2005/rules/wg/track/issues/50 21:58:04 +[IPcaller] 21:58:41 issue-80? 21:58:41 ISSUE-80 -- Shoudl we extend DTB to include more general builtins -- OPEN 21:58:41 http://www.w3.org/2005/rules/wg/track/issues/80 21:59:41 Axel: unfort. my keyboard is broken. so I cannot type on IRC. :-( 22:00:08 -[IPcaller] 22:01:02 RESOLVED: add isLiteralOfType and isLiteralNotOfType (Changing guards to return true only for literals that are/are not of the type, false for non-literals) and remove specific type-named guards (e.g. isInteger, isNotInteger). Closing ISSUE-79 and the membership/non-membership part of ISSUE-80. 22:04:31 +??P4 22:04:51 Gary: can we just have a "type" for everything that's not a literal? 22:06:05 Sandro, Gary, negation would become a problem, i.e., isNotObject is a problem; isObject would not be a problem, I think 22:07:15 isNotObject=isLiteral, so should actually not be a problem 22:07:19 jos: maybe yes we could do "isObject". 22:07:35 -??P4 22:07:52 something like isType(?X, Object) 22:08:08 isType(?X, Integer) 22:08:49 Jos: "object" in owl is owl:Thiing 22:09:37 sandro: obviously isLiteralofTtyype, etc, are clumsy and something more elegant would be great. 22:10:05 sandro: what about isObject, isLiteral 22:10:30 jos: isLiteral 22:10:39 We put the isLiteral part in notType as part of resolving the negative guards, the isLiteral part of ofType is just there for symmetry 22:11:14 sandro: need to cover unknown datatypes 22:11:46 dave: needed neg guards for owl RL 22:12:31 isLiteralNotInteger(x) :- isLiteral and (isDouble and isFloat ....) 22:12:36 isLiteralNotInteger(x) :- isLiteral and (isDouble or isFloat ....) 22:12:46 jos: instead of neg guards, enumerate, e.g. isNotInt == isDouble or isString or ... 22:13:19 ... can't cover because value spaces not disjoint 22:14:27 issue-81? 22:14:27 ISSUE-81 -- Support for additional OWL-RL datatype -- OPEN 22:14:27 http://www.w3.org/2005/rules/wg/track/issues/81 22:15:53 sandro: separate owl: and xsd: types 22:16:59 ... rationale for xsd: is completeness. for owl:, ability to use RIF to implement owl RL 22:17:50 jos: possible issue with lex spaces not disjoint 22:18:57 DaveReynolds: problem with binary types is: what builtins should we have? some work there? 22:19:57 the set of additional XPath functions is small: http://www.w3.org/TR/xpath-functions/ 22:20:51 If you are talking about numerics now then see http://lists.w3.org/Archives/Public/public-rif-wg/2009Jan/0017.html 22:21:06 sandro: I expect users are going to want promotion 22:26:17 what if we do type promotion, even with non-disjoint value spaces? 22:28:01 dave: if value space is not disjoint, then you can't dispatch on the type of the inputs to builtins (like numeric-add) so it makes type promotion tricky (roughly paraphrased by scribe) 22:30:29 dave: (adding to Gary's paraphrase) further in XPath you would promote to double, whereas for the OWL approach you would promote to BigDecimal and so do arbitrary precision arithmetic a lot of the time 22:32:21 LeoraMorgenstern has joined #rif 22:32:29 jos: will try to convince owl that disjointness is a good thing 22:32:54 +LeoraMorgenstern 22:33:02 dave: owl has no builtins, so they don't have our motivation 22:33:26 sandro: may need formal objection 22:33:29 our main argument we can give OWL is extensibility 22:38:06 sandro: XSD is so broken. :-) hexBinary and base64Binary both have identically described value spaces, but they are also defined as being disjoint. 22:38:54 http://www.w3.org/TR/xmlschema11-2/#order 22:39:03 "For purposes of this specification, the value spaces of primitive datatypes are disjoint, even in cases where the abstractions they represent might be thought of as having values in common." 22:39:29 Sandro, I agree; the spec is broken 22:40:31 also: http://www.w3.org/TR/xmlschema-2/#equal 22:40:38 "# the ·value space·s of all ·primitive· datatypes are disjoint (they do not share any values) " 22:43:54 StellaMitchell has joined #rif 22:44:03 Changhai: use case for xsd:hasBinary is including an encrypted password. 22:44:11 s/has/hex/ 22:45:27 base64binary looks like to be the way to convert binary information into printable characters. This is required for storing passwords, for example. 22:45:27 PROPOSED: Include all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately. 22:45:47 PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately. 22:45:55 Does that include the string subtypes? 22:46:15 PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. 22:47:15 PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. In RIF, the xsd numeric types will have disjoint value spaces -- we'll push for OWL to change. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. 22:47:27 Does that include the string subtypes? 22:47:51 yes (as written) 22:47:52 subtypes are not disjoint 22:48:20 PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. 22:48:48 I would vote -0.1 against include the string subtypes - they are pointless 22:49:20 PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. 22:53:00 PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. 22:53:02 dave: anyURI is only useful string subtype 22:53:24 jos: anyURI is NOT a subtype of string -- it's a separate data type. 22:53:26 jos: actually, anyURI is primitive 22:54:15 PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. 22:54:31 note that xsd:anyURI is a datatype whereas rif:iri is only a symbol space 22:54:50 PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. 22:55:57 ACTION: josb to push back on OWL-WG about disjoint value spaces 22:55:58 Created ACTION-693 - Push back on OWL-WG about disjoint value spaces [on Jos de Bruijn - due 2009-01-22]. 22:57:14 PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. [The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. When those are decided, it will close issue-81] 22:57:38 +1 22:57:38 +1 22:57:40 +1 22:57:46 +1 22:57:49 +1 22:57:53 0 22:57:54 +1 22:57:55 +1 22:57:58 1 22:58:06 =0 22:58:06 RESOLVED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. [The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. When those are decided, it will close issue-81] 22:58:40 clarifying -- we're NOT adding the listed subtypes of String 22:59:00 I don't care either 22:59:26 sandro: do we push on OWL about subtype of string? -- no one cares. 23:00:28 DaveReynolds: owl:real only makes sense when the value spaces for numerics overlap. So it makes no sense for us. 23:01:00 jos: owl:real would still be a way to test if it's a numeric. 23:01:19 DaveReynolds: I wouldn't object to owl:real, but it seems unnecessary. 23:02:00 jos: no pred:isNumeric 23:02:07 DaveReynolds: that's a problem. 23:02:23 jos: So let's use isLiteralOfType(...., owl:real) 23:03:52 sandro: so owl:real is just a union type of all the numeric xsd types. 23:03:57 +q 23:04:40 q- 23:05:35 DaveReynolds: I agree with Jos, except we should use owl:realPlus. Also NaN, -0, +inf, -inf. Since those are part of the double valuespace. 23:06:11 I agree w. Dave, since we indeed have double 23:06:23 DaveReynolds: but OWL RL has owl:Real to avoid reasoning-by-cases. 23:07:33 sandro: rofl that NaN will pass the "numeric" test we're talking about. 23:07:48 would could take both owl:real and owl:realPlus 23:08:37 +1 to both. 23:09:04 dave, is owl:datetime a subset of xsd:dateTime? 23:09:19 can't remember, just trying to find def 23:11:13 They actually call it xsd:dateTimeStamp 23:11:50 "Feature At Risk #3: owl:dateTime name 23:11:52 The name datatype owl:dateTime was previously used as a placeholder. XML Schema 1.1 Working Group has introduced a datatype for date-time with required timezone. The datatype owl:dateTime was thus changed to the new datatype, xsd:dateTimeStamp. which is described here in a way compatible with its expected definition in XML Schema. If the XML Schema WG proceeds as expected, this section may... 23:11:53 ...be removed in favour of a pointer to the XML Schema documents." 23:12:38 PROPOSED: Add owl:dateTime (with the same AT RISK caveats as in the current OWL drafts, ie xsd:dateTimeStamp), owl:real, owl:realPlus to Core, PRD, BLD. Not owl:rational. This will replace xs:dateTime (currently in DTB). 23:18:11 PROPOSED: Add owl:dateTime (with the same AT RISK caveats as in the current OWL drafts, ie xsd:dateTimeStamp), owl:real, owl:realPlus to Core, PRD, BLD. Not owl:rational. This will replace NOT xs:dateTime which has no real time semantics but is still present in real data, so implementations should make their best guess. 23:18:24 -1 is SHOULD replace xs:dateTime 23:18:32 s/is/it/ 23:19:24 DaveReynolds: Any processor getting xs:dateTime data can map it to xs:dateTimeStamp. 23:20:07 csma:what about existing schemas using xs:dataTime? 23:21:29 DaveReynolds: as part of the mapping for XML data to RIF, you do the conversion from xs:dateTime to xs:dateTimeStamp. 23:22:00 csma: does this change the semantics of the rule? 23:22:14 DaveReynolds: No more than the error already there in the missing timezone. 23:22:50 DaveReynolds: Danger is you don't round trip. The data would go back out as xs:dateTimeStamp. 23:23:17 GaryHallmark: I can imagine rules that rely on local time zone. 23:23:58 DaveReynolds: in the XML schema mapping, we COULD say, the default assumption SHOULD BE local timezone. 23:24:31 PS I just realized that in this case, our equality (which is identity) is different from dateTime-equal 23:25:22 actually it is not 23:26:03 in XSD, equality between non-timezoned datetimes can be determined 23:26:28 http://www.w3.org/TR/xmlschema-2/#dateTime-order 23:29:18 PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime, but require systems to accept it, and when getting dateTimes without a timezone, they SHOULD use the local timezone and SHOULD give a warning in doing so. 23:29:40 if both datetimes either do or do not have a timezone, comparison works as you expect 23:30:05 if one does and one does not have a timezone, it becomes tricky 23:30:49 Suggest replacing first SHOULD with MAY 23:30:52 PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime, but require systems to accept it, and when getting dateTimes without a timezone, they SHOULD use the local timezone and SHOULD give a warning in doing so. 23:31:03 PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime, but require systems to accept it, and when getting dateTimes without a timezone, they MAY use the local timezone and SHOULD give a warning in doing so. 23:32:58 PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime. We anticipate that our XML Schema to RIF mapping will specify mapping xs:dateTimes to xs:dateTimeStamp, such a mapping MAY use the local timezone but SHOULD give a warning in doing so. 23:33:16 +1 23:33:24 PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). xs:dateTime will no longer be supported by RIF. On receipt of xs:dateTime data without a timeZone (ie not an xs:dateTimeStamp), systems MAY use the local timezone and SHOULD give a warning in doing so. 23:33:27 DateTime is well known in many programming languages 23:33:40 it can be transformed into the Epoch value 23:33:50 sorry -- Dave, is mine the same? 23:35:05 Proposed: Add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). Keep xs:dateTime as at Risk. 23:35:50 csma: I expect implementors of RIF to handle them both, by mapping them both to stuff in their local system. 23:36:09 why have both? 23:36:24 DaveReynolds: We'll have BOTH in DTB, with BOTH having comparion operators, and comparisons between the two? 23:37:59 I will object to having both 23:37:59 jos: it's horrible. 23:38:10 Succinctly put :-) 23:39:03 csma: seems like we have to table this issue 23:39:17 gary: yeah, it's broken -- I just don't know how much we depend on the way it's broken. 23:42:05 sandro: (with jos) the bad situation is that you cannot compare two times when one has a time zone and one doesn't, and they're within 14 hours of each other. the comparison is not defined. 23:43:11 the timezone is simply an extra agrument in adition to the DateTime value 23:43:53 gary: might get timezone added by the translator, instead of the system doing the rule execution. 23:44:10 q+ 23:44:19 ack DaveReynolds 23:44:22 ack dave 23:45:24 DaveReynolds: if you want local time zone semantics, then let's have a built-in "compare in local time zone". 23:46:35 Sandro: If Gary is relying on local-time-zone semantics, then yes, he should xlate his rules to use that built-in. 23:47:25 action: Gary to investigate what sort of local time zone semantics (ie java.Calendar semantics) his rulesets need. 23:47:25 Created ACTION-694 - Investigate what sort of local time zone semantics (ie java.Calendar semantics) his rulesets need. [on Gary Hallmark - due 2009-01-22]. 23:48:41 csma: It seems very risky to fix this bug, because people are relying on this broken behavior 23:49:07 csma: or people MIGHT be relying on it 23:49:41 DaveReynolds: But that behavior, being undefined, is not interoperable. 23:53:23 equality is not a problem 23:54:33 sandro: this will manifest on date-less-then being undefined sometimes (when one tz is missing) 23:55:18 sandro: I strongly expect most rule engines do not do this kind of datetime comparison. 23:57:22 +q 23:58:08 ack dave 23:58:13 we have three options: (1) xs:dateTime, (2) xs:dateTimeStamp, (3) try to document java semantics. 23:59:50 DaveReynolds: Gary's customers are probably assuming the dt semantics Gary has implemented. So when Gary translates to/from RIF, he needs to map to/from those semantics.