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

Mark Proctor wrote:
> 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.
If we wanted to have IDs to allow things like retractions based on an 
ID, we would need to make sure that an spec implementator can provide a 
mapping from their internal IDs to our defined IDs - that or support RIF 
ID schema generators.

However I still think for anonymous instances we should still be able to 
define them without an ID - they are anonymous at this stage they have 
not been inserted into the engine yet.
>> -- 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)


-- 
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)