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

general observation <-- : [PRD] ACTION-531 Update PRD examples complete

From: Paul Vincent <pvincent@tibco.com>
Date: Tue, 24 Jun 2008 14:22:43 -0700
Message-ID: <637B7E7B51291C48838F5AE1F2ACA1D714D489@NA-PA-VBE02.na.tibco.com>
To: "Gary Hallmark" <gary.hallmark@oracle.com>, "Christian de Sainte Marie" <csma@ilog.fr>
Cc: "Adrian Paschke" <adrian.paschke@biotec.tu-dresden.de>, "pu >> RIF WG" <public-rif-wg@w3.org>

I have to say the whole subject of retract, assert, identifiers/pointers
for facts etc seems totally alien to the mainstream rule engine
languages (and potential RIF users) I am used too. I have not used this
type of syntax since my PROLOG days (many moons ago) and AFAIK PROLOG
users are more catered for by BLD and its developments.  

So lets try and make sense of this example:
?f1 <- (valve ?v open)
... -> assert(?f1)
So: we do a match (1st line), then later on assert it (presumably as
time has passed, the original match / fact could have been invalidated -
so the assert makes the fact valid / in working memory again). Clever
stuff, but a pretty damn complicated way of representing what (IMHO)
should be a pretty simple operation.

1. Find a particular valve that is open, and mark it as special in some
other fact: f1.valve = v
2. ... later, we "reassert" that v is open: f1.valve.open = true.

Ah - NOW I understand! 

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Gary Hallmark
> Sent: 24 June 2008 18:30
> 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 21:23:31 GMT

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