Chatlog 2009-01-15

From RIF
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

(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.