Comments to [[SCL] new version improved slightly]

[pat hayes]

>Hi,
>
>pat hayes wrote:
>
>>The document at
>>
>><http://www.ihmc.us/users/phayes/SCL_december_2.HTML>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

Quite.

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

Yes, others have commented on this. I know I tend to write in a 
streaming fashion rather than in modules; it is hard for me to change 
at this stage.

>
>Some important issues are not covered

Oh, MANY are not yet covered. I am still writing.

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

Yes, others have commented negatively on this. I thought it was 
amusing, but I was alone. I plan to change this to 'dialect' to keep 
the metaphor linguistic in nature.

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

See earlier message. It is so recognized (and indeed used) in all the 
communities I have dealings with. And now that the SW has become a 
hot topic among Webbies, this terminology is becoming used in venues 
all over the planet and in many communities, whether we like it or 
not. 10|5 XML enthusiasts can't be wrong....no, strike that, they can 
be *wrong*, but trying to correct their English is a losing 
proposition.

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

Indeed, Im not happy with it.

>
>Alternatively, if you do not like ordinary prefix syntax as core, 
>let us rather use
>s-expressions like KIF then.

Yes, I was trying to be too 'clever' here by inventing a more 
readable syntax. I think we should stick to KIF-style syntax for the 
core. I plan to rewrite this up today.

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

As noted, the syntax does not handle whitespace properly and needs fixing

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

I have come to agree. I was torn between keeping the core small (the 
kernel) and easy to work with formally (KIFfish) on the one hand, and 
having a 'readable' syntax to present examples in the text, on the 
other hand. I know that for many readers, the sight of too many 
nested parentheses is a strong turn-off for readability.

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

I have a suggestion, which is that they are not in the kernel  (since 
they have no semantics) but that any dialect may include material 
which does not parse to the kernel, and that is 'invisible' to SCL. 
THis allows any dialect to include comments and meta-info freely, 
using any non-SCL syntax. Do you think the core/kernel should provide 
an explicit comment syntax also?

>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 am writing that stuff now.

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

No: headers *do* play a semantic role. That is the reason for the distinction.

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

I cannot make semantic sense of

(not (import <ontology:foo>) )

If you can, I would be grateful for an explanation. (Also inside 
disjunctions, for example.)

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

Im working on it. It will be there. See below for sketch.

>
>5) Equality
>
>The current presentation avoids equality issues.

It defines equality: what issues did you have in mind (apart from 
those that arise in your previous point)? Semantically and 
syntactically, equality gives rise to no problems.  Computationally 
it is very tricky, I know.

>  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

It is not COMPLETE yet. I am working on it. I'll let y'all know when 
it is finished.

>, what are you planning to improve
>yourself and what could be left to other people?

I was planning to try to finish it in outline, with some parts rather 
sketchy, and ask for volunteers to fill out the text in various 
palces. And suggest changes/improvements, etc. , of course: though we 
need to try to keep internal consistency of terminology.

The document itself needs all kinds of work, including most notably 
internal HTML links from terms to their definitions. I will do that 
stuff after getting the writing done.

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

I'll try to get a sketch of this done in the next few days. It will 
be based on these observations:

0. A GOFOL SCL ontology is one with a 'standard FO header' which 
asserts not(scl:Ind(x) & scl:Rel(x)) and assigns the appropriate 
category to every name in the lexicon.

1. It is always possible to merge a header into the body and have a 
blank header, but the universe is enlarged; so to retain the old body 
quantifiers, one needs to restrict all quantifiers to a class called 
'ind' (not scl:ind) which represents what scl:Ind meant in the 
previous ontology.

2. scl:Ind used in a body can be rendered as scl:Ind(x) iff (x=x), ie 
using equality.

3. For a headerless ontology, the hold/app translation for the logic 
without equality is kind of obvious

4. Putting these observations together, with a bit of care, the 
quantifier restrictions for the holds/app translation (which is a 
very particular kind of translation, obeying a very regular pattern) 
can be captured exactly by (a) mapping equality to equality' (*not* 
using holds/app) where (b) equality' is equality but restricted to 
apply only to things not in the first position (since the others 
would fail the quantifier restriction - which can now be rendered as 
(x =' x) - and for these it would be the trivial restriction x=x.)

This can all be stated by adapting the 'position' terminology to the 
holds/app translation: the things in the first position after the 
holds or app are those that map from relation/function position in 
the original ontology, so the original fitting requirements (which 
were pretty trivial for GOFOL, but still were there as lexical 
restrictions) translate into conditions on those new positions.

Im sure you grok this, since I learnt it from you, though the 
terminology may be different. If you feel like writing it up, that 
would be great.

>
>Regards,
>                Tanel
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>SCL mailing list
>SCL at philebus.tamu.edu
>http://philebus.tamu.edu/mailman/listinfo/scl


-- 
---------------------------------------------------------------------
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 ihmc.us       http://www.ihmc.us/users/phayes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20031221/5942e96b/attachment-0001.htm