Re: implementing named-argument uniterms (ISSUE-44)

Frames have a different semantics.


> It seems simpler to just use frames for the interchange as well:
> 
> <Exists>
>   <declare><Var>car_problem_oid</Var></declare>
> <Frame>
>   <Member>
>     <lower><Var>car_problem_oid</Var></lower>
>     <upper><Const type="rif:local">car_problem</Const></upper>
>   </Member>
>   <slot>
>     <Const type="rif:local">name</Const>
>     <Const type="rif:local">headlights</Const>
>   </slot>
>   <slot>
>     <Const type="rif:local">status</Const>
>     <Const type="rif:local">work</Const>
>   </slot>
> </Frame>
> </Exists>
> 
> Then we can remove slotted uniterms from the syntax and semantics.
> 
> Boley, Harold wrote:
> > We have slides on this from a breakout session:
> >
> > [TED] Slides of F2F4 Breakout on Abstract Syntax and Semantics: Slots &
> > Constraints
> > http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0025.html
> >
> > as well as a wiki entry:
> >
> > [TED] CORE Pages Edited for Slot-to-Positional Transformation and
> > Multisorted Syntax
> > http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0110.html
> > http://www.w3.org/2005/rules/wg/wiki/CORE/Conditions/Positive?action=rec
> > all&rev=10
> > (SYNTACTIC TRANSFORMATION)
> >
> > Another translation approach might be to regard
> > named-argument uniterms as (named-argument) frames
> > whose OIDs are [bNodes or are] generated as indicated
> > in the 8 Jan 2008 telecon using the CLIPS example:
> >
> > http://lists.w3.org/Archives/Public/public-rif-wg/2008Jan/att-0028/rif-m
> > inutes-jan8-2008.html
> >
> > However, following up on the discussion with Gary,
> > CLIPS' source-level Lisp-like named-argument uniterm
> > <http://en.wikipedia.org/wiki/CLIPS>:
> >
> > (car_problem (name headlights) (status work))
> >
> > should be *interchanged* in RIF somehow like this
> > <http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions>:
> >
> > <Uniterm>
> >   <op><Const type="rif:local">car_problem</Const></op>
> >   <slot>
> >     <Const type="rif:local">name</Const>
> >     <Const type="rif:local">headlights</Const>
> >   </slot>
> >   <slot>
> >     <Const type="rif:local">status</Const>
> >     <Const type="rif:local">work</Const>
> >   </slot>
> > </Uniterm>
> >
> > Only when being *stored* in an engine would an OID be
> > generated, and the uniterm be transitioned into a frame.
> >
> > The generated OID (<Fact-0> or <Fact-1> or ...) may
> > depend on the assertion/loading history of one session
> > for a specific engine. But an interchange format
> > should be (initially) concerned with exchanging entire
> > KBs on the source-level as in the 'static' example of
> > <http://en.wikipedia.org/wiki/CLIPS> rather than with
> > exchanging stored KB parts as in the 'trace' example at
> > http://www.ghg.net/clips/download/documentation/bpg.pdf
> > (page 206).
> >
> > -- Harold
> >
> >
> > -----Original Message-----
> > From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
> > On Behalf Of Michael Kifer
> > Sent: Wednesday, January 09, 2008 1:10 PM
> > To: Sandro Hawke
> > Cc: public-rif-wg@w3.org
> > Subject: Re: implementing named-argument uniterms (ISSUE-44) 
> >
> >
> >
> > If the order of arguments is fixed, then it is easy. But the order of
> > arguments is not fixed in BLD, and this is cumbersome.
> >
> >
> > 	--michael  
> >
> >   
> >> How hard is it to translate from BLD with named-argument uniterms to
> >>     
> > BLD
> >   
> >> without them, or to various rule languages without them?  Is this
> >> basically syntactic sugar, or is it pretty hard?
> >>
> >> If it's hard, I don't think it's appropriate to include named-argument
> >> uniterms in BLD, as much as I happen to personally like them.
> >>
> >> Specifically, can someone provide a translation algorithm and example?
> >>
> >>     -- Sandro
> >>
> >>
> >>     
> >
> >
> >
> >
> >   
>

Received on Tuesday, 15 January 2008 07:06:03 UTC