CHAPTER 5

ERS: Prolog to an Expert System

for Transportation Planning
Richard K. Brail

Urban and regional transportation planners have long used sophisticated com-
puter models to assist the decision-making process. This rich tradition has
included a variety of model types and computer environments. For the most
part, the models were written in the computer languages of the day, chiefly
FORTRAN, with some use of the newer structured languages such as Pascal and
C in more recent applications. These procedural languages were used to write
complex and highly sophisticated programs. In the process of developing these
systems, a number of interesting algorithms, such as the shortest path through a
roadway network and the calculation of roadway volumes, were designed. The
"granddaddy" of the early mainframe systems was the Urban Transportation
Planning System (UTPS), supported by the U.S. Department of Transportation.
The evolution of expert system approaches suggests that traditional tran-
sportation planning analysis may benefit from a new look at building applied
models. This paper will explore the use of Prolog, a logic-based computer
language, in developing a simple transportation model. The presentation is
divided into three parts. First, we will introduce Prolog as a language. Second,
we will outline the transportation problem which will be examined. Finally, we
will present a simple working transportation model written in Prolog. This
actual demonstration is an excellent way to see the potential, as well as the obs-
tacles, of using such a language. Furthermore, we will be better able to assess
the potential for expert system approaches to applied transportation modeling.

Prolog as a Language
The Elements of Prolog
Prolog is declarative rather than procedural language. Rather than detailing the
procedures required to generate a solution, the user specifies a problem and the
computer provides a set of possible solutions. One of the key concepts of

T. J. Kim et al. (eds.), Expert Systems: Applications to Urban Planning

© Springer-Verlag New York Inc. 1990
88 Richard K. Brail

Prolog is recursion - the ability of Prolog instructions to invoke themselves in

carrying out a task.
The introduction in 1986 of a number of microcomputer-based Prolog
interpreters and compilers has made this language an increasingly important
option to other declarative languages. The majority of Prolog compilers and
interpreters follow the language conventions of Clocksin and Mellish (1987). In
Prolog, a program consists of three major elements-facts, rules and questions
about the facts and rules (Clocksin and Mellish,1987:1-20). Facts and rules are
generally referred to as clauses. A Prolog database might contain the following
facts:
trips-per_acre (office_land_use, 500.0)
is_county (new_jersey, somerset)

The first fact is a clause with a predicate, "trips_per_acre," and two argu-
ments, "office_land_use" and "500.0." This clause can be translated into the
phrase "office land use generates 500 trips per acre per day." The second fact
states that "Somerset is a county in New Jersey." Note that the arguments, or
atoms in Prolog, are written as all lower-case letters as single words or numbers.
The phrase,"office_Iand_use," is an atom, a lower-case non-integer constant
containing no spaces. Also, "somerset," "newjersey" and "500.0" are atoms.
Rules are the driving elements of a Prolog program. Rules are the condi-
tional "if-then" statements which lie at the base of Prolog, and of expert systems
in general. In Prolog the following is a rule:
dense (new_brunswick) :- many(people)

The ":-" symbol means if. The rule reads: "New Brunswick is dense if there are
many people." Instantiation is the process in Prolog of finding an instance
among the facts and rules which is supported. Prolog responds to a goal set by a
user as if it were a question which has an answer, yes or no. In Prolog, a goal is
an uninstantiated query. By stating a goal as a query, the Prolog interpreter or
compiler is directed to instantiate the clause as a query. Prolog will answer
"yes" or "no" to the query, depending on whether or not the goal was instan-
tiated. For example, we could set up clauses containing trip generation informa-
tion in terms of the number of daily trips per acre produced by different land use
categories:
trips (office_general, 145.0).
trips (office_medical, 426.0).
trips (restaurant_quality, 200.0).
trips (restaurant-popular, 932.0).