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

Hi Christian,
pls see my comments within.

On Tue, 20 Apr 2010 11:52:54 +0200
Christian De Sainte Marie <csma@fr.ibm.com> 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.

Sure. I just wanted to understand what exactly you were trying to do.

 
> 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)?

Semantics is mathematical modeling of some kind of behavior that you wish to
capture. So, to evaluate the goodness of a semantics one need to first
understand what this semantics is supposed to model. :-)

> > 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.

You should have writtn it in simple English right from the start :-)

> 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.

So, this seems to suggest that you want typing as, eg., in F-logic.
This can be added to BLD, making it BLD+, and then projected down and creating
Core+.


> 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?

I don't think this will work. What you want seems to be typing constraints.

> 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.

So, typing+cardinality constraints.

> 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).

There can be several possibilities:
1. Asserting 2 values can be treated as a constraint violation.
   This is very useful, but is not what you want in this particular case.
2. Asserting 2 values for an attribute  has the effect of inferring the equality
   of the two values. This is an OWL-esque approach. Again, not what you want,
   it seems.
3. Assuming that we want to stay within a logical framework, we have to allow
   actions with model-theoretic semantics. This would allow adding/deleting
   facts, but it is a very big extension.

> 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...).

I don't think that external frames provide a solution to what you are trying to
do. However, they can be used to express the fact that those classes are
externally defined, which is one (albeit small) aspect of what you have
described.


> > [...] 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).

Adding a syntax for path expressions and ascribing magical properties to
these expressions is not going to do any tricks. An expression a.b is just a
denotation for that object c such that a[b->c] is true. This does not
accomplish anything by itself.

The fundamental problem here is that BLD does not have constraints (because we
could not agree on that in the days of RIF infancy). In particular, it does not
have type constraints and cardinality constraints.

The second fundamental problem is that BLD (in fact, the whole of logic-based
part of RIF) is static. The KB is not allowed to change, so it is impossible to
model the "singleness" of attribute values the way PRD does.

Extending RIF in these directions is not a minor job.

> 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).

This is not a tiny extension by any means. It looks tiny to you only because
you wrote a tiny document. :-)
But, as far as I can see, this document didn't accomplish any of the goals that
you have set out to solve.

> 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).

If you do this strictly within the PRD framework, it can probably be
accomplished rather easily, since PRD is not constrained by the rules of a
logic. (I mean that PRD is not based on a logic, not that it is illogical :-)
To do this at a more fundamental level (so that it could be shared among
RIF dialects), we would need the aforesaid things (constraints, including
types and cardinality, and actions). I have this on my agenda, but not within
the next 6 months.

michael


> 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:33:44 UTC