RE: Business Protocol (was: Application Protocol Definition)

Behind offer and accept there is a communication act and Web services can do
that by exchanging offer and acceptance messages. Whether it's an offer or
acceptance, legal contract or imaginary contract, depends on the information
contained in the message.

In my opinion you would want some framework for describing offers and
acceptance from a contractual perspective, and a generic framework that
could associate these business semantics with the specific data that is
communicated, e.g. defining one as an ontology and the other using RDF.

There is more than one way in which we can formulate an offer, but to
transact we need to agree one some specific ways to formulate it. This
approach is interesting since it allows us to formulate it in various ways,
yet indicate that all these ways talk about the same offer.

For example, a purchase order with line items can be an offer to buy, a
purchase order that just references another quote is also an offer to buy,
and a reorder is also an offer to buy. So one framework is used to express
the idea of an offer to buy in exchange for payment, and serveral different
documents are defined that express these offers depending on how you would
realize it (first time buy, repeated buy, w/RFQ, etc).

The business protocol would be affected by the way you formulate the offer
depending on the context, but the idea of an offer to buy remains abstract
and decoupled from any specific business protocol.

Which is why I prefer not to use the word 'protocol' to describe an offer to
buy and its acceptance. As this document clearly illustrates there could be
multiple different protocols (I offer you agree, I offer you act, I offer
you counter offer, etc) for the same business commitment.

arkin


> -----Original Message-----
> From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
> Sent: Friday, February 28, 2003 8:50 AM
> To: bhaugen; Assaf Arkin
> Cc: www-ws-arch@w3.org
> Subject: RE: Business Protocol (was: Application Protocol Definition)
>
>
> This conversation is getting a bit cryptic, at least to me.  You guys
> seem to know a bunch of antecedents that may not be immediately familiar
> to others.  So when you get this all straightened out to your
> satisfaction, could you please explain it in a little more detail for
> those of us that are not exactly following?
>
> Incidentally, I looked at the source you linked to below
> (http://www.gldialtone.com/UCCformation.htm) and I find it pretty
> interesting.  It occurs to me that it might be amusing for someone with
> a background in this sort of thing to sit down some rainy Saturday
> afternoon and illustrate how the five elements of an offer (defined as
> "the demonstration of willingness to enter into a contract") can be
> accomplished by a Web service.  I think that the definition of the
> contract itself is probably beyond a reasonable present scope of Web
> services (although I believe Frank has ambitions in that direction), but
> perhaps "offer" is not.  If someone went through this exercise (and I
> personally don't feel qualified to do so or I would just do it) we could
> then look at the results and see if it has a plausible home in the
> architecture.
>
> Or is this trivial?
>
> -----Original Message-----
> From: bhaugen [mailto:linkage@interaccess.com]
> Sent: Friday, February 28, 2003 6:31 AM
> To: Assaf Arkin
> Cc: www-ws-arch@w3.org
> Subject: Re: Business Protocol (was: Application Protocol Definition)
>
>
>
> Comments interspersed.
> Not trying to make this into yet another permathread,
> but the distinctions I made have evidence behind them.
> They are not arbitrary.
>
> > > Here are some distinct things:
> > > 1. Offer-Acceptance as a description
> > > of the rules of contract formation.
> > > 2. UNECE Recommendation 31, Electronic Commcerce Agreement as a
> > > pretty neutral set of rules for doing offer-acceptance
> > > electronically. 3. RosettaNet PIP 3A4 as a document specifying
> > > a particular set of messages and signals for executing
> > > UNECE Recommendation 31.
> > > 4. An ebXML BPSS script describing PIP A34 in XML
> > > (which RosettaNet is actually developing).
>
> > At least in my understanding #1 and #2 are equivalent, with #1 being
> any
> > Joe's description and #2 being a UNECE Recommendation, but they are
> both at
> > the same level.
>
> #1 is not electronic.  It is the basic rules for offer-acceptance as
> found in a commercial law book.
> http://www.gldialtone.com/UCCformation.htm
> #2 is a description of how to do #1 electronically.
>
> > No #3 and no #4 seem to be at the same level.
>
> #3 is a document.  It is not executable.
> #4 is a script meant to be executed.
>
> RosettaNet and UNCEFACT both know the difference very well. RosettaNet
> already has #3, and is working on #4.
>
> UNCEFACT has a UML version of #3 and
> want to generate #4 from #3 using production rules.
> They'll also generate RDF from #3.
>
>

Received on Friday, 28 February 2003 23:54:31 UTC