Thoughts on RIF core, dialects, conformance

In preparation for the discussion I see on the agenda for today I tried 
to get the current status a little clearer in my own head. This  may not 
be accurate nor useful for others but just in case ...

** Summary of issues

o There will be many different forms of tools working with RIF - 
editors, pretty printers, rule engines etc. Here we're only going to 
talk about RIF rule engines by which we mean a combination of a rule 
engine for some existing language plus a translator which translates 
between a fragment of that language and a RIF dialect.

o We have at least two notions of how a given RIF rule engine might 
conform to a RIF dialect. I think Michael calls these "conforms" and 
"implements"; I'll use "complies" and "implements" to avoid prejudging 
the definition of "conformance".

o A RIF rule engine complies with RIF dialect D if there is a 1-1 
semantics-preserving mapping from the engine's language (L) into (not 
necessarily onto) D. Where "semantic-preserving" might mean preserving 
the set of atomic consequences of all translated rulesets.

o A RIF rule engine implements a RIF dialect D if there is a reverse 
mapping from D into L which preserves semantics. So the engine 
implements all of D, correctly.

o Some people expect RIF conformance to mean both "complies" and 
"implements". So if A and B both claim full conformance with D then any 
rule set in LA can be correctly translated into D and then into LB and 
vice versa. Let's call this "strong interoperation". Though note that LA 
is just the fragment of A's native language implemented by the RIF 
translator for dialect D, both A and B's native languages may still have 
"proprietary" features which are outside of D.

o Some people expect RIF conformance to mean "complies". For any engine 
A which complies with D you also need to know the subset of D which it 
covers. Two implementations can interoperate in the strong sense above 
only over the intersection of the features of D they cover. An engine 
which compiles with D but does not implement D may raise an exception 
when given a ruleset which uses a feature it doesn't handle.

o RIF Core is the base of all RIF dialects. If this is thought of as the 
intersection of all RIF dialects then any engine that implements a RIF 
dialect implements RIF Core. There has been some argument that if the 
set of RIF dialects includes a reasonable subset of the existing rule 
languages then that intersection is nearly empty or at least too weak to 
be of use to anyone.

o The specific issue that triggered a lot of this is the extent to which 
existing production rule engines can implement recursive Horn rules and 
so whether RIF Core should be RIF-Horn-without-recursion. Given a target 
query pattern (or some other context of use information) then a PR RIF 
translator can implement recursive horn rules but may be non-terminating 
for unrestricted queries. So either RIF has to convey that context of 
use, or the issue of ruleset termination is outside of RIF conformance, 
or we need some other notion of RIF Core.

** Discussion

I'm sympathetic to the desire for strong interoperation, implementing 
not just complying with RIF dialects. If everyone implements different 
subsets of a dialect then navigating that space will be hard.

I'm sympathetic to the desire for there to be at least one simple RIF 
dialect which lots of people, not necessarily everyone, could implement.

I can see the argument that the intersection of all reasonable RIF 
Dialects may be empty.

There are various possible solutions to this involving profiles, 
extension by restriction and so on. However one approach which seems to 
be implicit in the discussion intuitively appeals to me, viz. to change 
the notion of RIF Core so that it is no longer a dialect.

In this approach RIF core defines:
   - an extensible abstract syntax for rules
   - a semantics (which may be parametrized, for example in the way 
Hassan's CLP suggestions are flexible in choice of constraint language)
   - a library of datatypes and associated functions, operators and 
builtin predicates

All RIF conformant engines would comply with RIF Core.

A RIF Dialect:
   - starts from RIF Core
   - it may select a subset of features
   - it instantiates it (defines appropriate sorts, if RIF Core is based 
on CLP then it specifies a constraint language, etc)
   - it may extend it using the syntax extension hooks and providing 
semantics for the extensions

A RIF engine may implement a RIF Dialect.

RIF Base is a RIF Dialect which we define in phase 1:
   - it is an instantiation of RIF Core as above
   - it is intended to be implementable by an interesting range of rule 
systems and provide strong interoperability between them
   - it is largely Horn with functions
   - it could be Horn without recursive rules if we want it to be 
implementable by a wide range of production engines
   - it could be Horn without functions if we want it to be 
implementable by Datalog engines

We hope that many RIF dialects will be extensions of RIF base but do not 
require all to be.

In this nomenclature the architecture document proposed by the chairs 
[1] becomes a description of RIF Core.

The details are lacking and the names might be bad (perhaps the names 
should be RIF Architecture, RIF Dialect and RIF Core) but is something 
along these lines at all reasonable?

Dave

[1] http://www.w3.org/2005/rules/wg/wiki/Arch

Received on Tuesday, 16 January 2007 15:11:55 UTC