RE: [PRD] PRD TF telecon Tuesday 14 October

> The question seems to be, really, if we can expect that the author
> of a BLD compatible rule set (program) always knows (at authoring
> time) whether a given frame's slot is, essentially, multi- or single-valued.

To me, that author had better know what s/he wrote! So, *of course*, the
*author* of the rules knows what s/he wrote. How many programmers do you
know that write programs not knowing what the semantics of what they write?
My point is that one can always declare this intended semantics, and the
setup thet I propose takes care of that seemlessly (modulo the amendment
of the collection semantics from sets to monoids).

-hak
--
Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci



-----Original Message-----
From: Christian de Sainte Marie
Sent: Tue 10/14/2008 4:36 PM
To: Hassan Ait-Kaci
Cc: RIF WG
Subject: Re: [PRD] PRD TF telecon Tuesday 14 October
 
Hassan Ait-Kaci wrote:
> 
> Here is my take on the frame and aggregates issues as they are related):
> 
> (1) Frames as they are defined and given semantics is BLD are useless for
>     most OO models such as those used in Production Systems where objects
>     have variable (field) arity and each field is mono-valued (BLD's frames
>     have multi-valued fields). The designers of BLD (MK & HB) have defined
>     a collection semantics based on aggregating mulitple values of a 
> frame's
>     fields using a set constructor. This is problematic as this introduces
>     a confusion when a field's value is already a set.
> 
>     A safe, simple, and more general way that would solve this problem is
>     not to build the set-collection semantics into BLD's semantics of 
> frames
>     with multiple field values, but rather to parametrize BLD's semantics
>     with a monoid collector (that can be set, bag, list, +, *, max, ...)
>     that is used to bundle and unbundle frame field values. In this way,
>     all we have to do when exchanging BLD -> PRD or PRD -> BLD, the 
> (normative)
>     RIF XML format, is to specifiy a monoid collector per field (which 
> could
>     default to set if left unspecified). Then, all that needs to be done is
>     to bundle/unbundle objects represented as frames, is declare what 
> monoid
>     (if any) is associated to a frame's field. This is simple to specify in
>     the RIF XML format that we are defining to be normative.

The question seems to be, really, if we can expect that the author of a BLD compatible rule set (program) always knows (at authoring time) whether a given frame's slot is, essentially, multi- or single-valued.

If yes, we can have different syntaxes for the two cases, and your proposed solution can be implemented to facilitate the BLD<->PRD interchange (although some questions remain, since a collection of values to simulate a multi-valued slot would still be different from a single-valued slot where the value is a collection).

But is it the case? And what, if not?

Cheers,

Christian