W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2008

Re: AW: AW: [PRD] ACTION-531 Update PRD examples complete

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Tue, 24 Jun 2008 15:06:00 -0700
Message-ID: <48616FC8.7020707@oracle.com>
To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>
CC: Christian de Sainte Marie <csma@ilog.fr>, Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>, "pu >> RIF WG" <public-rif-wg@w3.org>

I don't think this works -
1. I don't see a way to retrieve the ID in a rule condition
2. I don't see a way to assign an ID when the valve predicate is in a 
rule head and the predicate arguments are variables

Instead, I think we'd have to translate all n-ary relations to n+1-ary 
relations and designate the first argument to be the ID "generated" by a 
Skolem function, e.g.

valve(valveID(?x ?y) ?x ?y) :- And(P(?x) Q(?y))

Boley, Harold wrote:
>> It is the "tuple ID" of a matching tuple in the "valve" relation. ...
>>     
> . . .
>   
>> I don't suppose we can quickly add IDs to BLD relations?
>>     
>
> We are about to finish their introduction as one application of
> optional IRIMETA (* ... *) annotations for Atoms:
>
> Group
> (
>   (* "http://sample.org/tupleID1"^^rif:iri *)
>   valve(v1001 open)
>
>   (* "http://sample.org/tupleID2"^^rif:iri *)
>   valve(v1002 closed)
> )
>
> -- Harold
>
>
> -----Original Message-----
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
> On Behalf Of Gary Hallmark
> Sent: June 24, 2008 2:30 PM
> To: Christian de Sainte Marie
> Cc: Adrian Paschke; 'pu >> RIF WG'
> Subject: Re: AW: AW: [PRD] ACTION-531 Update PRD examples complete
>
>
> Christian de Sainte Marie wrote:
>   
>> Adrian Paschke wrote:
>>
>>     
>>> Actually,
>>>
>>> ?f1 <- (valve ?v open)
>>>
>>> in Clips means: Match a valve fact whose first parameter is variable 
>>> ?v and
>>> second parameter is constant 'open'. When you find a match, then ?f1 
>>> is the
>>> ID of this fact which can be used in the head of a rule to assert it,
>>>       
>
>   
>>> i.e.
>>> ... -> assert(?f1)
>>>       
>> I still do not get it: if ?f1 is a fact, you cannot bind it to a 
>> variable without reifying it. If it is not, what is it?
>>     
> It is the "tuple ID" of a matching tuple in the "valve" relation.  BLD 
> doesn't have such a notion, so we have to decide how to "simulate" it 
> using either relations or frames.
>
> In some cases, the tuple ID is only used to retract the tuple, and so a 
> RIF translator could replace Retract(?f1) with
> Retract(valve(?v open)).  In general, though, the ID can be used as an 
> object reference to build trees and lists of facts, so in general it 
> seems one would need to use frames and not relations to model Clips 
> facts, although this requires frame axioms (additional rules), including
>
> rules with equality in the head, to make the frames behave as "relations
>
> with tuple IDs".
>
> I don't suppose we can quickly add IDs to BLD relations?
>
>   
>> Or is it the identifier of an object that has several valve properties
>>     
>
>   
>> with value "open" (or "closed", I guess)?
>>
>> I mean, rewritten with frames, is it something like this:
>>
>>   ?v#valve AND ?v[status->open]
>>
>> or is it rather something like that:
>>
>>   ?f1[?v->open], where ?v binds to the name of one of ?f1 valve 
>> properties?
>>
>> (thinking aloud: no, it cannot be what you mean, because, then, you 
>> would assert ?f1[?v->open], not ?f1)
>>
>> So, no, I still do not get it :-(
>>
>> Why do not you assert valve(?v open)?
>>
>> Actually, I do not even understand why you need to assert it: if it 
>> matches, does not that mean that it has been asserted already?
>>
>> (As you see, I do not know CLIPS :-)
>>
>>     
>>> But, I agree as our goal is to have an uncontroversial minimal PRD
>>>       
> which
>   
>>> works for all production rule systems and is aligned with BLD, we 
>>> should not
>>> include it in the first working draft.
>>>       
>> I do not agree that this is our goal, as you know.
>>
>>     
>
>
>   
Received on Tuesday, 24 June 2008 22:07:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:49 GMT