Re: proposed: use abstract syntax notation (asn06)

> Hassan Aït-Kaci wrote:
> > 
> > I agree 100% with Gerd's point - and Sandro. RIF is not about concrete
> > syntax, it is about abstract syntax (Please refer to POINT C in ACTION-87
> > http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/0083.html.
> > We need to define classes and attributes, and API- that sort of things
> > - not any particular surface syntax. Isn't this the *very need* for
> > a RIF? Viz., *interchange* of *disparate concrete surface syntaxes*
> > through a *common AST format* called ... the *Rule Interchange Format*,
> > a.k.a. RIF! :-)
> > 
> > I also agree (again) with Franck McCabe. As I wrote in the above
> > cited reference:
> > 
> >>    I personally think that the RIF should not be a J.A.R.L. and this
> >>    for the follwing reasons:
> >>
> >>    1. The RIF, being an Rule *Interchange* Format purporting to support
> >>       interoperability among rule languages, is a formalism for
> >>       expressing all the essential concepts making up rules and rulesets
> >>       that need to be represented. As I tried to explain in my original
> >>       quote from Peter Landin's "The Next 700 Programming Languages"
> >>       (and as Frank McCabe recently reminded us), the RIF is a language
> >>       space in which specific (rule) languages are to be mapped.
> >>
> >>    2. Such mappings are typically realized by parsing some RL's specific
> >>       *concrete* surface syntax into an *abstract* syntax representation
> >>       using elements of a RIF ontology. Such an abstract syntax is the
> >>       closest one may speak of "syntax" when sepaking of the RIF. Indeed,
> >>       by *RIF syntax* one should not mean human-readable syntax, but
> >>       some representation thereof based on a consensual vocabulary.
> >>
> >>       Importantly, such an abstract syntax, contrary to usual concrete
> >>       syntax,
> >>
> >>          (a) is non-linear (i.e., it is tree- or graph-based);
> >>
> >>          (b) is not human-readable (i.e., it will be XML-based);
> >>
> >>          (c) has well-defined semantics allowing one or several
> >>              operational interpretation;
> >>
> >>          (d) must be consensual (unlike concrete syntaxes that
> >>              can me mapped into a RIF-compliant AST).
> > 
> > My 2 cents,
> 
> Hi,
> 
> wouldn't most of these arguments for an abstract syntax
> be fulfilled by some RDF-based schema language? Ok, RDFS (contrary to
> its name) and OWL are not useful as (OO) schema languages, but such
> a language can easily be derived from them by using their primitives
> in a different namespace and defining the semantics simply to be
> that of a OO schema language.
> 
> Sandro's example would thus look like this (in N3),
> using "sl" for the schema language:
> 
> rif:Condit a sl:Class .
> 
> rif:Litform sl:subClassOf rif:Condit .
> 
> rif:Atom sl:subClassOf rif:Litform .
> rif:rel sl:domain rif:Atom ;
>          sl:range rif:Identifier ;
>          sl:cardinality 1 .
> 
> rif:Quantif sl:subClassOf rif:Condit .
> rif:? sl:domain rif:Quantif ;
>        sl:range rif:Var ;
>        sl:minCardinality 1 .
> 
> ...

Looking at such a syntax and comparing it to BNF, my reaction is:
why the hell do we need this trouble?


	--michael  


> As a side effect, we would automatically have a concrete
> RDF-based syntax for rules. Other concrete syntaxes (like
> an XML-based one) could be automatically generated from the schema
> (which would have to be annotated for this to indicate
> the concrete element names, ordering etc.).
> 
> Michael
> 
> 
> > 
> > -hak
> > 
> > Gerd Wagner wrote:
> > 
> >>> I think what you are trying to define is an ontology for rule parts
> >>> (or maybe a UML-like diagram). This is fine and useful, but I don't 
> >>> think it is a substitute for a concise BNF. 
> >>
> >>
> >> Sandro is right with observing the insufficiency of EBNF as compared 
> >> to MOF/UML, which is a bit more abstract (e.g. in its way not to imply 
> >> any order of expression components)
> >> and more expressive, e.g., by clearly distinguishing between
> >> references and components and by allowing to attach contraints to 
> >> syntax elements, while at the same time
> >> providing more readable syntax definitions.
> >>
> >> As OWL 1.1 is following R2ML (www.rewerse.net/i1) in using MOF/UML for 
> >> the abstract syntax definition (although, probably since they are 
> >> still a bit unexperienced, they are making a few mistakes such as 
> >> using the white diamond
> >> instead of the black diamond for composition, or not
> >> suppressing the visbility symbols), RIF should also follow
> >> this move and make both a MOF language model and an EBNF
> >> grammar, instead of trying to reinvent the wheel with developing some 
> >> other (non-standard) method.
> >>
> >> In the REWERSE project, several working groups (not just I1)
> >> have choosen MOF/UML as the abstract syntax definition
> >> language that can be complemented with EBNF.
> >>
> >> -Gerd
> >>
> >>
> >>
> >>
> > 
> > 
> 
> -- 
> Michael Sintek -- DFKI GmbH, Kaiserslautern
> http://www.michael-sintek.de -- sintek@dfki.uni-kl.de
> phone: +49 631 205-3460 -- fax: +49 631 205-4910
>

Received on Monday, 13 November 2006 21:06:02 UTC