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

Received on Tuesday, 11 November 2008 22:07:36 UTC