[SCL] Approach to a concrete syntax
Murray Altheim
m.altheim at open.ac.uk
Wed May 14 08:55:02 CDT 2003
[sorry -- the previous message had a syntax error that would make it
difficult to understand my point, that of elements or attributes like
<variable> being declared only on "predicates" like <quantifier>,
not on all predicates.]
Murray Altheim wrote:
> 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>
[begin fix]
> 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>
or
> <quantifier variable="X">
> <name>
> forall
> </name>
> <type>
> trailer_truck
> </type>
> </quantifier>
(removed the erroneous <variable> element from the second example)
[end fix]
> 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
>
> _______________________________________________
> SCL mailing list
> SCL at philebus.tamu.edu
> http://philebus.tamu.edu/mailman/listinfo/scl
>
--
Murray
......................................................................
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
More information about the Scl
mailing list