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

Ed Barkmeyer 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.
>  
>
What might well be "more conventional semantics"? There are two kinds of 
model theories used for formalizing the declarative (ie non-procedural) 
semantics of programming/rule languages:

1. ad hoc definitons fo models eg well-founded and stable model 
semantics. I agree that they are not easy to understand.

2. Tarskian model theories, ie the valuation (= truth value) of a 
formula is recursively defined on the structure of the formula. Such 
model theories are intuitive and much easier to understand than other 
formalisms unsed in formalazing the "meaning" of programs.

>>>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.
>  
>
Disjunctions in consequents is a well-understood isssue -- if the rule 
is used as Integrity Constraint (ie to specify eg that "a customer pays 
cash or with a VISA credit card". ). Please, please, do not exclude 
Integrity Constraints from the scope of RIF! Integrity Constraints are 
everywhere around in databases and information systems: have a look at 
amazon.com and you'll see the integrity constraints behind the scene.

>>>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.
>  
>
I agree. But let us have a RIF giving room to new interpretation. Let us 
look at a concrete example. Bank A has its own regulations (=rules) RA 
about granting loans. Bank B has other rules RB for granting loans. RA 
union RB might eg be inconsistent. Nonetheless, Banks A and B might be 
interested in interchannigng the rules RA and RB so as to perform somne  
sort of paraconsistent reasoning with RA union RB so as to investigate 
how they could join efforts in some way. Doing this, tthe banks of 
course cannot and will not rely on the rules engines they usually use.

My point is that rules on the Web, what RIF is all about, will make it 
much easier to interchange knowledge and data so as to invbesztigate new 
issues that, without interchange on the web would be much more 
complicated to investigate.

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

>>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.  
>
I disagree. Consider again my two examples above:

1. the semantics of an integrity constraint like "a customer pays cash 
or with a VISA credit card" can be formally defined without specifying 
how it is processed (= evaluated, or =cheked).

2. interchanging loan granting regulations between two banks does not 
require to know (=specify, =interchange) how each bank process these 
regulations. THis especially applies if, like in my example above, the 
goal of interchanging the regulation is not to grant loans but instead 
to investigate how the two regulations interact with each other.

What is the point here? A full-fledge semantics of a LP, like of any 
processable language, is based on assumptions on the processing (= the 
rule is used as integrity constraint, the rule is used for deriving new 
information, etc. An interchange language might well be more abstract in 
the sense of making much weaker assumptions ab out the proocessing (eg 
not requiring that a rule is only used as an integrity constraint). I am 
advocating for a RIF with such a "more abstract semantics".

-- 
Francois

Received on Thursday, 9 February 2006 07:49:35 UTC