Re: [TED] ACTION-306: suggestions for abstract syntax

Gary Hallmark wrote:
> 
> I'm a skeptic.  I see no proof that this is more or less extensible than 
> what we've got.  I see evidence that it is somewhat more complicated.  
> By experience, I know that I'm not very good at designing for 
> extensibility.  In fact, I haven't found any reliable way to do it other 
> than designing the extensions and then subsetting them.  I've had 
> several embarrassing experiences where designing for extensibility 
> resulting in a complicated design that wasn't extensible, when I could 
> have had a simple design that wasn't extensible.

Fair enough. Actually, I do not claim that I designed this for 
extensibility; I mean, not for extensibility in general. I only tried to 
make it extensible wrt some specific extensions I had in mind. See below.

Trying to explain the benefits of my design, I came to two conclusions: 
first, that I am still struggling with the level at which we do the 
design, and I have probably to much of a meta-modelling approach; and, 
second, that the design I proposed was indeed flawed (that's the purpose 
of having a discussion, right? :-).

So, find a modified, improved, and much simplified proposal (does not 
require any modif to Condition anymore) attached. Now, for extensibility.

1. Existentials in Rules and universals in Conditions: my first concern 
was extending to existential variables scoped by rules and/or 
universally quantified variables scoped by conditions.

I added the class Quantification (could also have been named 
QuantifiedStatement) to avoid repeating the associations that are common 
to all quantifiers (to the scoping statement, the var etc), and to avoid 
repeating all the quantifiers where they are allowed.

The purpose of adding the class QuantifierType was to allow easy 
extension with whatever new, strange, and as yet unknown quantifiers you 
want :-)

These are probably metamodelling concerns we can do without, see 
attached modified proposal.

The motivation for adding the top, abstract class RIFstatement as the 
scope for a quantification is that the reference to the scoping 
statement is via a property, which makes it difficult to add other kind 
of statements that can scope a quantified variable. With the proposed 
design, you only have to add the new kind of statement as a subclass of 
RIF statement (I had CONCLUSION in mind, but that work for EVENT if the 
spec of a complex event can scope a quantified variable in some 
language, etc). I think that we need to keep that one, otherwise we may 
need to extend the properties of a quantifier.

2. Mixing quantifiers: My other concern was with mixing quantifiers 
scoped by a rule or, generally, ordering quantifiers scoped by a rule 
(something that is often used in production rules: the query, or filter, 
or pattern statement that restrict the instantiations of a variable - 
and that would be added a way or another in a PR extension - often 
depend on the previously declared variables). The standard case for 
ordering the declaration is, of course, when you mix quantifiers.

The way to do so, in the current design, is to allow scoping a variable 
declared by a forall to a rule, recursively, as is done for Condition. 
But then, you have 2 different "formula" properties for the same Forall 
(btw, I prefer scopedBy as a role name, to formula), which looks ugly.

The solution I propose is only to raise Implies (I prefer the more 
generic "ConditionalStatement") and Atomic (could be generalised to 
Conclusion to preserve extensibility) to be subclasses of Rules, beside 
Forall (and Exists, in the extended case). That way, we can recursively 
scope a Var declared by a Forall (or, by extension, an Exists) to a Rule 
without problem, and we get rid of the redundant CLAUSE...

Of course, with the simplified version, we may not need an additional 
section in Core...

Cheers,

Christian

= Variables and quantification =

There are a few high level elements that is shared by rules in most, and maybe all, rule languages. One such element is the notion of variable: the scope of a variable is the statement in which the variable appears free, and across which it is constrained to keep the same binding when interpreted; the quantifier associated to a variable tells how a variable must be interpreted, that is, with which bindings of the variables that it scopes a statement must be instantiated.

Variables can be scoped by different parts of a rule, especially the condition (or body, in a logic programming context) or the rule, ad how RIF deals with their declaration and scoping must therefore be defined before any other part of rules can be discussed. This requires that we define first what are the general classes of statements that RIF deals with, namely, at this stage: rules and conditions.

== Syntax ==

=== Abstract Syntax ===

The abstract syntax of the declaration of quantified variables is given in asn07 as follows:
{{{
class RIFstatement

    subclass RULE

    subclass CONDITION

class Var
    property varname : xsd:string
    property varDomain : DomainOfValue

class Exists
    property declares : Var+
    property scopedby : RIFstatement

class Forall
    property declares : Var+
    property scopedby : RIFstatement

}}}

The semantics of these constructs and the associated concrete syntaxes, as well as restrictions on their use, are specified in further sections of this document.

||<#80FF80> *** The property ''varDomain'' is included as a placeholder for the declaration of the variable's type, to be discussed ***||

||<#80FF80> *** Future extension: ''query'' property could be added to ''Var'', with a ''CONDITION'' (or some proper restriction of ''CONDITION'', to define allowed bindings for a variable. ***||

The abstract syntax is visualized by a UML diagram used as a schema-level device for specifying syntactic classes with generalizations as well as multiplicity- and role-labeled associations. Automatic asn06-to-UML transformation is available.

(add diagram here)

 ||<#8080FF> ***The addition of that section would imply some modification in the '''Positive Conditions''' and '''Horn Rule''' sections, such as the the ones proposed below. ***||

=== Modifications to "Horn Rule" ===

The abstract syntax for Core rules would need to be modified, e.g. by replacing the definition of the ''RULE'' construct by the following one:

{{{
...

class RULE

    subclass Forall
        property scopedby : RULE
  
    subclass ConditionalStatement          ## Notice that I preferred a name like ''ConditionalStatement'' to ''Implies', which sounds more like the name of a property to me.
        property if : CONDITION
        property then : ATOMIC

    subclass ATOMIC

...
}}}

 ||<#80FF80> *** Extensibility Issue: how do we extend a property? A solution would be to define instead, based on the assumption that extending by adding new subclasses is easy:***||
{{{
...

class RULE

    ...
  
    subclass ConditionalStatement          ## Notice that I preferred a name like ''ConditionalStatement'' to ''Implies', which sounds more like the name of a property to me.
        property if : CONDITION
        property then : CONCLUSION

    subclass Fact                                  ## ...or any other name for a rule where the condition is considered always true and thus omitted
       property then : CONCLUSION         ## (I would prefer avoiding naming it "Fact", however, as it evokes strictly a ground statement (at least to me)

class CONCLUSION

    subclass ATOMIC

...}}}
 ||<#80FF80> *** Notice that, if we adopt that approach, ''CONCLUSION'' should be added as a subclass of ''RIFstatement'' (for extensibility purposes).***||