Re: [UCR] Review UCR (action-624)

Hi Gary,

This raises an interesting point.  Particular rules, like the one in UCR 
4.6, can easily be flattened. It's not clear, however, how one can express 
general principles such as the commonsense law of inertia if one flattens. 
And it's very difficult to incorporate robust temporal reasoning without 
being able to express the commonsense law of inertia. So, the question is, 
what exactly would it mean to put "flattenable" functions in Core, and 
would we  then be able to express the necessary principles?

Here are some examples to make my question clearer: 

It is  true that the example in Case 4.6 can easily be flattened. So, 
instead of having 

Document( 
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(ex http://example.org/example#)

  Group
  (
    Forall ?Patient ?Treatment ?Level ?T (
      ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :-
      ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T)
      ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T)
      ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T)
      )
    )
  )

we could instead have something like 

Document( 
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(ex http://example.org/example#)

  Group
  (
    Forall ?Patient ?Treatment ?Level ?T (
      ex:ineffective(?Patient ?Treatment ?T) :-
      ex:hasDisease(?Patient "diabetesTypeII" ?T)
      ex:elevatedLevelOf(?Patient "hbA1c" ?Level ?T)
      ex:treatmentPlan(?Treatment ?Patient ?T)
      )
    )
  )


But  this is a particularly simple example, because there isn't really any 
temporal reasoning going on here. (Note that nothing would get lost here 
if we just left out the ?T variable.)

Let's consider, however, an example in which there is real temporal 
reasoning --- for example, a description of an action which has an effect. 
For simplicity, let's consider a patient's blood-sugar level at any 
particular point, not the hb1AC level. (The hb1AC level itself reflects 
the blood-sugar level over the past several months; reasoning about that 
over time adds additional difficulties.) Insulin quickly lowers a 
patient's blood sugar level. So there could be a rule such as the 
following: (I am kludging over all sorts of representational issues 
because I just want to focus on the issue of whether or not flattening is 
possible.)

Document( 
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(ex http://example.org/example#)

  Group
  (
    Forall ?Patient ?T1 ?T2 (
      ex:normalBloodSugarLevelOf(?Patient "bloodsugarlevel" ?T2) :-
      ex:hasDisease(?Patient "diabetesTypeII" ?T1)
      ex:elevatedBloodSugarLevelOf(?Patient "bloodsugarlevel" ?T1)
      ex:inject(?Patient  "insulin" ?T1)
     T2 =  T1 + 1
 
      )
    )
  )


So, if you use this rule, and you have the appropriate statements about 
the use case patient Bob, you'd be able to infer that Bob's blood sugar is 
normal after he receives the insulin injection.

Now of course, most things about Bob don't change as the result of his 
insulin injection. For example, his height stays the same, his eye color 
stays the same, etc. You could write rules to express this, of the form:

Document( 
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(ex http://example.org/example#)

  Group
  (
    Forall ?Patient ?H ?T1 ?T2 (
      ex:heightOfPerson(?Patient ?H ?T2) :-
      ex:heightOfPerson(?Patient ?H ?T1)
      ex:inject(?Patient  "insulin" ?T1)
     T2 =  T1 + 1
 
      )
    )
  )

However, you'd have to write a rule for every single property (there can 
be dozens or hundreds or thousands)  that stays the same after an insulin 
injection. (This, in a nutshell, is the frame problem.)

The general approach to solving the frame problem is to write general 
principles saying how things change, and the commonsense law of inertial 
--- that things don't change unless there is some action/event that makes 
them change.  If one can represent nested functions and  the value of a 
function, one can represent the commonsense law of inertia as:

Document( 
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(ex http://example.org/example#)

  Group
  (
    Forall ?Event  ?Fluent ?T1 ?T2 (
      HoldsAt(?Fluent, ?T2) :-
      HoldsAt(?Fluent, ?T1)
      Occurs(?Event ?T1)
      not Terminates(?Event ?Fluent)
     ?T2 = ?T1 +1
 
      )
    )
  )

This is the key to being able to reason that Bob's eye color and hair 
color and height and marital status and virtuallly all other properties 
remain the same. The trick to making this work is having these nested 
functions and fluents.  One needs to have non-flattened functions, so that 
one can write the causal rule about insulin as: 

Document( 
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(ex http://example.org/example#)

Group
  (
  Forall ?Patient ?T1 ?T2 (
      ex:HoldsAt(ex:normalBloodSugarLevelOf(?Patient "bloodsugarlevel") 
?T2) :-
      ex:HoldsAt(ex:hasDisease(?Patient "diabetesTypeII" )?T1)
      ex:HoldsAt(ex:elevatedBloodSugarLevelOf(?Patient 
"bloodsugarlevel")?T1)
      ex:Occurs(ex:inject(?Patient  "insulin") ?T1)
     T2 =  T1 + 1
 
      )
    )
  )

This, together with the above principle of inertia, allows one to conclue 
that the myriad properties of Bob remain the same after the insulin 
injection.

This is the (core of) the most widely accepted approach to solving the 
frame problem. Would putting flattenable functions in Core allow people to 
write such rules?

I can't see AI practitioners using RIF unless somehow RIF allows them to 
write rules for temporal reasoning in the way that they've been doing it 
for the past decade or more.

I hope we can discuss this  --- perhaps at next week's (Nov. 25) telecon?

Regards,
Leora

 




 















Gary Hallmark <gary.hallmark@oracle.com> 
Sent by: public-rif-wg-request@w3.org
11/11/2008 05:06 PM

To
Leora Morgenstern/Watson/IBM@IBMUS
cc
rif WG <public-rif-wg@w3.org>, public-rif-wg-request@w3.org
Subject
Re: [UCR] Review UCR (action-624)







I wonder if we should try to put "flattenable" functions in core? 

Leora Morgenstern wrote:
>
> Hi Gary,
>
> You write:
>
> >4.6
>
> >Again, the use of logical functions puts this outside Core, but there
> >isn't any deep need for logical functions here.  You could just as
> >easily include T as the last argument of the predicates, I think.
> >I don't think its wise to draw attention to the fact that Core lacks
> >logical functions by using them in ways that are trivial to flatten.
>
> It is certainly true that the rules in UCR 4.6 can be easily changed 
> so that they contain only predicates, not logical functions. When I 
> wrote these rules back in 2006, Core didn't exist, so there were no 
> restrictions against having such functions.
>
> However, it is worth noting that the standard method among AI 
> practitioners for representing events, actions, and time --- whether 
> one uses the situation calculus, event calculus, fluent calculus, or 
> similar --- uses some sort of a Holds predicate which takes as 
> arguments a unit (point or interval) of time and a term of the form 
> function(arg1, ..., argn). This is the standard because it makes it 
> much easier to state principles that are important for temporal 
> reasoning, such as the principle of inertia.
>
> So, while we can easily change this example, in general, it will make 
> it much more difficult for AI practitioners to use RIF if they have to 
> write their rules without using such functions. This should probably 
> be noted in the text of this example. (I'd be happy to propose a 
> paragraph or two about this point.)
>
> Leora
>
>
>
>
>
>
> *Gary Hallmark <gary.hallmark@oracle.com>*
> Sent by: public-rif-wg-request@w3.org
>
> 11/10/2008 04:57 PM
>
> 
> To
>                rif WG <public-rif-wg@w3.org>
> cc
> 
> Subject
>                [UCR] Review UCR (action-624)
>
>
>
> 
>
>
>
>
>
>
> This is from the wiki as of 10/24:
>
> Section 3 (Structure of RIF)
>
> This is where the notion of RIF-Core should be explained.  A Venn
> diagram would be useful here, with
> DTB in the middle, surrounded by Core, with PRD and BLD intersecting
> such that the intersection includes Core and finally FLD surrounding BLD
> (but not all of PRD).
>
> It is important to explain Core, because a number of the code examples
> are in fact Core and not BLD or PRD specific (and that is a good selling
> point to emphasize)
>
> Section 4
>
> As noted above, many examples are Core.  I don't know why we want 2
> buttons to hide BLD and PRD examples.  We certainly don't want 3, I
> think.  I suggest just one button to hide all examples.
>
> 4.1  is a Core example
>
> func:subtract-numeric cannot be applied to datetimes (many places)
>
> ex:ware and ex:receiver are not legal argNames (I think)
>
> In the frame example, ?item[ex:delivered->"John:] should not be a
> conclusion (it is a condition)
>
> The PRD examples are exactly the BLD examples, since both are Core. 
> Remove them.
>
> change pred:numeric-smaller-than to pred:numeric-less-than
>
> 4.2  uses logical functions and thus must be BLD and not Core or PRD. 
> However, one could have translated the English rule to RIF without using
> logical functions, e.g. permit_access(?x) instead of
> permit(access(?x)).  This should be explained.  Also, the PRD variant
> also uses a logical function, and so is illegal PRD.
> Suggestion: don't use logical functions (they aren't needed) and just
> present the Core dialect.
>
> there are many places that use "nested frame syntax" e.g.
> ex:provide("eShop" ?buyer[ex:card->?x ex:addr->?y])
> this is illegal.  must use And(?buyer[ex:card->?x ex:addr->?y]
> ex:provide("eShop" ?buyer)).  This is repeated in many places.
>
> I don't understand the translation of the last rule, which is an
> integrity constraint:
> never provide both birthdate and postal code
> I would translate it as
> integrityConstraintViolation("never provide...") :-
> providedBirthdateTo(?shop) and providedPostalCodeTo(?shop)
>
> BLD can be a little stronger and define
> 0=1 :- integrityConstraintViolation(?x)
>
> 4.3
>
> The first rule should use PRD's negation.
>
> misspelling: engergy
>
> These rules need to handle changing values over time.  I.e. a band may
> be available now, but not in a minute from now.  We can use production
> rules, whose truth values can change over time, or use BLD and an event
> calculus axiomatization.
>
> I would rather not assume an external function like detect energy.  I
> would model it as an ordinary frame or predicate with a timestamp.  But
> if it is external, it needs the External wrapper in the syntax.
>
> 4.4
>
> This "example" is weak and adds very little to section 4.1.  I would
> merge with 4.1 (mainly keep 1st 2 paragraphs of 4.4)
>
> 4.5
>
> all rules are integrity constraints so we need a standard phrasing of
> integrity constraints as rules (see preceding 4.2 comment)
>
> I think the first rule requires negation (PRD's for example)
> I think the other rules can be Core.
>
> 4.6
>
> Again, the use of logical functions puts this outside Core, but there
> isn't any deep need for logical functions here.  You could just as
> easily include T as the last argument of the predicates, I think.
> I don't think its wise to draw attention to the fact that Core lacks
> logical functions by using them in ways that are trivial to flatten.
>
> 4.7
>
> This is a trivial Core rule.
>
> 4.8
>
> This example has a confusing mix of rdf:type and #.  I don't think it
> needs to use both.  # is clearer (to non-rdf readers).
>
> 4.9
>
> These examples look like prolog with side-effects.  They should instead
> use PRD to modify (retract then assert) a score fact.
>
> It might also be nice to have a logical example, although its not very
> nice without aggregation.  Maybe we could use the proposed FLD
> aggregation here.
>
> 4.10
>
> These examples have nested membership forumlas (?Movie#ex:Movie).  These
> must be unnested.
>
> The examples imply that we have a standard way to call Java methods.
>
> The examples use other syntax shortcuts, like x,y instead of And(x y)
> and implicit universal quantification.  I hope we can make some of these
> standard in the PS.  But if not, these will have to change.
>
> 5.2  delete all the "motivated by" sections.  These are just clutter. 
> E.g., consider "RIF must be able to pass comments".  No use case seems
> to need this more or less than the others.  Yet we list 3 use cases that
> motivate this requirement.  That's just nonsense.
>
>