A vision for the RIF

Dear All,

This is a try to clarify issues discussed again and again in the past, as Christian yesterday in our telecon askeed me to do. In the following, I discuss the following issues: 

1. Data accessed. 
2. Syntax. 
3. Rules: What means a "rule language", what kinds of rules are needed.
4. Semantics and Realtionship to RDF.
5. Semantics and Relationship to OWL. 


1. Data accessed. 

In my opinion, the RIF should make it possible to access XML, RDF and OWL data. Adding to this list Topic Maps would be a good strategic move, I think. 

Accessing RDF and OWL means taking them with their semantics. Concretely, this means that a property like the transitivity of the sublcass relationship in RDF should be part of the RIF semantics, ie should not have to be encoded by RIF programmers. Accessing data without their semantics would be very similar to saying: `I speak English but for me "table" means a kind of animal'. 

2. Syntax. 

In my opinion, the RIF should make it possible to access XML, RDF and OWL data both (1) expressed in their established syntaxes and (2) expressed in some human readable, user friendly syntax. For example, a RDF triple s p o shgould better be expressed like eg (s, p, o) instead of any other more complicated manner like eg rdf-triple(s, p, o). 

This of course means that implementing RIF will require to implement XML, RDF, and OWL parsers. This is a rather simple task especially because such parsers as well as parser generators are available. 

Looking at RDF syntaxes with colleagues, we found more than 20 variations. This is a considerable number. I could well imagine that not all of them be supported by the RIF. 

3. Rules: What means a "rule language", what kinds of rules are needed.

In my opinion, the RIF should be a "rule language" in the following senses: 

(a) The RIF should make it possible to express in a natural manner deduction rules (also called "constructive rules" and similar to database views), normative rules (similar to database integrity constraints), and reactive rules of the form Event-Condition-Action (or ECA) rules. 

Deduction rules are necessary as a basic mean for simple form of deduction which RDF (and by the way Topic Maps) applications urgently need. Normative rules are absolutely necessary for controlling the evolution of RDF stores. If we fail to give the RIF the capability to express normative rules, then 
most business rule applications will not be expressible in the RIF what will considerably slow down the Semantic Web ermergence. Reactive rules of the form ECA are urgently needed both (1) for expressing "production rules" as needed by most business rule applications, and (2) for propagating reactive information (in the form ofevents) between Web sites. 

(b) its logic, or reasoning, should be restricted to "constructive logic", ie to deduction procedures like SLD resolution, that can be expressed without "refutation" and/or "exccluded middle". 

This second point is a widespread, standard understanding of rule languages, Horn logic, logic programming, etc. Giving it up would make the RIF a very stange animal in the world of rule languages and thus slow down its acceptance by practitioners and scientists alike. 

4. Semantics and Relationship to RDF. 

A clearly defined compelling declarative semantics is indispensable for the RIF, otherwise (1) its usage would be seriously restricted and (2) incompatible implementations would emerge. 

In my opinion, this declarative semantics should be expressed in the well established form of a fixpoint and equivalently of a minimal model semantics for Horn deduction rules. Such a choice would require further decisions, which, I think could be made as follows, as far as XML and RDF (and Topic Mapds) data are concerned: 

(a) termination: An interpreter of RIF deduction rules should terminate if the deduction rules' consequents do not include blank nodes, containers, aggregated values, and any other data constructors ("function symbols" in logic programming and "functors" in Prolog). Else, under certain other syntactic conditions, ie decidable conditons that can be checked at compile time, termination of an 
interpreter of RIF deduction rules could be required as well. 

(b) evaluation strategy and procedural semantics: should be left open to the implementors so as (1) to give room to optimizations that are not yet known, (2) to give room for an evaluation involving computations at different Web sites (eg in presence of RIF deduction rules accessing several distributed RDF stores), (3) to give room for different evaluation strategies. In particular, the no selection functions (that specify the order in which expressions are evaluated in conjunctive antecedents of RIF deduction rules) should be specified for interpreter of RIF deduction rules. This approach is the same as the one retained in defining database query languages eg SQL what has left room for the very lively field of SQL query optimization. 

The above would make the logic of RIF deduction rules "constructive" (in the sense of "constructive logic"), ie their evaluatuion would not require "refutation" or "excluded middle". Such a constructive logic for the semantics of RIF deduction rules would have at least four advantages: 

(a) This would be perfectly in phase with a common understanding of deduction ruler languages (eg SLD resolution of logic programming and Prolog is expressible in constructive logic). 

(b) This would make the RIF different from and complementary to OWL (the interpretarers/reasoners of which go beyond constructive logic). 

(c) This would make it possible to specify the semantics of normative rules in the very same, and rather simple manner, of database integrity constraints. 

(d)  This would make a specification of the semantics of ECA RIF rules simple, in the very same manner this is usually done for production and ECA rules.  

5. Semantics and Relationship to OWL. 

The declarative semantics of RIF deduction rules accessing OWL data seems to me a more delicate issue       for two reasons. First, a semantics based on constructive logic should be retained for 
RIF deduction rules accessing OWL data. Second, RIF deduction rules should not be the same as OWL formulas, for avoiding a redundancy rthat no one, especially programers/users would not understand. A simple way out would be to offer two alternate ways for RIF deduction rules to ccess OWL data: 

(a) Either without their semantics. 
(b) Or with their semantics but only by querying (by procedural attachement) an OWL reasoner. 

In the case (b), I would suggest to leave it to the programmer whether, considering the semantics of the OWL data accessed, the RIF deduction rules are meaningful or not. Any other apporach would amount to make the RIF encompass OWL, ie be a kind of fourth flavour of OWL. I doubt such an extension to OWL is desirable. 


Most likely, some essential points are missing in the notes aobve. However, I hope they will give a basis for the emregence of a common vision of the RIF in our Working Group. My belief is that, with the necessary additions, the above would be good basis for a RIF that would (a) fullfil requirements of practitioners, especially implementers of business rule application, (b) nicely and meaningfully complement RDF and OWL, (c) realizable in the given very short time (a significant part of it is already gone). 

Regards, 

Francois

Received on Wednesday, 19 April 2006 07:59:02 UTC