[SCL] (SCL) Getting a move on

[pat hayes]

Thanks to all who have responded to my earlier message. This is a 
follow-up to explain the idea slightly more clearly. (If anyone 
getting these messages wants to stop getting them, just send me an 
email.)

First, the intent is not to take over the CL initiative, although I 
expect that what we do may influence that group's activities. That is 
why the message was not sent to everyone on the CL mailing list. It 
is, rather, to create a related faster-track initiative which has a 
somewhat different emphasis, one more focused on bringing a version 
(?subset?) of CL into line with existing and emerging 'logic' 
standards; that is why the message was CCd to people who are involved 
in various such standardization efforts. It would therefore probably 
be useful to distinguish this effort by a new name, so as to avoid 
confusion with the original (and on-going) CL effort and avoid any 
appearance of a turf war. There is a risk of name-inflation here, 
since "Common Logic" was introduced only recently to replace the 
venerable "KIF", but I think that the benefits outweigh the risks. So 
I propose to call this initiative SCL, at least for now, and use the 
(SCL) subject-line prefix to help with email filtration.

I see SCL as differing from CL in at several respects. First, it is 
likely to be more limited in its ambitions to full generality. CL has 
taken a very 'high' road, with a syntax which allows an extraordinary 
degree of syntactic freedom and a very abstract, elegant statement of 
the truth conditions. SCL needs to be willing to compromise these 
lofty ideals somewhat in order to allow practical interaction with 
the rather more restricted world of languages like OWL and RDF. I do 
not mean to imply that SCL will be a trivial subset of CL, only that 
it has to allow for practical compromises and will be less of a 
logician's 'gee-whiz'. The Lbase proposal which Guha and I recently 
wrote (http://www.w3.org/2002/06/lbase/) might convey something of 
the level of generality I think we might try to aim at, but this is 
only intended to give a general idea. For example, it is far from 
clear that SCL needs to have sequence quantifiers; but if it does 
not, then it should establish and codify a way to achieve the same, 
or a very similar, effect, such as by defining a relationship between 
sequence quantification in CL and the use of explicit lists to encode 
argument sequences in OWL/RDF, which achieves a similar practical 
effect using a much uglier syntax which is however becoming, for all 
its ugliness, a kind of RDF standard.

Second, the SCL documentation needs to pay a considerable amount of 
attention to very low-level matters such as character encodings, XML 
syntax, handling of URIrefs and so on. None of this is theoretically 
difficult, and most of the work has already been done by other 
standards groups, but this kind of detail work does take some time 
and effort. (Ignoring these issues is a way to ensure that the 
proposal will not get adopted by anyone.)

Third, SCL has to be done on a fast timescale, so we have to be 
prepared to simply postpone some issues or features on the grounds 
that we cannot get them decided in time. So SCL will have gaps and 
inadequacies in it which CL will eventually, we all hope and pray, 
get sorted out, such as exactly what a sorted syntax is supposed to 
be like, or how to do a full-KIF-style meta-logic for a language 
defined using an abstract syntax. There is no way we will get things 
like that done in six months, so lets agree to just forget about 
them, other than to in trying to avoid taking decisions which might 
screw up any future work.

Fourth, and somewhat in opposition to the last, SCL will need to 
allow some 'nonlogical' features which might reasonably be thought to 
be out of place in CL. For example, the XML schema datatypes (XSD) 
comprise a fairly large collection of domains which are defined in a 
style which is a kind of mixture of informal algebra and recursion. 
To incorporate XSD into CL in a kosher way would seem to require 
writing out explicit ontologies for these domains, which would be a 
considerable amount of work, would tax the expressive powers of full 
KIF, which has no explicit fixed-point semantics, and would in any 
case be inappropriate since it would be doing the XML Schema WG's job 
for them. I would instead propose that SCL be provided with a 
suitable vocabulary which is simply required, by semantic fiat, to 
have the appropriate denotations in the XSD domains (eg see the 
treatment of XSD datatypes in 
http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/#Lbase). This 
would make SCL into something other than a true logician's logic, but 
it has the merits of simplicity and instant compatibility; and 
applications are of course free to declare that their usage or 
understanding of the SCL XSD vocabulary is limited in some way (eg to 
checking datatype  lexical instances for syntactic conformance, say).

I hope this helps to clarify things.

More later.

Pat Hayes

PS.. For those who feel a need to get up to speed with any of the 
relevant topics, here are some places to get info:
CL: http://cl.tamu.edu/
KIF (ancestor of CL): http://www-ksl.stanford.edu/knowledge-sharing/kif/
RDF (basic semantic web standard): background: http://www.w3.org/RDF/
activity: http://www.w3.org/2001/sw/RDFCore/
OWL (new s.w. standard, successor to DAML): http://www.w3.org/2001/sw/WebOnt/
XSD: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
-- 
---------------------------------------------------------------------
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