next action based on the negotiation protocol and the
adopted strategy. We have collected the most
important actions and depicted them as concepts in
our ontology in an attempt to describe internal
behavior in each phase of the negotiation for each
participant. Among the concepts we discriminate:
Prepare Preference, Send, Receive, Prepare
Proposal, Make Choice, Matchmaking-Critic etc.
Negotiations depend a lot on the modeling of the
item that is under negotiation, since different
approaches can be adopted depending on the
negotiated-item. For example, negotiation schemes
for multi-attribute items can become very
complicated. An agreement on the negotiated object
properties that should not be altered, such as
minimum and maximum values of properties and
flexible or “don’t care” properties, has to be
established in an early step. Participants may express
these constrains upon the concepts of the negotiated
item ontology.
Every negotiation can be modeled as a peer-to-
peer interaction. Based on that, we decided to model
the negotiation process as peer-to-peer interaction in
flexible way that can be extended.
5.2 Modeling Interactions
The above defined representation of the negotiation
domain captures the static view and not the dynamic
view that is very important in interactions. The FSM
ontology was defined to address this requirement.
The most important concepts of the UML FSM
notation were used to describe the negotiation
process as an FSM diagram. Such an attempt that led
to an FSM ontology based on UML FSM notation is
also presented in Dolog (2004).
Negotiating participants go through a process
that can be described as a sequence of states. Each
state describes the exact phase of the negotiation.
During a state one or more activities are performed
by each negotiating party. Usually one participant
performs some activity while the other waits for an
event to occur. The description of the activity will
come from the negotiation ontology. Entry actions
of states can be used to perform the setup needed
within a state, as for example the check for validity
in an incoming message. Exit actions can be used
for the required clean up before exiting the state.
Transitions can also have actions which usually
produce a message from the message ontology for
the waiting participant. The transition guards contain
SWRL rules in order to create Boolean Expressions
for the firing of transitions. It should be noted that
the Completion Transition has no explicit trigger
event but it is fired by the completion of the
activities of the current state.
FSM notation has already been used for
modeling the negotiation process domain (Kumar,
1998 - Su, 2000). In (Kumar, 1998) a very simple
representation is presented trying to catch only basic
states in an English auction negotiation mechanism.
In (Su, 2000) again the possible phases of the
negotiation are represented as FSM states and the
transitions between states are fired from “send” and
“receive” proposals. The diagram produced is more
complex and uses numerous states trying to catch
the internal behaviour for each participant for the
bilateral bargaining negotiation scheme. Our
approach uses: a) a rule-based basic negotiation
protocol to give the desired generality, and b) the
FSM notation for specific scheme description able to
catch all important details using well defined
semantics.
Benyoucef and Rinderle stating the FSM
limitations propose Statecharts due to their
advantage in executability, popularity and
completeness. The Process Specification Language
(PSL-
http://www. mel.nist.gov/psl/) provides another
alternative for modeling interactions. PSL was used
for this purpose in (Tamma et al., 2005) although the
applicability is not proven.
5.3 Automated Generation of Stateful
Web Services
One important issue towards automation is the
translation of the OWL document describing the
overall negotiation process, to an OWL-S document
that will give the semantic description of the SWS
created to handle the negotiation for each party.
What is needed is to translate and map between
XML-based (OWL and OWL-S) documents. For
this, XSLT will be used to grasp all appropriate
information from the OWL document and generate
the OWL-S SWS description. In this way our engine
will only have to be in position of using a simple
XSLT engine and understanding and using the well
known ontology concepts.
Web services, by their nature, typically do not
maintain state information during their interactions.
However their interfaces must frequently allow for
the manipulation of state, that is, data values that
persist across and evolve as a result of SWS
interactions. Especially in our case a way of
remembering previous proposals must be
implemented. We could leave this job to the private
negotiating engine but selecting stateful resources is
another way of taking burden from the internal
proprietary engine of each party and injecting it to
TOWARDS A FRAMEWORK FOR AUTOMATED E-NEGOTIATIONS
171