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

RE: Thoughts on RIF core, dialects, conformance

From: Paul Vincent <pvincent@tibco.com>
Date: Tue, 16 Jan 2007 10:19:16 -0800
Message-ID: <8F4A4531BB49A74387A7C99C7D0B0E0501DF7282@NA-PA-VBE02.na.tibco.com>
To: "Dave Reynolds" <der@hplb.hpl.hp.com>, "RIF" <public-rif-wg@w3.org>

+1

Thanks Dave for a very useful summary of the RIF Core discussion. 

The main issue I have had in previous discussions has been the assumption that RIF Core = RIF Horn as an executable dialect/language, which implies that RIF for PR (and probably others) is not Core "compliant", with the consequence that RIF immediately becomes less interesting for the commercial PR engine market and the CSF/goal of widespread adoption is skewered. Not to mention the implied fundamental (for a supposed standards body) issue of "appearing" to "favor" one group of members' interests at the expense of another.

RIF Base is an interesting concept, in the idea that maybe it is some superset of mainstream rule concepts. Hassan's paper seems to provide a useful basis for a superset representation, if I am not misunderstanding them. This could mean that the need for additional dialects is much reduced (or the dialect effectively represents a particular semantic interpretation of the RIF Base interchange format).

Paul Vincent
TIBCO - ETG/Business Rules 
 


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Dave Reynolds
Sent: 16 January 2007 15:12
To: RIF
Subject: Thoughts on RIF core, dialects, conformance


[PV>] ...

** 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 18:19:52 GMT

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