- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Tue, 16 Jan 2007 16:03:11 +0000
- 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 UTC