Next message: Mike Dean: "no Joint Committee telecon tomorrow 4 March"
At 11:14 AM 3/3/2003, Ian Horrocks wrote:
>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'm not an expert in ECA rules, but I don't think the problem
is that one could not in principle reason with any of
the mentioned languages - but that these languages
don't provide the cognitive support for formulating
the rules. Kind of programming with a Turing Machine, rather
than Java or LISP. The expressive power is the same
but I'm faster and more efficient with Java.
>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.
What is in or not in should be application driven - not driven by the
fact if we have a nice elegant formalism for it or not.
>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.
The relationship to OWL a major question mark - something that needs to
be worked out.
My position is that a rule language should be agnostic to the
ontology model used to express the vocabulary - so that
it works with OWL as well as with RDF-Schema, DAML+OIL, UML,
MOF, TopicMaps, F-Logic, ER, (and maybe even Prototypes -
although they are still not well understood and researched)
From my point of view we need to be able to support different
modeling languages. If we focus on just one
we leave the folks using other modeling styles
out in the dust - which means interoperaton is hampered.
Tim Berners-Lee calls this the "test of independent invention" - if
two different modeling languages would meet on the web - can
they interoperate or would they fight with each other?
Rather then focus on a specific modeling language, it seems to be
more promising to be able to reason with all of them - like the
Web Browser was able to also deal with GOPHER, Telnet, and FTP.
To get a start here: How could a layering on OWL help, e.g.,
to reason with UML?
Do we care if the web splits up - one part driven by OMG standards,
the other by W3C recommendations? Or would we like to avoid the
split? If yes, how (by technical means)?
Or maybe politics?
Convincing Rational Rose that they should use OWL
instead? What about DMTF? (http://www.dmtf.org)
Should we explain to them that OWL (instead of MOF)
is the much nicer technology for representing their
CIM-Models (=ontologies)?
What about other communities? ER? TopicMaps? Do we care?
Best,
Stefan
>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>
--
http://www.isi.edu/~stefan
This archive was generated by hypermail 2.1.4
: 03/03/03 EST