[CL] (S)CL mapping for Object Role Modeling?

[John F. Sowa]

Elisa,

Thanks for the comments.  They help clarify some
of the issues.

When I looked at the SBVR document, I was horrified
by the sheer volume of terminology, especially very
loose terms such as "meaning", which I would never
attempt to use in any kind of technical sense.

 > ... it's also my understanding that their use of
 > modal operators is really minimal, essentially as
 > sentential markers.

That worries me.  I agree that they're important,
and I believe that they can be accommodated by a
metalevel extension to a language such as CL.
But they have to be treated in a very careful and
very systematic way.

 > The quasi-structured English that is used in the text
 > and in their examples is a notation that the business
 > rules community represented by Ron Ross, Donald Chapin,
 > John Hall, and other co-authors of the document have been
 > using successfully for some 15 years with their clients,
 > and companies including Unisys and HP have interest in
 > building products that use it.

I am very much in favor of promoting variations of structured
or controlled natural languages.  Fred Thompson, who earned
his PhD from Berkeley as a student of Tarski's and taught
at Cal Tech for many years, pioneered a language called REL
(Rapidly Extensible Language), which he developed as a
query/update language for database system back in the 1970s.

And note the word *rapidly*:  Fred emphasized the need for
modifying the top levels very easily and very quickly in
order to tailor it for many different kinds of applications.
At the bottom level, the logic can be very, very small and
very, very stable.  But at the top levels, there is no
such thing as a one-size-fits-all user interface.  I
recommended the REL approach in my 1984 book, and I still
think it's an excellent idea that deserves far more
attention than it has received.

But Fred and I would emphasize the importance of defining
any such language by its mapping to the underlying logic.
That is how CLIF is defined in terms of CL, and CGIF
is defined by  a two-level translation: extended CGIF
-> core CGIF -> CL.  Those intermediate levels are
also very important, and they should be able to support
alternative top levels, especially when the upper levels
are quasi-NL like.  (And it is possible to make the
top levels even more NL like than SBVR attempts to do
-- that is another reason for decoupling the syntax.)

Furthermore, CLIF and CGIF are decoupled in the sense
that they have been independently developed and defined.
That kind of stratified development is essential, and
I don't see it in the SBVR document.  Without clearly
specifying the levels and having clearly defined and
independently maintainable interfaces, any effort such
as SBVR is doomed.

 > Again, when I read it, since my background includes work
 > in Situation Semantics, hairs on the back of my neck went up.
 > I spent time with folks from NIST working through this with
 > them, and attempted to convince a couple of them that a
 > grounding that included situation calculus (which one could
 > potentially extend CL to support) would be better than what
 > they have, but had little success on this.

That is another concern that I have.  Situation semantics
and situation calculus share some similarities (a bit more
than just the word), but there are also many other approaches
for defining processes.  In particular, I would recommend the
book by Michael Havey, _Essentials of Business Process Modeling_,
which uses the pi calculus.  That is a very different approach,
and it would be a major, major blunder to standardize something
that could not accommodate developments such as BPM, which I
believe has a great deal of potential for the future.

 > I also asked that they dramatically reduce the claims
 > regarding how and why one might use this specification,
 > and that in particular, I did not think it was adequate
 > as an ontology language, and should not be used for that
 > purpose unless and until the grounding in CL was completed
 > and included in the document.  That was also supposed to
 > happen in the latest version, which I'm hoping to review
 > this week.

Something like that has to be done.  And I would emphasize
the need for multiple layers between the user's view and
the core logic.  Something like that is also needed for UML,
which has been a festering sore for many years because the
developers did not adopt a clear logic foundation at the
beginning.

So my suggestion would be the following:  scale back the
effort drastically, explicitly define the intermediate
levels (as we did with CL & CLIF or CL & core-CGIF &
extended-CGIF), and make it possible to have new variations
of languages at the top that would not shake the entire
edifice to its foundations.

It's always possible to add new features later, but it is
very difficult to get rid of mistakes, especially if those
mistakes are edicted as standards right from the beginning.

John