[SCL] Telecon Tuesday

[John F. Sowa]

Unfortunately, I can't make it for tomorrow's telecon.

But I'd like to make some comments on some of the issues
that have been discussed recently:

  1. I believe that Pat and I are very close to an agreement
     on the question of what to do about integer arithmetic:

     a) I agree with Pat that the official SCL core should not
        assume full arithmetic (i.e., Peano's axioms) and that
        some lesser theory would be sufficient to represent
        numeric quantifiers, numerals, addition, and less-than.

     b) I also agree that there should not be a *required*
        ontology for sets, sequences, and full arithmetic.
        But I believe that those languages that require them
        should have be able to find a library of *recommended*
        ontology modules for such things.  In particular, I
        believe that we could just include a pointer to the
        Z library and say that anybody who wants such things
        can go there to find a suitable ontology.

  2. I very strongly support Pat's statement:

     "I want a rather stronger notion than compatibility.
     SCL/XML should *be* SCL, rendered into XML...
     I do not want it to be modifiable. It can be extendable,
     by adding new syntactic categories, although even that
     slightly worries me. But to allow the basic SCL syntax
     to be *modifiable* would undermine the basic idea of the
     entire project."

     I would prefer that XCL or CLML be nothing more nor less
     than the SCL abstract syntax represented in a linear order
     similar to KIF and decorated with angle brackets.

  3. I believe that we will need examples, tutorials, and ohter
     explanatory material, of which Pat's example is just one:

     "It occurs to me that taking a very simple SCL expression and
     showing what it looks like in, say, the holds/app translation
     using only and, not and exists, might be an instructive exercise
     for some readers."

     But we'll also need a lot more.

  4. The discussion between Pat and Tanel about "include" raises a
     large number of questions:  How are ontologies expressed in
     some language of the CL framework going to be handled?
     What are the conventions for translation functions, naming
     conventions, and possibly recursive (hopefully primitive
     recursive) algorithms for cascading imbeds of ontologies in
     multiple CL-conformant languages?

     We have to recognize that these issues will arise, but we don't
     have to *implement* the translation functions.  We can specify
     them for the basic languages we have committed to and require
     that anybody who wants to introduce another language must do
     the additional specification and implementation.

  5. Interoperability is essential.  There is no argument about that:

     "Nevertheless, the fact remains that OWL and DAML and RDFS written
     in that ugly XML syntax are going to be out there, and we need to
     not do anything that would break our ability to interoperate with
     them."

     And speaking about interoperability, SQL is another ugly syntax,
     which happens to support the world's economy.  It will also have to
     be accommodated, hopefully not by us, but we shouldn't forget it.

  6. I agree with Pat about annotations:

     "... all we have to a do is allow annotations to be strings.
     I would prefer that they could be *anything*, in fact, even things
     like datastructures representing parsed structures or WAV files.
     I see no reason to restrict the form of annotations in the abstract
     syntax in any way. As far as SCL is concerned, they are simply
     chunks of information in some arbitrary form which is 'attached'
     to the SCL expression but otherwise has no characteristics whatever,
     other than being what it is."

     Example:  Suppose I record an explanation of a particular SCL term
     as expressed in language A and attach it to that term as a WAV file.
     Then if somebody else reads the translated version in language B,
     my WAV file (not translated) should be attached as an annotation
     to the translated term in language B.

  7. I agree with Pat that we would need simple strings and numerals in
     the base logic -- perhaps also BLOBs (Binary Large Objects).  But
     there is also a question about quoted terms in some CL-conformant
     language.  Can we have quoted terms?  What happens when a quoted
     term in language A is part of a statement that is translated to
     language B?  Is the quoted term translated or left untranslated?
     There are times when you might want one or the other option.
     Can we support both -- with some mechansism for saying which one
     is wanted?

John Sowa