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

yes, that much even I can glean from the model theory :-)
I'm suggesting that we get rid of the 2 interpretation functions Isr and 
Isf because frames are more expressive and there is no reason not to use 
them to interchange slotted relations if your source or target rule 
language has such a thing. 

I am not all persuaded by the argument that because CLIPS has a syntax 
that looks like slotted relations, that we should therefore have slotted 
uniterms in RIF.  Frames are more useful, and have the right semantics 
for the CLIPS use case (the only one we have for this feature).

Michael Kifer wrote:
> 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:33:33 UTC