Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-01-15
From RIF
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
(Some of the original chatlog carries over onto the next day because that log uses UTC timestamps. Also, some of the log is missing, because RRSAgent was not on the channel. Sandro's xchatlog was used instead.)
Day 2 of F2F12.
00:00:00 <sandro> PRESENT: csma, gary, adrian, harold, kifer, jos, sandro, paul, changhai 00:00:00 <sandro> REMOTE: chrisw, dave, stella, leora, axel 09:20:38 <apaschke> scribernick apaschke 09:20:50 <apaschke> scribenick apaschke 09:21:00 <apaschke> Zakim, who is on the phone? 09:21:00 <Zakim> On the phone I see Mike_Dean, Hassan_Ait-Kaci (muted), RIF_Meeting_Room 09:21:27 <sandro> scribenick: apaschke 09:21:30 <apaschke> scribenick: apaschke 09:22:16 <apaschke> csma: concerns about alignment between Core and PRD 09:22:31 <apaschke> Harold: safeness is important 09:24:02 <apaschke> csma: problem was raised by example of Gary about backward chaining 09:24:23 <Zakim> +DaveReynolds 09:25:04 <apaschke> Harold: in analogy to DL we have defined safeness for external calls 09:25:40 <apaschke> Sandro: are there useful rules which do not fulfil safeness 09:25:49 <DaveReynolds> Yes 09:26:02 <DaveReynolds> But safeness is not defined yet - we have an open issue 09:26:54 <apaschke> csma: Forall ?x if a(?x+1) then a(?x) is unsafe 09:27:23 <sandro> yeah, this requires backward chaining, or ... 09:27:34 <apaschke> Gary: you need constraint solving 09:27:56 <sandro> csma: if you had constraint solving, then you could do this. 09:29:01 <apaschke> Gary: in RIF we only have built-in functions 09:29:44 <DaveReynolds> q+ 09:29:53 <apaschke> Gary: in the defintion it is too restrictive that there can't be disjunction 09:30:19 <apaschke> Sandro: why don't we say Core and safe Core 09:30:28 <csma> ack dave 09:30:53 <apaschke> Dave: there is just Core 09:31:03 <sandro> DaveReynolds: core isn't split (core and safe-core), but we're only requiring conformance to safe-core. 09:31:19 <DaveReynolds> ex:A(?x) :- ex:A(?y), ?x = ?y + 1, ?x < 10 09:32:10 <apaschke> Dave: safeness equals finiteness is over conversative 09:32:34 <sandro> DaveReynolds: conservative approach would be safeness=finiteness. that's what Axel's asking for, but given Halting, that's too restrictive. 09:32:55 <apaschke> Dave: constraints on variables so that you can not call built-ins with free variables 09:33:11 <sandro> DaveReynolds: But Gary and I just want safeness= forward chaining is admissible strategy. if it terminates, then fixed point would be model-theoretic answer. 09:33:23 <apaschke> Dave: if rules a finite the fixpoint is for forward chaining is similar as for the model theory 09:34:09 <apaschke> Sandro: Core authoring systems have to have in mind if they write rules for Core or safe core 09:34:25 <apaschke> Sandro: this is market confusing 09:34:59 <apaschke> csma: two question: How to align PRD and Core 09:35:02 <sandro> sandro: it's equivalent to have two core dialects, as far as I can tell. 09:35:39 <sandro> csma: let's first discuss what constitutes safeness. 09:35:41 <apaschke> csma: how do we restrict Core once we have aligned PRD and Core 09:36:23 <apaschke> Dave: there is a bug in the current definition if we allow nested functions 09:36:47 <apaschke> csma: PRD as an extension of Core 09:37:15 <sandro> DaveReynolds: Axel's datalog engines have the finiteness constraint. 09:38:11 <apaschke> Dave: fraction of RIF to exchange RDF rules in Core 09:38:31 <sandro> DaveReynolds: I'm fine with non-terminating rule sets. 09:39:02 <Harold> Did PRD initially want only range restricted rules, i.e. each variable in the conclusion of a rule must also appear in a not negated clause in the premise of this rule? 09:39:02 <apaschke> Dave: pure Datalog is alsway finite 09:39:29 <josb> fixpoints are not necessarily finite 09:39:44 <apaschke> Dave: it is not unusal that Datalog engines have built-ins restricted to strict safeness 09:39:46 <DaveReynolds> jos - true 09:40:40 <apaschke> Harold: PRD never want to conclude non-ground rules 09:40:45 <Zakim> -Mike_Dean 09:41:06 <apaschke> cke: variables alway need to be initialized 09:41:49 <apaschke> csma: would range restricted rules guaranty finiteness 09:42:15 <apaschke> Harold: each variable in the head also needs to appear in the body 09:43:11 <apaschke> Sandro: disjunction is syntactic sugar so it should not change the definition 09:43:32 <apaschke> Jos: the current definition can be fixed to have disjunction 09:43:48 <apaschke> csma: we need to define finite safeness or forward-chaining safeness 09:45:09 <sandro> Changhai: we just say "variable must be initialized" 09:45:12 <apaschke> ke: in production rules variables always need to be initialized 09:46:07 <apaschke> Sandro: do you allow reordering 09:46:25 <apaschke> Changhai: this can be syntactic sugar 09:46:44 <sandro> Sandro: So you'd be okay with having the system do reordering. 09:47:27 <DaveReynolds> But we should pick one for now, even if it is at risk 09:47:28 <apaschke> Sandro: we need feedback from implementors to know what we need 09:47:33 <sandro> Sandro: This finiteness question seems like an At-Risk subject, to base on implementors. 09:48:43 <apaschke> ke: finiteness depends on the domain 09:49:18 <apaschke> csma: as Dave said finiteness is not required for the interchange. It is the problem of the consumer to take care of it 09:49:56 <sandro> issue-82? 09:49:56 <trackbot> ISSUE-82 -- Finalize Core/PRD alignement -- OPEN 09:49:56 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/82 09:49:59 <apaschke> jos: the current definition is not clear 09:50:27 <apaschke> Gary: we should allow a limited form of disjunction 09:51:15 <sandro> csma: so you don't want if p(X) or q(Y) then .... those should be separate rules. 09:51:30 <apaschke> Gary: e.g. if color is green or red should be one disjunctive rule 09:52:04 <apaschke> Gary: or test should be allowd 09:52:07 <sandro> gary: or-in-test (okay) vs or-in-pattern (dangerous) 09:52:58 <DaveReynolds> q+ 09:53:40 <apaschke> Changhai: the customers should take care to write disjunctive rules correct 09:53:50 <sandro> Changhai: jrules does not allow it... (disjunctive patterns) 09:53:57 <apaschke> Changhai: we don't allow disjunctive aptters 09:54:01 <apaschke> Gary: we allow it 09:54:12 <sandro> ack DaveReynolds 09:54:13 <csma> ack dave 09:54:14 <apaschke> Paul: we allow disjunctive patterns too 09:55:07 <apaschke> Dave: the alternative was to have a disjunctive built-in test 09:55:24 <sandro> GaryHallmark: builtin for "value is one of a set of values" --- a disjunctive test, but no disjunction in rule. 09:55:41 <sandro> (or, that's what Dave said Gary said) 09:55:46 <josb> +1 to Dave 09:55:55 <josb> either have disjunction or not 09:56:28 <apaschke> csma: p(?X) or q(?X) is ok but not p(?X) or q(?Y) 09:57:56 <apaschke> csma: leave full disjunctive in Core and PRD and leave it to the consumer 09:58:14 <apaschke> Sandro: a conformate consumer would need to handle all of them 09:58:23 <apaschke> Paul: you would rewrite it 09:58:50 <sandro> csma: If you do not have disjunction in your language, then it will have to do the splitting. 10:00:11 <apaschke> csma: proposal is leave disjunction in COre and PRD. If a consumer does not have disjunction he needs to split the rules 10:01:24 <sandro> PROPOSED: Core (and thus PRD) will have unrestricted disjunction in the conditions. Consumers with engines not handling disjunction can do the rewriting to eliminate disjunction by splitting into multiple rules. 10:02:51 <sandro> PROPOSED: Core (and thus PRD) will have unrestricted disjunction in the conditions. Consumers with engines not handling disjunction can do the rewriting to eliminate disjunction by splitting into multiple rules. 10:03:05 <apaschke> Sandro: disjunction is only syntactic sugar 10:04:19 <apaschke> csma: if p(?a) or q(?Y) then ac(?x ?y) is not safe 10:04:35 <sandro> csma: IF P(?X) or Q(?Y) then ACT(?x ?y) splits into if p(?x) then act(?x ?y) and if q(?y) then act(?x ?y) 10:05:07 <josb> PROPOSED: suspend the safeness discussion until we have a decent deifnition of safeness 10:05:22 <josb> s/deifnition/definition / 10:06:17 <sandro> PROPOSED: Core (and thus PRD) will have unrestricted disjunction in the conditions. (Of course disjunction interacts with safeness, where there probably will be restriction.) Consumers with engines not handling disjunction can do the rewriting to eliminate disjunction by splitting into multiple rules. 10:08:51 <sandro> PROPOSED: Core (and thus PRD) will allow disjunction in the conditions. 10:10:05 <DaveReynolds> See (closed) http://www.w3.org/2005/rules/wg/track/issues/75 10:10:17 <apaschke> csma: if PRD does not allow an unbound variable in the head what does this mean for the restrictions on Core? 10:11:14 <sandro> thanks, DaveReynolds :-) 10:11:41 <sandro> quoting= 2008-11-04 18:48:50: At the Oct 21 2008 telecon the WG resolved to close this issue and decided that Core should keep safe disjunction in rule bodies. Implementations can be direct or use a well-known preprocessing step. See http://lists.w3.org/Archives/Public/public-rif-wg/2008Oct/att-0088/2008-10-21-rif-minutes.html [Christopher Welty] 10:12:15 <apaschke> Michael: disallow unbound variables which are potentially infinite 10:12:19 <sandro> mk: disallow unbound variables in predicates that are potentially infinite, like equality. 10:12:32 <apaschke> Michael: such as equal, built-in predicates 10:13:48 <apaschke> Michael: condition that disallows unbound variables in the head and in potentially infinite predicates 10:17:13 <sandro> ACTION: josb to write a proposed new definition of the safeness restriction 10:17:13 <trackbot> Created ACTION-687 - Write a proposed new definition of the safeness restriction [on Jos de Bruijn - due 2009-01-22]. 10:18:21 <sandro> csma: keep issue-82 open until we have safeness happily defined. 10:18:21 <josb> ACTION: josb to write some safeness test cases 10:18:22 <trackbot> Created ACTION-688 - Write some safeness test cases [on Jos de Bruijn - due 2009-01-22]. 10:18:42 <apaschke> csma: PRD will be a superset of safe core 10:18:51 <apaschke> Sandro: I need to know what safe core is 10:19:18 <sandro> sandro: it's understood that PRD is a syntactic superset of Core? gary/csma: yes. 10:19:54 <sandro> csma: Does SWC work with Core? 10:20:01 <sandro> Jos: Yes, of course. It does. 10:20:21 <apaschke> Jos: Core is a subset of BLD and has the same model theory 10:20:29 <apaschke> csma: what is the impact on PRD? 10:20:41 <apaschke> jos: equality in the head to check constraints 10:20:59 <apaschke> jos: there is one unsafe rule. But you can get arround that 10:21:21 <sandro> csma: would safeness impact SWC? 10:21:27 <apaschke> csma: Would the safeness restriction impact SWC? 10:21:59 <sandro> jos: not from a def'n point of view. the embedding has one unsafe rule, but I *think* that can be remedied. 10:22:01 <apaschke> Jos: there is one rule which can be replaced by two safe rules 10:24:02 <apaschke> Changhai: can you give examples of Core rules handling RDF? 10:24:39 <apaschke> Sandro: the test cases which we went through yesterday 10:25:05 <apaschke> Jos: OWL RL embending - we need equality in the head for this 10:25:41 <apaschke> Jos: so you can not have OWL RL embeding in Core 10:25:58 <apaschke> Sandro: can't you axiomatize equality for that 10:27:11 <sandro> sandro: Ah, I see. Yes, OWL provides equality. So if you want to use it with RIF, you have to use it with a RIF dialect that provides equality. 10:27:33 <DaveReynolds> Jos - could you explain where in OWL RL you need equality in head? 10:27:37 <cke> r/changai/changhai/a 10:28:02 <sandro> Jos: sameAs and keys 10:28:04 <apaschke> Jos: sameas statements and keyeys 10:28:19 <sandro> presumably you can get there with cardinality as well. 10:28:49 <josb> http://www.w3.org/TR/owl2-profiles/#Axioms_3 10:28:54 <josb> HasKey 10:29:19 <josb> Yes, MaxCardinality as well 10:29:54 <apaschke> http://www.w3.org/2005/rules/wiki/UCR#Publishing_Rules_for_Interlinked_Metadata 10:31:14 <apaschke> Jos: you would restrict to the part of safe core in SWC 10:32:42 <apaschke> Jos: there is no semantics for what the implementation will do 10:33:56 <apaschke> Jos: in practice if you have priorities etc. order matters 10:34:04 <sandro> jos: for instance, in the presence of Retract, it would matter how you prioritized your RDF/OWL-implementation-rules. 10:37:36 <sandro> Sandro: I'll agree with Jos that there may be nasty bits un unspecified-ness 10:37:42 <sandro> csma: but those are not RIF's problem. 10:38:34 <apaschke> csma: interoperability of RDF and OWL is through the safe core of RIF 10:38:55 <apaschke> csma: PRD interoperability 10:39:55 <sandro> csma: I want readers to know http://www.w3.org/TR/rif-rdf-owl/ applies to Core and (in a sense) to PRD. 10:40:59 <sandro> sandro: Some of embeddings (eg equality) cannot be done in Core, of course. 10:41:47 <sandro> jos: rdfs embeddings can probably be fixed. 10:42:14 <josb> ACTION: josb to coreify SWC 10:42:14 <trackbot> Created ACTION-689 - Coreify SWC [on Jos de Bruijn - due 2009-01-22]. 10:43:36 <sandro> PROPOSED: PRD will not address interop with RDF and OWL directly -- there is no work to do there. SWC will instead be updated to be phrased in terms of Core, so it can be (in most ways) inherited for PRD. 10:44:12 <sandro> PROPOSED: PRD will not address interop with RDF and OWL directly -- there is no work to do there. SWC will instead be updated to be phrased in terms of [safe] Core, so it can be (in most ways) inherited for PRD. 10:44:26 <sandro> sandro: I strongly object to ever hearing the term "safe core" again. :-( 10:44:30 <cke> +1 10:44:33 <sandro> +1 10:44:40 <apaschke> +1 10:45:12 <josb> +1 10:45:15 <Zakim> -Hassan_Ait-Kaci 10:45:40 <sandro> RESOLVED: PRD will not address interop with RDF and OWL directly -- there is no work to do there. SWC will instead be updated to be phrased in terms of [safe] Core, so it can be (in most ways) inherited for PRD. 10:45:50 <pvincent> +0 10:46:00 <Harold> +1 10:46:11 <sandro> action-686? 10:46:11 <trackbot> ACTION-686 -- Jos de Bruijn to remind Sandro that 'josb' works in assigning actions. -- due 2009-01-21 -- OPEN 10:46:11 <trackbot> http://www.w3.org/2005/rules/wg/track/actions/686 10:46:53 <sandro> action-686 done 10:46:58 <sandro> action-686 closed 10:46:58 <trackbot> ACTION-686 Remind Sandro that 'josb' works in assigning actions. closed 10:47:17 <sandro> csma: Do we have two levels in core> 10:47:25 <apaschke> csma: two levels of Core? 10:47:38 <sandro> DaveReynolds? 10:47:42 <sandro> zakim, who is here? 10:47:42 <csma> ack dave 10:47:43 <Zakim> On the phone I see RIF_Meeting_Room, DaveReynolds 10:47:45 <Zakim> On IRC I see pvincent, DaveReynolds, StellaMitchell, apaschke, sandro, Harold, csma, GaryHallmark, cke, josb, MoZ, Hassan, mdean, trackbot, Zakim 10:47:54 <sandro> PROPOSED: Core == Safe Core 10:48:42 <apaschke> Dave: some wanted Core to be restricted to only Datalog 10:49:03 <sandro> DaveReynolds: If safeness==finiteness, if "safe core" is datalog, then that rules out stuff I want, interop between PRD and BLD. 10:49:08 <apaschke> Dave: others want Core to the maximum interestion of PRD and BLD 10:50:11 <apaschke> Dave: if we end up with a definition of forward chaining safeness (as discussed before) that would be fine from my point of view 10:50:32 <apaschke> Dave: if we have a much more restricted safeness condition we will have a problem 10:51:08 <sandro> Dave: If we have a very-strict notion of safeness, then yeah we need two cores. 10:52:05 <apaschke> Sandro: it is finite core vs. Core (intersection of PRD /BLD) 10:52:21 <sandro> sandro: so the smaller core is "finite core" or "terminating core". "safe core" is actually the bigger one. 10:52:52 <josb> The definition I have in mind is a standard Datalog one 10:53:24 <josb> It is not going to be finite; I would allow a(x+1) :- a(x). a(1). 10:53:28 <josb> This does not terminate 10:53:31 <sandro> dave: let's do one core, with safeness restriction. but if safeness is too restrictive, then we might re-examine. 10:54:11 <sandro> DaveReynolds: remove weasely conformance, one core... 10:56:41 <apaschke> Sandro: let's first do the definition of safeness and then see if we need two cores? 10:56:53 <apaschke> Dave: yes, we will mark it at risk 10:56:58 <sandro> so we'll procede with one (larger but safe) core, and maybe have a smaller (terminating) core, AT RISK. 11:00:30 <sandro> PROPOSED: Close issue-82, given understandings in discussion so far today. Core as specialization of PRD is just work to do. Yes, safeness restriction will resolve backware chaining problem (action on Jos). Does Core compatibiliy with RDF+OWL extend PRD - yes. 11:01:12 <cke> +1 11:01:18 <csma> action: gary to specify core as a specialisation of PRD 11:01:18 <trackbot> Created ACTION-690 - Specify core as a specialisation of PRD [on Gary Hallmark - due 2009-01-22]. 11:01:22 <sandro> +1 11:01:50 <DaveReynolds> +1 11:02:37 <sandro> PROPOSED: Close issue-82, given understandings in discussion so far today. Core as specialization of PRD is just work to do. Yes, safeness restriction will resolve backware chaining problem (action on Jos). Does Core compatibiliy with RDF+OWL extend to PRD? only to the extend that's automatic through Core 11:02:47 <DaveReynolds> +1 11:02:47 <sandro> +1 11:02:49 <josb> s/extend/extent/ 11:02:51 <josb> +1 11:02:53 <cke> +1 11:02:55 <apaschke> ++1 11:02:58 <Harold> +1 11:03:00 <apaschke> +1 11:03:08 <Michael_Kifer> +1 11:03:42 <Zakim> -DaveReynolds 11:03:52 <sandro> RESOLVED: Close issue-82, given understandings in discussion so far today. Core as specialization of PRD is just work to do. Yes, safeness restriction will resolve backward chaining problem (action on Jos). Does Core compatibility with RDF+OWL extend to PRD? only to the extend that's automatic through Core 11:03:59 <josb> s/extend/extent/ 11:04:16 <sandro> issue-39? 11:04:17 <trackbot> ISSUE-39 -- RIF should support import or inclusion of rulesets [NOT CP] -- CLOSED 11:04:17 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/39 11:04:45 <RRSAgent> logging to http://www.w3.org/2009/01/15-rif-irc 11:04:54 <sandro> RRSAgent, make minutes 11:04:54 <RRSAgent> I have made the request to generate http://www.w3.org/2009/01/15-rif-minutes.html sandro 11:05:33 <sandro> pointer? 11:05:37 <sandro> RRSAgent, pointer? 11:05:37 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T19-05-47 11:34:16 <sandro> zakim, who is on the call? 11:34:16 <Zakim> On the phone I see RIF_Meeting_Room 11:34:24 <sandro> RESTARTING 11:35:48 <sandro> scribenick: cke 11:36:03 <sandro> issue-48? 11:36:03 <trackbot> ISSUE-48 -- Classification constructs in Core [NOT CP] -- OPEN 11:36:03 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/48 11:39:06 <Zakim> +DaveReynolds 11:39:14 <cke> Membership means: object # classname, where classname is a name of a class (correction of yesterday) 11:42:18 <sandro> PROPOSED: Have # and ## in Conditions and Facts in Core. 11:43:03 <DaveReynolds> -1 11:43:10 <josb> -1 11:43:16 <GaryHallmark> +1 11:43:22 <sandro> +1 11:43:39 <sandro> DaveReynolds: I have two problems with these 11:44:02 <sandro> DaveReynolds: I'd like to be able to assert these as well -- the restrictions are awkward. 11:44:50 <sandro> 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. 11:45:15 <pvincent> +1 to Dave as subclass tests not that interesting to PR engines... 11:45:30 <sandro> DaveReynolds: I could live with # in Conditions and Facts in Core. (we already decided this.) 11:46:15 <sandro> mk: What does PRD do about an rdfs:subClassOf appearing in the head of a rule? 11:47:01 <sandro> Jos: as we said earlier, there's no interop between PRD and RDFS. 11:49:04 <sandro> sandro: PRD's notion of classes and RDF's notion of classes will just be independent. Oh well, that's how it is. 11:51:16 <sandro> PROPOSED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core. 11:51:36 <sandro> Jos: Take # out of core because it's redundant with rdf:type 11:52:44 <DaveReynolds> Jos - could you talk closer to a mike? 11:53:07 <cke> Jos: agree with Dave that subclass is not the same as in RDFS 11:55:01 <sandro> Sandro: I'd like # and ## in core, with ## fixed to align with rdfs:subClassOf. 11:55:47 <sandro> ## == subclassof and not equivalent class 11:55:54 <sandro> PROPOSED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core. 11:56:01 <sandro> +0 11:56:04 <josb> 0 11:56:07 <cke> +1 11:56:11 <pvincent> +1 11:56:11 <apaschke> +1 11:56:12 <Harold> +1 11:56:17 <DaveReynolds> 0 11:56:24 <GaryHallmark> 0 11:56:43 <Zakim> +??P1 11:56:45 <Michael_Kifer> 0 11:57:46 <Zakim> -??P1 11:57:50 <sandro> RESOLVED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core. 11:57:56 <sandro> RRSAgent, pointer? 11:57:56 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T19-58-06 11:58:31 <sandro> issue-68? 11:58:31 <trackbot> ISSUE-68 -- Named argument UNITERM in CORE? -- OPEN 11:58:31 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/68 11:59:35 <sandro> PROPOSED: close issue-68 with no Named-Argument Uniterms (NAU) in Core or PRD. 11:59:43 <josb> +1 11:59:47 <DaveReynolds> +1 11:59:53 <sandro> +1 11:59:56 <Harold> 0 12:01:46 <sandro> I'd like to put this on the list of things to take out of BLD. 12:02:17 <pvincent> +1 12:02:18 <GaryHallmark> 0 12:03:18 <Michael_Kifer> 0 12:03:28 <cke> 0 12:03:29 <sandro> RESOLVED: close issue-68 with no Named-Argument Uniterms (NAU) in Core or PRD. 12:03:31 <sandro> RRSAgent, pointer? 12:03:31 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T20-03-41 12:03:40 <sandro> action: csma remove NAU from PRD 12:03:40 <trackbot> Created ACTION-691 - Remove NAU from PRD [on Christian de Sainte Marie - due 2009-01-22]. 12:03:59 <sandro> issue-72? 12:03:59 <trackbot> ISSUE-72 -- Should Core support some approximation to skolem functions? -- OPEN 12:03:59 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/72 12:04:12 <Harold> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0245.html 12:04:28 <Harold> (above link shows CLIPS example with NAU) 12:06:03 <sandro> PROPOSED: Close issue-72 saying "No". (Nothing like skolem functions in Core.) 12:06:34 <sandro> DaveReynolds: not happy, but I wouldnt object. 12:08:28 <sandro> 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. 12:09:23 <sandro> gary: challenges with making it deterministic -- eg two new objects when rule fires twice. 12:09:49 <sandro> gary: it didn't seem possible to solve in the general PRD case. 12:10:04 <cke> +0 12:10:09 <sandro> 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. 12:10:10 <DaveReynolds> 0 12:10:17 <GaryHallmark> 0 12:10:19 <sandro> 0 12:10:22 <cke> 0 12:10:23 <Harold> 1 12:10:25 <josb> +1 12:10:29 <pvincent> +0 12:10:29 <Michael_Kifer> 1 12:10:33 <apaschke> 0 12:10:41 <sandro> 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. 12:10:45 <sandro> RRSAgent, pointer? 12:10:45 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T20-10-55 12:11:19 <sandro> issue-33? 12:11:20 <trackbot> ISSUE-33 -- Specification of data sources in RIF [NOT CP] -- OPEN 12:11:20 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/33 12:11:24 <apaschke> 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, ... 12:12:51 <sandro> PROPOSED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources will be sufficient. 12:13:22 <josb> +1 12:13:23 <pvincent> +1 12:13:24 <DaveReynolds> Harold, Adrian - the CLIPS facts are not NAUs normally, you can pattern match on a subset of the arguments 12:13:36 <sandro> PROPOSED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources, and using external builtins, will be sufficient. 12:13:45 <sandro> +1 12:13:52 <cke> +1 12:13:57 <Michael_Kifer> 1 12:13:59 <DaveReynolds> +1 12:14:03 <apaschke> 0 12:14:08 <pvincent> +1 12:14:17 <Harold> +1 12:14:28 <sandro> RESOLVED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources, and using externals, will be sufficient. 12:14:31 <GaryHallmark> +1 12:14:32 <sandro> RRSAgent, pointer? 12:14:32 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T20-14-41-1 12:15:03 <sandro> issue-78? 12:15:03 <trackbot> ISSUE-78 -- Which to make external: ATOMIC, ATOM, or ATOM|FRAME -- OPEN 12:15:03 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/78 12:16:14 <josb> http://www.w3.org/2005/rules/wiki/BLD#Formulas 12:16:38 <sandro> csma: currently -- BLD externals can be position or na term, or a frame. later (frame) at risk. 12:16:55 <sandro> csma: issue was raised because I didn;t know what an external frame was. 12:17:38 <sandro> sandro: example? 12:19:46 <sandro> 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). 12:20:09 <sandro> csma: any frame can be external 12:20:26 <sandro> mk: yes. it was just an oversight. #, ##, and = should be external-able. 12:20:46 <sandro> mk: some kinds of = are builtin. 12:20:46 <DaveReynolds> 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. 12:21:25 <sandro> 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. 12:21:34 <sandro> csma: that's in the defn't of the external. 12:22:49 <sandro> mk: when you get an RIF document, with an external frame, there should be some IRI identifying which source for external frames. 12:24:54 <sandro> sandro: don't have anything external except for predicates and functions. If you want your own #, then give it your own URI name. 12:26:25 <sandro> PROPOSED: The only Externals in BLD will be Predicates and Functions. No external frames, no external equality, etc. 12:26:58 <sandro> PROPOSED: The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc. 12:27:02 <josb> +1 12:27:08 <DaveReynolds> +1 12:27:22 <sandro> 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. 12:27:31 <cke> +1 12:27:37 <Harold> 0 12:27:37 <sandro> +1 12:27:48 <Michael_Kifer> 0 12:28:16 <sandro> 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. 12:28:20 <sandro> RRSAgent, pointer? 12:28:20 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T20-28-29 12:29:19 <sandro> BREAK FOR LUNCH 12:29:23 <sandro> issue-48? 12:29:25 <trackbot> ISSUE-48 -- Classification constructs in Core [NOT CP] -- CLOSED 12:29:25 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/48 12:29:30 <sandro> issue-68? 12:29:31 <trackbot> ISSUE-68 -- Named argument UNITERM in CORE? -- CLOSED 12:29:31 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/68 12:29:35 <Zakim> -DaveReynolds 12:29:42 <sandro> issue-72? 12:29:42 <trackbot> ISSUE-72 -- Should Core support some approximation to skolem functions? -- CLOSED 12:29:42 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/72 12:29:46 <sandro> issue-33? 12:29:47 <trackbot> ISSUE-33 -- Specification of data sources in RIF [NOT CP] -- CLOSED 12:29:47 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/33 12:29:51 <sandro> issue-78? 12:29:52 <trackbot> ISSUE-78 -- Which to make external: ATOMIC, ATOM, or ATOM|FRAME -- CLOSED 12:29:54 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/78 12:30:11 <cke> We restart at 13:30. 12:32:00 <sandro> issue-46? 12:32:00 <trackbot> ISSUE-46 -- Modules in RIF [NOT CP] -- OPEN 12:32:00 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/46 13:37:51 <Harold> http://www.econ.kuleuven.be/eng/fetew/medewerker/Userpage.aspx?PID=271 13:41:46 <sandro> issue-69? 13:41:47 <trackbot> ISSUE-69 -- Should there be a Core schema incldued in BLD and PRD schemata? -- OPEN 13:41:47 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/69 13:42:08 <sandro> scribenick: gary 13:42:25 <Zakim> +DaveReynolds 13:42:28 <Zakim> -RIF_Meeting_Room 13:42:30 <Zakim> +RIF_Meeting_Room 13:43:15 <GaryHallmark> harold: specialize bld schema to arrive at core schema 13:43:28 <GaryHallmark> ... should look at how to inherit core into bld 13:43:58 <sandro> 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. 13:44:08 <GaryHallmark> ... inherit means xml include 13:45:01 <GaryHallmark> sandro: include is just an editorial change 13:46:25 <GaryHallmark> sandro: who will do the modularization exercise? 13:46:49 <GaryHallmark> harold: will help changhai 13:46:58 <sandro> ACTION: changhai to draft modularized Core and PRD schema, coordinating with Harold on BLD Schema 13:46:58 <trackbot> Created ACTION-692 - Draft modularized Core and PRD schema, coordinating with Harold on BLD Schema [on Changhai Ke - due 2009-01-22]. 13:48:41 <Harold> In http://www.w3.org/2005/rules/wiki/BLD#Rule_Language we have <xs:include schemaLocation="BLDCond.xsd"/>. 13:49:08 <GaryHallmark> changhai: work toward a core schema and BLD and PRD schemas that include the core schema 13:49:15 <DaveReynolds> Harold - is the Core schema online or on the wiki somewhere? 13:49:37 <Harold> A Core schema doesn't exist yet. 13:49:43 <sandro> PROPOSED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692. 13:49:50 <DaveReynolds> Sorry misheard, your audio is very quiet 13:50:00 <csma> zakim, who is on the phone? 13:50:00 <Zakim> On the phone I see RIF_Meeting_Room, DaveReynolds 13:50:26 <DaveReynolds> :-) 13:50:34 <sandro> proooooojeeeeeect 13:50:59 <sandro> PROPOSED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692. 13:51:15 <sandro> +1 13:51:27 <AdrianP> +1 13:51:27 <chke> +1 13:51:28 <josb> +1 13:51:30 <DaveReynolds> +1 13:51:50 <Harold> +1 13:51:53 <Michael_Kifer> 1 13:51:56 <GaryHallmark> +1 13:52:01 <sandro> RESOLVED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692. 13:52:20 <sandro> rrsagent, pointer? 13:52:20 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T21-52-29 13:54:14 <sandro> issue-46? 13:54:14 <trackbot> ISSUE-46 -- Modules in RIF [NOT CP] -- OPEN 13:54:14 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/46 13:55:43 <sandro> PROPOSED: Close issue-46; no decision to make at this time. If someone produces a proposal for modules, we may consider it. 13:56:00 <chke> +1 13:56:11 <sandro> +1 13:56:11 <DaveReynolds> +1 13:56:16 <AdrianP> +1 13:56:18 <Harold> +1 13:56:24 <GaryHallmark> +1 13:56:28 <josb> +1 13:56:31 <sandro> RESOLVED: Close issue-46; no decision to make at this time. If someone produces a proposal for modules, we may consider it. 13:56:35 <sandro> RRSAgent, pointer? 13:56:35 <RRSAgent> See http://www.w3.org/2009/01/15-rif-irc#T21-56-45 13:57:33 <sandro> issue-50? 13:57:33 <trackbot> ISSUE-50 -- Semantic metadata -- OPEN 13:57:33 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/50 13:57:54 <Zakim> +[IPcaller] 13:58:31 <sandro> issue-80? 13:58:31 <trackbot> ISSUE-80 -- Shoudl we extend DTB to include more general builtins -- OPEN 13:58:31 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/80 13:59:32 <sandro> Axel: unfort. my keyboard is broken. so I cannot type on IRC. :-( 13:59:59 <Zakim> -[IPcaller] 14:00:52 <sandro> <csma> 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. 14:04:22 <Zakim> +??P4 14:04:42 <sandro> Gary: can we just have a "type" for everything that's not a literal? 14:05:56 <josb> Sandro, Gary, negation would become a problem, i.e., isNotObject is a problem; isObject would not be a problem, I think 14:07:06 <josb> isNotObject=isLiteral, so should actually not be a problem 14:07:09 <sandro> jos: maybe yes we could do "isObject". 14:07:26 <Zakim> -??P4 14:07:43 <AdrianP> something like isType(?X, Object) 14:07:58 <AdrianP> isType(?X, Integer) 14:08:39 <sandro> Jos: "object" in owl is owl:Thiing 14:09:27 <sandro> sandro: obviously isLiteralofTtyype, etc, are clumsy and something more elegant would be great. 14:09:56 <GaryHallmark> sandro: what about isObject, isLiteral 14:10:21 <GaryHallmark> jos: isLiteral 14:10:29 <DaveReynolds> We put the isLiteral part in notType as part of resolving the negative guards, the isLiteral part of ofType is just there for symmetry 14:11:04 <GaryHallmark> sandro: need to cover unknown datatypes 14:11:37 <GaryHallmark> dave: needed neg guards for owl RL 14:12:21 <josb> isLiteralNotInteger(x) :- isLiteral and (isDouble and isFloat ....) 14:12:27 <josb> isLiteralNotInteger(x) :- isLiteral and (isDouble or isFloat ....) 14:12:37 <GaryHallmark> jos: instead of neg guards, enumerate, e.g. isNotInt == isDouble or isString or ... 14:13:09 <GaryHallmark> ... can't cover because value spaces not disjoint 14:14:17 <sandro> issue-81? 14:14:17 <trackbot> ISSUE-81 -- Support for additional OWL-RL datatype -- OPEN 14:14:17 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/81 14:15:43 <GaryHallmark> sandro: separate owl: and xsd: types 14:16:49 <GaryHallmark> ... rationale for xsd: is completeness. for owl:, ability to use RIF to implement owl RL 14:17:41 <GaryHallmark> jos: possible issue with lex spaces not disjoint 14:18:47 <sandro> DaveReynolds: problem with binary types is: what builtins should we have? some work there? 14:19:47 <josb> the set of additional XPath functions is small: http://www.w3.org/TR/xpath-functions/ 14:20:42 <DaveReynolds> If you are talking about numerics now then see http://lists.w3.org/Archives/Public/public-rif-wg/2009Jan/0017.html 14:20:56 <sandro> sandro: I expect users are going to want promotion 14:26:08 <josb> what if we do type promotion, even with non-disjoint value spaces? 14:27:51 <GaryHallmark> 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) 14:30:20 <DaveReynolds> 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 14:32:19 <GaryHallmark> jos: will try to convince owl that disjointness is a good thing 14:32:44 <Zakim> +LeoraMorgenstern 14:32:52 <GaryHallmark> dave: owl has no builtins, so they don't have our motivation 14:33:18 <GaryHallmark> sandro: may need formal objection 14:33:19 <josb> our main argument we can give OWL is extensibility 14:37:56 <sandro> sandro: XSD is so broken. :-) hexBinary and base64Binary both have identically described value spaces, but they are also defined as being disjoint. 14:38:45 <josb> http://www.w3.org/TR/xmlschema11-2/#order 14:38:54 <josb> "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." 14:39:19 <josb> Sandro, I agree; the spec is broken 14:40:22 <josb> also: http://www.w3.org/TR/xmlschema-2/#equal 14:40:28 <josb> "# the ·value space·s of all ·primitive· datatypes are disjoint (they do not share any values) " 14:43:54 <sandro> Changhai: use case for xsd:hasBinary is including an encrypted password. 14:44:02 <sandro> s/has/hex/ 14:45:17 <chke> base64binary looks like to be the way to convert binary information into printable characters. This is required for storing passwords, for example. 14:45:18 <sandro> PROPOSED: Include all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately. 14:45:37 <sandro> 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. 14:45:46 <DaveReynolds> Does that include the string subtypes? 14:46:05 <sandro> 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. 14:47:05 <sandro> 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. 14:47:18 <DaveReynolds> Does that include the string subtypes? 14:47:41 <sandro> yes (as written) 14:47:42 <GaryHallmark> subtypes are not disjoint 14:48:10 <sandro> 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. 14:48:38 <DaveReynolds> I would vote -0.1 against include the string subtypes - they are pointless 14:49:10 <sandro> 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. 14:52:51 <sandro> PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. 14:52:52 <GaryHallmark> dave: anyURI is only useful string subtype 14:53:14 <sandro> jos: anyURI is NOT a subtype of string -- it's a separate data type. 14:53:16 <GaryHallmark> jos: actually, anyURI is primitive 14:54:05 <sandro> PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. 14:54:21 <GaryHallmark> note that xsd:anyURI is a datatype whereas rif:iri is only a symbol space 14:54:41 <sandro> 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. 14:55:48 <sandro> ACTION: josb to push back on OWL-WG about disjoint value spaces 14:55:48 <trackbot> Created ACTION-693 - Push back on OWL-WG about disjoint value spaces [on Jos de Bruijn - due 2009-01-22]. 14:57:05 <sandro> 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] 14:57:28 <josb> +1 14:57:29 <sandro> +1 14:57:31 <DaveReynolds> +1 14:57:36 <chke> +1 14:57:39 <Harold> +1 14:57:43 <LeoraMorgenstern> 0 14:57:44 <AdrianP> +1 14:57:46 <GaryHallmark> +1 14:57:48 <Michael_Kifer> 1 14:57:56 <sandro> 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] 14:57:56 <pvincent> =0 14:58:30 <sandro> clarifying -- we're NOT adding the listed subtypes of String 14:58:51 <DaveReynolds> I don't care either 14:59:17 <sandro> sandro: do we push on OWL about subtype of string? -- no one cares. 15:00:19 <sandro> DaveReynolds: owl:real only makes sense when the value spaces for numerics overlap. So it makes no sense for us. 15:00:50 <sandro> jos: owl:real would still be a way to test if it's a numeric. 15:01:10 <sandro> DaveReynolds: I wouldn't object to owl:real, but it seems unnecessary. 15:01:50 <sandro> jos: no pred:isNumeric 15:01:57 <sandro> DaveReynolds: that's a problem. 15:02:13 <sandro> jos: So let's use isLiteralOfType(...., owl:real) 15:03:42 <sandro> sandro: so owl:real is just a union type of all the numeric xsd types. 15:03:47 <DaveReynolds> +q 15:04:30 <DaveReynolds> q- 15:05:25 <sandro> DaveReynolds: I agree with Jos, except we should use owl:realPlus. Also NaN, -0, +inf, -inf. Since those are part of the double valuespace. 15:06:02 <josb> I agree w. Dave, since we indeed have double 15:06:13 <sandro> DaveReynolds: but OWL RL has owl:Real to avoid reasoning-by-cases. 15:07:23 <sandro> sandro: rofl that NaN will pass the "numeric" test we're talking about. 15:07:38 <josb> would could take both owl:real and owl:realPlus 15:08:28 <sandro> +1 to both. 15:08:55 <josb> dave, is owl:datetime a subset of xsd:dateTime? 15:09:10 <DaveReynolds> can't remember, just trying to find def 15:11:04 <DaveReynolds> They actually call it xsd:dateTimeStamp 15:11:41 <DaveReynolds> "Feature At Risk #3: owl:dateTime name 15:11:42 <DaveReynolds> 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... 15:11:44 <DaveReynolds> ...be removed in favour of a pointer to the XML Schema documents." 15:12:29 <sandro> 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). 15:18:02 <sandro> 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. 15:18:14 <DaveReynolds> -1 is SHOULD replace xs:dateTime 15:18:23 <DaveReynolds> s/is/it/ 15:19:15 <sandro> DaveReynolds: Any processor getting xs:dateTime data can map it to xs:dateTimeStamp. 15:19:57 <sandro> csma:what about existing schemas using xs:dataTime? 15:21:19 <sandro> DaveReynolds: as part of the mapping for XML data to RIF, you do the conversion from xs:dateTime to xs:dateTimeStamp. 15:21:51 <sandro> csma: does this change the semantics of the rule? 15:22:05 <sandro> DaveReynolds: No more than the error already there in the missing timezone. 15:22:40 <sandro> DaveReynolds: Danger is you don't round trip. The data would go back out as xs:dateTimeStamp. 15:23:07 <sandro> GaryHallmark: I can imagine rules that rely on local time zone. 15:23:48 <sandro> DaveReynolds: in the XML schema mapping, we COULD say, the default assumption SHOULD BE local timezone. 15:24:21 <josb> PS I just realized that in this case, our equality (which is identity) is different from dateTime-equal 15:25:13 <josb> actually it is not 15:25:53 <josb> in XSD, equality between non-timezoned datetimes can be determined 15:26:19 <josb> http://www.w3.org/TR/xmlschema-2/#dateTime-order 15:29:09 <sandro> 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. 15:29:31 <josb> if both datetimes either do or do not have a timezone, comparison works as you expect 15:29:55 <josb> if one does and one does not have a timezone, it becomes tricky 15:30:39 <DaveReynolds> Suggest replacing first SHOULD with MAY 15:30:42 <sandro> 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. 15:30:53 <sandro> 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. 15:32:49 <DaveReynolds> 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. 15:33:06 <josb> +1 15:33:15 <sandro> 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. 15:33:18 <AdrianP> DateTime is well known in many programming languages 15:33:31 <AdrianP> it can be transformed into the Epoch value 15:33:40 <sandro> sorry -- Dave, is mine the same? 15:34:56 <sandro> Proposed: Add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). Keep xs:dateTime as at Risk. 15:35:40 <sandro> csma: I expect implementors of RIF to handle them both, by mapping them both to stuff in their local system. 15:35:59 <josb> why have both? 15:36:15 <sandro> DaveReynolds: We'll have BOTH in DTB, with BOTH having comparion operators, and comparisons between the two? 15:37:49 <josb> I will object to having both 15:37:49 <sandro> jos: it's horrible. 15:38:01 <DaveReynolds> Succinctly put :-) 15:38:53 <sandro> csma: seems like we have to table this issue 15:39:08 <sandro> gary: yeah, it's broken -- I just don't know how much we depend on the way it's broken. 15:41:55 <sandro> 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. 15:43:01 <AdrianP> the timezone is simply an extra agrument in adition to the DateTime value 15:43:44 <sandro> gary: might get timezone added by the translator, instead of the system doing the rule execution. 15:44:00 <DaveReynolds> q+ 15:44:10 <sandro> ack DaveReynolds 15:44:12 <csma> ack dave 15:45:14 <sandro> DaveReynolds: if you want local time zone semantics, then let's have a built-in "compare in local time zone". 15:46:25 <sandro> Sandro: If Gary is relying on local-time-zone semantics, then yes, he should xlate his rules to use that built-in. 15:47:15 <sandro> action: Gary to investigate what sort of local time zone semantics (ie java.Calendar semantics) his rulesets need. 15:47:16 <trackbot> 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]. 15:48:31 <sandro> csma: It seems very risky to fix this bug, because people are relying on this broken behavior 15:48:58 <sandro> csma: or people MIGHT be relying on it 15:49:31 <sandro> DaveReynolds: But that behavior, being undefined, is not interoperable. 15:53:13 <josb> equality is not a problem 15:54:24 <sandro> sandro: this will manifest on date-less-then being undefined sometimes (when one tz is missing) 15:55:08 <sandro> sandro: I strongly expect most rule engines do not do this kind of datetime comparison. 15:57:13 <DaveReynolds> +q 15:57:58 <csma> ack dave 15:58:03 <sandro> we have three options: (1) xs:dateTime, (2) xs:dateTimeStamp, (3) try to document java semantics. 15:59:41 <sandro> 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. 16:04:12 <sandro> PROPOSED: We'll use xs:dateTimeStamp (or owl:datetime if xs:dateTimeStamp isn't mature in time -- xs:dateTime with required timeZone and timeline semantics), and not xs:dateTime. We recognize the mapping this to/from what rule engines do may be challenging, but we see no easy solution. 16:04:51 <DaveReynolds> We may need additional builtins to enable that mapping in an inteoperable way. 16:04:52 <sandro> PROPOSED: We'll use xs:dateTimeStamp (or owl:datetime if xs:dateTimeStamp isn't mature in time -- xs:dateTime with required timeZone and timeline semantics), and not xs:dateTime. We recognize the mapping of this to/from what rule engines do may be challenging, but we see no approach that makes this mapping easier. 16:05:38 <chke> -1 16:05:50 <josb> +1 16:05:54 <Michael_Kifer> 0 16:06:01 <AdrianP> 0 16:06:06 <DaveReynolds> +1 (with note that additional builtins may be needed to enable the mapping) 16:06:06 <GaryHallmark> 0 16:06:07 <sandro> (chke needs more time -- will have concrete answer in two weeks) 16:06:09 <sandro> +1 16:06:24 <AdrianP> we probably need a much richer time onology 16:06:29 <Harold> +1 16:06:31 <sandro> NOT RESOLVED. 16:06:32 <pvincent> +0 16:07:25 <csma> action: to christian to add the issue on the agenda for RIF telecon Jan 29 16:07:25 <trackbot> Sorry, couldn't find user - to 16:07:33 <sandro> ACTION: changhai to agree with xs:dateTimeStamp proposal or send us arguments against it. 16:07:33 <trackbot> Created ACTION-695 - Agree with xs:dateTimeStamp proposal or send us arguments against it. [on Changhai Ke - due 2009-01-23]. 16:08:19 <sandro> PROPOSED: Add owl:real and owl:realPlus to RIF Core, BLD, PRD. 16:08:22 <sandro> +1 16:08:44 <sandro> csma: reminder -- these are union types of the numeric types. 16:08:45 <josb> +1 16:08:46 <DaveReynolds> +1 16:08:50 <AdrianP> 0 16:08:52 <sandro> RESOLVED: Add owl:real and owl:realPlus to RIF Core, BLD, PRD. 16:08:57 <Harold> 0 16:08:58 <GaryHallmark> +1 (for use as isNumeric() only) 16:09:33 <sandro> table owl:rational 16:09:46 <DaveReynolds> Ah. If OWL doesn't change the disjointness we will need to revisit this because we'll have to write our own defns of them 16:10:56 <sandro> sandro: yeah, this assumes that OWL will change the disjointness part. 16:11:29 <Zakim> -DaveReynolds 16:11:32 <sandro> thanks for all your help, DaveReynolds 16:11:35 <sandro> BREAK 16:11:42 <Zakim> -LeoraMorgenstern 16:27:23 <josb> PROPOSED: have dinner at Typhoon at 20:00 16:27:45 <josb> http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=typhoon,+portland&sll=37.0625,-95.677068&sspn=33.352165,58.886719&ie=UTF8&ll=45.523307,-122.678103&spn=0.014402,0.028753&z=15&iwloc=A 16:27:53 <josb> Who will join? 16:28:41 <josb> (it's Thai food) 16:29:05 <Harold> +1 16:34:21 <AdrianP> +1 16:41:35 <sandro> -1 (conflicts with flight) 16:45:41 <josb> RESOLVED: have dinner at Typhoon at 20:00 without Sandro ;) 16:46:41 <GaryHallmark> whitepaper on Oracle Business Rules is at http://www.oracle.com/technology/products/ias/business_rules/files/smart_business_processes_using_oracle_business.pdf 16:47:14 <sandro> PROPOSED: Close RIF. Burn all the evidence. 16:47:42 <csma> PROPOSED: PRD extends frames with some new syntax for attributes which are single-valued and have replacement semantics (matching OO object attributes). This doesn't make sense for Core or BLD. 16:49:05 <cke> +1 16:50:16 <sandro> gary: we said you don't need the equals in conditions. 16:53:29 <sandro> sandro: if you're going to use java type information, then you don't need RIF to tell you which properties are multivalued vs single valued. 16:54:25 <sandro> sandro: (you need multi/single info to know which kinds of java to write, but sure you can get it from Java.) 16:58:23 <sandro> gary: sometimes you have to generate the java -- java wont tell you the type. But you can infer that it's replacement semantics because somewhere in the ruleset there's an UPDATE action on it. 16:58:51 <sandro> cke: No, facts might provide multiple values. 16:59:04 <sandro> gary: You just look to see if there's more than one fact. 16:59:32 <sandro> cke: That's a very weak interpretation. You add another fact and then a single-valued attribute becomes multi-valued?! I don't like that. 17:01:02 <sandro> csma: I had one use case, but I don't know if it matters. I send you a ruleset and you run it to get some more data. YOu figure out whether you need a list or not. Then then NEXT ruleset I send you catches you on that. 17:01:16 <sandro> gary: That's multiple-rulesets-over-time is out of scope. 17:01:41 <sandro> gary: I assume you get the all the ruleset & data at once, and can analyze it all at once. 17:04:34 <sandro> gary: I'm afraid most PRD rulesets will be outside Core, because the single-valued-case is the common one. 17:05:43 <sandro> csma: Even if PRD uses single-valued properites, it can ...... something 17:05:54 <Zakim> +LeoraMorgenstern 17:06:47 <AdrianP> example if ?c#eg:Customer and ?c[eg:name->?n1 eg:name->?n2] and not(?n1 = ?n2) then do (?x new(?x)) (?x#rif:ClassException ?x[rif:class->eg:Customer rif:cardinalityViolation->eg:name]) 17:06:57 <sandro> Harold: singleton (one multievalue) vs single-valued-property. 17:06:58 <AdrianP> from http://www.w3.org/2005/rules/wiki/PRD_Ruleset_Example 17:08:21 <sandro> Changhai: I reject anything requiring us to analyze the whole document to figure out maxCard 17:11:07 <josb> +1 to proposal Sandro 17:12:26 <sandro> sandro: let's say everything is multivalued, but there is an UPDATE action which wipes out all the values before setting one (or more) new ones. If you can implement without lsits, more power to you. 17:13:07 <Harold> Yes, PRD could then still optionally use OWL 2 for expressing cardinality constraints such card=1, card>0, and 2 < card < 7. 17:13:17 <sandro> right, Harold 17:13:58 <csma> s/lsists/lists/ 17:14:22 <Harold> s/such/such as/ 17:16:05 <sandro> sandro: you don't need complete analysis -- or any at all really -- it's just a performance trick to notice when you'll only have singletons. 17:17:11 <sandro> gary: during the translation, you look at the rulesets, look for asserts vs updates for a frame, if it's all updates (not asserts) then it's singletons. 17:17:57 <sandro> gary: So you can't use assert to set a first value. 17:19:07 <sandro> cke: why not just indicate when properties are single values? 17:19:20 <sandro> sandro: because that syntax would be rejected by Core. 17:22:30 <sandro> csma: if ?x # Car ?c [ color -> Red ] then MODIFY ?c [color -> Blue ] 17:23:56 <sandro> csma: if ?x # Car ?c [ color -> Red ] then ?c[color -> Blue ] MEANS 'color' is multivalued. 17:29:40 <sandro> PROPOSED: action Modify on frames removes previous values, then does assert. Implementations can use the fact that a ruleset has ONLY modifies on some property to implement it as as single-valued. 17:32:15 <sandro> PROPOSED: PRD will have have "Modify" action which removes all previous values for the given properties, then sets one new value as given. Implementations can be use the fact that values for a given property are only provided via MODIFY (never ASSERT), then it can be implemented as single-valued. 17:32:19 <cke> -1 17:32:30 <GaryHallmark> +1 17:32:44 <Harold> +1 17:33:09 <sandro> cke: I'm against looking at the actions like this. I'm also opposed to pushing implementation to use lists so much. 17:33:55 <sandro> Gary, the problem with this is that I think most PRD rulesets will be all MODIFYs, so they wont work in Core. Alas. 17:34:11 <sandro> (but I doubt we can do better than that.) 17:35:06 <sandro> cke: I receive a document containing rules and facts, with no schema.... 17:35:21 <sandro> gary: I don't know how you can do anything with that without analysis 17:35:55 <AdrianP> the problem is that you might want to use modify to modify a complete list, e.g. an oder with several products which should be modified with a collection of several new products 17:37:04 <GaryHallmark> Sandro, I imagine a translator switch that will "gently force" into C 17:37:28 <GaryHallmark> ... into Core, including using assert instead of modify and hoping it all works out 17:38:01 <GaryHallmark> ... basically, make the user swear that the asserts are "single assignment" 17:40:29 <Harold> Next f2f and future of WG: 17:41:53 <Harold> Sandro: We need to work hard to get specs to their next levels (within two months), then accommodate comments. 17:52:20 <sandro> Plan is to meet approx in April, and at that meeting to resolve to publish all documents as Last Call. (maybe BLD as CR). 17:52:29 <sandro> (maybe test, ucr not.) 17:54:50 <sandro> csma: I like apr 14-24. range. 17:55:33 <sandro> csma: maybe 3 days; 3rd day for editors. 17:55:56 <sandro> csma: other offers that Boston. 17:56:43 <sandro> paul: I could maybe do TIBCO in West London. 18:01:22 <sandro> Week of April 13th, Boston. After Easter, Before www2009. 18:04:38 <sandro> ACTION: sandro start survey, including question about objecting to having it in north america again. 18:04:39 <trackbot> Created ACTION-696 - Start survey, including question about objecting to having it in north america again. [on Sandro Hawke - due 2009-01-23]. 18:05:00 <sandro> (survey of dates in that week, and maybe nearby weeks.) 18:06:12 <sandro> ADJOURNED.