From phayes at ai.uwf.edu Wed Nov 1 09:27:18 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:54 2003 Subject: Notes for KIF teleconference In-Reply-To: <200010312331.RAA01253@philebus.tamu.edu> References: <200010312331.RAA01253@philebus.tamu.edu> Message-ID: > > > > > (Incidentally, it is not at all clear that KIF is really > > > > first-order, since one can define 'finite' in KIF using sequence > > > > quantifiers.) > > > > > >I doubt that finitude is definable in the sense of there being a KIF > > >sentence that is true in all and only finite models of KIF. > > > > How about: > > (exists (@l)(forall (x)(or (member ?x (list @l)) (= ?x (list @l)))) > > > > According to the spec, every model must contain all finite lists of > > members of the domain. So the domain is finite iff it contains a > > list of all its members (I will generously allow that it not contain > > itself). @l varies over all the finite lists (sequences) in the > > domain. > >Your sentence will characterize finitude only if the spec also sez >that every model must contain *only* finite lists. Well, what really matters is whether the sequence quantifier ranges only over the finite ones. And the KIF spec doesnt actually say that (Genesereth is a wily old bird.) But on the other hand, it kind of assumes it, implicitly, by using the sequence quantifier to define its own syntax, saying that its own expressions are sequences which are also lists; so if the domain can contain infinite lists then the recursive definitions which characterize the list operations might never terminate, so the syntax itself isnt well-defined... or else it is potentially infinitary. Either way, there seems to be a problem. .... > > >No problem if we don't have predicate variables. Manageable but more > > >complicated if we do. > > > > No, its easy if we only have predicate variables. > >It is easy, I agree, but the fact remains that it is definitely more >complicated. I think with a careful choice of wording when describing the ordinary first-order models, it can be slipped through without any extra effort (apart from the aforementioned care.) > > > > Semantically what this involves is allowing some functions and > > > > relations into the domain of quantification, > > > > > >Not if it's just syntactic sugar -- i.e.,, we don't have predicate > > >variables. > > > > But I was thinking of the case where we do, so we can quantify over > > them. The point being that the range of that quantification may be > > even more limited than in a Henkin model: it could be just over the > > *named* predicates, which are in the first-order model anyway (though > > not in the usual first-order domain of quantification: but it is > > harmless to put them there.) > >A minor problem with this is that one likes (read: I like) to be able >to specify a notion of a model structure ahead of time independent of >a language. But no big deal (I don't think...). I agree, and I think we can still manage that. All one really needs is a countable infinity of relations (countable=Henkin) from which a finite set is going to be selected by the signature. That finiteness is what keeps everything very simple. > > >I'm not confident that is the best way to approach this. Why wouldn't > > >the syntax of another language just be a *theory* in an extension of > > >KIF that has syntactic predicates for that language? The syntax > > >itself would constitute (some of) the axioms of the theory. > > > > It would be a theory (with predicates for the syntactic classes), but > > we still need some basic machinery for describing syntax. How are you > > going to axiomatise concatenation of symbol strings? > >By axiomatizing a concatenation operator and a "String" predicate. (I >believe Quine did exactly that in his dissertation. I suspect this is >the first time I've ever mentioned Quine twice in an email msg...just >FYI, y'all...) Ah yes, kind of obvious once you say it. OK, maybe you are right. I just LIKE quasi-quotation, I think its an elegant device. And Quine invented that, too. > > > > 10. Allow structured typing of expressions ? > > > > > >Aren't you just talking about a sorted language here, Pat? > > > > Yes, but should it really be sorted? If so, we need a syntax for > > declaring sorts, a way of describing sort relations, etc. . I know > > its bread-and-butter work, but it will need to be done, and there are > > lots of boring but potentially important decisions to be made. Do we > > allow multiple inheritance? Overloading of sorts? Are quantifiers > > sorted or are argument positions sorted, or both? And so on. > >Agreed. I've attached the straightforward definition of a sorted >language I sent to the SUO list below (where it is easily ignored). >It makes these decisions, for better or ill. It's easily modified. OK, thanks for the input. I'd modify it to allow equality between different sorts (known to be false, but useful to state.) However we will need a syntax for declaring things to be one sort or another, and a way to describe sorts themselves. For example, what is the difference between a sort and a predicate? Can any predicate act as a sort or does it have to be specially designated as one? Another approach is to not 'sort' the syntax explicitly, but allow sort-restricted quantifiers as abbreviations for the (forall sort implies..) and (exist sort and...) patterns, and rely on axioms to declare things like subsort relationships, inheritance restrictions, etc.. This keeps the language open-ended and allows people to describe multiple inheritances, overloading and other exotica if they want to. I don't really have a brief here, just want the issue up for discussion. What neither of these buy you is things like default inheritance, however. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From apease at teknowledge.com Wed Nov 1 12:41:22 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:54 2003 Subject: Workshop dates In-Reply-To: <39fe3491.3580.0@bestweb.net> Message-ID: <4.2.0.58.20001101103913.01ad4db0@pop.teknowledge.com> John, I agree with this process. I think we also have to be sensitive to the requirements of the IEEE standards process by at least usually having open invitations to the SUO list to participate in any proposed smaller group, and acknowledging that until the larger group approves a proposal that results from a small group, it is just a proposal and not part of the standard. Adam At 09:55 PM 10/30/2000 -0400, John F. Sowa wrote: >Adam, > >I agree with the following point: > > >... For my part, > >I'm most interested in getting down to the specifics of defining the > >ontological content and wrapping up discussions about how to justify the > >SUO. Language discussion is an enabling issue for the SUO I think, not what > > >I'd like as the focus, but a definitely necessary prerequisite. > >One of the major problems is that a single, large mailing list >is not going to work, no matter what topics are being addressed. > >I'm not sure what will work, but I know that the best work >of any kind gets done by an iterative process: > > 1. Deciding on topics to be addressed (large group). > > 2. Assigning topics to individuals and small groups (based > on interests, abilities, and, if possible, funding). > > 3. Hard work by individuals and small groups to produce > something tangible (tools, definitions, reports,...). > > 4. Distribution of products of #3 to larger group (probably > by posting to a web site). > > 5. Evaluation of products by larger group. > > 6. Go back to #1 and repeat. > >Defining SUO-KIF by the people going to the TAMU workshop is >one such example of a small group. And the writing of the new >KIF definition will take an even smaller group, which would >produce a draft to be evaluated by this group, which would then >be submitted to the next group higher up, etc. > >There are many content projects to be done. PSL is one >example. My critique of PSL and the paper on processes and >causality is another. We still haven't taken the next step >of deciding how to merge/relate/evaluate those contributions, >but something like that should be done at some point, not just >for processes, but for every subtopic in ontology. And all of >those subtopics must be related to the larger framework. > >John Sowa ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From apease at teknowledge.com Wed Nov 1 12:50:35 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:54 2003 Subject: Workshop dates In-Reply-To: <200010310321.TAA26610@puffin.rt.cs.boeing.com> Message-ID: <4.2.0.58.20001101104139.01a49ef0@pop.teknowledge.com> Mike, While many ontologies are intended to suit a specific purpose I don't take it as a given that all must be. In fact, I think that any ontology intended for general use can be "debugged" by trying to extend it for a series of different applications. I take the Cyc ontology as an existence proof that this approach can work. In practice in my group on half a dozen projects in areas as diverse as real estate, political and economic reasoning, and army battlefield planning we've found a great deal of utility in building from the Cyc ontology. There were no fundamental changes in the upper ontology that were needed, just domain specific extensions. Doug's comments are true but are not a criticism of the SUO effort. He doesn't assert that an upper ontology isn't very useful, he merely states that getting the "one true upper ontology" isn't a worthwhile goal. There's more than one right ontology and so people should make reasonable engineering compromises to create a practical result. That's been the Cyc approach and is exactly what I believe we need in the SUO. Adam At 07:21 PM 10/30/2000 -0800, Michael Uschold wrote: > From Adam Pease: > >Folks, > Actually, my understanding of Jim's position on the SUO (from a >conversation I had with him in August) was not so much that he had concerns >about the language, but that he feels that a common ontology is >impractical. The model he has for DAML is that given a language and set of >tools, many different ontologies will spring up organically and that it's >unlikely people will agree on a single one. I respectfully disagree with him. > As a DAML participant, my group is developing some tools for ontology >search and translation so I can disagree with one aspect of his model and >yet still provide his program with some good results (I hope). > >Adam >=========== > >Well, I must confess that I have a lot of sympathy for and concern about >Jim's view that a common ontology may just never catch on. I have more basic >concerns that there are in-principle reasons why it is a bad idea (such as >the fact that an ontology is an engineered artifact that is intended to suit >specific purposes. Thus it is right and proper for 3 ontologies in the same >domain designed for three different purposes, to be **different**. > >I regard teh SUO as a big experiment which if we are lucky, will shed insight >into various important questions such as: >1. can there, IN PRACTICE, be real benefits to having an SUO >2. if so, can we clearly articulate under what specific circumstances this > is likelyh to be so? I am quite confident that an SUO will often NOT be > useful. >3. Is there a viable process for getitng big project like this done in > a collaborative way using an mail list as a primary vehicle? >4. Does the Upper Level really matter much? Doug Lenat supposedly thinks >it does not matter becuase there is minimal connection betweenit and the >lower levels. I had this experience in my work on teh Enterprise Ontology. >Nothing has been published that I am aware of that argues strongly with >some empirical results that this is just not so. > >and various others, that have been bandied about ... > > >I'm aware now, that this is a message that shoudl be sent to everyone.. >but i shall refrain for no good reason. > >Mike > ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Wed Nov 1 13:44:39 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:54 2003 Subject: Workshop dates In-Reply-To: <4.2.0.58.20001101104139.01a49ef0@pop.teknowledge.com> References: <4.2.0.58.20001101104139.01a49ef0@pop.teknowledge.com> Message-ID: >Mike, > While many ontologies are intended to suit a specific purpose I >don't take it as a given that all must be. In fact, I think that >any ontology intended for general use can be "debugged" by trying to >extend it for a series of different applications. I take the Cyc >ontology as an existence proof that this approach can work. Hmmm. Maybe this isnt the right forum for this debate, but I think the experience of Cyc is, if anything, that ontologies tend to fracture into special-purpose parts. Cyc makes heavy use of 'contexts' for example as a way of partitioning its axioms into micro-ontologies, and a larger percentage of its axioms are only applicable within a microtheory (such as most of the geometric and topological concepts, which are restricted to geographical uses.) > In practice in my group on half a dozen projects in areas as >diverse as real estate, political and economic reasoning, and army >battlefield planning we've found a great deal of utility in building >from the Cyc ontology. There were no fundamental changes in the >upper ontology that were needed, just domain specific extensions. > Doug's comments are true but are not a criticism of the SUO >effort. He doesn't assert that an upper ontology isn't very useful, >he merely states that getting the "one true upper ontology" isn't a >worthwhile goal. Er...isnt the the very point of the SUO ? > There's more than one right ontology and so people should make >reasonable engineering compromises to create a practical result. >That's been the Cyc approach and is exactly what I believe we need >in the SUO. I guess I dont follow this. How is the SUO going to allow for many upper ontologies? Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From gruning at cme.nist.gov Wed Nov 1 14:08:28 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:54 2003 Subject: KIF teleconference info References: <200011010022.SAA01527@philebus.tamu.edu> Message-ID: <3A00783C.20027304@cme.nist.gov> Hello everyone, the KIF teleconference will be November 9, 2:00 pm - 4:00 pm EST. We will be using a conferencing service, so here is the contact info: USA Toll Free Number: 888-603-9067 USA Toll Number: +1-712-271-3623 PASSCODE: 51584 LEADER: Michael Gruninger Based on the original notes and subsequent discussion, I will write up and agenda and distribute it by next Tuesday. Pat: I am still trying to find out whether you can use the toll-free number from the UK, or whether the conferencing service needs to contact you at the time of the meeting. - michael From apease at teknowledge.com Wed Nov 1 14:27:01 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:54 2003 Subject: Workshop dates In-Reply-To: References: <4.2.0.58.20001101104139.01a49ef0@pop.teknowledge.com> <4.2.0.58.20001101104139.01a49ef0@pop.teknowledge.com> Message-ID: <4.2.0.58.20001101121139.019c4f68@pop.teknowledge.com> Pat, At 01:44 PM 11/1/2000 -0600, pat hayes wrote: >>Mike, >> While many ontologies are intended to suit a specific purpose I don't >> take it as a given that all must be. In fact, I think that any ontology >> intended for general use can be "debugged" by trying to extend it for a >> series of different applications. I take the Cyc ontology as an >> existence proof that this approach can work. > >Hmmm. Maybe this isnt the right forum for this debate, but I think the >experience of Cyc is, if anything, that ontologies tend to fracture into >special-purpose parts. Cyc makes heavy use of 'contexts' for example as a >way of partitioning its axioms into micro-ontologies, and a >larger percentage of its axioms are only applicable within a microtheory >(such as most of the geometric and topological concepts, which are >restricted to geographical uses.) For the most part, although contexts allow truly contradictory knowledge bases to exists, in practice, contexts in Cyc tend to be used for the more mundane reason of "package" management - more of a software engineering convention for keep different projects coherent. Also, you'll find that any significant set of inferences are made in contexts which inherit from most of the general content of the KB. This was certainly true in our HPKB Crisis Management test questions. I'm not sure which geometric and topological concepts you're referring to. #$between, #$above-Directly, #$in-ContClosed are all in the public Cyc upper (otherwise known as the BaseKB in the DARPA version of Cyc), and all just take tangible things as arguments rather than any more specific geographical-only things. >> In practice in my group on half a dozen projects in areas as diverse as >> real estate, political and economic reasoning, and army battlefield >> planning we've found a great deal of utility in building from the Cyc >> ontology. There were no fundamental changes in the upper ontology that >> were needed, just domain specific extensions. >> Doug's comments are true but are not a criticism of the SUO effort. He >> doesn't assert that an upper ontology isn't very useful, he merely >> states that getting the "one true upper ontology" isn't a worthwhile goal. > >Er...isnt the the very point of the SUO ? I wouldn't say so. The goal of the SUO is to create a common upper ontology that is general and reusable. There's no implication that there's only one possible solution, only that if we find one solution that is "good enough" that the "network effects" (to use a new economy term) will mean that there's huge value in everyone adopting the same upper ontology. >>There's more than one right ontology and so people should make reasonable >>engineering compromises to create a practical result. That's been the Cyc >>approach and is exactly what I believe we need in the SUO. > >I guess I dont follow this. How is the SUO going to allow for many upper >ontologies? I haven't been clear I guess. I don't believe that the SUO will or should allow for many upper ontologies. I'm just agreeing with the comment attributed to Doug that there are lots of potential "good enough" upper ontologies. We should make reasonable engineering choices to come up with a good enough upper ontology and make that one the standard. The straw man alternative is to have people arguing for eternity on minor ontological distinctions in order to find the "one true ontology". (I'm not attributing that straw man to anyone). Adam >Pat > >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola, FL 32501 (850)202 4440 fax >phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes > ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Wed Nov 1 18:25:25 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:54 2003 Subject: Another note for KIF teleconference Message-ID: As promised, here is a note on quotation. I sent this a while ago but I think it didnt get to you all.Apologies if you have seen this before (but see the PS) Pat -------------- Quotation. The language needs a simple, clear notation for describing syntax, which allows quantification over expressions. It should be possible to write axioms in the language which fully describe the syntax of any reasonable language, as well as KISS itself. I think that this requires the ability to quote arbitrary strings of characters, even if they are not well-formed KISS expressions. KIF relies on the Sexpression convention to indicate the end of a quotation; the quoted expression is an Sexpression prefixed by a caret. One can think of the string '^(' as indicating an opening quote (actually a corner-quote since one can quantify into it) , but the matching close-quote is simply the matching close-bracket. It is impossible to quote a string containing unmatched brackets using this convention. A fully expressive quotation scheme must have a way to indicate the start and end of the quoted string, and a way to indicate internal string variables. One can adapt the KIF notation to this end with a minimal change by allowing '^)' as the end-quote mark and retaining the ',?' prefix for string variables in quotes. In order to make it possible to include the characters '^', ',' and '?' in strings, their special meanings can be cancelled by prefixing them with an extra caret. Thus for example if ?foo is bound to the string 'def' then ^(ABC ^^,?foo ^,?baz^) would denote the string 'ABC ^def,?baz' (note that the space after the 'C' is a genuine character, but that after the variable name is the variable name terminator.) However, this convention is awkward. It would be simpler to assume that all variables were genuine variables unless the '?' is cancelled. Then one single special character is required: prefixed to '(' and ')' respectively it indicates open and close quote; prefixed to itself it indicates itself; and prefixed to '?' it cancels the default interpretation of this as the beginning of a variable name. This could be the caret, but I will use backslash instead to emphasise the difference. Otherwise, variables are treated as usual (and thought of as including their terminating whitespace character, if there is one) and other characters are treated as though they were inside normal literal quotation marks. The above string would then be quoted like this: \(ABC ^?foo ,\?baz\). Notice again that even though the comma would terminate the variable name, the space which in fact does so is 'absorbed' into the variable and does not occur in the string. To include an opening or closing quote inside a quoted string it is necessary to think of it as consisting of two characters, and to prefix the first of these with an additional backslash to force it to be interpreted literally, thus: \(...\\(...\). Other special conventions can be used as long as they are always indicated by an initial backslash, which can then be cancelled (and the rest of the string read literally) by an additional backslash. For example, to indicate nonprinting symbols we can follow KIF by using numerical codes. Inside a character string the sequence \#n where n is a number, indicates the character with ASCII code n . Like variables, these character constants 'absorb' terminating whitespace (without this convention it would be impossible to quote a character not followed by a space.) The number may be a variable, of course, so that one might write \#?num to denote a character whose ASCII code lies in a certain range. Arbitrary BNF syntax can now be described by axioms, although somewhat clumsily. For example consider the following piece of toy BNF: ::= | ? | \# which can be axiomatised as follows: (forall (?x)(iff (variable ?x)(or (charstring ?x) (exists (?y)(and (charstring ?y)(= ?x \(\??y\)))) (exists (?y) (and (number ?y)(= ?x \(\\#?y\)))) ))) -------- Pat Hayes PS. Recently I have discovered that to be fully XML-compliant, we need to be able to specify not just arbitrary ASCII characters but a wider range, eg. those from Unicode. Since there are several distinct conventions in international use for indicating character codes( http://www.ietf.org/rfc/rfc2277.txt ) we should probably allow an even more delicate syntax which specifies a character with code #n from character-set called 'foo'. For example we could use the convention \#n\foo , using the same quote-escape convention to cancel the backslash where necessary and the same terminating whitespace convention. This will work provided nobody uses a character code name which contains \( # or ). --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5108 bytes Desc: not available Url : http://philebus.tamu.edu/pipermail/kif/attachments/20001101/104f7074/attachment.bin From sowa at bestweb.net Wed Nov 1 20:08:06 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:54 2003 Subject: Workshop dates Message-ID: <3a00da96.a494.0@bestweb.net> Adam, There is a major difference between doing the nitty-gritty hard work of designing and writing a specification and the process of getting it accepted as a standard. > I agree with this process. I think we also have to be sensitive to the >requirements of the IEEE standards process by at least usually having open >invitations to the SUO list to participate in any proposed smaller group, >and acknowledging that until the larger group approves a proposal that >results from a small group, it is just a proposal and not part of the standard. The IEEE, ANSI, NCITS, ISO, ECMA, etc., standards bodies all insist upon open review and standardization processes. But 99.92% of the work in developing the standard is done outside the committee meetings of those bodies. An example is the way ECMA developed ECMAScript as a standardized version of JavaScript. The overwhelming amount of effort was done by Netscape (and some by other vendors) long before the project was submitted to ECMA. The final version approved by ECMA was largely based on the earlier work with minor modifications. That is what happens with any standard. Committees are good for reviewing things that have already been designed. Their strength is in critiquing and probing the soft underbelly for any sins of omission or commision. But the really hard work of design and testing goes on outside the committees. John From apease at teknowledge.com Wed Nov 1 21:11:56 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference In-Reply-To: Message-ID: <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> Pat, This may be a dumb question, but why have any special quoting characters? Why not pass sentences as arguments without quoting like CycL does? Adam At 06:25 PM 11/1/2000 -0600, pat hayes wrote: >As promised, here is a note on quotation. I sent this a while ago but I >think it didnt get to you all.Apologies if you have seen this before (but >see the PS) > >Pat >-------------- > > >Quotation. > >The language needs a simple, clear notation for describing syntax, which >allows quantification over expressions. It should be possible to write >axioms in the language which fully describe the syntax of any reasonable >language, as well as KISS itself. I think that this requires the ability >to quote arbitrary strings of characters, even if they are not well-formed >KISS expressions. > >KIF relies on the Sexpression convention to indicate the end of a >quotation; the quoted expression is an Sexpression prefixed by a caret. >One can think of the string '^(' as indicating an opening quote >(actually a corner-quote since one can quantify into it) , but the >matching close-quote is simply the matching close-bracket. It is >impossible to quote a string containing unmatched brackets using this >convention. > >A fully expressive quotation scheme must have a way to indicate the start >and end of the quoted string, and a way to indicate internal string >variables. One can adapt the KIF notation to this end with a minimal >change by allowing '^)' as the end-quote mark and retaining the ',?' >prefix for string variables in quotes. In order to make it possible to >include the characters '^', ',' and '?' in strings, their special meanings >can be cancelled by prefixing them with an extra caret. Thus for example >if ?foo is bound to the string 'def' then ^(ABC ^^,?foo ^,?baz^) would >denote the string 'ABC ^def,?baz' (note that the space after the 'C' is a >genuine character, but that after the variable name is the variable name >terminator.) > >However, this convention is awkward. It would be simpler to assume that >all variables were genuine variables unless the '?' is cancelled. Then one >single special character is required: prefixed to '(' and ')' respectively >it indicates open and close quote; prefixed to itself it indicates itself; >and prefixed to '?' it cancels the default interpretation of this as the >beginning of a variable name. This could be the caret, but I will use >backslash instead to emphasise the difference. Otherwise, variables are >treated as usual (and thought of as including their terminating whitespace >character, if there is one) and other characters are treated as though >they were inside normal literal quotation marks. The above string would >then be quoted like this: \(ABC ^?foo ,\?baz\). Notice again that even >though the comma would terminate the variable name, the space which in >fact does so is 'absorbed' into the variable and does not occur in the >string. To include an opening or closing quote inside a quoted string it >is necessary to think of it as consisting of two characters, and to prefix >the first of these with an additional backslash to force it to be >interpreted literally, thus: \(...\\(...\). Other special conventions can >be used as long as they are always indicated by an initial backslash, >which can then be cancelled (and the rest of the string read literally) by >an additional backslash. > >For example, to indicate nonprinting symbols we can follow KIF by using >numerical codes. Inside a character string the sequence \#n where n is a >number, indicates the character with ASCII code n . Like variables, these >character constants 'absorb' terminating whitespace (without this >convention it would be impossible to quote a character not followed by a >space.) The number may be a variable, of course, so that one might write >\#?num to denote a character whose ASCII code lies in a certain range. > >Arbitrary BNF syntax can now be described by axioms, although somewhat >clumsily. For example consider the following piece of toy BNF: > > ::= | ? | \# > >which can be axiomatised as follows: > >(forall (?x)(iff (variable ?x)(or > (charstring ?x) > (exists (?y)(and (charstring ?y)(= ?x \(\??y\)))) > (exists (?y) (and (number ?y)(= ?x \(\\#?y\)))) ))) > >-------- > >Pat Hayes > >PS. Recently I have discovered that to be fully XML-compliant, we need to >be able to specify not just arbitrary ASCII characters but a wider range, >eg. those from Unicode. Since there are several distinct conventions in >international use for indicating character codes( >http://www.ietf.org/rfc/rfc2277.txt ) >we should probably allow an even more delicate syntax which specifies a >character with code #n from character-set called 'foo'. For example we >could use the convention \#n\foo , using the same quote-escape convention >to cancel the backslash where necessary and the same terminating >whitespace convention. This will work provided nobody uses a character >code name which contains \( # or ). >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola, FL 32501 (850)202 4440 fax >phayes@ai.uwf.edu >http://www.coginst.uwf.edu/~phayes > ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From apease at teknowledge.com Wed Nov 1 21:13:40 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:55 2003 Subject: Workshop dates In-Reply-To: <3a00da96.a494.0@bestweb.net> Message-ID: <4.2.0.58.20001101191237.01a475e8@pop.teknowledge.com> John, Ok. This is the first formal standards effort I've been involved in. I just want to make sure we're following the right process. What you describe makes sense to me. Adam At 10:08 PM 11/1/2000 -0400, John F. Sowa wrote: >Adam, > >There is a major difference between doing the nitty-gritty >hard work of designing and writing a specification and the >process of getting it accepted as a standard. > > > I agree with this process. I think we also have to be sensitive to the > > >requirements of the IEEE standards process by at least usually having open > > >invitations to the SUO list to participate in any proposed smaller group, > > >and acknowledging that until the larger group approves a proposal that > >results from a small group, it is just a proposal and not part of the > standard. > > >The IEEE, ANSI, NCITS, ISO, ECMA, etc., standards bodies all >insist upon open review and standardization processes. But >99.92% of the work in developing the standard is done outside >the committee meetings of those bodies. An example is the >way ECMA developed ECMAScript as a standardized version of >JavaScript. The overwhelming amount of effort was done by >Netscape (and some by other vendors) long before the project >was submitted to ECMA. The final version approved by ECMA >was largely based on the earlier work with minor modifications. > >That is what happens with any standard. Committees are good >for reviewing things that have already been designed. Their >strength is in critiquing and probing the soft underbelly for >any sins of omission or commision. But the really hard work >of design and testing goes on outside the committees. > >John ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Thu Nov 2 11:01:40 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference In-Reply-To: <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> References: <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> Message-ID: >Pat, > This may be a dumb question, but why have any special quoting >characters? Why not pass sentences as arguments without quoting >like CycL does? > >Adam Yes, I thought about that. It works provided that (1) one is always passing a well-formed sentence and (2) the thing one is passing it to 'knows' whether to treat it as a sentence or as the name of a sentence, and (3) there is no other way to describe an expression which this needs to interact with. I think we could fix KIF to satisfy (3), and we could design the core to satisfy (2) but it would be v. hard to ensure that this was preserved in every extension, and (1) is the real killer, since I think that in order to be viable, KIF needs to be able to describe the syntax of other languages as well as its own. So I think that KIF (maybe in an extension) will neeed some kind of quotation machinery. But it might be worth thinking of this option as one mode of 'transparent' quoting. In many ways it is a natural extension of the idea of allowing predicate variables, since one can think of a sentence as a zero-ary predicate with no arguments. It is a real semantic extension, however, and takes the language slightly further towards being a genuine type theory. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From apease at teknowledge.com Thu Nov 2 11:41:16 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference In-Reply-To: References: <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> Message-ID: <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> Pat, I'm afraid I'll sound a bit like a broken record on this issue with the response "Cyc does it". Cyc has its flaws but if we know Cyc has accomplished something then we have a good foil against which to test our ideas. Any parser which supports the language can ensure (1) if you need to ensure syntactic well-formedness. To address (2), Cyc has the type CycExpression. We can just constrain arguments to be of type "expression". However, this is one computer scientist's/engineer's simplistic solution to a problem which may have significant implications for the logical properties of the language. I don't know how hard the logical implications of such a decision would be to handle. I don't understand why we'd need to have the language itself handle quoting other languages. That seems like an unnecessary complication to me and a task better left to some text processing code, not a logical language. We could define "=>" as just another predicate in the language with arity two and arguments of type "Expression". Similarly for "or", "and" etc. We'd then have a very consistent and simple syntax and everything other than "(" and ")" would be a term in the ontology. Adam At 11:01 AM 11/2/2000 -0600, pat hayes wrote: >>Pat, >> This may be a dumb question, but why have any special quoting >> characters? Why not pass sentences as arguments without quoting like >> CycL does? >> >>Adam > >Yes, I thought about that. It works provided that (1) one is always >passing a well-formed sentence and (2) the thing one is passing it to >'knows' whether to treat it as a sentence or as the name of a sentence, >and (3) there is no other way to describe an expression which this needs >to interact with. I think we could fix KIF to satisfy (3), and we could >design the core to satisfy (2) but it would be v. hard to ensure that this >was preserved in every extension, and (1) is the real killer, since I >think that in order to be viable, KIF needs to be able to describe the >syntax of other languages as well as its own. So I think that KIF (maybe >in an extension) will neeed some kind of quotation machinery. > >But it might be worth thinking of this option as one mode of 'transparent' >quoting. In many ways it is a natural extension of the idea of allowing >predicate variables, since one can think of a sentence as a zero-ary >predicate with no arguments. It is a real semantic extension, however, and >takes the language slightly further towards being a genuine type theory. > >Pat > >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola, FL 32501 (850)202 4440 fax >phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes > ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From sowa at bestweb.net Thu Nov 2 19:14:23 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference Message-ID: <3a021f7f.d85.0@bestweb.net> Pat, Adam, et al., The fact that Cyc does something is a useful data point, but we all have our doubts about Cyc's internal consistency. However, I would like to suggest another data point that is more trustworthy: Goedel (not the person, but the programming language) as documented in _The Goedel Programming Language_ by Patricia Hill and John Lloyd, MIT Press, 1994. The Goedel language is a very nice, cleaned-up logic programming language (the authors say that Goedel is to Prolog as Pascal is to Fortran). One of the important things they addressed is the problem of using Prolog as a metalanguage (which many people frequently do, following the advice of Robert Kowalski, who has been doing wonders with it for about 20 years). However, one of the nasty pitfalls that anyone who uses Prolog as a metalanguage discovers sooner or later is the confusion of the object language variables with the metalanguage variables. Goedel manages to avoid that pitfall by using a strongly typed syntax (the authors make the point that they are using "sorts", but they use the word "type" to be consistent with programming usage instead of Bertie R's usage). Goedel also has some other features that Cyc uses, such as "modules" for containing theories, which can be imported into other theories. They use the modules to address some of the problems that we have discussed for KIF -- namely do we really have to give a full axiomatization of integers, real numbers, etc. What they do is to provide a "built-in" module that implements arithmetic, but they show only the signatures of the predicates and hide the actual axioms. If you trust your computer's arithmetic (not recommended, if you use Intel), you can pretend that everything has been adequately defined. In any case, I recommend that we use Goedel as an example of a well thought out approach to using typed (or sorted) variables, modules, and metalanguage. John Sowa From gruning at cme.nist.gov Mon Nov 6 10:45:30 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:55 2003 Subject: Agenda for Nov.9 KIF teleconference References: <200011010022.SAA01527@philebus.tamu.edu> Message-ID: <3A06E02A.A669F8CB@cme.nist.gov> Here is the proposed agenda for the teleconference on November 9. If anyone has items that I missed or misrepresented, please contact me. - michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://philebus.tamu.edu/pipermail/kif/attachments/20001106/f63c20b4/nov9agenda.html From apease at teknowledge.com Mon Nov 6 21:20:17 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:55 2003 Subject: Agenda for Nov.9 KIF teleconference In-Reply-To: <3A06E02A.A669F8CB@cme.nist.gov> References: <200011010022.SAA01527@philebus.tamu.edu> Message-ID: <4.2.0.58.20001106190947.01a6f160@pop.teknowledge.com> Michael, I'd like to register a few opinions on these items. At 11:45 AM 11/6/2000 -0500, Michael Gruninger wrote: >Here is the proposed agenda for the teleconference on November 9. >If anyone has items that I missed or misrepresented, please contact me. > >- michael > > > >Agenda for KIF Standardization Meeting > > > > >November 9, 2000 > >Below is a list of issues and proposals that have been contributed by >people within the group. For each agenda item, we will decide to either > * adopt the proposal; > * identify several alternatives to the proposal, and make a final > decision at the workshop; > * table the issue and leave for the workshop. > > > >Proposals > > > * Organize KIF into a KIF-Core and a set of modules. These modules > will either be extensions to the core (ie those definable by axiomatic > theories written in the same core language) or they will be extensions/ > modifications to the language itself. I'd like to amend this to state that the syntax of the core should be fixed and very simple. The extensions should be to the ontology or the model theory. > * Proposed extensions to KIF-Core: > * Number theory > * Lists > * Characters and strings > * KIF Metatheory We should have semantics for numbers but keep in mind that while we should strive for as complete a semantics for numbers as possible, that no automated process is actually going to be proving theorems in order to do addition or multiplication. The theory for numbers should be in the ontology, not part of the language. Lists seem like an unnecessary programming language construct Characters and strings should be allowed types but I'm not sure they need to be in the language as opposed to the ontology. >For all following issues, we will need to decide whether to include the >proposed feature in KIF-Core, include the feature in a KIF module, or >whether to leave out the feature altogether. > > * Omit variadic relations and functions > * Omit sequence quantification agreed > * Simplify and reorganize quotation yes, I'd suggest eliminating quotation per se and simply allowing relations to specify a type of "Expression" >The proposal follows the note from Pat Hayes (1 Nov 2000 18:25:25) > * Eliminate the identification of expressions with lists yes > * Allow case-sensitive identifier names yes > * Introduce a sorted language definition > The proposal follows the note from Chris Menzel (31 Oct 2000 17:31:20) > * Retain the use of the truth predicate wtr, possibly within the > Metatheory Extension. > * Change the syntax for definitional forms I'd recommend removing them altogether. > * Introduce lambda expressions no > * Allow general terms, including variables, to occur in the first > position of expressions (i.e. relations and functions need not be > constant symbols.) yes > * Introduce expressions (not just KIF expressions, but arbitrary > expressions) as first-class entities, distinct from lists, and have a > reasonably powerful syntax-description ability using the language to > express BNF directly. I'd support allowing expressings as first-class entities but not including syntax-description facilities > * Integrate a modern class-inheritance mechanism into the syntax I think this should be in the ontology, not the syntax > * There are several additional issues which seemed to be for general > discussion rather than specific proposals: > > * What must features must be included in the Metatheory extension? > * If KIF-Core does not contain an explicit axiomatization of the > metatheory, must we still specify the metatheory within the KIF-Core > document? What form should this specification take? > * Should the document contain a specification of the semantics of KIF? > (Although this is included in the KIF 3.0 document, it is not included in > the KIF 98 document.) > * Clarify the semantics of quantifiers > * Clarify the role of bottom > * Does the current document require that KIF must contain only finite > lists? Are there any additional such requirements that are not fist-order? ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Tue Nov 7 08:09:10 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference In-Reply-To: <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> References: <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> Message-ID: (Sorry about delay in replying, I am back online now.) > I'm afraid I'll sound a bit like a broken record on this issue >with the response "Cyc does it". Cyc has its flaws but if we know >Cyc has accomplished something then we have a good foil against >which to test our ideas. > Any parser which supports the language can ensure (1) if you need >to ensure syntactic well-formedness. Yes, but that wasnt my point. I think we need to be able to quote things which are NOT well-formed. In fact,to be fully syntactically expressible, KIF should be able to quote (or otherwise describe) *any string whatever*, including for example 'pieces' of Sexpressions. I don't think that Cyc has this ability. > To address (2), Cyc has the type CycExpression. We can just >constrain arguments to be of type "expression". What about strings that arent expressions? What about things like 'every relation name starting with "Physical..." '? What about wanting to be able to say "The meaning of '...' in DAML is ',,,' in KIF " ? I agree that the Cyc idea is often very convenient and handy (though I agree with John in wanting a bit more reassurance that one cannot reproduce paradoxes in CycL) but it isnt a general-purpose solution. >However, this is one computer scientist's/engineer's simplistic >solution to a problem which may have significant implications for >the logical properties of the language. I don't know how hard the >logical implications of such a decision would be to handle. I don't >understand why we'd need to have the language itself handle quoting >other languages. That seems like an unnecessary complication to me >and a task better left to some text processing code, not a logical >language. This turns out to be centrally important once one starts dealing with 'web logics'. Think of ontologies as being first-class objects themselves, and the need to say in one language what is provable in an ontology written in a different language. True, this could be left to text processing code, but I think it would be a bad strategy to do so, since this kind of complication is likely to be norm in future rather than something exotic, and people will need a logical language to do it in, and if that is a different logic then that is the one which will get used. > We could define "=>" as just another predicate in the language >with arity two and arguments of type "Expression". Similarly for >"or", "and" etc. We'd then have a very consistent and simple syntax >and everything other than "(" and ")" would be a term in the >ontology. I agree, this might be well worth doing, though it needs some care. The argument of a first-order connective actually is a truth-value, not an expression, for example, so this isnt really to do with the quoting issue and could be discussed independently of it. Treating the connectives as relations is conventionally done in type theories. If one allows arbitrary functions then truth-functions are just a special case. The complication is that if one starts with a first-order language, then allowing tricks like this enlarges the universe of relations and functions over which one is forced to quantify. This isnt fatal, but it does require us to exercise some care if we want to retain the first-order character of KIF. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From andersen at ontologyworks.com Tue Nov 7 10:41:02 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference References: <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> Message-ID: <3A08309E.199D15E3@ontologyworks.com> pat hayes wrote: > > (Sorry about delay in replying, I am back online now.) > > > I'm afraid I'll sound a bit like a broken record on this issue > >with the response "Cyc does it". Cyc has its flaws but if we know > >Cyc has accomplished something then we have a good foil against > >which to test our ideas. > > Any parser which supports the language can ensure (1) if you need > >to ensure syntactic well-formedness. > > Yes, but that wasnt my point. I think we need to be able to quote > things which are NOT well-formed. In fact,to be fully syntactically > expressible, KIF should be able to quote (or otherwise describe) > *any string whatever*, including for example 'pieces' of > Sexpressions. I don't think that Cyc has this ability. Pat is right. If memory serves, Cyc uses a functional representation of formulas. For example, "and" is a function that ranges over a list of formulas and returns a formula. So, Cyc encapsulates some normally syntactic restrictions as semantic ones. One could not say in CycL, for example ( and not ( Phlogiston ) ) The objects just don't have the right types: "not" is not a formula and parentheses aren't even syntactic objects in the system. > > To address (2), Cyc has the type CycExpression. We can just > >constrain arguments to be of type "expression". > > What about strings that arent expressions? What about things like > 'every relation name starting with "Physical..." '? What about > wanting to be able to say "The meaning of '...' in DAML is ',,,' in > KIF " ? > > I agree that the Cyc idea is often very convenient and handy (though > I agree with John in wanting a bit more reassurance that one cannot > reproduce paradoxes in CycL) but it isnt a general-purpose solution. I wouldn't lose sleep over worry that Cyc allows paradox. It's all too easy to define paradoxical stuff. Now, what effect that would have on Cyc's theorem prover God only knows. ...bill -- Bill Andersen Chief Technology Officer - Ontology Works 1130 Annapolis Road, Suite 203, Odenton, MD 21113 andersen@ontologyworks.com / 410-674-7600 From apease at teknowledge.com Tue Nov 7 11:04:49 2000 From: apease at teknowledge.com (apease) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference In-Reply-To: References: <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> Message-ID: <4.2.0.58.20001107084242.01249820@pop.teknowledge.com> Pat, At 02:09 PM 11/7/2000 +0000, pat hayes wrote: >(Sorry about delay in replying, I am back online now.) > >> I'm afraid I'll sound a bit like a broken record on this issue with the >> response "Cyc does it". Cyc has its flaws but if we know Cyc has >> accomplished something then we have a good foil against which to test >> our ideas. >> Any parser which supports the language can ensure (1) if you need to >> ensure syntactic well-formedness. > >Yes, but that wasnt my point. I think we need to be able to quote things >which are NOT well-formed. In fact,to be fully syntactically >expressible, KIF should be able to quote (or otherwise describe) *any >string whatever*, including for example 'pieces' of Sexpressions. I don't >think that Cyc has this ability. Why would you want to be able to quote things which are not well-formed? >>To address (2), Cyc has the type CycExpression. We can just constrain >>arguments to be of type "expression". > >What about strings that arent expressions? What about things like 'every >relation name starting with "Physical..." '? What about wanting to be able >to say "The meaning of '...' in DAML is ',,,' in KIF " ? The first example is the sort of string processing that I think would be better accomplished in Perl or even Prolog. We shouldn't be trying to create a programming language. The second example is easy to do in Cyc: (synonymousExternalConcept Animal SENSUS-Information1997 "ANIMAL") or (synonymousExternalConcept Inform-CommunicationAct SENSUS-Information1997 "ASSERTIVE-ACT") >I agree that the Cyc idea is often very convenient and handy (though I >agree with John in wanting a bit more reassurance that one cannot >reproduce paradoxes in CycL) but it isnt a general-purpose solution. Well, I don't want to put myself in the position of being an apologist for Cyc but a lot of their solutions are eminently practical. Theoretical problems like paradoxes should certainly be addressed, but if there's no general solution, there is often an engineering solution that works for all practical cases and allows further progress to be made. >>However, this is one computer scientist's/engineer's simplistic solution >>to a problem which may have significant implications for the logical >>properties of the language. I don't know how hard the logical >>implications of such a decision would be to handle. I don't understand >>why we'd need to have the language itself handle quoting other >>languages. That seems like an unnecessary complication to me and a task >>better left to some text processing code, not a logical language. > >This turns out to be centrally important once one starts dealing with 'web >logics'. Think of ontologies as being first-class objects themselves, and >the need to say in one language what is provable in an ontology written in >a different language. True, this could be left to text processing code, >but I think it would be a bad strategy to do so, since this kind of >complication is likely to be norm in future rather than something exotic, >and people will need a logical language to do it in, and if that is a >different logic then that is the one which will get used. Another alternative would be to have text processing sorts of stuff in another language that can coexist and interact with a compiled logical language. This approach would be compatible with the sort of thing that Bill and his colleagues are pursuing of having a high level logical language which compiles down into prolog. You can then write more "algorithmic" code in prolog. I should note that this is also similar to what Cycorp does in practice. Knowledge engineers write strictly in CycL. However, they have a lisp variant called subL which implements the inference engine and can interact with the declarative knowledge. If a Cyclist wants to manipulate strings he or she can write some subL code to accomplish that and then make the code "visible" to the declarative language as a function. I believe if we take the approach I'm proposing we'll have a much simpler and cleaner declarative language which would still enable system developers to make use of programming languages appropriate for more procedural activities. >> We could define "=>" as just another predicate in the language with >> arity two and arguments of type "Expression". Similarly for "or", "and" >> etc. We'd then have a very consistent and simple syntax and everything >> other than "(" and ")" would be a term in the ontology. > >I agree, this might be well worth doing, though it needs some care. The >argument of a first-order connective actually is a truth-value, not an >expression, for example, so this isnt really to do with the quoting issue >and could be discussed independently of it. Treating the connectives as >relations is conventionally done in type theories. If one allows arbitrary >functions then truth-functions are just a special case. The complication >is that if one starts with a first-order language, then allowing tricks >like this enlarges the universe of relations and functions over which one >is forced to quantify. This isnt fatal, but it does require us to exercise >some care if we want to retain the first-order character of KIF. Ok, there's a lot in this paragraph I don't understand because I'm lacking the degree of background in formal logic I need. But, thanks to your posts and others I'm managing to learn little by little. Many thanks for the dialog. Adam >Pat > >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola, FL 32501 (850)202 4440 fax >phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes > ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From sowa at bestweb.net Tue Nov 7 12:00:52 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:55 2003 Subject: Another note for KIF teleconference Message-ID: <3a085164.6883.0@bestweb.net> Bill, Pat, et al., Pat Hayes wrote: >> I agree with John in wanting a bit more reassurance that one cannot >> reproduce paradoxes in CycL) but it isnt a general-purpose solution. Bill Andersen replied: > I wouldn't lose sleep over worry that Cyc allows paradox. It's >all too easy to define paradoxical stuff. Now, what effect that >would have on Cyc's theorem prover God only knows. There is a difference between contradictions in the language itself and contradictions in what someone says in the language. Any version of logic that supports negation will let you say (p & ~p). In fact, sometimes you might really want to say something like "I don't believe (p & ~p)." But we want to make sure that the structural framework of the language is sufficiently clean that (p & ~p) does not pop out of the woodwork when it shouldn't. With Cyc, we're never quite sure what might pop out of the woodwork. But I hope that we can make sure that the KIF framework doesn't harbor pesky rodents. John From andersen at ontologyworks.com Tue Nov 7 16:02:06 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:30:55 2003 Subject: Agenda for Nov.9 KIF teleconference References: <200011010022.SAA01527@philebus.tamu.edu> <3A06E02A.A669F8CB@cme.nist.gov> Message-ID: <3A087BDE.D66285B5@ontologyworks.com> Michael... Some questions Michael Gruninger wrote: > Proposals > > o KIF Metatheory What's the outline of what goes into this theory? I saw that this is one of the "open issues" but I'd like to get a flavor of the proposed contents to date... Is the "module" facility itself defined in terms of the metatheory... This is related to the truth predicate... > 14. Integrate a modern class-inheritance mechanism into the syntax Can you explicate this some more. If it means what I think it does (something like frames) then it's another (significant) extension to the core and ought to go under that bullet. Thanks ...bill -- Bill Andersen Chief Technology Officer - Ontology Works 1130 Annapolis Road, Suite 203, Odenton, MD 21113 andersen@ontologyworks.com / 410-674-7600 From gruning at cme.nist.gov Tue Nov 7 16:17:01 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:56 2003 Subject: Agenda for Nov.9 KIF teleconference References: <200011010022.SAA01527@philebus.tamu.edu> <3A06E02A.A669F8CB@cme.nist.gov> <3A087BDE.D66285B5@ontologyworks.com> Message-ID: <3A087F5D.79F4C805@cme.nist.gov> Bill Andersen wrote: > Michael... Some questions Hi Bill, these are great questions ... > > > > Proposals > > > > o KIF Metatheory > > What's the outline of what goes into this theory? I saw > that this is one of the "open issues" but I'd like to get > a flavor of the proposed contents to date... There are two documents floating around for KIF -- the KIF 3.0 manual and the KIF dpANS document (which has been referred to in earlier messages as KIF 98). The former document contains two chapters devoted to axiomatizing such notions as "function", "relation", "sentence". The latter document does not go into this much detail, but there is a section on "Metaknowledge". I personally have a preference for a very simple language (vanilla FOL, together with some way of specifying axiom schemae). In the work that I've done, I haven't had the need for any form of a metatheory within the language. The idea of the modular organization keeps the door open for more expressive possibilities. > > > Is the "module" facility itself defined in terms of the > metatheory... This is related to the truth predicate... There will need to be some facility for combining modules. Whether this is simply specified in the document or whether it is something that is expressible within the language is open for discussion. I personally have a preference for the former, but if you want the latter approach, then we would need some sort of truth predicate. > > > > 14. Integrate a modern class-inheritance mechanism into the syntax > > Can you explicate this some more. If it means what I think it > does (something like frames) then it's another (significant) > extension to the core and ought to go under that bullet. I will defer this to Pat (since he is the person who raised the issue), but I think that some of the later discussion, it was indeed proposed that this be included in an extension to the core. - michael From phayes at ai.uwf.edu Wed Nov 8 06:28:59 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:56 2003 Subject: Agenda for Nov.9 KIF teleconference In-Reply-To: <3A087F5D.79F4C805@cme.nist.gov> References: <200011010022.SAA01527@philebus.tamu.edu> <3A06E02A.A669F8CB@cme.nist.gov> <3A087BDE.D66285B5@ontologyworks.com> <3A087F5D.79F4C805@cme.nist.gov> Message-ID: > Bill Andersen: > > > > > 14. Integrate a modern class-inheritance mechanism into the syntax > > > > Can you explicate this some more. If it means what I think it > > does (something like frames) then it's another (significant) > > extension to the core and ought to go under that bullet. > >I will defer this to Pat (since he is the person who raised the issue), >but I think that some of the later discussion, it was indeed proposed >that this be included in an extension to the core. Yes, that is what it means. I raised this issue for several reasons. First, many folk in the 'ontology' community seem to think that object- or frame-oriented languages are the primary kind of ontological formalism. Both the emerging US and European 'standard' web-ontology languages (DAML and OIL) are object-based, as is the inter-ontology framework developed by the Stanford group. So it seems that KIF should at least pay attention to this, and one way to do so would be to incorporate some kind of OIL-like system into the language as away of specifying a sort or type heirarchy. Second, there seems to be an independent case for having the basic logic be sorted, and if we do decide to go this route then it seems like we ought to at least make the sorting machinery have some clear relationship to the OIL-type class declaration machinery. It is possible to describe OIL using an unsorted language (with equality), where all the classes map to unary predicates and all the properties to binary relations. Maybe KIF's attitude should be that this is the appropriate logical transcription of OIL (as is done indeed by OIL itself), in which case a class-heirarchy theory would simply be a KIF ontology (more strictly, it would be a kind of 'style sheet' for a class of KIF ontologies, I think, unless the basic core KIF has an axiom-schema mechanism built in.) But if the KIF core is to be sorted, then we ought to at least consider the possibility of integrating an OIL-type scheme into the sort specification machinery. I took a look at the Goedel language which John S. pointed out a while ago (there are some useful examples on the website which give the flavor.) This is basically a rigorously sorted first-order syntax of the kind which Chris gave us a semantics for a while ago. I worry however that this rather rigid kind of sorting (each argument place has a single well-defined sort in a tree-like sort heirarchy, no overloading or multiple inheritance) is too simple for realistic ontological use these days. And if we want to allow any kind of nonmonotonicity in the inheritance (which frame-oriented folk often seem to think of as a freebie) then we will need to be very careful about how we design the core. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Wed Nov 8 06:33:31 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:56 2003 Subject: No subject Message-ID: Folks, for a current perspective on where 'web ontologies' are at, take a look at http://ontobroker.semanticweb.org/ontos/ Pat Hayes --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Wed Nov 8 07:05:11 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:56 2003 Subject: Another note for KIF teleconference In-Reply-To: <4.2.0.58.20001107084242.01249820@pop.teknowledge.com> References: <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001101191029.01a4c760@pop.teknowledge.com> <4.2.0.58.20001102091305.01a8a270@pop.teknowledge.com> <4.2.0.58.20001107084242.01249820@pop.teknowledge.com> Message-ID: >> >>>[Adam] I'm afraid I'll sound a bit like a broken record on this >>>issue with the response "Cyc does it". Cyc has its flaws but if >>>we know Cyc has accomplished something then we have a good foil >>>against which to test our ideas. >>>Any parser which supports the language can ensure (1) if you need >>>to ensure syntactic well-formedness. >> >>[Pat] Yes, but that wasnt my point. I think we need to be able to >>quote things which are NOT well-formed. In fact,to be fully >>syntactically expressible, KIF should be able to quote (or >>otherwise describe) *any string whatever*, including for example >>'pieces' of Sexpressions. I don't think that Cyc has this ability. > >[Adam] Why would you want to be able to quote things which are not >well-formed? For several reasons. First, I might want to quantify over parts of a wellformed expression which are not themselves well-formed. For example, I might want to specify that anything of the form (PhysicalObject ?x) is false whenever the thing bound to ?x has a name *starting with* "Abstract#", or that any assertion in which the third argument of any relation with an "R" in its name is existentially quantified should be treated with suspicion. Second, I might want to refer to an expression in a different language and assert (in KIF) what it means in KIF. Third, I might (no, I do) want to be able to describe the syntax of a different language as an ontology in KIF with enough precision to be able to prove (in KIF) that a certain expression, or any one of a class of expressions, is well-formed in that other language. And I might want to be able to describe the syntax of an extension to the language in the basic language, and then say something in that extended language, and have something follow (in the base language) from that assertion (in the extended language) plus its description. >>>To address (2), Cyc has the type CycExpression. We can just >>>constrain arguments to be of type "expression". >> >>What about strings that arent expressions? What about things like >>'every relation name starting with "Physical..." '? What about >>wanting to be able to say "The meaning of '...' in DAML is ',,,' in >>KIF " ? > >The first example is the sort of string processing that I think >would be better accomplished in Perl or even Prolog. We shouldn't >be trying to create a programming language. Sorry, but I think your attitude to this is now impossibly out of date. Web ontology languages absolutely require that the ontology and the 'string processing' be integrated together. String processing in this sense is not a separate programming exercise: it is central to the ontology enterprise. The basic assertion is 'X written in language Y means Z (in this language)'. If KIF can't say things like this then it is useless. > The second example is easy to do in Cyc: > >(synonymousExternalConcept Animal SENSUS-Information1997 "ANIMAL") >or > (synonymousExternalConcept Inform-CommunicationAct >SENSUS-Information1997 "ASSERTIVE-ACT") Two things. First, assertions like this are (literally) meaningless in Cyc. They amount to comments, not real axioms. Second, even if they had any real force, they only allow one to establish symbol-to-symbol links between CYC names and other constant symbols, whereas I want to be able to describe an entire language, syntax and all. > >>I agree that the Cyc idea is often very convenient and handy >>(though I agree with John in wanting a bit more reassurance that >>one cannot reproduce paradoxes in CycL) but it isnt a >>general-purpose solution. > >Well, I don't want to put myself in the position of being an >apologist for Cyc but a lot of their solutions are eminently >practical. Theoretical problems like paradoxes should certainly be >addressed, but if there's no general solution, there is often an >engineering solution that works for all practical cases and allows >further progress to be made. There is a general solution, and indeed KIF 3.0 uses it very nicely. (WTR, used in ANSI-KIF, is a weaker version. I would opt for the more powerful 3.0 version.) > >>>However, this is one computer scientist's/engineer's simplistic >>>solution to a problem which may have significant implications for >>>the logical properties of the language. I don't know how hard the >>>logical implications of such a decision would be to handle. I >>>don't understand why we'd need to have the language itself handle >>>quoting other languages. That seems like an unnecessary >>>complication to me and a task better left to some text processing >>>code, not a logical language. >> >>This turns out to be centrally important once one starts dealing >>with 'web logics'. Think of ontologies as being first-class objects >>themselves, and the need to say in one language what is provable in >>an ontology written in a different language. True, this could be >>left to text processing code, but I think it would be a bad >>strategy to do so, since this kind of complication is likely to be >>norm in future rather than something exotic, and people will need a >>logical language to do it in, and if that is a different logic then >>that is the one which will get used. > >Another alternative would be to have text processing sorts of stuff >in another language that can coexist and interact with a compiled >logical language. This approach would be compatible with the sort >of thing that Bill and his colleagues are pursuing of having a high >level logical language which compiles down into prolog. You can >then write more "algorithmic" code in prolog. I should note that >this is also similar to what Cycorp does in practice. Knowledge >engineers write strictly in CycL. However, they have a lisp variant >called subL which implements the inference engine and can interact >with the declarative knowledge. If a Cyclist wants to manipulate >strings he or she can write some subL code to accomplish that and >then make the code "visible" to the declarative language as a >function. >I believe if we take the approach I'm proposing we'll have a much >simpler and cleaner declarative language which would still enable >system developers to make use of programming languages appropriate >for more procedural activities. OK, now show me the semantics for this 'simpler and cleaner' combination, where one can perform arbitrary computations on the 'upper' level strings in the 'lower' level language. It would be trivially easy to generate paradoxes, seems to me, and almost impossible to rule them out. In other words, they can't coexist without allowing the lower one to destroy the semantic integrity of the higher one. Trusting the semantic insight of system programmers isnt a viable solution. For example, its fine to compile down into Prolog, but if you then go on to hack the Prolog so that it can't be decompiled, then you arent using the same language any more. But surely, having a language with a semantics which is preserved by any implementation is the point of what we are trying to do here. If it is OK to hack around with the meanings in arbitrary code, then why do we need a standard ontology language? Let everyone implement their own favorite inference engine in C++. BTW, the point is not to *manipulate* strings, but to reason about them. Meta-description is one thing KIF got largely right, though I think it can be improved (as outlined in previous messages). It is also an area which has become centrally important in web ontologies. It seems a shame to throw it away and go back to the pragmatic confusion we would have been in about 20 years ago. Look, having meta-description in the language doesnt force anyone to use it. If you don't want to get involved in it, just ignore it. But if someone does want a secure, powerful general-pupose meta-description ability, and if we know how to do it (which I think we do), then why not put it in there? Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Wed Nov 8 07:06:20 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:56 2003 Subject: Another note for KIF teleconference In-Reply-To: <3a085164.6883.0@bestweb.net> References: <3a085164.6883.0@bestweb.net> Message-ID: >..... >But we want to make sure that the structural framework of >the language is sufficiently clean that (p & ~p) does not >pop out of the woodwork when it shouldn't. > >With Cyc, we're never quite sure what might pop out of the >woodwork. But I hope that we can make sure that the KIF >framework doesn't harbor pesky rodents. > >John I agree. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From sowa at bestweb.net Wed Nov 8 12:29:33 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:56 2003 Subject: Agenda for Nov.9 KIF teleconference Message-ID: <3a09a99d.15866.0@bestweb.net> Pat, Some comments on your comments: >KIF should at least pay attention to this, and one way to do so >would be to incorporate some kind of OIL-like system into the >language as away of specifying a sort or type heirarchy. Second, >there seems to be an independent case for having the basic logic be >sorted, and if we do decide to go this route then it seems like we >ought to at least make the sorting machinery have some clear >relationship to the OIL-type class declaration machinery. I agree. That is also why I incorporated the sorting machinery into the foundations of conceptual graphs. That means that any frame system can be mapped one-to-one into a subset of CGs, but the full CG system also accommodates much richer versions of logic, if one wants to use them. The option of specifying types on the KIF quantified variables was a syntactic technique for keeping track of which monadic predicates were intended to represent sorts and which variables were constrained by those predicates. But since KIF left that as a syntactic option, the conventions were not enforced when you translated CGs to KIF and back again. >I took a look at the Goedel language which John S. pointed out a >while ago (there are some useful examples on the website which give >the flavor.) This is basically a rigorously sorted first-order syntax >of the kind which Chris gave us a semantics for a while ago. I worry >however that this rather rigid kind of sorting (each argument place >has a single well-defined sort in a tree-like sort heirarchy, no >overloading or multiple inheritance) is too simple for realistic >ontological use these days. I agree. The Goedel typing is one step beyond KIF, but I would prefer a more general approach. > And if we want to allow any kind of >nonmonotonicity in the inheritance (which frame-oriented folk often >seem to think of as a freebie) then we will need to be very careful >about how we design the core. I am very suspicious of those freebies. I prefer to treat nonmonotonic reasoning as a kind of theory revision system. Each theory is expressed in classical FOL, and the nonmon effect is obtained by metalevel assert and retract statements, each of which is considered to generate a new theory in the lattice. Each assert specializes a theory, and each retract generalizes a theory. That is essentially what you get with Prolog-like negation as failure, but you can formalize assert and retract as commands for walking around the lattice of FOL theories. Each theory in the lattice has classical Tarski- style models, and there is a duality between theories and models: more axioms, fewer models; fewer axioms, more models. John Sowa From andersen at ontologyworks.com Wed Nov 8 13:49:08 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:30:56 2003 Subject: Agenda for Nov.9 KIF teleconference References: <3a09a99d.15866.0@bestweb.net> Message-ID: <3A09AE34.7CDBC796@ontologyworks.com> "John F. Sowa" wrote: > ? And if we want to allow any kind of > ?nonmonotonicity in the inheritance (which frame-oriented folk often > ?seem to think of as a freebie) then we will need to be very careful > ?about how we design the core. > > I am very suspicious of those freebies. I prefer to treat > nonmonotonic reasoning as a kind of theory revision system. > Each theory is expressed in classical FOL, and the nonmon > effect is obtained by metalevel assert and retract statements, > each of which is considered to generate a new theory in the > lattice. Each assert specializes a theory, and each retract > generalizes a theory. That is essentially what you get with > Prolog-like negation as failure, but you can formalize assert > and retract as commands for walking around the lattice of FOL > theories. Each theory in the lattice has classical Tarski- > style models, and there is a duality between theories and > models: more axioms, fewer models; fewer axioms, more models. John... This is an interesting idea, but I don't thing the NM problems can so simply be dissmissed by employing a metalogical device. You will just face the same problems in the metalogical level that you would face in the normal NML. Rephrasing the question to one of "commands for walking aroung the lattice of FOL theories" doesn't help determine what those commands ought to be. I'd rather push off talk of any specific NML until later. My personal bias is toward worrying about Ontology (big-O) which does not include Epistemology. IMHO you only need NML if you want to talk about epistemology. I think if we need a guiding principle to help us decide what topics to include in the KIF discussion and which to exclude, this principle is as good as any. ...bill From sowa at bestweb.net Wed Nov 8 18:55:44 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:56 2003 Subject: Another note for KIF teleconference Message-ID: <3a0a0420.2a99.0@bestweb.net> Pat and Adam, My recommendation is to have multiple microtheories or modules for representing many kinds of things, including the syntax of various languages. But the theory of KIF syntax could be expressed equally well in KIF or CGs or many other notations for logic. There is no reason why there should be a privileged relationship between the language KIF, when used to express theories, and any particular theory expressed in KIF (including the theory of KIF syntax itself). I would recommend that there be microtheories for expressing the syntactic structures of any language that one might find interesting, including XML, DAML, KIF, CGs, SUO-CE, etc. Any or all of those theories could be expressed in KIF, CGs, or many other versions of logic. But all of them should be included in separate modules that are outside the KIF core. If you want to use KIF to describe CGs, you could import the CG module as expressed in KIF into your KIF workspace (or context or whatever you call it). Similarly, you could import the KIF module as expressed in CGs into the CG workspace if you want to use CGs to represent KIF. A few comments: >>[Adam] Why would you want to be able to quote things which are not >>well-formed? > >For several reasons. First, I might want to quantify over parts of a >wellformed expression which are not themselves well-formed. For >example, I might want to specify that anything of the form >(PhysicalObject ?x) is false whenever the thing bound to ?x has a >name *starting with* "Abstract#", or that any assertion in which the >third argument of any relation with an "R" in its name is >existentially quantified should be treated with suspicion. Second, I >might want to refer to an expression in a different language and >assert (in KIF) what it means in KIF. Third, I might (no, I do) want >to be able to describe the syntax of a different language as an >ontology in KIF with enough precision to be able to prove (in KIF) >that a certain expression, or any one of a class of expressions, is >well-formed in that other language. And I might want to be able to >describe the syntax of an extension to the language in the basic >language, and then say something in that extended language, and have >something follow (in the base language) from that assertion (in the >extended language) plus its description. I agree completely. But I would like to be able to translate the KIF statements for describing KIF into CG statements for describing KIF. (The translation of KIF statements for describing KIF into CG statements for describing CGs is a very much different and far more difficult task.) >>The first example is the sort of string processing that I think >>would be better accomplished in Perl or even Prolog. We shouldn't >>be trying to create a programming language. > >Sorry, but I think your attitude to this is now impossibly out of >date. Web ontology languages absolutely require that the ontology and >the 'string processing' be integrated together. String processing in >this sense is not a separate programming exercise: it is central to >the ontology enterprise. The basic assertion is 'X written in >language Y means Z (in this language)'. If KIF can't say things like >this then it is useless. I agree. Furthermore, Prolog is an excellent tool for representing syntax, and every purely logical statement in Prolog can be translated one for one into KIF or CGs. BNF, for example, is just a special case of Horn-clause logic with a somewhat more specialized notation. >>>>I >>>>don't understand why we'd need to have the language itself handle >>>>quoting other languages. That seems like an unnecessary >>>>complication to me and a task better left to some text processing >>>>code, not a logical language. That is actually a very easy thing to do. As I said before, BNF is just a specialized subset of logic, representable in essentially the same way in KIF, Prolog, or CGs. >BTW, the point is not to *manipulate* strings, but to reason about them. Actually, there isn't much difference between manipulating and reasoning when you have a language like Prolog or KIF. A constructive proof that X can be translated to Y is identical in structure to a procedure for translating X to Y. A compiler, in fact, is just a special-purpose theorem prover. John Sowa From weltyc at cs.vassar.edu Wed Nov 8 22:25:15 2000 From: weltyc at cs.vassar.edu (Christopher A. Welty) Date: Fri Oct 10 03:30:56 2003 Subject: Another note for KIF teleconference In-Reply-To: <3a0a0420.2a99.0@bestweb.net> References: <3a0a0420.2a99.0@bestweb.net> Message-ID: All, I've been of course late in reading all this, just taking a look at it now in preparation for the call tomorrow, which I will also join late and leave early due to my daughter's birthday. There are a lot of issues on Mike's agenda, and it seems that given this group it's unreasonable to expect to get to them all. Of all the issues discussed by email, I'm really not clear on why people think KIF needs typing or support for subclassing? KIF in my understanding is not meant to be an implemented system with inference capabilities. Sorted quantification is a useful thing to have to simplify notation, to be sure, but I'm not sure why this or subtypes can't be expressed already. Alex Borgida has a paper on comparing the semantics and expressive power of description logics (OIL is a DL) to FOL on his web page at Rutgers. I recall the only difficult difference is in the ability to express cardinality for relations (at-least and at-most restrictions). However, the semantics is usually expressed with respect to the extension of the sets that correspond to DL concepts, it is difficult to represent the semantics of T-Box reasoning. I'm pretty familiar with SHOE as well and there's really not much to it logically, however it allows for what amounts to a belief predicate. -ChrisW ****NOTE NEW AREA CODE: Christopher A. Welty http://www.cs.vassar.edu/faculty/welty/ Vassar College Computer Science Dept. Voice: (845) 437-5992 Poughkeepsie, NY 12604-0462 Fax: (845) 437-7498 From sowa at bestweb.net Thu Nov 9 08:28:33 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:56 2003 Subject: Another note for KIF teleconference Message-ID: <3a0ac2a1.7be4.0@bestweb.net> Chris, There is a difference between purely syntactic support for sorts, such as the option in KIF'98, and a strong typing system, which takes advantage of typed or sorted variables in ways that have semantic implications. >Of all the issues discussed by email, I'm really not clear on why >people think KIF needs typing or support for subclassing? KIF in my >understanding is not meant to be an implemented system with inference >capabilities. Sorted quantification is a useful thing to have to >simplify notation, to be sure, but I'm not sure why this or subtypes >can't be expressed already. In KIF'98, it is possible to put a monadic predicate after a variable name in the quantifier: (forall ((?x string) (?y number) (?z expression)) But there is no corresponding constraint on the signatures of the predicates. Therefore, you can write (+ ?x ?y) and there is no error check. That is an example where the sorts can help to detect human errors. The semantic effect is even more important. For example, suppose you have a function named parse, which applies to strings and generates expressions, and another function named eval, which applies to expressions to generate results. Then you could write (eval (parse "(+ 2 2)") or (eval (+ 2 2)) but not (eval "(+ 2 2)") or (parse (+ 2 2)). You could also use strong typing to handle many of the issues that Pay Hayes discussed. For example, you might have a function named kif2ace, which translates a KIF expression to a controlled English expression in ACE. Then you could write (kif2ace (+ 2 2)) or (kif2ace (parse "(+ 2 2)")) The result of either one would be "two plus two" in ACE. But if you wrote (kif2ace (eval (parse "(+ 2 2)"))) the result would be "four" in ACE. Strong typing would allow the kif2ace function to take expressions as input without evaluating them. If you had a partial ordering of sorts, you could even have sorts such as KIFexpression or ACEexpression, which are subtypes of expression. There are also other theoretical issues, which Chris Menzel and I were discussing in earlier notes on the SUO list. In particular, it is possible to use a sorted FOL to represent HOL, if you allows sorts to represent sets of functions or predicates -- i.e., sorts whose denotations are truly nondenumerable sets. John Sowa From phayes at ai.uwf.edu Fri Nov 10 09:46:00 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:57 2003 Subject: Workshop dates In-Reply-To: <20001027141745.C13120@tamu.edu> References: <200010271814.LAA03958@puffin.rt.cs.boeing.com> <20001027141745.C13120@tamu.edu> Message-ID: Chris, I was unable to sleep after the telethon; the things you said worried me too much. Let me urge you to take a slightly broader view of the issues at stake here. I get the impression that you think of KIF as basically a first-order logic as specified in a logic textbook, and you use what might be called 'pure-logic' terminology to describe it. But this view of KIF just won't do; a usable interlingua for ontologies has to be much more than a textbook version of a deductive logic. It is more like a programming language in many ways. Think of the interlingua as not just being a language to express the logical content of some axioms, but as a notation in which everything that could possibly be relevant about a set of axioms can be asserted in a uniform way. That includes their logical content, but it also might include a lot of information about the ontology itself (who wrote it, in what language originally, whether it is complete, etc) and about its own structure (how its various nonlogical terminals are classified, limitations on the numbers of arguments allowed, whether or not it conforms to various syntactic specifications, etc.) In web logics, certainly, it seems that every ontology must have 'ontologies' in its ontology, if you see what I mean; because one of the first things an inference engine must be able to infer is that the ontology actually *is* an ontology, and so every DAML ontology has to say this explicitly. Just as we do not say that writing a program in LISP is an extension to the language itself, so the idea of 'language' which is being used here is one in which many ontologies can be written in the same language. It is an ontology (theory) which has a logical signature, not a language: the language only provides what might be called the grammatical frame within which the syntactic (actually lexical) form of the signature can be defined. (This is in fact the usage of 'language' throughout almost every academic discipline except a subset of formal logicians, and certainly as used throughout computer science. ) Secondly, at several points in the telecon you rather dismissed various matters as being not really part of the langauge proper, but belonging to the metalanguage. This attitude might be fine for logicians who are not overly concerned with proof theory in any case, but it won't do for KIF. For example, if KIF is to be sorted, it is not enough to just give a sorted model theory. We will need to decide on a notation which allows users to express every meaningful attribute of their ontologies, and if this includes assigning types or sorts to the vocabulary, then we need to invent a syntax *for the language itself* to allow them to do so. Think of programming languages, for example, and the need for a syntax for declarations. This can be done, of course; in fact there are many ideas around about how to do it. But it is not a task that can be delegated or dismissed, or indeed that should be undertaken lightly. Doing this well, and properly integrating it into the semantics, is going to be much more work than adding quasi-quotation and downward reflection (wtr), for example, both of which are relatively simple, thoroughly studied, and can be thought of as self-contained language extensions; but the sorting machinery will permeate every aspect of the language. Here are some of the issues. If (as someone suggested yesterday) the declarations are placed in a preamble (like ALGOL-60), then this means that a piece of KIF without a preamble will not be well-formed; that has many unfortunate consequences, notably for any ideas of merging ontologies or cross-using axioms from several ontologies. But if not, then we must provide a syntactic device in the language to specify sortals. Should sort mismatches be simply illegal, or should there be an automatic sort-restriction process? Can sorts be unified? Can any predicate be treated as a sort, or must the sortal predicates be specially declared? Can one infer that a predicate is a sort? Should sort restrictions be attached to the quantifiers or to the argument-places of relations, or both? Sorts form a heirarchy. What is the abstract form of this heirarchy? Is it a tree, a directed graph, a semilattice, or something even more exotic? (Cyc uses a semilattice, in effect.) Consider having sorts 'male' and 'female' and a binary relation 'married' which is well-sorted when its arguments are of different gender (ie its sort is (maleXfemale)U(femaleXmale)). Is this possible? How about the function 'plus' with sort ((integerXinteger->integer)U(integerXreal->real)U(realXinteger->real)U (realXreal->real)) ? What happens to 'plus' if someone later says something which has as a consequence that integer is a subclass of real? Does it become illegal, or is its sort now (realXreal->real)? Suppose we have A with sort S, and B with sort T, and suppose that S and T have a common subsort W; can we infer that if A(x) and B(x) then x has sort W? One can indeed look at languages like OIL as consisting almost entirely of 'class declarations', which is why I suggested that if we are going to move to a sorted language that such a modern class-heirarchy syntax (actually I think we can do better than OIL syntax) might be integrated with the sort-declaration machinery. But, to emphasise, this is *not* metatheory, and it cannot be dismissed as a minor matter. As an example of the kind of thing one needs to be able to do in even a minimal ontology language, take a look at the following , which are transcriptions of parts of DAML-0 (A pretty minimal and almost 'toy' ontology language) into ANSI-KIF, written a few days ago by Deborah McGuiness and Rich Fikes. The point of all this is that DAML has a notion of a 'property' (ie a binary relation) and provides the ability to say that a property has a 'maximum cardinality', which is an integer, meaning that for any X there are at most that many things Y such that P(X,Y). Note, this is *part of the language*, not a meta-assertion assertion (though it has a distinctly 'meta' flavor to someone with a logical training.) The KIF translation has to allow both assertions which USE a 'property' and those which assert things about its cardinality. Now read on: %% A "no-repeats-list" is a list for which no item occurs more than once. (<=> (no-repeats-list ?l) (or (= ?l (listof)) (= ?l (listof ?x)) (and (not (item (rest ?l) (first ?l))) (no-repeats-list (rest ?l))))) %% A "values-list" is the list of second arguments that a property has for a given first argument. Note that this formulation assumes a finite number of second arguments for a given property and first argument. (<=> (values-list ?p ?x ?ys) (and (Property ?p) (no-repeats-list ?ys) (forall ?y (<=> (holds ?p ?x ?y) (item ?ys ?y))))) "Item" means list-membership. %% A property has a "cardinality" n when for each first argument it can have n second arguments. (<=> (cardinality ?p ?n) (forall ?x (= (length (values-list ?p ?x)) ?n))) (The following is what DAML-0 looks like (Its based on RDF, which also looks this ugly:) for maxCardinality(P, N) read: P has maximum cardinality N; i.e. everything x in the domain of P has at most N things y such that P(x, y). %% "maxCardinality" is a property. (Property maxCardinality) %% The first argument of "maxCardinality" is a property. (Domain maxCardinality Property) %% The second argument of "maxCardinality" is a non-negative integer. (Range maxCardinality Number) (=> (maxCardinality ?p ?n) (and (integer ?n) (not (negative ?n)))) %% A property has a "maxCardinality" n when for each first argument it can at most n second arguments. (<=> (maxCardinality ?p ?n) (forall ?x (=< (length (values-list ?p ?x)) ?n))) ------ There is much more of it, but I thought this might give the flavor. (To see it all, search at http://www.ksl.stanford.edu/projects/daml ) Notice that they do not use lists here as a way to describe the KIF syntax, but as a way to axiomatise certain properties of the relations themselves, properties which have consequences for the well-formedness of DAML assertions. There is something very worrying (to me) about this example. First, it uses *centrally* aspects of KIF which we have relegated to future 'extensions', notably integers and lists. (They also use sequence variables, but that could be eliminated.). I am very worried that by restricting the 'core' to be a pure logic we might be making it effectively unusable in practice. I suspect that the ability to describe simple relationships on integers (maybe not full arithmetic) is a vitally important part of any core ontology language, since that language has to be able to talk about its own symbols well enough to be able to specify things like 'maxCardinality'. Providing a minimal expressive power to do this seems to require something like sequences and something like integer comparisons. Maybe we are being too cavalier (and oldfashioned) in thinking of these as 'nonlogical' and therefore not part of a Pure Core Language. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 9718 bytes Desc: not available Url : http://philebus.tamu.edu/pipermail/kif/attachments/20001110/824b773e/attachment.bin From cmenzel Fri Nov 10 10:40:35 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:30:57 2003 Subject: Workshop dates In-Reply-To: Your message of "Fri, 10 Nov 2000 15:46:00 GMT." Message-ID: > Chris, I was unable to sleep after the telethon; the things you said > worried me too much. Let me urge you to take a slightly broader view > of the issues at stake here. Pat, Quick reply. I'm sorry if I gave you (and perhaps others) this impression. I'm not sure what I said to convey it, but any narrowness in my view should be attributed only to the fact that I am not as familiar as you with the broader needs that KIF must address. I am also told that my ordinary conversational tone is a bit, err, direct, which might have given a doctrinaire ring to what were supposed only to be assertions about how I currently understand things -- with no normative implications whatever. I REALLY DON'T CARE how we do things -- sorted/unsorted, quotation/no quotation, higher-order/first-order, open-ended/strictly delimited, with programming-style constructs -- as long as things are clear and well-defined. Textbook first-order logic is just a model of how to proceed methodologically -- it's clarity, rigor, etc. I do not think of it as a model for KIF's final content. I will give you no resistance on this point. Now, get some sleep. ;-) Best, -chris From cmenzel Fri Nov 10 11:33:37 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:30:57 2003 Subject: Workshop dates In-Reply-To: Your message of "Fri, 10 Nov 2000 15:46:00 GMT." Message-ID: > I am very worried that by restricting the 'core' to be a pure logic > we might be making it effectively unusable in practice. I suspect > that the ability to describe simple relationships on integers (maybe > not full arithmetic) is a vitally important part of any core > ontology language, since that language has to be able to talk about > its own symbols well enough to be able to specify things like > 'maxCardinality'. Providing a minimal expressive power to do this > seems to require something like sequences and something like integer > comparisons. Maybe we are being too cavalier (and oldfashioned) in > thinking of these as 'nonlogical' and therefore not part of a Pure > Core Language. I think you are reading too much into the word "core", Pat. From my (and I think Michael's) perspective, this is a *purely architectural* term. It has no connotations of importance or priority. Many basic ontologies use no more than first-order logic with identity (and of course a bunch of extralogical predicates). It seems to me that it should be possible for people to look at a simple KIF "core" (or call it BASIC-FOL-KIF, or whatever) to find out how to write such ontologies without having to wade through all kinds of (for *their* purposes) unnecessary stuff about sorts, numbers, lists, etc. That's all I intend by having a core: a nice clear basic first-order part of KIF that doesn't overwhelm users who only want to express content. ALL the other stuff you are arguing for is good; all, or at least most, of it should be there in the VERY FIRST DRAFT that we put out. But why not PRESENT all of that in a way that shows it as explicit extensions to a basic "core" or (foundation, or whatever you want to call it)? Wouldn't that make things clear and make the whole package more accessible? In sum, though -- I do not believe I disagree with you about anything, Pat -- however, there are issues that are somewhat new to me that I simply don't fully understand yet, so I need to do some homework. But any resistance you might have sensed on my part was a reflection of that fact only. -chris From weltyc at cs.vassar.edu Fri Nov 10 12:27:37 2000 From: weltyc at cs.vassar.edu (Christopher A. Welty) Date: Fri Oct 10 03:30:57 2003 Subject: Workshop dates In-Reply-To: References: <200010271814.LAA03958@puffin.rt.cs.boeing.com> <20001027141745.C13120@tamu.edu> Message-ID: Pat, I don't envision "core KIF" as being something anyone will actually use. Personally I have been thinking about there being a likely set of standard extensions most people will use. Think of it as "core LISP", for example. At one time this was considered to be the smallest part of LISP you need to be able to express everything else. No one ever restricts themselves to only that part of it. -Chris ****NOTE NEW AREA CODE: Christopher A. Welty http://www.cs.vassar.edu/faculty/welty/ Vassar College Computer Science Dept. Voice: (845) 437-5992 Poughkeepsie, NY 12604-0462 Fax: (845) 437-7498 From cmenzel Fri Nov 10 13:02:25 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:30:57 2003 Subject: KIF Message-ID: Folks, a couple of quick notes I fired off to Pat; I forgot to cc: y'all. -chris ------- Forwarded Message To: pat hayes Subject: Re: Workshop dates In-Reply-To: Your message of "Fri, 10 Nov 2000 15:46:00 GMT." Date: Fri, 10 Nov 2000 10:40:35 -0600 From: Chris Menzel > Chris, I was unable to sleep after the telethon; the things you said > worried me too much. Let me urge you to take a slightly broader view > of the issues at stake here. Pat, Quick reply. I'm sorry if I gave you (and perhaps others) this impression. I'm not sure what I said to convey it, but any narrowness in my view should be attributed only to the fact that I am not as familiar as you with the broader needs that KIF must address. I am also told that my ordinary conversational tone is a bit, err, direct, which might have given a doctrinaire ring to what were supposed only to be assertions about how I currently understand things -- with no normative implications whatever. I REALLY DON'T CARE how we do things -- sorted/unsorted, quotation/no quotation, higher-order/first-order, open-ended/strictly delimited, with programming-style constructs -- as long as things are clear and well-defined. Textbook first-order logic is just a model of how to proceed methodologically -- it's clarity, rigor, etc. I do not think of it as a model for KIF's final content. I will give you no resistance on this point. Now, get some sleep. ;-) Best, -chris ********** To: pat hayes Subject: Re: Workshop dates Date: Fri, 10 Nov 2000 11:33:37 -0600 From: Chris Menzel > I am very worried that by restricting the 'core' to be a pure logic > we might be making it effectively unusable in practice. I suspect > that the ability to describe simple relationships on integers (maybe > not full arithmetic) is a vitally important part of any core > ontology language, since that language has to be able to talk about > its own symbols well enough to be able to specify things like > 'maxCardinality'. Providing a minimal expressive power to do this > seems to require something like sequences and something like integer > comparisons. Maybe we are being too cavalier (and oldfashioned) in > thinking of these as 'nonlogical' and therefore not part of a Pure > Core Language. I think you are reading too much into the word "core", Pat. From my (and I think Michael's) perspective, this is a *purely architectural* term. It has no connotations of importance or priority. Many basic ontologies use no more than first-order logic with identity (and of course a bunch of extralogical predicates). It seems to me that it should be possible for people to look at a simple KIF "core" (or call it BASIC-FOL-KIF, or whatever) to find out how to write such ontologies without having to wade through all kinds of (for *their* purposes) unnecessary stuff about sorts, numbers, lists, etc. That's all I intend by having a core: a nice clear basic first-order part of KIF that doesn't overwhelm users who only want to express content. ALL the other stuff you are arguing for is good; all, or at least most, of it should be there in the VERY FIRST DRAFT that we put out. But why not PRESENT all of that in a way that shows it as explicit extensions to a basic "core" or (foundation, or whatever you want to call it)? Wouldn't that make things clear and make the whole package more accessible? In sum, though -- I do not believe I disagree with you about anything, Pat -- however, there are issues that are somewhat new to me that I simply don't fully understand yet, so I need to do some homework. But any resistance you might have sensed on my part was a reflection of that fact only. -chris ------- End of Forwarded Message From sowa at bestweb.net Fri Nov 10 13:17:23 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:57 2003 Subject: Workshop dates Message-ID: <3a0c57d3.2d15.0@bestweb.net> Chris, Pat, et al., First, let me make a very shame-faced apology for missing the teleconference yesterday. There was something that I kept thinking that I was supposed to do yesterday, and I just realized this morning that it was that telephone call. That said, I can see from the notes that Pat was making a strong case for many of the things that I would have said. So let me endorse Pat's note below with some annotations to clarify, emphasize, or modify some of the details. >.... Let me urge you to take a slightly broader view of >the issues at stake here. I agree on the importance of these issues, even when I might seem to be differing on some of the details. >.... Think of the interlingua as not just >being a language to express the logical content of some axioms, but as >a notation in which everything that could possibly be relevant about a >set of axioms can be asserted in a uniform way. That includes their >logical content, but it also might include a lot of information about >the ontology itself (who wrote it, in what language originally, whether >it is complete, etc) and about its own structure (how its various >nonlogical terminals are classified, limitations on the numbers of >arguments allowed, whether or not it conforms to various syntactic >specifications, etc.) I very strongly agree. > In web logics, certainly, it seems that every >ontology must have 'ontologies' in its ontology, if you see what I >mean; because one of the first things an inference engine must be able >to infer is that the ontology actually *is* an ontology, and so every >DAML ontology has to say this explicitly. These are the kinds of things that KQML was supposed to do. But I remember asking Mike Genesereth why there was a need for KQML as a separate language instead of considering it as just an ontology expressed in metalevel KIF. Mike answered very simply: "It is purely a political issue. The people who are defining KQML want to design their own language instead of just designing an ontology to be expressed in KIf." Now that KQML has died a well-deserved death, I suggest that we make the point that metalevel KIF can do everything that KQML was intended to do plus a whole lot more. We will still need an ontology, and whatever ideas in KQML are still useful can be adapted to an ontology expressed in KIF. >Just as we do not say that writing a program in LISP is an extension to >the language itself, so the idea of 'language' which is being used here >is one in which many ontologies can be written in the same language. It >is an ontology (theory) which has a logical signature, not a language: >the language only provides what might be called the grammatical frame >within which the syntactic (actually lexical) form of the signature can >be defined. (This is in fact the usage of 'language' throughout almost >every academic discipline except a subset of formal logicians, and >certainly as used throughout computer science. ) I wholeheartedly agree. >Secondly, at several points in the telecon you rather dismissed various >matters as being not really part of the langauge proper, but belonging >to the metalanguage. This attitude might be fine for logicians who are >not overly concerned with proof theory in any case, but it won't do for >KIF. For example, if KIF is to be sorted, it is not enough to just give >a sorted model theory. We will need to decide on a notation which >allows users to express every meaningful attribute of their ontologies, >and if this includes assigning types or sorts to the vocabulary, then >we need to invent a syntax *for the language itself* to allow them to >do so. Think of programming languages, for example, and the need for a >syntax for declarations. This can be done, of course; in fact there are >many ideas around about how to do it. But it is not a task that can be >delegated or dismissed, or indeed that should be undertaken lightly. >Doing this well, and properly integrating it into the semantics, is >going to be much more work than adding quasi-quotation and downward >reflection (wtr), for example, both of which are relatively simple, >thoroughly studied, and can be thought of as self-contained language >extensions; but the sorting machinery will permeate every aspect of the >language. I agree. >Here are some of the issues.... I deleted the issues because there is too much to comment on in this note. But I agree with Pat's general approach. >One can indeed look at languages like OIL as consisting almost entirely >of 'class declarations', which is why I suggested that if we are going >to move to a sorted language that such a modern class-heirarchy syntax >(actually I think we can do better than OIL syntax) might be integrated >with the sort-declaration machinery. But, to emphasise, this is *not* >metatheory, and it cannot be dismissed as a minor matter. I agree. >As an example.... Good example. And I endorse the following observation about it: >There is something very worrying (to me) about this example. First, it >uses *centrally* aspects of KIF which we have relegated to future >'extensions', notably integers and lists. (They also use sequence >variables, but that could be eliminated.). I am very worried that by >restricting the 'core' to be a pure logic we might be making it >effectively unusable in practice. I agree. >Maybe we are being too cavalier >(and oldfashioned) in thinking of these as 'nonlogical' and therefore >not part of a Pure Core Language. I believe that we can do the same thing that Goedel and many modern programming languages do: define a very clean, simple core with metalevel techniques for importing modules. Some of the basic modules, such as integers and lists, must be available as "built-in" features, but they could be overridden by anybody that really felt a need to redefine integers. John Sowa From gruning at cme.nist.gov Mon Nov 13 09:30:49 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting Message-ID: <3A100929.286AD6AF@cme.nist.gov> Hello everyone, here is the draft of the minutes from the teleconference. My notes got a little sketchy at the end of the meeting, so if anyone can fill in the details, please send them to me. Also, if there is any issue that I missed or misrepresented, please send the changes to me, and I will pass on the official minutes to Adam Pease. I will try to setup another teleconference for this Friday (November 17) at 12:00 EST. Will this time be acceptable for everyone? - michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://philebus.tamu.edu/pipermail/kif/attachments/20001113/0e6dceb9/nov9minutes.html From apease at teknowledge.com Mon Nov 13 10:28:37 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <3A100929.286AD6AF@cme.nist.gov> Message-ID: <4.2.0.58.20001113082507.01291078@helium.teknowledge.com> Michael, These are excellent notes. They agree with my recollection except for #13. I would say that some members (although I wouldn't venture to say who other than myself), feel that the language should not be given features just to be able to describe the syntax of other languages or itself. I believe Pat Hayes took the opposite position that KIF should written so as to be able to describe the syntax of different languages. Adam At 10:30 AM 11/13/2000 -0500, Michael Gruninger wrote: >Hello everyone, >here is the draft of the minutes from the teleconference. >My notes got a little sketchy at the end of the meeting, so if anyone >can fill in the details, please send them to me. Also, if there is any >issue that I missed or misrepresented, please send the changes to >me, and I will pass on the official minutes to Adam Pease. > >I will try to setup another teleconference for this Friday >(November 17) at 12:00 EST. Will this time be acceptable for everyone? > >- michael > > > > >Minutes for KIF Standardization Meeting > > > > >November 9, 2000 >Participants: > >Pat Hayes, Chris Menzel, Adam Pease, Mark Stickel, Mike Uschold, Chris >Welty, Michael Gruninger > > > >Discussion > > > * Organize KIF into a KIF-Core and a set of modules. > > * In general, these issues raised a number of different points > concerning the nature of languages, lexicons (signatures), and theories. > > * Adam emphasized the need to distinguish the language of KIF from > ontologies that can be written in KIF. > > * The discussion centered on what it meant for something to be an > ``extension'' of KIF-Core. Chris Menzel identified two approaches to > defining extensions to the language: > * KIF-Core contains only one nonlogical symbol (=); all others are > introduced and axiomatized in extensions; > * The language of KIF-Core includes all possible relation symbols, > but only equality is axiomatized in the Core > Pat raised the issue of how to extend the language when building > ontologies. In particular, what is the syntax for declarations for new > symbols in the language? > > Chris responded by proposing that we define the notion of the language > of a "KIF theory", which would include a possibly empty set of predicates > (except for =), a possibly empty set of function symbols, and a possibly > empty set of constant symbols. > > The fundamental issue here is: > > What is the language of KIF, and how do we ensure extensibility? > > Adam saw three aspects to the language: > * BNF grammar > * axioms for the lexicon i.e. terminals of the grammar > * ontologies/theories > * Proposed extensions to KIF-Core > > * Adam expressed concerns that the modular organization of KIF could > lead to the balkanization of the standard. (Editor's note: This is my > wording, but I believe that it captures the danger that whenever > contentious issues arise, the proposed options will be treated as > different extensions rather than be resolved in a unified manner within > the standard.) The following general principle was proposed: > > * For any extension, we should be able to "back-translate" into the > KIF-Core. > > * Omit variadic relations and functions > > * The group agreed to adopt this proposal. > > * Omit sequence quantification > > * The group agreed to adopt this proposal. > > * Eliminate the identification of expressions with lists > > * The group agreed to adopt this proposal. > > * Allow case-sensitive identifier names > > * The group agreed to adopt this proposal. > > * Introduce a sorted language definition > > * The discussion of this feature revolved around whether it should be > included in KIF-Core, and also on how sorts should be incorporated into > the syntax. One proposal was that sorts could be a grammatical extension > to KIF-Core; the problem is that sorts complicate the grammar. > > * Mark Stickel and Pat Hayes both stressed the need of an additional > specification of the grammar for a sorted language rather than relying on > the mapping between sorted and nonsorted language. In particular, one can > take a non-well-formed formula in a sorted language and map it into a > well-formed formula in a nonsorted language. > > * Chris Menzel had earlier proposed an approach to sorted languages > based on Enderton. However, it was felt that this approach is too > simplistic for KIF. > > * Simplify and reorganize quotation > * The group agreed to table this issue for the workshop. > > * Retain the use of the truth predicate wtr, possibly within the > Metatheory Extension. > > * Editor's note: I can't remember what we said here ... > > * Change the syntax for definitional forms > > * The group agreed to adopt this proposal, although no new syntactic > constructs were proposed. Pat stressed the need for some syntactic > mechanism for pointing out definitions without the logical weight of the > definitional forms in the current KIF documents. > > * Introduce lambda expressions > > * The group agreed to table this issue for the workshop. > > * Allow general terms, including variables, to occur in the first > position of expressions (i.e. relations and functions need not be > constant symbols.) > > * Editor's note: I can't remember what we said here ... > > * Introduce expressions (not just KIF expressions, but arbitrary > expressions) as first-class entities, distinct from lists, and have a > reasonably powerful syntax-description ability using the language to > express BNF directly. > > * The group agreed tht we need the ability to describe languages and > their syntax. Ontologies can be written using this language extension; > the original KIF Metatheory would be one such ontology. > > * This feature (together with quotation) will be necessary to specify > axiom schemata > > * Integrate a modern class-inheritance mechanism into the syntax. > > * This issue will be tabled either to a later meeting or the workshop. > >Action Items > > > * Chris Menzel will identify options for addressing the issue of "What > is a language?" > * Identification of options for sorted languages. (I can't remember > who was going to do this). ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From stickel at AI.SRI.COM Mon Nov 13 17:10:56 2000 From: stickel at AI.SRI.COM (Mark Stickel) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <3A100929.286AD6AF@cme.nist.gov> (message from Michael Gruninger on Mon, 13 Nov 2000 10:30:49 -0500) Message-ID: <200011132310.PAA22571@Pacific.AI.SRI.COM> > Allow general terms, including variables, to occur in the first > position of expressions (i.e. relations and functions need not be constant symbols.) > > Editor's note: I can't remember what we said here ... I remember some of it. I questioned the idea because it complicates or precludes dispatching to special unification algorithms depending on the function or predicate symbol that heads the expressions. This lead to some further discussion of whether implementation issues like this should play a role in defining the language (yes/no/it depends). The matter was left undecided. While on this topic, I have further concerns about the idea of using general terms in the first position of expressions. 1. When considering the interpretation or semantics of logical expressions, the proposal apparently requires that the domain includes functions and relations. This is not customary for first-order logic and may require that otherwise universal statements be qualified to restrict the domain. 2. KIF core in particular should be as precisely specified and standard as possible. SUO KIF comes closes to this ideal in specifying a standard first-order logic. Generalizing heads of expressions seems operationally simple (although I already have some problems with that) but seems semantically nontrivial. In my opinion, 1. Generalized heads should not be in core KIF, but might be in an extension. 2. The semantics of the generalized head extension should be specified by something like the mapping (?R X Y) and (?F X Y) to (apply-predicate ?R X Y) and (apply-function ?F X Y). 3. It might be worth considering this only in the context of a sorted extension so that ?R and ?F range over predicates and functions but X and Y do not. From whitten at lynx.eaze.net Mon Nov 13 18:07:15 2000 From: whitten at lynx.eaze.net (David Whitten) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <200011132310.PAA22571@Pacific.AI.SRI.COM> from "Mark Stickel" at Nov 13, 2000 03:10:56 PM Message-ID: <200011140007.SAA19504@lynx.eaze.net> Mark Stickel stated: > While on this topic, I have further concerns about the idea of using > general terms in the first position of expressions. > > 1. When considering the interpretation or semantics of logical > expressions, the proposal apparently requires that the domain includes > functions and relations. This is not customary for first-order logic > and may require that otherwise universal statements be qualified > to restrict the domain. I would think that it depends on how 'universal' you expect your universal statements to be. I certainly know that when the domain includes a very large number of kinds of instances, that I am careful to state what subset of the Universe the statements are about. I know we have talked about functions and relations in the universe of Discourse, I have assumed that applications of functions are also in the universe and as well as lambda abstractions. (Because a lambda abstraction is a natural way of defining a function that 'computes' a recursively enumerable set, as a 'value' for the function symbol) If we choose not have these in the KIF core universe of discourse, I would hope that we specify how an extension to KIF-Core can 'increase the size' of the universe of discourse if it wants them. What are other alternatives commonly used to define functions by other logicians? > 2. KIF core in particular should be as precisely specified and > standard as possible. I agree that this is desirable. Is there a risk that 'my standard is better than your standard' when trying to formulate the KIF core? Will we be defining a logical model of interpretation for the KIF syntax? What about an operational model that is computationally tractable? > SUO KIF comes closes to this ideal in > specifying a standard first-order logic. I agree that as we pare the standard we can get closer to a 'purist logical syntax'. My concern is that we need to add definion/structure to avoid the problem of two people seeing the same expressions and reading them as meaning totally different things. This is one of the reasons I hoped we would be linking the syntax to some mathematical structures. Perhaps this is a harder task than I thought, because I didn't hear any discussion of this on the conference call. > Generalizing heads of expressions seems operationally simple > (although I already have some problems with that) > but seems semantically nontrivial. I agreed with Adam when he said that (holds ?R ?X ?Y) may be mechanically translated into (?R ?X ?Y), hence we are still as 'first order now' as we were with the 'holds' relation. > 1. Generalized heads should not be in core KIF, but might be in an > extension. > 2. The semantics of the generalized head extension should be specified > by something like the mapping (?R X Y) and (?F X Y) to > (apply-predicate ?R X Y) and (apply-function ?F X Y). I assume this is the back-translation you would expect to tie to the generalized head extension when converting its expressions into KIF-Core. Why did you chose 'apply-predicate' as opposed to 'holds' ? Is there a subtle distinction you are making that the back-translation doesn't have a truth value ? > 3. It might be worth considering this only in the context of a > sorted extension so that ?R and ?F range over predicates and functions > but X and Y do not. Why not? Are you not going to allow functions that take functions or predicates as inputs? What about functions whose result is a predicate or function? I appreciate your ideas, David Whitten From phayes at ai.uwf.edu Tue Nov 14 07:42:55 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <3A100929.286AD6AF@cme.nist.gov> References: <3A100929.286AD6AF@cme.nist.gov> Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 17477 bytes Desc: not available Url : http://philebus.tamu.edu/pipermail/kif/attachments/20001114/5c06cace/attachment.bin From sowa at bestweb.net Tue Nov 14 09:43:31 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting Message-ID: <3a116bb3.151fc.0@bestweb.net> This is another issue that is related to the question of making KIF a "strongly typed" language instead of making the type or sort declarations optional. Mark Stickel wrote: >> While on this topic, I have further concerns about the idea of using >> general terms in the first position of expressions. >> >> 1. When considering the interpretation or semantics of logical >> expressions, the proposal apparently requires that the domain includes >> functions and relations. This is not customary for first-order logic >> and may require that otherwise universal statements be qualified >> to restrict the domain. David Whitten wrote: >I would think that it depends on how 'universal' you expect your >universal statements to be. I certainly know that when the domain >includes a very large number of kinds of instances, that I am >careful to state what subset of the Universe the statements are about. If such declarations are required, the parser would know what kind of entity any particular variable might refer to. John Sowa From sowa at bestweb.net Tue Nov 14 10:19:51 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:57 2003 Subject: SUO: Starter Ontology Version 2 Message-ID: <3a117437.15b78.0@bestweb.net> Chris, There is a major difference between inconsistency/bugs in the data, inconsistency/bugs in the coding, inconsistency/bugs in the design, and inconsistency/bugs in the compilers used to generate the code. >For example, in most commercial systems I have worked on, the design has >included the potential for redundant/duplicate data - as well as >inconsistency across the data. As a result after a few years of use, almost >all the systems have had inconsistencies (where there is a family of >systems, this is even more true). The designers/programmers did not regard >these as bugs - as they usually did not lead to problems. For example, in >some cases, it was regarded as the inputters' responsibility to enter >reasonably correct data (this is particularly true of standing data) - and >to check it was OK on a reasonably frequent basis. These are examples of inconsistencies/bugs in the input data, which all programmers have learned to distrust, and every production program always checks the input syntax. Checking the input semantics is harder to do, and most databases end up with lots of inconsistencies. That is why DB constraint checking has been added to SQL and other systems. The seriousness of the inconsistencies/bugs and the potential for disaster increases as you go down the list. Inconsistencies or bugs in the coding is more serious than in the data. And the inconsistencies/bugs in the design are much more difficult and expensive to detect and fix than simple inconsistencies/bugs in the code. Finally, inconsistencies/bugs in the compilers are so potentially disastrous to everything in the system, that they are the first ones that have to be fixed. Microsoft, for example, is notorious for buggy code. But the only product they sell that is reasonably bug free is their C/C++ compiler. And the reason why it has been thoroughly debugged is that any bugs in it would percolate through every last one of their products. Fixing inconsistencies/bugs in the compiler is such a high priority task, that it takes precedence over everything else, including performance. That is one reason why Microsoft compilers are notorious for the poor performance of the run-time code. Basic point: Inconsistencies/bugs in KIF correspond to inconsistencies/bugs in the compilers: they can destroy everything else. Inconsistencies/bugs in the SUO correspond to inconsistencies/bugs in the application design: they can destroy every program based on them. John Sowa From weltyc at cs.vassar.edu Wed Nov 15 20:12:06 2000 From: weltyc at cs.vassar.edu (Christopher A. Welty) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <200011152249.QAA07353@lynx.eaze.net> References: <200011152249.QAA07353@lynx.eaze.net> Message-ID: > >Chris, do I see your position as one of favouring an extension that >provides a binding from KIF to XML, so XML will handle the syntax >and KIF will provide semantics for sentences after XML 'parses' them? Actually, no, I am ambivalent. I just don't understand *why* someone would want KIF to support syntax descriptions. That's been done. > >Is XML able to describe KIF's syntax?David Errr...well no. XML can only describe tagged languages. But that's not the point. If KIF were to be the basis of a web language, it would be a "tagged" version of KIF. -ChrisW ****NOTE NEW AREA CODE: Christopher A. Welty http://www.cs.vassar.edu/faculty/welty/ Vassar College Computer Science Dept. Voice: (845) 437-5992 Poughkeepsie, NY 12604-0462 Fax: (845) 437-7498 From phayes at ai.uwf.edu Thu Nov 16 04:07:51 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:57 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: References: <3A100929.286AD6AF@cme.nist.gov> Message-ID: >At 1:42 PM +0000 11/14/00, pat hayes wrote: >> >>Adam: >> >I would say that some members (although I wouldn't venture to say >>who other >than myself), feel that the language should not be given >>features just to be able >to describe the syntax of other languages >>or itself. I believe Pat Hayes took the >opposite position that >>KIF should written so as to be able to describe the syntax >of >>different languages. >> >>Yes, and I will argue for this very strongly. It might be in an >>extension, but if KIF does not have this ability then it is to all >>intents and purposes useless, and I for one will have no further >>use for it or interest in it, and will suggest that W3C ignore it >>and adopt a different standard logical framework. > >I simply do not understand this position, in particular from the >perspective of the W3C. As I said in the call, they already have >something for describing the syntax of languages - XML. Im not sure if I have the patience or ability to explain this in detail to the point where you will understand it. Can't you just accept that there are research agenda out there which you may not perfectly empathise with? Sigh. The point is not JUST to describe syntax (though even there I think that KIF plus quotation might actually be preferable to XML), but to provide a means to allow an ontology to refer to parts of other ontologies written in different languages. If one tries to take this view of ontology interaction seriously, one finds that the role of syntax description becomes much more integrated into the ontology itself than has been usual case in the past. It would be awkward and artifical to have a separate syntax-describing language, distinct from the ontology language. In any case, speaking now as an ontology axiom-writer, I not infrequently find it genuinely useful to be able to specify classes of axioms in terms of syntactic constraints on parts of the expressions involved. (CYC uses a similar trick, though in a rather more limited way, by including all its own symbols in its ontology.) This seems like a very handy device for an ontology language to have, and if it can be provided at little cost then what is the possible reason to not do so? Maybe one way to do it would be to incorporate XML into KIF, but I think that quasi-quotation would be a lot simpler and generally better. > Why should KIF do it? Why should it not? More constructively, because the Web logics *will* do it (in XML or otherwise) and so if KIF is to be relevant to them, as I think it should be as far as possible, it ought to accept this requirement and live up to it, rather than try to forbid it on some arbitrary grounds. > Describing syntax is notoriously difficult in a logical language. On the contrary, it is easy. In fact it is one of the few aspects of new-KIF which I think I can claim to have completely specified (in a previous email) in enough detail to satisfy anyone. The semantics of quasi-quotation were worked out by Quine about 30 years ago (and quasi-quotation itself is widely used by logicians, by the way.) What on earth are you thinking about here? (Added later. Maybe you are thinking about the difficulty of specifying that all strings are finite, which indeed would take us beyond conventional first-order logic. We are going to have a similar difficulty with integers and lists, of course. This overall issue is one we will have to discuss. The simplest position to adopt is that we should accept that our axiomatisations are not categorical, admit that our logic allows 'nonstandard' models with transfinite numbers, infinite lists and infinitely long character strings, and just live with this. I do not think it will be a realistic impediment to the actual use of these constructs in KIF.) > They are the wrong tool for that task. It's like using LISP to >write a context switch. Our job isnt to design a Krep language which satisfies some academic criteria of elegance, particularly when those criteria differ from campus to campus and go in and out of fashion. If people want to write context switches in LISP, then our job is to be able to express what they are saying, not to teach them better ways. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From cmenzel Thu Nov 16 08:03:18 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:30:58 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: Your message of "Thu, 16 Nov 2000 10:07:51 GMT." Message-ID: Folks, Make sure that Mark Stickel and Mike Genesereth are included in the cc: field of your workshop-related messages. I'm also including my CS colleague Tom Ioerger, who may also be joining us. -chris ***** Forwarded message ***** >From phayes@ai.uwf.edu Thu Nov 16 04:50:55 2000 Mime-Version: 1.0 X-Sender: phayes@mail.coginst.uwf.edu Date: Thu, 16 Nov 2000 10:07:51 +0000 To: "Christopher A. Welty" From: pat hayes Subject: Re: minutes for Nov 9 KIF meeting Cc: pat hayes , Michael Gruninger , mfu@redwood.rt.cs.boeing.com, apease@teknowledge.com, cmenzel@philebus.tamu.edu, chaudhri@ai.sri.com, sowa@bestweb.net, andersen@ontologyworks.com, rasmith@tamu.edu, fikes@ksl.stanford.edu, David Whitten >>[Adam wrote:] >> >I would say that some members (although I wouldn't venture to say >> >than myself), feel that the language should not be given >> >features just to be able >> >to describe the syntax of other languages or itself. >> >I believe Pat Hayes took the opposite position that >> >KIF should written so as to be able to describe the syntax >> >of different languages. >>[Pat responded:] >>Yes, and I will argue for this very strongly. It might be in an >>extension, but if KIF does not have this ability then it is to all >>intents and purposes useless, and I for one will have no further >>use for it or interest in it, and will suggest that W3C ignore it >>and adopt a different standard logical framework. >[Chris Welty wrote:] >I simply do not understand this position, in particular from the >perspective of the W3C. As I said in the call, they already have >something for describing the syntax of languages - XML. Im not sure if I have the patience or ability to explain this in detail to the point where you will understand it. Can't you just accept that there are research agenda out there which you may not perfectly empathise with? Sigh. The point is not JUST to describe syntax (though even there I think that KIF plus quotation might actually be preferable to XML), but to provide a means to allow an ontology to refer to parts of other ontologies written in different languages. If one tries to take this view of ontology interaction seriously, one finds that the role of syntax description becomes much more integrated into the ontology itself than has been usual case in the past. It would be awkward and artifical to have a separate syntax-describing language, distinct from the ontology language. In any case, speaking now as an ontology axiom-writer, I not infrequently find it genuinely useful to be able to specify classes of axioms in terms of syntactic constraints on parts of the expressions involved. (CYC uses a similar trick, though in a rather more limited way, by including all its own symbols in its ontology.) This seems like a very handy device for an ontology language to have, and if it can be provided at little cost then what is the possible reason to not do so? Maybe one way to do it would be to incorporate XML into KIF, but I think that quasi-quotation would be a lot simpler and generally better. > Why should KIF do it? Why should it not? More constructively, because the Web logics *will* do it (in XML or otherwise) and so if KIF is to be relevant to them, as I think it should be as far as possible, it ought to accept this requirement and live up to it, rather than try to forbid it on some arbitrary grounds. > Describing syntax is notoriously difficult in a logical language. On the contrary, it is easy. In fact it is one of the few aspects of new-KIF which I think I can claim to have completely specified (in a previous email) in enough detail to satisfy anyone. The semantics of quasi-quotation were worked out by Quine about 30 years ago (and quasi-quotation itself is widely used by logicians, by the way.) What on earth are you thinking about here? (Added later. Maybe you are thinking about the difficulty of specifying that all strings are finite, which indeed would take us beyond conventional first-order logic. We are going to have a similar difficulty with integers and lists, of course. This overall issue is one we will have to discuss. The simplest position to adopt is that we should accept that our axiomatisations are not categorical, admit that our logic allows 'nonstandard' models with transfinite numbers, infinite lists and infinitely long character strings, and just live with this. I do not think it will be a realistic impediment to the actual use of these constructs in KIF.) > They are the wrong tool for that task. It's like using LISP to >write a context switch. Our job isnt to design a Krep language which satisfies some academic criteria of elegance, particularly when those criteria differ from campus to campus and go in and out of fashion. If people want to write context switches in LISP, then our job is to be able to express what they are saying, not to teach them better ways. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From gruning at cme.nist.gov Thu Nov 16 10:01:21 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:58 2003 Subject: November 17 KIF meeting: Agenda Message-ID: <3A1404D1.53B3585@cme.nist.gov> Hello everyone, here is the contact information for tomorrow's (November 17) KIF teleconference at 12:00 EST. USA Toll Free Number: 888-787-0206 PASSCODE: 16626 LEADER: Michael Gruninger The agenda is a little more difficult to set than last time, since we dealt with all of the easy issues in the first telecon. There seem to be four outstanding issues that are generating the most discussion: 1. What do we mean by "language"? 2. How will KIF be organized into modules? This is related to the question "What constitutes an extension of KIF-Core?" 3. Sorted languages and KIF 4. The ability to describe the syntax of languages within KIF We will continue discussion of these issues in the telecon to help refine our ideas in preparation for the workshop. In particular, one outcome of this meeting should be a preliminary agenda for the workshop. - michael From andersen at ontologyworks.com Thu Nov 16 10:37:30 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:30:58 2003 Subject: November 17 KIF meeting: Agenda References: <3A1404D1.53B3585@cme.nist.gov> Message-ID: <3A140D4A.63FBAFA3@ontologyworks.com> Michael Gruninger wrote: > 2. How will KIF be organized into modules? > This is related to the question "What constitutes an extension of > KIF-Core?" Mike, Do you have in mind the mechanism for defining modules and an associated semantics, the contents of specific extensions, or both? ...bill -- Bill Andersen Chief Technology Officer - Ontology Works 1130 Annapolis Road, Suite 203, Odenton, MD 21113 andersen@ontologyworks.com / 410-674-7600 From apease at teknowledge.com Thu Nov 16 12:56:08 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:30:58 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: References: <3A100929.286AD6AF@cme.nist.gov> Message-ID: <4.2.0.58.20001116103542.012aae00@helium.teknowledge.com> Pat, Forgive me for arguing this point again a bit. I don't think that this is an issue of just a desire for academic elegance. We could make a KIF++ that could incorporate any number of facilities - regular expression matching from Perl, stacks from Forth etc. but we need a strong argument for why we'd want to do that. You believe that the strong argument for including syntax description features is so that KIF can say things about other ontology languages. I believe that's better handled in another language. One example I might give is a recent project where we had knowledge encoded in CycL, an inference module in Prolog and a Java-based module that took XML input. We used Prolog to convert CycL to XML. It wouldn't have made any sense to have a KR language perform that conversion. Adam At 10:07 AM 11/16/2000 +0000, pat hayes wrote: >>At 1:42 PM +0000 11/14/00, pat hayes wrote: >>> >>>Adam: >>> >I would say that some members (although I wouldn't venture to say who >>> other >than myself), feel that the language should not be given >>> features just to be able >to describe the syntax of other languages or >>> itself. I believe Pat Hayes took the >opposite position that KIF >>> should written so as to be able to describe the syntax >of different languages. >>> >>>Yes, and I will argue for this very strongly. It might be in an >>>extension, but if KIF does not have this ability then it is to all >>>intents and purposes useless, and I for one will have no further use for >>>it or interest in it, and will suggest that W3C ignore it and adopt a >>>different standard logical framework. >> >>I simply do not understand this position, in particular from the >>perspective of the W3C. As I said in the call, they already have >>something for describing the syntax of languages - XML. > >Im not sure if I have the patience or ability to explain this in detail to >the point where you will understand it. Can't you just accept that there >are research agenda out there which you may not perfectly empathise with? > >Sigh. The point is not JUST to describe syntax (though even there I think >that KIF plus quotation might actually be preferable to XML), but to >provide a means to allow an ontology to refer to parts of other ontologies >written in different languages. If one tries to take this view of ontology >interaction seriously, one finds that the role of syntax description >becomes much more integrated into the ontology itself than has been usual >case in the past. It would be awkward and artifical to have a separate >syntax-describing language, distinct from the ontology language. > >In any case, speaking now as an ontology axiom-writer, I not infrequently >find it genuinely useful to be able to specify classes of axioms in terms >of syntactic constraints on parts of the expressions involved. (CYC uses a >similar trick, though in a rather more limited way, by including all its >own symbols in its ontology.) This seems like a very handy device for an >ontology language to have, and if it can be provided at little cost then >what is the possible reason to not do so? Maybe one way to do it would be >to incorporate XML into KIF, but I think that quasi-quotation would be a >lot simpler and generally better. > >>Why should KIF do it? > >Why should it not? More constructively, because the Web logics *will* do >it (in XML or otherwise) and so if KIF is to be relevant to them, as I >think it should be as far as possible, it ought to accept this requirement >and live up to it, rather than try to forbid it on some arbitrary grounds. > >>Describing syntax is notoriously difficult in a logical language. > >On the contrary, it is easy. In fact it is one of the few aspects of >new-KIF which I think I can claim to have completely specified (in a >previous email) in enough detail to satisfy anyone. The semantics of >quasi-quotation were worked out by Quine about 30 years ago (and >quasi-quotation itself is widely used by logicians, by the way.) What on >earth are you thinking about here? > >(Added later. Maybe you are thinking about the difficulty of specifying >that all strings are finite, which indeed would take us beyond >conventional first-order logic. We are going to have a similar difficulty >with integers and lists, of course. This overall issue is one we will >have to discuss. The simplest position to adopt is that we should accept >that our axiomatisations are not categorical, admit that our logic allows >'nonstandard' models with transfinite numbers, infinite lists and >infinitely long character strings, and just live with this. I do not think >it will be a realistic impediment to the actual use of these constructs in >KIF.) > >>They are the wrong tool for that task. It's like using LISP to write a >>context switch. > >Our job isnt to design a Krep language which satisfies some academic >criteria of elegance, particularly when those criteria differ from campus >to campus and go in and out of fashion. If people want to write context >switches in LISP, then our job is to be able to express what they are >saying, not to teach them better ways. > >Pat > >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola, FL 32501 (850)202 4440 fax >phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From cmenzel Thu Nov 16 13:20:25 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:30:58 2003 Subject: languages, sorts, types, etc. Message-ID: Well, I started writing something that soon promised to be an exercise in excess regarding the syntactic structure of KIF. But it struck me that the basic ideas can be laid out rather quickly and painlessly, which I've tried to do here. (Though, having now written them up, I must admit they weren't quick; hopefully they are still painless.) This message reflects both last week's telecon discussion and subsequent rumination. I'm especially interested in reactions to the idea of combining sorting with type names in Section 5 below. 1 KIF core = FOL with identity I had suggested that we build upon the idea of a basic first-order KIF core, and that this core should be first-order logic with identity. Hence, the lexicon for the language would include only boolean operators, quantifiers, parens, variables, and the 2-place identity predicate. We would choose some standard axiomatization. Obviously, this language would not be useful for much of anything, but it does serve as a nice, simplest baseline language. 2 Tightly structured KIF languages A somewhat more flexible approach is to define a notion of a KIF language in general. The specification would be something like the following. We would start by defining the notion of an expression, and by delimiting disjoint classes of "words" that could be used to form variables, constants, and predicates. The LEXICON for a KIF language A lexicon for a KIF language consists of the following pairwise disjoint sets: * Boolean operators, quantifiers, parens * A denumerable set of variables (It is perhaps easiest just to let ::= ?) * A (possibly empty) set of words known as *constants*. * For each n, a (possibly empty) set of words known as _n-place function symbols_. * For each n other than 2, a (possibly empty) set of words known as _n-place predicates_. The set of 2-place predicates must at least contain the predicate `='. Basically, then, a KIF lexicon gives the signature of a KIF language. FOL with identity simply ends up being the smallest KIF language. Note that this specification does not allow the same word to serve as, e.g., both a constant and a predicate; that could of course be altered by loosening the disjointness restriction. A given choice of lexicon, of course, determines a KIF language, whose WFFs would be given by a BNF in the usual fashion. We could then say that the *KIF logical core* of a KIF language consists of the axioms of FOL relative to the language. Any additional axioms given for the nonlogical predicates and constants would then be considered a _theory_ of those predicates (or their intended denotations) based on the given KIF core. An ontology could thus be presented with the signature of its language and the corresponding axioms. Of course, it is trivial to extend any given ontology just by adding new constants or predicates and concomitant axioms. If we also follow Pat's advice and include certain further capacities to basic KIF, then we'd need to reserve more keywords, but that's easily done. This would also require a broader grammar, of course, since we'd have to specify precisely how all the extra apparatus functions syntactically. I call these languages "tightly structured because the role of each expression is precisely determined. I am partial to this approach, as it seems to me to provide a basis for clean, more easily managed ontologies. 3 Loosely structured KIF Pat suggested that we might want to retain the loose syntactic structure of the language in the current KIF document. In this language, basically, any word can serve as either a constant, predicate, or function symbol, and any "list" of them (i.e., an expression of the form "( ... )" counts as a well-formed expression. Hence, predicates and function symbols do not have any fixed arity. A feature of this approach is that there is only ONE KIF language (given the usual basic ASCII building blocks). This is doable, but dicey, I think. It requires that, semantically, we have a way of interpreting every expression `(E1 ... En)' as both a function symbol and a predicate. Hence, in classical logic, `(E1 ... En)', qua function term, must be assigned a value. To see why from a practical point of view, note that, on the loosely structured syntax in question, the expression `(R (E1 ... En))' can be treated as an atomic formula, and hence `(E1 ... En)' has to be treated as a functional term (here, the argument to `R'), where the value of `E1' is being applied to the values of `E2', ..., `En', respectively. Now, this gets especially dicey if `E1' is being treated only as a predicate in an ontology (i.e., it appears only as a predicate in the ontology's axioms). Unless we want to venture into the quagmire of free logic (which allows terms that have no denotation), we need a denotation for `(E1 ... En)' qua function term. But if `E1' indicates only a property or relation in the ontology, what sense does this make? Seems like we are forced to interpret `E1' as the null (hence as a partial) function, which in turn will either force us into free logic or else force us to include something like Bottom in our semantics to serve as a value for partial functions applied to objects outside their domains. But that raises a whole new raft of complications, some of which Pat has already alluded to. So I'm dubious about the idea of loosely structured languages, though I'd be happy to be convinced that the problems they engender are not onerous. However, I really do not any advantages of such languages over tightly structured languages. 4 Sorted Langauges This is mostly just a clarification. Some of Pat's comments on sorting suggest to me that some of us are operating with difference notions. Notably: > Can any predicate be treated as a sort, or must the sortal predicates > be specially declared? Can one infer that a predicate is a sort? On the approach to sorting I laid out in my note of a couple weeks ago, sorts are *not* predicates. They are more like syntactic colors that we use to paint constants and variables, and to mark the argument places of predicates. Now, of course, it is possible to introduce predicates corresponding to sorts: Let VAR be a variable of a given sort Sort; then we can extend our language with a 1-place predicate `SortalPred' of sort that (intuitively) is true of all and only instances of the corresponding type Type_Sort via the axiom `(forall (VAR) (SortalPred VAR))'. (As I noted in my earlier message, I think of sorts as syntactic entities, to each of which is assigned a corresponding type -- every variable of a sort S, in a given model, thus ranges over all and only entities of the corresponding type Type_S.) But I'm not sure we'd want to do this. What we *might* want to do is the following: 5 Predicates as arguments; Types as logical individuals One of the issues we will be facing is that of allowing predicates to appears as arguments to other predicates. It has always been a feature -- or perhaps better, an embarrassment -- of first-order logic that it does not distinguish between common nouns (notably, sortals) and adjectives; it just uses 1-place predicates for both. But, in ontology especially, we seem to want to *talk about* the classes, or types, indicated by common nouns directly -- notably such predicates as `instance-of' and `subclass-of'. And I think that this is the major motivation for wanting to allow predicates to occur as arguments to other predicates. Perhaps sorting provides a kind (or sort :-) of middle ground here. Suppose we introduce a *name* denoting the type associated with each sort, rather than a predicate, each such name being of sort TYPE. We could then explicitly introduce `instance-of' and `subclass-of' (or `subtype-of') predicates of sort and respectively (intuitively, IND is the sort corresonding to the type of individuals), and appropriate axioms for each sort name: where VAR_FOO is a variable of sort FOO, Foo the corresponding typename, and VAR_IND a variable of type IND, we have (forall (VAR_IND) (<=> (instance-of VAR_Ind Foo) (exists (VAR_FOO) (= VAR_IND VAR_FOO)))) With type names we can talk explicitly about types without extending the usual syntax of first-order languages by allowing predicates to occur in argument position. I'm assuming here that the type Ind corresponding to the sort IND subsumes everything the quantifiers can range over, and hence also the types. Thus, if TYPE is a sort, then on this approach there is a corresponding type name `Type', and hence it will follow that (instance-of Type Type). I don't think that this bit of self-instantiation would is problematic. We only get into trouble if we allow arbitrary conditions to define types; notably, if we place no restrictions on type definition, we have a type Russell such that (forall (?x_TYPE) (<=> (instance-of ?x_TYPE Russell) (not (instance-of ?x_TYPE ?x_TYPE)))) and hence, by universal instantiation, we have (<=> (instance-of Russell Russell) (not (instance-of Russell Russell))), a consequence generally regarded as an NGT (non-good thing). We are safe, I think, so long as we just just consider types to be closed under the usual boolean (and perhaps cylindrical) operations, and permit only them in the definitions of new types in terms of old. -chris From phayes at ai.uwf.edu Fri Nov 17 04:18:59 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:58 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <4.2.0.58.20001116103542.012aae00@helium.teknowledge.com> References: <3A100929.286AD6AF@cme.nist.gov> <4.2.0.58.20001116103542.012aae00@helium.teknowledge.com> Message-ID: >Pat, > Forgive me for arguing this point again a bit. I don't think that >this is an issue of just a desire for academic elegance. We could >make a KIF++ that could incorporate any number of facilities - >regular expression matching from Perl, stacks from Forth etc. but >we need a strong argument for why we'd want to do that. You believe >that the strong argument for including syntax description features >is so that KIF can say things about other ontology languages. Not exactly. It is so that KIF can say things about *expressions* in other languages (that for example a certain expression, or class of expressions in OIL means the same as a certain sentence or set of sentences in KIF); and also that it can refer to classes of KIF expressions, as for example in stating axiom schema. > I believe that's better handled in another language. > One example I might give is a recent project where we had >knowledge encoded in CycL, an inference module in Prolog and a >Java-based module that took XML input. We used Prolog to convert >CycL to XML. It wouldn't have made any sense to have a KR language >perform that conversion. Maybe not, though see below. But I was not thinking about an overall operation of converting one language into another or writing a translator, but allowing KIF to express propositions *about* expression in other ontologies written in other languages and their content *expressed in KIF*. The other ontology might for example contain millions of assertions, and one might be interested only in those that refer to the city of Boston. It wouldnt make sense to have to translate the entire database into KIF; better to be able to say in KIF, this is what I am interested in, and this is what it would look like in your language, and then rely on some other engine, running on some other website, to retrieve the information you want and send it to you. Now, you might respond that while this is all true, it is the business of something else to do the inter-translation. But KIF is supposed to be the interlingua, remember? If we have to go to something else to express the semantic content of the translation process, then KIF has been relegated to just another logic, and we are no further forward in having an ontology language which can support web-based transactions between ontologies. As I said, in this case I have no further interest in it. There are lots of versions of FOL out there and nothing much to choose between them, and the last thing we need is yet another notation for FOL. ------ Adam, Im not prepared to argue this point over and over again, since I do not have time and do not expect to be able to persuade you. Nor do I want to persuade you. Having a feature in a language does not entail that everyone is obliged to use it, but if a sizeable group of potential users want a feature (and that feature has already been adequately defined) then it seems both perverse and arrogant to continue to insist that it shouldnt be there just because you don't want to use it. It seems clear that your programming style (methodology) and the uses you have envisioned for this kind of feature would be best served by using some other language (for reaasons which I do not follow but have no particular interest in following since I do not share your assumptions and am interested in doing different things with this kind of feature.) The same is not true for me, however, and I know that it is not true for Time Berners-Lee, Dan Connolley and others at W3C. I would suggest that you take this matter up with them if you really want to convince the world to think in your way. Incidentally, I disagree with you that it wouldnt have "made sense" to use a KR language to perform that conversion. It might have been inefficient, but it wouldnt have been crazy. It certainly would have made sense to use a KR language to describe the effect of performing the conversion in such a way that conclusions could be drawn from it (Yes, I do want to be able to do that.) I do not think of the world as divided up into lots of little languages, each optimised for a particular use. KIF is supposed to be a general-purpose interlingua, and it needs to be usable by people who may not share your views about how programming languages are best used. In particular, it needs to be usable by people who want to have ontologies with a much more pervasive usage of multi-language description than has been normal up to now. And if we include quasi-quotation (which as I say has been a feature of logical languages for about 40 years and was invented by Quine for use in describing set theory) then KIF will be able to describe regular expression matching, stacks, lists and just about everything else that can be described in all your favorite programming languages. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Fri Nov 17 07:00:43 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:58 2003 Subject: languages, sorts, types, etc. In-Reply-To: <200011161920.eAGJKPf19556@philebus.tamu.edu> References: <200011161920.eAGJKPf19556@philebus.tamu.edu> Message-ID: Chris wrote: >1 KIF core = FOL with identity > >I had suggested that we build upon the idea of a basic first-order KIF >core, and that this core should be first-order logic with identity. >Hence, the lexicon for the language would include only boolean >operators, quantifiers, parens, variables, and the 2-place identity >predicate. We would choose some standard axiomatization. I think it would be better to provide a standard model theory and not commit to any particular axiomatization (though one could be provided for illustrative or pedagogic purposes). Mechanical inference systems are unlikely to use anything like a 'standard' axiomatization in any case. >Obviously, >this language would not be useful for much of anything, but it does >serve as a nice, simplest baseline language. It might look nice to you, but it seems to me to be completely useless. What is the point of carefully defining a 'base' language which is so designed that it is impossible to say anything in it, since it has no nonlogical vocabulary? This would be like a programming language in which it was forbidden to use any identifiers, so it is impossible to write any programs in it. I agree that something like this could be the 'simplest possible case' of a KIF axiomatisation, much as the null set is the simplest possible set. (But, to make my point again, there seems to be little use in defining a set *theory* in which the only set is the null set.) >2 Tightly structured KIF languages > >A somewhat more flexible approach is to define a notion of a KIF >language in general. The specification would be something like the >following. We would start by defining the notion of an expression, >and by delimiting disjoint classes of "words" that could be used to >form variables, constants, and predicates. > >The LEXICON for a KIF language > >A lexicon for a KIF language consists of the following pairwise >disjoint sets: > >* Boolean operators, quantifiers, parens > >* A denumerable set of variables (It is perhaps easiest just to let > ::= ?) > >* A (possibly empty) set of words known as *constants*. > >* For each n, a (possibly empty) set of words known as _n-place >function symbols_. > >* For each n other than 2, a (possibly empty) set of words known as >_n-place predicates_. The set of 2-place predicates must at least >contain the predicate `='. > >Basically, then, a KIF lexicon gives the signature of a KIF language. Now, how does a user of the language actually write all this down? If I want 'Boston' to be a constant symbol and 'Fred' to be a 3-place relation, what do I have to actually type in order to declare that this is my intention? Or do I have to say anything? Can I just use the symbols in this way and rely on something to figure out, from the fact that I write (Fred ?x ?y ?z) in an axiom somewhere, that Fred must be a three-place relation? Is it enough that a consistent assignment of arities to my vocabulary *exists*? (If we have a sorted logic then similar questions apply, but in spades.) >FOL with identity simply ends up being the smallest KIF language. >Note that this specification does not allow the same word to serve as, >e.g., both a constant and a predicate; that could of course be altered >by loosening the disjointness restriction. As a general matter of methodology, I think we should impose restrictions only where they are absolutely necessary. People are free to use a language in a more restricted way if they feel comfortable doing so, but it is impossible to use the language in a less restrictive way. Every restriction we impose is a potential burden to someone. >A given choice of lexicon, of course, determines a KIF language, whose >WFFs would be given by a BNF in the usual fashion. Yes, but we will need to specify this 'usual fashion' in detail. There are people on the standards committee who have never heard of BNF, remember :-) > We could then say >that the *KIF logical core* of a KIF language consists of the axioms >of FOL relative to the language. Any additional axioms given for the >nonlogical predicates and constants would then be considered a >_theory_ of those predicates (or their intended denotations) based on >the given KIF core. An ontology could thus be presented with the >signature of its language and the corresponding axioms. Of course, it >is trivial to extend any given ontology just by adding new constants >or predicates and concomitant axioms. Well, that depends a lot on how the signature is declared. Compare for examples declarations in programmming languages. If we say that the symbols have to be specified by some kind of declaration wrapper, then it is *not* trivial to add new vocabulary: the declarations have to be re-written and the new axioms have to be inserted into the new wrapper. For example, if two sets of axioms are stored in two files then just appending the files will result in an illformed KIF expression. >If we also follow Pat's advice and include certain further capacities >to basic KIF, then we'd need to reserve more keywords, but that's >easily done. This would also require a broader grammar, of course, >since we'd have to specify precisely how all the extra apparatus >functions syntactically. > >I call these languages "tightly structured because the role of each >expression is precisely determined. I am partial to this approach, as >it seems to me to provide a basis for clean, more easily managed >ontologies. > >3 Loosely structured KIF > >Pat suggested that we might want to retain the loose syntactic >structure of the language in the current KIF document. In this >language, basically, any word can serve as either a constant, >predicate, or function symbol, and any "list" of them (i.e., an >expression of the form "( ... )" counts as a well-formed >expression. Hence, predicates and function symbols do not have any >fixed arity. No, I did NOT suggest this. You have drawn two extreme cases, and there is a lot of territory in between. I explicitly suggested not allowing variable-arity relations and functions. However, I do think that there is no harm in allowing the same name to be used for two different syntactic roles. Since the role can be determined from the syntax, there is no real ambiguity here, and someone might want to make use of this kind of punning. I also think that there is no need to impose a rigid sort hierarchy, but that (as in current KIF) we can allow it to be inferred from the axioms themselves. One possibility we should consider is distinguishing between actual restrictions on the language (violations of which are illegal) and some 'recommended practice' conventions (on which some parsers might rely in practice, even though that would make them strictly non-compliant). For example, it might be recommended practice to use an initial upper-case letter for relations and lower-case for individual constants, say. >A feature of this approach is that there is only ONE KIF >language (given the usual basic ASCII building blocks). > >This is doable, but dicey, I think. It requires that, semantically, >we have a way of interpreting every expression `(E1 ... En)' as both a >function symbol and a predicate. Hence, in classical logic, `(E1 >... En)', qua function term, must be assigned a value. Er..Im not sure what the problem is here, since in conventional logic every such expression DOES have a value (which may be a truth-value, but is still a value). In fact, classical type theory treats everything - relations, propositional connectives and even quantifiers in some versions - as a function. (I'm not suggesting we go this route, only that it illustrates that this isn't an incoherent or difficult idea.) > To see why >from a practical point of view, note that, on the loosely structured >syntax in question, the expression `(R (E1 ... En))' can be treated as >an atomic formula, and hence `(E1 ... En)' has to be treated as a >functional term (here, the argument to `R'), where the value of `E1' >is being applied to the values of `E2', ..., `En', respectively. Now, >this gets especially dicey if `E1' is being treated only as a >predicate in an ontology (i.e., it appears only as a predicate in the >ontology's axioms). Two points to make here. First, the current KIF 'style' of implicit typing would say that if you use an expression of the form '(R (E1 ... En))' then you are implicitly asserting that the subexpression is of the appropriate sort for the the property to apply to. So if 'E1' is being treated as a predicate, then it must be the case that R is being asserted of a truthvalue. (And the current semantics says that if it isn't, then the whole expression is simply false.) Second point, I don't see why it is "dicey". >Unless we want to venture into the quagmire of >free logic (which allows terms that have no denotation), we need a >denotation for `(E1 ... En)' qua function term. But if `E1' indicates >only a property or relation in the ontology, what sense does this >make? It either denotes true or it denotes false. And I think we are going to have to venture into the 'quagmire' (you know, Chris, you sound like an old lady who is afraid of getting her hem dirty, which is comical when you are talking to people who wear wellies) since we have to allow recursive definitions, so we will have to allow that sometimes our terms may fail to denote. My earlier point about needing to have a proper treatment of 'bottom' wasnt meant to imply that we could avoid having 'bottom', it was meant to point out that the current KIF treatment of it doesnt work properly. > Seems like we are forced to interpret `E1' as the null (hence >as a partial) function, which in turn will either force us into free >logic or else force us to include something like Bottom in our >semantics to serve as a value for partial functions applied to objects >outside their domains. But that raises a whole new raft of >complications, some of which Pat has already alluded to. KIF has been with that raft for years. I don't think these are new complications, and I think we are going to have to deal with them. >So I'm dubious about the idea of loosely structured languages, though >I'd be happy to be convinced that the problems they engender are not >onerous. However, I really do not any advantages of such languages >over tightly structured languages. I think you have muddled a number of issues together, among them. 1. Do we want explicit declarations for the vocabulary? 2. How complicated should the domains be allowed (or required) to be? 3. How do we deal with expressions which (intuitively) lack a denotation? and we can be more or less "loose" on these independently from the others. >4 Sorted Langauges > >This is mostly just a clarification. Some of Pat's comments on >sorting suggest to me that some of us are operating with difference >notions. Notably: > > > Can any predicate be treated as a sort, or must the sortal predicates > > be specially declared? Can one infer that a predicate is a sort? > >On the approach to sorting I laid out in my note of a couple weeks >ago, sorts are *not* predicates. They are more like syntactic colors >that we use to paint constants and variables, and to mark the argument >places of predicates. A perfect example of the kind of academic nicety which is likely to be incomprehensible to a lay user, and serves no useful purpose other than to keep the metatheory 'neat'. > Now, of course, it is possible to introduce >predicates corresponding to sorts: Let VAR be a variable of a given >sort Sort; then we can extend our language with a 1-place predicate >`SortalPred' of sort that (intuitively) is true of all and only >instances of the corresponding type Type_Sort via the axiom `(forall >(VAR) (SortalPred VAR))'. (As I noted in my earlier message, I think >of sorts as syntactic entities, to each of which is assigned a >corresponding type -- every variable of a sort S, in a given model, >thus ranges over all and only entities of the corresponding type >Type_S.) But I'm not sure we'd want to do this. I think it would be *essential* to do this. For example, it is in general impossible to express a most general unifier without having the ability to generate sortal assertions to express the restrictions on sorts produced during unification. But in any case, the identification of sorts with predicates is widespread and extremely natural, and it would be crazy to forbid it artifically. I would like to be able to *infer* that a certain predicate is a sort (for example on criteria which arise from indictive reasoning over a large corpus) and then as a consequence of that inference, have it treated as a sort by the 'sort machinery' (if there is any). So if the language is a sorted logic then, as a minimal requirement, it must be possible for the sort heirarchy to allow the creation of new sorts without changing the language. This is easy if sorts are simply a category of predicate. >What we *might* want to do is the following: > >5 Predicates as arguments; Types as logical individuals > >One of the issues we will be facing is that of allowing predicates to >appears as arguments to other predicates. It has always been a >feature -- or perhaps better, an embarrassment -- of first-order logic >that it does not distinguish between common nouns (notably, sortals) >and adjectives; Hey, wait a minute. Those are linguistic classifications, not ontological ones. I will oppose any attempt to make KIF more like English. > it just uses 1-place predicates for both. But, in >ontology especially, we seem to want to *talk about* the classes, or >types, indicated by common nouns directly -- notably such predicates >as `instance-of' and `subclass-of'. We want to be able to talk about the classes, but that has nothing to do with common nouns. In general, we ought to be able to 'talk about' (predicate properties of) anything that is denoted by a symbol in the language, seems to me, unless there is a very strong reason to the contrary. >And I think that this is the >major motivation for wanting to allow predicates to occur as arguments >to other predicates. It might be one, but it isn't the only one. We must resist the temptation to make KIF into a kind of tutorial device to force the rest of the world to adopt our ontological (still worse, philosophical) viewpoint. > >Perhaps sorting provides a kind (or sort :-) of middle ground here. >Suppose we introduce a *name* denoting the type associated with each >sort, rather than a predicate, each such name being of sort TYPE. Oh God, why make things this complicated? Now we have predicates AND sorts AND types, all ontologically distinct, for no good reason. Three ways of saying the same thing, distinguished only by theoretical criteria which one needs a graduate education to even appreciate. Surely if this stuff belongs anywhere, it is in an ontology of 'types'. KIF should be capable of expressing such an ontology, but not have it built into its very fabric. For example, maybe you could have a predicate on predicates called 'is-sortal' and an axiom: (forall (?x)(=> (is-sortal ?x) (exists (?y)(and (is-type ?y) (forall (?z)(<=> (?x ?z)(has-type ?z ?y))))))) which if you Skolemize it will provide you with a very handy function from sorts (considered as a sort of predicate) to types. (Ive deliberately omitted 'holds' in the above axiom.) >We >could then explicitly introduce `instance-of' and `subclass-of' (or >`subtype-of') predicates of sort and >respectively (intuitively, IND is the sort corresonding to the type of >individuals), and appropriate axioms for each sort name: where VAR_FOO >is a variable of sort FOO, Foo the corresponding typename, and VAR_IND >a variable of type IND, we have > >(forall (VAR_IND) > (<=> (instance-of VAR_Ind Foo) > (exists (VAR_FOO) > (= VAR_IND VAR_FOO)))) > >With type names we can talk explicitly about types without extending >the usual syntax of first-order languages by allowing predicates to >occur in argument position. But we want to do this for independent reasons; and if do allow this, then there is no need to 'introduce' types since they can be cleanly and directly axiomatised in the language itself. > I'm assuming here that the type Ind >corresponding to the sort IND subsumes everything the quantifiers can >range over, and hence also the types. Thus, if TYPE is a sort, then >on this approach there is a corresponding type name `Type', and hence >it will follow that (instance-of Type Type). I don't think that this >bit of self-instantiation would is problematic. I agree. Most ontological heirachies have a loop at the top (what else are you going to do?) >We only get into >trouble if we allow arbitrary conditions to define types; notably, if >we place no restrictions on type definition, we have a type Russell >such that > >(forall (?x_TYPE) > (<=> (instance-of ?x_TYPE Russell) > (not (instance-of ?x_TYPE ?x_TYPE)))) > >and hence, by universal instantiation, we have > >(<=> (instance-of Russell Russell) > (not (instance-of Russell Russell))), > >a consequence generally regarded as an NGT (non-good thing). Actually I think that particular conclusion is harmless, since it is simply a contradiction, so by modus tollens we can conclude that the original forall axiom is also a contradiction. If someone goes and asserts a contradiction then they must reap their own whirlwind. See below. > We are >safe, I think, so long as we just just consider types to be closed >under the usual boolean (and perhaps cylindrical) operations, and >permit only them in the definitions of new types in terms of old. Apart from the fact that I don't want 'types'in the langauge, this raises a basic issue of language design which we need to address more generally. The current design philosophy of KIF is that it is indeed 'unsafe' in the sense that one can define paradoxical concepts; but the resulting flexibility is worth the possible risk, and that any 'paradoxical' assertions are the responsibility of the user to avoid. Now, this kind of stance goes against the long tradition in FOM work in logic, since it provides no guarantees of internal consistency; and it was the search for such guarantees which was the chief motivational factor for early work in formal logic. But we are not doing foundational work here, but rather trying to produce a broadly useful interlingua; and I think that the 'user beware' (Caveat Orator, ie its up to whoever asserts the axioms to do so consistently) principle is a reasonable stance to adopt. Of course, if the logic were capable of *generating* paradoxes by performing inferences from a nonparadoxical assertion (as an unrestricted comprehension inference scheme would be, or a Russell-vulnerable axiom in naive set theory) then this wouldn't be acceptable, since nobody using the language could be sure that inconsistencies might not arise at any moment; but our proposed language has no such comprehension principles or lambda-abstracting power: it is strictly first-order, and the only predicates in its universe are those which would be (denoted by terms in) in the first-order Herbrand universe, so provided that nobody says anything crazy in it, it will stay sane by itself. A stronger position to take it that it should be foolproof in the sense that it should be impossible for a user to make a paradoxical assertion. This is rather hard to manage, however, since it is impossible to prevent a sufficiently bone-headed user from asserting a contradiction, and if we allow them to also make definitions then just defining B to mean (not B) creates a paradox right there; so simple propositional logic isn't foolproof in this sense. (Which, by the way, is one reason we probably will have to step into the free-logic quagmire. Hey, a little mud is good for you. Programming lanugage designers have been wallowing around here for years.) Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From sowa at bestweb.net Fri Nov 17 07:55:36 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:58 2003 Subject: languages, sorts, types, etc. Message-ID: <3a1546e8.3ef4.0@bestweb.net> Pat and Chris, I agree with Pat on all the essential points. FOL+EQ is useless unless you have enough metalevel operators to define your nonlogical vocabulary. Once you open those gates, you have to let in an awful lot of other stuff that people have come to expect in a modern programming language. KIF may not be a programming language, but it must support the ontology that is being represented in every programming language -- and it must therefore support development tools that are compatible; i.e., if somebody imports the XML syntax module into Java, C++, Perl, Python, etc., they will need some way to specify the ontology of what those XML tags are going to represent. And it would be very convenient to have a 1-to-1 mapping with the modules that support those definitions in KIF. Some other comments (>> for Chris, and > for Pat): >>... We would choose some standard axiomatization. > >I think it would be better to provide a standard model theory and not >commit to any particular axiomatization (though one could be provided >for illustrative or pedagogic purposes). Mechanical inference systems >are unlikely to use anything like a 'standard' axiomatization in any >case. I agree with Pat. The only axiomatization that I consider a reasonable candidate for being "standard" is the empty set. That is the axiomatization for Peirce's rules, Gentzen's natural deduction, resolution theorem provers, and other systems. Everything else is in the rules of inference, which I believe we have already decided not to put in the standard. >It [basic FOL+EQ] might look nice to you, but it seems to me >to be completely useless. I agree. You must include at least the ability to define things, to import packages (modules) of definitions, etc. >I would like to be able to *infer* that a certain predicate is a sort >(for example on criteria which arise from indictive reasoning over a >large corpus) and then as a consequence of that inference, have it >treated as a sort by the 'sort machinery' (if there is any). So if >the language is a sorted logic then, as a minimal requirement, it >must be possible for the sort heirarchy to allow the creation of new >sorts without changing the language. This is easy if sorts are simply >a category of predicate. I agree. And you can help the system "infer" that a predicate P is being used as a sort by writing it in the quantifier field; e.g., (forall ((?x P)) ...). >Hey, wait a minute. Those are linguistic classifications, not >ontological ones. I will oppose any attempt to make KIF more like >English. I agree. I am proposing something like ACE as an English-like language that can be easily translated into KIF. Syntactic sugar in KIF does not facilitate that translation. >We want to be able to talk about the classes, but that has nothing to >do with common nouns. In general, we ought to be able to 'talk >about' (predicate properties of) anything that is denoted by a symbol >in the language, seems to me, unless there is a very strong reason to >the contrary. Yes. I would rather write (P ?x) than (instance-of ?x P). >Oh God, why make things this complicated? Now we have predicates AND >sorts AND types, all ontologically distinct, for no good reason. I agree. I don't want special treatment for predicates such as IND for individual. If I want to say ?x is an instance of P, I don't want to write (instance-of ?x P). I just want to write (P ?x). And if I want to refer to an individual, I define a variable ?x. I don't want to declare it (IND ?x). All ontological assumptions should be kept out of KIF. At this point, I hereby make a global declaration of "I agree" to the remainder of Pat's comments. John Sowa From sowa at bestweb.net Fri Nov 17 08:18:30 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:58 2003 Subject: minutes for Nov 9 KIF meeting Message-ID: <3a154c46.47b5.0@bestweb.net> Adam and Pat, I mostly support Pat on this issue, but I would like to give a somewhat different explanation of the reasons. Consider Adam's example: >> One example I might give is a recent project where we had >>knowledge encoded in CycL, an inference module in Prolog and a >>Java-based module that took XML input. We used Prolog to convert >>CycL to XML. It wouldn't have made any sense to have a KR language >>perform that conversion. There is a difference between performing the conversion and making assertions or reasoning about it. In KIF, for example, we can write (+ 2 2) and let a theorem prover that uses Peano's axioms plus lots of definitions of constants deduce the value 4. However, that level of detail is usually unnecessary, since many theorem provers are able to call an attached procedure that evaluates (+ 2 2) to give 4 by using the underlying hardware/software system. Exactly the same techniques that are used to support the + function can be used to support translation functions such as CycL2XML. What you might use KIF to do, however, is to state what it means to translate one expression in CycL to another expression in XML and finally to a true KIF expression. In order to do that, you need to be able to talk about expressions and languages, even though you might not use KIF to "compute" the actual results. John Sowa From sowa at bestweb.net Fri Nov 17 08:54:17 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:58 2003 Subject: minutes for Nov 9 KIF meeting Message-ID: <3a1554a9.5407.0@bestweb.net> Pat's bottom line says it all: >So the question I would ask is, can one describe XML in KIF? And if >not, there would be something wrong with KIF. John Sowa From phayes at ai.uwf.edu Fri Nov 17 09:03:05 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:58 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: References: <200011152249.QAA07353@lynx.eaze.net> Message-ID: >>Chris, do I see your position as one of favouring an extension that >>provides a binding from KIF to XML, so XML will handle the syntax >>and KIF will provide semantics for sentences after XML 'parses' them? > >Actually, no, I am ambivalent. I just don't understand *why* >someone would want KIF to support syntax descriptions. That's been >done. Syntax descriptions have been done (though I think that XML will not turn out to be the final word in this area.) But what hasnt been done (and what DAML eg aims to attempt) is to have a language which can describe how content relates to syntax. There is more to this than parsing. (BTW, I cant help noting that FOL has been done as well, probably more times than syntax descriptions. None of what we are doing is really *new* in any deep sense.) >>Is XML able to describe KIF's syntax?David > > >Errr...well no. XML can only describe tagged languages. But that's >not the point. If KIF were to be the basis of a web language, it >would be a "tagged" version of KIF. A tagged version might be required just in order to be XML-compliant, but that would be highly artificial and shouldnt be imposed on the rest of the user community. More to the point, however, even if we assume 'tagged KIF', could XML describe the relevant 'parts' and classes? For example, can one specify in XML a generalisation over all XML expressions with tags containing a certain substring? The problem with almost all these 'syntax languages', seems to me, is that they are only capable of describing well-formed substructures (by their own criteria of wellformedness), whereas quasi-quotation is a completely general-purpose device which can describe any syntax which can be expressed as a sequence of characters. It is precisely the lack of structural assumptions which makes quasi-quotation so useful. It refuses, as it were, to move in the HTML->XML->RDF direction of increasingly 'structured' descriptions, and sticks with the view of an expression as a linear string, relying on the descriptive power of the ontology to express whatever syntactic (or other) structure might be required. This open-endedness is just what we want in a 'reference' ontolingua. So the question I would ask is, can one describe XML in KIF? And if not, there would be something wrong with KIF. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From gruning at cme.nist.gov Fri Nov 17 11:54:53 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:59 2003 Subject: Quotation Message-ID: <3A1570ED.4206C2D3@cme.nist.gov> -------------- next part -------------- An embedded message was scrubbed... From: pat hayes Subject: Re: KIF teleconference Date: Thu, 26 Oct 2000 16:43:55 -0500 Size: 10338 Url: http://philebus.tamu.edu/pipermail/kif/attachments/20001117/d9faaed0/attachment.eml From mfu at redwood.rt.cs.boeing.com Fri Nov 17 13:10:43 2000 From: mfu at redwood.rt.cs.boeing.com (Michael Uschold) Date: Fri Oct 10 03:30:59 2003 Subject: Some rough minutes/notes of todays telecon Message-ID: <200011171910.LAA08174@puffin.rt.cs.boeing.com> FYI: These are rough and ready scribbled notes taken during todays telecon, which reflects my understanding of what was discussed. PH: Pat hayes CM: Chris Menzel JS: John Sowa MU: Mike Uschold MG: Michael Gruninger AP: Adam Pease MS: Mark Sticklen CW: Chris Welty --------------------------------------------------------------- 1. What do we mean by "language"? --------------------------------------------------------------- (non question...we're all happy, actually) JS all agree that there should be simple, limited core plus meta level to do things like assert, ... Meta kif: kif core plus builtin set of meta stuff. These operators can talk abojut what goes into another kif module. PH also need ability to describe other languages. --------------------------------------------------------------- 2. How will KIF be organized into modules? This is related to the question "What constitutes an extension of KIF-Core?" --------------------------------------------------------------- --------------------------------------------------------------- 3. Sorted languages and KIF --------------------------------------------------------------- PH: votes for UNsorted core, but with ready ability to describe sorted things. Can describe as predicate, but cannot enforce argument place validity. Can say whether well-sorted, can even prove it, but cannot enforce it - i.e. prevent someone from writing ill-formed expression and catch at parsing level. Why: can extend to sorted anyway want sortal machinery to be translatable back to unsorted. can get core done quicker (KIF 98 ok) Have sorts: --> can have polymorphism. But this imposes HEAVY burden on implementers CM: do we know what we mean by sorted language? KIF98: gives basic definition of sorts. CM: not really sorted, just syntactic sugar, no semnantic change. JS: Next level: sorts tied to variables, and so are predicate places. Like COLORING. May or may not be a unary predicate for each sort. One way to translate back to First Order, but there are other ways. Side Issue: JS: extensional or intensional? PH and CM: extensional JS: true by intension if have same name. Semantics: are different from First Order. Break class into subclasses. predicates generally not pertain to the whole universe, but just the elements of the domain for the argument places. Order-sorted: general agreement that we want this, along with inheritance. PH: Many people think order-sorted logics have built-in machinery, i.e. some predicates have special status which get handled in special way. e.g. subtype, instance, restriction-to, ... CLEAR PROPOSALS? 1. UNsorted core, but with ready ability to describe sorted things. Can describe as predicate, but cannot enforce argument place validity. Can say whether well-sorted, can even prove it, but cannot enforce it - i.e. prevent someone from writing ill-formed expression and catch at parsing level. No type-theoretic semantics. Let simple extension let predicates be arguments, along with semantics. MS: Interesting idea: punning... extension says let puns have ontological force. Call it relations-as-indivuduls, or predicates-as-argments, or no-punning, or the Stickel-extension. Have unrestricted syntax, but in core have no semantic constraints. Kind of an accidnet that the P as predicate is same as P as constant. In an extension, it is no longer an accident. TODO: write this up, (CM was volunteered). PH wants extensional theory of types to follow. 2. Order-Sorting: need subtype predicate. PH: Sorts can't just be predicates, but something else too, but what, exactly? Maybe talk about name of predicate, rather than predicat. CM: hesitates, worried about referring to the language. Often problematic,BUT it might work and if it does, go for it. JS: likes this idea of associate with name. Different names implies different predicats, by default. --- WHAT DO DO FOR THE ACTUAL MEETING? --------------------------------------------------------------- 4. The ability to describe the syntax of languages within KIF --------------------------------------------------------------- Features needed to support this: To what extent to we need to support this? JS: if we have good operators for KIF(meta), can probably do what we need for any other syntax. PH already solved the problem in an email, one new character. A good quotation mechanism. KIF vs MetaLevel KIF AP: not want meta-level stuff in KIF core, not sure why. Just want plain First-Order Logic, not the extra gunk. SUOKIF: min requires: Want simple language, with simple extensions. Want to be able to do nice things that I can do in CycL now, not worried about deep scientific principles, but is simple, clean and pragmatic. The complexity comes from the ontological definitions. No confusion, as there were in early versions of KIF with all the ontological stuff there and otehr facilities too. JS: wants meta-level assertions, To explicitly say "I am asserting X". Editing is a meta-level assertion. Need to be able to say we are using theory X and theory Y, this is meta-level. CM/PH: not need to explicitly say I am asserting, just hand off the ontology and that means these are asserted. General agreement to be clear about what is meta-level vs what is object level. want to be able to do belief revision. Current KIF not do this well, need an extension in the core (Sowa). First log in: no assertion, but do have metalevel tools, e.g editor tool, which does asserting. Need to be able to say want to use this editor or that, also translate character string into kif expression, copy this module into that module - primitieve meta-level operations. MU: why need to formalize what editor does? JS: META level KIF defines API for kif. JS: Ability to HAVE meta-level needs to be in core. But the metalevel stuff can be in an extension. PH: current KIF-meta stuff may be adequate insome sense, but probably/possibly not the best way to do it. TODO: make a list of the kinds of meta-level operations that we want. (JS?) * translate * assert/retract * rename * procedural attachments... * - here is stuff in XML, want to say XML tags have formal definition. JS nearly comes for free, with quasi-quote CW: this may best be thought of as 'Ontology Management Software'. Need quotation mechanism to do this. Punch line: General agreement about need for meta-stuff, substantially in an extension. Not total agreement on how central the meta stuff is? JS: Python has XML parser defined in Python, but terribly inefficient. It serves role of saying what actualy happens, but need to go to, say C implementation to actually do the work. PH: but, is this visible to the logic? Much of this is orthogonal to the logic, so let's move on! ======================================== ======================================== AGENDA IDEAS: KIF-meta extension Sorted Languages Starting point for SUOKIF: * SUOKIF * KIF98, divided up into parts... like chapters... but more loosely coupled Need to be simple, becuae otehrwise it never gets actually IMPLEMENTED! JS: must make this available as open source. AP: agrees to deliver this for something very like current SUOKIF. AP: concerned about some things, e.g. quasi-quotation... Possible danger: people use quasi-quotation as substitute for true higher order things. Then can't exchange. GOOD POINT! Disagreement - whether to include meta stuff in the core SUOKIF. MU: but anytime yo have optoins to use some modules and not other ones, then inter-operability suffers to the extent that people use different sets of modules. I see this as a potentially BIG ISSUE! JS need to be able to relate to other languages, to do this requires meta-level stuff. Division between KIF and SUOKIF: =============== From apease at teknowledge.com Fri Nov 17 17:52:27 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:30:59 2003 Subject: purpose of quoting In-Reply-To: <200011161403.eAGE3I318456@philebus.tamu.edu> References: Message-ID: <4.2.0.58.20001117154333.01aa8a88@helium.teknowledge.com> Folks, In the last part of the telecon today, after Pat left, I realized the possible cause of some of the disagreement about the quoting issue. I think at least part of this comes from different assumptions about what the language should be for. 1. Mike Gruninger and I stated that we though SUO-KIF should be a language to support the IEEE Standard Upper Ontology effort. SUO-KIF was conceived as a language to support the specification of terms and axioms which comprise an upper ontology and which are suitable for knowledge based inference. 2. John Sowa, Chris Menzel, (and presumably Pat although he was not on the telecon at the time) conceived of a language for knowledge interchange. This was at least part of the original purpose of KIF. As an interchange language, it makes a lot of sense to have the language be able to "talk about" other languages. The consensus that I think we wound up with is that we need a core which serves #1 and an extension which serves #2. We'd need an explicit directive to folks that are writing KIF for purpose #1 not to use the facilities in #2. Folks who were on the telecon at the time may wish to elaborate or correct this. My apologies in advance for any errors in attribution. Adam ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From stickel at AI.SRI.COM Fri Nov 17 17:56:36 2000 From: stickel at AI.SRI.COM (Mark Stickel) Date: Fri Oct 10 03:30:59 2003 Subject: Quotation In-Reply-To: <3A1570ED.4206C2D3@cme.nist.gov> (message from Michael Gruninger on Fri, 17 Nov 2000 12:54:53 -0500) Message-ID: <200011172356.PAA27641@Pacific.AI.SRI.COM> Pat, Do you envision multiple levels of quotation or only a single level? Using different opening and closing brackets like ^( and ^) would support the former, but be unnecessary for the latter. If single level quotation would suffice, then couldn't we just using the standard string quote " to bracket them, and specify the behavior for substrings beginning with ?. I.e., "A ?X B" would be equivalent to (concatenate "A" ?X "B"). What if the variable in a quotation is unbound, or bound to something other than a string? From weltyc at cs.vassar.edu Fri Nov 17 19:50:55 2000 From: weltyc at cs.vassar.edu (Christopher A. Welty) Date: Fri Oct 10 03:30:59 2003 Subject: purpose of quoting In-Reply-To: <4.2.0.58.20001117154333.01aa8a88@helium.teknowledge.com> References: <4.2.0.58.20001117154333.01aa8a88@helium.teknowledge.com> Message-ID: At 3:52 PM -0800 11/17/00, Adam Pease wrote: >2. John Sowa, Chris Menzel, (and presumably Pat although he was not >on the telecon at the time) conceived of a language for knowledge >interchange. This was at least part of the original purpose of KIF. >As an interchange language, it makes a lot of sense to have the >language be able to "talk about" other languages. Being an interchange language does not require being able to describe other languages - it only requires that knowledge represented in other languages be expressable in KIF. It's like compilation vs. interpretation in programming languages. I've been thinking of KIF as the assembly language that other KR languages compile into, not a language in which interpreters are written. I also don't understand why (those who do) want KIF to have the ability to support ontology management functionality. This just does not seem to me to be "core" functionality. I think the basic problem, as someone said on the phone, is that we all have different expectations. These should be revealed. Pat said, e.g., "If KIF can't describe the syntax of other languages, I'm going to tell Berners-Lee to ignore it." But Pat, why do you want to describe syntax in KIF? Do you mean something different by "describing syntax" than I and others do? >The consensus that I think we wound up with is that we need a core >which serves #1 and an extension which serves #2. I hope those of us on this side are not being stubbornly purist about this, but if we all have different purposes in mind for KIF (or SUO-KIF), it seems to me the core should be the intersection of what we need, not the union. I think the same must hold true for the SUO itself. -ChrisW ****NOTE NEW AREA CODE: Christopher A. Welty http://www.cs.vassar.edu/faculty/welty/ Vassar College Computer Science Dept. Voice: (845) 437-5992 Poughkeepsie, NY 12604-0462 Fax: (845) 437-7498 From sowa at bestweb.net Fri Nov 17 20:25:29 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:59 2003 Subject: purpose of quoting Message-ID: <3a15f6a9.f3e3.0@bestweb.net> Chris W wrote: >Being an interchange language does not require being able to describe >other languages - it only requires that knowledge represented in >other languages be expressable in KIF. It's like compilation vs. >interpretation in programming languages. I've been thinking of KIF >as the assembly language that other KR languages compile into, not a >language in which interpreters are written. It all depends on what parts of the ontology you're trying to describe. By definition, the SUO will include the most general supertypes of all the categories that anyone might want to implement, talk about, program about, or even think about. While specifying airplanes and computer circuits, it will have to specify the programs that guide those airplanes and the operations of those circuits. That means that KIF will have to be able to describe data structures, logic circuits, decoders, sequencers, and all their possible combinations. In other words, it will have to be able to specify a Turing machine or any language that can simulate a Turing machine or interpret the specifications of a Turing machine. That is not a big deal, because FOL can indeed specify a Turing machine. So we won't need any functionality beyond what is already in the FOL core. >I also don't understand why (those who do) want KIF to have the >ability to support ontology management functionality. This just does >not seem to me to be "core" functionality. When I am writing a program in the "core" subset of C, C++, Java, Python, or whatever, one of the first things I do is to write some import statements that load the independently compiled modules or packages that will be referenced by the statements in my current module. An import statement seems to be a rather basic feature that is needed in KIF. I agree that it is a metalevel statement, but calling it "ontology management functionality" makes it sound far more difficult than it really is. >>The consensus that I think we wound up with is that we need a core >>which serves #1 and an extension which serves #2. > >I hope those of us on this side are not being stubbornly purist about >this, but if we all have different purposes in mind for KIF (or >SUO-KIF), it seems to me the core should be the intersection of what >we need, not the union. I think the same must hold true for the SUO >itself. Predicates like define, assert, and import are used in metalevel statements about how KIF statements are going to be used. We have already agreed that there will indeed be metalevel mechanisms for defining, asserting, and importing KIF statements and groups of statements. That facility will have to be expressed in some language. Instead of inventing a new language, such as KQML, the simplest approach is to use the one we already have, namely KIF. Using KIF as that metalevel language does not add any new tasks that would not otherwise need to be done, and it provides function that can be very useful for a wide range of tasks that are typically performed by KR languages (including CycL). John Sowa From weltyc at cs.vassar.edu Fri Nov 17 22:38:45 2000 From: weltyc at cs.vassar.edu (Christopher A. Welty) Date: Fri Oct 10 03:30:59 2003 Subject: purpose of quoting In-Reply-To: <3a15f6a9.f3e3.0@bestweb.net> References: <3a15f6a9.f3e3.0@bestweb.net> Message-ID: At 10:25 PM -0400 11/17/00, John F. Sowa wrote: >Chris W wrote: > >>Being an interchange language does not require being able to describe >>other languages - it only requires that knowledge represented in >>other languages be expressable in KIF. It's like compilation vs. >>interpretation in programming languages. I've been thinking of KIF >>as the assembly language that other KR languages compile into, not a >>language in which interpreters are written. > >It all depends on what parts of the ontology you're trying >to describe. By definition, the SUO will include the most >general supertypes of all the categories that anyone might >want to implement, talk about, program about, or even think >about. While specifying airplanes and computer circuits, it >will have to specify the programs that guide those airplanes >and the operations of those circuits. That means that KIF will >have to be able to describe data structures, logic circuits, >decoders, sequencers, and all their possible combinations. >In other words, it will have to be able to specify a Turing >machine or any language that can simulate a Turing machine >or interpret the specifications of a Turing machine. Isn't this a little ambitious? > >That is not a big deal, because FOL can indeed specify a >Turing machine. So we won't need any functionality beyond >what is already in the FOL core. That FOL can specify a Turing Machine and for that matter that a Turing Machine can specify a control system for an airplane is not the point. the point is these are the wrong tools for doing that. Tools for specifying Turing machines exist. Tools for specifying control systems exist. Tools for specifying syntax exist. I don't see why KIF should try to be all those things. In fact, such a goal is precisely the opposite of what I thought we were after with "SUO-KIF-core". I believe there is a group of us who envision the core as being very minimalist. > >>I also don't understand why (those who do) want KIF to have the >>ability to support ontology management functionality. This just does >>not seem to me to be "core" functionality. > >When I am writing a program in the "core" subset of C, C++, >Java, Python, or whatever, one of the first things I do is >to write some import statements that load the independently >compiled modules or packages that will be referenced by the >statements in my current module. You may perform this operation, but it is not part of the core of any of these languages. I'm not saying we don't want this capability in practice, just that it isn't in the core! > >>The consensus that I think we wound up with is that we need a core >>>which serves #1 and an extension which serves #2. >> >>I hope those of us on this side are not being stubbornly purist about >>this, but if we all have different purposes in mind for KIF (or >>SUO-KIF), it seems to me the core should be the intersection of what >>we need, not the union. I think the same must hold true for the SUO >>itself. > >Predicates like define, assert, and import are used in >metalevel statements about how KIF statements are going >to be used. We have already agreed that there will indeed >be metalevel mechanisms for defining, asserting, and >importing KIF statements and groups of statements. > >That facility will have to be expressed in some language. >Instead of inventing a new language, such as KQML, the simplest >approach is to use the one we already have, namely KIF. Using >KIF as that metalevel language does not add any new tasks that >would not otherwise need to be done, and it provides function >that can be very useful for a wide range of tasks that are >typically performed by KR languages (including CycL). Hmmmm. Uh oh. Hmmmm. This makes sense. -ChrisW ****NOTE NEW AREA CODE: Christopher A. Welty http://www.cs.vassar.edu/faculty/welty/ Vassar College Computer Science Dept. Voice: (845) 437-5992 Poughkeepsie, NY 12604-0462 Fax: (845) 437-7498 From cmenzel Sun Nov 19 10:28:07 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:30:59 2003 Subject: purpose of quoting In-Reply-To: Your message of "Fri, 17 Nov 2000 23:38:45 EST." Message-ID: > In fact, such a goal is precisely the opposite of what I thought we > were after with "SUO-KIF-core". I believe there is a group of us who > envision the core as being very minimalist. > ... > >When I am writing a program in the "core" subset of C, C++, > >Java, Python, or whatever, one of the first things I do is > >to write some import statements that load the independently > >compiled modules or packages that will be referenced by the > >statements in my current module. > > You may perform this operation, but it is not part of the core of any > of these languages. I'm not saying we don't want this capability in > practice, just that it isn't in the core! Chris, I think you and John might be talking at cross purposes here. As Adam pointed out in Friday's telecon -- perhaps after you left the call -- the KIF core (which will at least be a large subset of SUO-KIF) is only part of the goal of our workshop. The focus is full KIF standardization, which will include the core and a variety of modules that increase its expressive power, and in particular make it more suitable for ontology interchange and, more generally, more suitable for use in the development of a "semantic web". The features Pat and John are talking about are all part of the full language. I believe everyone envisions the core as being rather minimilist. > [John wrote:] > >Predicates like define, assert, and import are used in > >metalevel statements about how KIF statements are going > >to be used. We have already agreed that there will indeed > >be metalevel mechanisms for defining, asserting, and > >importing KIF statements and groups of statements. > > > >That facility will have to be expressed in some language. > >Instead of inventing a new language, such as KQML, the simplest > >approach is to use the one we already have, namely KIF. Using > >KIF as that metalevel language does not add any new tasks that > >would not otherwise need to be done, and it provides function > >that can be very useful for a wide range of tasks that are > >typically performed by KR languages (including CycL). > > Hmmmm. Uh oh. Hmmmm. > > This makes sense. Oh. Good. -chris ps: BTW, after struggling directly with how to express axiom schemas in KIF in recent days (a flag Michael has raised a couple of times) I am becoming convinced that a metalevel facility in KIF is going to be needed even by those who just want a minimal KIF for writing ontologies. From gruning at cme.nist.gov Mon Nov 20 09:27:54 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:30:59 2003 Subject: minutes from Nov 17 KIF meeting Message-ID: <3A1942FA.AB9B297F@cme.nist.gov> Here are the minutes from Friday's telecon. Thanks to Mike Uschold for his notes. - michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://philebus.tamu.edu/pipermail/kif/attachments/20001120/0905bd8c/nov17minutes.html From apease at teknowledge.com Mon Nov 20 12:08:41 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:30:59 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <200011190115.RAA03046@puffin.rt.cs.boeing.com> Message-ID: <4.2.0.58.20001120100715.01a200f0@helium.teknowledge.com> Mike, In order to support the SUO project, I believe SUO-KIF should be for authoring ontologies. As a separate point, it would be beneficial to have a language for interchange that is consistent with the language for authoring. Adam At 05:15 PM 11/18/2000 -0800, Michael Uschold wrote: >Pat Said: > > > But I was not thinking about an overall > > operation of converting one language into another or writing a > > translator, but allowing KIF to express propositions *about* > > expression in other ontologies written in other languages and their > > content *expressed in KIF*. The other ontology might for example > > contain millions of assertions, and one might be interested only in > > those that refer to the city of Boston. It wouldnt make sense to have > > to translate the entire database into KIF; better to be able to say > > in KIF, this is what I am interested in, and this is what it would > > look like in your language, and then rely on some other engine, > > running on some other website, to retrieve the information you want > > and send it to you. Now, you might respond that while this is all > > true, it is the business of something else to do the > > inter-translation. But KIF is supposed to be the interlingua, > > remember? If we have to go to something else to express the semantic > > content of the translation process, then KIF has been relegated to > > just another logic, and we are no further forward in having an > > ontology language which can support web-based transactions between > > ontologies. > >Pat, > >I have to say, I do believe that: "it is the business of something else >[besides KIF] to do the inter-translation. It feels like you are >confusing/conflating two different roles for a language. One, to be an >interlingua (IL), and two, to specify how translation is done. > >All that it means to be an IL is to be a language through which all >language-to-language translations take place. It is merely a temporary >placeholder in a two step translation process. There may always be loss in >translation when translating into a less expressive language. To avoid >loss in >translation in *both* steps, one can design the Interchange Language (IL) >to be >at least as expressive as any of the intended or potential languages that may >be translated to/fro. This should be uncontentious. > >A quite separate question is how one does translation. You seem to be placing >demands on the language to be able to also specify "the semantic content >of the translation process". This seems quite a separate business entirely, >although, of course a very important one. > >I see no reason for requiring an IL to include such features, per se. >However, >a separate language which is also a standard for specifying such things may >well be a good idea. But I think the two things are quite separate. > >I also thought that SUOKIF was intended to be used for AUTHORING ontologies, >which again, is a very different use of a language, as compared to use as an >IL. An authoring language that is intended for translation into multiple >target implementation languages has different requirements. To avoid loss in >translation, one does well to have *less* expressive power, kind of the least >common demominator. The strategy for reducing loss of translation for an IL is >the opposite: to have MORE expressive power. > >Which raises the question: what is SUOKIF for??? Authoring? Interchange? >Both? > >NB: Im not arguing that we shold not includ the [quasi]-quote feature in >SUOKIF. Instead, I'm trying to make some general points regarding the >uses and >corresponding design strategies for SUOKIF. > > >Mike >---- ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Tue Nov 21 03:39:08 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:59 2003 Subject: Quotation In-Reply-To: <200011172356.PAA27641@Pacific.AI.SRI.COM> References: <200011172356.PAA27641@Pacific.AI.SRI.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4141 bytes Desc: not available Url : http://philebus.tamu.edu/pipermail/kif/attachments/20001121/c4f9f047/attachment.bin From phayes at ai.uwf.edu Tue Nov 21 03:39:08 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:30:59 2003 Subject: Quotation In-Reply-To: <200011172356.PAA27641@Pacific.AI.SRI.COM> References: <200011172356.PAA27641@Pacific.AI.SRI.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4141 bytes Desc: not available Url : http://philebus.tamu.edu/pipermail/kif/attachments/20001121/c4f9f047/attachment-0001.bin From sowa at bestweb.net Tue Nov 21 08:34:27 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:30:59 2003 Subject: Quotation Message-ID: <3a1a9603.393a.0@bestweb.net> Pat, Mark, et al., I agree that in an unsorted language, you can make do with a single kind of quotation mark with some escape mechanism for quotations within quotations. If you have a language that is strictly sorted, then you can use the sort machinery to determine what kind of expression to expect and whether or not a particular expression should be "coerced" into a different sort. That distinction is related to the methods of passing arguments in programming languages: call by reference passes a pointer to something, call by value evaluates an expression (which might be a single variable), and call by name passes the expression itself (which in Algol was processed by passing a "thunk" -- which is essentially the expression enclosed in a wrapper, such as lambda. That question of which method is being used is determined by the declaration (or signature) of the function or procedure that is being called. When you have a strictly typed (or sorted) language, the signature of a function specifies what types are expected for each parameter. If one parameter is of type Expression, the unevaluated (i.e. quoted) expression is assigned to it. If another paramter has type Number, any argument of any type other than Number (or some subtype, such as Integer or Rational) is evaluated. If the result is not a number, an error check occurs. If you use strict typing, you can get away without having a quote. But you're not home completely free, since you may still need explicit conversion functions from one type to another. (The Lisp EVAL is a special case of a conversion function.) Question for Mark: What effect would strict typing of this kind have on your unification algorithms? John Sowa From apease at teknowledge.com Tue Nov 21 16:26:35 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:31:00 2003 Subject: Quotation In-Reply-To: <3a1a9603.393a.0@bestweb.net> Message-ID: <4.2.0.58.20001121142521.01ae0008@helium.teknowledge.com> John, Thanks for the lucid explanation. I've been advocating an approach like Cyc's for SUO-KIF in which relations have strongly typed arguments and quoting is implied by the type Expression. Adam At 10:34 AM 11/21/2000 -0400, John F. Sowa wrote: >Pat, Mark, et al., > >I agree that in an unsorted language, you can make do with a >single kind of quotation mark with some escape mechanism for >quotations within quotations. > >If you have a language that is strictly sorted, then you can >use the sort machinery to determine what kind of expression >to expect and whether or not a particular expression should >be "coerced" into a different sort. > >That distinction is related to the methods of passing >arguments in programming languages: call by reference >passes a pointer to something, call by value evaluates an >expression (which might be a single variable), and call by >name passes the expression itself (which in Algol was processed >by passing a "thunk" -- which is essentially the expression >enclosed in a wrapper, such as lambda. > >That question of which method is being used is determined by >the declaration (or signature) of the function or procedure >that is being called. > >When you have a strictly typed (or sorted) language, the >signature of a function specifies what types are expected >for each parameter. If one parameter is of type Expression, >the unevaluated (i.e. quoted) expression is assigned to it. >If another paramter has type Number, any argument of any type >other than Number (or some subtype, such as Integer or Rational) >is evaluated. If the result is not a number, an error check >occurs. > >If you use strict typing, you can get away without having >a quote. But you're not home completely free, since you >may still need explicit conversion functions from one type >to another. (The Lisp EVAL is a special case of a conversion >function.) > >Question for Mark: What effect would strict typing of this >kind have on your unification algorithms? > >John Sowa ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Thu Nov 23 15:46:12 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:00 2003 Subject: purpose of quoting In-Reply-To: References: <3a15f6a9.f3e3.0@bestweb.net> Message-ID: >At 10:25 PM -0400 11/17/00, John F. Sowa wrote: >>Chris W wrote: >> >>>Being an interchange language does not require being able to describe >>>other languages - it only requires that knowledge represented in >>>other languages be expressable in KIF. It's like compilation vs. >>>interpretation in programming languages. I've been thinking of KIF >>>as the assembly language that other KR languages compile into, not a >>>language in which interpreters are written. >> >>It all depends on what parts of the ontology you're trying >>to describe. By definition, the SUO will include the most >>general supertypes of all the categories that anyone might >>want to implement, talk about, program about, or even think >>about. While specifying airplanes and computer circuits, it >>will have to specify the programs that guide those airplanes >>and the operations of those circuits. That means that KIF will >>have to be able to describe data structures, logic circuits, >>decoders, sequencers, and all their possible combinations. >>In other words, it will have to be able to specify a Turing >>machine or any language that can simulate a Turing machine >>or interpret the specifications of a Turing machine. > >Isn't this a little ambitious? No, since the SUO is supposed to be the upper ontology for EVERYTHING. That includes things like Turing machines and aircraft control systems, as well as diseases of Welsh mountain goats, oil transportation systems and tropical shellfish. (As an aside, I am constantly surprised that people can be so enthusiastic about an upper ontology which is supposed to be suitable for a world-wide standard, and simultaneously so narrowminded about what they think an ontology is going to be talking about.) >>That is not a big deal, because FOL can indeed specify a >>Turing machine. So we won't need any functionality beyond >>what is already in the FOL core. > >That FOL can specify a Turing Machine and for that matter that a >Turing Machine can specify a control system for an airplane is not >the point. I tend to agree....but.... > the point is these are the wrong tools for doing that. I disagree with that. First, any judgement about what is or is not the 'right tool' has to be essentially a subjective, aesthetic judgement. But more seriously, the business of an ontology language is to describe *content*, and that content can be about anything under the sun. Chris, are you seriously suggesting that it will *never* be appropriate to use logic to describe aircraft control systems? What on earth do you think that ontologies are for? >Tools for specifying Turing machines exist. Tools for specifying >control systems exist. Tools for specifying syntax exist. I don't >see why KIF should try to be all those things. Tools for describing ontologies exist also. So what? >In fact, such a goal is precisely the opposite of what I thought we >were after with "SUO-KIF-core". I believe there is a group of us >who envision the core as being very minimalist. Well, OIL is more minimalist than FOL, and RDF is more minimalist still. Would you therfore argue that RDF would be a suitable candidate? >>>I also don't understand why (those who do) want KIF to have the >>>ability to support ontology management functionality. This just does >>>not seem to me to be "core" functionality. >> >>When I am writing a program in the "core" subset of C, C++, >>Java, Python, or whatever, one of the first things I do is >>to write some import statements that load the independently >>compiled modules or packages that will be referenced by the >>statements in my current module. > >You may perform this operation, but it is not part of the core of >any of these languages. I'm not saying we don't want this >capability in practice, just that it isn't in the core! It would be more constructive if people were to say what it is they DO want in the core, rather than what they DONT want in it. Having something there that you don't want to use is no great burden to bear, while not having something that you do what could be fatal. >> >>The consensus that I think we wound up with is that we need a core >>>>which serves #1 and an extension which serves #2. I agree, this has been the consensus for some time, so why are we still bickering about it? Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From cmenzel Fri Nov 24 02:14:10 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:00 2003 Subject: Quotation In-Reply-To: Your message of "Tue, 21 Nov 2000 09:39:08 GMT." Message-ID: Folks, Here follows an attempt to work out in detail some of the ideas that have come out recently on quotation and quasi-quotation. I have used a sort of simplified KIF-meta that helps focus the account. Quotation is cashed out in the form of a theory of string concatenation. The account is based largely on Pat's second posting (and ultimately upon Quine). I *think* it differs from Pat's in that there are no actual quoted terms of length > 1 in KIF-meta; rather, there are only functional terms indicating iterated concatenation (as suggested in a post by Mark). However, as you can see, quoted terms of length > 1 can be introduced as abbreviations. I say more about quasi-quotation below. Actually, what I'm laying out here is not really KIF-meta, but, so to say, *a* KIF-meta. I think KIF-meta is likely to be a *specification* that tells us how in general to define a KIF theory about some specific language or languages. Hence, what I'm laying out here is a particular KIF-meta whose target language happens to be *itself*, that is, the intended model that makes its axioms true is its own syntax; you should see the clauses of the BNF mirrored directly in the axioms. I've written this up more or less in the form of a KIF file, with metalinguistic stuff commented out (except for the BNF for the language). If I'm confused, just tell me why nicely, please. -chris ;;;;;;;;;;;;;;;;;;;;;;;;; A BNF FOR KIF-META ;;;;;;;;;;;;;;;;;;;;;;;;; ;; This BNF is asserted in the metalanguage for KIF-meta, of course, ;; not in KIF-meta itself. Hence, if I were to be completely ;; consistent here, I would comment it out. But it wouldn't look as ;; pretty... ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z ::= a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ::= | | ::= - | _ ::= | ::= ~ | ` | ! | @ | # | $ | % | ^ | & | * | ( | ) | + | = | { | [ | } | ] | | | \ | : | ; | ' | < | , | > | . | ? | / | \" ::= | ::= * ::= * ::= | | | ::= ? ::= ( { }*) ::= "" ::= | | | ::= ( { }*) ::= (not ) ::= ({and|or} +) | ({=>|<=>} ) ::= ({forall|exists} (+) ) ;;;;;;;;;;;;;;;;;;;;;;;; KIF-META IN KIF-META ;;;;;;;;;;;;;;;;;;;;;;;; ;; AXIOMS FOR THE BASIC SYNTACTIC CATEGORIES (<=> (Upper ?x) (or (= ?x "A") (= ?x "B") (= ?x "C") (= ?x "D") (= ?x "E") (= ?x "F") (= ?x "G") (= ?x "H") (= ?x "I") (= ?x "J") (= ?x "K") (= ?x "L") (= ?x "M") (= ?x "N") (= ?x "O") (= ?x "P") (= ?x "Q") (= ?x "R") (= ?x "S") (= ?x "T") (= ?x "U") (= ?x "V") (= ?x "W") (= ?x "X") (= ?x "Y") (= ?x "Z"))) (<=> (Lower ?x) (or (= ?x "a") (= ?x "b") (= ?x "c") (= ?x "d") (= ?x "e") (= ?x "f") (= ?x "g") (= ?x "h") (= ?x "i") (= ?x "j") (= ?x "k") (= ?x "l") (= ?x "m") (= ?x "n") (= ?x "o") (= ?x "p") (= ?x "q") (= ?x "r") (= ?x "s") (= ?x "t") (= ?x "u") (= ?x "v") (= ?x "w") (= ?x "x") (= ?x "y") (= ?x "z"))) (<=> (Digit ?x) (or (= ?x "0") (= ?x "1") (= ?x "2") (= ?x "3") (= ?x "4") (= ?x "5") (= ?x "6") (= ?x "7") (= ?x "8") (= ?x "9"))) (<=> (Alphanum ?x) (or (Upper ?x) (Lower ?x) (Digit ?x))) (<=> (Dash ?x) (or (= ?x "-") (= ?x "_"))) (<=> (Wordchar ?x) (or (Alphanum ?x) (Dash ?x))) (<=> (Misc ?x) (or (= ?x "~") (= ?x "`") (= ?x "!") (= ?x "@") (= ?x "#") (= ?x "$") (= ?x "%") (= ?x "^") (= ?x "&") (= ?x "*") (= ?x "(") (= ?x ")") (= ?x "+") (= ?x "=") (= ?x "{") (= ?x "[") (= ?x "}") (= ?x "]") (= ?x "|") (= ?x "\") (= ?x ":") (= ?x ";") (= ?x "'") (= ?x "<") (= ?x ",") (= ?x ">") (= ?x ".") (= ?x "?") (= ?x "/") (= ?x " ") (= ?x "\""))) (<=> (Char ?x) (or (Wordchar ?x) (Misc ?x))) ;; ON QUOTATION AND QUASI-QUOTATION IN THE METALANGUAGE FOR KIF-META ;; To mention strings of KIF-meta in this metalanguage (i.e., the ;; mathematical English I am using to describe KIF-meta) I will ;; surround them with a backquote and a single quote. Thus, I quote ;; the KIF-meta predicate `Char' as indicated. For metalinguistic ;; quasi-quotation I will use angle brackets. I will also use all ;; caps for metavariables. Thus, where S is a term of KIF-meta, a ;; sentence of the form <(Char S)> is an atomic sentence whose ;; predicate is `Char'. If I need to describe a string of KIF-meta ;; that contains one of these quotation characters (or a backslash) ;; I'll escape it with a backslash in the usual fashion. ;; STRINGS AND THE CONCATENATION OPERATOR ;; To talk about strings generally, and terms and sentences in ;; particular, meta-KIF needs to talk about the results of ;; concatenating one string with another. Thus, we introduce an ;; explicit concatentation operator `cc' into meta-KIF. Our first use ;; of this operator is in the characterization of strings as arbitrary ;; concatentations of characters. (<=> (String ?x) (or (Char ?x) (exists (?y ?z) (and (String ?y) (String ?z) (= ?x (cc ?y ?z)))))) ;; Axioms for the null string and concatentation. ;; cc is associative (= (cc (cc ?x ?y) ?z) (cc ?x (cc ?y ?z)))) ;; null is the identity under cc. (= (cc ?x null) ?x) (= (cc null ?x) ?x) ;; For algebra geeks: Given these axioms, the algebra consisting of ;; the strings under cc is a monoid, more specifically, the free ;; monoid generated by the set of Chars. ;; null is the only thing that is identical to its self-concatentation (=> (= ?x (cc ?x ?x)) (= ?x null)) ;; The value of cc is always a string. (String (cc ?x ?y)) ;; We set the value of cc to be the null string if one of its ;; arguments is not a string. This is for convenience only, as it ;; makes the string axioms simpler to state. (=> (or (not (String ?x)) (not (String ?y))) (= null (cc ?x ?y))) ;; ON QUOTATION AND QUASI-QUOTATION IN KIF-META ;; Note that there are no literal quoted strings of length greater ;; than 1 in this proposed meta-KIF. Rather, what we have are ;; function terms of the form <(cc (cc ... (cc T1 T2) ... Tn-1) Tn)>, ;; where the Ti are either names of characters or variables, and whose ;; semantic values (in any model) are strings of the language being ;; characterized. Thus, we don't have the quoted term "ab" in this ;; metalanguage; rather, we have the term `(cc "a" "b")' whose ;; semantic value is the concatenation of "a" and "b", i.e., the ;; string `ab'. ;; Clearly, however, terms like `"ab"' can be conveniently employed as ;; *abbreviations* for terms involving `cc', thereby reflecting in a ;; structurally more similar way the semantic value of the ;; unabbreviated term. Thus, in particular, `"ab"' can be throught of ;; as an abbreviation for `(cc "a" "b")'. For longer strings, we can ;; associate "to the left", e.g., `"ab c"' can be understood as an ;; abbreviation for `(cc (cc (cc "a" "b") " ") "c")'. By the ;; associativity of cc, of course, this will be identical to, e.g., ;; `(cc "a" (cc "b" (cc " " "c")))'. By our convention, this in turn ;; could be "partially abbreviated" as `(cc "a" "b c")'. Note that ;; spaces within quotes indicate the actual space character. ;; As noted, the terms T1 and T2 in <(cc T1 T2)> can be variables. ;; However, to avoid ambiguity, we need a convention to indicate the ;; end of a variable name in a concatenation from the beginning of an ;; adjacent string. Moreover, we need to be able to distinguish the ;; beginning of a variable name in an abbreviation from a string that ;; just happens to contain an occurrence of `?'. Here we can follow ;; Pat's suggestion and use the backward slash `\' to indicate both ;; the beginning and the end of a variable name. Thus, for example, ;; `(cc (cc (cc ?v1 ?v2) "a") ?v3)' would be abbreviated as ;; `"\?v1\\?v2\a\?v3\"'. By contrast, `(cc (cc (cc ?v1 "?v2") "a") ;; ?v3)' would be abbreviated as `"\?v1\?v2a\?v3\"'. Note that the ;; KIF-meta term `"\""' denotes the doublequote character `"'. Hence, ;; a quoted term of KIF-meta like `"ab"' is denoted in KIF-meta by ;; `(cc (cc (cc "\"" "a") "b") "\"")', and hence abbreviated as ;; `"\"ab\""'. ;; TERM AND SENTENCES (<=> (Word ?x) (or (Alphanum ?x) (exists (?y ?z) (and (Alphanum ?y) (Wordchar ?z) (= ?x "\?y\\?z\"))) (exists (?y ?z) (and (Word ?y) (Word ?z) (= ?x "\?y\\?z\"))))) ;; Terms ;; A termlist is simply a string consisting of either a single term or ;; numerous terms separated by single spaces. This is an auxiliary ;; notion that is Needed for defining function terms and atomic ;; sentences. (Obviously, the recursive character of the definition ;; is used to capture the arbitrary iteratability implied by the + ;; operator in a BNF (cf. the clauses for s and s). ;; I saw this trick employed recently (can't remember where) in some ;; syntactic axioms by Fikes and/or McGuinness.) (<=> (Termlist ?x) (or (Term ?x) (exists (?y ?z) (and (Termlist ?y) (Termlist ?z) (= ?x "\?y\ \?z\"))))) (<=> (Term ?x) (or (Word ?x) (Variable ?x) (Funterm ?x) (Quoterm ?x))) (<=> (Variable ?x) (exists (?y) (and (Word ?y) (= ?x "?\?y\")))) (<=> (Funterm ?x) (exists (?y ?z) (and (Word ?y) (Termlist ?z) (= ?x "(\?y\ \?z\)"))))) (<=> (Quoterm ?x) (exists (?y) (and (String ?y) (= ?x "\"\?y\\"")))) ;; Auxiliary notions for defining sentences ;; The "term-in" relation holds between a term and a termlist in which ;; the term occurs as a "member". (<=> (term-in ?x ?y) (and (Termlist ?y) (exists (?z ?w) (or (= ?y ?x) (= ?y "\?x\ \?z\") (= ?y "\?w\ \?x\") (= ?y "\?w\ \?x\ \?z\"))))) ;; A varlist is a termlist whose "members" are variables. (<=> (Varlist ?x) (and (Termlist ?x) (forall (?y) (=> (term-in ?y ?x) (Variable ?y))))) ;; A sentlist is a string consisting of either a single sentence or ;; numerous sentences separated by single spaces. (<=> (Sentlist ?x) (and (String ?x) (or (Sentence ?x) (exists (?y ?z) (and (Sentlist ?y) (Sentlist ?z) (= ?x "\?y\ \?z\")))))) ;; Sentences (<=> (Sentence ?x) (or (Atomic ?x) (Negation ?x) (Boolean ?x) (Quant ?x))) (<=> (Atomic ?x) (exists (?y ?z) (and (Word ?y) (Termlist ?z) (= ?x "(\?y\ \?z\)")))) (<=> (Negation ?x) (exists (?y) (and (Sentence ?y) (= ?x "(not \?y\)")))) (<=> (Boolean ?x) (exists (?y ?z) (and (Sentlist ?y) (or (= ?x "(and \?y\)") (= ?x "(or \?y\)") (= ?x "(=> \?y\)") (= ?x "(<=> \?y\)"))))) (<=> (Quant ?x) (exists (?y ?z) (and (Varlist ?y) (Sentence ?z) (or (= ?x "(forall (\?y\) \?z\)") (= ?x "(exists (\?y\) \?z\)"))))) From cmenzel Fri Nov 24 15:56:48 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:00 2003 Subject: Quotation again In-Reply-To: Your message of "Fri, 24 Nov 2000 02:14:10 CST." Message-ID: There were a few flaws in the previous document. This one corrects them (well, the ones I found, anyway) and also adds a bit more exposition, notably about quasi-quotation. -chris ***** ;;;;;;;;;;;;;;;;;;;;;;;;; A BNF FOR KIF-META ;;;;;;;;;;;;;;;;;;;;;;;;; ;; This BNF is asserted in the metalanguage for KIF-meta, of course, ;; not in KIF-meta itself. Hence, if I were to be completely ;; consistent here, I would comment it out. But it wouldn't look as ;; pretty... ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z ::= a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ::= | | ::= - | _ ::= | ::= ~ | ` | ! | @ | # | $ | % | ^ | & | * | ( | ) | + | = | { | [ | } | ] | | | \ | : | ; | ' | < | , | > | . | ? | / | \" ::= | ::= * ::= * ::= | | | ::= ? ::= ( { }*) ::= "" ::= | | | ::= ( { }*) ::= (not ) ::= ({and|or} +) | ({=>|<=>} ) ::= ({forall|exists} (+) ) ;;;;;;;;;;;;;;;;;;;;;;;; KIF-META IN KIF-META ;;;;;;;;;;;;;;;;;;;;;;;; ;; Axioms for the basic syntactic categories (<=> (Upper ?x) (or (= ?x "A") (= ?x "B") (= ?x "C") (= ?x "D") (= ?x "E") (= ?x "F") (= ?x "G") (= ?x "H") (= ?x "I") (= ?x "J") (= ?x "K") (= ?x "L") (= ?x "M") (= ?x "N") (= ?x "O") (= ?x "P") (= ?x "Q") (= ?x "R") (= ?x "S") (= ?x "T") (= ?x "U") (= ?x "V") (= ?x "W") (= ?x "X") (= ?x "Y") (= ?x "Z"))) (<=> (Lower ?x) (or (= ?x "a") (= ?x "b") (= ?x "c") (= ?x "d") (= ?x "e") (= ?x "f") (= ?x "g") (= ?x "h") (= ?x "i") (= ?x "j") (= ?x "k") (= ?x "l") (= ?x "m") (= ?x "n") (= ?x "o") (= ?x "p") (= ?x "q") (= ?x "r") (= ?x "s") (= ?x "t") (= ?x "u") (= ?x "v") (= ?x "w") (= ?x "x") (= ?x "y") (= ?x "z"))) (<=> (Digit ?x) (or (= ?x "0") (= ?x "1") (= ?x "2") (= ?x "3") (= ?x "4") (= ?x "5") (= ?x "6") (= ?x "7") (= ?x "8") (= ?x "9"))) (<=> (Alphanum ?x) (or (Upper ?x) (Lower ?x) (Digit ?x))) (<=> (Dash ?x) (or (= ?x "-") (= ?x "_"))) (<=> (Wordchar ?x) (or (Alphanum ?x) (Dash ?x))) (<=> (Misc ?x) (or (= ?x "~") (= ?x "`") (= ?x "!") (= ?x "@") (= ?x "#") (= ?x "$") (= ?x "%") (= ?x "^") (= ?x "&") (= ?x "*") (= ?x "(") (= ?x ")") (= ?x "+") (= ?x "=") (= ?x "{") (= ?x "[") (= ?x "}") (= ?x "]") (= ?x "|") (= ?x "\") (= ?x ":") (= ?x ";") (= ?x "'") (= ?x "<") (= ?x ",") (= ?x ">") (= ?x ".") (= ?x "?") (= ?x "/") (= ?x " ") (= ?x "\""))) (<=> (Char ?x) (or (Wordchar ?x) (Misc ?x))) ;; ON QUOTATION AND QUASI-QUOTATION IN THE METALANGUAGE FOR KIF-META ;; To mention strings of KIF-meta in this metalanguage (i.e., the ;; mathematical English I am using to describe KIF-meta) I will ;; surround them with a backquote and a single quote. Thus, I quote ;; the KIF-meta predicate `Char' as indicated. For metalinguistic ;; quasi-quotation I will use angle brackets. I will also use all ;; caps for metavariables. Thus, where S is a term of KIF-meta, a ;; sentence of the form <(Char S)> is an atomic sentence whose ;; predicate is `Char'. If I need to describe a string of KIF-meta ;; that contains one of these quotation characters (or a backslash) ;; I'll escape it with a backslash in the usual fashion. ;; STRINGS AND THE CONCATENATION OPERATOR ;; To talk about strings generally, and terms and sentences in ;; particular, meta-KIF needs to talk about the results of ;; concatenating one string with another. Thus, we introduce an ;; explicit concatentation operator `cc' into meta-KIF. Our first use ;; of this operator is in the characterization of strings as arbitrary ;; concatentations of characters. (Obviously, the "recursive" ;; character of the axiom is used to capture the arbitrary ;; iteratability implied by the * and + operators in a BNF.) (<=> (String ?x) (or (Char ?x) (exists (?y ?z) (and (String ?y) (String ?z) (= ?x (cc ?y ?z)))))) ;; Axioms for the null string and concatentation. ;; cc is associative (= (cc (cc ?x ?y) ?z) (cc ?x (cc ?y ?z)))) ;; null is the identity under cc. (= (cc ?x null) ?x) (= (cc null ?x) ?x) ;; For algebra geeks: Given these axioms, the algebra consisting of ;; the strings under cc is a monoid, more specifically, the free ;; monoid generated by the set of Chars. ;; null is the only thing that is identical to its self-concatentation (=> (= ?x (cc ?x ?x)) (= ?x null)) ;; The value of cc is always a string. (String (cc ?x ?y)) ;; We set the value of cc to be the null string if one of its ;; arguments is not a string. This is for convenience only, as it ;; makes the string axioms simpler to state. (=> (or (not (String ?x)) (not (String ?y))) (= null (cc ?x ?y))) ;; ON QUOTATION AND QUASI-QUOTATION IN KIF-META ;; Note that there are no literal quoted strings of length greater ;; than 1 in this proposed meta-KIF. Rather, what we have are ;; function terms of the form <(cc (cc ... (cc T1 T2) ... Tn-1) Tn)>, ;; where the Ti are either names of characters or variables, and whose ;; semantic values (in any model) are strings of the language being ;; characterized. Thus, we don't have the quoted term "ab" in this ;; metalanguage; rather, we have the term `(cc "a" "b")' whose ;; semantic value is the concatenation of "a" and "b", i.e., the ;; string `ab'. ;; Clearly, however, terms like `"ab"' can be conveniently employed as ;; *abbreviations* for terms involving `cc', thereby reflecting in a ;; structurally more similar way the semantic value of the ;; unabbreviated term. Thus, in particular, `"ab"' can be throught of ;; as an abbreviation for `(cc "a" "b")'. For longer strings, we can ;; associate "to the left", e.g., `"ab c"' can be understood as an ;; abbreviation for `(cc (cc (cc "a" "b") " ") "c")'. By the ;; associativity of cc, of course, this will be identical to, e.g., ;; `(cc "a" (cc "b" (cc " " "c")))'. By our convention, this in turn ;; could be "partially abbreviated" as `(cc "a" "b c")'. Note that ;; spaces within quotes indicate the actual space character. ;; As noted, the terms T1 and T2 in <(cc T1 T2)> can be variables. ;; Thus, our convention for abbreviation effectively gives us ;; quasi-quotation in KIF-meta. (Actually, it gives us *exactly* ;; quasi-quotation in KIF-meta, as quasi-quotation (the way Quine ;; defines) just *is* a metalinguistic abbreviative convention.) ;; However, to avoid ambiguity, we need a convention to distinguish ;; the end of a variable name in a concatenation from the beginning of ;; an adjacent string. Moreover, we need to be able to distinguish ;; the beginning of a variable name in an abbreviation from a string ;; that just happens to contain an occurrence of `?'. Here we can ;; follow Pat's suggestion and use the backward slash `\' to indicate ;; both the beginning and the end of a variable name. Thus, for ;; example, `(cc (cc (cc ?v1 ?v2) "a") ?v3)' would be abbreviated as ;; `"\?v1\\?v2\a\?v3\"'. By contrast, `(cc (cc (cc ?v1 "?v2") "a") ;; ?v3)' would be abbreviated as `"\?v1\?v2a\?v3\"'. Note that the ;; KIF-meta term `"\""' denotes the doublequote character `"'. Hence, ;; a quoted term of KIF-meta like `"ab"' is denoted in KIF-meta by ;; `(cc (cc (cc "\"" "a") "b") "\"")', and hence abbreviated as ;; `"\"ab\""'. ;; TERM AND SENTENCES (<=> (Word ?x) (or (Alphanum ?x) (exists (?y ?z) (and (Alphanum ?y) (Wordchar ?z) (= ?x "\?y\\?z\"))) (exists (?y ?z) (and (Word ?y) (Word ?z) (= ?x "\?y\\?z\"))))) ;; Terms ;; A termlist is simply a string consisting of either a single term or ;; numerous terms separated by single spaces. This is an auxiliary ;; notion that is Needed for defining function terms and atomic ;; sentences. (<=> (Termlist ?x) (or (Term ?x) (exists (?y ?z) (and (Termlist ?y) (Termlist ?z) (= ?x "\?y\ \?z\"))))) (<=> (Term ?x) (or (Word ?x) (Variable ?x) (Funterm ?x) (Quoterm ?x))) (<=> (Variable ?x) (exists (?y) (and (Word ?y) (= ?x "?\?y\")))) (<=> (Funterm ?x) (exists (?y ?z) (and (Word ?y) (Termlist ?z) (= ?x "(\?y\ \?z\)"))))) (<=> (Quoterm ?x) (exists (?y) (and (String ?y) (= ?x "\"\?y\\"")))) ;; Auxiliary notions for defining sentences ;; The "term-in" relation holds between a term and a termlist in which ;; it occurs as an "member". (<=> (term-in ?x ?y) (and (Termlist ?y) (exists (?z ?w) (or (= ?y ?x) (= ?y "\?x\ \?z\") (= ?y "\?w\ \?x\") (= ?y "\?w\ \?x\ \?z\"))))) ;; A varlist is a termlist whose "members" are variables. (<=> (Varlist ?x) (and (Termlist ?x) (forall (?y) (=> (term-in ?y ?x) (Variable ?y))))) ;; A sentlist is a string consisting of either a single sentence or ;; numerous sentences separated by single spaces. (<=> (Sentlist ?x) (and (String ?x) (or (Sentence ?x) (exists (?y ?z) (and (Sentlist ?y) (Sentlist ?z) (= ?x "\?y\ \?z\")))))) ;; Sentences (<=> (Sentence ?x) (or (Atomic ?x) (Negation ?x) (Boolean ?x)(Quant ?x))) (<=> (Atomic ?x) (exists (?y ?z) (and (Word ?y) (Termlist ?z) (= ?x "(\?y\ \?z\)")))) (<=> (Negation ?x) (exists (?y) (and (Sentence ?y) (= ?x "(not \?y\)")))) (<=> (Boolean ?x) (or (exists (?y) (and (Sentlist ?y) (or (= ?x "(and \?y\)") (= ?x "(or \?y\)")))) (exists (?y ?z) (and (Sentence ?y) (Sentence ?z) (= ?x "(=> \?y\ \?z\)") (= ?x "(<=> \?y\ \?z\)"))))) (<=> (Quant ?x) (exists (?y ?z) (and (Varlist ?y) (Sentence ?z) (or (= ?x "(forall (\?y\) \?z\)") (= ?x "(exists (\?y\) \?z\)"))))) From phayes at ai.uwf.edu Sun Nov 26 15:05:17 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:00 2003 Subject: Quotation again In-Reply-To: <200011242156.eAOLumT11727@philebus.tamu.edu> References: <200011242156.eAOLumT11727@philebus.tamu.edu> Message-ID: Chris, a heroic piece of work. Let me suggest a few modifications, though. First, let us allow variables in the function and relation positions of expressions, which will require a small change to the basic syntax. Second, more to the current point, why do you use a distinct syntax for plain quotation and quasi-quotation? There seems to be no need to do this, since a quasi-quote without any variables in it means the same as a plain string quotation, so having a distinct quasi-quote syntax creates two alternative syntactic constructions for quotation. (This was one of the things which needed cleaning up in KIF.) As long as we have some way to 'insert' a dequoted string variable into a quotation, quasi-quote and string quote can be treated identically. We could allow strings into the core harmlessly, seems to me, just as a category of constants, and then the meta-extension needs only the extra syntactic machinery for dequoting string variables, which can be done by the surrounding-backslash convention. This minimises the extra syntactic machinery (notably, the extensions to the lexical analyser) needed to support the meta-extension, and uses fewer special characters. Third, your definition of 'string' is, as you note, recursive; but in fact it isn't really recursive, since one cannot give true recursive definitions in FOL. This is a very basic issue which we need to address, in fact: all finite things, including lists, character strings and integers, are intrinsically undefinable in FOL. Maybe we should have a 'recursive' extension which explicitly allows recursion and has a special minimum-fixed-point semantic specification? Fourth, although we havnt discussed this yet, KIF in fact allows 'character strings' to contain arbitrary sequences of 'characters' which are specified by numerical codes. As the KIF documentation noted, this allows things like digitised images or file contents more generally to be referred to as KIF strings, which might be useful. I would vote to retain this flexibility if it can be done without significant cost, which I think it can be by simply retaining the KIF convention (which uses the # character, as I recall.) Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From cmenzel Sun Nov 26 18:39:33 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:00 2003 Subject: Quotation again In-Reply-To: Your message of "Sun, 26 Nov 2000 15:05:17 CST." Message-ID: Thanks for the comments, Pat. > First, let us allow variables in the function and relation positions > of expressions, which will require a small change to the basic syntax. That should be ok as long as the semantics is done carefully. This might require the "Stickel semantics" that I promised but have yet to deliver. I will probably just have to give a short presentation at the workshop. > Second, more to the current point, why do you use a distinct syntax > for plain quotation and quasi-quotation? I didn't think I did. Are you sure you are not referring to the distinction between quotation and quasi-quotation in the *metalanguage* in which the document is written? There I do indeed use backquote and single quote for "real" quotation, and angle brackets for quasi-quotation. But in the proposed KIF-meta, quasi-quotation shows up in the form of an abbreviation for functional terms of the form (cc STRING1 STRING2), where `cc' is the concatenation operator. And the notation I'm using for these abbreviations is the same double quote notation that I'm using for real quotation. > Third, your definition of 'string' is, as you note, recursive; but in > fact it isn't really recursive, Well, it isn't really a definition! :-) > since one cannot give true recursive definitions in FOL. Yes, of course. In fact this is one of the infelicities of the first version that I sent around that I fixed in the second version; I hastily typed the word "definition" after I typed "recursive". Of course there will be non-standard first-order models of all of those "recursive" axioms that would not be the classes generated by a genuine recursive definition (in a second-order theory) -- one can't in particular express the idea of the *smallest* possible class that makes such an axiom true in FOL. (There is, for example, nothing to prevent us (in FOL) from just declaring George Bush to be a string -- I will bite my tongue and avoid any attempt at political humor here.) Here is the revision you will find in the second version, which replaces "definition" with "axiom", and puts "recursive" in scare quotes: ;; To talk about strings generally, and terms and sentences in ;; particular, meta-KIF needs to talk about the results of ;; concatenating one string with another. Thus, we introduce an ;; explicit concatentation operator `cc' into meta-KIF. Our first use ;; of this operator is in the characterization of strings as arbitrary ;; concatentations of characters. (Obviously, the "recursive" ;; character of the axiom is used to capture the arbitrary ;; iteratability implied by the * and + operators in a BNF.) (<=> (String ?x) (or (Char ?x) (exists (?y ?z) (and (String ?y) (String ?z) (= ?x (cc ?y ?z)))))) > This is a very basic issue which we need to address, in fact: all > finite things, including lists, character strings and integers, are > intrinsically undefinable in FOL. Maybe we should have a 'recursive' > extension which explicitly allows recursion and has a special > minimum-fixed-point semantic specification? We could certainly add a theory of recursive definition, but, frankly, I think axioms like the above are probably all anyone needs for ontology (??). In FOL, nonstandard models will always be with us. And, of course, as you well know, nothing we *say*, even in a higher-order language, can force a higher-order interpretation, even if we supply one. So I'm not sure your proposed recursion extension would buy us much more than we have already. > Fourth, although we havnt discussed this yet, KIF in fact allows > 'character strings' to contain arbitrary sequences of 'characters' > which are specified by numerical codes. Right. As I noted in my "preface", what I am calling "KIF-meta" in that document is an intentionally simplified language. The numerical code stuff might be handy, but it was unnecessary for the points I was trying to illustrate. > As the KIF documentation noted, this allows things like digitised > images or file contents more generally to be referred to as KIF > strings, which might be useful. I would vote to retain this > flexibility if it can be done without significant cost, which I > think it can be by simply retaining the KIF convention (which uses > the # character, as I recall.) You are certainly right about that it would be easy to keep this feature of KIF; and I will defer to you regarding its usefulness. -chris From cmenzel Sun Nov 26 20:30:33 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:00 2003 Subject: In-Reply-To: Your message of "Sun, 26 Nov 2000 15:05:17 CST." Message-ID: One other thing. As noted, I'm proposing we take (quasi-)quoted strings of length >1 to be abbreviations for terms of the form (cc ). The form of these terms is just the result of making the string concatenation operator explicit (unlike a language for an algebra where we just let actual concatenation indicate an application of the relevant algebraic operator -- though even there we need to disambiguate with parens) in the context of KIF's Lispy syntax. Consequently, the clause for `' in the BNF is wrong; it should be: ::= "" | (cc ) And the corresponding axiom for `Quoterm' should be: (<=> (Quoterm ?x) (or (exists (?y) (and (Char ?y) (= ?x "\"\?y\\""))) (exists (?y ?z) (and (Quoterm ?y) (Quoterm ?z) (= ?x "(cc \?y\ \?z\)"))))) Just to look at it, the unabbreviated form of this axiom reads: (<=> (Quoterm ?x) (or (exists (?y) (and (Char ?y) (= ?x (cc (cc """ ?y) """)))) (exists (?y ?z) (and (Quoterm ?y) (Quoterm ?z) (= ?x (cc (cc (cc (cc (cc (cc (cc "(" "c") "c") " ") ?y) " ") ?z) ")")))))) A further consequence of all this, I believe, is that the double quote character needn't be escaped in KIF-meta proper; we can just take `"' to be a character rather than `\"'. The quoted term `"""' denoting the double quote is unproblematic, as the BNF for a requires that a occur between two double quotes. Hence, there is no possibility of ambiguity. However, we will still want to escape the double quote in our abbreviations to avoid abbreviational ambiguity. E.g., if we want to abbreviate `(cc (cc (cc (cc "a" """) " ") """) "b")' (which refers to the string `a" "b'), we should use `"a\" \"b"' instead of `"a" "b"', which otherwise in a KIF-meta atomic sentence or function term would be ambiguous between the string in question as a single argument and the individual strings `"a"' and `"b"' as separate arguments. -chris From sowa at bestweb.net Sun Nov 26 21:17:59 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:31:00 2003 Subject: purpose of quoting Message-ID: <3a21e077.f927.0@bestweb.net> Pat et al., I always thought that the underlying assumption behind the SUO was that the upper ontology must establish the minimum foundation for describing everything. There are three ways to proceed: 1. Top down: Start from T and add axioms and definitions. 2. Bottom up: Start from the complete OED and look for possible generalizations. 3. Iterative: Do a little of both and keep repeating until you have a hierarchy with the top node at #1 and the leaves at #2. The third option is what Lenat & Co. have been doing with Cyc for the past 16 years. They have done a lot of good work, but the result has disturbing similarities to Microsoft Windows: 1. It is very big and undocumented. Nobody understands it except possibly the developers, but some of us strongly suspect that they don't understand it either. 2. The parts that we can see (the top levels) do not have a clean, systematic structure that anyone feels comfortable with. 3. It is a closed source, proprietary system that prevents the academic community from examining and criticizizg its foundations. Consequently, my view of the ontology project(s) we have been doing since 1996 (the workshops sponsored by NCITS T2 and the current SUO) is that we start with a "rational reconstruction" of the foundations -- both logical and ontological -- in a way that would enable anyone and everyone to extend them in any way they see fit. In short, I view it as the GNU/Linux counterpart to Cyc (but with an open invitation to the Cyclers to collaborate). Chris W. wrote: >>Isn't this a little ambitious? Pat H. responded: >No, since the SUO is supposed to be the upper ontology for >EVERYTHING. That includes things like Turing machines and aircraft >control systems, as well as diseases of Welsh mountain goats, oil >transportation systems and tropical shellfish. >(As an aside, I am constantly surprised that people can be so >enthusiastic about an upper ontology which is supposed to be suitable >for a world-wide standard, and simultaneously so narrowminded about >what they think an ontology is going to be talking about.) I agree with Pat. And I don't believe that designing a fully general system is any harder than designing a large special case. Cyc started as a frame-based system in 1984, and they kept adding features until they ended up with full FOL plus metalevel capabilities. As Lenat keeps repeating, every one of the features in the current CycL is there because it is necessary for to handle practical problems. There are lots of systems that support full FOL plus metalevels, including CycL. So we're not starting from scratch. We should look at what is already there and make sure that we can support it -- with KIF'99 as a starting point to work from. John Sowa From phayes at ai.uwf.edu Mon Nov 27 11:14:34 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:00 2003 Subject: Quotation again; and a note on recursion In-Reply-To: <200011270039.eAR0dXA21089@philebus.tamu.edu> References: <200011270039.eAR0dXA21089@philebus.tamu.edu> Message-ID: > > First, let us allow variables in the function and relation positions > > of expressions, which will require a small change to the basic syntax. > >That should be ok as long as the semantics is done carefully. This >might require the "Stickel semantics" that I promised but have yet to >deliver. I will probably just have to give a short presentation at >the workshop. I am trying to get a suitable semantics done in a neat fashion also. (Its easy to do it in an ugly and complicated fashion :-) What needs doing elegantly is specifying a general notion of 'stratified' which formulae should conform to, without introducing a fully-fledged type heirarchy.) After further thought I now think that the 'Stickel semantics' isn't really workable, in spite of my initial enthusiasm for it on the telecon. For example, consider the definition of reflexive: (iff (reflexive ?r) (forall (?x)(?r ?x ?x))) The fact that the language allows the same NAME to be used both for an individual and for a relation (but treats them as distinct neverthless, ie allows 'punning') is of little use here, since the relevant co-occurence involves a variable. If the Stickel semantics means that a single variable used in this way has to be treated as a 'pun' then I don't think this is even worth bothering with: the syntactic damage done to the notion of quantifier binding would be more trouble than it is worth, especially since the resulting language isn't of much practical utility. > > Second, more to the current point, why do you use a distinct syntax > > for plain quotation and quasi-quotation? > >I didn't think I did. Are you sure you are not referring to the >distinction between quotation and quasi-quotation in the >*metalanguage* in which the document is written? ..... Oh, I see. Indeed I was making this mistake, sorry. >...... > > This is a very basic issue which we need to address, in fact: all > > finite things, including lists, character strings and integers, are > > intrinsically undefinable in FOL. Maybe we should have a 'recursive' > > extension which explicitly allows recursion and has a special > > minimum-fixed-point semantic specification? > >We could certainly add a theory of recursive definition, but, frankly, >I think axioms like the above are probably all anyone needs for >ontology (??). In FOL, nonstandard models will always be with us. >And, of course, as you well know, nothing we *say*, even in a >higher-order language, can force a higher-order interpretation, even >if we supply one. So I'm not sure your proposed recursion extension >would buy us much more than we have already. I wonder, why do people never get worried about the fact that recursion in programming languages might allow nonstandard models, and feel free to use non-first-order (minimum-fixed-point) semantics, without feeling that they are 'cheating'? Is it because the computational process of recursion (ie recursive-definition-unwrapping) is so restricted, considered as a mode of inference? There does seem to be something here worth considering. I agree (as you know) that there is little point in our declaring that we have noncomputable powers of definition, but the minimal-fixed-point semantics is routinely used to capture precisely the content of computational specifications, so maybe we can take advantage of this insight in giving a fixpoint semantics to recursive definitions. I think the right way to approach this might be to think of the recursions as part of an idealised proof theory rather than part of the model theory, and to think of a recursive definition as a (computationally well-defined) summary of an infinite RE set of sentences gotten by all the recursive unpackings. This set of sentences is defined by a fixpoint 'semantics' applied to the recursion, but as far as the model theory is concerned it is just a set of sentences and has the usual truth rules. So recursive definitions, in this perspective, are really a way to make the logic 'computationally infinitary'. This could be an extension to the core, by the way, one that has an explicit 'definition' syntax (not as baroque as that from KIF, but one which makes recursions explicit.) The meaning of "is defined as" (or whatever syntax we invent) would be the operation of 'expanding' the definition into some appropriate finite subset of the infinite set of possible expansions. The subtlety involved in this will be the fact that the choice of which set to terminate the recursion will depend in general on the denotations of some of the symbols involved in the particular instance of the defined concept, so this is a genuinely 'semantic' business, even though it doesnt really put the Y-operator into the model theory in a full-blooded way.. > > Fourth, although we havnt discussed this yet, KIF in fact allows > > 'character strings' to contain arbitrary sequences of 'characters' > > which are specified by numerical codes. > >Right. As I noted in my "preface", what I am calling "KIF-meta" in >that document is an intentionally simplified language. The numerical >code stuff might be handy, but it was unnecessary for the points I was >trying to illustrate. OK, fair enough. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From cmenzel Mon Nov 27 12:04:55 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:01 2003 Subject: Quotation again; and a note on recursion In-Reply-To: Your message of "Mon, 27 Nov 2000 11:14:34 CST." Message-ID: > After further thought I now think that the 'Stickel semantics' isn't > really workable, in spite of my initial enthusiasm for it on the > telecon. For example, consider the definition of reflexive: > > (iff (reflexive ?r) (forall (?x)(?r ?x ?x))) > > The fact that the language allows the same NAME to be used both for > an individual and for a relation (but treats them as distinct > neverthless, ie allows 'punning') is of little use here, since the > relevant co-occurence involves a variable. > > If the Stickel semantics means that a single variable used in this > way has to be treated as a 'pun' then I don't think this is even > worth bothering with: the syntactic damage done to the notion of > quantifier binding would be more trouble than it is worth, especially > since the resulting language isn't of much practical utility. That might be your Stickel semnatics, Pat, but it's not mine! In the version I will be proposing, there is no punning; relations are themselves fully-fledged objects over which the quantifiers range. Obviously, I am not identifying relations with sets of n-tuples. (Though actually, one *could* do that in a non-well-founded set theory, but it's easier not to go that route.) The basic idea is just to include a bunch of things called relations in your domain and assign each of them an appropriate extension. `(?r ?x ?x)' will be true just in case `?r' is assigned a relation such that is in its extension for all objects e in the domain -- including itself. Self-instantiation in this semantics is utterly harmless. You just can't permit yourself the power to create relations from arbitrary conditions; notably, we reject the general comprehension schema (exists (?r) (forall (?x) (<=> (?r ?x) FOO))) for any condition FOO -- let FOO be `(not (?x ?x))' and yer hosed. But frankly, I don't know that I've ever seen an ontology that required even the existence of innocuous logically complex relations (e.g., conjuunctive properties like *being red and round*), let alone ones defined by *arbitrary* condition. Comprehension schemas are useful in logic, and do some nice philosophical work in intensional logic and the semantics of natural language, but I am dubious about their usefulness in knowledge engineering. They *might* be useful in the form of lambda predicates, which I recall John praising at one point. But I suspect that all John wants is to allow simple boolean and quantified combinations of relations, and those can be introduced into the Stickel semantics just by closing the class of relations under corresponding semantic operators and placing certain simple syntactic restrictions on the defining condition FOO (notably (among others), that `?x' can't occur free therein). -chris From phayes at ai.uwf.edu Mon Nov 27 12:18:53 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:01 2003 Subject: Quotation again; and a note on recursion In-Reply-To: <200011271804.eARI4uO23724@philebus.tamu.edu> References: <200011271804.eARI4uO23724@philebus.tamu.edu> Message-ID: > >That might be your Stickel semnatics, Pat, but it's not mine! In the >version I will be proposing, there is no punning; relations are >themselves fully-fledged objects over which the quantifiers range. >Obviously, I am not identifying relations with sets of n-tuples. >(Though actually, one *could* do that in a non-well-founded set >theory, but it's easier not to go that route.) The basic idea is just >to include a bunch of things called relations in your domain and >assign each of them an appropriate extension. `(?r ?x ?x)' will be >true just in case `?r' is assigned a relation such that is in >its extension for all objects e in the domain -- including itself. >Self-instantiation in this semantics is utterly harmless. You just >can't permit yourself the power to create relations from arbitrary >conditions; notably, we reject the general comprehension schema > >(exists (?r) > (forall (?x) > (<=> (?r ?x) FOO))) > >for any condition FOO -- let FOO be `(not (?x ?x))' and yer hosed. >But frankly, I don't know that I've ever seen an ontology that >required even the existence of innocuous logically complex relations >(e.g., conjuunctive properties like *being red and round*), let alone >ones defined by *arbitrary* condition. Comprehension schemas are >useful in logic, and do some nice philosophical work in intensional >logic and the semantics of natural language, but I am dubious about >their usefulness in knowledge engineering. They *might* be useful in >the form of lambda predicates, which I recall John praising at one >point. But I suspect that all John wants is to allow simple boolean >and quantified combinations of relations, and those can be introduced >into the Stickel semantics just by closing the class of relations >under corresponding semantic operators and placing certain simple >syntactic restrictions on the defining condition FOO (notably (among >others), that `?x' can't occur free therein). OK, I think we see eye to eye on this. I agree with you entirely about comprehension. The nearest thing Ive ever seen to comprehension in an ontological setting is some ideas from Jerry Hobbs, who has a schema for generating what he calls 'eventualities' from assertions, which turns out to be exactly like your proposed closure involving boolean and quantifier combinations. This seems pretty far-out, ontologically speaking, but it is still first-order and sub-Henkin. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From cmenzel Mon Nov 27 12:38:26 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:01 2003 Subject: Quotation again; and a note on recursion In-Reply-To: Your message of "Mon, 27 Nov 2000 12:18:53 CST." Message-ID: I wrote: > The basic idea is just to include a bunch of things called relations > in your domain and assign each of them an appropriate extension. > `(?r ?x ?x)' will be true just in case `?r' is assigned a relation > such that is in its extension for all objects e in the domain > -- including itself. That should have read: `(?r ?x ?x)' will be true just in case `?r' is assigned a "relation" R and `?x' an object e such that is in R's extension. `(reflexive ?r)' will thus be true just in case is in the extension of R for all objects e in the domain -- including itself. -chris From stickel at AI.SRI.COM Tue Nov 28 03:59:06 2000 From: stickel at AI.SRI.COM (Mark Stickel) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 Message-ID: <200011280959.BAA15837@Pacific.AI.SRI.COM> Lisp languages are partly characterized by the number of "name spaces" they use. For example, Scheme is a "Lisp-1" language because it uses a single name space for functions and variables. On the other hand, Common Lisp is called a "Lisp-2" language because it uses separate name spaces for functions and variables, e.g., LIST designates the list-creating function but can have a separate variable value like 13; context determines which measning is used. Using this terminology, I propose that three name space FOL (FOL-3) be used in the KIF core and that one name space FOL (FOL-1) be available as an extension. In FOL-3, there are separate name spaces (i.e., interpretations or symbol-to-value maps) for predicate, function, and constant symbols. A permissive grammar will allow any word to be used simultaneously in any of these ways, unlike textbook logics where predicate, function, and constant symbols are disjoint. In FOL-3, (P (P P) P) is a legal expression, where P is a binary predicate symbol, a unary function symbol, and a constant symbol. Predicate, function, and constant occurrences can be distinguished syntactically. In the model theory, occurrences of P in predicate position are interpreted as predicates, occurrences of P in function position are interpreted as functions, occurrences of P in constant position are interpreted as constants, as is customary for first-order logic. In FOL-3, there is no prescribed relationship between the predicate, function, and constant interpretations of a single name. Since the constant P does not refer in FOL-3 to the predicate or function P, there is no need to go beyond standard first-order semantics by including relations in the domain of variable and constant values. For quasi-higher-order or meta-level reasoning, we often want to refer to predicates and functions by constants with the same name. The domain will now normally include relations. FOL-1 is a refinement of FOL-3 in which the following relationships are enforced. If P is an N-ary function symbol, then P is also an N+1-ary predicate symbol and (<=> (= (P ?X1 ... ?XN) ?Y) (P ?X1 ... ?XN ?Y)) holds. If P is an N-ary predicate symbol, then P is also a constant symbol that is interpreted as the P relation and something like (<=> (P ?X) (INSTANCE-OF ?X P)) holds. In FOL-1, (P (P P) P) is again a legal expression, but all occurrences of P refer to the same functional binary relation. If variables are to be used in predicate and function position, it seems reasonable to allow this only in the FOL-1 extension, not in the FOL-3 core. From sowa at bestweb.net Tue Nov 28 08:36:02 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:31:01 2003 Subject: purpose of quoting Message-ID: <3a23d0e2.b4ee.0@bestweb.net> Adam, Yes, I should have made that point clear: >I'd agree with your whole message except what might be implied by >juxtaposing your two lists. The fact that Cyc has some faults doesn't >follow from the fact that it was developed top-down and bottom-up at the >same time (I don't think you believe that either but it's worth >clarifying). We can document what we do, have a clean upper level, and, as >required by our standards effort, make the result open source, while >conducting the construction of the ontology as a mixed, top-down and >bottom-up effort. I agree. I believe that the iterative approach is the best for us as well as for Cyc. My major point is that it's now time to step back, take a hard look at what has been done, and clean it up while preserving the best parts. We should take advantage of the 16 years of work on Cyc as well as the parallel activity going on around the world in related fields. In any case, the ultimate goals for the SUO should be as broad as the original (and current) goals for Cyc. But to some extent, our goals are less ambitious because we don't have to start from scratch. John From andersen at ontologyworks.com Tue Nov 28 08:57:03 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 References: <200011280959.BAA15837@Pacific.AI.SRI.COM> Message-ID: <3A23C7BF.4CECBF32@ontologyworks.com> Mark Stickel wrote: > > Lisp languages are partly characterized by the number of "name spaces" > they use. For example, Scheme is a "Lisp-1" language because it uses > a single name space for functions and variables. On the other hand, > Common Lisp is called a "Lisp-2" language because it uses separate > name spaces for functions and variables, e.g., LIST designates the > list-creating function but can have a separate variable value like 13; > context determines which measning is used. > > Using this terminology, I propose that three name space FOL (FOL-3) be > used in the KIF core and that one name space FOL (FOL-1) be available > as an extension. All... - Lemme know if what I'm going to say has been covered. I haven't - been paying attention as I should This brings up a generally good point - namespaces. As suggested by Chris Menzel, theory extensions bring extensions to the lexicon of non-logical symbols. An alternative to a specific metalogical predicate to arrange inheritance or inclusion of theories would be to do the same trick with Java-style namespaces. So, every symbol would have a namespace or package prefix (often implicit and interpreted by the compiler). An example best illustrates this: Theory a: (forall (?x) (<=> (p ?x) (q ?x))) here p and q are introduced in theory a as non-logical symbols. Theory b: (forall (?x) (or (a.p ?x) (r ?x))) where r is new in theory b. This way, theory b implicitly imports/includes theory a by virtue of mentioning one of a's symbols. To make this work, appropriate syntactic modifications would have to be made and rules regarding interpretation of namespace-relative names in definitions. Just a thought. ...bill P.S. I think Common Lisp is more correctly characterized as a Lisp-5 language. Each symbol (can) denote 1) a function, 2) a value, 3) a property list, 4) a type (predicate), and 5) a name. My memory is fuzzy (been 4 years since I've done CL) but it's something like this. One of the reasons I like Scheme... From stickel at AI.SRI.COM Tue Nov 28 10:28:04 2000 From: stickel at AI.SRI.COM (Mark Stickel) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: <3A23C7BF.4CECBF32@ontologyworks.com> (message from Bill Andersen on Tue, 28 Nov 2000 09:57:03 -0500) Message-ID: <200011281628.IAA16368@Pacific.AI.SRI.COM> > P.S. I think Common Lisp is more correctly characterized as a Lisp-5 > language. Each symbol (can) denote 1) a function, 2) a value, 3) a > property list, 4) a type (predicate), and 5) a name. My memory is > fuzzy (been 4 years since I've done CL) but it's something like this. > One of the reasons I like Scheme... Symbols (can) denote packages too. I've heard CL referred to as a Lisp-7, but never examined the list. Referring to it as a Lisp-2 oversimplifies somewhat, but accurately characterizes the different meanings of (LIST LIST) in Scheme and Common Lisp. I think you're right that something like Lisp package prefixes for symbols might be useful in KIF. One could thus avoid unintended name collisions when importing theories. From phayes at ai.uwf.edu Tue Nov 28 11:41:06 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: <200011280959.BAA15837@Pacific.AI.SRI.COM> References: <200011280959.BAA15837@Pacific.AI.SRI.COM> Message-ID: >Lisp languages are partly characterized by the number of "name spaces" >they use. For example, Scheme is a "Lisp-1" language because it uses >a single name space for functions and variables. On the other hand, >Common Lisp is called a "Lisp-2" language because it uses separate >name spaces for functions and variables, e.g., LIST designates the >list-creating function but can have a separate variable value like 13; >context determines which measning is used. > >Using this terminology, I propose that three name space FOL (FOL-3) be >used in the KIF core and that one name space FOL (FOL-1) be available >as an extension. The 'punning' in FOL-3 is of no practical use and can only be confusing. (It violates the widespread convention that every token of a name has the same denotation.) So if we do adopt FOL-3 as the core, let us not allow 'punning', and keep the name spaces separate from one another. However, I would argue that there is no practical reason for imposing this restriction (to separate namespaces) in the core language, and that relaxing the KIF restriction, to allow quantification over relations, is of immediate practical utility in almost every ontology, and does not in fact go "beyond standard first-order semantics" in anything other than a trivial sense. Standard first-order semantics relates all quantifiers to a universe of individuals. (Sorting the language partitions this universe in various ways.) Now, the ONLY semantic requirement on this universe is that it be non-empty. Nothing is said, in the standard first-order semantics, about the nature of the entities in the universe: they can be any kinds of things whatsoever. So it is not correct to claim, as Mark and others have done, that to include relations in the universe 'goes beyond' first-order semantics. One can in fact construct a perfectly fine first-order interpretation over a universe which consists of nothing but relations. What makes a semantics non-first-order is not the nature of the things in the universe, but the scope of the quantifiers. If quantifiers over relations are required to range over universes built by set-theoretic constructions from the first-order universe, then indeed we may have a genuinely non-first-order logic. For example, if we insist that relation quantifiers range over universes which contain *all* relations over some base universe, or *all lambda-definable* relations, then the logic changes its character. But if there are no such requirements on the minimal size of the universe, then fist-order logic (and meta-logic) applies without serious change. I believe that almost every ontology language that has been put to serious practical use has found a need for quantification over relations, and for expressing relations between relations. Many of them have had to resort to various subterfuges to actually sneak this past the FOL censors, such as the use of 'holds' or some other such 'dummy' relation. In his recent KIF axiomatisation of DAML, Richard Fikes has had to use a similar trick. (Extract from an email between us yesterday: Pat: >> OK, on further study I see what you are doing. You are using >> PropertyValue as a kind of DAML version of 'holds', and you need >> to do this because you have to quantify over the first argument >> in later axioms. Richard: >Exactly. Ore Lassila commented (to Richard): >7) Ax56, Ax 59: as a shorthand, you could do the same for "range" and >"domain" as you did for "type", so that one could write something like > > (Domain X Y) > >instead of > > (PropertyValue domain X Y) and he is right, but it would have been a lot easier and more natural if Richard could have used these 'shorthand' forms directly, instead of being forced to use a dummy relation to force the relation names into an object position.) >For quasi-higher-order or meta-level reasoning, we often want to >refer to predicates and functions by constants with the same name. ..... >If P is an N-ary function symbol, then P is also an N+1-ary predicate >symbol and (<=> (= (P ?X1 ... ?XN) ?Y) (P ?X1 ... ?XN ?Y)) holds. This is a separate proposal. I dont have a strong opinion about this: KIF allows it, but I wouldn't weep if we disallowed it. It looks odd at first sight but it is semantically natural (independently of whether or not we quantify over relations.) >If P is an N-ary predicate symbol, then P is also a constant symbol >that is interpreted as the P relation and something like (<=> (P ?X) >(INSTANCE-OF ?X P)) holds. There is no need to introduce this 'instance-of' relation, and it seems to me to be confusing. If you want it, it can easily be axiomatised ( just put a query mark in front of the P in your axiom and universally quantify it.) Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Tue Nov 28 11:58:52 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: <3A23C7BF.4CECBF32@ontologyworks.com> References: <200011280959.BAA15837@Pacific.AI.SRI.COM> <3A23C7BF.4CECBF32@ontologyworks.com> Message-ID: > All... > > - Lemme know if what I'm going to say has been covered. I haven't > - been paying attention as I should No, it hasnt, and it is something we should consider. > This brings up a generally good point - namespaces. As suggested >by Chris Menzel, theory extensions bring extensions to the lexicon >of non-logical symbols. An alternative to a specific metalogical >predicate to arrange inheritance or inclusion of theories would be >to do the same trick with Java-style namespaces. So, every symbol >would have a namespace or package prefix (often implicit and >interpreted by the compiler). DAML has adopted a very specific such convention, in which every identifier in every ontology must be a URI, and there is a convention that any 'bare' names are shorthand for the URI got by prefixing the URL of the webpage on which they occur. So that 'a' used on, say, http://www.cs.man.ac.uk/~horrocks/DAML-OIL is in fact understood to 'really' be http://www.cs.man.ac.uk/~horrocks/DAML-OIL#a . This convention is obviously designed strictly for Web-based ontologies, but we could adopt a similar kind of convention. > An example best illustrates this: > > Theory a: > > (forall (?x) (<=> (p ?x) (q ?x))) > > here p and q are introduced in theory a as non-logical symbols. > > Theory b: > > (forall (?x) (or (a.p ?x) (r ?x))) > > where r is new in theory b. > > This way, theory b implicitly imports/includes theory a by virtue >of mentioning one of a's symbols. Yes, exactly. In fact in DAML, one theory can declare a prefix (say 'horr:') to be a shorthand for the name of any other ontology (http://www.cs.man.ac.uk/~horrocks/DAML-OIL), and then use this prefix to indicate that an identifier is being used in the same sense as it is used in that other ontology, so that 'horr:a' means what I said earlier. This trick is widely used to 'import' meaning from one ontology into another. > To make this work, appropriate syntactic modifications would have >to be made and rules regarding interpretation of namespace-relative >names in definitions. Actually, I don't think we really need to change anything. The current syntax allows almost any string not starting with '?' to be a name, after all. What it WOULD need is the adoption of some conventions to indicate importation, and maybe some name-prefix-declaring syntax. Just as a general comment, namespace management is one area where the W3C folk are way ahead of us; its been central to them since the beginning, and they now have internationally accepted conventions for registering and distinguishing namespaces, resolving ambinguity, etc. . So if we are going to get involved in this we ought to take this stuff into account. Or, maybe the right conclusion is that we should leave this to them, and just make sure that we don't define things too narrowly to allow their conventions to operate. For example, XML compliance apparently requires that character strings use Unicode rather than ASCII, a point we might need to be sensitive to. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From cmenzel Tue Nov 28 12:19:43 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: Your message of "Tue, 28 Nov 2000 01:59:06 PST." <200011280959.BAA15837@Pacific.AI.SRI.COM> Message-ID: > In FOL-3, (P (P P) P) is a legal expression, where P is a binary > predicate symbol, a unary function symbol, and a constant symbol. > Predicate, function, and constant occurrences can be distinguished > syntactically. > > In the model theory, > occurrences of P in predicate position are interpreted as predicates, > occurrences of P in function position are interpreted as functions, > occurrences of P in constant position are interpreted as constants, > as is customary for first-order logic. > > In FOL-3, there is no prescribed relationship between the predicate, > function, and constant interpretations of a single name. Since the > constant P does not refer in FOL-3 to the predicate or function P, > there is no need to go beyond standard first-order semantics by > including relations in the domain of variable and constant values. As Pat notes, merely including relations in the domain does not of itself move us out of the first-order arena. I suggest a model theory along the following lines: The domain D of the quantifiers can be partitioned into n-place relations (in separate partitions) and everything else (call these "individuals"). Relations are *not* taken to be sets (though, as I noted earlier, they could be so taken if we adopt a non-well-founded set theory); they are just objects in the domain. However, there is a function ext that takes each n-place relation to a set of n-tuples of things in the domain. Since a relation so understood can obviously be in (an n-tuple in) its own, or another relation's, extension, sentences of the form (R P) (in particular, (P P)) are unproblematic. A further (equivalent) possibility here would be to think of relations as having functions from n-tuples to truth values as extensions. That way we wouldn't have to "pun" on a predicate P depending on whether it occurs as a predicate or as a function symbol; on this approach, it always occurs as a function symbol. (This requires including T and F in the domain of quantification, but that is not problematic -- I don't think...) -chris From cmenzel Tue Nov 28 12:34:25 2000 From: cmenzel (Chris Menzel) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: Your message of "Tue, 28 Nov 2000 11:41:06 CST." Message-ID: > What makes a semantics non-first-order is not the nature of the > things in the universe, but the scope of the quantifiers. A very important and usually unappreciated point. > If quantifiers over relations are required to range over universes > built by set-theoretic constructions from the first-order universe, > then indeed we may have a genuinely non-first-order logic. I'd put it more strongly, since most any interpretation of quantification over relations -- whether first-order or not -- will involve set theoretic constructions from the first-order universe. > For example, if we insist that relation quantifiers range over > universes which contain *all* relations over some base universe, Yes, some construction in terms of the entire power set of the first-order universe is essential to a true higher-order semantics. > or *all lambda-definable* relations, then the logic changes its > character. Not necessarily. Typically, guaranteeing all lambda-definable relations just means adopting closure conditions of some sort on the relations. Granted, one way to get that is to interpret relation quantifers in terms of the full power set of the first-order domain, but the closure conditions themselves don't require that, and in particular don't necessarily bump up the cardinality of the domain of relations beyond countable. -chris From phayes at ai.uwf.edu Tue Nov 28 12:42:41 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: <200011281819.eASIJhd26606@philebus.tamu.edu> References: <200011281819.eASIJhd26606@philebus.tamu.edu> Message-ID: > I suggest a model theory >along the following lines: > >The domain D of the quantifiers can be partitioned into n-place >relations (in separate partitions) and everything else (call these >"individuals"). Relations are *not* taken to be sets (though, as I >noted earlier, they could be so taken if we adopt a non-well-founded >set theory); they are just objects in the domain. However, there is a >function ext that takes each n-place relation to a set of n-tuples of >things in the domain. Since a relation so understood can obviously be >in (an n-tuple in) its own, or another relation's, extension, >sentences of the form (R P) (in particular, (P P)) are unproblematic. Yes, I think this idea is better than the idea I was going to propose, so I won't propose it. I would be interested in seeing what happens to the Russell paradox in this framework, though. >A further (equivalent) possibility here would be to think of relations >as having functions from n-tuples to truth values as extensions. That >way we wouldn't have to "pun" on a predicate P depending on whether it >occurs as a predicate or as a function symbol; on this approach, it >always occurs as a function symbol. Just a remark, but this is a slightly different way of indentifying functions and relations than the way Mark was suggesting (and which KIF currently uses) in which every function is considered to be a relation, so that(= (F A B) C) can be written (F A B C). Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Tue Nov 28 13:03:45 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:01 2003 Subject: FOL-3 and FOL-1 In-Reply-To: <200011281834.eASIYPL26644@philebus.tamu.edu> References: <200011281834.eASIYPL26644@philebus.tamu.edu> Message-ID: > > > or *all lambda-definable* relations, then the logic changes its > > character. > >Not necessarily. Typically, guaranteeing all lambda-definable >relations just means adopting closure conditions of some sort on the >relations. Granted, one way to get that is to interpret relation >quantifers in terms of the full power set of the first-order domain, >but the closure conditions themselves don't require that, and in >particular don't necessarily bump up the cardinality of the domain of >relations beyond countable. True, but I would still say that the logic changes its character. It is 'semantically first-order'; but even with the Henkin semantics, proofs in type theory have a very different flavor than what is usually called FOL. For example, it is impossible to compute most general unifiers when lambda-conversion is allowed. My point was to contrast that (admittedly rather drastic) kind of 'extension' to the one under discussion, which is much more tractable and indeed has a proof theory which is identical to 'normal' FOL. The "higher-order" quantifiers here are exactly like all the other quantifiers, because they are the same kind of quantification. Resolution works and is complete, and so on: nothing really changes, but one can say what one wants to say. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From andersen at ontologyworks.com Tue Nov 28 13:22:47 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:31:02 2003 Subject: FOL-3 and FOL-1 References: <200011280959.BAA15837@Pacific.AI.SRI.COM> <3A23C7BF.4CECBF32@ontologyworks.com> Message-ID: <3A240607.D9493743@ontologyworks.com> pat hayes wrote: > Yes, exactly. In fact in DAML, one theory can declare a prefix (say > 'horr:') to be a shorthand for the name of any other ontology > (http://www.cs.man.ac.uk/~horrocks/DAML-OIL), and then use this > prefix to indicate that an identifier is being used in the same sense > as it is used in that other ontology, so that 'horr:a' means what I > said earlier. This trick is widely used to 'import' meaning from one > ontology into another. Right, but *does* DAML use it? I have not gathered that there is any such convention for importation or, if there is a convention, what the semantics are. Maybe Adam or Pat can help here. > > To make this work, appropriate syntactic modifications would have > >to be made and rules regarding interpretation of namespace-relative > >names in definitions. > > Actually, I don't think we really need to change anything. The > current syntax allows almost any string not starting with '?' to be a > name, after all. What it WOULD need is the adoption of some > conventions to indicate importation, and maybe some > name-prefix-declaring syntax. Well, (I don't have any recent KIF syntactic spec in front of me) you'd have to change the definition of word to explicitly support the prefixation syntax. Not any sequence of characters would be allowed, e.g.: foo.bar:fred, but * foo:bar:fred so it's not sufficient to say that any string not beginning with '?' is kosher... > Just as a general comment, namespace management is one area where the > W3C folk are way ahead of us; its been central to them since the > beginning, and they now have internationally accepted conventions for > registering and distinguishing namespaces, resolving ambinguity, etc. > . So if we are going to get involved in this we ought to take this > stuff into account. Or, maybe the right conclusion is that we should > leave this to them, and just make sure that we don't define things > too narrowly to allow their conventions to operate. For example, XML > compliance apparently requires that character strings use Unicode > rather than ASCII, a point we might need to be sensitive to. I second Pat here. We should decide and record the decision, either way it goes. ...bill -- Bill Andersen Chief Technology Officer - Ontology Works 1130 Annapolis Road, Suite 203, Odenton, MD 21113 andersen@ontologyworks.com / 410-674-7600 From gruning at cme.nist.gov Tue Nov 28 13:55:04 2000 From: gruning at cme.nist.gov (Michael Gruninger) Date: Fri Oct 10 03:31:02 2003 Subject: KIF meeting agenda Message-ID: <3A240D98.330FBB95@cme.nist.gov> -------------- next part -------------- A non-text attachment was scrubbed... Name: tamu-agenda.tex Type: application/x-tex Size: 1006 bytes Desc: not available Url : http://philebus.tamu.edu/pipermail/kif/attachments/20001128/d9268e4e/tamu-agenda.tex From stickel at AI.SRI.COM Tue Nov 28 19:27:06 2000 From: stickel at AI.SRI.COM (Mark Stickel) Date: Fri Oct 10 03:31:02 2003 Subject: FOL-3 and FOL-1 In-Reply-To: (message from pat hayes on Tue, 28 Nov 2000 11:41:06 -0600) Message-ID: <200011290127.RAA16950@Pacific.AI.SRI.COM> > that relaxing the KIF restriction, to allow quantification over > relations, is of immediate practical utility in almost every > ontology, and does not in fact go "beyond standard first-order > semantics" in anything other than a trivial sense. My concern is more that an interpretation that includes relations is nonstandard than that it is necessarily non-first-order. For theorem proving, groups are often axiomatized as (= (f e ?x) ?x) (= (f (g ?x) ?x) e) (= (f (f ?x ?y) ?z) (f ?x (f ?y ?z))) rather than (=> (group-element ?x) (= (f e ?x) ?x)) (=> (group-element ?x) (= (f (g ?x) ?x) e)) (=> (= (f (f ?x ?y) ?z) (f ?x (f ?y ?z)))) The intended interpretation of the former has the set of group elements as the domain. I want to keep doing this without violating the spirit of KIF. However, if the KIF standard prescribes a model theory for the core that includes relations in the domain, this creates some dissonance with the practice of axiomatizing groups as above with the above intended interpretation. (Of course, any proof will derive valid conclusions regardless of the interpretation, so the problem is more conceptual than practical.) While "allow[ing] quantification over relations is of immediate practical utility", I think it is also important to preserve the possibility of interpretations whose domain does not include relations. I prefer that pushing relations into the domain be reserved for an extension and that the core be standard first-order logic with the usual freedom to choose an interpretation. On the other hand, if you want to include the capacity to use relation names as constant symbols and/or quantify over relations in the core, I would ask for some careful wording about the model theory in the KIF standard that preserves the capacity for relationless interpretations when these features are not used. From sowa at bestweb.net Wed Nov 29 09:35:57 2000 From: sowa at bestweb.net (John F. Sowa) Date: Fri Oct 10 03:31:02 2003 Subject: minutes for Nov 9 KIF meeting Message-ID: <3a25306d.441b.0@bestweb.net> Mike wrote >What about the fact that a language for authoring and a language for interchange >have conflicting requirements? How to choose? An authoring language should be easy to read and write by human beings, and an interchange language should be efficient to parse and generate by computers. But anything that anyone authors should be possible for computers to interchange. Therefore, the two kinds of languages should have identical expressive power. I believe that is the motivation for having SUO-KIF as an interchange language and a language such as ACE (or the proposed SUO-CE) as an (optional) authoring language. SUO-CE and SUO-KIF should be identical in expressive power, and either one should be automatically translatable to the other. Anyone who doesn't like SUO-CE could use SUO-KIF for all purposes. Anyone who doesn't like SUO-KIF should be able to write SUO-CE, but should at least be able to read SUO-KIF in order to check the results -- just as people who use C should have at least some acquaintance with assembly language. John Sowa From mfu at redwood.rt.cs.boeing.com Wed Nov 29 10:06:45 2000 From: mfu at redwood.rt.cs.boeing.com (Michael Uschold) Date: Fri Oct 10 03:31:02 2003 Subject: minutes for Nov 9 KIF meeting Message-ID: <200011291606.IAA13184@thumper.rt.cs.boeing.com> Adam says: Mike, In order to support the SUO project, I believe SUO-KIF should be for authoring ontologies. As a separate point, it would be beneficial to have a language for interchange that is consistent with the language for authoring. Adam ---- What about the fact that a language for authoring and a language for interchange have conflicting requirements? How to choose? Mike From andersen at ontologyworks.com Wed Nov 29 10:49:09 2000 From: andersen at ontologyworks.com (Bill Andersen) Date: Fri Oct 10 03:31:02 2003 Subject: KIF: Re: minutes for Nov 9 KIF meeting References: <3a25306d.441b.0@bestweb.net> Message-ID: <3A253385.75AEBFEF@ontologyworks.com> "John F. Sowa" wrote: > > Mike wrote > > >What about the fact that a language for authoring and a language for interchange > > >have conflicting requirements? How to choose? > > An authoring language should be easy to read and write by > human beings, and an interchange language should be efficient > to parse and generate by computers. There's no reason to limit consideration to *an* authoring language. Any such language will do, so long as it has the full expressive power of the underlying exchange language and that it can be translated readily into the exchange language. The authoring language could be partially graphical, such as that proposed in IDEF5. An important thing to do would be to define a standard for compliance of authoring languages with the exchange language, the latter being the benchmark. ...bill From whitten at lynx.eaze.net Wed Nov 29 12:10:39 2000 From: whitten at lynx.eaze.net (David Whitten) Date: Fri Oct 10 03:31:02 2003 Subject: KIF: KIF = Authoring OR Interchange ? In-Reply-To: <3A253385.75AEBFEF@ontologyworks.com> from "Bill Andersen" at Nov 29, 2000 11:49:09 AM Message-ID: <200011291810.MAA24733@lynx.eaze.net> > > > Mike wrote > > > > >What about the fact that a language for authoring and a language for interchange > > >have conflicting requirements? How to choose? > > > "John F. Sowa" wrote: > > An authoring language should be easy to read and write by > > human beings, and an interchange language should be efficient > > to parse and generate by computers. > Bill Andersen wrote: > There's no reason to limit consideration to *an* authoring language. > Any such language will do, so long as it has the full expressive power > of the underlying exchange language and that it can be translated > readily into the exchange language. The authoring language could be > partially graphical, such as that proposed in IDEF5. An important > thing to do would be to define a standard for compliance of authoring > languages with the exchange language, the latter being the benchmark. In my opinion, an interchange language should not only be efficient to parse and generate but should be also provide a good basis for inference. As was mentioned previously, there should either be a way of referencing context indirectly or incorporating it directly when necessary. Because KIF == Knowledge Interchange Format, we should be focused on interchange issues, in preference to authoring issues. (In my Opinion) David From mfu at redwood.rt.cs.boeing.com Wed Nov 29 13:45:32 2000 From: mfu at redwood.rt.cs.boeing.com (Michael Uschold) Date: Fri Oct 10 03:31:02 2003 Subject: purpose of quoting Message-ID: <200011291945.LAA23312@thumper.rt.cs.boeing.com> >From John Sowa: Pat et al., I always thought that the underlying assumption behind the SUO was that the upper ontology must establish the minimum foundation for describing everything. There are three ways to proceed: 1. Top down: Start from T and add axioms and definitions. 2. Bottom up: Start from the complete OED and look for possible generalizations. 3. Iterative: Do a little of both and keep repeating until you have a hierarchy with the top node at #1 and the leaves at #2. ===== There is anotehr: middle out, whereby you start with 'cognitively basic', as per Lackoff, concepts. This might include say dog. Then move up to make generalizations, or down to make further distinctions, as appropriate. This was successfully used when building the Enterprise Ontology. ALthough that was only a 100 terms, I see no reason why the approach is likely to be problematic for larger efforts. This is described in our papers. Mike From apease at teknowledge.com Wed Nov 29 13:59:46 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:31:02 2003 Subject: FOL-3 and FOL-1 In-Reply-To: <3A240607.D9493743@ontologyworks.com> References: <200011280959.BAA15837@Pacific.AI.SRI.COM> <3A23C7BF.4CECBF32@ontologyworks.com> Message-ID: <4.2.0.58.20001129114854.01fbb730@helium.teknowledge.com> Bill, Comments below: At 02:22 PM 11/28/2000 -0500, Bill Andersen wrote: >pat hayes wrote: > > > Yes, exactly. In fact in DAML, one theory can declare a prefix (say > > 'horr:') to be a shorthand for the name of any other ontology > > (http://www.cs.man.ac.uk/~horrocks/DAML-OIL), and then use this > > prefix to indicate that an identifier is being used in the same sense > > as it is used in that other ontology, so that 'horr:a' means what I > > said earlier. This trick is widely used to 'import' meaning from one > > ontology into another. > > Right, but *does* DAML use it? I have not gathered that there is >any such convention for importation or, if there is a convention, what >the semantics are. Maybe Adam or Pat can help here. We haven't used it in our work. I'll check to see if other DAML participants have used it. > > > To make this work, appropriate syntactic modifications would have > > >to be made and rules regarding interpretation of namespace-relative > > >names in definitions. > > > > Actually, I don't think we really need to change anything. The > > current syntax allows almost any string not starting with '?' to be a > > name, after all. What it WOULD need is the adoption of some > > conventions to indicate importation, and maybe some > > name-prefix-declaring syntax. > > Well, (I don't have any recent KIF syntactic spec in front of me) >you'd have to change the definition of word to explicitly support >the prefixation syntax. Not any sequence of characters would be >allowed, e.g.: > > foo.bar:fred, but > * foo:bar:fred > >so it's not sufficient to say that any string not beginning with '?' >is kosher... I've attached below a proposal on namespace syntax that I worked out with Matthew West on the SUO list. > > Just as a general comment, namespace management is one area where the > > W3C folk are way ahead of us; its been central to them since the > > beginning, and they now have internationally accepted conventions for > > registering and distinguishing namespaces, resolving ambinguity, etc. > > . So if we are going to get involved in this we ought to take this > > stuff into account. Or, maybe the right conclusion is that we should > > leave this to them, and just make sure that we don't define things > > too narrowly to allow their conventions to operate. For example, XML > > compliance apparently requires that character strings use Unicode > > rather than ASCII, a point we might need to be sensitive to. > > I second Pat here. We should decide and record the decision, >either way it goes. > > ...bill > >-- >Bill Andersen >Chief Technology Officer - Ontology Works >1130 Annapolis Road, Suite 203, Odenton, MD 21113 >andersen@ontologyworks.com / 410-674-7600 X-Sender: apease@helium.teknowledge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Nov 2000 12:51:27 -0800 To: "West, Matthew MR SSI-GREA-UK" , standard-upper-ontology@ieee.org From: Adam Pease Subject: RE: SUO: RE: RE: What language to use In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-standard-upper-ontology@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: standard-upper-ontology X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: standard-upper-ontology-approval@majordomo.ieee.org X-Return-Path: owner-standard-upper-ontology@ieee.org X-MDRedirect: 1 X-MDaemon-Deliver-To: apease@pa.teknowledge.com Matthew, Below is the formal content from your file with my comments. Where I've made a suggestion, I've commented out your original version, added a suggested new version, and inserted any comments I have prefixed by "; [AP]" I like your use of the namespace prefix. If we were to suggest an addition to SUO-KIF http://ltsc.ieee.org/suo/suo-kif.html in line with the example usage we might have change in section 4.1 add the sentence Bracket characters [] denote an expression that is repeated 0 or 1 time. change in section 4.3 to definition for "constant" prefix := initialchar wordchar* / constant := [prefix] initialchar wordchar* -------------------------------------------------------------------------- [snip] ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From apease at teknowledge.com Wed Nov 29 13:59:46 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:31:02 2003 Subject: KIF: Re: FOL-3 and FOL-1 In-Reply-To: <3A240607.D9493743@ontologyworks.com> References: <200011280959.BAA15837@Pacific.AI.SRI.COM> <3A23C7BF.4CECBF32@ontologyworks.com> Message-ID: <4.2.0.58.20001129114854.01fbb730@helium.teknowledge.com> Bill, Comments below: At 02:22 PM 11/28/2000 -0500, Bill Andersen wrote: >pat hayes wrote: > > > Yes, exactly. In fact in DAML, one theory can declare a prefix (say > > 'horr:') to be a shorthand for the name of any other ontology > > (http://www.cs.man.ac.uk/~horrocks/DAML-OIL), and then use this > > prefix to indicate that an identifier is being used in the same sense > > as it is used in that other ontology, so that 'horr:a' means what I > > said earlier. This trick is widely used to 'import' meaning from one > > ontology into another. > > Right, but *does* DAML use it? I have not gathered that there is >any such convention for importation or, if there is a convention, what >the semantics are. Maybe Adam or Pat can help here. We haven't used it in our work. I'll check to see if other DAML participants have used it. > > > To make this work, appropriate syntactic modifications would have > > >to be made and rules regarding interpretation of namespace-relative > > >names in definitions. > > > > Actually, I don't think we really need to change anything. The > > current syntax allows almost any string not starting with '?' to be a > > name, after all. What it WOULD need is the adoption of some > > conventions to indicate importation, and maybe some > > name-prefix-declaring syntax. > > Well, (I don't have any recent KIF syntactic spec in front of me) >you'd have to change the definition of word to explicitly support >the prefixation syntax. Not any sequence of characters would be >allowed, e.g.: > > foo.bar:fred, but > * foo:bar:fred > >so it's not sufficient to say that any string not beginning with '?' >is kosher... I've attached below a proposal on namespace syntax that I worked out with Matthew West on the SUO list. > > Just as a general comment, namespace management is one area where the > > W3C folk are way ahead of us; its been central to them since the > > beginning, and they now have internationally accepted conventions for > > registering and distinguishing namespaces, resolving ambinguity, etc. > > . So if we are going to get involved in this we ought to take this > > stuff into account. Or, maybe the right conclusion is that we should > > leave this to them, and just make sure that we don't define things > > too narrowly to allow their conventions to operate. For example, XML > > compliance apparently requires that character strings use Unicode > > rather than ASCII, a point we might need to be sensitive to. > > I second Pat here. We should decide and record the decision, >either way it goes. > > ...bill > >-- >Bill Andersen >Chief Technology Officer - Ontology Works >1130 Annapolis Road, Suite 203, Odenton, MD 21113 >andersen@ontologyworks.com / 410-674-7600 X-Sender: apease@helium.teknowledge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Nov 2000 12:51:27 -0800 To: "West, Matthew MR SSI-GREA-UK" , standard-upper-ontology@ieee.org From: Adam Pease Subject: RE: SUO: RE: RE: What language to use In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-standard-upper-ontology@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: standard-upper-ontology X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: standard-upper-ontology-approval@majordomo.ieee.org X-Return-Path: owner-standard-upper-ontology@ieee.org X-MDRedirect: 1 X-MDaemon-Deliver-To: apease@pa.teknowledge.com Matthew, Below is the formal content from your file with my comments. Where I've made a suggestion, I've commented out your original version, added a suggested new version, and inserted any comments I have prefixed by "; [AP]" I like your use of the namespace prefix. If we were to suggest an addition to SUO-KIF http://ltsc.ieee.org/suo/suo-kif.html in line with the example usage we might have change in section 4.1 add the sentence Bracket characters [] denote an expression that is repeated 0 or 1 time. change in section 4.3 to definition for "constant" prefix := initialchar wordchar* / constant := [prefix] initialchar wordchar* -------------------------------------------------------------------------- [snip] ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From phayes at ai.uwf.edu Wed Nov 29 14:01:52 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:02 2003 Subject: KIF: Re: FOL-3 and FOL-1 In-Reply-To: <200011290127.RAA16950@Pacific.AI.SRI.COM> References: <200011290127.RAA16950@Pacific.AI.SRI.COM> Message-ID: > > that relaxing the KIF restriction, to allow quantification over > > relations, is of immediate practical utility in almost every > > ontology, and does not in fact go "beyond standard first-order > > semantics" in anything other than a trivial sense. > >My concern is more that an interpretation that includes relations is >nonstandard than that it is necessarily non-first-order. > >For theorem proving, groups are often axiomatized >as (= (f e ?x) ?x) > (= (f (g ?x) ?x) e) > (= (f (f ?x ?y) ?z) (f ?x (f ?y ?z))) >rather than > (=> (group-element ?x) (= (f e ?x) ?x)) > (=> (group-element ?x) (= (f (g ?x) ?x) e)) > (=> (= (f (f ?x ?y) ?z) (f ?x (f ?y ?z)))) >The intended interpretation of the former has the set >of group elements as the domain. I want to keep doing >this without violating the spirit of KIF. OK, but this is a deeper problem than just not having relations in the domain. In order to axiomatize in this fashion you can't have *anything* in the domain except group elements. That's rather a severe restriction an upper-level ontology language. I think that what you really want is a sorted language, so that the 'sort' restrictions don't have to be made explicit in the quantifiers. OK, but the sortal restrictions do have to be said somehow, so I don't think that a sorted KIF is going to be simpler than an unsorted one; in fact I think the core should be unsorted (with any required quantifier restrictions stated explicitly) and the sorted language considered an extension. Your axioms could be written fairly neatly in an unsorted core by placing a restricted quantification as a kind of universal 'wrapper' around the unrestricted form: (forall (?x ?y ?z) (=> (and (group-element ?x)(group-element ?y)(group-element ?z)) (and (= (f e ?x) ?x) (= (f (g ?x) ?x) e) (= (f (f ?x ?y) ?z) (f ?x (f ?y ?z))) )))) >However, if the KIF standard prescribes a model theory for the core >that includes relations in the domain, this creates some dissonance >with the practice of axiomatizing groups as above with the above >intended interpretation. My proposal would require relations in the domain when they are required to make sense of any relational quantifiers. If there were no relations of relations in the signature, the domain needn't contain any relations, so your 'pure-group-theory' axiom style would still be OK if you really were doing pure group theory. >(Of course, any proof will derive valid conclusions regardless of the >interpretation, so the problem is more conceptual than practical.) > >While "allow[ing] quantification over relations is of immediate >practical utility", I think it is also important to preserve the >possibility of interpretations whose domain does not include >relations. > >I prefer that pushing relations into the domain be reserved >for an extension and that the core be standard first-order logic >with the usual freedom to choose an interpretation. My proposal is standard first-order logic, with a little additional freedom to allow relations in the domain. The only real constraints are that every quantifier must have some nonempty set to range over, and that every name has something to denote. If your axioms have a signature which doesnt require any relations in the domain, then it would be fine to not have any (or maybe to have nothing which ranges over them, so they would be 'invisible'. This is a technicality.) >On the other hand, if you want to include the capacity to use relation >names as constant symbols and/or quantify over relations in the core, >I would ask for some careful wording about the model theory in the KIF >standard that preserves the capacity for relationless interpretations >when these features are not used. I agree, and think that this can indeed be done so as to keep everyone happy. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Wed Nov 29 14:45:03 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:03 2003 Subject: KIF: Ways to proceed [was: Re: purpose of quoting] In-Reply-To: <200011291945.LAA23312@thumper.rt.cs.boeing.com> References: <200011291945.LAA23312@thumper.rt.cs.boeing.com> Message-ID: >From John Sowa: > >Pat et al., > >I always thought that the underlying assumption behind the >SUO was that the upper ontology must establish the minimum >foundation for describing everything. There are three ways >to proceed: > > 1. Top down: Start from T and add axioms and definitions. > > 2. Bottom up: Start from the complete OED and look for > possible generalizations. > > 3. Iterative: Do a little of both and keep repeating until > you have a hierarchy with the top node at #1 and the > leaves at #2. >===== > >There is anotehr: middle out, whereby you start with 'cognitively >basic', as per >Lackoff, concepts. This might include say dog. Then move up to make >generalizations, or >down to make further distinctions, as appropriate. > There is also the 'spiral' approach, where one chooses some place and first goes up to a generalisation, then sideways, then down twice to an instance, then sideways, and then upwards again, thus eventually passing through every node. Other strategies suggest themselves, such as using a random walk, or making one complete 'branch' from ENTITY all the way down to (say) MANHOLE_COVER_ADJUSTMENT_SCREW, and then pushing it sideways like a kind of windscreen wiper. Is this topic really worth spending any more time on? Will it alter the design of SUO-KIF? Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From phayes at ai.uwf.edu Wed Nov 29 14:47:19 2000 From: phayes at ai.uwf.edu (pat hayes) Date: Fri Oct 10 03:31:03 2003 Subject: KIF: KIF = Authoring OR Interchange ? In-Reply-To: <200011291925.eATJPTC30724@philebus.tamu.edu> References: <200011291925.eATJPTC30724@philebus.tamu.edu> Message-ID: Im not sure what this discussion (debate?) is about. What exactly is the tension between authoring and interchange requirements of a language? KIF was explicitly designed as an interchange, but it has turned out to be widely used for authoring. I suspect that this discussion is a non-issue, or maybe a non-meta-issue. Pat --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes From apease at teknowledge.com Wed Nov 29 19:25:28 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:31:03 2003 Subject: minutes for Nov 9 KIF meeting In-Reply-To: <3a25306d.441b.0@bestweb.net> Message-ID: <4.2.0.58.20001129172132.016d26e0@helium.teknowledge.com> John, I agree with this with the following clarification. It may be that the needs for interchange are slightly different from the needs of authoring, even if the authors are logicians. My suggestion in order to support Pat's desires for interchange are that SUO-KIF be stratified into two levels, the base level which supports authoring, and an extension which supports some additional features needed for interchange. SUO-CE would map to the base (authoring) level of SUO-KIF only. Adam At 11:35 AM 11/29/2000 -0400, John F. Sowa wrote: >Mike wrote > > >What about the fact that a language for authoring and a language for > interchange > > >have conflicting requirements? How to choose? > >An authoring language should be easy to read and write by >human beings, and an interchange language should be efficient >to parse and generate by computers. > >But anything that anyone authors should be possible for >computers to interchange. Therefore, the two kinds of >languages should have identical expressive power. > >I believe that is the motivation for having SUO-KIF as an >interchange language and a language such as ACE (or the >proposed SUO-CE) as an (optional) authoring language. >SUO-CE and SUO-KIF should be identical in expressive power, >and either one should be automatically translatable to the >other. > >Anyone who doesn't like SUO-CE could use SUO-KIF for all >purposes. Anyone who doesn't like SUO-KIF should be able to >write SUO-CE, but should at least be able to read SUO-KIF >in order to check the results -- just as people who use C >should have at least some acquaintance with assembly language. > >John Sowa ----------------- Adam Pease Teknowledge (650) 424-0500 x571 From apease at teknowledge.com Wed Nov 29 19:31:17 2000 From: apease at teknowledge.com (Adam Pease) Date: Fri Oct 10 03:31:03 2003 Subject: KIF: KIF = Authoring OR Interchange ? In-Reply-To: References: <200011291925.eATJPTC30724@philebus.tamu.edu> <200011291925.eATJPTC30724@philebus.tamu.edu> Message-ID: <4.2.0.58.20001129172940.01f88538@helium.teknowledge.com> Pat, I do think this is a reasonable issue as it partitions our discussion on the need for representing syntax in the logical language. If one takes SUO-KIF as strictly a language for authoring, there is no need to represent syntax. If we take it as a language for interchange, as you recommend, such a need does in fact exist. Adam At 02:47 PM 11/29/2000 -0600, pat hayes wrote: >Im not sure what this discussion (debate?) is about. What exactly is the >tension between authoring and interchange requirements of a language? KIF >was explicitly designed as an interchange, but it has turned out to be >widely used for authoring. I suspect that this discussion is a non-issue, >or maybe a non-meta-issue. > >Pat >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola, FL 32501 (850)202 4440 fax >phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes > ----------------- Adam Pease Teknowledge (650) 424-0500 x571