3.     SILKROAD Approach

The primary goal for the SilkRoad framework is to facilitate the design and implementation of electronic negotiation media according to the definition discussed in this section.

The two core elements of SilkRoad are the Roadmap and the Skeleton. The Skeleton provides several modular and configurable negotiation service components and can be classified as an application framework [8] – the skeleton of an Enimem. Hence, an Enimem is an instantiation of the Skeleton framework, which supports one or multiple agreement scenarios. Following the reuse and ‘inversion of control’ paradigm of frameworks, SilkRoad developers can subclass framework components to implement specific application logic. But the most common usage of the framework will be the customisation and deployment of Enimem instances of the Skeleton. The customisation affects the runtime behaviour of the Enimem and is based on specifications generated in the Enimem design.

Following the concept of media, the design of an Enimem has to encompass three dimensions [20]:

·       The communication design provides the structures of the logical spaces of the Enimem – syntactical and semantical representations of the agents, attributes of the items, and the terms and conditions of the transactions.

·       The organisational design describes the roles (structure) and protocols (behaviour) of agreement scenarios that will be supported by the Enimem.

·       The IT design addresses the architecture of the Enimem, its technical channels and interfaces.

SilkRoad assists all of the introduced design dimensions with the Roadmap design action-model, which prescribes how the design of an agreement scenario is performed on the basis of the SilkRoad design meta-model (SDMM). Hence, in the case where one Enimem should support various agreement scenarios, the Roadmap design action model has to be applied several times, each time complementing the design of one agreement scenario.

In SilkRoad the complexity of the final IT design and implementation of electronic negotiation media is reduced to a generation of executable agreement scenario representations, which customise the behaviour of the Skeleton negotiation service component instances at runtime.

Before the design action-model can be applied, it is essential to perform an analysis of the preconditions of the agreement phase of the electronic transaction. For the organisation design, characteristics such as the transaction value (high, low, perishable etc.), the risk for the agents involved in this transaction, or the customisability of the item of the transaction have to be investigated in order to select an appropriate design for the electronic negotiation (see, for example, [3]). In addition to the characteristics of the transaction, this analysis also has to cover aspects of the agents’ roles (their beliefs, desires, intentions…) as well as the relationships between the agents (dependency, distribution of market power, level of confidentiality, intensity of information exchange, etc.). For the communication design (see below), this analysis needs to identify typical and necessary elements of the logical space, such as standard terms for transactions (delivery time, return policy, etc.) or common representation formats for the transaction items in a certain domain (e.g. computers are always specified on the basis of CPU speed, RAM etc.).

Figure 2: SilkRoad Roadmap.

Figure 2 illustrates the sequence of actions in the design action model and the input/output relations between these actions. The first action to be performed in the Roadmap is the agreement scenario communication design, which is based on the findings of the analysis of precondi­tions and the SDMM. Then the organisation design is performed, using the results of the communication design, the precondition analysis and the constructs provided by the SDMM for the organisation design. Finally, in the integrated design activity, the results from the organisation and communication design are refined, merged, and verified – resulting in one complete and consistent agreement scenario model, which can be used to generate runtime specifications for the deployed Skeleton instance.

Referring back to the layers of the media reference model, SilkRoad specifically addresses the community, implementation and transaction view. The roles and protocols of the community layer are modelled within the SilkRoad design phase. Actual processes on the implementation layer are then executed on the basis of the generated runtime specifications and the negotiation service component instances in the transaction layer.

The basis for all design activities in the Roadmap is the SilkRoad design meta-model (SDMM, see in Figure 3), which introduces the principal entity types and the relations between these types for the organisation design as well as the communication design.

Figure 3: SilkRoad design meta-model.

All entity types in the SDMM have associated properties except the relation and transition types marked in lighter grey, which are used to formalise relations between other entity types.

The SDMM captures both structural and behavioural aspects of agreement scenarios. The semantics of the entity types can be summarised as follows: An actor is a service or an agent. Items, transactions and agents are represented as concepts in an offer. An offer has three or more associated states. Actors create, delete or modify offers and cause events, which can stimulate transitions between the states of an offer. One event can be caused by multiple actors and might be associated with a set of offers. A transition always transfers an offer from one state to another, and will only occur if the guard condition is true. The ‘firing’ of a transition might also invoke an action.

The concept of state charts is the underlying modelling paradigm (for both the organisation and communication design). The advantage of state charts is that they are commonly used in information systems design and also part of UML [18]. Therefore it can be assumed that most designers are familiar with this approach.

For the remainder of this paper, the focus is set on the communication design aspects of SilkRoad. Organisation design issues are only referenced if they are coupled to constructs in the communication design. For details regarding the organisation design, see [22].

4.     Communication Design

The goal of the communication design is to structure the logical space of an electronic negotiation medium for a particular agreement scenario. The central objects of the communication design are the offers exchanged in a negotiation. Offer instances are the primary means of communication in the agreement phase (see, for example, [13]) and in the SilkRoad framework are the only supported type of structured interaction.

The SDMM distinguishes between two types of offers that can be issued by agents: offers-to-buy (O2B) and offers-to-sell (O2S). Depending on the agreement scenario chosen, a final contract might require that two compatible offer instances be found that are both signed by the originator with respect to the complementary offer (one-sided contracting), or that one offer instance of one type is signed by both agents (double-sided contracting).

In the Roadmap the design of offer types is separated into the definition of offer ontologies for the semantical aspects, and the specification of offer states for the syntactical aspects of offer communication in a negotiation.

4.1     Offer Ontology Design

The goal of commercial negotiations is to conduct one or more transactions between the agents involved in the negotiation. A transaction transfers one or more items (e.g. a product, money etc.) from one agent to another and vice versa. The transaction, the item, and the agent(s) involved can be described with sets of attributes such as the delivery date of the transaction, the colour of the item or the location of the agent. An attribute has a value or value domain such as ‘12-12-00’, ‘green’, or ‘Switzerland’.

Ontologies are formally specified models of knowledge, which can be used to share semantics among a set of agents. An ontology defines the concepts describing a certain domain and the relationships that hold between them [5]. It can be represented as a hierarchy of concepts. For electronic negotiations in SilkRoad domains have to be specified for the representation of and reasoning about the transaction, its related items, and the agents involved.

Figure 4 illustrates an (incomplete) example of a hierarchy of concepts in the domain of computer hardware items. A notebook, for instance, is a sub-concept of a computer and accordingly inherits the properties of computer, which are, in this example, the CPU clock speed, the type of the media drive etc. Notebooks are also sub-concepts of monitors, thus inheriting another set of properties (e.g. the display resolution). Properties in the ontology have a certain type and can be constrained, thus allowing only certain property values (in the example the CPU clock-speed is constrained to the range between 300 and 1200 MHz). Relations between concepts complement the ontology. An example of such a relation is that the CPU of notebooks has to have power management functions. It is possible to infer new knowledge on the basis of given facts. An agent could derive, for instance, that if a certain CPU is offered with notebooks, it must have power management functions.

Figure 4: Ontology example.

For a complete offer ontology design, this item domain has to be complemented with a domain ontology for the transaction, which defines possible attributes and attribute values for terms and conditions and an agent ontology. Domain ontologies can be reused for multiple agreement scenarios. Hence, the transaction and agent domain ontology in the example could also be used for scenarios designed for other items such as computer software or IT services.

In an offer instance, concepts from the item, transaction and agent domain can or must be used as offer properties to describe the proposed deal completely. The representation of concepts in an offer follows the notation domain.property (e.g. transaction.delivery_date, notebook.CPU, or seller.location).

The effort to design and establish an ontology for an electronic negotiation medium can be significant, as agents have to agree (in a social process) on this common terminology (see, for example, [2]). In other words, before ontologies can be used in the agreement phase, the agents have to negotiate on a meta-level the structure, meaning, and content of these domains – their common language. This meta-level negotiation is manifested in the ontologies developed or chosen for the latter electronic negotiation.

4.2     Offer State Design

In the offer state design, the dynamic structures of the offer-to-buy and offer-to-sell types for a specific agreement scenario are modelled. From a behavioural perspective, any offer instance in SilkRoad has a certain type and, at least and initially, three different states of formality during the negotiation process: advertised, bid and contracted. In the SDMM, an offer is associated with these three or more states, with one or more actors, and might be related to certain events. To associate a state with an offer, the notation offer.state is used.

The basis for the offer state design is a generic offer syntax specification developed for SilkRoad. This syntax defines the notation for structural offer elements such as property domains (e.g. price < $1000) or evaluation criteria (e.g. utility[price,$800] = 0.4). On the basis of the defined notation, offer instances are created and edited. The notation for property value domains, for example, is the syntax used to represent item, transaction, or agent ontology concepts in an offer instance. In general, the defined notation is not specific to one particular domain ontology but applies to all concepts represented in an offer.

In the meta-model the following abstractions of common offer notation elements with associated sets of notation options are available to represent an offer state:

·       Agents (one, n, unbounded)

·       Signatures (none, single, all)

·       Timestamps (none, start, end, both)

·       Domains (properties, values, ranges, dynamic)

·       Constraints (basic, negotiable, weighted)

·       Counters (none, n, unbounded)

·       Criteria (none, importance, utility, functions)

Details regarding the semantics of these notation elements can be found in [23]. The notation options are ordered in the sense that a ‘higher’ option allows a richer notation. To give an example, the value dynamic for the property Domains explicitly allows an agent to define the range of values for any property in an offer-to-sell, only if the agent knows more about the agent interested to buy. A typical example can be found in the insurance industry, where quotes are usually dependent on age, medical record, driving experience etc. A more restricted notation would disallow the dynamic option and limit offer specifications to a definition of domain ranges. Another example is the negotiable value for the Constraints element. It allows an agent to express the intention to concede this offer property if he/she is compensated with another property, thus enabling tradeoffs between buyer and seller (see [21] for further details).

The specification of the offer state notation is performed on two levels: required and optional offer notation elements. Generic offer templates for the three introduced states are provided by SilkRoad. The offer.advertised state, for instance, is characterised by the offer state notation in Table 1.

Table 1: State offer.advertised template.

These initial offer-state templates are the starting point of the communication design. Depending on the analysis of preconditions, further refinements and adaptations of the notation can be applied. Some scenarios might, for example, require property domain specifications with explicit values or ranges, whereas other scenarios may disallow dynamic property domains. To ensure compliance with the framework, templates cannot be changed arbitrarily; modifiable offer structure properties are explicitly marked (see Table 1 where ‘+’ indicates that a richer notation might be used and ‘-’ indicates that a more restricted notation is possible).

Additional states might be necessary to model the agreement scenario. These states are added in the organisation and integrated design (see Section 5). For each additional offer state the respective level of formality is also represented by enabling or disabling notation elements for the construction of offer instances.

The final step of the communication design is to assign the offer type with its related state design to domains specified in the offer ontology design. An offer type needs to be associated with at least one item domain, one transaction domain, and one agent domain. Multiple agent domains, for instance, might make sense if certain typical agent types such as distributors or outsourcers participate in a market and their properties might be referenced in an offer. If a concept (e.g. in the item domain a computer) has sub-concepts (workstation, notebook, etc.), the offer can be issued for any of the sub-concepts as well (this functionality is especially useful for advertisements where often general classes of products or services are offered, see Section 2).

This ontology association guarantees that the content of offer instances can be validated not only syntactically, on the basis of the offer state design, but also semantically against the domain specifications in the ontology. Hence, only properties related to the concepts and the concept relations defined can be used in the offer description. If an offer were assigned to the notebook concept in Figure 4, it is only possible for the construction of an offer instance to use constraints for item properties related to notebook, such as display resolution or CPU clock-speed.

5.     Integrated Design

In the integrated design of an agreement scenario, the deliverables from the organisation and communication design are integrated, refined, and verified – resulting in one complete and consistent agreement scenario model. On the basis of this agreement scenario model, runtime specifications are generated, which are used to customise the behaviour of an Enimem and to validate actual negotiation processes executed through the Enimem.

5.1     Integration and Refinement

The basis for the integrated design is the set of offer states defined for an agreement scenario in the precedent design activities. These offer states are the mandatory (and optionally customised) template states (advertised, bid, and contracted) specified in the communication design, complemented by additional states discovered within the organisation design.

The task of the organisation design is to model all necessary states of offer types within an agreement scenario and thereby to discover the associated actor roles, events, transitions, guards, and actions. One agreement scenario completed in the organisation design represents all necessary roles and the protocol for the complete agreement phase specification of a transaction in an Enimem. Roles are defined as the total of all possible events an agent can or must raise. The protocol constitutes all the rules in one scenario, represented by valid states and transitions, which define how agents come to an agreement.

Figure 5 illustrates an example of an organisation design. The graphical notation follows the UML conventions for state-chart diagrams. States are represented by rounded rectangles. The offer type related to a state is indicated with capital letters preceding the state identifier. Transitions are arrows connecting states. Events (‘E:’), guards (‘G:’), actions (‘A:’), and properties (‘P:’) are specified as textual information complementing the transition arrows.

Figure 5: Organisation design example.

For the organisation design additional state templates, so-called service-states, are pre-defined (shown in a lighter grey). One of the state templates from the communication design (O2B.advertised) is also represented in Figure 5.

The task of the integrated design is to add syntactical structure to the additional states stemming from the organisation design, and potentially to identify supplementary states necessary to represent the organisation design. Depending on the organisation design of the agreement scenario, agents can or can not, for instance, counter the offer of another agent by deriving a new bid that disputes some of the constraints of the original advertisement or bid. In the integrated design this additional offer state has to be reflected with a corresponding offer state representation where the notation element counters is set to the bound or unbound notation option.

The integrated design may result in additional offer states in order to reflect necessary changes to the offer structure. These changes might also require additional agent interaction. In the example in Figure 5, the score service can be invoked after an offer instance was matched. This requires the initiating offer to feature evaluation criteria such as utility functions. Therefore, an additional state O2B.updated is necessary if an offer in O2B.matched does not necessarily contain evaluation criteria. The event activating a transition from O2B.matched to O2B.updated is buyer.submitted. The guard for this transition specifies a successful validation of the modified offer according to the offer structure properties defined for the state O2B.updated.

The result of this design activity is an agreement scenario model with offer state specifications, which is complete from a communication and organisation design perspective, thus comprising the logical space (syntactical and semantical representation of items, transactions and agents) as well as the roles and protocols of the agreement scenario.

5.2     Consistency Checking

Merging the organisation and communication design in the integrated design phase enables one to check the resulting agreement scenario model for consistency and accuracy from a structural and behavioural point of view.

To be a valid agreement scenario model, the model has to comply with the following types of conditions:

·       Offer template states are modified only within the defined restrictions.

·       Events with actions activate only transitions to service-states.

·       Only service-states and actions available in the application framework are used.

·       Guard conditions evaluate only those offer properties and notation elements that are available at the preceding offer state(s).

·       Offer notation options required for subsequent service executions are specified.

·       Negotiation service component interrelationships are reflected (e.g. match is a necessary predecessor of mediate).

If the agreement scenario model passes the consistency check, the next step in SilkRoad is the generation of executable representations for this design[1].

6.     Generation of XML Schemata

This section describes how the communication design is transferred to XML schemata, which are used for the runtime validation of offer instances.

On the basis of the completed agreement scenario model, runtime representations for the Enimem can be generated. These runtime representations are persisted in communication and organisation design repositories as agreement scenario policies (see Figure 6). One Enimem can support multiple agreement scenarios, depending on the policies available in its repositories.

Electronic negotiation media are instances of the Skeleton. The facility in the Enimem responsible for controlling the execution of actual agreement scenarios is the policy manager. It checks, depending on the current state of the agreement scenario, offer instances for correctness as well as events and actions of agents for compatibility with the protocol and role specification in the organisation design. Depending on the underlying agreement scenario model the policy manager will also invoke services, if, for instance, a transition fires with an associated action for a negotiation service component. The current set of negotiation service components available within the Skeleton is outlined as well in Figure 6.

Figure 6: Runtime architecture overview.

6.1     XML Schema

XML Schema is a W3C working draft, which was published in April 2000 for review by the public and by the members of the World Wide Web Consortium [7]. In November 2000 it was considered to be stable and promoted to a candidate recommendation.

Schemata are used to specify classes of XML instance documents by describing the document structure in a much richer way than is possible on the basis of document type definitions (DTD) [6]. With the basic vocabulary and predefined structuring mechanisms of XML Schema, fine-grained constraints on XML documents can be defined, thus enabling rich automated validation. The primary advantages of using XML schemata compared to DTDs are that it is possible to express hierarchies of data types, and that schemata themselves are XML documents. Hierarchies of types are critical for the schema generation process in SilkRoad as model-specific types are derived from a set of generic types. Owing to their XML nature, schemata can be created in the same way (with the same tools) as traditional XML documents. Accordingly, it is not necessary to build an automated schema generation process from scratch.

In SilkRoad, schemata represent the logical space design of agreement scenarios at runtime. For each offer state definition in the integrated design a customised schema is generated. If different offer ontology assignments are used for the same offer states, additional schemata have to be generated. At runtime, agents use these schemata to construct or modify offers for the various offer states.

6.2     SilkRoad Base Schema

The foundation for the customisation and generation process is the basic SilkRoad syntax. A snippet of the syntax representation in XML Schema, the base schema, is illustrated in Figure 7.

The base schema defines fundamental constraints such as ‘an offer needs to have one or more specified item domains’. Overall, the base-schema defines all possible offer notations supported from a structural point of view by the underlying framework. All types in the base schema are declared to be abstract (using the attribute setting abstract="true” in the type declaration). Abstract types cannot be used in conforming XML document instances. Hence, all generic types need to be re-defined in the subsequently customised scenario-specific schemata.

Figure 7: Base schema.

To generate a state- and ontology-dependent schema, additional constraints are derived from the design specification, which lead to restrictions of the base schema. To restrict a schema, the following generic XML Schema mechanisms are used in the generation process:

·          Redefining types.

·          Deriving types by extension or restriction.

·          Changing attribute use from optional to required.

·          Forbidding the use of attributes with prohibited.

·          Assigning fixed values to attributes or elements.

·          Setting elements to be required (minOccurs = 1).

·          Limiting the number of elements (maxOccurs = x).

·          Deleting enumeration elements in simple types.

In the next sections, the subsequent scenario-specific derivation and customisation mechanism, which underlies the automated schema generation process in SilkRoad, is outlined.

6.3     State-dependent Customisation

Whereas the base schema defines a generic namespace www.silkroads.ch, a new unique namespace is created for each agreement scenario. Hence, the first step in the derivation and customisation mechanism is to define this agreement scenario namespace.

For all states defined in the agreement scenario model for an offer type, a corresponding state-dependent schema has to be generated that adds the state-specific offer notation to the agreement scenario namespace. This is done by importing all types defined in the generic SilkRoad namespace, and redefining state-specific types according to the notation elements assigned to this state in the offer state design. The process can be illustrated using the example of the state offer.advertised as defined in the template (see Section 4.2), which results in the following snippet of an offer.advertised schema for a sample namespace www.silkroads.ch/example:

Figure 8: State-dependent schema example.

In the example in Figure 8, the use of the START attribute of the OFFER type is required, corresponding to the notation element definition in the offer.advertised template. Deriving by extension or restriction in XML Schema is comparable to the inheritance mechanism in object-oriented programming languages in the sense that elements and attributes can be added or omitted, and specifications of the super-type can be overwritten. The state-dependent schema redefines only those types, where the offer design for this state manifests specific notation elements. For all other types, the definition in the base schema remains valid.

As outlined in Section 4.2, modifications to the templates can be performed within certain restrictions. If a specific agreement scenario requires, for example, an agent to define an expiration date for the advertisement, the OFFER type definition in Figure 8 would also set the use of END to required. To restrict, for instance, the domain structure to allow no value ranges, all elements of the OPERATOR enumeration for a domain (‘>’, ‘<’ etc.) except the ‘=’ operator are deleted.

The result of this first customisation step is the generation of a set of schemata, one for each offer-state, defining an agreement scenario namespace and constraining XML instance documents from a syntactical perspective. In the next step, semantical constraints are added.

6.4     Ontology-dependent Customisation

In this step, the ontology domain assignment for the offer type, performed in the conceptual communication design, is manifested in all generated state-dependent offer schemata. Ontology-dependent offer schemata are constructed using the syntactical notation from a state-dependent schema and the semantical concept specification from the ontology.

For each state-dependent offer schema, this ontology-dependent customisation has to be performed. The state-dependent offer schema is included (using the include schemaLocation directive in XML Schema) in a new ontology-dependent schema specification (which shares the namespace with the state-dependent schema). The base schema is also imported. A designer has two options for the ontology-dependent customisation:

·       Domain typing

This option defines for each property in the chosen ontology domain a new type as extension to the ATTRIBUTE_DOMAIN type.

·       Context typing

This second option adds more semantics through additional extensions of the CONTEXT and the CONSTRAINT type and the definition of corresponding element substitution groups.

The trade-off between these two options is that domain typing does not guarantee structural integrity – it cannot be validated, for instance, whether an agent used all necessary properties in the specification of an offer for a certain item domain represented as a CONTEXT. Context typing, on the other hand, does provide context structure, but the elements used in the specification are not standardised, thus making parsing much more complicated, because every property is represented with a specific domain and constraint element[2].

The first example shown in Figure 9 demonstrates domain typing for the WORKSTATION.CPU property, which is restricted to values between 300 and 1200 GHz (see the definition of the Computer concept in Section 4.1).

Figure 9: Ontology-dependent schema with domain typing.

Similarly all other concepts and (inherited or native) attributes from the chosen domain ontology are defined as extensions to ATTRIBUTE_DOMAIN types in the state-dependent schema. As the ATTRIBUTE_DOMAIN type is declared to be abstract in state schemata, only these new semantic domain types can be used for the actual offer specification.

In addition, the ontology-dependent schema declares new types with final="restriction", which prevents further restrictions of this type in new schemata, whereas extensions are still possible (e.g. if an agent needs to extend the MHz range or add GHz as another unit enumeration).

Figure 10: Ontology-dependent schema with context typing.

The second example shown in Figure 10 illustrates context typing, where additionally the CONTEXT and CONSTRAINT type are extended and complemented with corresponding element definitions.

Figure 10 demonstrates a customisation example for CONTEXT with the type WORKSTATION, and for CONSTRAINT with the type CPU_CONSTRAINT. The semantics of this example is as follows: the WORKSTATION type requires that a mandatory constraint be defined for the CPU property of a workstation. This CPU_CONSTRAINT can substitute any valid occurrence of an offer constraint in an offer instance document. Furthermore, the WORKSTATION.CPU domain has to be used in this constraint. The example also demonstrates how types from the base schema (denoted with the xsr: namespace reference) and types from the state schema (such as example:Context) are combined to construct the ontology-dependent schema.

6.5     XML Instance Document Examples

With the completion of the final customisation step in the previous section, the set of ontology- and state-dependent schemata for an offer type is complete and can be used to construct and validate XML offer documents at runtime. To demonstrate the result of the generation process, Figure 11 features an XML instance document compliant with the ontology schema in Figure 9.

In this example, the property types are specified with the xsi:type assignment for the ATTRIBUTE_DOMAIN element. It can be seen that only standardised elements such as ITEM_DOMAIN or OFFER_CONSTRAINT are used, thus simplifying the parsing of instance documents. However, there is no constraint that the WORKSTATION.CPU type is required in the offer.

Figure 11: XML instance document with domain typing.

This additional validation can be achieved with context typing and is illustrated in the instance document example in Figure 12.

Figure 12: XML instance document with context typing.

In the example in Figure 12 the type specification is used to assign the restricted WORKSTATION type for the ITEM_DOMAIN element, which requires that CPU_CONSTRAINT be used. The disadvantage of this added semantic is that an item specification may contain different constraint types: customised constraints (e.g. CPU_CONSTRAINT) and generic OFFER_CONSTRAINT elements, which are used, for instance, to define additional binary constraints.

7.     Conclusions

This paper demonstrates how the communication design of electronic negotiations is performed within the SilkRoad frame­work. The goal of the communication design is to define agree­ment scenario models for the logical space of an electronic nego­tiation medium. This logical space comprises the syntax and semantics of offer representations shared by agents, which nego­tiate item attributes and/or terms and conditions of an electronic transaction. The proposed solution is intended to avoid misunder­standings during the negotiation process, before an agreement is made and the settlement is enacted.

In this final section, the proposed solution is evaluated and compared with related research efforts.

7.1     Evaluation

Referring back to the initial claims, an evaluation of the presented communication design approach has to discuss two interrelated questions:

·       Can the ontology problem of electronic negotiations be addressed by the proposed solution?

·       Are XML Schema mechanisms useful for expressing and validating the communication design at runtime?

The result of the explicit communication design of electronic negotiation media within the SilkRoad framework is an ontology for the item, transaction, and agent domain, and state specifications for offer instances associated to these domains. To achieve a common understanding of the issues that are subject to the negotiation, these design deliverables can be specified in a joint process with all agents involved in the later usage of the Enimem. The constructs introduced in the SDMM (ontology definitions and state diagrams) support this meta-level agreement process, as they can be used for communication and discussion on a conceptual level. The resulting formal agreement about the semantics of offer representations is a necessary prerequisite for the latter negotiation support implementation.

Once the communication design has been mutually accepted, it can be transferred to a runtime representation, thus enabling the checking of a negotiation process for semantical and syntactical correctness towards the original design. Hence, assuming that both the communication design and the generation of the runtime representation are complete and correct, the ontology problem cannot occur during actual negotiation processes as violations of the agreed-upon logical space are detected. This is at least true for the agents originally involved in the design process. Accordingly, the admission of new agents to participate in the Enimem requires an acknowledgement of the logical space defined.

Whether the runtime representation is complete and correct depends largely on the mechanisms provided by XML Schema in association with the defined generation process. Various suggestions (see, for example, [5]) have been made to move from specific ontology formalisms (KL-ONE, KIF, frame logic…) towards more standardised and widely used representation mechanisms such as UML or XML document type definitions (DTD). The latter approach was chosen by Erdmann and Studer [6]. They point out that transforming ontologies into XML Schema appears to be more appropriate than into DTDs, mainly because of the ability to define type hierarchies. In [15], a process for the stepwise translation of an ontology to XML Schema is proposed. SilkRoad uses a similar abstraction-based approach, but in comparison, the communication models do not represent a complete ontology in a schema but only the selected set of concepts.

Regarding completeness, the status of the current representation is still insufficient. On the basis of domain typing, the relation of properties to concepts is lost if multiple concepts are represented in one ontology-state schema. This might be the case if an agent intends to issue a combinatorial offer for several types of goods (e.g. notebooks and servers). Related to this problem is also the fact that multiple inheritance cannot be represented in XML Schema. This is one of the shortcomings of the current framework, which has to be tackled in future work.

Beyond the completeness and correctness necessary to address the ontology problem, the usage of XML Schema provides additional advantages. As a forthcoming W3C standard, a number of powerful and widely accepted tools such as the Xerces parser [26] can be used to create or validate XML documents adhering to this standard. Hence, agents can easily interface with an Enimem by submitting XML documents. These documents can be edited, administered, and validated decentrally according to the internal processes of the agent’s organisation. Though this creates a distributed and decentralised system of negotiating agents, common integrity constraints are defined centrally using schemata.

XML Schema by means of the control options for the derivation process also offers the ability to extend the ontology in a decentralised way. Let us assume that a seller agent can offer computers with new features not reflected in the current ontology in Figure 4, e.g. a DVD writer. The domain schema specification could then be extended by the agent with a derived media drive type, which also includes an enumeration for the DVD write option. Using this extension functionality enables the ontology to be maintained in a distributed way. To guarantee the integrity of the overall ontology, the other agents certainly would have to approve such extensions.

Finally, from a technical perspective, the light-weight XML access interface to the Enimem, which allows for decentralised schema validation and extension, can be further extended across all functionalities (raising events to execute services etc.) if, for instance, SOAP (Simple Object Access Protocol, see [26]) is used as a general means of service invocation. This option is currently being investigated.

7.2     Related Work

This approach relates to work in the areas of negotiation support and semi-structured data models. From a negotiation support view, this work is an effort situated in the area of generalised models of negotiations, which is undertaken from an information systems perspective. Most approaches to modelling negotiations to date stem from an artificial intelligence (e.g. [16]) or decision science (e.g. [14]) background. In addition, the media concept with its explicit distinction in communication and organisation design aspects adds a different perspective on negotiation support. This distinction provides an additional level of abstraction and reduces the complexity of negotiation design significantly.

Approaches to the ontology problem of electronic negotiations that aim at a common understanding of the negotiating parties regarding the question ‘what is to be negotiated’, can be found in the ContractBot project and in the work of Kang and Lee.

For ContractBot, Reeves et al. [17] developed a declarative contract language that allows one to specify offers and eventually contracts with terms and conditions, constraints, dependencies, as rules and to represent them as XML documents. The expressive power of this contract language certainly exceeds the capabilities of the notation and XML Schema offer representation in SilkRoad: first, because rules have higher semantics than constraints, and second, because these contracts are executable logic programs. SilkRoad, however, does not only provide an offer language, but also a design framework with offer templates and means to model and represent the various states of an offer within a negotiation process. Furthermore, this design framework allows linking the question of ‘what is to be negotiated’ with the complementary organisation design question ‘how is the negotiation executed’ through the integrated design activity.

Kang and Lee developed a negotiation support system that relies on a shared ontology mechanism to structure negotiations. Based on the description in [12] buyers and sellers can edit the ontology – but the documentation does not disclose how this ontology is constructed and validated.

Regarding syntax formalisms, related work can be found in the area of XML-based trading protocols such as IOTP [4] or OBI [25]. The difference to SilkRoad is that these protocols are focussed on the settlement phase of electronic transactions (see Figure 1) by providing reference expressions for payment conditions etc. whereas the base-schema in SilkRoad defines generic syntactical structures for the agreement phase, abstracting from the actual message content.

7.3     Outlook

Regarding future work, an interesting opportunity arises once the design approach is actually in use and applied to a multitude of real agreement scenarios. Whereas the SDMM specifies ‘how’ to model electronic negotiation media, a reference model can specify ‘what’ to model. This reference model could evolve from a set of basic agreement scenarios, which, comparable to proved idioms in object-oriented software engineering [9], represent reusable best practices for electronic negotiations. A communication pattern might suggest, for example, that offers for the domain of internet services usually comprise certain mandatory attributes such as the definition of a support contract (e.g. 24x7) or the pricing scheme (fixed rate, traffic dependent etc.).

Another promising foundation for the definition of communi­cation patterns could be the INCOTERMS and ETERMS repositories (see for example [24]). These collections of standard commercial terms aim at avoiding the friction resulting from the diversity of semantic and legal interpretation of terms in international commerce. For usage in SilkRoad these terms could be represented in generic transaction domain ontologies, defining, for instance, standard concept terms for packaging, delivery points, transits etc.

If this abstraction is feasible, SilkRoad could provide not only a design and implementation framework, but also a reference model for electronic negotiations.

8.     ACKNOWLEDGEMENTS

The author thanks his colleagues at IBM’s Zurich Research Laboratory for supporting this work – Heiko Ludwig and Markus Stolze for valuable feedback on the ideas presented in this paper, and Achille Fokoue Nkoutche for XML Schema troubleshooting.

9.     REFERENCES

[1]     Beam, C., Segev, A., Bichler, M., and Krishnan, R. On Negotiations and Deal Making in Electronic Markets. Information Systems Frontier, Vol. 1, No. 3, 1999, 241-258.

[2]     Benjamins, R., Fensel, D., Decker, S., and Perez, A. Building Ontologies for the Internet: A Mid Term Report. International Journal of Human Computer Studies, Vol. 51, 1999, 687-712.

[3]     Bichler, M. A Roadmap to Auction-based Negotiation Protocols for Electronic Commerce. Proceedings of the 33rd Annual Hawaii Int’l. Conference on Systems Science HICCS, Hawaii, 2000.

[4]     Burdett, D. Internet Open Trading Protocol - IOTP Version 1.0. IETF TRADE Working Group, Internet Draft, 1999.