W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2007

Re: Thoughts on RIF core, dialects, conformance

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Tue, 16 Jan 2007 16:03:11 +0000
Message-ID: <45ACF73F.2030208@hplb.hpl.hp.com>
To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>
CC: RIF <public-rif-wg@w3.org>

Boley, Harold wrote:
>> RIF Base is a RIF Dialect which we define in phase 1:
> 
> Let me suggest, to avoid confusion, to keep the term "RIF Core"
> for that core dialect, and come up with a new term such as
> Michael's term "RIF Foundation" for what appeals to you.

Fine by me.
Dave

> 
> -- Harold
> 
> 
> -----Original Message-----
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
> On Behalf Of Dave Reynolds
> Sent: Tuesday, January 16, 2007 11:12 AM
> To: RIF
> Subject: 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 16:03:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:35 GMT