Re: production rule object creation actions and frame axioms

Paul Vincent wrote:
>> Unlike RIF frames, with typical PRD objects,
>>
>>     * classification is externally defined -- you can't have a rule
>>       "forall ?e (?e # Employee :- exists ?i (?e[empNo->?i))"
>>     
> [PV>] Clarification: classification by class hierarchy is externally
> defined (for example in the Java class or XSD). However, I can always
> have a "classification property" as a text field in a class. Of course,
> I lose inheritance etc if I do that, and in practice I will normally be
> using the same fixed object model for source and destination anyway...
>
>   
doesn't matter how you represent the classification - the point is that 
the rules do not affect the classification (that's what "externally 
defined" means)
>>     * the cardinality of object:slot is 1:1 -- forall ?o ?x ?v1 ?v2
>>       (?v1=?v2 :- ?o[?x->?v1 ?x->?v2])
>>     
> [PV>] Surely a "slot" refers to a frame.attribute (or object.property)
> pair? Objects can have multiple properties so I would expect the
> cardinality of object:slot to be n:1 - a slot is associated with only a
> single object, but an object can have associated with it multiple slots
> (o.p1, o.p2, ...). 
>   
I should have said the cardinality of  slot:value is 1:1 (that is what 
the rule says).
In other words, RIF frames have the peculiar (from a javabean 
perspective) property that a slot is multi-valued (or that slot keys can 
be repeated), whereas the object model in most non-semweb products use 
single-valued slots (and slot keys must be unique within an object).
Hence the need for frame axioms to "tighten up" the RIF object model to 
make it correspond to the object model in the target rule language.
>  
>   
>>     * a datamodel (typically not expressed in rules) associates slots
>>       with the class, e.g.
>>       forall ?o (exists ?s ?i (And(?o[salary->?s empNo->?i]
>>       ?s#xs:decimal ?i#xs:string)) :- ?o#Employee)
>>     
> [PV>] That wording gave me a problem too - data models don't define
> slots per se, but data and attribute relationships that are the
> equivalent of slots. But maybe I'm being too pedantic! 
>
>   
I don't want to argue about what a datamodel is, but to the extent that 
RIF can represent datamodel-like things, we should do so.
>> Joe#Employee
>> Joe[salary->40000]
>> ?e[salary->?salary * 1.1] :- And(?e#Employee ?e[salary->?salary]
>>     
> ?salary
>   
>> < 48000)
>>
>> With frame semantics, a model is Joe[salary->40000 salary->44000
>> salary->48400].  With Javabean/PRD semantics, we must have a final
>> configuration with only Joe[salary->48400] (or maybe
>>     
> Joe[salary->44000]
>   
>> ??)
>>     
> [PV>] Of course, that is a pretty ambiguous rule from a production rule
> perspective. For example, the rule engine may only "execute" the
> following (and PRD source rule, I hope) rule once, as the state of the
> condition does not change after the 1st rule execution. 
>
> If 
> 	?e is some Employee
> 	?e.salary < 48000
> Then
> 	?e.salary = ?e.salary * 1.1
>
>   
It is only ambiguous if we fail to define the semantics!  Right now, we 
have a BIG PROBLEM, because ILOG and Oracle/Jess disagree about the 
semantics.  With Oracle/Jess, you end up with a salary of 48400, whereas 
with ILOG I understand you will get 44000.

Received on Wednesday, 13 August 2008 18:52:02 UTC