Re: proposed: use abstract syntax notation (asn06)

Michael Kifer wrote:
> 
>> 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?

Hi,

I did *not propsose* this syntax, I only said IMHO it fulfills
the arguments some people braught up, including
"a) is non-linear (i.e., it is tree- or graph-based);
(b) is not human-readable (i.e., it will be XML-based)"

Esp. (b) is nicely fulfilled (when using RDF/XML serialization),
as you just pointed out :-)

N3 was meant to simplify RDF/XML syntax for
communication in emails etc., but obviously fails in some
cases. I don't think that we then should go for something
*completely* different, but just try to remedy this by
extending N3 for a few stereotypical things like class
definitions with their properties, e.g.

rif:Quantif sl:subClassOf rif:Condit .
rif:? sl:domain rif:Quantif ;
       sl:range rif:Var ;
       sl:minCardinality 1 .
rif:? sl:domain rif:Quantif ;
       sl:range rif:Condit ;
       sl:cardinality 1 .

could become something like this in "N3++":

rif:Quantif :: rif:Condit
   rif:? : rif:Var + ;
   rif:? : rif:Condit + .

Of course, we have to be careful for properties that are
used on more than one class; intersection of the domains
obviously does not do the job (but this just shows that we
have to be careful if we define some new abstract syntax without
relating it to an existing, well-defined modeling language).

BTW, Sandro, does your syntax also include a syntax for "instances", i.e.,
for concrete rules?

Michael


> 
> 
> 	--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
>>
> 
> 
> 
> 

-- 
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 22:38:09 UTC