[SCL] General sugar: an idea for discussion

[pat hayes]

>  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.

Agreed, but that wasn't my point.  I was meaning to suggest putting 
this into the basic logic, at the abstract syntax level, as a 
general-purpose device, not as another concrete syntax. Or at least 
put the idea up for discussion. Once I get my head around Chris' 
style of writing abstract syntax I will try to write this up more 
precisely.

The role-tag idea seems to transcend particular concrete syntaxes and 
be a more basic kind of relationship between N-ary relations and what 
might be called N-ary clusters of binary relations; it would map 
uniformly into any of the concrete syntaxes (perhaps with custom 
modifications, eg to use explicit Sexpressions in a KIF syntax or 
rdf:Collection language in an RDF-based syntax).

>  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.

I agree with you on that general topic. We need to treat XML 
enthusiasts rather like devotees of a new religion: with respect, but 
not so as to seem like potential converts. In particular the idea, 
much prosleytized, that XML somehow makes parser-writing obsolete and 
unnecessary is one that we should be ready for.  Our reply, I 
suggest, should be to smile sweetly and say that is why we are 
providing an XML syntax, for those folk who wish to take advantage of 
the brave new pre-parsed XML world. The other syntaxes are for the 
few troglodytes who insist on sticking with their archaic notations, 
for some stubborn irrational reason. But don't argue with an XML 
enthusiast, any more than you would argue with a Mormon missionary 
who rings your doorbell. They are not folk who are in a condition to 
be persuaded.

See comments added below.

>
>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.

Quite.

>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.)

XML notations probably have the lowest information density of any 
notation devised in the last 5000 years. I have done actual 
calculations with DAML; the number of symbols needed to express a KB 
in DAML-RDF-XML notation is between 1.7 and 2.3 orders of magnitude 
more than a conventional logical translation of the same content 
(comparison by counting the number of ascii symbols on a few dozen 
actual examples). I have also been told of DAML engines which have 
been rendered inoperative on industrial-scale examples because the 
sheer size of the XML encoding breaks the file-handling machinery.

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