XLBC - An extensible language for business communication Hans Weigand Infolab, Tilburg University The Netherlands email:
[email protected]
Abstract This document contains the definition of XLBC and how it can be used in Electronic Commerce applications. XLBC is derived from FLBC and XML. FLBC stands for Formal Language for Business Communication and is based on speech-act theory and logic. FLBC messages can be used both in the negotiation and in the fulfilment stage of Electronic Commerce. XLBC message patterns are stored in the XLBC component library. This library may also contain higher units (transaction patterns). The predicates and other smaller units invoked in XLBC messages are taken from a multilingual thesaurus. XLBC is the basis of a Negotiation Manager currently developed in the MeMo project.
1. Introduction In spite of all the surrounding hype, it is becoming increasingly clear that Electronic Commerce is taking off on a global scale, not only in the consumer market (b2c) but also in business-to business (b2b) and business-toadministration(b2a). However, there are also many barriers that still need to be taken. One barrier is the standardization of the message formats. Although b2b has a longer tradition of electronic data interchange in the form of EDIFACT, it is generally recognized that EDI is too costly and not flexible enough to cope with the dynamics of the new economy [KM97, KL 97, MG98]. The proposed successor is called XML XML is a markup specification for creating self-descriptive data; in contrast to HTML, it separates style and content and is extensible in the sense that new tags can be used as long as they are defined in the DTD (document type definition). For Electronic Commerce, it is especially interesting that one format can be used both for electronic messages (to be processed by computers) and for human interfaces; an XML document itself is already readable for humans (what an EDI document is not), but especially when it is accompanied by a style document (XSL), it can be presented by means of a web browser in any desired layout. This feature not only allows to have one single interface to application systems (for humans and for systems), but also enables hybrid set-ups in which humans and systems are involved in different stages of the process and the same format can be used throughout. However, XML on itself will not do the job. The receiving party can recognize something as a valid XML document, and when it has the accompanying DTD, it can check whether it adheres to this DTD, but nothing is said yet about the meaning of the data elements. If every company were to develop its own DTDs, there would be no real interoperability. So although XML is technically superior to EDI X.12, it does not solve the huge problem that EDIFACT has worked on for years, namely, how to define the contents of the messages. What elements should be there, how are they represented and what do they mean? If XML is ever used in b2b, something equivalent to the EDIFACT standards must be in place. A consortium around VeoSystems (and later CommerceNet) has proposed CBL (Common Business Library) to solve this problem. The idea is to develop a standardized set of “building
fmec
2-5-00
1
blocks”, such as for representing an address, or a time unit, or product description, and to make this library publically available. The approach of CBL is to start “bottom-up”, that is, with those elements that are common to all industries, and then to proceed by incorporating more and more of the industry-specific services. Although we think this is a useful approach, it provides a partial solution for the standardization problem only. There is more in a message that address and date fields. For some time, a number of researchers have investigated the possibility of developing a general-purpose formal language for business communication (FLBC), notably Kimbrough, Moore, Covington and Lee. The impetus for this research has been a shared analysis to the effect that existing EDI standards leave much to be desired in flexibility, in expressivity, in clarity and much else. Kimbrough ([KM97]) mentions two assumptions of the FLBC approach: • Public-only lexicons: Using only publicly available lexicons (with a public grammar) – that is, without recourse to direct conversation – would-be business partners should be able to commence meaningful and effective exchange of messages. • FOL: First-order logic should be used insofar as possible for expressions in any FLBC The first assumption states that a properly designed FLBC should permit business messaging to begin and to proceed without the business partners having to come to a separate and specific agreement concerning the content, structure, and proper interpretation of the messages to be exchanged. This assumption is very close to the approach called Open-EDI. It does not require that every message be based entirely on public lexicons. Exchange of particular vocabularies should certainly be allowed, as should “linguistic bootstrapping” (agreement to define new expressions in terms of existing expressions). The second assumption calls for a logical-semantic foundation for the language. Whether this is exactly First-Order Logic or a higher modal logic such as Illocutionary Deontic Logic ([WD95]) remains to be seen. FLBC ([KM97,M99]) is based on speech act theory that makes a distinction between the illocutionary force of a message and the propositional content. By explicating the illocutionary force, FLBC makes clear that messages are not just pieces of data, but (intend to) have some social effects, such as creating an obligation. Moreover, the propositional content is represented in such a way that it contains indeed a proposition, that is, a statement that can be logically true or not (in the case of a assertive message), or an action to be taken (in the case of a directive message). This is in contrast to traditional EDIFACT messages where all the necessary data elements are present (otherwise it would not work of course), but not structured in the form of a proposition or action. As a result, the syntax definitions are arbitrary and unpredictable. In the FLBC approach proposed by Kimbrough and Moore, the basic structure of FLBC messages is defined once for all. Of course, different message types (also called patterns) can be defined, such as for ORDER, INVOICE, etc. These message patterns differ in the actions that they refer to and the arguments that these actions take. However, they can always be parsed, and interpreted to some extent; for the full interpretation, the receiver should know the meanings of the terms and predicates. In this document, we introduce the language XLBC (Extensible Language for Business Communication). XLBC combines the semantic orientation of FLBC with the extensible syntax of XML. XLBC is currently developed and implemented in the context of the ESPRIT project MeMo (Mediating and Monitoring Electronic Commerce. Although we started with FLBC, the result turned out to be rather different, not only because we use XML syntax. Therefore we have decided to use a different name (XLBC) in order to avoid confusion. The structure of this paper is as follows. In section 2, I will discuss the major requirements for a message standard in Electronic Commerce. In section 3, an overview of the component library is given, followed in section 4 by a description of XLBC. The general architecture of the MeMo Negotiation Manager is described in section 5. We conclude in section 6 by comparing XLBC with FLBC.
fmec
2-5-00
2
2. Requirements for an FLBC For the exchange and automatic processing of messages, a standardized language is needed. This standardization can be at different levels: at the superficial level of character set (data representation) and message structure to a deeper semantic level of vocabulary and integrity constraints. If the two communicating parties want true communication, they must agree not only on the form but also on the meaning of the messages. The agreeement can be implicit or explicit. Implicit means for example that the parties rely on the “common English meaning” of a lexical, whereas explicit means that the lexicals have a precise formal definition. If the message is to be processed automatically, the meaning must be formalized, although the formal definition may not be available at the machine level but somehow incorporated in the code. The standardization can be on different levels and also more or less complete. If the standardization is not complete, this means that in some cases, the communication fails. This is not necessarily a problem as long as it is possible to repair the situation by adding the requred standardization on the spot. In some EDI forms, an extension of the standard can be achieved by means of meta-messages. From an institutional point of view, standards are vehicles for facilitating coordination of economic activities (Heap, 1992). Instead of repeated coordination between actors, a standard solves a number of dilemmas for actors in a situation where communication is requried.. A standard therefore diminishes the need for short-run coordination. On the other hand, there is an increased need for concerted action when standards are created or changed. Normally, this concerted action is executed at the level of standardizaton committees. However, this now turns out to be not feasible anymore, or only to a limited extent. For example, a standardization committee or industrial consortium can decide on the syntax of XML, but this does not say anything yet about the semantics of the message. In the open and dynamic business environment of today, the partners have to take over (or back) part of the standardization process themselves. This can be two partners who want to set up a business relationship on the spot, or an industrial platform/ market owner who does this standardization for its members. The standardization process - defining a language plus semantics - is a process that currently is done mostly by standardization committees, but if the users have to do it themselves, the question arises how it must be supported.. We distinguish five aspects of this support: • • • • •
representation support: how to represent the syntax and semantics of messages accessibility support: how to store the definitions and make them available methodological support: how to arrive at a definition of redefinition process support: how to manage the standardization process implementation support: how to implement the language in the context of legacy systems
In section 4, we will introduce the XLBC language that defines the semantic structure of messages. The meaning of the lexicals has to come from elsewhere. For this purpose, we have developed a multilingual thesaurus and a component library that are described in section 3. In this way, the MEMO system is able to provide users with representation and accessibility support. The other support aspects are not worked out in this paper but we can make a few remarks. Methodological support has to do with the definition process itself. [Vis94] is an extensive study on how dictionary definitions can be made. [Hass00] discusses definition in the form of integrating heterogeneous information systems, that is, systems with different data models. A bottom-up approach is to start with the data models to be integrated and then trying to define superclasses of which the original classes are specializations. The study shows that this can lead to very complex integrated models. A top-down approach starts with an available domain model and specializes this to the situation at
fmec
2-5-00
3
hand. In the case of a message standard, a top-down approach could be followed if generic concepts, such as order, invoice but also product, buyer, seller, or transport medium are available. The top-down approach and the bottom-up approach can be combined in a so-called yoyo-approach. Process support is needed especially in the case that there are more than two stakeholders, for example, a business group or virtual community. In that case, the process should start by identifying all relevant stakeholders and ensure that everyone who wants to be involved has the possibility to do so. It is important that the process is legitimate so that the results are acceptable to all stakeholders. In (De Moor, 1999), a method is described in which virtual professional communities can arrive at acceptable specifications. Implementation support is especially important for the coupling of the standardized language with the legacy systems of the parties involved. Typically, the communication language is not identical to the language spoken by these legacy systems. A translation or mapping is needed to transform one representation into the other. This translation software is one of the major components of current EDI systems. In an open-edi setting, it must be relatively eaay for users to set up this mapping themselves by means of a “bilingual dictionary”.
3. Component library In the absence of a complete and comprehenisive set of document formats, as EDIFACT did provide, several attempts are made to set up repositories of components that can be taken out and combined by business partners themselves. In section 1, we already mentioned CBL, which has been adopted by CommerceNet and also by BizTalk of Microsoft. CBL defines a set of building-blocks. These building-blocks are then pulled together to make the actual documents describing the interactions between two organizations. [Lee98] suggests the use of a central repository in which formal trade procedures can be stored. Users can download these trade procedures - formally represented as PetriNets -, adapt them if necessary, and then adopt them immediately for execution. [G+99] proposes a central repository of standard contracts that can be used by negotiating partners in the process of contract building. XLBC is based on speech act theory Furthermore, the XLBC messages have been grouped into different aggregation levels of conversations, as displayed in figure 2.
Speech Act Transaction Workflow Loop Contract Scenario Figure 1 XLBC patterns At each level, various patterns can be defined. Speech acts typically go in pairs, for instance a request followed by a response. The request/accept transaction is an example of a pattern at transaction level. Transactions can make part of workflow loops, of which contracts or reciprocal interactions can be construed. It is possible to specify rules on for instance the sequence order in which elements of XLBC-patterns must occur.
fmec
2-5-00
4
Using the patterns it is possible to set up a library of standard components that can be used to build for instance new contracts. If we parameterise these predefined contracts, they can be reused in different settings and different levels of detail. Figure 2 shows one way of looking at contracts in the negotiation module. An original contract in textual form (top) can be represented with XLBC-patterns (bottom), which gives a formal representation of the contract (which automated systems can process). To enable this contract to be used in different settings, it is composed of parameterised pattern-components, which can be instantiated by filling out the parameters to form an actual contract (if the textual representation is available, the parameters can also be placed in the text to form an actual contract).
__________ __________ __________ p ro d u c t __________ __________ __________ | __________ __________
Parameterised contract __________ __________ __________ __________ __________ __________ __________ __________
Original Contract (in textual form)
FLBC-patterns (Formal Representation of contract)
Figure 2 The different contract representations in the contract negotiation module
We will store the XLBC-patterns in a repository, as well as their instantiations. To create a library, existing contracts and contract structures need to be divided in and translated to XLBC patterns, to act as a basis for negotiations in the MeMo system. In Figure 3 an (abstract) top level design of the contract data is shown, with generic patterns and instances with entered parameters. Instances may be values or links to the repository, as will be explained later. The different XLBC patterns share a lot of functionality, and may contain other patterns as can be seen in Figure 3. (createXMLRepresentation will be a crucial method. It will create a XML document of the structure, which can e.g. be processed to generate forms for the user interface).
Multilingual thesaurus The different elements (XLBC-patterns) that make up a contract refer to certain real world entities, such as the parties involved, the products/ goods that are exchanged etc. Usually these items will have different properties such as location and price. Both the properties themselves and the values of those properties have an expression, like: "company" "product" "colour" "Heineken" "cement-mixer" "red" These expressions are basically words that represent some entity, or concept. Although in human usage, such as textual contracts, it is often the words that are used to describe the concept, what is really meant is the concept itself. What we want to do is refer to concepts in the contract representations, instead of words. For this, we use a thesaurus.
fmec
2-5-00
5
XLBCSpeechAct
XLBCTransaction
XLBCPattern type : String containedIn : XLBCPattern[] contains : XLBCPattern[]
XLBCInstance pattern : XLBCPattern parameters : InstanceParameter[]
getElements() createXMLRepresentation(InstanceParameter[]) addElement(XLBCPattern) removeElement(XLBCPattern)
create(XLBCPattern, parameters) createXMLRepresentation() setParameter(index, InstanceParameter)
InstanceParameter XLBCWorkflowLoop getValue()
XLBCContract
RepositoryParameter linkToRepository : ConceptBasePointer getValue() setValue(ConceptBasePointer)
ValueParameter value : String type : int getValue()
XLBCScenario
Figure 3 Design of the XLBC component library The MeMo thesaurus is built up as a semantic network of concepts. The concepts are defined through their relationships with: • Words, which are basically the language description of concepts. Multiple words can describe one concept (author and writer both describe the concept of a person that writes things), and one word can be used to describe multiple concepts (a bank, a place where money is maintained or the sides of a river). We call the relation between a concept and a word a denotation (a representation of the concept). • Other concepts. The concept represented by author and writer may have concepts linked to them. For instance it may have as a hierarchical parent (hyperonym) a concept that represents a person. This says something about the concept of author/writer. • A concept may have different types of relations with other concepts. Besides the parent-relation the part-of relation between concepts is useful for defining concepts. After the general domain of contracts and contract negotiation, and the domain of the industry about which contracts are negotiated have both been modelled into the thesaurus, words and terms used in the contract structures can be replaced by the concepts that represent the words and terms. As can be seen in figure 4, elements in the different data structures that make up the contract shall link to concepts which have been defined in the semantic network of the thesaurus.
fmec
2-5-00
6
Contract Data Structures Scenario Contract Workflow Loop device
Transaction machine
Message
máquina
group
computer
computador
…
company
grupo
compañia
Figure 4 Linking the contract data structures with the thesaurus
4. XLBC basic syntax In this section we describe the basic syntax of XLBC messages using XML.
XLBC message
#REQUIRED #THESAURUS #REQUIRED #REQUIRED> #REQUIRED>
This definition defines a message as consisting of one or more speech acts and a context element. Note that we do not identify a message with one speech act: a message may combine several into one, resulting in one complex speech act. However, these speech acts must have the same sender and receiver. The TYPE attribute defines the message type taken from a controlled vocabulary. Examples are QUOTE and PURCHASE ORDER. Since the message types are taken from a controlled vocabulary, we associate a check function with this message attribute. The check function is called when the XML document is processed and checks (in the multilingual thesaurus) whether the value is indeed a valid message type. We use the keyword #THESAURUS for data fields that should be checked against a controlled vocabulary, such as available in the repository. This is not standard XML. In the current implementation, this is dealt with by means of the XSL sheet. In the future, it may be done perhaps by means of XML schema’s.
fmec
2-5-00
7
Speech act and propositional content
#THESAURUS>
#REQUIRED #THESAURUS #IMPLIED #IMPLIED>
#THESAURUS>
These definitions contain the basic structure of the speech acts. A speech act is divided into an illocution and a propositional content. The illocution is taken from a standard set of illocutions (directive, assertive etc - see 2.6). Usually, a speech act also contains a speaker and addressee. However, these are already implied by the sender/receiver of the message. The propositional content consists of a number of predications, where a simple predication takes the form of a predicate (usually a verb, such as “deliver”) followed by one or more arguments. An argument consists of a role identifying the argument (for example, “agent”) and a term. We also allow for subclauses, and therefore instead of a term, it is also possible to fill an argument with a predication. The ID of a predication is the identifier of the action occurrence, as it is used in event semantics. The predicate operator can be positive or negative (default: positive). The aspect operator can be used to indicate a phase of the event (“going to v”, “start v-ing”, “is v-ing”, “stop v-ing”, “has v-ed”). A complex predication allows for Boolean combinations of simple predications.
Roles The role names are taken from a controlled set. In linguistics (e.g. [D89], a set of about 10 to 20 role names are distinguished, but since the goal of XLBC is not to attain maximal linguistic adequacy, we allow in principle any role name to be added. The basic roles are: Agent Theme Source Destination Time Recipient Beneficiary Location Reference Speaker Addressee Message Usage: the Theme role can be left out. In other words, an argument without role is assumed to have the Theme role. A role is a semantic characterisation of the relationship between the event and the participants in the event. A standard example is an event of giving, where three roles can be distinguished: the agent, who does the giving; a theme, the thing that is given; and a recipient, the one to whom the thing is given. Note that these roles do not depend on the syntactic representation: whether a sentence is active or passive, the semantic roles remain the same. Besides the essential roles that can be associated with an event, there are also optional roles, such as Time, Location and Benificiary.
fmec
2-5-00
8
Note that we also allow for a predication to have restrictors, in addition to the role arguments. The syntax of the restrictors is given below. Using restrictors, it is possible to add any attribute to the predication, as long as it is semantically coherent. Predication restrictors are the semantic equivalent of adverbial expressions in natural language.
Time reference One of the arguments of a predication is the time reference. The time reference can be a date such as 12-12-98 or a time such as GMT 30-jun-1999:19:32. The time reference can have a duration, for example, 3 weeks. The time reference can be relative, for example, after delivery or after 3 weeks or 3 weeks after delivery. The structure of time references is not given here. Although we intend to keep the XLBC syntax simple, time references must be taken into account. This is because XLBC messages typically report a fact or require an action, and in both cases, the time (the event time or the specified time) is an essential element.
Illocutions The illocutions distinguished in XLBC so far are: Illocution
possible synonyms
Assert Request Commit Express Define Dispute Accept Reject Ask Cancel Propose Failure
Report, State, Declare, Inform, List Require, Directive Promise Specify Dissent Confirm Refuse Inquiry, Question Retract Not-understood
Illocutions are distinguished from message types. The list of message types is open-ended, but at least it must contain the following: Invoice Delivery-order Customs-clearing Quotation The examples make more clear, I hope, why we distinguish illocutions from message types. An invoice, or a quotation are familiar message types. However, they can be analysed as consisting of one or more speech acts. An invoice differs from a delivery-order in the action to be taken: the action to pay versus the action to deliver, but both have the illocution “request”. It is important that the illocutions and message types are well-defined logically. This will be done later in the development of the XLBC component library. It should be kept in mind that the list of illocutions is neither closed once for all – there may arise a need for yet another illocution to be distinguished – nor arbitrary – there is a wellthought-out logical structure behind it.
Predicates Most of the predicates are verbal and denote some action or activity. Examples of frequently-occurring verbal predicates are the following (cf. Kimbrough). Note that speech acts are actions themselves and so they can also occur as predicates.
fmec
2-5-00
9
Arrive Change Charge-back Check Count Create Deliver
agent (agent) agent agent agent agent agent
destination theme debt account theme theme theme theme
Predicates are stored in the multilingual thesaurus. Some are very general, such as the above, and some will be domain-specific. The thesaurus definition specifies the part-of-speech (in this case, “verb”), the argument structure, and semantic links (ISA, PART-OF). It also contains the lexical expression of the concept in one or more natural languages.
Context The context of the message contains all kinds of pragmatic features, such as the session of which the message is a part, a link to a previous message, but also the ontology used or the preferred language setting (note: usually, the multilingual thesaurus will contain translational equivalents of the terms used, and so the message can be read in other languages as well. However, this should be regarded as a translation, which may not have the same status as the original).
#CHECK #CHECK #THESAURUS>
Terms and references A term is an expression by means of which the speaker refers to some entity ([D89]). If the entity has a unique identifier, then the reference is simple, comparable to the reference by means of a personal name in natural language. However, this is not always the case. For example, when a customer orders 3 items of product X (identified by some EAN code), then the reference includes both a product type (identified by EAN code) and a quantity. The situation becomes more complex when the product is not sold in discrete items. In that case, some unit-of-measure is needed, for example, 200 kg. The entity type can be uniquely identified by an EAN code, but it can also be described by means of a general entity type and a list of restrictors. For example, the entity type can be “Toyota Carina Model 1432” and restrictors can specify the colour, the transmission system etc.
fmec
CDATA CDATA
#REQUIRED #REQUIRED>
2-5-00
10
)
#THESAURUS #THESAURUS #THESAURUS “=”>
A term is defined as an optional name element followed by zero or more restrictors. The minimal case is where both are absent; in that case, we only have the term attributes: tag, type and code. The most important one is the type: it specifies the concept type of the object referred to, for example, “money” or “brick”. The concept types can be stored again in the multilingual thesaurus (either the general domain or a specific domain). In such a case, the domain from which the type is taken is indicated by means of the “CODE” attribute. It is also possible that the concept type is defined by means of some formal standard, such as the EAN product code. The tag attribute is to identify the term within the context of the XML-document and can be used elsewhere in the document (co-reference). The quantity and measure-unit attributes take care of the quantitative aspect of the term. Note that the objects referred to can be both discrete (and countable), or non-discrete (mass-terms). If they are conceived as being non-discrete, a measure unit must be given. In most cases, the reference will be to some specific item (e.g. a certain company, or a certain delivered product). In those cases, we need the NAME element that gives a unique identifier based on some coding (the set of identifiers). Restrictors give further qualifications of the term reference. We have opted for a representation in terms of attribute/value pairs. Attribute names are colour, weight, seize, price etc. The values of the attribute are taken from some domain, such as the domain of colours (to be more precise, the ISO definition of colour names, or some other formalisation), the domain of money etc. In some cases, the value is numeric, but note that this implies the use of a measure unit again (3.5 meter, 500 pound etc). We also give (limited) opportunity to provide not just a value, but a comparison with some other value (“higher than 3.5 meter”).
Some examples of terms 1. “5000 tiles; the set is identified as ID73937” 2. “600 meter of (some product with EAN code 1000178191”)” 3. RED 7 “bricks of colour red and length 7 inch”
Example XLBC message A delivery order might look as follows in XLBC::
fmec
2-5-00
11
The SIMPL-EDI representation of the same message looks moreless as follows: 128576 19970812 5012345678900 900 19970812 The XLBC message starts with a message header including sender, receiver and message date. As can be seen, the message date is also in the SIMPL-EDI message, although less explicitly, in the DTM1 field. The sender and receiver are represented by their names in simple terms; however, we foresee that the MEMO system will contain a user directory in which all users of the system have a unique identity. A user is a real person, role of software agent; it is not a company, although each user is associated with one company. The illocution of the speech act is a REQUEST since an order is a request to deliver. Note that neither the illocution, nor the action requested - the delivery - is explicit in the SIMPL-EDI message. The buyer and seller are identified by means of an EAN code. In the XLBC message, their role is made explicit (agent/recipient), as well as their type (company). Although there are of course many ways to identify a party, we have chosen to use the same EAN coding in the XLBC message. The LIN segment in SIMPL-EDI contains the order lines. XLBC does not talk about order lines, but about objects that are the “theme” of delivery. The objects are identified by means of an EAN code, as in SIMPL-EDI. Note that this is an identifier of a product type. What is ordered is 900 items of that product type.
fmec
2-5-00
12
Since the meaning of the RFF element in SIMPL-EDI message is not completely clear, we have not represented this information in the XLBC message. Note, however, that we have given a session number to the whole message. This session number can be used in later messages, for example, the INVOICE. The example shows that the XLBC message is more explicit, and therefore also longer than the SIMPL-EDI message.
5. General Architecture This section describes the general architecture of the MeMo Negotiation Manager.
user interface
Partner Search
Contract Negotiation
Contract Fulfillment
Repository Figure 5 Place of Contract Negotiation in the entire MeMo system Figure 5 shows the place of the contract negotiation module within the MeMo system. (Most of) the MeMo data is stored in the Meta-data repository. The negotiation module uses the results of the partner search module as a starting point for the contract negotiation. The negotiated contract is communicated to the contract fulfilment module, for executing the actual contract. Like the other modules, the negotiation module has an interface with the end user. This user interface is one of the elements of the top-level architecture of the system, as shown below in figure 6.
User Interface
EMail System
Contract Management
Data Storage
Contract Database Thesaurus
Figure 6 Top-level architecture of the contract negotiation module The contract negotiation has an email interface. Underlying the user interface is a system for generating and exchanging the email messages, which represent the contract negotiation messages. This module has its own data
fmec
2-5-00
13
storage for, for instance, the mailboxes of the different users of the system. This data is not directly connected to the contracts themselves. The contract 'templates', (partially) filled-out contracts and contract meta-information is stored in the contract database, with a contract management tool on top of it to give access to the contracts to both the email system and the user interface (e.g. for displaying the current state of a contract), keep the contracts consistent, and process the exchanged negotiation messages on the creation of contracts. The contracts are partially specified using thesaurus concepts, to allow the contracts to be embedded in multiple languages. The contract negotiation is presented to the end user as an email system.. If one looks at the real-life contract negotiation process it looks like this (simplified presentation): You start with an empty piece of paper and two or more partners gradually fill this piece of paper with paragraphs of text, which at the end specifes the contract. To agree on what paragraphs are placed in the contract the partners communicate with each other, e.g. through telephone calls or the exchange of messages Of course, contracts are seldom started from scratch; the included paragraphs or even entire contracts are often based on templates, and the terms of the contract also are often extended by other contracts and regulations. Therefore instead of starting with an empty piece of paper, one can start with a template contract as well. The thrust of this scenario is that contract negotiation is a form of goal-oriented communication, in which the goal is to define some document called a contract. Since the most common means of communication over networks is through email, we have decided to present the process of contract negotiation in the contract negotiation module as a process of exchanging emails. There are a few main differences with normal email conversations, which amongst other things indicates why we need to create our own email system instead of existing ones: The message exchange for contract negotiation is more structured than the 'average' email exchange. In fact, we want it to be more structured to ease the contract negotiation process for end users. Most current email systems support basically three fields (the address-lists are not part of the message but of the envelope of the message); one to indicate the subject and one to indicate the body of the message, and an optional field for attachments. When more is known about the message being sent it is possible to provide more fields (in the 'body' of the message) to enter the information, in order to allow the information to be structured more1. You can see this process as a conversion of forms you fill out to email messages. The structure of the messages and the message sequences is based on XLBC.
1
We do acknowledge the fact that there is still a need for a free-text message body like provided with regular email, for entering 'random' comments since we cannot anticipate everything an end-user wants to communicate .
fmec
2-5-00
14
Subject Contract for rooftiles Attachment
Contract ref. Standard Purchase Order
header
contract~01.doc
Body Hi Paul,
Product
thank you for your quote, I really like the ‘Housemartin’ rooftiles you are proposing. It turns out I need 2500 instead of the 2800 I mentioned earlier. Could this mean I could get them before Friday? I hope this doesn’t mean the price of EURO 12 we agreed on has to be changed?
‘Housemartin’ rooftiles
2500
Amount Price
12 EURO
Delivery Date Tuesday 12/14/99 Comments
body
Thanks, --Martin Gare
Submit
Figure 7 Comparison (simplified) between regular email (on the left), and a more structured view of the same message (changed values are italicised), as they would be presented to an end-user
The messages exchanged always relate to a contract document. This document changes according to the messages exchanged and its current state should always be available to partners involved in the communication. This is different from email attachments, since we do not want different copies to reside in different places. Furthermore, it is convenient that the negotiating parties can refer to (parts of) the contract document in their messages. As far as the contract specifies how the fulfilment of the contract is to be done, it can be specified formally using XLBC again. So note that we use XLBC both for the negotiation messages and for the fulfilment messages.
In essence, the contract document contains the current state of the contract, while the sum of the messages exchanged represents the negotiation process up until now.
A
B
[A]
[B]
[O] Figure 8 Abstract visualisation of the channels between users ([A] and [B]) for the communication and their shared workspace ([O]) which contains the shared information the communication refers to
fmec
2-5-00
15
6. Conclusion XLBC is a language in the family of FLBC aimed at supporting the formal communication between businesses. Like FLBC, XLBC makes a distinction between the propositional content of a message and its illocution or illocutions. However, there are also some differences: • for the propositional content, we use Functional Grammar as a reference framework. It means that the content is centerered around predications denoting some action; • a distinction is made between messages and documents. The expressivity of messages is limited and aimed at supporting coordination. A more complete Knowledge Representation Language is needed for the document; it could also consist of different languages, for example, one for contracts. • XLBC also supports higher-level constructs such as transactions and contracts. They describe the communication at the social level of obligations and commitments that are raised during the communication process. • whereas FLBC has focused on BDI (Belief-Desire-Intention) semantics of speech acts, our focus is on social commitments. This difference can also be described as complimentarity. • as has been described in this paper, XLBC is heavily dependent on the existence of a central repository consisting of a component library and thesaurus. The XLBC system is currentl y implemented as part of the MeMo project. The emphasis in this project is on the support of the negotiation phase.
7. Acknowledgements The research in this paper was partly supported by the ESPRIT project MeMo (Mediating and Monitoring Electronic Commerce), project code 26.895, a consortium consisting of ABN-AMRO bank (NL), Origin (E), Tilburg University (NL), RWTH Aachen(D), EKD (E), Sarenet (E) and Checkmark (NL). For more information, see http://www.abnamro.com/memo.
8. References [CBL] CBL documentation: http://www.veosystems.com [D89] Dik, S.C. 1989. “The theory of Functional Grammar”. Mouton-De Gruyter [F97] Nicholas D. Finke, “TEI Extensions for Legal Text”, Text Encoding Initiative Tenth Anniversary User Conference, 1997, http://www.stg.brown.edu/webs/tei10/abstracts.html, accessed 27-09-1999. [G+99] Gisler., M et al. “Requirements on secure contracts”. Technical report MCM Institute 1999-01, Univ St. Gallen, 1999. [Has00] W. Hasselbring. The role of standards for interoperating information systems. In K.Jakobs, ed “Information Technology Standards on Standardization: A Global Perspective”, pp116-130. Idea Group Publishing, 2000. [ICC83] “Commercial Agency – Guide for the drawing up of contracts”, ICC Publication N410E, ICC Publishing, Paris, 1983 [ICC99] “Guide to the Incoterms 2000”, ICC Publication N620E, ICC Publishing, Paris, 1999
fmec
2-5-00
16
[ICC97] “The ICC Model International Sale Contract – Manufactured goods intended for resale”, ICC Publication N566E, ICC Publishing, Paris, 1998 [K97] van Kralingen, “A Conceptual Frame-based Ontology for the Law”, Proceedings of the First International Workshop on Legal Ontologies, Melbourne, Australia, 1997 [KM97] Kimbrough, S., S Moore, 1997. “On automated message processing in electronic commerce and work support systems” ACM Transactions on Information Systems. [Lee98] RE. Lee “Toward open electronic contracting”. J Electronic Markets 8(3), 1998. [M99] Moore, S. 1999. “A foundation for flexible automated electronic communication”. Internal report, Univ of Michigan Business School, http://www-personal.umich.edu/~samoore/research/flbc [MTT98], Mitrakas, A., Tan, Y.H. and Thoen, W., “A formal analysis of Incoterms for electronic commerce”, Nationaal Programma Informatietechnologie en Recht (ITeR), Vol. 12, Kluwer, 1998 [SEDI] XML Document Type Definitions for SIMPL-EDI http://www.geocities.com/Wallstreet/Floor/5815 [TT98] Tan, Y.H. and Thoen, W., “A Logical Model of transfer of obligation in trade contracts”, Accounting, Management and Information Technology (AMIT), Vol. 8, No. 1, pp. 23-38, 1998 [TT99] Tan, Y.H. and Thoen, W., “A Logical Model of Directed Obligations and Permissions to Support Electronic Contracting”, International Journal of Electronic Commerce (IJEC), Vol. 3, No. 2, pp. 87-104, 1999 [Vis94] Viskil, E. “Definieren: een bijdrage tot de theorievorming over het opstellen van definities. Ph. D. Thesis, Vrije Universiteit Amsterdam, 1989. [W3C99] World Wide Web Consortium, “XML XPointer Requirements, Version 1.0”, W3C Note 24-Feb-1999, http://www.w3.org/TR/NOTE-xptr-req, accessed 28-09-1999 [WD95] Weigand, H., E. Verharen, F. Dignum, 1995. “Integrated semantics for information and communication systems”. Proc. IFIP WG 2.6 Conf on Data Application Semantics. [WH98] Weigand, H., WJ vd Heuvel, 1998. “Meta-patterns for Electronic Commerce”. Proc. HICSS’98 (also published in IJEC 3,2, 1999)
fmec
2-5-00
17
