% >From hki@hydroman.hut.fi  Tue Apr 16 11:49:14 1991
% Return-Path: <hki@hydroman.hut.fi>
% Received: from hydroman by ngs.fi (5.61++/SMI-4.0)
% 	id AA03630; Tue, 16 Apr 91 11:49:14 +0300
% From: <hki@hydroman.hut.fi>
% Received: by hydroman.hut.fi (5.61++/6.8/S-TeKoLa)
% 	id AA05253; Tue, 16 Apr 91 11:50:43 +0300
% Message-Id: <9104160850.AA05253@hydroman.hut.fi>
% Subject: Englannin kurssin materiaalia
% To: Pekka.Nikander@ngs.fi
% Date: Tue, 16 Apr 91 11:50:40 EET DST
% X-Mailer: ELM [version 2.3 PL0]
% 
% Terve
% 
% T{ss{ on aluksi kirjoitukseni puhtaana ASCIIna; skandit ovat muotoa
% \"a, \"o jne. ASCII-osuuden loputtua on teksti PostScript-muodossa.
% 
% Kiitokset vaivann{|st{.
% 
% ----klip----klap----klip----klap----klip----klap----klip----klap

\chapter{Knowledge Engineering}
\author{Harri Kiljander}

\section{Introduction}

Knowledge Engineering (KE) is a relatively new branch of computer
science which has been overloaded with several different meanings.  It
can be seen as a group of methodologies for building certain kinds of
software applications --- namely expert systems; this definition brings
it closer to traditional software engineering.  Quite often it is also
associated with all the unrealistic expectations focused on the
artificial intelligence research in general during the last few
decades.

\section{History of Artificial Intelligence Research}

Artificial Intelligence (AI) has been a research topic for over thirty
years now.  From the middle of the fifties to the middle of the sixties
some kind of a goal of the research was to build general problem
solving systems.  This means that the AI programs developed at that
time were supposed to be able to solve just any kind of problem
provided they were first given enough background information.  The
results achieved were not so promising; the best systems developed
were extremely slow and still capable of solving only very simple
problems.  From this the researches concluded that some basic technical
issues of knowledge representation and e.g.\ search algorithms had to
be solved before any reasonable problem solvers could be built.

From the mid-sixties to the mid-seventies the main emphasis of AI
re\-search was on developing efficient ways to represent knowledge and
to find a correct solution to a problem from the search space of all
possible solutions.  This period of time gave us more powerful problem
solvers than ever before but they still did not have any greater importance
outside the academic world.

From the mid seventies we have been living with the third wave of AI
and it is still continuing.  This paradigm or way of thinking is expert
systems.  The distinction between the earlier general problem solvers
and expert systems is that while the former tried to answer just any
kind of question the latter focus on a narrow problem domain trying to
mimic the problem solving processes of a genuine human expert of that
domain.  During this period people have started using the term
{\it Knowledge Engineering} meaning applied AI i.e.\ the art and science of
building expert systems.  KE is the opposite of {\it pure} AI although it
uses the methods developed by AI research.  Another term which has come
into existence is {\it Knowledge Engineer} meaning a person whose task is
to extract the domain knowledge out of the mind of the human expert
and turn it into an expert system; actually a knowledge engineer is a
software engineer using knowledge engineering methods to build expert
systems.

\section{Knowledge Engineering Tools: Software}

Knowledge Engineering deals with the automation of decision processes.
Conventional data processing utilizes predefined algorithms which are
executed sequentially and always in the same manner while the
inference processes used in expert system applications are case
sensitive i.e.\ the inference process used consists of steps which
depend on and whose ordering depends on the data the system is being
used with.  Because of the mixing of data and program logic to control
the system, expert systems represent data-driven data-processing.

The software tools used in expert system building can be roughly
categorized into three groups; programming languages, shells and
toolkits.  The most frequently used programming languages for expert
system building have been Lisp and Prolog; Lisp was conceived in the
fifties while Prolog was born in the middle of the seventies.   Lisp is
a functional language and its name stands for {\it LISt Processing} whilst
Prolog has its origins in logic, its name stands for {\it PROgramming in
LOGic}.  Of course there are no reasons why just any programming
language could not be used in the development of expert systems; it is
possible to build an expert system even in Cobol --- although it is not
advisable because of the effort needed, performance issues and so on.
Languages like Lisp and Prolog are better suited for the required
data-driven approach.

Shells usually contain an interpreter and some predefined way to
represent knowledge e.g.\ in the form of rules.  It can be possible to
produce prototypes of the system quite fast when working with shells
but for the speed gained the richness of knowledge representation is
at least to some extent lost.  The distinction between languages and
shells is sometimes rather vague since some shells are implemented
just as extensions on top of e.g.\ Lisp or Prolog.  Shells can be
subdivided into rule based shells, natural language processing shells
etc.

Toolkits are the most sophisticated and flexible expert systems
building tools.  Typically they are hybrid environments offering e.g.\
several knowledge representation paradigms surrounded by complete
prototyping and application development environments.  Previously the
majority of them was closely related with Lisp but during the last few
years there has been a movement from Lisp-based systems towards
C-oriented systems.  It can be said that Lisp (and Prolog) is not dead
but it has become a very specialized concern.  Many of the leading
commercially important KE vendors have recently released new
C-oriented expert systems development tools.

The most sophisticated KE toolkits nowadays work in graphical user
interfaces.  This is because the data processing world in general is
moving towards GUI's and KE tools have always been state-of-the-art
applications.  Second, a graphical user interface solves many knowledge
representation problems which could not have been so easily solved
with character based user interfaces, like how to represent and edit
complex hierarchical data structures in an efficient way.

\section{Knowledge Representation}

A conceptualized and simplified expert system contains two things; a
knowledge base which is the {\it knowledge} the system has, and an
inference engine which is operated on that knowledge to produce some
meaningful results.  The contents of the knowledge base may be rules or
facts or both.  The inference engine picks up some facts from the
knowledge base and by using some of the rules in the knowledge base it
deduces new facts and asserts them into the knowledge base repeating
this process over and over again until some specified state is
reached.  It can be seen that only the knowledge base of the expert
system is application dependent while the general purpose inference
engine can be used with diverse applications.

Before we can use the knowledge to produce some meaningful results we
must first have ways to represent and store it.  The problems of
knowledge storage are mostly technical and deal with the same kind of
issues as conventional database systems so we need to focus on the
much more important issue of knowledge representation.  There are two
almost mutually exclusive requirements being stated; first, the
representation has to be easily understood by the people developing
and maintaining the system, and second, the representation has to be
efficient enough for the computer to be able to handle it fast.

The oldest and still maybe the most widely used way to represent
knowledge is rule-based reasoning.  Within this knowledge
representation paradigm the knowledge is stored in the form of facts
and rules.  The facts are of the type {\tt the cat is in the moon} and
the rules are of the type {\tt if \it thing\_x \tt is in \it place\_x
\tt then \it place\_x \tt is not empty}; from these our hypothetical
system would deduce the fact {\tt the moon is not empty}.  Pure
rule-based systems are well-suited for certain kinds of applications
but for some others they are too strict and limiting; usually it is
the system that decides what to ask and in which order, not the user.

At the other end of the knowledge representation spectrum are
different conceptual hierarchies or frame systems using e.g.\ attribute
inheritance.  For example we could state that {\tt cars have doors} and
{\tt Porsche is a car}; the actual representation of these facts would be
environment dependent of course.  If we now knew something to be a
{\tt Porsche} then we would automatically know it to have {\tt doors}; for the
first it would be a car and for the second, cars have doors, so also
this car specimen would have doors.  This kind of knowledge
representation paradigm moves us close to object oriented programming
and modelling in general.  By building an expert system on top of a
graphical user interface and using the object oriented way of approach
it is possible to build more user friendly (and more complex too)
expert systems; this seems to be the future we are heading into.

Selecting an inefficient way to represent domain knowledge within an
expert system is likely to hamper or even halt the development of an
otherwise successful expert system, so extreme care should be taken to
avoid mistakes like this.  It can well be said that it is even more
important for the systems engineer to really get acquainted with the
application domain when working with expert systems than with more
traditional systems and tools.

\section{Knowledge Engineering Tools: Hardware}

Before the eighties nearly all AI systems development had been done
using conventional computer systems.  Although it had been possible to
implement large and effective expert systems like MYCIN which uses
expert medical knowledge to diagnose e.g.\ bacterial infections of the
blood and PROSPECTOR which determines the probable location and type
of ore deposits based on geological information about a site, it was
seen that dedicated Lisp-oriented computers would perform better with
applications like these.  There has never been a greater emphasis on
Prolog-oriented computers although the Japanese are using them within
their fifth generation computer project; the differences between
Prolog-computers and Lisp-computers are small anyway.

The differences between ``ordinary'' computers and Lisp-computers are
quite small if we compare them e.g.\ with the differences between
ordinary computers and neural network computers.  Lisp-machines are
based on the traditional von Neumann architecture, but they have three
additional features when compared to the ordinary machines: First
there are tag bits in the memory words because Lisp is a typeless
language and the tag bits are needed to handle the internal type
information faster than it would be possible with software; second
Lisp-machines have a stack-based architecture because Lisp is a
functional recursive language and third the machines have a ``flat''
virtual memory because Lisp keeps its data structures in a
single-level ``flat'' memory and getting data from secondary memory to
primary memory has to be as easy and fast as possible.

Ten years ago Lisp-machines clearly outperformed conventional
computers although they were also much more expensive.  Although the
prices of Lisp-machines have gone down just like any other computing
equipment and it is now possible to get efficient Lisp-hardware
implementations even for high end personal computers the benefits of
the Lisp-machines are not so clear any more.  An increasing amount of
KE software tools has been and is being ported to industry standard
workstations with a good price-performance ratio and a lot of other
applications already available, while there have been few new releases
of commercially important software for Lisp-machines lately.  It may
well be the case that in the future the dedicated Lisp-machines lose
some of their earlier importance and it is not totally impossible that
the AI hardware will merge with the conventional data processing
hardware --- especially the workstation world.  After all it is the
software which counts, not the hardware.  It does not actually matter
how powerful the machine is if it is powerful enough; what you can do
with the machine is more important, and there Lisp is not enough.

\section{Expert System Feasibility}

The idea of developing expert systems has become quite a fashionable
one during the last few years.  In any case it should be kept in mind
that they do not perform miracles, but they do require hard work and
skilled professionals to implement them.  Below follows some kind of a
checklist which should be carefully considered before any decisions
are made on behalf of or against a possible expert system.

There should be the following prerequisites for the expert system
development to be possible:
\begin{itemize}
\item task does not require common sense
\item task requires only cognitive skills
\item experts can articulate their methods
\item genuine experts exist
\item experts agree on solutions
\item task is not too difficult
\end{itemize}

If at least one of the following items is true then the expert system
development is justified:
\begin{itemize}
\item task system has high payoff
\item human expertise is being lost
\item human expertise is scarce
\item expertise is needed in many locations
\item expertise is needed in hostile locations
\end{itemize}

Finally if also all of the following issues are true then the expert
system development is appropriate:
\begin{itemize}
\item task requires symbol manipulation
\item task requires heuristic solutions
\item task is not too easy
\item task has practical value
\item task is of manageable size
\end{itemize}

\section*{Glossary}

\begin{tabular}{ll}
cognitive skills		& skills related to knowledge and \\
				& perception; e.g.\ learning\\
data-driven data-processing	& a form of data-processing in which \\
				& the flow of program control is to \\
				& a large extent controlled by the \\
				& input data \\
expert system			& a computer (software) application \\
				& mimicing the problem solving processes\\
				& of a human ``expert'' to solve a given \\
				& problem of a specific problem domain\\
GUI				& Graphical User Interface \\
heuristic 			& something serving to indicate or point\\
				& out; e.g.\ a good hypothesis\\
hybrid 				& something composed of elements of \\
				& different kinds\\
inference 			& the process of deriving consequences \\
				& of premises\\
knowledge engineer		& a software engineer using knowledge \\
				& engineering methods to build expert \\
				& systems\\
knowledge engineering		& the art and science of how to build \\
				& expert systems; a form of software \\
				& engineering in general\\
paradigm 			& a distinctive pattern a set of things\\
				& has in common\\
state-of-the-art		& up-to-date, leading edge\\
to have high payoff		& to make good profit with something\\
\end{tabular}

\section*{References}

{\parindent=0pt\parskip=3pt
Paul Harmon, {\it What's happening in the expert systems market?},
Intelligent Software Strategies, August 1990

Markku Syrj\"anen, {\it Tiet\"amystekniikka --- s\"a\"ant\"opohjaisista 
j\"arjestelmist\"a koh\-ti olio\-suun\-tau\-tu\-nei\-ta}
}
