[SCL] Approach to a concrete syntax

[Murray Altheim]

sowa wrote:
> Murray,
> 
> I realize that you have been trained to ask penetrating questions
> about what a notation really means before writing a grammar for it.
> For some languages, that is fine thing to do.  But for SCL, that
> thinking has already been done in great depth.
> 
> It is good to think about the semantics when you're learning SCL,
> but it is a mistake to try to rethink it before writing an
> XML-based grammar for it.

I may have perhaps been asking those questions as much for my own
understanding as anything else. I've actually tried *not* to design
something different than what you guys have, and consider most of
my proposal(s) to be more at an XML level as features, such as
linking and web-enabling, not as grammatical changes. Though the
boundaries between what is and what was etc. are hamplered to some
degree by my ignorance of the field. Hopefully that is changing.

And now that I see Chris' latest SCL incarnation, I'd go back and
rewrite much of XCL. So in essence, I agree with you. I just had a
bit of a learning curve to go through in the past few weeks...

[...]
> As Pat said,
> 
>  > We have done that thinking and do not want to take it
>  > apart and re-do it at this stage.
> 
> The best way to define an XML-based syntax for SCL is to approach it
> in a brute-force way:  Don't think about what it means.  Just write
> grammar rules that express the categories of the abstract syntax
> in angle-bracket notation.
> 
> Bottom line:  Don't conceptualize.  Don't think.  Don't ask what
> it means.  Just write grammar rules.

As I mentioned above, in reading over Chris' latest draft, I'd not
approach XCL now in the same way. But what I would still advocate is
not hardwiring the quantifiers, connectives, and predicates as fixed
element types. First, it creates more element types than is really
necessary (complicating the language), but it also locks the language
into that fixed set, which is unnecessary (and then when people want
to extend the language you have two types of "verbs", those hardwired
as elements in the core syntax and those somehow defined by others).

So what I'd advocate now is to have the three types as distinct
elements:

    <quantifier />
    <connective />
    <predicate />

and then have a typing subelement that provides its meaning, as in

    <quantifier>
      <type>forall</type>
    </quantifier>

and then in some web-enabled version of the language (if that's not
already a feature in version 1), we add a reference element to allow
people to link to PSIs for their own types:

    <quantifier>
      <typeRef xlink:href="http://purl.org/cyc/1.0/constants/#thereExistsAtMost"/>
    </quantifier>

In the XML notation, you could have either a <type> or a <typeRef> as the
first child element of <quantifier>, <connective>, or <predicate>.

In a nutshell, all I'd change in moving from abstract to concrete syntax
(now that I understand you all better -- and I do agree, John), is to
generalize the syntax as described above, opening it up so that extensions
don't need to rely on ugly things like XML namespaces and the creation of
new elements and attributes, where element and attribute *content* would
do. I'm trying to avoid:

    <scl:formula xmlns:scl="http://purl.org/cl/scl/1.0/"
           xmlns:cyc="http://www.cyc.com/cycdoc/vocab/">
      <scl:forall>
        <scl:var>x</scl:var>
      </scl:forall>
      <scl:formula>
        <cyc:thereExistsAtMost>
          <scl:var>x</scl:var>
          ...
        </cyc:thereExistsAtMost>
      </scl:formula>
    </scl:formula>

when it's *really* not necessary:

    <formula xmlns="http://purl.org/cl/scl/1.0/">
      <quantifier>
        <type>forall</type>
        <var>x</var>
      </quantifier>
      <formula>
        <quantifier>
          <typeRef xlink:href="http://purl.org/cyc/1.0/#thereExistAtMost"/>
          <var>x</var>
          ...
        </quantifier>
      </formula>
    </formula>

I suppose it's basically the difference between using XML Namespaces and
PSIs, i.e., avoiding having people create their own markup (as they
are required to do in RDF, as the first example illustrates), or use PSIs,
which are document content. This way, all of SCL can be in one namespace,
and any new XML namespaces add features that aren't part of a new grammar,
but some other kind of feature (such as XHTML documentation). I think Pat
perhaps didn't understand me when I said this earlier.

I'm really just trying to keep it simple, but extensible. Not change the
grammar.

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