Re: PRD review, part 1 and 2

Hi gary,

Continuing from where I stopped Friday night...

Gary Hallmark wrote:
> 
> 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.

The Aggregation construct is meant to represent the specification of 
aggregate bindings for variables. I do not know whether logic rule 
languages bind variables to aggregate values, but I infered (maybe 
erroneously) that it was, at least, not a basic feature, since it was 
never discussed in connection with Core ro BLD (whereas it is quite 
basic in PR languages).

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

That is because the "declare" role of QUANTIFICATION constructs 
represents the fact that the declared variable must be bound (and the 
QUANTIFICATION construct specify which tuples of bindings need be 
considered) that I propose to make the Aggregation construct a target of 
that role: if the target of a declare is immediatly a Var, it means that 
the declared Var has simple bindings; if it is an aggregation, it means 
that the declared Var has aggregate bindings.

I considered other options, like having two kinds of Var to be declared 
(the normal Var to declare simple bindings, and an AggregateVar for 
aggregate bindings), but it is not satisfying, because, except for the 
value to which it binds, the Var has exactly the same properties as a 
simply bounded Var...

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

Yes, if your AggregationMode is the COUNT function and your target Var 
has 0 candidate bindings, then the aggregate value of your declared Var 
will be 0, as expected.

> But 
> maybe your intent was simply to reuse the <declare>.

Indeed.

> May Aggregation should be a QUANTIFICATION?

No, Aggregation cannot be a QUANTIFICATION: Q specify which tuples of 
bindings have to be considered to determine the truth value of the 
formula in its scope; an Aggregation specifies how to determine the 
binding a a single Var.

> 2.2.
> 
> For PRD conditions, I think equals, member, and subclass are builtins
> (not actual data in WM)  and have a "fixed interpretation" as far as
> the rules are concerned (the rules can't change the interpretation).
> In my PR system, we have something called the datamodel that provides
> these interpretations.  The datamodel is typically used by many
> rules/rulesets.
> WM contains ground COMPOUND Uniterms  and ground COMPOUND (basic) frames.

Yes, of course, you are right: they (equal/members/subclass/data 
types/data models) are more akin to builtins than to data. I put them in 
the WM for the purpose of specifying the semantics only: it has nothing 
to do with how it is implemented in real PR systems, in the same way as 
I put the extension of builtin functions and predicates in the WM too. 
It is purely conceptual, in order to be able to specify the semantics 
unambiguously and in a way that is completely neutral wrt the 
implementation (e.g., it would be feasible, if not efficiently, with 
finite domain fct/predicates, but not with infinite domain ones).

So, the idea is to put, conceptually, all the knowledge/information that 
is needed to specify the smeantics into some store (that I named WM by 
reference to most PR systems working memory, but maybe that is an error 
and it shoul dbe named with a neutral name, to avoid any possible 
confusion).

I think I will change the abreviation "WM" for something else, to avoid 
the ambiguity.

> I find the semantics hard to understand.  The semantics in the simpler
> case of no quantifiers (save for an enclosing forall) [...]

That's a good idea. I will add something like that in the introduction, 
for us to see how it works.

> A tricky thing to specify is in what order are the tuples of T
> processed [...]

Did you write this before reading the semantics of rulesets or after? If 
after, it means that the draft must be really bad :-)

> 3.
> 
> Many PR systems have "truth-maintenance". [...]

Right. Is that basic/pervasive enough that we should have it in the 
"basic" PRD? I will add a note.

In any case, I do not believe that it is necessary for a first public WD 
(with the appropriate note).

> 3.1.1.3.
> 
> I don't know what this is for.  [...]

Ok. Personnaly, I think that we should not have it (Update), but find 
another way for systems that need it to interchange the info.

> 3.1.1.4.
> 
> seems like there are 2 use cases here:
> 1. builtins with side-effects are kept out of rule conditions and
> can only be in rule actions.  But what builtins are we talking about,
> other than assert, remove, etc.?

E.g. Print, Notify, and probably many more.

> 2. modularity: common sequences of actions can be factored into a
> "user defined builtin" and invoked from several rule actions.  But
> you'd have to create a way to define and interchange the user
> defined builtin.

Yes, users will need a way to define and interchange user defined 
buitlins, data models etc. But that is out of scope for RIF, as far as I 
can see.

> 3.1.1.5.
> 
> In my PR system, assign to a frame slot (aka a java bean property) is
> not the same as removing and asserting (or just re-asserting) the frame.
> Assert will activate rules whose conditions reference *any* frame slot,
> whereas assign will activate rules whose conditions reference the
> assigned slot.

Not sure I understand: can you give me a simple example?

> 3.2.2.
> 
> I think the semantics of actions should talk about what they do to the
> ground facts (uniterms and frames) in WM.

Isn't it what it does? Hmmm... That's what I attempted to do, anyway :-)

The action part needs quite a lot of work anyway. So, we will discuss at 
the F2F how best to specify it.

> 4.1.
> 
> There should be some nontrivial intersection of PRD and BLD rules with
> exactly the same syntax and semantics (even though the semantics is
> written down differently, test cases should give the same answers).
> Otherwise, I think we will have failed...

I agree with "with exactly the same semantics..." and with 
"Otherwise...". As regards "exactly the same syntax...", in principle, I 
agree too (because Core must not need to know PRD to be able to process 
PRD rules that are in the intersection with Core - where Core is defined 
as the intersection between PRD and BLD), but I see two snags:
- Assert VS head (but we could decide that an eligible ATOMIC that is 
not the target of a specific ACTION construct is an Assert);
- Roundtripping (for rules in the intersection of BLD and PRD, you can 
move the binding patterns to the conditions without changing the 
semantics; but what about roundtripping?).

(And that is assuming that we resolne the naming differences one way or 
another, of course :-)

> 5.1.2.
> 
> I think we need to adjust the syntax so that no transformations are needed. 

yes, but... (see above).

Thanx for your comments. I will update the draft tomorrow (sorry, I had 
no time to work on that today).

And I will look at Adrian's and Michael's comments tomorrow, too. 
Hopefully, there is some redundancy with your own comments and I will be 
able to come up with a freesable version before the telecon :-)

Cheers,

Christian

Received on Monday, 18 February 2008 22:03:53 UTC