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

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 06:57:50 UTC