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

Here is the ASN I  propose:

class Ruleset
   property formula : list of RULE

class RULE

   subclass Forall
      property declare : Var+
      property formula : Implies

   subclass GROUND_ATOMIC

class Implies
   property if: CONDITION
   property then: ATOMIC

---- following is added to Positive Condition ASN ----

class GROUND_TERM

   subclass Const

   subclass GroundUniterm
      property op : Const
      property arg : list of GroundTerm

class GROUND_ATOMIC

   subclass GroundUniterm

   subclass GroundFrame

class GroundFrame

    ** To be done when Frame ASN is finalized **

---- Here is the existing Positive Condition Syntax, which is unchanged ----

class CONDITION

    subclass And
        property formula : list of CONDITION

    subclass Or
        property formula : list of CONDITION

    subclass Exists
        property declare : list of Var
        property formula : CONDITION

    subclass ATOMIC

class ATOMIC

    subclass Equal
       property side: list of TERM

    subclass Uniterm

class TERM

    subclass Var
        property name: xsd:string

    subclass Const
        property name: xsd:string

    subclass Uniterm      
        property op: Const
        property arg: list of TERM

Gary Hallmark wrote:

>
> I like the ability to have ground facts not wrapped in a forall.
> I don't like the ability to have free variables (not scoped in a forall)
>
> To me, a better solution would be have rulesets consist of ground 
> facts and implications.  Implications must be wrapped in a forall and 
> ground facts must not be wrapped in a forall and must not contain 
> variables.
>
> Is the intent of an ATOMIC formula with variables to be a query?
>
> From the spec: an ATOMICformula, for representing facts, that is, 
> Implies where the then-part is always true and is omitted, by convention;
>
> Doesn't this represent a query?  Isn't a fact an Implies where the 
> IF-part is always true?
>
> Christian de Sainte Marie wrote:
>
>> All,
>>
>> after the useful discussion yesterday (well, useful at least for me), 
>> I stand by my proposed modification of the abstract syntax for Core 
>> rules.
>>
>> I can see the benefits of it. Not even mentionning extensibility and 
>> future usages:
>> - it is simpler (does not need the CLAUSE class);
>> - it allows everything that the current model allows and more (with 
>> the current abstract syntax, a ground fact must still be wrapped 
>> within a Forall);
>> - it does not break what already exists (I did the modifications in 
>> the text that the modification of the model requires, see [1] for the 
>> result and [2] for the diff with the current "Horn_Rule" page).
>>
>> On the other hand, I do not see any inconvenient.
>>
>> I am less confident wrt the other part of my proposal, summarized in 
>> the Quantificaton2 diagram in my previous email on the subject [3]. I 
>> will discuss the questions I have on that subject after yesterday's 
>> discussion in another email.
>>
>> Cheers,
>>
>> Christian
>>
>> [1] http://www.w3.org/2005/rules/wg/wiki/Core/Horn_Rules_Alternative
>>
>> [2] http://www.w3.org/2005/rules/wg/wiki/Core/Horn_Rules
>>
>> [3] 
>> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/att-0026/Quantification2.png 
>>
>>
>

-- 


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 Wednesday, 13 June 2007 18:28:19 UTC