[SCL] Approach to a concrete syntax

[pat hayes]

>pat hayes[even]:
>>>Murray Altheim [odd]:

(Reference to depth of nesting, not personal characteristics)

>[...]
>>>>No!  We should not require users to restrict themselves to any 
>>>>particular syntax for logical names. If they want to use PSIs, 
>>>>then obviously we can allow that; but we must not require it. 
>>>>Similarly for URIs.
>>>
>>>I think we're talking past each other, AFAIK. I'm not trying to restrict
>>>anything, I'm trying to open things up.
>>
>>What I mean is, that SCL should not require any particular format 
>>for identifiers (logical names) . If someone wants to use 'father' 
>>(six ascii characters) as a relation name, then the fact that that 
>>string isnt a URI or a PSI should not be a barrier to their using 
>>it.  Some SCL languages will be web languages, but others will be 
>>use in other ways and may have other reasons for imposing their own 
>>syntactic conventions on names.
>
>Topic Maps solves this

Solves? What needs to be solved here? I didn't think I was stating a problem.

>  by considering that whatever that "ur" thing
>is we're talking about, one can assign it zero or more names, and these
>can be in any form whatsoever (even links to external things that can't
>be expressed in characters, like graphical icons, images, QuickTime
>movies, etc.)

Sure, we can use links for that, I agree. Thee is no logical reason 
why a relation name cannot be something like an image or even a 
movie, though that latter strains my semantic imagination.

>. If we're still talking some separation between expressed
>syntax (XML) and semantics, at the syntactic level things in XML are
>referred to generally by identifier. The identifiers (IDs) can be XML name
>tokens (which have a restricted syntax, e.g., no whitespace), URIs as
>links, query expressions, etc.
>
>>>>>such as
>>>>>
>>>>>     http://pathayes.org/psi/myPredicates.html#meet
>>>>>
>>>>>and publish a short document describing the PSI in human-readable
>>>>>language (letting the world know what it means)
>>>>
>>>>
>>>>It is unlikely that any such document can possibly capture the 
>>>>formal meaning. Again, English comments are a useful feature 
>>>>which we should allow as an option, but not require.
>>
>>>The document at that URL contains an ID "meet". When you point your
>>>web browser at that URL, the page loads and the document scrolls
>>>down to something called "meet", where there is a definition of what
>>>the predicate meet(i,j) means. A formal definition.
>>
>>This is going outside our topic to some extent, but this account 
>>just doesn't work. First, the ways in which browsers should 
>>interact with reasoning is highly controversial and labile, and  it 
>>would be very inadvisable for us to assume that it will be globally 
>>settled in this kind of a way. For one thing, its not clear that SW 
>>formalisms will have anything to do with browsers at all; SW 
>>engines might use HTTP for completely different purposes. Second, 
>>most formal names (predicates or otherwise) simply do not have 
>>definitions: the whole idea of a 'definition' does not fit well 
>>with logical semantics. Third, even if it had one, there is no 
>>utility to be had from writing it in English and making it readable 
>>by a human being watching a browser screen: the entire point of the 
>>semantic web is that meanings of this kind of markup must be 
>>accessible by software, without human invention.
>
>I clearly don't understand your point of view. There is no world in
>which humans are not involved in interpretation that is separated
>from interpretation.

Not sure I can parse that.

>Software is just an intermediary written by humans,
>and the software used in processing SCL is not just a telephone connection
>used as a carrier for information, it's reasoning is based on whatever the
>programmer understood when writing it.

Yes and no. This is obviously true in some sense, but in a stronger 
sense (which is often intended, since the weak, true, sense is kind 
of uninteresting) it is false. Software can incorporate and use 
understanding, and can do so in ways that were not forseen by the 
writer of the software. This is the entire point of having machines 
which can draw conclusions from information expressed in formal 
notations.

>This reasoning is expressed using
>identifiers for concepts.

No, it is expressed in terms of validity of inference processes which 
can be performed by software.

>When I put my ATM card in the machine, it uses
>an identifier for "Murray's bank account". It's not meaningless.

It is meaningful to the machine just to the extent that the machine 
can utilize some information about what it means. Machines cannot 
read English.

>I don't believe meaning exists in machines. Do you?

Yes, most definitely. I believe that I am such a machine, myself; but 
I don't expect you to necessarily agree with that :-) In fact, Im 
willing to go out on a limb and say I believe that this is 
*characteristic* of machines that we call computers: they are 
machines in which meaning genuinely exists, in a sense which can be 
made objective. But now we really are getting into the philosophical 
weeds, I admit.

>If there's meaning,
>it's only in interpretation.

Interpretations is a way of expressing the notion of meaning.

>
>>>The URL is used
>>>as an identifier for the concept "meet(i,j)".
>>
>>Fourth, there isn't a coherent notion of a "concept" which can be 
>>given an identifier.
>
>Then how does anything get expressed as "x"?

Well, how it works is, that we use names in our sentences (the 
assertional building blocks of logic) and the names mean whatever 
they need to mean to make the sentences true. We trade sentences with 
one another (and let us suppose, somewhat naively, that we always 
believe what we are told) and we draw conclusions from them, using 
logically valid methods approved by the semantic specs of the 
languages we are using.  All of this can also be done by software. 
That is the central modus operandi of the semantic web.

>What is the connection between
>"x" and the thing it represents?

There is no single 'thing it represents', most of the time. The 
connection you are referring to is denotation, but that is basically 
a three-way relation, between a name, a referent and *an 
interpretation*.

>  Is "x" a name/identifier for something?

No.

>Or does "x" represent nothing?

It represents one thing in one interpretation, something else in a 
different interpretation.

>So in this example, I used "meet()" because
>I know you know what it means -- you defined it.

No, I didn't. It has no definition, in fact. What it has is a 
associated axiomatization - a set of sentences that everyone is asked 
to believe are true - but they do not add up to a *definition*. And 
they don't need to: they are quite adequate for the job without being 
a definition.

>If I point a browser at
>a definition of "meet()" we can talk about it.

We can, you and I, because we can read and talk English. But software 
cannot do this; so to make the SW web work, we need something other 
than a browser.

>Hey, I haven't even pointed
>a browser at it and we both know what it's about. I can refer to it as
>John Sowa did in his KR book [KR] on page 114 as "Allen and Hayes (1985)"
>and you know what I'm talking about. Well, "[KR]" and "Allen and Hayes
>(1985)" are identifiers, names for things. We can assign them URLs and
>let people write software to reason about them.

No, look, there is a level missing in your account. If people have to 
read web pages and write software to handle every concept they find 
there, the SW isn't going to work. What the people are going to write 
are *general-purpose reasoning engines*, and then THEY - the engines 
-  are going to go out on the Web, find sentences and put them 
together and come to conclusions, ALL BY THEMSELVES. If they have to 
stop and ask a human being what this all means, the SW won't work. It 
has to work at electronic speeds without human intervention.

>
>>>If you as the publisher
>>>want to say that that URL is stable, i.e., for other people to use
>>>as an identifier too, then you call that URL a PSI. Then when two
>>>people want to refer to "meet(i,j)", they use
>>>
>>>     http://pathayes.org/psi/myPredicates.html#meet
>>
>>It seems to me that this can be done just by using URI conventions, 
>>as in RDF, no?
>
>Yes. PSIs are *just* URIs. The *only* difference is that the person
>publishing them (telling the world they exist) says that they are stable
>enough to be used as identifiers, that their meaning won't change within
>some reasonable period. And there are some recommendations on publishing
>metadata with them. But they're just URIs.

OK, lets agree then that we are talking about URIs. Im happy with 
using URIs in the XML syntax.

>
>[...]
>>>>>  > ??When did datatypes come into the discussion??
>>>>>
>>>>>When we began talking about XML markup.
>>
>>I didn't think we were talking about markup at all. What we are 
>>looking for is an XML syntax for SCL, not an SCL-style markup 
>>language. (Have I misunderstood what you mean by 'markup'? )
>
>How do you differentiate "XML" from "markup"? XML is a form of markup. If
>you express SCL as XML, you're expressing it in an XML markup language.

OK, just terminology. I was understanding 'markup' to mean, well, 
mark-up, ie annotating (hyper)text with essentially compositing 
information. If XML is all 'markup' by definition, then I will just 
ignore that word from now on.

>>>>>The string "exists" is a string,
>>>>>whereas "http://purl.org/xcl/1.0/#exists" should not be interpreted as
>>>>>a string, but rather as a URI.
>>>>
>>>>
>>>>I have it on good W3C authority that URIs are strings. They 
>>>>certainly seem to be strings to me: RFC 2396 defines URIs as 
>>>>character sequences and XML Schema Part 2 defines XSD strings the 
>>>>same way.
>>>
>>>
>>>Well, admittedly URIs are not cacti either. They may be composed of
>>>strings, as are numerals, but they're *interpreted* as URIs.
>>
>>Oh, sure: but we are talking here about syntax, right? And in the 
>>syntax they are strings (of a particular form, but still strings).
>
>That particular form is what I'm calling a "datatype", i.e., what the
>string is interpreted as. In XML it's important to differentiate them
>so that URIs can be treated as URIs, not strings. They're not the same
>thing.

I want to worry on this bone because we had a lot of discussions 
inside the RDF core WG (and between us and XMLS) about this. The XML 
datatypes model (in its current form)  insists that value spaces of 
different datatypes are distinct; but it also defines them in ways 
which require some of them to be identical. Strings and URIs are a 
case in point. On the face of it this is incoherent. The revised 
version will correct this, by defining the value spaces so that they 
can overlap, but insisting that entities of a given datatype (eg 
URIs) are conceptually pairs of the thing itself and the datatype it 
is supposed to come from. This, it turns out, is required in order to 
make theXML datatype model mathematically coherent. So URIs *are* 
strings (for example) - they *are* the same thing - but they are 
'seen' as different when thought of as URIs than when they are 
thought of as strings.

However, I am still puzzled why this 'thought of as' distinction is 
relevant to a syntax specification. Syntax is what it is: it consists 
of (traditionally) marks on a surface, perhaps better marks on a 
hypersurface, for hypertext. Still, I don't see where a *datatype* 
distinction would become relevant when describing syntax, even 
hyper-syntax.

>>>In the
>>>specific context of an XML document, one needs to know whether to
>>>interpret any specific string as a decimal number, a hexidecimal
>>>number, a date, a URI, etc.
>>
>>BUt this would only be an issue for us if we planned to use these 
>>constructs in the SCL syntax, right? And we do not (currently).
>
>I'm planning on using URIs. But I'm on a diffent project it seems.
>So is Tanel, since he plans to work in RDF/RDFS, which is completely
>littered with URIs.

I have no objection to using URIs; RDF itself is littered with URIs, 
and I wrote its semantics.  My concern is with the XML datatypes.

BUt lets agree to stop arguing over this; Im sure that your sense of 
good design here is superior to mine.

....

>
>I suppose before we go on we must mutually understand the difference
>in your mind between "XML" and "markup". XML is not just a string of
>characters, its an interpretation of a string of characters as a
>combination of markup characters and data characters. There is a distinct
>differentiation between markup and content, for example, the "<" and ">"
>are interpreted differently than "a" or "b".

Yes, but you are talking about an *interpretation*, and I am talking 
about *syntax*.

>
>If SCL's XML expression is text, pure and simple, then you're claiming
>that "<" and ">" are not to be interpreted as markup characters?

No, of course not. My point can be expressed by saying that markup 
characters are still *characters*.  But it would help if you could 
tell me, in return, what you mean by 'markup' in the case when there 
is no text be be marked up. This XML syntax is not a set of 
annotations attaching markup to an existing text: It IS the text; 
there is no other text to be marked, up or in any other way. (Im not 
making a cute rhetorical point here, by the way: I am, and always 
have been, centrally puzzled by this question, which seems to be at 
the heart of XML. XML as a markup notation I can understand, and its 
design makes good sense. XML as a syntax specification language seems 
to me to be another kind of thing altogether, and the design of XML 
seems ill-suited to that task. Somewhere, a text markup convention 
got morphed into a general-purpose structural description language.)
....

>
>>>SCL processors wouldn't know how to
>>>interpret/process it. So what I'm suggesting is that rather than
>>>use an attribute, we break it off into an element, well, actually
>>>two elements (showing a more appropriate expression of the previous
>>>two examples):
>>>
>>>    <quantifier>
>>>      <type>forall</type>
>>>      ...
>>>    </quantifier>
>>>
>>>    <quantifier>
>>>      <typeRef xlink:href="http://purl.org/cl/scl/1.0/#forall"/>
>>>      ...
>>>    </quantifier>
>>>I can design an XML schema (a DTD, RELAXNG grammar or XML Schema
>>>document) to define this easily. There's no ambiguity. In DTD
>>>syntax this would be (ignoring the "..." content for now):
>>>
>>>   <!ELEMENT quantifier  ( type | typeRef ) >
>>>   <!ELEMENT type  ( PCDATA )* >
>>>   <!ELEMENT typeRef  EMPTY >
>>>   <!ATTLIST typeRef
>>>       xlink:href    CDATA    #REQUIRED
>>>   >
>>>
>>>This declares three element types, <quantifier>, <type>, and <typeRef>.
>>>The content of <quantifier is one <type> OR one <typeRef>. The former
>>>contains character data (PCDATA), the latter is a linking element
>>>that has an attribute containing a URI. If we were using RELAXNG or
>>>XML Schema this would look a hell of a lot more complicated, but we
>>>could constrain the contents of <type> and <typeRef> so that a validator
>>>would flag an error if it found the wrong datatype. Actually, there's
>>>a trick in DTDs called "enumerated values" where we could change <type>
>>>from having element content to having an attribute, then constrain the
>>>attribute to having a fixed set of name tokens, such as "forall" or
>>>"exists". Then even XML 1.0 validators using DTDs could flag errors.
>>>
>>>I'm guessing this is more than you wanted to know, but I'm trying to
>>>be clear.
>>
>>
>>All of this seems to be solving a problem (in fact an entire series 
>>of problems) which should never have been allowed to arise in the 
>>first place. They are artifacts of XML, and have no relevance to 
>>SCL.
>
>I thought we were trying to design an XML syntax for SCL. I'm trying
>to solve the issues that arise in designing such a syntax. That certainly
>seems relevant to me. No, they aren't relevant to SCL as an abstract
>syntax. They are artifacts of XML. We are discussing an XML syntax for SCL.
>Am I in the wrong room?

What I meant was, these problems arise from the complexities of the 
particular(ly complicated) form of your XML syntax. So I am left 
wondering why you do not avoid them by simplifying the syntax, rather 
than by complicating it, since these complexities are not mandated by 
the needs of SCL itself.

.....
>>
>>>I'm
>>>suggesting a means of allowing constraints that would allow a
>>>restriction to the exact set of quantifiers, connectives and
>>>predicates in SCL, but also allow it to be extended.
>>
>>
>>There is absolutely no need to allow for extending the quantifiers 
>>and connectives, any more than English needs to allow for new 
>>grammatical forms. Extending the set of predicates is another 
>>matter, but there the error is to label them as 'predicate' in the 
>>syntax in the first place.
>>
>>(It might make sense to allow for extending SCL by entirely other 
>>classes of syntactic operators. For example, someone might want to 
>>add modalities to the language, or have a special comment 
>>attachment syntax for encoding detailed provenance information, or 
>>to allow terms with bound variables such as lambda-expressions . 
>>But these would be entirely new classes in the syntax, not new 
>>types of connective or quantifier.)
>
>The idea with XCL (my proposal for SCL expressed in XML, i.e., an
>XML markup language expressing SCL), is that the Level 1 syntax is
>an exact expression of SCL with nothing else. XCL Level 2 is the
>XML framework upon which modal and other forms of logic can sit.

OK, fair enough; but then you havnt designed it right. In order to 
provide for future modal extensions, for example, you do not need to 
add new quantifiers or new connectives. Modalities are an entirely 
different kind of syntactic construction with their own special 
requirements (eg you will want to be able to associate diamonds with 
boxes in natural pairings, and you might want to allow for external 
links to things like transition diagrams, and you will want to 
distinguish types of modality). Lambda-terms are yet another 
syntactic type with its own complications; they are something like 
quantifiers but typically have associated types which might have 
their own special syntax, so if you treat them as quantifiers you 
will need infinitely many of them.  Sorted logics are yet another 
kind of syntax extension in which each argument place has an 
associated sort, and there might be an elementary syntax for 
expressing sort relationships which is also connected to the 
quantifier syntax in a new way.  And so on.  It would be an 
interesting project to try to invent a kind of general-purpose syntax 
toolkit that could be morphed into all these forms (I'm sure that it 
could be done, at some level these are all acyclic labelled graph 
structures, and at another level one can describe all of his as a 
kind of higher-order term logic, and then use Montague-style tricks 
to incorporate the non-tree-like aspects) but I really don't think 
that the world needs this, to be frank. It tends to get so abstract 
and so far removed from the intuitive business of actually making 
factual assertions that the generality isn't worth the effort of 
using it for anyone but a rather rare species of mathematical 
logician. It would be easier to just use a new DTD.

>They're not in conflict, and because Level 1 syntax has a Level 2
>isomorphism, there's no reason why XCL Level 2 can't be taken
>entirely offline and I'll just take over the known world by myself,
>thankyouverymuch. But the expression of SCL-in-XCL shouldn't preclude
>being extended. I'm just trying to coordinate what you little people
>do with what I'm doing while taking over the world.

Good luck. You might try reading up on Montague semantics and type 
theory before designing level 2, if you really do have these grand 
ambitions.
....

>>
>>I am not particularly interested in allowing users to extend the 
>>base language. If people ever plan to extend the language then they 
>>will presumably use new syntax categories, and the XML markup of 
>>their extended languages will reflect that extra structure. But we 
>>cannot pre-guess what that will be or what it will mean.
>
>My point is that with a very minor variation in syntax (not even in
>using XLink or anything fancy, just moving some stuff from being
>attributes to being child elements), my megalomaniacal fantasies can
>be lived out to their fullest.

In order for them to be interesting, you have to fantasize about 
extending the model theory to go along with these syntactic 
extensions; and you have to make sure you are providing the right 
kind of extensibility.

>>>>
>>>>A distinctive prefix for variables is a widely used convention. I 
>>>>would abandon it only very reluctantly and under the pressure of 
>>>>a very cogent reason.
>>>
>>>The reason is that the notation is not classical FOL, it's XML.
>>
>>That is irrelevant; the point is to make it easy to transfer 
>>syntactic forms between different syntaxes. If the XML syntax is 
>>the only one which writes variables differently, what is gained by 
>>being idiosyncratic? Its not as though one or two extra characters 
>>are likely to be noticed in the deluge of tag names, after all.
>
>No, that's correct. I was just pointing out that the "?" is entirely
>unnecessary. You yourself have said this is all to be interpreted by
>computers. We can assume the upside down "A" is interpreted as a "forall",
>and <boundvar>x</boundvar> is interpreted as "?x" would be in classical
>FOL. In the XML syntax you don't need the question mark.

You don't need it, but it does no harm; and it makes the transition 
between this form and other forms easier.

>
>[...]
>>Well, maybe, but please tell us what your project is, and then we 
>>can discuss it. For a start, why do you think that anyone will want 
>>to extent the quantifiers and connectives, and what role do you see 
>>XSCL having in markup?
>
>I've clearly published my project and referred to it a number of times.
>I've tried to describe it repeatedly. XCL Level 1 is an expression of
>SCL in XML. XCL Level 2 is an extension of Level 1 that allows for
>web things like links, URIs, etc. Both you and Tanel apparently think
>you can express SCL in RDF. Well, with RDF you are already in "Level 2"
>territory, with links, URIs, etc. All I'm trying to do is have a basic
>SCL-in-XML syntax that is in great harmony with its Level 2 syntax,
>i.e., that they are semantically *identical*, with *nothing* added by
>the move in levels, a smooth transition. You won't get that with RDF,
>as you've added the entire mess of RDF/RDFS semantics to it. Whether
>you believe it or not.

OK, but this doesn't mention your overall emphasis on 'extending' SCL 
to other notations and languages. Is that level 3?

BTW, I am all for using links in the XML syntax. But lets look at 
some of the actual uses. There is little (zero?) utility in allowing 
a link to specify a quantifier. There is however considerable utility 
in allowing a link to indicate a file containing SCL-XML expressions 
which are understood to be 'imported' in place of the link. This 
trick has already been used in several implementations and it has 
obvious utility in composing ontologies from multiple sources. 
Suppose we were to allow an 'importation' assumption into the SCL-XML 
syntax, what would be the best way to do it?

OWL has an 'import <uriref> ' assertional form in its syntax, but 
this only allows 'top-level' importing. Jos DeRoos' Euler program 
uses what one might call micro-importing, in which a single complex 
expression can be distributed over a bunch of files and then the URLs 
of those files are used as syntactic components, so that (<uri-1> 
implies <uri-2> ) can be a single sentence which encodes a much more 
complicated one.  We might try for this - we would need to 
distinguish various uses of URIs in the syntax if we did so - or we 
might be content with a simple OWL-style importing.  Or we might have 
a compromise.

Another use of explicit links between ontologies is to say 'this SCL 
ontology (the one you are reading, at <uri> this uri) supercedes 
<uri>that ontology) or maybe 'that part<uri> of that <uri> ontology', 
ie to maintain versioning. A related kind of assertion is that this 
relation name/axiom/whatever replaces that<uriref> relation name in 
that<uri> ontology, which is here considered to be deprecated. 
Another is saying that this<uriref> relation name is explicitly 
intended to be read in the context of that <uri>ontology. And so on. 
In other words, there are lots of plausible ways that URis will be 
used in particularly webbish ways to link SCL ontologies, if SCL ever 
gets used as a Web logic in its own right. Having an XML syntax which 
is extendable in these kinds of ways would be very worthwhile, since 
the abstract syntax does not refer to this kind of world at all. 
Extending the SCL abstract syntax language itself is less interesting.

Any thoughts? THIS QUESTION ADDRESSED TO EVERYONE, BTW :-)

>>>And that's not a bad thing, even if you're not interested in it.
>>
>>I am primarily interested, here, in getting this project done. If 
>>aligning it with yours will slow it down or distract it from its 
>>goals, that *is* a bad thing, I'm afraid. But let us not prejudge 
>>the issue, by all means.
>
>If by "this project" you mean SCL, then I'm only an encumbrance. If by
>an XML expression of SCL, that's what I've been proposing.

Well,  apparently you have in  mind some kind of extension of SCL 
rather than SCL itself, which would be fine as long as the 
requirements of this extension weren't distorting the SCL effort 
itself. What worries me is that they seem to be doing just that.

>I'm increasingly thinking I'm in the wrong room.

It would be nice to have you on board, but we need to keep the SCL 
project focussed if we are going to get it done in a reasonable 
timescale.

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