Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SUO KIF



Chris,
  Comments below:

At 07:02 PM 7/26/2000 -0500, Chris Menzel wrote:
[snip]

> >Doable, but messy; not to mention unlovely.  But ALL of this
> >unbecoming mess can be avoided simply by imposing a bit more order on
> >KIF's laissez faire syntax; in particular, simply by introducing
> >strict, disjoint classes of constants, function symbols, and
> >predicates.
> >
> >Now, the perception might be that this imposes too much order on KIF;
> >it legislates ahead of time which strings of characters are to fall in
> >what categories.  But this brings us to another problem with KIF's
> >current definition.  Currently (I mentioned this once before) there is
> >only the one KIF language.
>
> Actually chapter 12 does specify levels of compliance which seem to allow
> users to employ only some of KIF.

I don't think that quite does it.  The definitions given in that chapter
in question just seem to quaalify *sets* of KIF sentences.  Formally
speaking, one is still working with the entire language, and only paying
attention to parts of it.  I find this messy and imprecise, and
potentially troublesome, e.g., for the design and implementation of
translators.

ok, if the wording could be made more precise I think that would be a good idea.

> >In sum, then, my suggestion is that, once one has defined KIF
> >characters and lexemes in sections 4.2 and 4.3, we define in section
> >4.4 the notion of a KIF *language*, of which there will be
> >uncountably many.  (Proof left to reader :-) Such a language will
> >have denumerably many variables, a countable number (hence, possibly
> >zero) of *individual constants*, a countable number of *predicates*,
> >and a countable number of *function symbols*, where these items would
> >constitute pairwise disjoint sets of character sequences.  I would be
> >happy to work out the details if this suggestion is accepted.
>
> Just to make sure I understand, it seems to me you are offering to
> specify a more correct or more tightly defined semantics for the
> elements of the language specified in section 4.4. 

Actually, I'm offering to specify and tighter *syntax* in section 4.4.
Most of what is there will remain, but it will be in the context of
specifying the notion of a *particular* KIF language, one whose set of
lexemes would be a subset of all possible KIF lexemes, and where these
lexemes would be divided into variables, constants, function symbols,
and predicates.

> Maybe that becomes
> a new section 4.5 and we delete the last paragraph of the current
> section 4.3?

Not quite sure of the structure, but that last paragraph of 4.3 should
definitely be clobbered (assuming my suggestion about dividing lexemes
into disjoint syntactic categories is accepted) and Section 5 tightened
up accordingly.

> If that's what you're suggesting, I think it's a great idea.

Do you feel the same about my clarification of what I'm proposing?

yes

 
> I'm a little hesitant to put numbers, characters and strings outside
> the basic document. 

Well, if modules on basic number theory and some basic self-referential
stuff get written up in a hurry, they could be part of the basic
document.  But I really think that there should be a simple core that is
nothing more than FOL, as that is all a lot of folks are going to want.
If you add the modules in question, it is only an issue of architecture.
If you want numbers, characters, or strings you've got them.

ok

> They seem so fundamental, from the ability to use integers to specify
> an argument position in "nth-domain" to being able to associate a
> comment string with a term.  I know there are some theoretical issues
> associated with how the semantics of numbers affect the computational
> power required to interpret a logical language but I'm wondering how
> much that issue shows up in practice.

Maybe not in certain aspects of practice, but surely in others.  For a
number of salient application envisioned for an SUO (e.g., translators
once again) it will be essential that the source and target languages be
clearly circumscribed.  If numbers or strings or lists are not being
used in either or both, it will be both a waste of time and a potential
source of trouble to have to think about translating types of sentences
that are never used.  It is therefore important to know when these
elements are not being used.

Moreover, just enough number theory to get the nth-domain apparatus and
some basic string stuff would add very little in the way of complexity.
It would be nice to be able to have a little module with just that
little bit of added power without having to bring a full-blown number
theory and heavy self-referential machinery into the language.  Same
with lists.

One difficulty for me personally is that I don't have enough background in number theory to propose a module for this, so I hope someone else can suggest a version of this soon.

> >  Chapter 12 should be chapter 8.
>
> well, I wanted to keep the chapter and section numbering the same to
> show correspondence with the earlier versions of KIF.  Once we have
> agreement on content and that reference is no longer useful we should
> certainly renumber.

Good idea.
 
> >The structural ontology of Appendix B does not fit the suggested KIF
> >core, as it involves notions of subclass and instance -- but there
> >are no classes in the current core.  This would have to be part of an
> >extension -- one that should probably be worked up ASAP.
>
> ok, whether we call it an appendix or an extension doesn't really
> matter to me.  I'd need to rely on folks like you, John Sowa, and
> other folks with a deeper theoretical knowledge of logic than I in
> order to add more detail to this section.
>
> Thanks again for the many helpful comments.  I hope this will nudge
> other folks to contribute so we can arrive at a consensus on language
> quickly and move on to ontological content.

Yes, I hope.  I'm just shooting my mouth off here.  I hope my
suggestions are reasonable, but I sure wouldn't want anyone to think
that I'm trying to hijack the project.  However, that might be the
practical effect if no one else chimes in.  I'm interested in getting
this right, not in having my way.  Though, of course, I do like to have
my way!  :-)

All your suggestions sound reasonable to me.  I guess part of any group effort is to make sure everybody gets a little of their way :-)

Adam


-chris

--

Christopher Menzel               # web: philebus.tamu.edu/~cmenzel
Philosophy, Texas A&M University # net:      chris.menzel@tamu.edu
College Station, TX  77843-4237  # vox:             (979) 845-8764

-----------------
Adam Pease
Teknowledge
(650) 424-0500 x571