[SCL] new draft

[Frank Farance]

At 02:15 2003-12-22 -0500, John F. Sowa wrote:
> Frank,
> 
> Your note raised several issues, and I'll respond
> briefly to each of them.
> 
> Re CL & SCL lists:  The original list was named KIF,
> and it was renamed CL for Common Logic.  Earlier
> this year, a less ambitious version of CL, called
> Simplified Common Logic or SCL, was set up in order
> to get more rapid agreement on basic issues.  Since
> then, the SCL list has been devoted to rather detailed
> technical discussions, and CL will be used for progress
> reports about settled issues and for drafts that are
> progressing toward the standard.  Essentially all of
> the SCL participants are also subscribed to CL, but
> CL will be devoted more to standards related issues
> than to technical issues in logic.
> 
> Re Z:  The relationship between Z and CL was discussed
> at the SC32 WG2 meeting in Santa Fe in January.  The
> slides, which were prepared by Pat Hayes, Chris Menzel,
> and me and which I presented to WG2, discuss these issues:
> 
>    http://www.jfsowa.com/talks/clprop.htm

Yes, I remember the presentations and I felt that the questions were (largely) unanswered.  In your presentation above, you said:

        - Like CL, Z is a version of FOL with a model-theoretic semantics.

        - Differences between CL and Z:

                * CL semantics is a superset of Z semantics.

                * CL abstract syntax supports a much wider range of notations.

                * CL supports the Universal Resource Identifiers (URIs) specified by the W3C.

                * Both typed and untyped versions of FOL can be CL-conformant, but Z requires strict typing. 

Regarding "CL semantics is a superset of Z semantics", my memory of your presentations then and since have been the opposite: CL is a subset of Z, not a superset.  Besides, can you tell me what is a subset or superset in this context?

Regarding "CL abstract syntax supports a much wider range of notations", I am not convinced of that -- can you explain what is possible in CL but not Z?  (FYI, since CL is incompletely defined, I guess is supports anything, right?  Or are there some real differences?)

Regarding "CL supports the Universal Resource Identifiers (URIs) specified by the W3C", CL uses URIs in a trivial way -- one that could be easily added as an extension (read: profile) of Z.

Regarding "... but Z requires strict typing", I'm not convinced that typing is bad.  For example, in Z subclause 13.1:

        An example of a Z phrase that is not well-typed is the predicate 2 element-of 3, because the second expression of a membership predicate is required to be a set of values, each of the same type as the first expression.

The typing is strict in the sense that the types must match, but it is possible to have types with large value spaces (thus, effectively untyped).

Without typing, I can write an expression using LISP-like notation "(add dog cat)" -- but for what purpose?  Assuming that "add" is the arithemtic operator and "dog" and "cat" represent non-numeric objects dog and cat, then a non-typed system has the (non-)advantage of being able to write statements that I can discover (now or later) that don't make much sense.  If "(add dog cat)" is intended to represent some additive operator and "dog" and "cat" are intended to be suitable operands, then either (1) the notion of "add" needs to be different than the arithemetic operation, or (2) the notion of "dog" and "cat" needs to imply something quantitative and compatible for aritmetic addition.  So in conclusion, either "dog" and "cat" really need to be typed properly or the "add" operator needs to be defined differently.

> In short, Z and CL do have a large overlap, but they were
> designed for different purposes:
> 
>   1. CL is designed to serve as a common semantic base
>      for multiple logic-based languages, each of which
>      has been designed for a different purpose, but each
>      of which has a large overlap with the others.
> 
>   2. Z was designed as a specification language, not as
>      a target language for translations to and from other
>      logic-based languages.
> 
> For these reasons, CL supports a broader range of semantics
> than Z.  Every feature of Z can be translated to CL
> (or SCL core).  But it is not possible to translate all
> of CL (or even SCL core) to Z.

Based on the above statement, it sounds like Z would be a better starting point ... and then profile it for CL, right?

> One of the major reasons why Z cannot be used as a target
> for translations to and from other versions of logic is
> that it has a very strict typing system.  But many of
> the languages that we need to support with CL are either
> untyped, have optional types, or have less rigorously
> enforced type constraints than Z.

This can easily be accomplished by wider/broader types.  Certainly from a machine automation perspective (and debugging/quality perspective), the past 40 years have taught us that typing is a Good Thing.  The "design" process that produces an analysis and specification of types also produces a significant risk-reduction of development and integration with no loss of expressivity.  Who wants to spend hours of debugging to discover the improperly typed "2 element-of 3" in an untyped system?

The original C programming language (K&R) was largely untyped.  However, the ANSI C standards committee decided in the mid-1980's to incorporate type checking.  At the time, the rationale for this major change was: the new feature would support the writing of larger programs and larger applications because the type checking was, in effect, trading up-front thinking (i.e., some design work) for back-end debugging (debugging is always difficult to schedule and manage, in contrast to design work).  Overall, that "gamble" in the mid-1980's turned out to be a Wise Decision -- and one that has been emulated in many programming and database environments since.

Thus, enforced typing supports better scalability.

> Therefore, the SCL core is untyped, but it can support
> a wide variety of typing systems, including the strict
> typing of Z, the optional types of conceptual graphs,
> and untyped versions of RDF and OWL.  It is possible to
> translate Z to SCL, but it is not possible to translate
> SCL, CL, and many other logic-based languages to Z.

I don't believe any of the above until I see it demonstrated.

> For the proposed CL standard, we plan to include an
> annex that shows how Z can be translated to CL.  That
> translation would make Z a CL-conformant language.

For what purpose?  This appears to be a waste of time -- especially if we are considering developing a standard for CL.  I doubt there will be little support to re-invent the wheel (considering that developing normative wording for Z or an equivalent is easily a 5-8 year project).

> Re definitions of terms:  There will be a glossary of
> all technical terms in the draft CL stsandard for May '04.
> 
> If you have tuned in to some of the ongoing discussions,
> you may have noticed that we are still arguing over some
> of the terminology.  We have actually reached a greater
> consensus on the technical issues than on the terms we
> should use to describe them.

OK, if you are looking to make progress in a discussion of terminology, why aren't you discussing "essential characteristics" and "delimiting characteristics"?  All other (terminological) discussion is unfocused and likely to be less productive.

> The reason for the disagreements is that we are
> addressing a multidisciplinary audience of logicians,
> computer scientists, and software developers.  Over
> time, these groups have adopted different words for
> very similar concepts.  We therefore have an abundance
> of terminology, and we are trying to decide which
> are the most common and most readily understood terms
> (which are sometimes quite different from the highly
> specialized terminology used by the logicians).

Well, why not write down a strawman set of concept-term pairs for the Definitions Clause that you anticipate in the 2004-04 draft?

-FF

______________________________________________________________________
Frank Farance, Farance Inc.    T: +1 212 486 4700   F: +1 212 759 1605
mailto:frank at farance.com       http://farance.com
Standards/Products/Services for Information/Communication Technologies