|
|
|
david trastour |
|
claudio bartolini |
|
chris preist |
|
|
|
hp labs |
|
|
|
semantic web support for the b2b e-commerce
lifecycle |
|
|
|
|
|
|
edi |
|
pros: less paperwork, faster transactions |
|
cons: direct and expensive one-to-one
connections |
|
|
|
electronic marketplaces |
|
pros: flexibility, better deals |
|
cons: not automated, more labour intensive than
edi |
|
|
|
agent mediated e-commerce: best of both worlds,
flexible but automated |
|
|
|
|
|
|
|
matchmaking is the process whereby potential
trading partners become aware of each other’s existence |
|
negotiation is a regulated process aimed at the
formation of an agreement among the participants to the process |
|
|
|
|
|
|
architecting for reuse: |
|
strategies vs protocols |
|
to develop a framework that can deal with many
types of interactions and market mechanisms |
|
to increase the degree of automation |
|
|
|
common language to support the different
structures of the lifecycle (advertisements, proposals, etc.) |
|
|
|
|
|
|
|
|
|
|
operations for matchmaking |
|
|
|
|
|
|
|
|
|
|
|
agreement template: parameters of negotiation,
their types and constraints on their value |
|
negotiation proposal: configuration of
negotiation parameters (exact value or constraints) representing a deal
that is currently acceptable to the submitter |
|
agreement: configuration of negotiation
parameters that parties find acceptable |
|
|
|
|
|
|
|
|
|
validation: proposals must be a valid
restriction of the parameter space defined by the agreement template |
|
protocol enforcement: proposals must be
submitted according to the negotiation rules |
|
agreement formation determines, given a set of
proposals of which two at least are compatible, which agreements should be
formed |
|
|
|
|
|
flexibility by allowing loose structure
(semi-structured data) |
|
sharing of common semantics |
|
expressive language |
|
negotiation templates and proposals should
describe services that are not fully specified (constraints) |
|
language should lend itself to performing
validation of negotiation proposals against the negotiation template and
compatibility checking of two negotiation proposals to determine if an
agreement can be made |
|
|
|
|
a proposal P is valid if it is a more
constrained version of the negotiation template T for this negotiation (T
should subsume P). |
|
|
|
|
|
|
the negotiation needs to identify all pairs of
proposals which are compatible (protocol specific rules are used to
determine exactly which pairs are used to form an agreement). |
|
let F be the set of all valid proposals currently
registered with the negotiation host: |
|
|
|
|
|
|
|
|
our experience with daml+oil |
|
|
|
|
|
|
operations on descriptions |
|
|
|
|
|
|
negotiation framework architecture |
|
|
|
|
|
|
|
consolidate both prototypes under one
environment (jade, racer, jess) |
|
use a standard interchange format for rules
(ruleml) |
|
work on various end-to-end scenarios to validate
the work |
|
work on multi-attribute utility theory |
|
|
|
|
|
use daml+oil to model the structure of contracts
(clauses, dependencies and constraints between clauses) |
|
use deontic logic to model the semantic of
clauses (obligation, permission, prohibition) |
|
contract formation: from a contract template to
a contract |
|
|
|
|
|
|
|
|
rules for admission of participants |
|
responsible role: gatekeeper |
|
admission rules: govern admission to negotiation |
|
|
|
rules for proposal validity |
|
responsible role: proposal validator |
|
validity rule: ensures that any submitted
proposal be compliant with the agreement template |
|
|
|
|
|
|
rules for protocol enforcement |
|
responsible role: protocol enforcer |
|
posting rule: determines circumstances in which
a participant may post a proposal |
|
improvement rule: specifies, given a set of
existing proposals, what new proposals may be posted |
|
withdrawal rule: specifies if and when proposal
can be withdrawn, and policies over the expiration time of proposals |
|
|
|
|
|
|
rules for updating status and informing
participants |
|
responsible role: information updater |
|
update rule: specifies how the parameters of the
negotiation change on occurrence of certain events |
|
visibility rule: specifies which participants
can view a given proposal |
|
display rule: specifies if and how the
information updater notifies the participants that a proposal has been
submitted or an agreement has been made |
|
|
|
|
|
|
rules for lifecycle of negotiation |
|
responsible role: negotiation terminator |
|
termination rule: specifies when no more
proposals may be posted (e.g. a given time, period of quiescence) |
|
|
|
rules for agreement formation |
|
responsible role: agreement maker |
|
agreement formation rules: determine, given
a set of proposals of which at
least two are compatible, which agreements should be formed |
|
tie-breaking rule: specific agreement formation
rule applied after all others |
|
