Comments to [[SCL] new version improved slightly]

[Tanel Tammet]

pat hayes wrote:

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

Yes. The comments and metainformation (for SCL they are the same!) are 
extremely important. Better
not push them to some obscure corner.

For example: the reason why you introduced ontology and header special 
names was IMHO that
you forgot the comments: if you had had them in the core or kernel, 
the'yd have sticked out as
a suitable machinery to use instead of inventing new names for 
special-purpose metainformation.

I know you claim otherwise, but I am not so sure yet that these 
mysterious headers are a necessity.

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

Waiting with interest.

>>
>> 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.
>
Perhaps, we'll see.

>> 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.)
>
Sure there is the ordinary, trivial procedural meaning: replace the 
(import ....) substring with the contents
of a file with this URL. This is a simple macro operation.

Observe that:

- there is no semantics of (import ...) in SCL: it is a different 
language level, as macros always are

- it is completely up to the person who wrote the (import ...) to 
guarantee that the content and syntax
  in the included file will suit the context.

- in case you restrict (import ....) to top level only, nothing will get 
cleaner or get more semantics:
   it is still a macro operation without SCL semantics.

Hence, in case we prefer to put (import ....) into SCL, then I'd be all 
for removing any restrictions:
let it occur wherever the writer wants to write it.

Of course, I prefer NOT putting (import ...) into core SCL at all. This 
kind of thing should be
implemented on a different level. For example, should we put XML 
namespaces into SCL?
No? If not, then let us avoid putting XLINK into SCL, for similar reasons!

>>
>> 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.
>
I had in mind the problems we get from equality in connection to 
TFOL<->SCL translations.

> 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.
>
No, I do not grok this yet.

What you wrote here seems to be strongly related to these headers you 
are planning to describe
in the near future.

Since you have not described them yet, I have no idea why they are there 
or what exactly they do,
and hence I cannot really understand what you mean  by the paragraph above.

Naturally, I am rather sceptical about the whole idea of suddenly 
bringing in the header concept
nobody has discussed or heard of before. Sounds like either complicating 
things up or acting
as a special kludge. But, as said: any sensible discussion of the header 
concept will just have to
wait until you write a description.

Tanel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20031222/dfdbdeaa/attachment-0001.htm