This page is proposed to be obsolete, replaced by Arch/Extensibility2.
Multiple dialects
TBC (Why do we have dialects, and how they relate)
First, there is a common core of rules that can be expressed in most rule languages and on the semantics of which they agree. That core seems to be, basically, positive Horn rules. That is rather limited, but it covers already a lot of the rules that will be usefully interchanged. It does not mean that it covers many, or even any, useful ruleset, but it as RIF Core dialect, it will guarantee a minimum level of rule interchangeability between RIF-compliant implementations.
RIF Core is positive Horn
There are broad families of rules languages that differ mostly by their concrete syntax and their expressive power, but that share a much broader common core: production rule languages, families of logic programming languages etc.
Once we have RIF Core, we will standardize a limited number of dialects that extend RIF Core for important families of rule languages. Which ones exactly is not yet decided, but, broadly speaking, there will certainly be at least one for the logic programming familly of languages and at least one for the production rules family.
Notice that the dialect do not create islands, since they are all extensions of the common core. In addition, it might be possible to define partial mappings between some of the dialects, thanks to their limited number.
Notice further that rule language owners, industry bodies etc will be able to specify their own extensions: they will not be standard RIF dialects, or not necessarily; but they will benefit from the forward/backward compatibility that comes with being a RIF-compliant dialect.
Forward Compatibility
A RIF dialect is forward compatible if a conformant implementation will process instances of any future or unknown extension according to the specification of the said extension.
(From Sandro http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0031.html
The requirement might be phrased like this:
- RIF must be extensible, so that implementations can be forward compatible, continuing to operate well when given RIF dialects which use extensions unknown to the implementation.
The wikipedia page on forward compatibility has some discussion of this issue: http://en.wikipedia.org/wiki/Forward_compatibility (Their page on extensibility refers only to extensible systems, not to extensible formats.)
Forward compatibility is essential to allowing a format to grow in a large, decentralized environment like the web. Without it, the decision to use an extension in some document is also a decision to entirely exclude the base of users using software which does not implement the extension.
Document format evolution, without forward compatibility, proceeds in ponderous steps where everyone has to install new versions of the software. In constrast, if RIF implementation are forward compatible, the decision to use an extension can be based on the particular characteristics of that extension, and an awareness (from the RIF standard) of how implementation will handle your rules when they don't implement the extension. Forward compatibility means progress can be incremental instead of revolutionary.
The simplest approach to forward compatibility, in general, is to mark each extension as "must-understand" or "may-ignore". For example, an extension which introduces negation probably falls under "must-understand", since if you were to ignore the syntactic elements of a ruleset which used negation, the meaning of the ruleset would probably be quite different from what was intended. On the other hand, an extension which annotates rules with the last date they were modified would be a "may-ignore" one. In general, the term "annotation" is used to cover syntactic elements which can safely ignored. (This matches RDF well, since RDF is generally processed with the notion that any triples you don't understand can be safely ignored.)
I think RIF can do better than this general must-understand/may-ignore approach. Here are some intermediate categories:
- an extension which affects the semantics, but ignoring it wont
- give you any incorrect results -- just fewer results. (This is only possible if your dialect is monotonic, I think.) Whether you ignore this or not is something to ask the user.
- an extension which affects performance, so you'll get the same
- answers/actions, but the performance will be significantly worse. Again, you can probably ignore this, but you should warn the user.
- an extension which affects the presentation, but not the
- semantics. So a reasoner can ignore it, but a system which shows the ruleset to a user needs to warn the user.
- an extension which offers syntactic sugar. This
- overlaps the other categories -- ignoring it might affect the semantics, the performance, etc, -- but perhaps an XSLT script can be provided which rewrites out the sugar, so systems which don't implement the extension but do have XSLT handy can, in effect, download an implementation of the extension. (This suggests one could get extreme here and allow extension to include, say, JVM code for a reference implementation. I'm not proposing that, however.)
I think that covers the basic problem space.
Here's a rough proposal for an extensibility mechanism:
- when you're parsing RIF XML and see a syntactic element you don't
- recognize, you turn it into a URI (by concatenating the namespace part and the local part of the element tag) and dereference the URI to get information about the syntactic element. The information includes, at least, the consequences of ignoring the element (as above).
- as a work-around for dereference not being available, RIF
- documents could include that information as well.
Backward Compatibility
A RIF dialect E is backward compatible if a conformant implementation of E will process instances of any RIF dialect D according to D's specification if E is an extension of D.
A RIF dialect is backward compatible if:
- it includes without restriction the syntax of all the dialects it extends;
- and the semantics of its syntactic restriction to the syntax of one of the dialects it extends implies the semantics of that dialect.
QUESTIONS: Any other way to guaranty backward compatibility? "Implies" is shorthand for any consequence allowed by the semantics of the restriction must be allorwed by the semantics of the extended dialect. Must that be "equivalent" instead? Of implied by?
Reusable Components