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

I referred to the "tuple ID" of tuples (ground facts) in the
"valve" relation. While BLD strictly separates the levels of
IRIMETA annotations and content, other dialects might try to
'amalgamate' (cf. http://citeseer.ist.psu.edu/context/15688/0)
both levels. Normal IRIMETA usage proceeds from the ID to the
tuple it is annotating.

1. Proceeding from a query to the IDs of matching tuples is
indeed problematic -- it calls for a non-deterministic Query
primitive: in my example, Query(?f1 valve(?v open)) would bind
?f1 to "http://sample.org/tupleID1"^^rif:iri and ?v to v1001
(?f1 and ?v coming from the annotation and content level, resp.),
while Query(?f1 valve(?v ?state)) would even enumerate two
solutions, incl. two bindings for the 'ID variable' ?f1.

2. When we generalize the use of IDs from annotating ground facts
to annotating (non-ground) rules, our (* ... *) syntax applies
the ID (an IRI, which cannot be easily 'parameterized' by logic
variables such as ?x, ?y) to the rule as one (non-ground) term.
A parameterized non-IRI ID "generated" by a Skolem function would
go beyond that as in your valveID(?x ?y) example, similar to what
was discussed earlier for generating objects of frames.

BTW, coming back to our LC edits, you proposed a _new construct.
I think Michael's question about it was not answered yet:
http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0089.html
I'd be in favor of trying to still put it in.

-- Harold


-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: June 24, 2008 7:06 PM
To: Boley, Harold
Cc: Christian de Sainte Marie; Adrian Paschke; pu >> RIF WG
Subject: Re: AW: AW: [PRD] ACTION-531 Update PRD examples complete

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 Wednesday, 25 June 2008 01:30:45 UTC