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 .

...

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 19:28:06 UTC