[SCL] Re: comments to scl new version improved slightly

[Jon Awbrey]

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

TT = Tanel Tammet

TT: I am not very happy with "skin", since it is normally used in UI talk,
    not language talk.  Everybody will understand it of course, just feels
    a bit out of place (although certainly survivable).

talk about core/periphery, interior/boundary, rational/empirical, regular/irregular,
has been fairly well established in traditional, transformational, and computational
linguistics for about as long as most folks can remember.  i used the topological
language interior/boundary for the rulebase/interface divide in programs that
i wrote 20 years ago, and the idea was already hackneyed then, but this usage
would probably fit best with the categorial paradigm of the info-flow-frame.

incidentally, the hot topic here is whether natural languages
are "fractal", that is to say, "almost everywhere boundary"?

ja

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

> Tanel Tammet wrote:
> 
> Hi,
> 
> pat hayes wrote:
> 
> > The document at
> >
> > http://www.ihmc.us/users/phayes/SCL_december_2.HTML
> >
> > has some bugs fixed and a diagram to help see the relationship
> > to the presentation in your document.
> >
> > Comments/feedback would be very welcome whenever you (or anyone) has them.
> >
> Some comments, suggestions and questions follow.
> 
> The general feeling I have about this: the basic stuff looks nice. IMHO some
> smaller changes etc would be good (since it is an early draft, it obviously needs
> work, and I be happy to help if I get some directions, more about that later).
> More modularisation in presentation would be IMHO good when we move
> closer to the final spec.
> 
> Some important issues are not covered in the spec yet and I am a bit worried about
> how to approach these. I know how I'd approach them, but as we have seen,
> this is not necessary the approach Pat or Chris would prefer.
> 
>  I' ll give the details in the following, starting with smaller
> suggestions and then moving to more substantial issues.
> 
> 1) Terminology.
> 
> I am not very happy with "skin", since it is normally used in UI talk,
> not language talk. Everybody will understand it of course, just feels
> a bit out of place (although certainly survivable).

talk about core/periphery, interior/boundary, rational/empirical, regular/irregular,
has been fairly well established in traditional, transformational, and computational
linguistics for about as long as most folks can remember.  i used the topological
language interior/boundary for the rulebase/interface divide in programs that
i wrote 20 years ago, and the idea was already hackneyed then, but this usage
would probably fit best with the categorial paradigm of the info-flow-frame.

incidentally, the hot topic here is whether natural languages
are "fractal", that is to say, "almost everywhere boundary"?

ja

> The "ontology" vs theory or module has been talked about on the list.
> I'd prefer theory, module being the second, and I do not particularly
> like "ontology". Ontologies are theories of a specific kind, whereas
> we are NOT assuming that only theories of a specific kind can be
> imported. "Ontology" is not recognised as a neutral piece of terminology.
> 
> 2) Syntax:
> 
> A) The examples are given mostly in "core syntax", with term/atom defined as
> <term> ::= <term>( <term>* <seqvar>? ) | <name> | <specialname>
> and examples like "married(Jack Jill)".
> 
> I suggest to change this core syntax by adopting the convention of using
> commas between terms in a sequence.  Then we'll have the ordinary prefix
> syntax as core syntax.  The current core syntax is an uncommon compromise
> between S-expression and prefix syntax.
> 
> Alternatively, if you do not like ordinary prefix syntax as core,
> let us rather use s-expressions like KIF then.
> 
> B)  Related to this, I could not really understand the syntax definition
> <term> ::= <term>( <term>* <seqvar>? ) | <name> | <specialname>
> since it DOES NOT specify any separators (comma, whitespace?).
> 
> C) Core syntax as presented avoids explicit "forall" and uses complex infix syntax a lot
> (=, iff) making it hard to parse. I'd suggest avoiding any infix syntax in core
> and using explicit quantifiers always: parsing will be much simpler. We can
> have more user-friendly syntaxes anyway, there is IMHO no need to put
> any nontrivial sugar into the core syntax.
> 
> 3) Comments and headers and topsentences etc.
> 
> There is no talk about how comments and metainfo should be given.
> Comments have to be put back into the core, preferrably into
> the kernel.
> 
> Although I understand the principal need for headers, the current talk about
> headers (unavoidably) stops too early.  There is no indication about what and
> how should be put there, and as such, one cannot use the headers.
> 
> I'd rather see the headers and comments merged into one.
> Comments should have no semantics for SCL (they should have
> semantics at the level outside the scope of SCL).  Since any
> headers can be written as comments, I think we should not
> separate them. Comments are IMHO enough.
> 
> If/where they are not enough, then I am afraid that headers will work neither.
> 
> As an example, consider http. The type of a body part of a http response
> (gif, jpg, html, txt, doc etc) is NOT given as part of the body.  It is
> given as content-type in the http headers, which is on a _different_ level
> than the http body itself. Similarly, any "headers" should IMHO be either
> given as comments or they should not be at the SCL syntax level at all.
> 
> As another example, you just cannot declare in XML text itself that now we
> are going to have something in arbitrary NON-XML: this non-xml might contain
> less-than etc symbols, breaking the XML syntax of the whole text.
> 
> I am also not sure we should use topsentence and allow imports at top level only.
> IMHO we could allow import in any place, not just top level.  This would make the
> kernel more flexible while syntax is actually simplified.
> 
> 4) Relations to TFOL
> 
> My pet issue has been the relation between SCL and traditional FOL.
> 
> The exact translation algorithms TFOL->SCL and SCL->TFOL have
> to be a part of the SCL spec.
> 
> Now, despite the seemingly obvious nature of these algorithms (holds app stuff etc)
> we have had remarkably different (and strong) views on how these translation
> algorithms should look like.
> 
> Until these translation algorithms are there, I am not at all confident
> that I understand this (or any other) SCL presentation as it is meant to
> be understood, and  I am not confident that no major blunders have crept in.
> 
> IMHO these translation algorithms are a first priority.
> 
> 5) Equality
> 
> The current presentation avoids equality issues.  Like relations
> to TFOL, these issues have been a major source of problems during
> the whole SCL process.
> 
> Again, until the equality issues have been covered in the spec, I am not at all
> sure that we understand the presentation as it is meant to be understood or that
> the presented semantics will work out without any crazy tricks.
> 
> The equality would be the second priority after the TFOL relations.
> 
> 6) What to do next
> 
> Pat: now that you have this nice draft, what are you planning
> to improve yourself and what could be left to other people?
> Chris: how is your workplan?
> 
> I'd be happy to help writing, but we need to fix some plan for this.
> The precondition of the plan, as noted before, is the common understanding
> of how this draft SCL relates to TFOL and how is the equality handled.
> 
> Regards,
> Tanel

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
http://www.cs.bsu.edu/homepages/mighty/history.html
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o