RE: [TED] Abstract Syntax and Abstract-to-Concrete Mappings

The Resolution from the 5th F2F Meeting

> RESOLVED: Equal aggregates 2 Terms (one association with multiplicity
= 2 in Core condition language diagram)
<http://www.w3.org/2005/rules/wg/wiki/WG_Resolutions>

asked to rename the two roles 'lhs' and 'rhs' into the neutral
role 'side' (I felt this wasn't a great idea because at one
point we'll want to express oriented equations, so we would
again need to be capable of distinguishing the left-hand side
from the right-hand side). Since asn has only had an n-ary
'list of', the spec had to make this assumption since then:

> The multiplicity of the side property (role) of the Equal class is
assumed to be exactly 2.
<http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions?action=re
call&rev=261>

In EBNF this was trivial to formalize -- an example of avoiding
unresolved dependencies.

There were more assumptions in the Slotted Conditions, e.g.:

> The above asn06 is generalized with a fixed-arity list constructor
(complementing the unfixed-arity list of constructor) so that the
multiplicity of the side property (role) of the Equal class no longer
requires the assumption of being exactly 2 (the 2 TERMs are just
listed). ... Also, optional of and subproperty constructs are assumed.
<http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions?action=rec
all&rev=75>

All of them were removed by just using widely-known
constructs from EBNF.

As discussed, the mapping is from the Abstract EBNF to
the Concrete EBNF without building in tokens such as '='.
Instead, it uses facts for the token table and equations
for the algorithm, both known from our own BLD formalism.
It specifies the mapping between Abstract and Concrete
parameterized by a token table, which also insulates the
7 tokens used in the Concrete EBNF for possible updates:

class2token('Equal','=')
class2token('type','^^')
class2token('Var','?')

class2token('Implies',':-')

class2token('slot','->')
class2token('Instance','#')
class2token('Subclass','##')

The wiki presentation has meanwhile been updated.

Your work on asn06, asn07, sbnf, ... has greatly helped us
to understand the relevant concepts and issues.

-- Harold


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Sandro Hawke
Sent: Monday, September 10, 2007 9:00 AM
To: Michael Kifer
Cc: Sandro Hawke; RIF WG
Subject: Re: [TED] Abstract Syntax and Abstract-to-Concrete Mappings 



kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
> Sandro, you are looking in a wrong place. Look at the abstract syntax.
> Instead, you are looking at a translation algorithm!

No, I don't think so.

Yes, I could have compared the abstract syntax.  In that case I would
have compared what's in the BLD draft...

   Equal      ::= 'Equal'
                    '('
                        'side' '->' TERM
                        'side' '->' TERM
                    ')'

to some asn07 like this:

    class Equal         
        property left: Term
        property right: Term

in which case I also have a strong preference for the asn07.

But, no, instead I chose to focus on the specification of the mapping
from abstract syntax to presentation syntax.  For that, I quoted the BLD
text which specifies the mapping for Equal and showed it with the a
single line of sbnf which performs the same function.  (The fact that
the text in BLD shows more of how to one might perform that
transformation, instead of *just* specifying it -- that surely accounts
for why it is so much more complicated -- but I don't see that as a
benefit.)

     -- Sandro



> > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > 
> > > "Sandro Hawke" <sandro@w3.org> wrote:
> > > > 
> > > > "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca> writes:
> > > > > 
> > > > > Based on the recent discussions, I updated the Abstract Syntax
by also
> > > > > just using EBNF and introduced Abstract-to-Concrete Mappings
for:
> > > > > 
> > > > > http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions
> > > > > http://www.w3.org/2005/rules/wg/wiki/Core/Horn_Rules
> > > > > http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions
> > > > > 
> > > > > Thus, unresolved dependencies on a future metalanguage for
defining
> > > > > the RIF Syntax were removed, especially in the Slotted
Conditions.
> > > > > This can now contribute to speeding up our editorial BLD WD2
work.
> > > > 
> > > > What's the advantage of this formalism over SBNF?  It seems much
more
> > > > complicated to me.
> > > > 
> > > >     - s
> > > 
> > > As far as I can see, this is a slight elaboration (and, perhaps, a
visually
> > > more convenient form) of your own proposal of a couple of weeks
ago.
> > > Can you explain where do you see the differences?
> > 
> > If you find this:
> > 
> >   class2token('Equal','=')
> >   abs2con4g('Equal'
> >             '('
> >                'side' '->' TERM1
> >                'side' '->' TERM2
> >              ')',
> >           TokenTable)
> >    =
> >     TERM1 lookup('Equal',TokenTable) TERM2
> > 
> > more "visually convenient" than this:
> > 
> >   Equal ::= left::Term '=' right::Term
> > 
> > then I have no idea where to begin this discussion.   
> > 
> > > (Your syntax was at times at odds with the formal syntax, and that
has been
> > > fixed. 
> > 
> > I think I was trying to match the BNF not the formal syntax, but
that
> > was just for illustration purposes anyway.
> > 
> > > Otherwise, the two seem basically isomorphic to me.)
> > 
> > They appear equalent in some essential ways -- a bit like C++ and
> > assembly are equivalent, I guess.  I have a pretty strong preference
for
> > one style over the other.
> > 
> >     -- Sandro
>

Received on Monday, 10 September 2007 14:42:28 UTC