[SCL] Approach to a concrete syntax

[Murray Altheim]

pat hayes wrote:
>> I've put an SCL spec on the web: http://cl.tamu.edu/docs/scl.html .
>> It is not highly polished, but it will do as a start to get ideas fixed.
>>
>> Features (all negotiable):
>>
>> * No distinction between predicates and individual constants.
> 
> For the record, I would prefer that we do make such a distinction in the 
> abstract syntax, with appropriate (and conventional) assignments to the 
> various parts of the term and atom syntax, and conventional semantic 
> requirements expressed using extension mappings (ie function symbols 
> have functional extensions, relation symbols have relational 
> extensions);  but not require that these categories are disjoint in any 
> concrete syntax. This keeps the exposition maximally conventional-seeming.
[...]

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

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. For interchange, each has an associated PSI, since
"exists" and "forall" are names within the XCL namespace. It would
be poor practice to mix datatypes 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, 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?

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

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.

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.

As I was saying though, limiting its content (either as elements or
attributes, doesn't matter) is difficult, and if we do need to limit
the content based upon what kind of predicate it is (e.g., if it's
a quantifier vs. a logical connective vs. a general predicate vs.
a general quantifier, etc.) that's difficult or impossible, depending
on schema language (e.g., DTDs couldn't do it). But in consideration
of what was expressed in the telecon, that the syntax itself should
not be the limiting factor, that we don't want to overly constrain
usage via syntax, maybe having one vs. four is a better approach. It's
what I had a few months ago when I was even more naive (partly because
my prototype implementations in GXL or XTM only have one relation
element anyway, <edge> and <association>, resp., noting that a lot
of existing markup or graph languages only have one predicate type).

Anyway, I've been thinking about this and maybe this will advance
the discussion. Dunno. [and if I'm getting the language entirely
wrong, sorry -- please be gentle in correcting me -- it's been a
rough week on my ego. :-) ]

Murray

PS. it occurs to me I left GXL off the reference list I posted
earlier:

    Graph Exchange Language (GXL)
    http://www.gupro.de/GXL/

though currently, der Server konnte das angeforderte Dokument
nicht liefern. I'll send a message off asking why.
......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

    Boundless wind and moon - the eye within eyes,
    Inexhaustible heaven and earth - the light beyond light,
    The willow dark, the flower bright - ten thousand houses,
    Knock at any door - there's one who will respond.
                                     -- The Blue Cliff Record