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

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).
>   
Fact IDs should  really be considered local to that engine and only 
applicable for that session scope. Any form of OID is really only for 
objects inserted externally into the engine. Considering that engines 
have different schemes  for IDs, and some are counter based, others not 
- any forcing of the ID semantics on internal data would be problematic.
> -- 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
>>
>>
>>     
>
>
>
>
>   


-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)