TITLE: Side Thoughts on Tasks, Methods, and Intelligent Systems
AUTHOR: Eugene Wallingford
DATE: January 31, 2011  4:12 PM
DESC: 
-----
BODY:
I've been
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-01.html#e2011-01-13T15_42_00.htm">
   enjoying teaching</A>
Intelligent Systems again this semester.  A big part
of the fun is re-reading old papers.  I had a lot of
fun re-reading and thinking about the ideas in
<A HREF="http://bill.clancey.name/">
   William Clancey</A>'s
classic paper,
<A HREF="http://portal.acm.org/citation.cfm?id=5122">
   Heuristic Classification</A>.
Long-time readers may recall me mentioning this paper
in a long-ago post about one of computing's basic
concepts, the
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-02.html#e2007-02-06T22_31_26.htm">
   unity of data and program</A>.

My students didn't read this paper, but they did read a
chapter from Peter Jackson's <EM>Introduction to Expert
Systems</EM> that discusses it in some detail.  The
chapter is called "Heuristic Classification", too, but
it's really about much more: the distinction between
tasks and methods, the distinction between analytic
tasks and synthesis tasks, and Clancey's heuristic
classification method itself.

This one paper set me off on a mini-lecture that could
have been much longer.  To me, it felt like a technical
reminiscence, a story of ideas that set the stage for
my own work on design patterns of knowledge-based
systems.  Eventually, I had to cut my story short, both
in the interest of having time to do other things in
class that day and in the interest of not boring students
with my own deep fascination with these topics.  I hope
I said enough to give them a sense of how important these
ideas are and to whet the appetite of any student who
might have his or her own fascination with the ideas.

Our reading and our conversation that day brought to my
mind a rich set of ideas for students of intelligent
systems to think about, such as:
<UL>
<LI> The distinction between <B>task</B> (what) and
     <B>method</B> (how) is, at one level, no big deal.
     Students begin learning about this in their intro
     course, see its idea more clearly in their data
     structures course, and study the lifecycle issues
     involved with both in Software Engineering.  But
     understanding the specification for a software
     system is often a challenge; it's easy to focus on
     the wrong task.  The problem is made more difficult
     in many AI software projects because we are working
     in domains we understand less well, on problems at
     the edge of our intellectual abilities.  </LI>

<LI> Many problems in the world are really composites
     of other, more primitive tasks.  For example, a
     tutoring system must diagnose "bugs" in a student's
     thinking, develop a plan to fix the bug, and monitor
     student performance while solving problems.  When we
     decompose a task in this way, we are in effect
     talking about a method for performing the task, but
     at a level that commits only to the exchange of
     information among high-level modules.  </LI>

<LI> Where do learning systems fit into our classification
     of tasks.  In one sense, a learning system "goes meta",
     because it creates a system capable of performing one
     of the tasks in the taxonomy.  In another, though, it,
     too, is performing a task.  But which one?  </LI>
</UL>

Many of these go beyond my current interests precisely
because they are at the beginning of their studies,
focused on building a particular system.  They may find
their interest in these ideas piqued after they build
one of these systems, or three, and realize just how many
degrees of freedom they face when writing a program that
behaves "intelligently".
-----