[KIF] Re: [SCL] DTD for XML/SCL

[pat hayes]

>Bill and Chris,
>
>I think we all agree on the fundamental issues regarding how SCL should
>relate to XML.  To clarify, and in some respects broaden, the issues,
>I would like to suggest the following approach:
>
>  1. Write an XML DTD to relate the abstract syntax of SCL to XML along
>     the lines that Chris has been doing.

There is still an open issue of how best to define an XML syntax. We 
need to discuss this in more detail.

>
>  2. Include other concrete syntaxes in the SCL standards document,
>     such as KIF and CGIF.

Of course, but also an RDF-compatible triples syntax would be 
extremely useful. This requires some nontrivial effort, however.

>
>  3. Provide an escape tag, which would allow the embedding of various
>     SCL concrete notations within an XML document.  For example,
>
>        <logic language=kif>
>            (exists ((?x Cat) (?y Mat)) (on ?x ?y))
>        </logic>
>
>        <logic language=cgif>
>             (on [Cat] [Mat])
>        </logic>

I agree that this seems useful. However I think it will meet with 
considerable opposition from several XML user groups and standards 
bodies, and we should consider it more carefully, and particularly 
look for any precedents, if there are any, and any archived 
discussions of this kind of escaping strategy. In particular if there 
is any existing usage of this kind, and if any kind of normal 
practice has emerged in a substantial user community, we should 
attempt to conform to it as far as possible.

Does anyone have any suggestions for where to look?

>  4. Include Z as a first-class member of the SCL family, with the same
>     status as KIF and CGIF.  The SCL standard document should relate
>     the SCL abstract syntax to the concrete syntax of core Z (which is
>     Z without the mathematic toolkit) in the same way that it relates
>     the abstract SCL syntax to the concrete syntaxes of KIF and CGIF.

I have no objection to anyone doing this, but I do not want it to be 
on the critical path, and therefore ask that we as a group put it to 
one side for now. It was not part of the original agenda either of 
the CL group or of the newer SCL project, and seems to have no 
relevance to the purpose of SCL.

It is misleading to characterize Z as a version of FOL, in my view. 
It is better seen as a type system for formal description of 
programs, which is also what the Z documentation itself describes it 
as. The syntax of Z would be completely unsuitable as an input 
notation for most inference engines, for example, and would be hard 
to relate to existing ontology languages.

>Points #1 and #2 seem to be well accepted by everybody who is working
>on the SCL project.  Point #3 is one that I raised in my earlier note,
>to which Bill and Chris replied.  I would have no objections to the
>verbosity of the XML DTD along the lines of #1 provided that we also
>have an escape along the lines of #3, which would allow KIF, CGIF, and
>other compatible SCL languages in an XML document without the overhead
>of the encoding proposed for point #1.

I do not think that this issue is quite this simple. There are 
emerging conventions for 'good' XML usage, and we need to be more 
sensitive to them.

>
>The major new point I believe we should add is the adoption of Z as
>a member of the SCL family of concrete notations.  There are several
>reasons, which I discussed in my earlier note and which I would like
>to summarize here:
>
>  1. The model-theoretic foundations for Z, as presented in the ISO Z
>     standard, are logically equivalent to the simplified SCL semantics
>     that Pat Hayes proposed.

I do not believe this is accurate. They are similar, in the sense 
that all FOL semantics are closely similar, but they do not seem to 
be equivalent languages.

>
>  2. Z has been developed and used by well-qualified computer scientists
>     who have a long history of applying logic to formal specifications
>     of programming languages and other kinds of software.

Quite. Those are not our prime concerns, however, and the use of 
logic in this special way has special concerns of its own, which will 
only be irrelevant and distracting to our effort.

>  It was first
>     published as a PhD dissertation by Mike Spivey at Oxford, but it
>     incorporates the approach developed by Hoare, Abrial, and others,
>     including distinguished visitors to Oxford, such as Dana Scott.
>
>  3. Z has been officially adopted as an ISO standard.  An SCL standard
>     that builds on the Z standard would be very easy to sell to the
>     ANSI and ISO standards bodies as well as to any country, company,
>     or computer scientist who respects ANSI and ISO (which includes
>     nearly everybody in the world except Bill Gates).
>
>  4. Finally, we have been proposing CL and SCL as a way of unifying
>     the diverse logic-based notations that have been developed.
>     If we adopt the Z standard as a foundation for SCL, we will set
>     a good example for other people to follow.

On the contrary, I think that our goal regarding Z should be to make 
SCL a possible foundation for Z. The Z standard is not written to the 
degree of precision that I would expect the SCL standard to be 
written, not in what I think is an appropriate style for 
software-developer use; and my own ambitions for the SCL project are 
not primarily aimed at ISO acceptance in any case.

>But if we ignore Z and
>     go our own way independently of Z, we will lose any credibility
>     we may have had.

I disagree. There is a huge user community for whom Z is completely irrelevant.

>The first question anybody would ask is why
>     they should accept our proposal instead of adopting an official
>     ISO standard that has the same semantics.
>
>As I said in my earlier note, the adoption of Z semantics as a
>foundation for SCL would allow us to develop an upward compatible
>semantics that would satisfy the more ambitious goals of our
>earlier CL efforts.

Using Z as a foundation would cripple the CL/SCL effort, in my view.

>  We could write a solid SCL standard document
>with an outline similar to the Z document by June 2003.  After that,
>we could turn to the more ambitious metalanguage project for CL,
>which would go beyond what has been done in the Z standard.
>
>Bottom line:  Adopting the Z standard for the SCL foundations would
>enable us to finish an SCL standard document quickly, and let us begin
>work on the much more interesting metalanguage project.

I disagree. Incorporating Z would increase our work load needlessly; 
adopting the text of the Z standard is completely impractical; and in 
any case the Z standard documentation does not reach the standards of 
precision that we will require.

Pat
-- 
---------------------------------------------------------------------
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 ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam at ai.uwf.edu   for spam