OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [legalxml-econtracts] Automated Negotiation and Contract Markup



Is this looking at an agent to agent negotiation or an agent to human negotiation, or both? It may be that the requirements are different depending upon human and agent actors.

I think a generalized model of how contract negotiation between humans takes place might be a useful backdrop or context to begin with. Has this already been done?

---------- Original Message ----------------------------------
From: Dave Marvit <dave@marvit.org>
Date:  Wed, 16 Apr 2003 16:34:24 -0700

>Automated Negotiation and Contract Markup
>Dave Marvit <dave@marvit.org>
>Dr. Leff  <D-Leff@wiu.edu>
>
>Automated negotiation reveals several requirements for the
>representation of electronic contracts. However, they do not fit the
>discussion format (Jason’s) that seems appropriate for many of the
>other scenarios. As such, please consider this discussion as a way of
>expressing these requirements. The scenario this discussion refers to
>is available at:
>http://lists.oasis-open.org/archives/legalxml-econtracts/200302/
>msg00016.html
>
>Our model for automated negotiation involves two parties exchanging
>‘proposals’ that represent suggested sets of business terms. These
>proposals require a parameterized representation of the terms. However,
>the proposals need not be the contract itself. All that is required is
>that a contract can be uniquely generated from a set of agreed-upon
>parameters.
>
>This also means that there need be no indication in the contract of
>which terms are negotiable. In fact, from a game-theoretic standpoint,
>there should NOT be any indication in the contract of what is or is not
>negotiable. This reveals more information to the other party than one
>might want to.
>
>It is also a requirement that the negotiation system must be able to
>represent constraints. Some of these constraints can be shared between
>the parties (if you deliver blue widgets then I need them by Tuesday)
>while others are probably best kept internal (I cannot sell more than
>six blue widgets because I only have 6 blue widgets to sell).
>
>In any case, the ability to share constraints mandates that contracts
>be able to represent constraints in a parameterized way.
>
>Making sure that our contract representation supports full
>parameterization and constraint representation is useful in many areas.
>We can easily see how it would be valuable in automated negotiation, in
>drafting, and in compliance. There are probably many other areas as
>well.
>
>So, two requirements emerge.
>1. Complete Parameterization such that a contract can be uniquely
>generated from a parameter set.
>
>2. Some method of representing constraints in the contract that can
>also be parameterized.
>
>As far as we have determined, there are no other requirements that an
>automated negotiation system imposes on the format of eContracts.
>(Comments are especially welcome on this point.)
>
>A couple of open questions:
>1. Is the markup needed to represent constraints and parameters in a
>contract necessarily the same as the markup that is needed to extract
>them from a contract? (For example, extraction is important for
>compliance, while going from parameters to contract is important for
>negotiation, drafting, and automated contract generation – and possibly 
>Dr. Leff’s ‘Dispute Resolution and Litigation Involving Contracts’.)
>
>2. Are requirements for, and applications of, parameterization and
>constraint representation different in different legal application
>areas? For example, do the same methodologies work in contract
>representation and in, say, legal filing applications, or generalized
>document construction outside of the legal realm?
>
>
>As always, comments are much appreciated.
>
>Dave Marvit and Dr. Leff
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]