Re: some Q&A on the Sisyphus (configuration design) experiment

sowa <sowa@turing.pacss.binghamton.edu>
Date: Thu, 12 Aug 1993 05:26:42 -0700
Message-id: <9308121221.AA09815@turing.pacss.binghamton.edu>
Comment: List name: SRKB-LIST (do not use email address as name)
Originator: srkb-list@isi.edu
Errors-To: aberg@ISI.EDU
Reply-To: <sowa@turing.pacss.binghamton.edu>
Sender: srkb-list@ISI.EDU
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: sowa <sowa@turing.pacss.binghamton.edu>
To: Multiple recipients of list <srkb-list@ISI.EDU>
Subject: Re:  some Q&A on the Sisyphus (configuration design) experiment

I wanted to comment on a point that was raised by Tom Gruber's
correspondent in the recent note to SRKB-LIST:

> Anyhow I have the impression that the ontolingua definition is
> constraint-satisfaction biased and !not! method-independent. Even more, I
> would claim that a method-independent representation of a domain is nearly
> impossible. (on last EKAW, Dean Allemang said that "use-free knowledge is
> use-less knowledge").

A purely declarative description of constraints is the most
unbiased form of problem description possible.  It may be true
that only a constraint-satisfaction system can work with such a
specification unchanged.  But every system -- procedural, declarative,
or whatever -- must implement those constraints in one way or another.
A declarative system states the constraints in the most explicit
possible way.  In a procedural system, it may be impossible to
separate the problem-specific constraints from the idiosyncracies
of the programmer and the programming language.

Despite my preferences for a declarative specification, I also
agree with the slogan that use-free knowledge is use-less knowledge.
I would even go one step further and say that there is no such
thing as use-free knowledge:  every specification, description, or
statement of any kind is an abstraction from the potentially infinite
amount of detail that could be given about any kind of object or
situation.  A declarative specification of constraints always
contains an implicit assumption about the problem to be solved
and the further implication that the constraints are relevant
in some way to the solution.

What is omitted in a declarative specification, however, is a
time-ordered sequence of steps that must be taken in order to
reach the goal.  In some cases, it may be easy to deduce an efficient
sequence from an analysis of the constraints.  But in other cases,
it may be very difficult to see how the constraints are related
to the goal.

Example:  As constraints, assume a declarative description of
chess moves.  As a goal, try to checkmate the opponent's king.
Finding an efficient way to reach that goal would require an
awful lot of trial and error with many unsuccessful attempts
along the way.

But just imagine how much more difficult the problem would be if
all you were given is a list of the moves from the Karpov-Kasparov
games with no commentary -- not even a statement of the legal moves
or the goal of the game of chess.  (Since none of the games in
their match ended in checkmate, you wouldn't even see an example
of the ultimate goal they were trying to achieve or avoid.)

John Sowa