[CL] Re: [SCL] new draft
pat hayes
phayes at ihmc.us
Wed Dec 31 13:27:53 CST 2003
>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).
No, not effectively untyped. Even 'large' typing is fundamentally
different from an untyped framework.
>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.
You have chosen an example which makes little sense, but there are
plenty of examples which do make sense and arise in practice. For
example, in datatyping it is highly convenient to be able to use the
same name for the value class and for the lexical-to-value function,
as in xsd:integer(xsd:integer('3')), a convention that is used
(though not in this notational form) in RDFS and OWL. It is also
common to discover that two different formalizations of a concept
treat it - the concept - as having sharply different 'types'. SCL
allows such divergent formalizations to co-exist and be used together
without modification in m any cases which would be illegal in a typed
language.
> If "(add dog cat)" is intended to represent some additive operator
>and "dog" and "cat" are intended to be suitable operands
SCL is not a programming language, so talk of 'operators' is inappropriate.
>, 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.
BUt consider for example the assertion
=(= owl:sameAs), which asserts that the identity relation is the same
entity (and hence the same relation) as the OWL identity. This is a
perfectly coherent assertion which may even be true in some
frameworks, and certainly if true it would be useful to be able to
assert it. But it applies a relation to itself, which is illegal in
*any* typed framework based on ZF set theory. Another example is the
observation that the class of all classes is itself a class, a
tautology in RDFS:
rdfs:Class(rdfs:Class)
>
>> 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?
No. What makes you think that a language designed for software
specification would be a good starting point for knowledge
interchange? Your intuitions seem way out of alignment here.
>
>> 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.
That is a completely fatuous remark. There are no Good or Bad Things
in formal matters. If you have anything substantive to say on this
matter, please say it clearly.
>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?
You are talking about a cooperative process of software or system
development. For that, typing and Z are indeed likely of more use
than SCL. SCL, however, is not intended for that purpose.
>
>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.
A controversial point, but in any case completely irrelevant to the
issue. SCL is not intended for software specification, still less as
a programming language.
>
>Thus, enforced typing supports better scalability.
That remark presumes that typing can be enforced. THe entire point of
SCL is that typing cannot be enforced in an open network like the
WWWeb. 40 years of experience on closed networks is largely
irrelevant.
>
>> 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.
Please feel free to give us a translation of SCL into Z.
>
>> 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
I tend to agree. I propose to completely ignore Z, myself.
>-- 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"?
Because this is exactly the kind of meaningless
undergraduate-philosophy debate which I am anxious to avoid polluting
my time with.
The text of ISO 704 which you cite uses the word 'intension', by the
way. Can you tell us what you mean by that word, Frank? But please
don't reply to the SCL list, as the resulting book will take up too
much transmission time. (I presume you will undertake to provide
essential and delimiting characteristics for intensions, so at least
one book will be needed)
>All other (terminological) discussion is unfocused and likely to be
>less productive.
If this were true, all of intellectual discourse in mathematics and
science would be 'less productive'. You might do well to read Kant,
by the way.
>
>> 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?
Based on reading other ISO documents, this list will be largely
boilerplate: the brief 'definitions' provided are almost all either
wrong or useless except possibly as an aide-memoire for readers who
have actually read the text and understood it. No doubt someone will
undertake to provide such boilerplate in time, but it is not a task
which is on our critical path.
Pat Hayes
>
>-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
>
>_______________________________________________
>CL mailing list
>CL at philebus.tamu.edu
>http://philebus.tamu.edu/mailman/listinfo/cl
--
---------------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32501 (850)291 0667 cell
phayes at ihmc.us http://www.ihmc.us/users/phayes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20031231/2c6f0664/attachment-0001.htm
More information about the SCL
mailing list