[SCL] Approach to a concrete syntax
pat hayes
phayes at ai.uwf.edu
Mon May 19 13:46:02 CDT 2003
>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.
? 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.)
>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.
>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).
>For interchange, each has an associated PSI, since
>"exists" and "forall" are names within the XCL namespace.
What sense of 'namespace' is this?
> It would
>be poor practice to mix datatypes
??When did datatypes come into the discussion??
>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?
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
<forall> <boundvar>?x</boundvar>
<body><atom><rel>P</rel><termseq>?x</termseq></atom></body></forall>
>
>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.
>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.
>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.
>
>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.
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
More information about the Scl
mailing list