KIF: new version of KIF-Core

[Uschold, Michael F]

Regarding what to call the core KIF and what should be in it. First, one must decide what criteria exist which determine what goes in and what stays out. If the criterion is whether the notion is first order or not, then calling it FOKIF is a good idea. If there are other reasons, but which happen for the most part (by chance) to be mostly first order things in the core, but there are exceptions - then I recommend against using FOKIF as a name, since it will surely be misleading. The name should directly reflect the criteria for inclusion.

Personally, I do not have a problem with 'core' - it does not denote better, to me, rather it denotes more central, more key, more likely to be used by everyone, things like that. If anything, what goes in the core are the less interesting things, but the basic ones.

Mike


******************************************************************************
NB:  If you send email to me 
          1. from outside the Boeing Company or 
          2. from inside the Boeing Company, but not using Exchange 
       Then, as of JULY 2001 you must use the following email
       address:  michael.f.uschold at boeing.com. Other addresses,
       such as   mfu at redwood.rt.cs.boeing.com or 
                      michael.f.uschold at PSS.boeing.com won't work.
       Please update your email address books accordingly.
******************************************************************************

 -----Original Message-----
From: 	owner-kif at philebus.tamu.edu [mailto:owner-kif at philebus.tamu.edu]  On Behalf Of pat hayes
Sent:	Wednesday, June 27, 2001 3:18 PM
To:	kif at philebus.tamu.edu
Subject:	Re: KIF: new version of KIF-Core

>"Christopher A. Welty" wrote:
>
> > At 12:27 PM -0700 6/27/01, Adam Pease wrote:
> > >>  > 9.  Section 5.5 needs more elaboration.  I think it would be best to
> > >>>  discard it.
> > >>
> > >>What elaboration would you like to see?
> > >
> > >well, I wouldn't, I'd rather see it removed since I thought we were
> > >going to have a separate extension to deal with
> > >modules/context/microtheories.
> >
> > I agree with Adam here.  Again, this is not an objection to the
> > notion that modules are important, of course they are, and of course
> > it woudl be a necessary thing to add.
> >
> > Adding support for modules to the core adds a WHOLE LOT of machinery
> > to any KIF-core compliant engine.  I would like to imagine it
> > possible to have a very lightweight KIF interpreter, supporting only
> > the core, that you could send small theories to and not worry about
> > the overhead of things like modules, sorts, etc.
> >
> > Now that we've got our non-onion (I forgot Chris' new word) approach,
> > I see no problem at all defining very simple extensions to KIF, such
> > as modules.
> >
>
>I'm rather sympathetic to these ideas, and I'm beginning to dislike the
>word "core", since it seems to have too many value connotations
>("anything in the core is superior to anything outside the core").
>Having a multi-part standard does not mean that Part 1 is more
>important than Parts 3 or 4 or 5. A part is simply a grouping of
>concepts for the purpose of presentation or some underlying functionality.
>
>I think that what we have been calling KIF-Core should
>really be called First-Order KIF.

FOISOKIF, pronounced 'foysohkif' , maybe? :-)

You know, strictly speaking the 'schema form' use of row variables is 
also first-order, so FOKIF ought to include slightly more than the 
current core/part1. One way to do this would be to put row variables 
in the language (but restricted to the last position of any term or 
atom) but not allow them to be bound by a quantifier, and treat them 
as schemas. That gets the 'firstorder' fragment precisely, gives a 
natural way to move to the 'infinitary' case (where the damn things 
get quantified and can be anywhere) and makes the 'core' more like 
old KIF 3. Or this could be an extension, but it still might be 
marking it out in this way as distinct subcase, as I think it wil be 
widely useful.

Any comments on this? The only snag I can see is that it would 
require rewriting the BNF slightly when we go form core to next 
layer, but maybe we just have to live with that.

>Along the lines of the above
>discussion, there would be a Part 5 called "Module Management"
>that would include Pat's ideas on URI's and importing/exporting.
>These would be included in a new part since they apply to theories
>written using the languages of all other Parts (e.g. First-Order KIF,
>row variables, Sorted KIF and MetaKIF).

Well, they are kind of orthogonal to what sentences are being 
imported. But whatever.

Pat

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes at ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes