[SCL] General sugar: an idea for discussion

[John F. Sowa]

  Pat,

The SCL document should include a chapter about
recommended ways of mapping the abstract syntax
to various kinds of concrete syntaxes.  In that chapter,
it would be appropriate to discuss something like
the tags for roles.

But I don't think we should waste our time in
developing a complete syntax for yet another
logic notation.  We already have four or five
that we have committed to presenting:  KIF,
CGs, traditional infix, and a couple versions
of OWL.  We can leave the rest as exercises
for the reader.

On another point, there has been some
discussion about using XML wrappers around
CGIF for communication between CG tools.
Some people wanted to XML-ize CGIF, and
I was arguing for leaving that as an option,
but not the preferred one.

Following is a note I sent to CG list on the
question of using XML for everything.

John

-------- Original Message --------
Subject: Re: CG: Too many CG tools -- but not enough usable ones
Date: Fri, 11 Apr 2003 22:16:09 -0400
From: "John F. Sowa" <sowa at bestweb.net>
To: cg at cs.uah.edu
References: <3E95CE7F.2080405 at bestweb.net> <3E96DED0.4020104 at open.ac.uk>

Murray,

After I responded to your note this morning,
I received two new items that strengthen the
points I made in my earlier notes:

 1. The note from Len Bullard, in which he
    recommended Roger Costello's web site
    for "best practices" in using XML.

 2. An offline comment from a reader who had
    been processing output from a parser that
    generated its results in XML format.

Following Len's recommendation, I went to
Roger's web site:

 http://xfront.com/

Roger has put together an excellent collection
of tutorials on XML, XSLT, RDF, OWL, etc., which
are all related to XML "best practices".  But by
the way, he also has tutorials on parser generators
for producing "custom" parsers.

If one of the major advocates of XML is also
recommending parser generators for custom parsers,
then I don't believe we should apologize for
advocating custom parsers for CGIF.

The second item was about the parser that
generated output in XML form.  Unfortunately,
the time required to parse the XML was longer than
one would like.  But it turned out that the parser
also had a "debugging option", which would generate
the same output in a form that was "humanly readable".

So my dear reader decided to try using the debugging
output instead of the "standard" XML output.  The
execution time for processing the "humanly readable"
output instead of the "computer readable" XML was
*AN ORDER OF MAGNITUDE* faster.  (That wasn't the
result of formal timing trials -- it was just the
perceived time of snappy results from using the
debugging output vs waiting, waiting, waiting for
the results from the XML version.)

Therefore, unless anyone can provide compelling
arguments to the contrary, I believe we should go
with Plan A:

 1. Use CGIF for all communications between CG
    components.

 2. Provide an option to use XCGIF for anyone who
    has unlimited time and storage space to waste.

Of course, I also recommend XML as the wrapper
language around CGIF for storing a knowledge base.
But the embedded CGIF would be marked by tags
that indicate the start and end of the CGIF.

John Sowa