RE: A Rule Interchange Format VS a Rule Language for Interoperability and other issues

> As regards indeterminate truth values, I do not know: could 
> you give me 
> an example where you need indeterminate truth values to 
> express a rule?

Such an example (from the Car Rental case study) was already 
presented in [1]. It's the rule "A car is available for rental 
if it is not assigned to any rental order and does not require 
service", which contains two negations (the first is NAF, but
the second is not NAF).

This rule refers to an optional Boolean-valued attribute/property 
"requiresService", which may have an undeterminate truth value 
(it may neither have the value TRUE nor the value FALSE, i.e. it 
may have the value NULL in SQL). In UML, this attribute would
be declared as 

	requiresService[0..1] : Boolean

while in an SQL table definition it would be defined as

	requiresService  Boolean	

Imagine that a car technician has to judge if a car requires 
service or not. So, simply because there was no judgement yet 
for a particular car does not mean that the car does not 
require service. In that case the 3-valued Kleene negation 
employed by SQL gives as a result of applying negation

	NOT(undetermined) = undetermined

so the above rule would not fire (which is the correct behavior).

One could say that the SQL negation operator NOT behaves like
Kleene negation in the case of an optional Boolean-valued 
attribute, and it behaves like classical (2-valued) negation
in the case of a mandatory Boolean-valued attribute.

This corresponds to the CycL concept of a closed class,
expressed with "#$completelyAssertedCollection" as pointed
out by douglas foxvog in an earlier mail on this list. 

-Gerd

[1] Harold Boley, Jing Mei, Michael Sintek, Gerd Wagner: 
RDF/RuleML Interoperability, W3C Workshop on Rule Languages 
for Interoperability Position Paper: 27-28 April 2005,
http://www.ruleml.org/w3c-ws-rules/rdf-ruleml-w3c-ws.html

Received on Thursday, 25 August 2005 23:51:11 UTC