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

Uli has it right, I think.

Uli Sattler 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,

This is the requirement.  Now we will surely argue about the form of a 
"well-defined semantics".  I like model theories, but even the theorists agree 
that it is hard for anyone to read them.  The reason for the hard mathematics, 
however, is that it resolves *all* the cases, and does not leave all the 
pathological cases to the reader's (or engine's) way of thinking.  So perhaps, 
like OWL, we need both a true model theory, and a more conventional (and 
perhaps somewhat less well-defined) explication for the software builders.

> eg, which are its "consequences" -- 

Hmm.  Well, depending on how one interprets that word, this may be exactly the 
sticking point for rules languages.

> what I do with them is, of course, up to me. For  
> example, I can use them with a different semantics.

I would have said: I can convert the ruleset in such a way as to convey the 
known-to-be-intended semantics to my reasoning tools.  Or I can convert them 
with known semantic "gains" or "losses" (which I believe will be irrelevant to 
the conclusions I draw and the actions I take, although I may be wrong).

>> 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...

Exactly.

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

Here, milady, we part company.  I could agree with the example, but not with 
the principle that Francois expresses.  I agree with Dieter that we should not 
go out of our way to support expressiveness that is beyond the power of 
available tools to work with.  We will have enough on our plate to deal with 
commercial rules engine expressiveness, SWRL, OWL and RDF.  We should leave 
the next generation of Ph.D. research to the universities.

If the choice is supporting disjunctive consequents and having a RIF model 
theory in 6 months that we can all accept, I'll take the latter.  And I don't 
want extra syntax for expressions that a rules author would be ill-advised to 
use if s/he expects any automated interpretation.  But I don't mind it if the 
syntax and extended interpretation fall out of a consistent and complete 
language and semantics for the target "rulespace", and we simply place 
"dialect" restrictions for use by certain kinds of engines.  (This is the OWL 
view and the CL view.)

>> 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.

Uli has it right.  I must be able to know exactly what you mean.  How I make 
use of that information is not your concern.

> 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.

To be more comfortable agreeing, I would edit this slightly:

Let us design a RIF with a well-defined syntax and semantics which
allows us to *communicate* the intended reading of a rule set --
whilst allowing for "extended" interpretation, e.g., into a larger knowledge 
base with a possibly different class of inference engine.

> 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...

Unfortunately, to define the semantics of some LP languages, we end up 
specifying the processing algorithm.  But I agree that RIF should strive to 
rise above that, as the creators of OWL (ultimately) did.  The trick, and it 
is not easy, is to specify WHAT is enabled by the HOW that is dear to the 
engine builder.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."

Received on Wednesday, 8 February 2006 15:27:27 UTC