From: Ian Horrocks ([email protected])
Date: 03/03/03
I am very much in agreement with Pat's basic arguments. One additional point I would make is that "reaction" rules, like Gerd's example: > "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." seem to be mixing up several elements: monitoring/sensory input, reasoning about the current state, action outputs. More or less any kind of logical formalism could be used for the reasoning part - KIF could certainly be used in this context, as could OWL. I would suggest that sensing and acting simply be ruled out of scope - as Pat points out, going down that road soon leads to having a fully fledged programming language. We can then concentrate on suitable languages for dealing with the middle part - reasoning about some given state - which is the same regardless of how the premises are derived (via sensing or whatever). This would get us back somewhere closer to where I thought we wanted to be - determining what might be a sensible "rules" language, preferably layered (if I can be forgiven the expression) on top of OWL, that would support the reasoning required in this kind of application. Ian > "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." All we need to do On February 25, pat hayes writes: > Attached are some @comments@ on Gerd's statement. > ---- > Statement by Gerd Wagner prepared on request of the Joint Committee . > 13-Feb-2003 > > It is hard to define what is a rule and, 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. @ > > Rather, I suggest to consider rules at three different levels [ 1]: > 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 > > @ Please say what is meant by 'declarative' here. See later comments. @ > > manner, typically using natural language or a visual language. > Some examples: > "A gold customer is a customer with more than $1MM on deposit." > "The driver of a rental car must be at least 25 years old." > > @ That is not a declarative statement, at least with its usual > intended meaning in such a context, i.e. to constrain behaviors. @ > > "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." > > @ That is also not a declarative: it is an imperative. @ > > 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. @ > > 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. In fact I don't think it can be mapped > into any kind of executable statements in any reasonable sense of > 'mapped'. @ > > At the (platform-specific) execution level, rules are statements in > a specific executable language, such as Jess, XSB or the Microsoft > Outlook Rule Wizzard. > In any case, rules are modular, stand-alone units, which directly > support or involve some form of reasoning. > > @ To me, what you have said is that rules are chalk, and therefore > rules are cheese. Look, both the second and third items in your list > emphasize *executable*; you are apparently talking about code, not > assertions. But then you immediately go on to sum this up using the > words 'stand-alone' and 'reasoning'. Reasoning and computation are > NOT the same; they are fundamentally different. So which one are we > talking about here? @ > > They may, for instance, specify > derivations (e.g. for defining derived concepts), > static and dynamic integrity constraints (e.g. for constraining the > state space or the execution histories of a system/agent), > 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?? @ > > Given the linguistic richness and the dynamics of natural problem > domains, it should be clear that any specific account of rules, such > as classical logic Horn clauses, must be viewed as a limited > descriptive theory that captures only a certain fragment of the > entire conceptual space of rules > > @ My point has always been that this is meaningless, or empty, since > there IS no conceptual space of 'rules' (other than the whole of > computation: and in your case, even more, including all of human > behavior). You havn't said anything to make me think I am wrong. @ > > , and not as a definitive, normative account (see also the discussion > at > http://lists.w3.org/Archives/Public/www-rdf-rules/2001Sep/0079.html > ). We need a pluralistic approach to the heterogeneous conceptual > space of rules. Therefore, in RuleML a family of rule languages > capturing the most important types of rules is going to be defined. > Each of these languages will have a recommended formal semantics, but > may have one or more alternate acceptable semantics. This will > accommodate various formalisms based on non-standard logics, > supporting temporal, fuzzy, defeasible and other forms of reasoning. > > @ It would be more helpful if you could say what they might NOT include. @ > > Pat Hayes > > > > -- > --------------------------------------------------------------------- > 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 > [email protected] http://www.coginst.uwf.edu/~phayes > [email protected] for spam > <!doctype html public "-//W3C//DTD W3 HTML//EN"> > <html><head><style type="text/css"><!-- > blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } > --></style><title>what is a rule?</title></head><body> > <div>Attached are some @comments@ on Gerd's statement.</div> > <div>----</div> > <div><font face="Lucida Grande" color="#000000">Statement > by</font><font face="Lucida Grande" color="#0000FF"> Gerd > Wagner</font><font face="Lucida Grande" color="#000000"> prepared on > request of the</font><font face="Lucida Grande" color="#0000FF"> > Joint Committee</font><font face="Lucida Grande" > color="#000000"> .<br> > 13-Feb-2003<br> > <br> > It is hard to define what is a rule and, 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. </font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ Unless we do, it > seems to me that the discussion is vacuous. We literally do not know > what we are talking about. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000"> Rather, I > suggest to consider rules at three different levels [</font><font > face="Lucida Grande" color="#0000FF"> 1</font><font > face="Lucida Grande" color="#000000">]:<br> > 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</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ Please say what is > meant by 'declarative' here. See later comments. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000"> manner, > typically using natural language or a visual > language.</font></div> > <div><font face="Lucida Grande" color="#000000">Some examples:<br> > "A gold customer is a customer with more than $1MM on > deposit."<br> > "The driver of a rental car must be at least 25 years > old."</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ That is not a > declarative statement, at least with its usual intended meaning in > such a context, i.e. to constrain behaviors. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">"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."</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ That is also not a > declarative: it is an imperative. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br> > 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.</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ That seems to cover > any programming platform at all. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">Rule languages used at > this level are</font><font face="Lucida Grande" color="#0000FF"> > RuleML</font><font face="Lucida Grande" color="#000000"> 0.82, SQL-99, > OCL 2.0, ISO Prolog or KIF.</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ KIF is purely an > assertional logic, and cannot be 'easily mapped' into executable > statements. In fact I don't think it can be mapped into any kind of > executable statements in any reasonable sense of 'mapped'. > @</font></div> > <div><font face="Lucida Grande" color="#000000"><br> > At the (platform-specific) execution level, rules are statements in > a specific executable language, such as Jess, XSB or the Microsoft > Outlook Rule Wizzard.</font></div> > <div><font face="Lucida Grande" color="#000000">In any case, rules are > modular, stand-alone units, which directly support or involve > some form of reasoning.</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ To me, what you have > said is that rules are chalk, and therefore rules are cheese. Look, > both the second and third items in your list emphasize *executable*; > you are apparently talking about code, not assertions. But then you > immediately go on to sum this up using the words 'stand-alone' and > 'reasoning'. Reasoning and computation are NOT the same; they are > fundamentally different. So which one are we talking about here? > @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000"> They may, for > instance, specify</font></div> > <div><font face="Lucida Grande" color="#000000">derivations (e.g. for > defining derived concepts),<br> > static and dynamic integrity constraints (e.g. for constraining the > state space or the execution histories of a system/agent),<br> > reactions (e.g. for specifying the reactive behavior of a system/agent > in response to events) </font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ in what sense is a > 'reaction' anything to do with reasoning?? @</font></div> > <div><font face="Lucida Grande" color="#000000"><br> > Given the linguistic richness and the dynamics of natural problem > domains, it should be clear that any specific account of rules, > such as classical logic Horn clauses, must be viewed as a > limited descriptive theory that captures only a certain fragment > of the entire conceptual space of rules</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ My point has always > been that this is meaningless, or empty, since there IS no conceptual > space of 'rules' (other than the whole of computation: and in your > case, even more, including all of human behavior). You havn't said > anything to make me think I am wrong. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">, and not as a > definitive, normative account (see also the discussion at</font><font > face="Lucida Grande" color="#0000FF"> > http://lists.w3.org/Archives/Public/www-rdf-rules/2001Sep/0079.html > ><font face="Lucida Grande" color="#000000"> ). We need a > pluralistic approach to the heterogeneous conceptual space of rules. > Therefore, in</font><font face="Lucida Grande" color="#0000FF"> > RuleML</font><font face="Lucida Grande" color="#000000"> a family of > rule languages capturing the most important types of rules is going to > be defined. Each of these languages will have a recommended formal > semantics, but may have one or more alternate acceptable semantics. > This will accommodate various formalisms based on non-standard logics, > supporting temporal, fuzzy, defeasible and other forms of > reasoning.</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">@ It would be more > helpful if you could say what they might NOT include. @</font></div> > <div><font face="Lucida Grande" color="#000000"><br></font></div> > <div><font face="Lucida Grande" color="#000000">Pat Hayes</font></div> > <div><font face="Lucida Grande" color="#000000"><br> > <br> > </font></div> > <div><br></div> > <x-sigsep><pre>-- > </pre></x-sigsep> > <div > >---------------------------------------------------------------------<br > > > IHMC<x-tab> > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab>(850)434 8903 or (650)494 3973 home<br> > 40 South Alcaniz St.<x-tab> > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab>(850)202 4416 office<br> > Pensacola <span > ></span> <x-tab> > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab>(850)202 4440 fax<br> > FL > 32501 <x-tab > > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab><x-tab> > </x-tab>(850)291 0667 cell<br> > [email protected]<x-tab> > </x-tab> > http://www.coginst.uwf.edu/~phayes
> > [email protected] for spam<br> > </div> > </body> > </html>
This archive was generated by hypermail 2.1.4 : 03/03/03 EST