Next message: Stefan Decker: "Re: what is a rule?"
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
> phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
> s.pam@ai.uwf.edu 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>
> phayes@ai.uwf.edu<x-tab>
> </x-tab>
> http://www.coginst.uwf.edu/~phayes>
> s.pam@ai.uwf.edu for spam<br>
> </div>
> </body>
> </html>
This archive was generated by hypermail 2.1.4
: 03/03/03 EST