[TED] ACTION-306: suggestions for abstract syntax

All,

Here are some proposed modifications to the abstract syntax, in 
completion of action-306 [1].

The modification I propose regards how to deal with quantifiers in an 
uniform way. The problem I see with the current abstract syntax is, 
indeed, that it may work for Horn rules, but it does not extend easily, 
because the universal and existential quatification are dealt with in 
completely different ways.

My suggestion requires adding a few generic classes such as 
"RIFstatement" (those class names can be changed, if they ar enot 
agreable to everybody), "Quantification", etc: I drafted (the skeletton 
of) a new section (wiki source attached), to be inserted either as a 
part of the RIF Overview or between the sections RIF Overview and RIF 
Condition Language. Being about generic classes, that section could and 
should probably end up in the RIF Arch document.

The proposed text also includes some remarks re extensibility and/or 
proposed future extensions.

Cheers,

Christian

[1] http://www.w3.org/2005/rules/wg/track/actions/306
= 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 QUANTIFICATION
    property declares : Var+
    property quantifier : QuantifierType
    property scopedby : RIFstatement

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

class QuantifierType
    
    subclass Exists

    subclass Forall
}}}

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 "Positive Condition" ===

The abstract syntax must be modified, for instance by replacing the ''Exists'' subclass of ''CONDITION'' as follows:
{{{
class CONDITION

    ...

    subclass QUANTIFICATION
        property quantifier : Exists
        property scopedby : CONDITION

    ...
}}}

The EBNF must be modified accordingly.

The semantics is not affected.

=== 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 QUANTIFICATION
        property quantifier : 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).***||

Received on Monday, 11 June 2007 15:45:02 UTC