• Arch
• Syntax

Syntactic Abstraction

TBC (Justify and explain the metasyntax)

However they may differ in their expressive power, their concrete syntax and their semantics, most rule languages share a lot at the abstract syntax level. RIF will be based on a common extensible abstract syntax and a standard way to derive a concrete XML syntax.

See also RIF Syntax

From Sandro http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0086.html

Extending the language described by a BNF grammar requires inserting a disjunction (alternate) into a production. In the asn06 model, it requires adding a new production (subclass). Arguably it's simple to think of an extension as just adding things (in any order), rather than as changing something.

To say that differently, when you're have a spot in the syntax where a "Foo" can go, do you want to say "a Foo can be a RedFoo, a BlueFoo, or a GreenFoo", or do you want to say "a RedFoo is a Foo, a BlueFoo is a Foo, and a GreenFoo is a Foo." The latter form seems preferable when you're expecting new subclasses of Foo to come along -- it doesn't suggest we're done listing the subclasses.

From Hassan http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/0083

C. THE RIF SHOULD ONLY HAVE ABSTRACT SYNTAX: IT SHOULD NOT BE CONCERNED

• WITH CONCRETE SYNTAX. Since I started my participation in this WG (i.e., December 2005), I have noticed a systematic confusion in many discussions by several members. Namely, some of us are still grappling with the question of whether the RIF should - or not - be a Just Another Rule Language (J.A.R.L.). This confusion has surfaced repeatedly either explicitly or implicitly, as is unfortunately likely to linger until we all agree. I personally think that the RIF should not be a J.A.R.L. and this for the follwing reasons:
• 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.

• 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).
    Thus, any debate regarding a specific concrete human-readable syntax (such as e.g., the RCL or HRL proposed by the REWERSE folks) is moot at best. The only issues that matter are the representation vocabulary to be used by RIF and its specification as an XML-based ontology. The onus of parsing/translating a concrete syntax to its RIF form is on the client Rule Language, not the RIF. The RIF is and must me a well-defined *target* AST representation *formalism* (rather than language) not meant for human consumption.
  • Finally, the (on-going) debate about the nature of symbols used for the RIF constructs (the name of elements, attributes, whether they should be simple identifiers, URI, IRI, or whatever, is (IMHO) pointless and technically vacuous. Basically, whatever the lexical *signature* of the ontology that will eventually emerge as that of the RIF is irrelevant to the main issue of specifying a correct and sufficiently complete vocabulary. (It is not even syntax, it is morphology.) This being said, it is important that we, in the RIF WG, do not reinvent ontological constructs that have been proposed in other related scientific venues that have aimed at defining some XML vocabularies classifying some forms of rules (i.e., RuleML, REWERSE, PRR, etc., ...). Still, the choice of words used for the RIF is "up to isomorphism" of the signature of symbols used for it. These lexical considerations are, at this point, trivial and obfuscate the central issue of classifying rule languages.

From ChrisW http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0135.html

Choosing the abstract syntax as the primary (though, again, perhaps non-normative) syntax appeals to me because it allows us to focus on certain aspects of RIF while postponing others. For example, we need to consider in Phase 1 how to integrate RDF into RIF (to the extent it is compatible with the CORE semantics). How will this be done? RDF only allows binary predicates, and treats unary predication as a special kind of binary predicate, e.g. the atom P(A) in a rule language would be expressed as type(A,P) in RDF. Do we define a mapping from RDF triples into RIF syntax, or does RIF carry RDF triples as RDF? We also need to consider how to transmit RDF data as ground atoms in RIF. Are we going to invent our own special RIF syntax for RDF triples, or are we going to invent a special RDF syntax for higher-arity predicates, or are some of our ground atoms going to be in RDF and the rest in our own syntax, or something else? Are rules going to look different than ground atoms? etc etc. We have not really begun to discuss the alternatives here.

By working at the level of an abstract syntax, we can postpone that decision and work on the current issues. It seems to me that we would need to directly address these questions if we are to have hope of a BNF syntax, and that the current BNF syntax already biases us away from some of the options for handling RDF (not to mention OWL) which we haven't discussed (it is biased because radical changes to the syntax would be needed if we went with some of the approaches). In an abstract syntax, we say something like

Atom::

• Predicate: term Args: list of term

GroundAtom::

• Args: NonVariableTerm

etc., without committing to a particular decision on how RDF ground atoms are to be treated specifically. We all know rules will have atoms in them and that the atoms may contain variables, etc., and there is considerable work that can be done without dealing with the specific problem of rdf-ground-atoms now.

Note of course that there are already a slew of other issues like the RDF one I use here that could have the same impact on a concrete (e.g. BNF) syntax, but far less impact on an abstract syntax.

Vocabularies

TBC (How do we interchange identifiers in application-specific vocabularies)

RIF will use URIs (IRIs) in the style of RDF and OWL, using them to identify at least: globally named predicates, functions, datatypes, constants (OWL individuals, not literal values), rules, and rulesets.

• Translators to and from languages which do not use URIs as names will need to use a name-mapping system (such as namespace prefixes)
• RIF does not mandate any particular mapping scheme. It will provide a metadata vocabulary to allow translators to record the mapping if they choose to.
  • For example, in rule systems where the predicates refer to fields of java objects the metadata annotations might be used to carry the java fully-qualified classname and field name.
  • For RIF these are purely annotations, any use of them for carrying semantic information steps outside of RIF.

Concrete Syntaxes