PRD review, part 1

This covers approx. the first half of the spec, up to but not including 
2.2. 
Hopefully I'll be able to finish tomorrow (and it won't invalidate the 
following :-)

General comment: in the wiki-tr version, most of the links are broken, I 
think because they are relative and thus link to, e.g., 
http://burns.w3.org/2005/rules/wg/wiki/CamelCase

The comments below are organized by section number.

1.

One thing to add to the overview is what kind of semantics PRD will have.

1.2.

RIF-PRD doesn't strictly extend RIF-BLD condition language (e.g. no 
logical functions)

1.2.2

I don't know what compatibility of PRD and BLD means.  Presumably there 
is some common core.  I think this core will be small and simple enough 
that signatures does not come into play.  The less said about 
signatures, the better.

The terms "individual" and "constant" sometimes seem to be used 
interchangeably, but really "object" is meant for individual..  
"Individual" should be defined (or use object, which is probably more 
familiar to PR folk)

If we do say something about signatures, I think "However, dialects 
extending RIF-BLD will be allowed" should be "However, dialects 
extending RIF-PRD will be allowed".

1.2.3.

BLD has no structure diagrams and XML is derived from the presentation 
syntax.  Why diverge here?

1.3.1

This looks like another "stylistic" divergence from BLD that needs to be 
reconciled.

[ and ] are used to form groups -- I think you need to escape the [ and 
] because it renders as a hyperlink

2.

[ RIF-Core ] should be a hyperlink, but it isn't.

2.1.

In the diagram, some lines that cross at right angles connect, and some 
don't.  This is confusing.

if PRD and BLD could agree on how to represent the syntax, it would be 
easier to verify (refute) the assertion that PRD's condition language 
extends BLD's.  It would also avoid repetition.

To the extent that PRD conditions are a superset of BLD's, then we 
should just describe the extensions (naf, aggregation) and not repeat 
the BLD descriptions, just point to BLD.  E.g., BLD recently renamed 
ATOMIC to COMPOUND.  Because we have repeated descriptions and syntax, 
we have many places to update in PRD.

2.1.1.

In preventing logical functions (Uniterm TERMs), have we also prevented 
nested frames (Frame TERMS)?  That's not good...

2.1.1.1.

exactly the same as BLD, right?

2.1.1.2.

I think ..--.. is a valid NMTOKEN, so I'm not sure this restriction 
helps much.

I don't think ? is legal in an NMTOKEN (but since the spec uses hex 
chars, I didn't exhaustively check)

2.1.1.3.

builtin function, evaluated function, or fixed interpretation function, 
... need consistent terminology

Isn't the syntax 'Builtin(' Uniterm ')'

The syntax and semantics should be exactly the same as BLD.

Why is the op a TERM rather than a Const?

2.1.2.2.

consistent terms: builtin, evaluated, or fixed interpretation relation

I prefer Const op only.

links are broken, e.g. [X F&O]

not defining behavior when args are out of domain hinders interoperability

2.1.2.3.

most PR systems have builtin equality (sides must be bound) and builtin 
assignment (in actions).  This "logical equals" is something more.

2.1.2.4.

object and class makes more sense to me, too.

My PR system has a builtin # predicate and a builtin "new" function that 
takes a (constant) class as an argument and returns a new object.  This 
"logical #" is something more.

2.1.2.5.

My PR system has a builtin ## predicate and a builtin class declaration 
function that takes a (constant) class as an argument and returns a new 
subclass.  This "logical ##" is something more.

2.1.2.6.

slotKey might be a case where a Uniterm TERM makes sense, if it can 
represent a frame "method".

I don't think the syntax diagram in 2.1 allows nested frames (disagrees 
with the presentation syntax here)

2.1.3.4.

My PR system is forward chaining.  It doesn't prove anything.  The 
informal semantics is simply that its truth value is the opposite of the 
truth value of its CONDITION.

according the syntax, there can be no empty NAF.

2.1.3.5.

is this needed in addition to 2.1.4.2.?

2.1.4.

I suspect that aggregation is at least as important in logic dialects as 
in production rules.  That is because logic based languages are 
frequently used for querying, and querying frequently uses aggregation. 
Consider SQL and, to a lesser extent,  prolog.

I would rather wait a bit and work to make sure we don't diverge too 
much here.  I find the linking of aggregation and quantification 
confusing.  I guess a SUM doesn't exist if there isn't anything to sum, 
but the COUNT exists and is zero if there isn't anything to count.  But 
maybe your intent was simply to reuse the <declare>.  May Aggregation 
should be a QUANTIFICATION?  (I suspect my questions are adequately 
reflecting my confusion :-)


-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204