From: AAAI Technical Report WS-93-07. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Using negotiation and coordination in
collaborative design
K. J. Werkman
Advanced Technology Department
IBM Federal Systems Company
Mail Drop 0210, Route 17c
Owego NY 13827
USA
Abstract
This paper examines negotiation as a means of conflict resolution among participants
involved in the design,
manufacture and assembly process of designing connections in buildings.
A distributed
problem-solvlng
(DPS) architecture
which models participants
as semi-autonomous computer "agents" which reason from their
perspectives during design evaluation is presented. The system, called the Designer Fabricator Interpreter (DFI),
is a knowledge-based tool for providing a "collaborative design" interaction among structural engineers (designers), fabricators and erectors. The DFI System utilizes a novel incremental negotiation method called knowledgebased negotiation.
Alternative
connection designs are proposed through "agent" counterproposals
developed
from shared knowledge representations
called shareable perspectives.
An arbitrator
agent helps the agents
to reach an agreement. The resulting
distributed
artificial
intelligence
(DAI) based negotiation
scheme
provides a means for suggesting potentially "better" designs as a result of differing "agent" viewpoints.
1
Introduction
A new form of collaborative design information processing system will evolve in the near future which will contain
a variety of diverse database and knowledge-based "agent" subsystems. This new type of information processing
system will contain computerized "agents" acting as assistants
to human designers and engineers. Each agent
will have its own perspective on its particular domain of expertise. Agents will contribute to the design of an
artifact by sharing their view of the artifact with other design "critiquing" agents long before the artifact is ever
realized in a physical state. The result of such an automated collaborative design system will be better engineered
artifacts,
delivered in a timely fashion without encurring development cost overruns.
One key technology area that will enable the development of automated collaborative
design will techniques
from the field of Distributed Artificial Intelligence (DAI). The enabling technologies from DAI will include the
"Submitted for consideration
Washington, D.C., July 1993.
to the Workshopon AI in Collaborative
Design in conjunction with AAAI-93help in
tThe following work was performed while the author was employed by the NSF Sponsored ATLSSEngineering Research
Center at Lehigh University.
129
design of autonomousintelligent domainagents, creation of efficient interagent communicationlanguages, developmentof methodsof agent coordination, and provisions for conflict resolution through agent negotiation. This
paper specifically underscores the need for negotiation amongagents (automated or human)during collborative
design/cooperative problem solving in order to promote coordination. A novel form of incremental negotiation
called knotaledge-bagednegotiation is presented. Throughthis negotiation process, conflicts are resolved by use of
shared agent knowledgerepresentations called 8hareable agent perspectives. An agent’s perspective can be made
"shareabh~ by providing an agent issue indexing scheme. This allows other agents to relate to the first agent’s
issue or perspective, thus allows each agent to reasonably negotiate without complete issue knowledgeof the
others agents.
In the knowledge-basednegotiation schemepresented in this paper, all agents maintain unique perspectives
about objects in the shared domainof problem-solving. Each agent’s perspectives is grouped and accessible by
other agents through an indexing concept called the domainaspect. In addition, two agent perspectives can be
combinedto form another knowledgeconstruct called an interagent issue relation. Pairings of interagent issue
relations are then grouped into a relational network which is maintained by a third-party arbitrator agent. The
arbitrator uses this relational networkto develop alternative suggestions for the conflicting agents during its
mediation phase of assistance. The arbitrator develops its suggestion by first searching the negotiation dialog for
relevant issues betweenconflicting agents that occurred as a result of previous agent negotiation. The arbitrator
then reviews the shared network for relations that are known to exist between the agents. Uponfinding a
"reasonable" interagent issue relation, the arbitrator presents the relation to the agents whouse them to identify
other possible viable alternativea which they might not have considered during their negotiation. If agents
still do not agree (mediation fails), the arbitrator enters into a technique of binding arbitration which forces
"fair" solution on the agents based on their past negotiation dialog. The resulting research is implementedas
the Deaigner Fabricator Interpreter (DFI) System which integrates diverse agent knowledgeof the construction
domain into a "what-if" tool used for critiquing connection designs in buildings. The DFI system allows a
structural engineer at preliminary design time the ability to review alternative steel connections which have been
cooperatively evaluated from multiple agent viewpoints. The engineer can then select the connection design
which is the most feasible and economicto produce and hence more beneficial for the construction project.
This paper is structured in the following fashion. An overview of distributed problem-solving is presented in
Section ??. This is followed in Section 3 by an illustrative exampleto give the reader somefeeling of the agent
negotiation process. The actual Knowledge-BasedNegotiation System (KBNS)model is presented in Section
4. The various types of local and global knowledgerequired by the knowledge-based negotiation approach are
detail in Section 4.1. The concept of a shareable agent perspective is presented in Section 4.2. Section 5 details
the various agent proposal strategies used in DFrs knowledge-basednegotiation schemeincluding key issue and
agent issue proposal strategies. A discussion about the role of arbitration within DFI is presented in Section ??
including resolution techniques whenagent proposals fail (mediation and arbitration strategies) as well as general
arbitrator control strategies. Finally, a summaryand future work directions are outlined in Section 6.
2
Distributed
Problem-Solving
in DFI
The agents in the DFI system act in both a cooperative and competitive fashion when critiquing a proposed
connection design, through cooperative behavior, the agents work together toward a commongoal, suggesting
alternative connection configurations which are "similar" to that originally specified by the user. In addition,
agents also behave competitively during the proposal process in order to maximallyimprove their own positions
during each proposal cycle. To provide some meansof balance, an independent arbitrator agent is used to monitor
the agent proposal process and mediate the process, interceeding only when necessary. Even though the agents
behave both cooperatively and competitively, they still have a commongoal; produce the best answer for the
user. Agents evaluate and suggests alternative connection designs based on their ownviewpoints as well as in
consideration of other agents’ perspectives. Each agent viewpoint is decomposedinto unique agent issues based
on different aspects of connections such as economics, feasibility, and type of material, to namea few. The agents
and their respective issue labels are seen in Table 1.
The importance ofan agent issue dependson which agent viewpoint one takes (designer, fabricator, or erector)
within the context of a specific connection evaluation. During the proposal process, an agent will look at each
130
DESIGN
Table’ h Agent Labels
AGENT FABRICATOR
Strength
Stiffness
Reliability
Versatility
and Related Issue
AGENT ERECTOR
Fabrication Cost
Fabrication Ease
Material Cost
AGENT
Erection Cost
Erection Ease
Safety
.......
.....i
Figure 1: Designer’s
Initial
Configuration
connection previously proposed by other agents and evaluate any of its affected
3
An Illustrative
issues.
Example
This section provides a brief example of how a design evaluation proceeds between the agents after the user (a
structural design engineer) selects a particular connection design for evaluation. Each agent has unique knowledge
about connections including a standardized qualitative rating scheme foi the issues related to each connection.
After the user enters a connection and selects the evaluate option, the user is asked for a single, most important
key issue which is maintained by all agents during their proposal of alternate connection configurations.
In
this example, the user specifies an endplate connection with a key issue of strength. The key issue consists of a
single non-negotiable agent issue which every agent must consider before proposing an alternative.
During the
evaluation, other agents will attempt to suggest alternatives
that are of the same connection type as the key
issue connection proposal. Initially,
the arbitrator
takes control from the user and commands*the design agent
to accept the user’s endplate connection proposal using strength as the positive supporting (key) issue because
the user is the designer in the first cycle of the negotiation. The design agent then informs all agents of the key
issue and requests that the proposed connection be evaluated. The designer’s request is shown graphically in the
designer’s window in Figure 1.
Before each agent’s evaluation, the arbitrator
reviews all proposed connections to determine which agent is
most detrimentally affected and hence should go next. In this case, the erector agent is most severely affected
by the designer’s endplate proposal. The erector determines that the designer’s proposal is unacceptable because
the endplate connection is too difficult in terms of erection ease. Therefore, the erector refuses the designer’s
connection and looks to the fabricator in hopes that it might have proposed an acceptable connection. At this
stage, the fabricator has not yet proposed anything, so the erector selects a connection from the set of possible
connections it knows about which satisfies it’s erection ease issue as well as satisfying the user specified key issue.
Thus, the erector requests the plates-tee as seen in the erector’8 windowin Figure 2.
It is important to note that the erector has directed it’s proposed connection back to the designer for review
since the designer was the last agent to make a proposal. In this case, the designer accepts the erector’s proposed
connection because it exceeds the designer’s/~ey issue of strength as well as meets the designer’s criterion for the
"Commandsin the DFI agent communication language appear in bold italics.
131
!
Figure 2: Erector Replies WithPlates-Tee
Tm-eJL[’l’.*J LI~
J
...... J
Figure 3: Designer Agrees With Erector
endplate connection. Note that the erector’s proposal has increased the value of the key issue to the new value
associated with the erector’s proposed connection. By increasing the value of the key issue, the search space of
possible connection alternatives is reduced, thus causing the agents to converge more quickly on a set of agreeable
proposals. The designer’s acceptance is seen graphically in the designer’s window in Figure 3.
Next, the arbitrator assumes control and notices that two agents have proposed the same connection. Usually,
this would cause the arbitrator to inform all agents of a halting condition. This is not so in this case because an
"unfair" evaluation condition has occurred - the fabricator has not yet had a chance to evaluate any connection
designs. Thus, the arbitrator gives control to the fabricator whoreviews the last proposal (the designer’s acceptance in this case) and immediately notices that the issue of material cost causes a problem for the fabricator
agent. Since both the designer’s and erector’s connection are the same, the fabricator performs 0nly one review.
Here, the next best connection that maintains the ~ey issue as well as improves the fabricator’s material cost
issue is the direct flange weld with shear plate as seen in the .fabricator’s windowin Figure 4.
Again, the arbitrator reviews the evaluation process and notices that two agents have agreed on a connection
and that each agent has had a chance at suggesting an alternative. The arbitrator informs all agents of the halting
condition and control is returned to the user. At this point the user can ask any agent to ezplain its proposed
connection or continue with the evaluation. If the user continues, the arbitrator reviews the situation and notices
that no particular agent is in "peril", and allows the agents to determine their own control sequence. Whichever
agent received the last message is given a chance to respond to that message. In this case, the fabricator proposed
a connection to the designer. The design agent, upon reviewing this connection, notices that the fabricator’s
connection satisfies all issues of the designer and thus accepts the fabricator’s proposal as seen in the designer’s
....
r r~--
[l
"’"r’
................
" If " ........ II=’--’=
--"----’
"--’"
’"’’"’I’"*
’"
!,1
Figure 4: Fabricator Proposes Flange Weld
132
Figure5: DesignerAgreesWithFabricator
AfterContinuing
window Iin. Figure 5. This causes another halting condition upon where the arbitrator returns control to the user
In Figure 5, the user has the option of selecting buttons from the User/Arbitrator window. This allows the
user to obtain a summaryof the initial connection, review the agent dialog of the entire negotiation process from
start to finish listing each agent’s proposal and related issues. Also, the user can change the overall key issue
which focuses the negotiation, continue the agent evaluation, ask for help, or stop the agent evaluation and exit.
Moreover, the user can select buttons from the Agent windows and obtain a summary description for each agent’s
proposed connection or ask the agent to ezplain its last proposal action. The explanation appears in the system’s
Input/Output window beneath the Agent windows, as seen in Figure 5, and includes the key issue, the connections
under review, the agent’s response to the reviewed connections, i.e., the acceptance or rejection of other agent’s
connection, the reasons for the action, and the agent’s proposed connection with its justifications.
At times, it
is also useful for the user to be able to refuse and remove a connection from the evaluation process if the user
knows that a particular connection is not desireable.
4
The Knowledge-Based
Negotiation
Model
The knowledge-based negotiation approach used in the DFI system requires that agents must be able to communicate the problem, reason from their own and other agent’s perspectives, and finally generate a solution. For
agents to be able to contemplate the effects of their proposals on others, they need to share a commonbackground
of the problem domain. In addition, if agents are to provide some form of explanation of their reasoning of the
proposal process, they must be able to communicate issues that the other agents can understand. This is done
through the sharing of agent perspectives with other agents. Though sharing commonknowledge and agent
perspectives, agents can review the dialog of the negotiation and use this knowledge to make better informed
proposals at future steps in the negotiation process. The history of the agent dialog also provides a basis for
explanations for the user. The negotiation dialog describes the agents’ behaviors at each point in time during the
tControl is returnedto the user after each proposal cycle.
133
negotiation process. The user can use the resulting
which final solution to select.
4.1
Knowledge-Based
Negotiation
dialog-based
Knowledge
explanations
to make a better
decision
about
Requirements
This section details the types of knowledge required by a knowledge-based negotiation
system (KBNS). In
KBNS, three types of knowledge are maintained. The first
type of knowledge is shared knowledge which is
accessible to all agents including the independent arbitrator
agent. The shared knowledge includes domain object
knowledge as well as knowledge about the history of the negotiation dialog. Object knowledge includes such
things as the names of objects known to all agents in the domain and is predefined and static in the system.
In DFI, this includes a list of connections labels (connection proposals), a list of connection component pieces
(proposal attributes)
and a list of agent issue labels (aspects of proposal attributes).
The negotiation history
includes all agent proposals, rejections,
and counterproposals made by the agents and is dynamically generated.
The second type of knowledge maintained by the DFI system is unique agent knowledge. In DFI, this includes
specialized knowledge of construction processes maintained by each agent which is also statistically
defined in
the system.
The third form of knowledge in the DFI system includes knowledge maintained by the arbitrator. The arbitrator
agent maintains both local unique agent knowledge related to mediation and arbitration strategies as well as shared
agent knowledge including object knowledge, agent issue labels and the negotiation dialog. In addition to this
shared knowledge, the arbitrator also maintains each agent’s shared perspective of domain objects. The arbitrator
maintains this knowledge in a relational
network of shareable agent perspectives.
An example of a network of
interlinked agent perspectives is seen in Figure 6. The figure contains three agent nodes each with its own loca/
issue nodes (grey block of issues), linked by agent issue links. The two remaining types of nodes in the figure are
the domain aspects and the domain object nodes (boxes with rounded corners). Each agent node is linked to a
domain object by means of a commonly accepted domain issue link isuch as expense~ which also passes through
a domain aspect node. This linking of nodes comprises a shareable agent perspective in the relational
network.
When two unique agent perspectives
are linked to the same domain object, the results is an interagent issue
relation. This is seen in the figure as a heavy black line. The arbitrator uses the interagent issue relations to aid
in selecting probable alternatives for agent’s to consider when they find themselves in a "deadlock" situation and
can not develop their own proposals. In the DFI system, this network is called the DFI Relational Network.
4.2
Shareable
Agent
Perspectives
An agent perspective includes a combination of agent issues and other domain factors that are related to an object
being evaluated given the context of the evaluation. An example of an agent perspective for a design agent in the
DFI system would include one of the designer’s agent issues of strength, stiffness, versatility or reliability related
to one of the connections known by the design agent. An agent perspective is different from the concept of object
perspective as described by Bobrow in the KRLlanguage [1]. Object perspectives usually include the selection of
specific object attributes
that are inherited from an object taxonomy depending on the focus of the perspective.
Instead, agent perspectives are a separate knowledge structure orthogonal to the object taxonomy, much like the
concept of domain perspective presented in work by McCoy[2]. Domain perspectives include salience values to
indicate which perspectives are highlighted and which are suppressed.
Two agent perspectives
can be combined with shared knowledge of domain aspects and domain issues to
produce relational "links" between issues of the two agents. These interagent issue relations make up a network
of relationships
which are maintained by the arbitrator
agent. Because all agent issues are made available to
a third party arbitrator in the form of agent perspectives and interagent issue relations, agent perspectives can
be considered "shareable." Agents can query the arbitrator
to check for the existence of a particular interagent
issue relation. Once an agent obtains a interagent issue relation between itself and another agent, it can use
this newly acquired knowledge and combine it with any past proposals found in negotiation dialog to develop a
counterproposal which might be more acceptable than if the agent had not had this knowledge available.
134
DomainImmeLinks
Interaoem
IssueRelation
Figure 6: Example Relational
4.2.1
An Agent
Network
Perspective
Eachagent’s perspective of a given domainobject is composedof the agent’s local issue, a domainissue link, and
a domain aspect, as seen previously in Figure 6. These three elements make up a context in which the agent
views a domainobject (that agent’s perspective). The first element, the agent’s local issue, consists of ordinal
values which allow the agent to rank the issue’s level of desirability. The second element, the domainissue link,
links the agent’s local issue to a shared domainaspect and thus provides a way of relating (grouping) common
domain concepts (domain issues) amongthe agents. Domainissues could be used to effect the outcome of the
negotiation by causing each agent to focus on a shared issue during its proposal cycle~. Domainissues can also
be used to develop general explanations that are understood by all agents. The third componentofa "shareable"
agent perspective is the domainaspect and is described below.
4.2.2
Domain
Aspects
Domainaspects are similar in concept to domainperspectives as described in work by McCoyon correcting dialog
misconceptions by use of agent perspectives [2]. Both DFI’s domainaspects and McCoy’sdomainperspectives are
similar in their four major characteristics. Both concepts include salience values to indicate which perspectives
are to be highlighted and which are suppressed over the entire domainof objects. Second, both are separate data
structures that are orthogonal to the system’s object generalization hierarchy. This differs from the concept of
object perspective described in the KRLlanguagewhich involves highlighting certain attributes of a single object.
Third, any number of domain objects can be viewed from the same domain aspect or perspective. Somedomain
aspects might not be applicable (make sense) to every domainobject, but this is acceptable considering that
in real life the same thing happenswhenone tries to apply a particular viewpoint to all possible objects in the
world. The fourth major characteristic of McCoy’sdomainperspectives states that only one domain perspective
is active at any one time during an evaluation. In the DFI system, one domainaspect is active for any given
:To someextent, a morelimited approachis used initially in the DFIsystemwhereone agent’s local immue(referred to
as the key iaaue) is usedto focus all other agents’ proposals. This is describedbelowin Section 5.
135
Asent Issue:
Slrongth (+)
DcsiL,ncr’sPcrsncct/yt~
Domsin Issue: Performance
Domain Aspect: Functional
Reason: UNr Selected
Fxc~tor’sPerspective
Domain Issue: Expense
Domain Aspect: Fmtene,’s
Reason: Field Operations
7
FABK[CATOR [
Agent Issue~ Erection Cmt (-)
Figure
7: Example Interagent
Issue
B.elation
agent at one time. During an evaluation,
two agents might be viewing the same domain object (connection)
from their own agent perspective and hence unique domain aspect. Therefore, an object can be considered from
several viewpoints at one time in DFI.
4.2.3
Interagent
Issue
Relations
An example of an interagent issue relation which links two agent’s unique perspectives
to a commondomain
object is shown in Figure 7. The domain issue which links the two agents’ perspectives during a negotiation cycle
can be different and an interagent issue link will still exist between the agents. In the example, a design agent
with an issue of strength and an erector agent with an issue of erection cost are linked to the endplate connection
via their own unique agent perspectives. The designer’s perspective on the endplate connection is seen through
the functional domain aspect based on the domain issue of performance. The erector agent views the endplate
connection through the fastener domain aspect with a domain issue of ezpense. From the designer’s viewpoint,
the endplate connection is favorable based on the supporting issue of strength (noted as a "+" in the figure) given
the domain issue of performance. From the erector’s perspective, the endplate connection is undesirable based
on the detracting issue of erection cost (noted as a "-" in the figure) given the domain issue of expense. Attached
to each agent’s issue is a reason describing why that agent considers the issue as supporting or detracting from
the agent’s goal. The supportive reason for the strength issue of the endplate connection from the designer’s
perspective is because of the detail material used in the connection (the endplate detail material is strong). From
the erector’s viewpoint, the endplate connection is costly (erection cost) because of the field operations required
to assemble the connection in the field (alignment problems for bolting the endplate).
5
Agent Proposal
Strategies
There are many negotiation proposal strategies used between agents depending on the type of role the agent plays
in the system. In the contract-net protocol the role of the agents is to recognize and allocate resources to agents
to allow them to perform their tasks. The nodes in the contract-net protocol generate proposals and negotiate
136
Table 2: Designer and Erector Interagent
Design Agent
Perspective
AGENT
ISSUE
REASON
DOMAIN ISSUE
DOMAIN ASPECT
Issue Relation
Erection Agent
Perspective
: Designer
: Strength
: Detail Material
: Performance
: Functional
AGENT
ISSUE
REASON
: Erector
: Erection Cost
: Field Operations
DOMAINISSUE : Expense
DOMAINASPECT : Fasteners
without any historical use of previous agent interactions. This is not the case in knowledge-basednegotiation
systems like DFI which attempt to produce detailed explanations of agent interactions during the negotiation
process.
5.1
Key Issue
Directed
Proposals
In DFI, the focus of the agent proposal and negotiation process is controlled by a key issue. The key issue consists
of a single (local) agent issue which every agent must consider before proposing an alternative connection. Since
the key issue is non-negotiable and must be maintained throughout the negotiation process, the key issue agent’s
viewpoint tends to becomedominant. Because the key issue agent is given the powerto maintain a non-negotiable
issue position, it attains a higher bargaining powerover the other agents. This elevated bargaining power helps
constrain and focus the proposals made by the other agents. In the DFI system, the key issue is selected by the
user and reflects the user’s interest in a particular agent issue for a given connection evaluation.
5.2
Agent
Issue
Directed
Proposals
The general agent issue directed proposal schemeseen in Figure 8 has been implementedfor distributed problemsolving amongsemi-autonomousagents in the DFI system. In DFI, each agent (called the reviewing agent when
reviewing a connection) reviews all of the other agents’ proposals and then proposes the best alternative possible
(by either accepting an existing proposal or generating an alternative counterproposal). Each agent reviews
another agent’s proposal based on the first (reviewing) agent’s unique set of issues and howthey are affected
the characteristics of the proposal.
The process outlined in Figure 8 starts with the reviewing agent evaluating the proposing agent’s connection
to determine which issue is most problematic based on the connection’s characteristics. If the reviewing agent
finds that the current connection proposal is acceptable, then the reviewing agent accepts the proposing agent’s
connection and proposes this as its own solution. If on the other hand the reviewing agent notices that one of
its particular issues is effected, the reviewing agent will search for a counterproposal which improvesits effected
issue while maintaining or improving the value of the user’s initial hey issue. The reviewing agent then generates
alternatives that enhance the worst issue and submits this list for review to the hey issue agent. The key issue
agent selects only the connections that meet or exceed the user specified bey issue and returns this newlist back
to the reviewing agent.
In an attempt to provide a coordinated behavior amongthe agents (cooperative solution), the reviewing agent
sends the list of alternatives which meets the key issue to the proposing agent for its review. This gives the
proposing agent a chance to rank the list of alternatives based on its preferences~. The reviewing agent then takes
IIn cooperative modeonly. In competitive mode,the original proposingagent can also delete connections it finds
unsuitable.
137
~,v/ewl~Aa*hi DeterminesWc~t/smu,
Generates
Alternatives
Bssedon Issue,
I
I
Ask KeyIssue Aamn~
to Sele,~
I
Alternatives WhichMeet Ihe Key Issus.
I
J
i
/
ASKProDomln~A~ to Order this Liid
/
Breed on Proposing Agen/’s Per~lvs~
f
~BCSecl
leCt Res/Alternative from Returned LI~
on Rovlimllna Aoenl’s Preference.
i
t
i
q
i
[
-@
J
la*m S*iects Bsst Altsrnativsl,
I
[
Figure
~,om
,*,t st Pot,,,.,IJutomsth,.,.
]ProposesBern Alternative
8: Agent Evaluation
I
and Proposal
Process
this ordered list and selects its best possible connection counterproposal in response to the proposing agent’s
initial proposal. The reviewing agent saves this specific counterproposal and performs a similar evaluation for all
other agent proposals. Uponevaluating all other agent proposals, the reviewing agent selects its best alternative
from its best alternatives list and proposes that alternative to the initial proposing agent whose proposal is to be
replaced by the reviewing agent’s proposal. This last action can be varied by the evaluation mode of the reviewing
agent. If the reviewing agent takes the competitive help single agent approach, the reviewing agent will simply
select and counterpropose its best alternative from its beat alternatives list as described above. If on the other
hand the agent takes the more cooperative help other agents approach, an additional review it performed by the
reviewing agent on the alternatives in its best alternatives list to find an alternative which might be beneficial to
other agents.
6
Summary
and
Future
Work
In summary, this paper tried to present the need for Knowledge-Based Negotiation Systems (KBNS) as part of
collaborative design system. As users wish to utilize knowledge from many knowledge sources to develop "better"
or more complete answers to their queries, they will require systems that can integrate diverse viewpoints. The
incremental negotiation scheme called knowledge-based negotiation presented here is one potential approach to
solving this problem. This scheme allows agents which share a commonbackground to behave both cooperatively
and competitively during negotiation, thus providing a form of critical
evaluation of the user’s query. This is
accomplished by use of a shared knowledge representation called shareable agent perspectives ~ A grouping of two
of more shareable agent perspectives results in an interagent issue relation that relates agents to domain objects
by means of domain aspects. A network of these relations is maintained by a third party arbitrator agent who
~Acomprehensive overview of shareable agent perspectives can be found in [3].
138
uses them during its mediation phase of conflict resolution. The arbitrator
selects an interagent issue relation
based on a review of the negotiation dialog for issues that exist between the conflicting agents. The arbitrator
suggests the interagent issue relation to the agents in hope that they will consider it as a viable alternative. If this
fails, the arbitrator enters its arbitration phase of conflict resolution which includes such techniques as setting
time limits and searching the negotiation dialog for other proposal alternatives
that have similar advantages and
disadvantages for each of the conflicting agents. The resulting research is demonstrated as an implementation
within a knowledge-based tool called the Designer Fabricator Interpreter (DFI) System which structural
design
engineers may use to evaluate preliminary designs from the additional perspectives of fabrication and field erection
in order to avoid potential "downstream" problems, thus reducing costs and saving time.
Current and future work includes the reimplementation of the knowledge-based negotiation scheme in the DFI
system into a more generic tool for use in other application domains. Currently, work is being done to modify
the DFI system to be used in a concurrent engineering setting where the system will act as a coordinator of
cooperative problem solving between human and computer agents. Even though it is believed that a sequential
pair-wise interaction between agents in greatest disagreement is best, additional agent interaction scenarios are
being investigated. As the system is extended to more than 3 agents, as in the case of the concurrent engineering
task (involves manyfunctions such as marketing, systems engineering, software engineering, manufacturing, etc.),
the problems of pair-wise agent issue interaction (and their potential reviews by the arbitrator) will be examined.
Also to be examined is the issue of agent behavior (competitive vs. cooperative mode) during negotiation.
KBNSarchitectures
are applied to multiagent application domains such as in ICIS, more will be learned about
the types of knowledge which compose agent perspectives and how to best share that knowledge among others in
the distributed cooperative problem solving (DCPS) system. The result should be more "thoughtful" answers
user queries through the coordinated interaction
of many diverse knowledge sources of which KBNSarchitectures
will be an integral part.
Acknowledgments
Special thanks to Mr. Marceno Barone who developed
Relational Network.
the construction
domain relations
used in the DFI
References
[1] D.G. Bobrow and T. Winograd. An overview of krl:
1:3-46, 1077.
A knowledge representation
[2] Kathleen F. McCoy. Generating context-sensative
Intelligence, 41:157-195, 1990.
responses
to object-related
language. Cognitive Science,
misconceptions.
[3] Keith James Werkman. Multiagcnt Cooperative Problem Solving Through Negotation and Perspective
PhD thesis, Lehigh University, 1990.
139
Artificial
Sharing.