[SCL] Approach to a concrete syntax

[pat hayes]

>Tanel Tammet wrote:
>>  Murray Altheim wrote:
>>
>>>  I suppose it's less interesting because there is less understanding
>>>  now that the issues of markup have hit the table.
>>
>>
>>  In a way, yes: I'd like to avoid putting too much stress on the
>>  markup issues right now. Not that they are unimportant, though.
>>
>>>  I think you're missing my point: in expressing SCL in RDF you have no
>>>  ability to avoid the complexities.
>>
>>
>>  I do completely agree to what you say here. What I was saying is that
>>  we have several issues at hand (*) complexity issue, where I'd like to
>>  avoid covering all possible the problems which may appear (*) RDF issue.
>>  I do NOT think that RDF issue simplifies things (that is why I did
>>  not initially try to make SCL-in-XML RDF-compatible). IMHO both the
>>  complexity issue and the RDF issue have to be taken seriously.
>>
>>  Even more: since attempts for RDF compatibility (whatever this will mean)
>>  will by nature bring additional potential complexities, we should then be
>>  ESPECIALLY careful to avoid going into all the rising actual and
>>  potential complexities.
>
>I think we're on the same page, or should I say, in the same room.
>
>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.

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.

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.

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.

>we're altering the form of expression from use
>of the commonly-used expressions of FOL (such as upside down As and
>backward Es) to an expression in XML markup, constituting an XML
>markup language. This in SGML parlance would be called "an application
>of SGML". It is a strict syntax that has a direct relationship with
>the semantics it embodies.
>
>When we express character data in a computer system we use a specific
>character set. In XML this is Unicode/ISO 10646. The character set
>for XML includes the characters used in expressions of classical
>FOL, such as ÅÕ (upside down "A" if your emailer doesn't display
>this correctly) and Å‘ (backwards "E"). I believe it would be
>possible in SGML (but not in XML) to design an SGML application
>that could actually use these characters directly as markup
>characters, and I think it'd even be possible to express FOL in
>SGML without alteration. There could be a few hitches, point is,
>SGML doesn't require you to use angle brackets. These can be altered
>in the SGML declaration.
>
>The entire set of "characters" are actually termed "glyphs" in
>Unicode*, owing to their absence of interpretation. They're just
>abstract symbols with no meaning whatsoever, absent interpretation
>in a given context. They're not even "characters" yet!
>
>An expression of "classical" FOL is a form of markup, expressing
>the formal, model-theoretical semantics of FOL using an accepted
>lexical notation.
>
>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.

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

>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 want to work with the 
W3C, or at least on a converging tracks, not in opposition to them.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20030525/97e237f4/attachment.htm