ABSTRACT

Representation of negotiations in electronic markets and their support are important issues in today’s e-commerce research. Whereas most activities are focused on automation aspects, only few efforts address the design of electronic negotiations – e.g. the sequence of actions, or obligations and responsibilities of the negotiating parties. However, an explicit negotiation design can also address what is commonly referred to as the ontology problem of electronic negotiations: how can one ensure that the negotiating parties have the same understanding regarding the issues that are subject to the negotiation?

The solution this paper proposes is to perform a communication design for electronic negotiations that explicitly specifies the common syntax and semantics of the negotiating parties, the logical space of the electronic negotiation. Furthermore, XML Schema is suggested as the mechanism for the runtime representation of the logical space and the validation of actual negotiations from a syntactical and semantical perspective. On the basis of this approach, organisations creating an electronic market or sellers who intend to offer their buyers the ability to bargain can design and generate support mechanisms for electronic negotiations in a flexible and efficient way.

The communication design action- and meta-model presented are part of SilkRoad, a design and application framework for electronic negotiations.

Categories and Subject Descriptors

D.2.10 [Software Engineering]: Design

D.2.2 [Software Engineering]: Design Tools and Techniques – computer-aided software engineering, state diagrams.

H.2.11 [Information Systems]: Logical Design

General Terms

Design

Keywords

Application Framework, Electronic Negotiation, Ontology, XML

1. INTRODUCTION

Let us assume that a new electronic market for multiple sellers and buyers is being created. Due to the nature of the goods traded, price-focused coordination mechanisms such as auctions are not applicable because an agreement between a seller and a buyer has to consider multiple attributes of the good or item (e.g. price and quality) as well as the terms and conditions of the transaction (e.g. delivery time and return policy).

A critical factor for the efficiency of the future negotiation processes on this market and the success of the potential settlements is an a-priori agreement among the negotiating parties about how the issues of a negotiation (item attributes, transaction terms and conditions) are represented as abstract objects in the negotiation and what this representation means to each of the negotiating parties. If, for instance, party X offers a delivery date of ‘12/10/2000’ for a workstation to party Y, one potential conflict arises if this syntax is misinterpreted by Y as ‘October 12’ whereas X intended to offer ‘December 10’. A semantical problem could occur if the meaning of this date to X is the point in time where the product will leave the premises of X, whereas Y assumes this is the date the workstation will arrive on the premises of Y. This problem is referred to as the ontology problem of electronic negotiations [1].

Like any other information system, the creation of an electronic market can be structured along the system development phases of analysis, design and implementation. For an electronic market intended to support electronic negotiations, the design activity has to comprise the agreement scenario, which defines how potential trading partners reach an agreement if conflicts arise regarding the transaction or item configuration. Choice and further specification of this scenario will vary depending on the market requirements identified in the analysis phase. In the implementation phase, the agreement scenario is mapped to a technical architecture and application system.

However, if the agreement scenario is supposed to include some kind of negotiations between buyers and sellers, there are no common means by which the market creator and its stakeholders can reason about the potential form of these negotiations. In 1991, Holsapple et al. [10] have identified this need for general models of negotiations, which could be used to characterise the nature and process of the negotiation as well as to formalise its aspects, and which have the flexibility to describe a wide range of possible structures and interactions. But modelling aspects have been largely neglected in related research, with the undesirable consequence that it is difficult to discuss agreement scenarios on a conceptual level, and that design efforts cannot be reused and refined in the implementation phase in a formal way.

This lack of support for the design of agreement scenarios is the underlying motivation for SilkRoad – a design and implementation framework for electronic negotiations. The SilkRoad framework can be used, for instance, by organisations creating electronic markets, for the design and implementation of electronic negotiation support. Two deliverables of this project, the design action- and meta-model for the specification of the common object syntax and semantics in an electronic negotiation, are presented in this paper.

After referring to theoretical foundations of this work in the next section, the approach chosen for SilkRoad will be illustrated in more detail in Section 3. Details of the communication design approach are presented in Section 4. Following the communication design in SilkRoad, the integrated design of agreement scenarios is outlined in Section 5. The consecutive generation of XML schemata for the runtime representation of logical spaces is then demonstrated in Section 6. Lastly, Section 7 discusses conclusions, as well as related and future work.

2. negotiation media

In SilkRoad, the notion of media and the media reference model [19] are used to conceptualise electronic negotiations. Media are platforms where the exchange of tangible or intangible items by means of transactions is coordinated through agent interaction. These platforms can be described in terms of three main components:

· Channels:
Agents access a medium via channels that can transport the items to be exchanged.

· Logical space:

The syntax and semantics defined for representing the items, which the agents exchange.

· Organisation:
Roles describing the types of agents and protocols specifying their interactions.

An electronic medium in particular is a medium with electronic (digital) channels that transport data. The agents, however, might still be humans or organisational units and do not necessarily have to be software agents.

The media reference model identifies several phases of agent interaction (see Figure 1). Offers, expressions of will concerning the configuration of a transaction or its associated item(s) communicated to other agents, are one possible means of representing this interaction. Depending on the actual phase transition, offers may assume different states of formality:

· Advertisement
In the knowledge phase, agents gather information concerning the items offered or the profiles of other agents. An offer in the form of an advertisement can be issued in the knowledge phase. This advertisement might relate to a general class of items (e.g. the types of products or services offered by this agent) and is typically not related to another offer from a different agent, but targeted at a group of potential trading partners. An advertised offer is also persistent in the sense that it is valid for a certain period of time.

· Bid
In the intention phase, demand and supply are specified. An offer in the form of a bid can be a response to an advertisement in the intention phase of an electronic transaction, and is therefore specific to the transaction and item configuration proposed in the advertisement. Bids might also result from an advertisement, which spawns bids specific to received requests. This is, for instance, often the case if the item is configurable or has certain options. In such an example, an interested agent might bid to buy an advertised item with certain options and the advertisement ‘generates’ a complementary bid with a total price for this choice of item options. The validity of a bid is limited by the validity of the associated advertisement or complementary bid, but is usually even constrained further (e.g. ‘please respond to this bid by…’).

· Contract
As a result of a successful agreement phase, a final offer in the form of a contract can seal mutually accepted bids with legally binding signatures of the agents. A contract marks the transition to the settlement phase where the agreed-upon transaction is executed and is therefore persistent beyond the duration of the agreement phase.

A negotiation takes place in the agreement phase when, based on the offers (bids) made in the intention phase, an agreement (a contract) cannot be reached, or the initial agreement has a potential for optimisation and the agents are willing to discuss their offer positions. From the perspective of one agent, negotiating is characterised by the modification of its own bid or the efforts to change another agent’s bid.

An electronic medium supporting negotiation processes in the agreement phase, is denoted an Electronic NegotIation MEdiuM (Enimem). An Enimem provides electronic negotiation support, meaning the assistance or automation of certain tasks (e.g. decisions) within the negotiation process. If a negotiation process is conducted using an Enimem and no other media (e.g. letters), an electronic negotiation takes place. Depending on the level of support provided by the medium, electronic negotiations can be completely, or partly automated – the latter case requires human intervention in the negotiation process.

A magnitude of technologies can be used to build electronic negotiation media. These technologies are core elements of development efforts that have historically come to be known as negotiation support systems (NSS, [11]). The notion of electronic negotiation media comprises NSS as services on the transaction layer of the media reference model (see Figure 1). In addition to this service level, the goal of an Enimem is to support negotiations in the agreement phase of electronic transactions also from a community, process, and infrastructure point of view.

The Enimem definition used in this proposal does not refer to negotiation media, which support agreements in electronic markets, but do not specifically provide assistance for negotiation processes. A medium might, for instance, support agents in legally accepting fixed offers with only one mechanism – signature validation. Hence, contractual obligation can be created and the agreement phase can be completed without any actual negotiation taking place. An Enimem might offer the same signature validation, but also has to include support for some form of negotiation mechanisms, e.g. auctions.

Finally, negotiation support is not restricted to electronic media. If a human mediator joins the negotiation process, for instance, to suggest an agreement in a dispute, this constitutes as well a negotiation support activity, but not a form of electronic negotiation support.

Figure 1: Agreement phase in the media reference model [19].

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 preconditions 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.

Notation element	Level	Option	Modifiable
Agents	Required	One	+
Agents	Optional	One	+
Signatures	Required	None	+
Signatures	Optional	Single	-
Timestamps	Required	Start	No
Timestamps	Optional	Both	-
Domains	Required	Attributes	+
Domains	Optional	Dynamic	-
Constraints	Required	Basic	No
Constraints	Optional	Negotiable	-
Counters	Required	None	No
Counters	Optional	None	No
Criteria	Required	None	+
Criteria	Optional	Functions	-

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.

. . .

</sequence>

</complexType>