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

> ... CLIPS use case (the only one we have for this feature).

What about a relational table UC? (Michael mentioned that earlier.)
Regarding each row as a uniterm, its arguments are not positional
but slotted with column headings allowing column reordering.

The row

     a1  a2  ...  aN

from the relational table

r    s1  s2  ...  sN
--------------------
. . .
     a1  a2  ...  aN
. . .

corresponds to the slotted uniterm

r ( s1->a1 s2->a2 ... sN->aN )

and equivalently to the slotted uniterm

r ( s2->a2 s1->a1 ... sN->aN )

etc.

-- Harold


-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: Tuesday, January 15, 2008 3:34 AM
To: Michael Kifer
Cc: Boley, Harold; Sandro Hawke; public-rif-wg@w3.org
Subject: 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 15:23:04 UTC