Re: PRD review - Part 1 Syntax of Condition Language

Hi Adrian,

Thanx for you comments. Here below, some replies, requests for 
clarification, etc.

Adrian Paschke wrote:
> 1.  Does RIF-PRD extend RIF-BLD condition language or partially adopt 
> and specialize it to the needs of production rules representation?

Right, it does not extend BLD condition language, but Core. The ref to 
BLD is a remnant of the previous draft. I corrected it.

> 1.2.2. dialects extending RIF-BLD --> dialects extending RIF-PRD

No, the sentence is about RIF-BLD. It was copied from the previous BLD WD.

The question is whether we should remove all reference to signatures in 
PRD, since they are not used anyway? I added the question as a note in 
the text.

> 1.3.1. BNF syntax for PRD and BLD should be consistent (as well as for 
> any other “future” dialects)

Agreed. I propose to use that BNF-style pseudo-schema style for 
introducing the XML syntax, but I am not religious about the specific 
BNF: I re-used the one from another W3C spec (I copied 1.3.1 from WSDL, 
I think [1]).

[1] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#bnfpseudoschemas

> 2. In 1.2. we state that we “extend” RIF BLD condition language; in 
> chapter 2 we state RIF Core; if RIF Core would be a subset common to 
> both RIF BLD and RIF PRD we would strictly extend it.

Yes. Corrected in 1.2.

> 2.1. There are several new constructs introduced, such as ExTerm, 
> Aggregation (see discussion later)

ExtTerm is not an addition: only, it was not yet in BLD when I wrote 
this, so I took it from the builtins wiki page [2]. I will see with 
Harold and Michael that we have the same syntax in BLD and PRD.

Aggregation is, indeed, an addtion.

[2] http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins

> 2.1.1.1. we need to refer explicitly (e.g. by a link) to all things 
> which we adopt from BLD and which are defined there, e.g. we don’t 
> define LITERAL since it is adopted from and defined in BLD.

No, it is not defined in BLD either.

But, on the principle, I agree. As soon as we have a Core to refer to, 
all the constructs that are inherited from Core must link to their spec 
in Core.

> 2.1.1.1. we exclude Uniterm and introduce ExTerm; why do we need a new 
> construct here? we can reuse Uniterm also to define procedural attachments

Resolution from Telecon 11 December 2007:
RESOLVED: Go with Axel's option C, that is using a special syntax to 
distinguish evaluated functions/predicates from logical 
functions/predicates.

> 2.1.1.2. as for constants we should introduce a type attribute for 
> variables, so that only objects (individuals/constants) of the 
> appropriate type can be bound to the variable. An extra Subclass 
> construct is inappropriate for this since (1) it unnecessarily blows up 
> the XML code if you want it for type checks and more importantly (2) 
> since it is not implicitly associated with a variable it is dependent on 
> the order where you place the Subclass construct in a rule (i.e. the 
> outcome differs accordingly and it is impossible to ensure correctness).

In principle, I agree that it would be easier for PRD if Var had a type. 
But BLD does not have them, and BLD has the Member construct, hence the 
proposal to follow BLD on that. I added a note, anyway.

As regards you point (2), I think that the semantics is specified in a 
way that excludes that risk. An example where it fails would help us 
correct it, if it does not.

> 2.1.1.2. In the informal semantics we only allow variable bindings to 
> values and individuals (btw we are not consistent in the use of the term 
> individual vs. value vs. constant), but variable bandings in the sense 
> of an explicitly defined variable renaming are need in certain 
> applications (e.g. for large classes of rule-based machine learning 
> approaches).

Ok. I added a note, so that we do not forget the issue.

Can you provide an example where variable binding is used to explicitely 
refine a variable renaming? That would help me understand the use case.

> 2.1.1.3. Most modern logic derivation rule engines support some kind of 
> procedural attachments to call external functionalities, so we should 
> discuss if a construct such as ExTerm (note: I’m not discussion the name 
> of such a construct here – we could e.g. reuse Uniterm) would also make 
> sense or even would be necessary for the “logic RIF” (but that would 
> probably not be “Core” – so what would be the relations?)

I do not understand that comment: BLD has buildin functions and 
predicates, like PRD; and Core is likely to have them too, so that the 
relation is simple: both BLD and PRD inherit them from Core?

> 2.1.1.3. we state that ExTerms on the level of TERM are interpreted as 
> evaluated functions (as opposed to evaluated relations under ATOMIC); in 
> general I agree with this statement, but depending on the data model and 
> type system of the externally called system this might be ambiguous 
> (note e.g. the distinction of matching two Java instances (objects) of 
> the Java class Boolean returned by a Java function as compared to 
> truth-valued relations). We should add some further clarification here.

No sure I understand what you mean, here. Can you explain further?

> 2.1.1.3. in the presentation syntax we introduce “APPLY”

Yes. Corrected, see my reply to Garry.

> 2.1.1.3. we need to handle exceptions of function calls in PRD and 
> explicitly describe that

I disagree (but Gary is on your side :-).

Let's continue that discussion in a separate thread (I will respond to 
Gary's "ball of fire" question in a separate mail).

> 2.1.1.4. in the informal semantics we mention procedural attachments; 
> maybe we should add a short explanation what this is, e.g. a footnote.

My copy does not have a 2.1.1.4...

:-)

Yes, see reply to Gary: we must make the terminology consistent and add 
a glossary.

> 2.1.2.1. The distinction in PRD between ExTerm and Uniterm seems to me 
> unnecessary, since Uniterm as the name indicates was introduced to cover 
> both relations and functions on the level of “ATOMIC” and “TERM”
> 
> 2.1.2.2. see 2.1.2.1

See 2.1.1.1, above.

> 2.1.2.1. we say that we exclude named arguments. There is a huge class 
> of production rule systems, e.g. all CLIPS derivates, which support 
> something like named arguments. [...]

Do you want to raise an issue?

> 2.1.2.3 in the last RIF telecon we decided for BLD to use Equal also for 
> assignment of objects (e.g. returned by function calls) to variables. 
> This much more declarative then having an extra Assign construct for 
> assignment and one for Equality testing. For instance, if a variable 
> used as first argument in Equal is bound it would be an equality testing 
> comparing both objects, if the variable in the first argument is free it 
> would be an assignment of the second argument to the variable (including 
> also variable renaming assignments).

There are no free Vars in PRD, but I think that the result is the same 
as what you would get with what you describe, anyway. Notice that Assign 
is an action allowed in the then part only, and using the Equal 
construct instead would be using the same construct with a different 
semantics...

Not that I am happy with the current proposal for Assign, btw; but 
that's a different question :-)

> 2.1.2.4. There is a need for an explicit Member and Subclass construct 
> so we should keep them – but as I have written in the discussion of 
> variables these constructs are not adequate for type checking

Do you keep by your comment after reading the semantics (and my reply, 
above)? If yes, it probably means that I did not fully understand what 
you meant: can you be more specific, please?

> 2.1.2.6. The definition of Frames should be common for both, BLD and PRD

It is, isn't it?

> 2.1.3. I agree negation as failure is needed to have a sufficiently 
> expressive rule language to describe real-life problem (btw: I also see 
> the need to the logic BLD). But when it comes to Naf things get much 
> more complicated and we need to give semantics for that (will discuss 
> this later in the semantics part)

I agree that it would be nice if BLD could have the same kind of 
negation as is needed in PRD, but we decided not to include it because 
it is where logic rule languages start to diverge (and thus it cannot be 
included in what is meant as a common basis).

> 2.1.3.2. We say that a CONDITION can be a conjunction of zero or more 
> statements. What would be the meaning of an empty condition? What 
> benefit do we get to allow empty Conditions if there is not extra 
> information it would carry, e.g. in an attribute field?
> 
> 2.3.3.3. similar to And

Agreed. I kept that possibility for compatibility with BLD (and, I 
assume, with Core).

> 2.1.3.4. If we introduce Naf, which I think we should do, we need to 
> give a good semantics to it (discussion later)

Agreed. That's what I tried to do :-)

> 2.1.4. If we exclude Forall in the condition language of PRD we only 
> address the very standard production rule systems, but there are also 
> hybrid systems on the market including systems mixing forward-directed 
> production rules and backward-reasoning (and many other using e.g. magic 
> sets, compilation approaches, …)  and when it comes to event-based 
> systems we can not easily build on PRD (but that’s a foresight).

Right. But my understanding is that PRD is supposed to address the 
standard PR systems. Non standard features should be dealt with in 
extensions. But we have to be careful that PRD can be extended to 
include them. You seem to think that event-based systems could be 
problematic: can you be more specific? (I see, indeed, a potential 
problem with extensibility to ECA rules, but that is in section 4.2.2; 
so, any hint of earlier problems would help).

> 2.1.4.1. Aggregation is newly introduced in PRD (as compared to BLD); 
> Aggregations are important, but not only for PRD; at least as a kind of 
> “findall” (as in Prolog derivates) is urgently needed to really work 
> with logical lists and also quite often in meta programming. So we 
> should start a discussion about that. And I don’t see why we need a new 
> extra construct for aggregations – why not using built-ins within 
> Uniterm (keeping the syntax minimal)

On Aggregation, see also my reply to Gary [3].

Re using builtins within Uniterms instead: yes, I can imagine such a 
syntax. But, although minimising the syntax is an objective I share, I 
would oppose it, because it would be using the same syntax for two 
different purposes and with two different semantics, which I tend to see 
as the epitome of bad design.

[3] http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0088.html

(to be continued)

Cheers,

Christian

Received on Tuesday, 19 February 2008 12:18:50 UTC