Re: [RIF] A Modest Proposal: Work Out Some Concrete Examples; Example-1: CHANGE-BABY-IF-WET rule

Looking at the list below I am filled with a deep sense of foreboding.

Imagine, for a moment, a different possible domain: program  
interchange format. The goal of such a putative specification would  
be to permit the translation between Java, Python, C#, C++, LISP, and  
(why not) APL. Even though most programming languages have the same  
fundamental meta-model (turing-complete computation), the idea of a  
single interchange language supporting the exchange of programs is  
patently ludricous.

I would argue that the difficulties for interchanging rule languages  
are harder, not simpler, than those for programming languages:  
because all the difficulties associated with exchanging programs are  
exacerbated with quite different semantics.

There are other arguments too: whenever you exchange anything that is  
recursive or iteratively interpreted you open yourself to significant  
security risks. The reason being that in such an exchange the  
simplest way of comprehending the 'program' is by evaluating/running  
it - which is subject to the halting problem. But, without such  
comprehension, it is v. difficult to properly constrain the effects  
of running the program without also seriously limiting the scope.  
(That is why Java's sandbox is so restrictive.)

Possible options, as I see it are:

1. define Yet Another Rule Language. Of course, this is fun to do;  
but we already have so many of them.

2. define a meta-specification that can be used to encapsulate  
rulesets - for example explaining the language that the ruleset is  
written in, and its provenance etc.

3. define a specification that supports interoperation across  
rulesets - allowing rules in one ruleset to reference predicates and  
terms defined in other rulesets.

Frank McCabe



On Feb 1, 2006, at 12:03 PM, Michael Kifer wrote:

>
>
> Francois Bry <bry@ifi.lmu.de> wrote:
>>
>> I agree that RIF should have (1) a clear declarative semantics and  
>> (2)
>> in addition support conveying *some* *limited* specifications of
>> procedural semantics (eg backward chaining is intended because with
>> forward chaining the considered rules would require to process all/ 
>> too
>> many nodes on the Web).
>
> I disagree with that, especially with the statement that "with forward
> chaining the considered rules would require to process all/too many  
> nodes
> on the Web".
>
> This is all a matter for the query optimizer to resolve.
>
>> Back to RIF: I beleive RIF should give rise to express:
>>
>> - logical formulas in a FOL style (preferably using a rich syntax)
>> - intended use of the formulas (eg deduction rule, integrity
>> constraints, ontologies)
>> - intended negation (monotonic or non-monotonic)
>> - intended declarative semantics (eg Well Founded or Stable Model  
>> or FOL)
>> - intended truth valuations of all kinds (including discrete truth
>> valuations such as eg true/false, true/unknown/false,
>> known-tue/possibly-true/possibly-false/known-false as well as  
>> continous
>> truth valuations such as [0..1] 0 meaining false, etc.)
>> - schemas (in the acception of RDFS) ie what is also called sorts in
>> automated reasoning and logic (ie classes and sub-class relationships
>> and the like)
>> - name (not procedural semantics!) of the rule engine the rules have
>> been designed for.
>> - maybe further "properties".
>>
>> Of course, RIF should make it possible that some of the above is not
>> specified with a ruleset.
>
> Amen to that (although I am not sure that we will want to handle  
> all of
> that in the end).
>
>
> 	--michael
>

Received on Thursday, 2 February 2006 02:17:03 UTC