[SCL] minutes of telecon 8 April 03

[pat hayes]

>Hi, Pat.
>
>I hope you are doing very well!
>
>I saw your comments on a recent SCL meeting
>through the SUO mailing list; I was wondering
>if/how I could be added directly to the SCL
>mailing list.

It is an open list: subscription instructions are in the header.

Welcome!

I hope you will not mind if I CC this reply to the list.

>As you may know, during my years at Cycorp I made
>substantial contributions to the design and support
>of CycL, and I authored the Cyc canonicalizer, and
>I remain keenly interested in many of the language
>design issues you and the SCL group are considering.
>
>I share your support for variable-arity relations
>and for function symbols; I'm not sure what you mean
>by "full terms" (do you mean sentences as terms?).

As opposed to some syntactically restricted form such as names and  variables.

>I'm very happy that you are permitting quantification
>over "relations" while remaining within FOL,

Right, although this has proved to be an extraordinarily 
controversial decision and is being actively opposed by many people 
in the W3C Working groups, for example.

>and that
>equality is included.  I considered arity a property
>of a relation that could be context-specific

Right, that is my favorite way to handle it, but those who are unable 
or unwilling to consider properties of relations will not find that 
an easy row to hoe.

>and as
>such arity constriants should be handled as a semantic
>constraint rather than as a syntactic constraint (except
>for those few relations, e.g., logical operators, that
>are themselves defined as part of the language grammar
>itself).  Users need to be able to assert arities for
>relations (e.g., that they create), as with other
>properties (domain, range, expansions, etc.) that may
>be very useful as semantic constraints.

I agree that is the most flexible and obvious approach.

>
>I'm not sure I appreciate the desire for supporting
>(e.g., typing of terms within) special-name domains
>as part of the syntax; why not let this be a semantic
>property of such terms?

This was motivated by my experience with RDF and OWL. These languages 
depend crucially on being smoothly interfaced to XML datatypes, and 
also on having a built-in provision for expressing strings and 
numerals. These have to conform to conditions (both syntactic and 
semantic) which are imposed by external standards and are checked by 
software written to conform to those standards, so even if it were 
practical to axiomatize these namespaces in a FO ontology (and of 
course it is not) it is better to simply refer to the external 
standards in order to achieve interoperability.

>  It's possible that some uses
>might not have any need for strings or for numbers;
>why complicate CL with this?

I agree, and that is why I would like these special-name domains to 
be an optional feature, ideally a kind of meta-feature which allows 
particular extensions to be incorporated in the same general way as 
the need arises. But even a small built-in list of options would be 
better than nothing.

>
>Do you worry about such things as function-denoting
>functions,

no worries

>predicate-denoting functions,

no worries; both of those can be handled smoothly by the model theory.

>logical-operator-
>denoting functions,

Ah, I would worry about those if anyone was to suggest having them :-)

>sentence-denoting functions,

again, that would be part of a richer language than SCL is proposed 
to be, one that had a fully-fledged metalanguage extension, probably 
one based on an extended form of quasi-quotation or reification. We 
have decided that is too advanced/controversial for this first round. 
We may return to this later.

>and
>variable-denoting functions?

I am not sure what those would be, to be honest; but we have no plans 
to incorporate them at present.

Pat
-- 
---------------------------------------------------------------------
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 ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam at ai.uwf.edu   for spam