Re: [RIF] Proposed object-oriented extension of Core (and BLD and PRD)

  On 20/04/2010 10:52, Christian De Sainte Marie wrote:
>
> (All of the following is with my PRD editor's hat; none of it wit hmy 
> chair's hat)
> -----------------------
> Hi Michael,
>
> Thanx for your feedback. I am not surprised that you could not make 
> sense of what I wrote: that is not unusual :-)
>
> For very good reasons, no doubt about that!
>
> But let us not throw away the baby with the bath water, and see if 
> there is something we can do to improve both the form and the 
> substance of this draft.
>
> Michael Kifer wrote on 20/04/2010 02:35:45:
> >
> > Your proposal [2]'s motivation/intro is completely disconnected from 
> your
> > proposed semantics.
> > Worse, I had really hard time parsing your introduction and the
> > desiderata, and
> > some aspects of your desiderata indicate that what you are trying 
> todo cannot
> > be given a model-theoretic semantics the way you have attempted.
>
> Ok, forget the introduction (I almost sent the draft without one: 
> maybe that is what I should have done :-)
>
> What about the remainder of the document? Does the semantics make 
> sense, or not even that (not that I would be surprised if it did not, 
> mind you: as you know, I was never quite comfortable with that kind of 
> stuff)?
>
> > I was trying to come up with a list of questions to you, but then I 
> discovered
> > that I have a question about almost every sentence in you 
> introduction because
> > most are extremely vague.
>
> Yep. We seem to speak different languages, definitely :-)
>
> Anyway, let me try to clarify.
>
> The main point is that the attributes-value pairs that are associated 
> to a frame object are defined logically (by the rules), whereas the 
> attributes that are associated with a program object are defined 
> externally [1]; and that definition is part of the definition of a 
> class ("program object" is the term I use in the draft as shorthand 
> for "objects as we use them in object-oriented programming languages").
>
> As a consequence, a program object must be a member of a class, it 
> must be associated with a value for each of the attribute defined for 
> its class, and it cannot be associated with a value for an attribute 
> that is not defined for its class.
>
> That is what I tried to formalize in making I<FV> a mapping from Dind 
> to *partial* functions from Dind to Dind, with the domain of the 
> function depending on the class. Is that what does not make sense in 
> my attempt to give a model-theoretic semantics to the construct I 
> propose?
>
> Another point is, indeed, that the (external) definition of a class 
> also defines the cardinality and type of each of the attributes. That 
> one is simplified, in my draft, by considering only single valued 
> attributes, since this is, practically, the case in most of the OO 
> languages; and by leaving the type out all together.
>
> The consequence of single valued attributes combined with objects 
> being required to have always a value assigned to each of their 
> attributes is that the (operational) semantics of asserting a value 
> for an attribute (in PRD) is to replace the existing value, not to add 
> a value (as it is with frames).
>
> One motivation for my proposal is that many widely used PR languages 
> need that operation. The main motivation, however, is that frames 
> cannot be generally translated into objects (e.g. Java objects), which 
> makes a frame-based RIF difficult to use with object-oriented rule 
> languages (at least PR languages).
>
> [1] At some point, eons ago, you wanted to have external frames, in 
> RIF, and I did not understand what you were talking about (see, the 
> relation is symmetrical :-). I realize, now, that it may have been 
> related to what I am trying to do here (or maybe not...).
>
> > [...] it seems that you are talking about the simple mechanism of
> > cardinality constraints, which I proposed to add to BLD quite a 
> while ago, but
> > nobody was interested. [...]
>
> I understand that program objects are only a specialization of frame 
> objects, and that we could, therefore, do what I propose with 
> specializing the existing frames.
>
> But that would not be much different from adding a whole new 
> construct, and a new construct allows us to handle those field values 
> as terms to be used in arbitrary formulas (whereas, with a frame, we 
> have to introduce a dummy variable to bind to the frame's value if we 
> want to use it in other formulas, since frames are formulas).
+1 to being able to do constraints without having to do bindings:
Person( age == 30)
instead of:
p : Person()
p.age == 30

Mark
>
> So, a third motivation for my proposal was to add that alternative to 
> the way we can handle the values of objects' attributes; knowing that 
> that alternative is esp. convenient for OO rule languages.
>
> And, then, of course, there is the questions of methods, that can be 
> handled easily with the new construct.
>
> > I also have a procedural question here. I thought that we are in the
> > maintenance mode where we are trying to shepherd the existing 
> documents to
> > the recommendation status. If we are going to introduce new 
> documents and give
> > them our official blessing then there are much better worked out 
> proposals,
> > which we could bless instead.
>
> Well, this is a tiny extension, and I think that it might be of 
> interest to all dialects, not only PRD (which is why I propose it as 
> an extension to Core).
>
> If the WG had not been extended, we would have discussed it within the 
> PR community without W3C support; and we would have also discussed 
> ways to give it an official status, if deemed useful (as I believe it 
> is).
>
> But since we have another 6 months, I thought that it would be worth 
> discussing.
>
> Cheers,
>
> Christian
>
> IBM
> 9 rue de Verdun
> 94253 - Gentilly cedex - FRANCE
> Tel. +33 1 49 08 35 00
> Fax +33 1 49 08 35 10
>
>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
> Compagnie IBM France
> Siege Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 611.451.766,20 EUR
> SIREN/SIRET : 552 118 465 03644
>