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

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.

Christian de Sainte Marie wrote:

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

-- 


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

Received on Monday, 11 June 2007 18:28:30 UTC