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