[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 Monday, 10 November 2008 21:58:05 UTC