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

Such slotted instances have been implemented by, and used in, OO jDREW
(http://www.jdrew.org/oojdrew/docs/OOjDREW.pdf):
 
                                "... Since the named slots do not
require any particular order, 

an artificial order (such as a lexicographical order), can be imposed
internally upon

the slots. In OO jDREW the ordering of slots is the encounter order,
where slots are

ordered based upon the order in which they are first encountered; this
ordering is

performed when creating the internal data structures that represent the
terms."

                     "This ordering allows the algorithm to scan the two
lists of arguments,

matching roles (...) and unifying the fillers in each of the argument
lists."

-- Harold


________________________________

From: Mark Proctor [mailto:mproctor@redhat.com] 
Sent: Tuesday, January 15, 2008 12:26 PM
To: Boley, Harold
Cc: Michael Kifer; Sandro Hawke; public-rif-wg@w3.org
Subject: 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>
<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>
<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>
<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)