some Q&A on the Sisyphus (configuration design) experiment
Tom Gruber <Gruber@HPP.Stanford.EDU>
Date: Wed, 11 Aug 1993 19:17:03 -0700
Message-id: <2954109509-12196958@KSL-Mac-69>
Comment: List name: SRKB-LIST (do not use email address as name)
Originator: srkb-list@isi.edu
Errors-To: aberg@ISI.EDU
Reply-To: <Gruber@HPP.Stanford.EDU>
Sender: srkb-list@ISI.EDU
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: Tom Gruber <Gruber@HPP.Stanford.EDU>
To: Multiple recipients of list <srkb-list@ISI.EDU>
Subject: some Q&A on the Sisyphus (configuration design) experiment
Below are excerpts (forwarded with permission) from a recent dialog
with someone who is solving the Sisyphus configuration design task
working from the formal specification written in KIF (via Ontolingua).
See
ksl.stanford.edu:/pub/knowledge-sharing/ontologies/config-design/README.TEXT
for more detail on Sisyphus.
--tom
> in the KAW-list. In your message you wrote:
> >> These new files
> >> provide a formal, declarative description of the task and
> >> machine-readable domain knowledge.
> However these files contain only the description of the components and the
> constraints and both the propose knowledge and the fixes are not included.
> However the original document by YOST obviously contains the propose and
> fix knowledge.
..
> Since for Sisyphus 93 running systems are required and at least the
> propose knowledge is essential for the system, this knowledge must be added
> by everyone intending to build a system.
Some of the "propose" and "fix" heuristics in the Yost document
contain search control knowledge. They also contain utility
knowledge, implicitly. The search control knowledge assumes a
particular method for solving the problem. The ontologies do not.
The utility knowledge is implicit in the ordering of proposing and
fixing rules. We carefully specified the problem so that these
utility functions we not part of the task description. Nowhere does
it say in the formal description that the elevators need to be
designed in the order prescribed by the heuristics in Yost.
Your analysis reveals some important assumptions:
1. control knowledge is NECESSARY to solve this design problem.
2. propose and revise method is the only way to solve the problem.
3. the propose and fix heuristics are appropriate forms for the
knowledge.
Part of the experiment is to tease out assumptions about our modeling
approaches, and to test hypotheses about knowledge reuse. So the fact
that you have represented the propose and fix heuristics in your
solution will help provide data on these issues.
> 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").
The semantics of the ontolingua specification are NOT specific to any
problem-solving method, including any algorithm for constraint
satisfaction. That's the point of a declarative specification. In
the configuration-design ontology, constraints are defined as a
special case of logical expressions; valid configurations are defined
as components whose constraints hold. That's it. You get to decide
how to compute over them. You could use a neural net as long as the
results are sound.
> After our discussion I am convinced that I have to change my understanding
> of propose&revise and that I have to change my knowledge representation to
> distinguish clearly between guesses and facts. Would you agree, that the
> ontolingua definition is a little bit weak too, since the difference
> between constraints performing range-tests like SUPPLEMENTWT_OF_CAR_VALUES
> and constraints that compute something like C131 is not really visible? My
> representation of the aboce two constraints is:
... <example in program-specific syntax>
> that is obviously method dependent, but I would consider it as
> clearer.
You get to categorize and reformulate the constraints any way you
want. I know of one group, for instance, that is building an ontology
of constraint types. The ontolingua specification is not meant to be
a user interface for the knowledge base, nor does it have to be the
form used internally by programs performing the task. If you discover
that you cannot solve the problem from the declarative specification,
that is a result worth reporting. If you find that reformulating the
knowledge in a method-specific syntax helps in eliciting constraints
>From domain experts, then that's also a finding.
tom