Re: Approaching an XML syntax for RIF

Hi Sandro,

I think something along these lines can work but I'm going to nit pick a 
few details first.

Sandro Hawke wrote:
> Continuing the discussion from November, I suggest that we approach
> the XML syntax of RIF Core like this:
> 
>    1.  Specify the abstract syntax for RIF Core in asn06.  (This
>        abstract syntax specification can also be thought of as an
>        ontology of RIF Core rules and as an object model/API for RIF
>        implementations.  It's my belief that it's close enough to both
>        of those: there may be some little semantic differences, but I'm
>        hoping they wont manifest as a real problem.)
> 
>    2.  Design a mapping from asn06 to an XML schema language.
> 
>    3.  Use the mapping in (2) to turn the asn06 spec (1) into an XML
>        schema/grammar for RIF.

Agreed.

You later talk about one category of benefits - simple dialect 
specification from which an XML syntax follows automatically).
There is a second benefit, extensibility. In the asn06 approach a 
dialect can extend the structure of a condition, rule etc just by adding 
new subclasses. An old version processor can parse an extended new 
version structure without knowledge of schema and then (in principle at 
least) go check whether the extensions are within its scope or not. I 
think this is a useful benefit but it affects how you do step (2).

> I've been working on step 2.   (Mostly I've been writing programs to do
> the mapping in step 3, and read and write the resulting XML syntax.)
> 
> The basic approach I'm exploring is "Stripe-Skipping". 

This is the bit I'm less happy with, I've three issues.

First, it looses, or at least weakens, the extensibility. For example if 
your class currently only has one property so you stripe skip and then 
some extension dialect adds a subclass with a new property you can't 
stripe skip in the extension. That breaks the forward compatibility.

Second, any sort of dynamic skipping (which would be a partial way round 
the above issue) causes confusion and painful mismatch with XML tools.

Third, without stripe skipping the parse structure is largely 
self-describing - you can parse an unknown dialect and then go lookup 
semantic annotations for the new classes and properties to see if the 
bits you don't understand are semantically significant. I say "largely" 
because you don't need type annotations for the literals to achieve that 
benefit.

[The first and last issue may be the same :-)]

The cost of not stripe skipping is a little more verboseness but to me 
that's an acceptable price in the XML format.

By the way, if neatness of the XML is an issue then there is a different 
trivial simplification possible: use an attribute for any property which 
takes a single literal value (name, ref etc).

> Here's an asn06 specification of the Condition language, with input
> from Harold, but he hasn't see this version.
> 
> ================================================================
>     
>     default namespace rif = "http://www.w3.org/2007/01/rif#"
>     
>     class Condition
>     
>         subclass And
>             property formulas : list of Condition
>     
>         subclass Exists
>             property declare : list of Var
>             property formula : Condition
>     
>         subclass Atom
>     
>         subclass Equals
>             property equated : list of Term
>     
>     class Composite
>         property parts : list of Term
>     
>         subclass Atom
>     
>         subclass Term
>     
>     
>     class Term
>     
>         subclass Expr
>     
>         subclass Var
>             property name : xsd:string
>     
>         subclass Con
>             property ref : xsd:anyURI
>     
> ================================================================    

That doesn't describe Expr and has Term as a subclass of Composite which 
doesn't seem right.

Did you mean:

      class Composite
         property parts : list of Term
            subclass Atom
            subclass Expr
?

[Something we shouldn't worry about at this stage but will need to 
eventually resolve is whether names should be text (things which could 
have language tags) or strings as you have it there. If names should be 
round tripped and appear in rule editor UIs then they will need i18n 
support and so should probably be lang taggable.]

> Harold has updated the XML example on the Positive Conditions page [1]
> to match this asn06 declaration.  (My software's not working right now,
> so I haven't mechanically checked that it is correct.).  Here it is, as
> of right now:
> 
> ================================================================
>  <And>
>     <Exists>
>       <declare><Var>Buyer</Var></declare>
>       <formula>
>         <Atom>
>           <Con>purchase</Con>
>           <Var>Buyer</Var>
>           <Var>Seller</Var>
>           <Expr>
>             <Con>book</Con>
>             <Var>Author</Var>
>             <Con>LeRif</Con>
>           </Expr>
>           <Con>$49</Con>
>         </Atom>
>       </formula>
>     </Exists>
>     <Equal>
>       <Var>Seller</Var>
>       <Var>Author</Var>
>     </Equal>
>   </And>
> ================================================================

Those Con's don't look much like xsd:anyURIs to me, especially $49.

> For comparison, a fully-striped version would look something like this:
> 
>  <And>
>     <formulas>
>        <Exists>
>           <declare><Var><name>Buyer</name></Var></declare>
>           <formula>
>             <Atom>
>                <parts>
>                    <Con><ref>purchase</ref></Con>
>                    <Var><name>Buyer</name></Var>

Or fully striped with the attribute short-cut you would have:

   <And>
     <formulas>   # formulae?
       <Exists>
         <declare><Var name="Buyer" /></declare>
         <formula>
           <Atom>
             <parts>
               <Con ref="Purchase" />
               <Var name="Buyer" />

Dave

Received on Monday, 29 January 2007 22:02:56 UTC