From: pat hayes (phayes@ai.uwf.edu)
Date: 03/04/03
> >> although we can come up with a formal account for a specific type >>> of rule, I think we should better not try to find a definitive formal >>> account for "rules", in general. > >> Unless we do, it seems to me that the discussion is vacuous. >> We literally do not know what we are talking about. > >Notice, you may define KIF, OWL, LBase (or whatever) rules, >but you are not in a position to define "rules", in general. Well then, let us stop talking about "rules", in general. The topic is not relevant to our discussions, and (as you say) we cannot define it. >(Do they define "numbers", in general, or do they rather >define natural, rational, etc. numbers?) An aside, but one way to definitely NOT do it is to try to get a theory of numbers in general by starting with English number words and trying to classify them in some way. > >> At the problem domain level, rules are statements that express >>> (certain parts of) a business/domain policy (e.g., defining terms >>> of the domain language, defining or constraining domain operations) >>> in a declarative manner > >> Please say what is meant by 'declarative' here. > >"Declarative", here, means not specìfying the details of how to >implement a policy but only specifying what constitutes the policy >at the highest level of description (with preconditions and >postconditions of implied actions). But this definition is self-destructive, since a rule engine is sufficient to generate action when given rules. That is, any implemented rule system *does* provide details of how to implement the policy. (Unless you mean only that the rules do not explicitly state all the implementation details: but this is true of all 'high-level' programming languages, from Fortran onwards.) >"If any 3 of the named analysts report a strong buy on the same stock >within the same day and before the market closes, then buy 1000 units of >that stock." > >>> At the (platform-independent) computational level, rules are formal >>> statements that operationalize domain policies and can be easily mapped >>> into executable statements of a programming platform. > >> That seems to cover any programming platform at all. > >Not really, because you want to have a kind of direct support here. Well, that seems like an observation that might provide some real progress. Can you give us more details of what you mean here by 'direct support' ? >E.g., SQL systems directly support many important types of integrity >constraints (by means of CHECK, CONSTRAINT and ASSERTION statements), >while C++ and Java do not. > >>> Rule languages used at this level are RuleML 0.82, SQL-99, OCL 2.0, ISO >Prolog or KIF. > >> KIF is purely an assertional logic, and cannot be 'easily mapped' into >> executable statements. > >So, KIF rules cannot be interpreted/executed by any inference engine? No, that is not what I said. An inference engine for KIF is not a mapping from KIF into executable statements: that would be a compiler for KIF. I would not describe a KIF reasoning engine as a KIF interpreter, precisely because KIF is not an imperative language. BTW, there is no such thing as a 'KIF rule', as far as I know. KIF can express implications, of course, but it is misleading to call these 'rules'. > They may, for instance, specify reactions (e.g. for specifying the > >> reactive behavior of a system/agent in response to events) > >> in what sense is a 'reaction' anything to do with reasoning?? > >I normally reason before I react :-) The point I was making is that the (re)action is something fundamentally different from the reasoning. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
This archive was generated by hypermail 2.1.4 : 03/04/03 EST