W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2007

Re: Approaching an XML syntax for RIF

From: David Z. Hirtle <dhirtle@cs.uwaterloo.ca>
Date: Mon, 29 Jan 2007 21:37:41 -0500
Message-ID: <95f576e70701291837ob959eccu8aa4a98049f2efdd@mail.gmail.com>
To: "Dave Reynolds" <der@hplb.hpl.hp.com>
Cc: "Sandro Hawke" <sandro@w3.org>, public-rif-wg@w3.org

Hi Dave,

> > The basic approach I'm exploring is "Stripe-Skipping".
>
> This is the bit I'm less happy with, I've three issues.

One thing to keep in mind (perhaps you already are): it's trivial to
translate between a stripe-skipped version and non-stripe-skipped (or
vice versa) with XSLT since, as Sandro pointed out, the skipped
elements only convey redundant information.

Dave

On 1/29/07, Dave Reynolds <der@hplb.hpl.hp.com> wrote:
>
> 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 Tuesday, 30 January 2007 02:37:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:35 GMT