[SCL] Approach to a concrete syntax

[Murray Altheim]

[I'm sending two messages to the list because I wrote them yesterday
and my wonderful SMTP server wouldn't accept them. I realize today
that John has replied to one of my earlier messages, and will follow
up on that in a separate message dated today, 20 May. This is 2 of 2.]

pat hayes wrote:
  >> Murray Altheim wrote:
  >> In the concrete syntax of XCL right now there are three separate
  >> elements
  >>
  >>   <quantifier />
  >>   <connective />
  >>   <predicate />
  >>
  >> that do to some extent the same thing, which is to take each other
  >> and <term> elements as content.
  >
  > ? Quantifiers require a bound variable (or list of them), connectives
  > apply to sentences, and predicates apply to terms (but in a semantically
  > distinct way, which needs therefore to be syntactically marked in some
  > way.)

Understood. So we probably need distinct element types to enforce
what we declare as content.

  >> Each is typed by a 'name' attribute,
  >> which should perhaps be a 'type' attribute (I used to call it this).
  >> A good reason to not call it 'type' is that this might be confused
  >> with the typing of the variable (where I'm talking here about the
  >> typing of the quantifier, e.g., "forall" vs. "exists").
  >
  > I am finding this very hard to follow, I confess. Familiar words seem to
  > be morphing new meanings in every sentence.

Pat, remember that not everyone uses language the same way as you do. I'm
new to the field, and still learning. What are the meanings of "familiar"
words to you do not necessarily have the same meanings as they do to me.
They're not morphing, we're just learning to communicate with each other,
i.e., I'm trying to learn your meanings. This is part of communication, eh?

  >> So we have things like:
  >>
  >>   <quantifier name="forall" />
  >>   <connective name="implies" />
  >>   <predicate name="equals" />
  >>
  >> The set of known types for these are called "reserved words", i.e,
  >> if somebody sees one of them in an XCL document we all know what
  >> they mean.
  >
  > BUt what about all the predicates (relations would be better) which are
  > not reserved? Equals is a rare exception (there will only be a few of
  > these in SCL).

That's the purpose of having the PSIs. By defining a language that has
"plug-in slots" for concepts, we define "reserved words" or PSIs for
those we consider canonical parts of SCL, and allow other people to
create their own. So if you want meet(i,j), you create a PSI 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). Then use it as:

      <predicate>
         <type xlink:href="http://pathayes.org/psi/myPredicates.html#meet"/>
         ...
      </predicate>

  >> For interchange, each has an associated PSI, since
  >> "exists" and "forall" are names within the XCL namespace.
  >
  > What sense of 'namespace' is this?

Not the XML Namespace (which I'll endeavour to always capitalize), but
the set of names used in the XCL markup language, i.e., the specific
elements and attributes, plus any reserved words or PSIs (they are
semantically identical in XCL, the former shorthands for the latter,
for ease of use. In RDF there are no shorthands; you always use the
full URLs).

  >>  It would
  >> be poor practice to mix datatypes
  >
  > ??When did datatypes come into the discussion??

When we began talking about XML markup. 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. That's all I meant, just that if you use
XML attributes to contain things, they should only contain one kind of
thing, one kind of datatype. Requiring processors to figure out what
kind of thing is in an attribute is very poor practice.

  >> within an attribute value, so
  >> we express URIs (of which PSIs are a specialization) as links,
  >> whether the links are traversed or not is not important. Since we
  >> can't stuff character data *or* URIs in an attribute value without
  >> mixing datatypes
  >
  > ??

You're having as much difficulty understanding me as I you. We'll work
it out.

What I meant was basically explained in my last comment above. Basically,
we're using PSIs (a specialization of URLs) as identifiers. We don't need
to traverse the implied link of the URL to be able to understand its
meaning -- if we see an XLink whose URI reference is
"http://purl.org/xcl/1.0/#exists" we can understand its meaning.

  >> , it's better to pull the 'name' attribute off into
  >> an element whose content is either PCDATA (character data) or a
  >> link element, so these two expressions mean the same thing:
  >>
  >>   <quantifier>
  >>     <name>forall</name>
  >>   </quantifier>
  >>
  >>   <quantifier>
  >>     <name>
  >>       <predRef xlink:href="http://purl.org/xcl/1.0/#forall" />
  >>     </name>
  >>   </quantifier>
  >>
  >> But we immediately see a bit of a problem. Should the <name>
  >> element contain a <predRef> or what? What is the appropriate
  >> name for that linking element? Is it a link to a predicate?
  >
  >
  > What the h**l are you talking about? Look, there are two quantifiers.
  > There is in fact no particular need to even have the notion of
  > 'quantifier' in the syntax: there are two syntactic categories which
  > happen to be remarkably similar in their structure, viz. 'forall' and
  > 'exists'. Why do you need to get into this complexity of naming a
  > quantifier? I would be quite happy to have
  > (forall (?x)(P ?x))
  > rendered into XML as something like

[I've rewritten the whitespace so I can see it better.]

     <forall>
       <boundvar>?x</boundvar>
         <body>
           <atom>
             <rel>P</rel>
               <termseq>?x</termseq>
           </atom>
         </body>
      </forall>

That's fine, and you might be happy, but what about those people
who want more than two quantifiers? There are more than two, right?
There's #$thereExistsAtMost and perhaps dozens of others. So what
I'm proposing is not hardwiring the quantifier type as an element
name, and having it specified either as a "reserved name" or a PSI.
The idea of using "reserved names" is not some XML thing, it's just
an idea of a shorthand for SCL since I'm guessing you all would
rather not be typing long URLs all the time, and there are a small
set of initial types.

So, these two examples would be identical semantically. You probably
don't need the "?" in front of the x in <boundvar> since it can be
implied in the context. I prefer your use of an element for bound
variables since using attributes requires you define a fixed set
of them, whereas you can always just add another <boundvar> element
if you're using elements. The specifid PSIs and element names below
aren't anything I'm married to, just using for the examples:

     <quantifier>
       <type>forall</type>
       <boundvar>x</boundvar>
         <body>
           <atom>
             <rel>P</rel>
               <termseq>?x</termseq>
           </atom>
         </body>
     </quantifier>

     <quantifier>
       <typeRef xlink:href="http://purl.org/cl/scl/1.0/#forall"/>
       <boundvar>x</boundvar>
         <body>
           <atom>
             <rel>P</rel>
               <termseq>?x</termseq>
           </atom>
         </body>
     </quantifier>

My idea in XCL was to have no external links in Level 1 (as in
the first example), and enable external links in Level 2 (as in
the second example). And then associate the reserved word "forall"
with the PSI "href="http://purl.org/cl/scl/1.0/#forall" so that
Level 1 and 2 have the same interpretation.

Now, I realize we're not talking Level 1 and 2 here, but the idea
can be the same. I think SCL should enable external links so that
people can define their own quantifiers, connectives and predicates
by defining their own PSI sets. This would enable the entire world
of other logics to be built upon SCL by use of PSI sets, which all
would come *later*. We'd just define the initial set for SCL v1.0.

BTW, why do we need <body>? Couldn't it be safely eliminated? We
can enforce element order in XML, so <atom> elements always must come
after <boundvar>, etc.

  >> This was one of those little things digging around in my head.
  >> What occurred to me following some thinking and some private
  >> emails on the subject is that the <quantifier>, <connective>,
  >> and <predicate> elements gain nothing (or at least very little)
  >> by being differentiated as distinct element types, and that
  >> we are prejudicing a specific set in some ways by doing so.
  >
  > I disagree. These are the primary distinctions in the logical syntax,
  > and they are motivated by essentially semantic distinctions.

Fine. Just an idea.

  >> That if generalized quantifiers are expected to be permitted
  >> in a concrete syntax, perhaps it's better to simply have one
  >> element that, as the previous example has, its typed by its
  >> name. An XCL processor would certainly interpret these two
  >> as identical semantically, as both statements of the universal
  >> quantifier:
  >>
  >>   <quantifier>
  >>     <name>
  >>       <predRef xlink:href="http://purl.org/xcl/1.0/#forall" />
  >>     </name>
  >>   </quantifier>
  >>
  >>   <predicate>
  >>     <name>
  >>       <predRef xlink:href="http://purl.org/xcl/1.0/#forall" />
  >>     </name>
  >>   </predicate>
  >
  > ?? The latter just seems wrong to me. A quantifier is not a predicate:
  > that is a category error and also violates the SCL abstract syntax.
  > (forall ?x) is not a well-formed SCL atom.

Like I said, it was just an idea. I thought a quantifier could be
considered as a predicate on a predicate (or a proposition on a
proposition, I don't quite understand the distinction in this context
yet). But if I'm wrong, I bow to your expertise. I'm not a logician.

  >> One upside is that now everything can be a link to somewhere
  >> else, so authors can reuse concepts from existing ontologies
  >> (ignore link types for now):
  >>
  >>   <quantifier>
  >>     <name>
  >>       <predRef xlink:href="http://purl.org/xcl/1.0/#forall" />
  >>     </name>
  >>     <variable>
  >>       X
  >>     </variable>
  >>     <type>
  >>       <predRef xlink:href="http://purl.org/opencyc/1.0/#TrailerTruck" />
  >>     </type>
  >>   </quantifier>
  >>
  >> The one downside of this is that in the current syntax we can
  >> declare only the <quantifier> element to having a variable and
  >> a type (variable type, not quantifier type) as in:
  >>
  >>   <quantifier>
  >>     <name>
  >>       forall
  >>     </name>
  >>     <variable>
  >>       X
  >>     </variable>
  >>     <type>
  >>       trailer_truck
  >>     </type>
  >>   </quantifier>
  >>
  >>   <quantifier variable="X">
  >>     <name>
  >>       forall
  >>     </name>
  >>     <variable>
  >>       X
  >>     </variable>
  >>     <type>
  >>       trailer_truck
  >>     </type>
  >>   </quantifier>
  >>
  >> which would read as  (forall (x? trailer_truck)). Now, I certainly
  >> don't claim any expertise in logic, but as was told me recently,
  >> quantifiers are propositions about propositions, so perhaps there's
  >> a good way to re-use that one <predicate> element within itself in
  >> order to do this.
  >
  > I would be happier with an XML syntax which followed, rather than
  > re-defined or re-conceptualized, the SCL abstract syntax. The primary
  > purpose of concrete syntaxes is to adequately express the categories and
  > relationships which the spec attaches, in terms of a model theory, to
  > the abstract syntax. The general form of the syntax is a fairly
  > well-developed logical flower at this stage, both in the generalizations
  > it makes and the ones it does not make. It would be possible to
  > conceptualize a quantifier as a kind of predication on a set, for
  > example, with an expression as a parameter; or as a functional operator,
  > or in many other ways; but each of these would require re-thinking the
  > entire SCL semantic apparatus in a new and alien way. We have done that
  > thinking and do not want to take it apart and re-do it at this stage.

Okay, I'm fine with that. The only alteration to the syntax that Chris
has proposed that I'd make would be to generalize the quantifiers,
connectives, and predicates to take a typing parameter so that rather
than hardwire their names/types (?), we'd use PSIs and perhaps "reserved
words" that act as shorthands for the PSIs (this latter is still an
experimental concept, but would not be hard to implement for developers;
we could at some later time even develop a syntax for declaring one's
own shorthands, but that's not necessary really).

  >> This gets back to that idea I expressed in the telecon about there
  >> being simply one fundamental graph relation, which I think Pat, you
  >> corrected me in saying it was an n-tuple relation. In either case
  >> I think the current XCL syntax is probably overcomplicated in having
  >> too many elements for predicates, that there needs be only one.
  >
  > It is important that the syntax clearly identify symbols used in
  > relation position from those used in function positions. It also should
  > allow the same symbol to be used in both kinds of position. It also
  > should allow an arbitrary term to occur in either position. All of this
  > is part of the abstract syntax.

I *think* the XCL syntax I've proposed allows this. If not, I need to
understand this paragraph better. What would be the difference between
"relation position" to "function position"? (an example would be
appreciated).

Murray

...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

     Jessica Lynch became an icon of the war, and the story of her capture by
     the Iraqis and her rescue by US special forces will go down as one of the
     most stunning pieces of news management yet conceived. It provides a
     remarkable insight into the real influence of Hollywood producers on the
     Pentagon's media managers, and has produced a template from which America
     hopes to present its future wars.  -- The Guardian, 15 May 2003
     http://www.guardian.co.uk/g2/story/0,3604,956127,00.html