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

On Tue, 20 Apr 2010 08:45:13 -0700
"Paul Vincent" <pvincent@tibco.com> wrote:

> Christian – let me know if you would like me to “attempt to improve the readability” of RIF-OO 
> proposal.

Christian's second attempt was much more successful, so I understood (I think)
what he wants to do. But the approach taken in the document does not lead
anywhere as far as I can see.

> Michael – does your work on F-Logic –e.g.
>  http://www.cs.sunysb.edu/~kifer/TechReports/flogic.pdf - help with the frame
>  to/from object mapping + representation issues?  I’m wondering if there your
>  past work here could be a “shortcut” to solving/achieving the
>  RIF-for-objects dilemma/goal (by which of course I really mean RIF-for-Java,
>  C#, C++ etc).

From what I could understand from Christian's second message, the issue boils
down to typing/cardinality and actions. So, yes, F-logic solves the first part
of it and Transaction Logic solves the other part.

But doing things in the framework of PRD directly would shortcut the whole
thing and should be relatively easy. The logics are needed only if we want to
have a more general approach, which can be shared with other dialects. This,
however, is not a simple task.

regards
michael

 
> Cheers
> 
> Paul Vincent 
> 
> TIBCO Software <http://www.tibco.com/default.jsp>  supporting standards development 
> 
> -- CEP-relevant stds: OMG UML class/state, OMG PRR rules, W3C RIF rules
> 
> -- blog: TIBCO Complex Event Processing Blog <http://tibcoblogs.com/cep> 
> 
>  
> 
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Christian De Sainte Marie
> Sent: 20 April 2010 10:53
> To: kifer@cs.sunysb.edu
> Cc: public-rif-wg@w3.org; public-rif-wg-request@w3.org
> Subject: Re: [RIF] Proposed object-oriented extension of Core (and BLD and PRD)
> 
>  
> 
> 
> (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). 
> 
> 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 €
> SIREN/SIRET : 552 118 465 03644
>

Received on Tuesday, 20 April 2010 20:51:59 UTC