[SCL] Approach to a concrete syntax

[pat hayes]

>pat hayes wrote:
>>>Murray Altheim wrote:
>[...]
>>>In going from the strict, model-theoretic semantics of SCL into an
>>>expression in XML,
>>
>>No; look, we aren't doing that. None of us are doing that. The XML 
>>syntax for SCL doesn't go FROM the model theory; it PRESERVES the 
>>model theory by expressing the full syntactic structure of SCL. The 
>>'commonly-used' upside-down A's and so forth are completely 
>>irrelevant.  SCL has been designed so that its abstract syntax 
>>makes NO committment to particular glyphs, character sequences, 
>>whatever. It doesn't even require that the syntax be encodable as a 
>>sequence of character codes, in fact: it could be encoded 
>>diagrammatically, or using sounds, or abstract 9-dimensional 
>>structures in superstring theory: anything you like; all that is 
>>required is that whatever the form used, it somehow make the 
>>syntactic distinctions required by the abstract syntax salient; it 
>>must be parsable as SCL. We don't want it to alter or adapt or 
>>extend the SCL abstract syntax; we just want it to express it, and 
>>to do so accurately, so that it can be a legal SCL language.
>
>Pat, you take from one of my utterances one preposition ("from") and
>incorrectly ascribe to my proposals some assumption of the XML syntax
>making changes to the SCL model theory. I am not stupid. I understand
>the difference between what you are calling an "abstract syntax" and
>XML as one of many possible "concrete syntaxes". It's not a difficult
>concept. I have an IQ larger than a mango. If you've read my email
>messages to this list and skimmed through the XCL proposal [XCL] you
>should see that I've repeatedly used language that states this. The
>very first goal stated clearly in the XCL spec is that "XCL should be
>compatible with CL"

I want a rather stronger notion than compatibility.  SCL/XML should 
*be* SCL, rendered into XML.

>and:
>
>   1.  XCL should conform to the CL abstract model, as expressed in
>       the CL standard (when available).
>   2. It should be a relatively straightforward process to convert
>      core XCL documents to other CL concrete syntaxes.
>   3. The core features of XCL syntax should have essentially the same
>      expressive power as CL.

The issue isn't expressive power so much as syntactic fidelity.

>
>[read "CL" as "SCL" here.]
>
>So even where I didn't use exactly the same language as you might
>have ("abstract model" vs. "model theory"), it should seem fairly
>clear that we have the same goals for an XML syntax.

To me the distinction between model theory and syntax (of any degree 
of abstraction) is fairly fundamental, and I guess I took you at your 
word. Sorry if we were at cross purposes.

>
>>Now, your level 2 envisions a webbified version of SCL. I agree 
>>this is a worthwhile goal, though rather more ambitious that our 
>>immediate one, but I think we need to ask some serious questions 
>>first about what kind of ways is a logical language going to be 
>>used on the Web. This is where it might be useful to look at 
>>RDFs?OWL/DAML , without being too slavish, in order to get a sense 
>>of what kinds of webbification are being contemplated. Extending 
>>the basic logical structure of the language isn't one of them; 
>>allowing things like importing, mutual referencing, versioning of 
>>ontologies is; so is issues like how to trace logical names to 
>>their 'source' and what that means exactly. So is how to express 
>>that one ontology is restricted to a particular universe of 
>>discourse, but the terminology it uses is being used in an ontology 
>>with a larger or smaller universe of discourse.
>
>Nothing I've proposed in XCL Level 2 in itself modifies the essential
>model theory that would be in Level 1.

Look, lets forget about model theory.  One of the basic goals of the 
SCL project is that there will only be one model theory, defined on 
the abstract syntax.  The only issue to be raised when talking about 
XML is the relationship between the XML syntax and the abstract 
syntax.

>All it does is alter the specific
>syntax used to express it in a way that *could* be modified by other
>people.

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.

>And as I've said before, the reason I've proposed both a "Level 1"
>and a "Level 2" at the same time is not to create some alternate model,
>but to provide (in Level 2) a clear path between the core syntax and
>one that is extendable. I repeat: I have not in either XCL Level 1 or
>Level 2 designed a syntax *different* than the SCL model theory, I've
>only in Level 2 *allowed others* to alter it.

And I wish you would not do that, because it isn't meant to be 
alterable. It is meant to be what it is.

>
>Now, if my XCL proposal in reality doesn't match SCL, it is not by
>intention but because I've not seen a stable SCL long enough and had
>enough time to update my draft to match it, OR (and this is a distinct
>and likely possibility) I didn't understand all the angles on the
>design well enough to implement them correctly. But -- I have NEVER
>expressed an intention to *alter* the SCL semantics in the delivered XCL
>specifications, either Level 1 or 2, neither in email, on the phone,
>or in the XCL proposal.

Then perhaps I misunderstood your discussion about there being many 
forms of quantifier. Adding extra quantifiers, or adding syntax that 
allows users to define new syntactic classes of quantifier, is an 
alteration to the SCL proposal.

>>That last one is a REAL problem that nobody is taking seriously 
>>enough and arises immediately on the Web, and which we could maybe 
>>make some genuine contribution to. For examp0le, suppose ontology A 
>>which is about human beings wants to use a relation name R used and 
>>'owned' by ontology B which is about Americans. In B, something 
>>might be said about the complement of R, meaning (but not saying 
>>explicitly) all Americans for which R is false. In A, however, this 
>>needs to be uniformly qualified by inserting the 'all Americans' 
>>qualifiation systematically, in order to translate adequately 
>>between the ontologies. Now, it would be GREAT if we could provide 
>>a notation for expressing that kind of 
>>translation-between-universes as part of the importation (using 
>>URIs which need to be dereferenced using HTTP protocols plus an SCL 
>>- encompassing RDFS and OWL - XML MIME-type rule of interpretation, 
>>perhaps?) when referring to an ontology but not when used as a 
>>relation name.
>
>Well, that sounds like a mapping problem. Topic Maps were designed to
>solve exactly this kind of problem.

Can TMs describe quantifier restrictions? (Genuine question; if the 
answer is yes then I need to do some reading, URIs would be greatly 
appreciated.)

>
>>Its not that Im against webbification or uninterested in it, but I 
>>don't want it to mess with the aspects of SCL that we have got 
>>right, but ignore the aspects of logic-on-the-web that really need 
>>urgent attention.
>
>Perhaps I'm not parsing that sentence correctly. Do you differentiate
>"webbication" and "logic-on-the-web" or consider them the same thing?

I meant them to be loosely synonymous.

>
>[...]
>>>What I believe we can do with XML is treat that minimally. I'll
>>>endeavour to fix up Chris' draft as promised, and also alter my
>>>XCL Level 1 syntax to match his as closely as possible, with the
>>>minor alterations I've proposed to Pat, and which are already
>>>there but not as clear as could be.
>>
>>Look, let me be blunt about this. Any XML syntax which alters the 
>>logical syntax of the SCL abstract syntax in ANY way is 
>>unacceptable. Minor alterations are just as destructive of the 
>>semantics as major alterations.  If you feel that the SCL syntax 
>>should be extended or altered, propose the alterations to the group 
>>and we can discuss them.  But in the final document, the XML/SCL 
>>syntax, like all the other concrete syntaxes for SCL, *must* track 
>>the SCL abstract syntax exactly. This is central to the entire 
>>project, and is not negotiable.
>
>I sometimes feel you need to consider me as an antagonist. Where have
>you gotten the idea that I've proposed an XML syntax that alters the
>SCL abstract syntax? In every case where I've suggested things like
>general quantifiers, I've done so as a *potential extension* to the
>base XML syntax, not as the delivered XCL specification.

Yes, but (1) those extensions, even if only potential, would be 
anathema to the SCL project, and (2) these potential extensions 
apparently have very real consequences for the structure of the XML 
syntax proposal. Having a similar syntactic form for quantifiers, 
connectives and relations, for example, is positively misleading and 
is likely to create problems.

>I've made
>the kinds of proposals I've made to *enable* those kinds of extensions,
>not to propose that the delivered syntax *itself* have those extensions.

I would prefer that extensions which are not clearly motivated by 
possible semantic extensions actually be disabled rather than 
enabled, frankly.

>
>>>Then, following on from Level
>>>1 is XCL Level 2, a lexically-different but semantically
>>>identical XML markup language. The only difference between Level
>>>1 and 2 in practice is that the latter is web-enabled, and may
>>>form the basis of other forms of logic *without* requiring new
>>>syntax. And any alterations in syntax will *hopefully* be with
>>>only very minor changes. I can envision an extension that would
>>>express the situational calculus with only a few small changes.
>>
>>What situational calculus? (If you mean in the AI sense, its 
>>already expressible as a first-order, and hence SCL, theory)
>
>Forget the situational calculus for a moment. Did you not read in
>that paragraph (and part of that paragraph you didn't quote above)
>that what I've proposed is an *attempt* at a faithful rendition
>of SCL-in-XML? Why not lay off the boogeyman bit -- I'm not trying
>to alter first order logic

I guess Im lost at this point. That sounds exactly like what you are 
trying to do, as you say above:  "other forms of logic without 
requiring new syntax." That is pretty much the definition of a change 
to the logic. Maybe we aren't communicating properly.

>-- and you guys can concentrate on getting
>SCL right, and I'll stop asking penetrating questions and sit
>quietly on the sidelines in my unthinking, non-conceptualizing way
>and just write grammar rules.
>
>>>Now, I don't claim to be a mathematician, but I'm pretty sure I
>>>can pull this off. I do understand that Pat has little interest
>>>in that, which is fine.
>>
>>Actually I have a lot of interest in it, but I think I may have a 
>>different long-term agenda. I take the W3C Semantic web standards 
>>seriously - I don't exactly love them, but I take them seriously - 
>>but have little to no interest in topic maps. [...]
>
>I've not proposed a Topic Map solution. XCL is simple XML. If
>I talk about Topic Maps, it's because I'm using them for my
>own projects. The idea of using PSIs is something just as useful
>to the RDF community. The only difference between PSIs and URIs
>is that the former provides a reasonable publishing methodology
>so that humans and computers can use them, whereas there is
>nothing available from the W3C or anyone else that satisfies
>this need (to my knowledge). If you want to think that PSIs have
>nothing to do with Topic Maps, that would probably give Bernard
>Vatant (chair of the OASIS Published Subjects TC) no grief.
>
>>  I want to work with the W3C,
>>  or at least on a converging tracks, not in opposition to them.
>
>Well, we can certainly have different agendas. I don't take them so
>seriously, but neither do I consider I'm working in opposition to
>them. I am simply ignoring them.

OK, fair enough; but I'm definitely not ignoring them. I hope to work 
with them in the future.

>I don't consider anything I've
>proposed so far to disable some potential convergence of technologies.
>I'm sure some engineer could write an XCL-to-RDF or RDF-to-XCL
>converter in XSLT in an afternoon. If you think the only thing
>that is acceptable to the community you consider relevant is some
>W3C RDF-based markup language, fine. I'm absolutely certain there's
>enough money and interest to keep that going within its own
>community. Little I say or do will have any effect on that. And
>if this group doesn't have any interest in an XML syntax (i.e.,
>a syntax that's not RDF-based), I'll probably still publish an
>XCL spec. I think it's a good idea, and it's a free world, right?

Of course. I would ask you, however, simply as a courtesy, to not 
assert that your language is an SCL language if it turns out not to 
be one.

>If it is in the end ignored, fine.

This is the state we are all in, of course :-)

>
>In summary:
>
>I don't find this approach to communication very productive. I
>basically have expressed an interest in assisting in developing
>an XML concrete syntax for CL/SCL.

I would love for you to do that; but you need to actually take part 
in the CL/SCL process to some extent. We have certain ground 
assumptions about the project, and some aspects of it are considered 
to be settled, and other matters are definitely outside of its scope. 
If you are willing to work with the rest of the group, that would be 
great.

Here's a question on what I hope is a more constructive note. Suppose 
that we (along the lines of your level1/2 distinction) separate out 
SCL-the -basic-logic from a 'web logic' version which would be more 
specialized but have special features intended for handling 
ontologies on the Web. Examples of what this might involve would be 
special ways of handling URIs and URIrefs, perhaps a specialized 
ontology for mapping between syntactic forms , eg functions like 
"RDF2SCL' which are required to evaluate according to predefined 
translations, syntactically distinct ways to use URI as names as 
opposed to URIs as references to other ontologies, perhaps a 
Web-oriented quotation feature to allow ontologies to refer to 
character strings, perhaps a more web-oriented set of built-in 
datatypes (such as XSD) and so on. Then your level 2 could be the XML 
syntax for this Web-SCL logic. Would this seem worthwhile to you? And 
would you have any ideas for what ought to be in such a logic?

>In return I seem to have been
>turned into the markup boogeyman and asked to please sit in the
>corner. I've not proposed anything except what I've called "SCL-
>in-XML" and "SCL-on-the-Web", two concepts that I thought would
>be straightforwardly easy to understand and noncontroversial.

Welcome to the world of committees.

>In
>return for that I've had to continually defend myself, discuss
>the merits of RDF vs. Topic Maps (which is pointless),

I would be very happy to not mention RDF or Topic Maps ever again 
when discussing the SCL/XML syntax. I only mentioned TMs because 
several of your innovations seemed to be somehow connected with them, 
if only sociologically. But I apologize if this was inappropriate.

>  be careful
>not to ask too penetrating questions, etc.  I hate to say not to
>look a gift horse in the mouth, but this horse is getting pretty
>tired of bearing that load. I could be spending my time much more
>productively either actually *designing* things for this project
>or some other project, like my Ph.D. studies or my own papers.
>Despite what might seem the case, arguing in email is one of my
>*least* favourite activities, second only to cleaning the toilet.
>I'd rather just get some productive work done.

I don't much like having email wars either, but the points at issue 
are substantive. You have, very kindly and selflessly, designed us an 
XML syntax. There are aspects of that syntax which are puzzling, 
however, and when we (I?) asked you about them, the reasons you have 
given for doing things that way seemed to be divergent from the 
central goals of the project. I don't feel that it is unreasonable or 
inappropriate for us to discuss these issues further, or in more 
depth, before agreeing that they should be incorporated into the 
design. The rest of our discussions seem to have arisen from mutual 
misunderstandings about terminology, which almost always arise in 
these kind of efforts involving people from different backgrounds, 
and the only solution to them is to talk through them until we 
achieve mutual comprehension. I know its a slow process but I don't 
see any other alternative if we are going to work together.

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