This is an archive of an inactive wiki and cannot be modified.

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:

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:

I think that covers the basic problem space.

Here's a rough proposal for an extensibility mechanism:

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:

  1. it includes without restriction the syntax of all the dialects it extends;
  2. 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

Composition of Dialects