CPA negotiation, contact with negotiation research community plussome thoughts.

[Sacha Schlegel <sacha_oasis@schlegel.li>]

Hi CPA negotiation team

When I started with the CPA negotiation research project I was looking
at a negotiation suport system (at www.interneg.org) from the interneg
project.

Back then I exchanged 1 or 2 emails with:

> Dr. Gregory E. Kersten
> Professor of Decision and Information Systems, DSMIS
> Director of Information Systems and Technologies
> J. Molson School of Business, Concordia University
> 1455 de Maisonneuve Blvd. West
> Montreal, Quebec, Canada H3G 1M8
> http://commerce.concordia.ca/gkersten
> http://interneg.org/~gregory  

Today, after almost 2 years, I sent another email to Dr. Gregory E.
Kersten telling him about my research project and the CPA negotiation
specification. I added a link to screenshots of my work. To me, my
prototype implementation looks a little bit like a negotiation support
system. It guides the negotiation actor (currently a human user) through
the negotiation and makes sure, the negotiation actor follows the
negotiation protocol (bpss).

In New Orleans, I told Kartha, that we should get some closer contact
with the negotiation research community. Marty might also have some good
contacts with the (negotiation) research community. So I started off
with an email to Dr. Gregory E. Kersten.

Currently, I am having problems to make the link between an ebXML BSI
and a backend application. In the CPA negotiation process, the BSI
executes the BPSS and uses a Message Service Interface to exchange the
negotiation messages and the backend application will do the negotiation
part.

In my research project I provided a user interface, so the negotiation
actor could do the negotiation, eg. select how to react to an offer (or
counter offer) and to set values for a negotiable information item.

Now, the user interface, looks like the backend application. So
potentially, the automated negotiation of a CPA will be done completely
in a backend application. If software programs (or software agents) will
be the negotiation actors, I think this will be the backend application.

If the Automated Negotiation of CPA specification does not deal with the
actual negotiation, then I think the negotiation protocol (bpss), the
negotiation messages, and some negotiation rules, are already pretty
good. The problem I think is the high number of possiblites of what can
be negotiated, there are so many possiblities, that its difficult to
imagine.

So, if we want to continue the negotiation path, I think we need to talk
about the NDD more, specially about those types of the negotiable
information items. In my research I did not realy use an NDD but sort of
a restricted NDD, where users only could negotiate over values of
elements and attributes of the CPA template, not about ranges or
cardinality problems, or values with piecewise functions.

Also, I wonder how much negoitation information is necessary in an NDD.
Beacuse, in the end, the negotiation will be run in a negotiation
application (or software agent). So for example, a piecewise function
might expose already too much information. A simple reference to the
negotiable element or attribute might be sufficient. The only reason for
more information in the NDD was (as far as I remember), to potentially
converge to a solution faster. On the other hand, the CPA composition
process can use some more information, again on the cost of revealing
those information.

Please let me know what you think.

Sacha
-- 
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------