Re: [RIF] [UCR]: What is the RIF (revisited)

On 8 Feb 2006, at 11:49, Francois Bry wrote:

>
> Peter has been right to state the following, I think:
>
> a. RIF should have a formal syntax.
> b. RIF should have a formal semantics.
>

what is formal? Why not "well-defined" in the sense "If you give me a  
set of rules, I can see what you meant by them, eg, which are its  
consequences" -- what I do with them is, of course, up to me. For  
example, I can use them with a different semantics.

> IMO, the following can be added:
>
> 1. RIF's formal semantics might, and may be should, be more  
> abstract than those of existing processable rule languages. Eg  
> making it possible to express "negation as failure" without  
> choosing between Stable Model and Well-Founded semsntics.
>

but this choice will make a difference, and thus not explicating it  
might lead to confusion! E.g., if I have a set of rules which reflect  
some piece of knowledge, and I want to "sell" it to you, you need to  
know how to read these rules: otherwise, you might draw conclusions  
that should not be drawn or you might not draw conclusions that  
should be drawn...

> 2. RIF could allow for rules the processing of which goes beyond  
> what currently is widespread. Eg rules with disjunctive conclusions.
>

I agree

> 3. One reason for not delivering RIF with (the specification of) a  
> processor is that a same rule can be used in different manners,  
> each requiring different processors. Eg a rule stating that "all  
> members in the RIF WG speak English" can be used for deriving that  
> I speak English, ie been used as a deduction/derivation rule, or  
> for checking if the requirement is enmfoprced, ie been unsed as an  
> integrity constraint. In many practical cases, it makes very much  
> sense to import, say deduction/derivation rules from a context/ 
> application A, and to use them as integrity constrainbts in a  
> context/application B.
>

I partly agree - but still, it would be useful to be able to describe  
the "intended" reading of (a set of) rules -- even though we can then  
use them in an un-intended way.

> My conclusion:
>
> Let us design a RIF with a formal language, a formal semantics  
> leaving room for re-interpretations 9as examplefied above under 2  
> and 3), and let us *not* define (or specify) a processor for RIF.

My conclusion:

Let us design a RIF with a well-defined syntax and semantics which  
allows us to describe the intended reading (ie, its consequences) of  
a rule set -- whilst being open for re-interpretation. Please note  
that "describing the intended reading" does not mean that we need to  
specify a processor: to describe the reading of "\models" in first  
order logic, we don't need to specify a theorem prover...

Cheers, Uli

> -- 
> Francois
>

Received on Wednesday, 8 February 2006 12:04:04 UTC