[This local archive copy is from the official and canonical URL, http://www.haas.berkeley.edu/~citm/cec/papers/moore/Moore.html; please refer to the canonical source document if possible.]

Position Statement

Prepared for the "International Workshop on Component-based Electronic Commerce"
at the Haas School of Business on July 25, 1998
by Scott A. Moore (samoore@umich.edu)
of the Computer & Information Systems department, University of Michigan Business School

I believe electronic commerce, if it is to be widely accepted by and applied in many industries, must have available an expressive and easily extendable language for automated communication. The interpretation mechanism for each message type should have a modular architecture and be made of reusable components. This language and its associated message interpretation system (what I call the MMS) should be easily integrated with open standards (e.g., XML and X.12) so that programmers and analysts can more easily add it to agents, web pages, EDI programs, and databases. This language should be usable in the whole range of activities that involves the exchange of messages, from those usually prescribed to agents of all types (whether or not they are mobile, adaptive, flexible, or have a character) to those within the narrow confines of EDI. Finally, this language and its associated MMS must not assume a friendly, fully trusting, cooperative relationship among conversants.

Certainly the deployed languages of today do not meet these requirements --- yet electronic commerce is being conducted. However, I believe there are many benefits to applying the above approach to e-commerce related communications. Some benefits of this approach are as follows:

Faster & easier deployment
A language that allows much of the message interpretation mechanism to be reusable should speed deployment. Additionally, since the message itself is in XML, the tools for parsing and displaying these messages should already exist.
Automation of more business processes
Since this system would allow and ease the automation of so many types of messages, a broader range of business processes should be able to be automated. By definition this expands the scope of e-commerce and opens up more industries and companies to its benefits.
Improved information retrieval
Using one message format for all messages would make it easier to find old messages since the information retrieval mechanism should be functional over a higher percentage of a business's automated communication.
Conversation management
Dialogue (or conversation) management should be more feasible because a higher percentage of the messages can go through this system. This helps dialogue management both because it's not possible to manage messages that the system doesn't know anything about and because it would be easier to manage a conversation with all the messages being handled by the same system.
Improved inter-operability
Having one communication language would allow the multitude of communicative agents which are being deployed to talk with each other (and with EDI systems, people, etc.) instead of only being able to talk with other agents deployed by the same research group.

I have developed a formal language for business communication (FLBC) based on speech act theory that has formally defined message types, has a broad range of message types, defines message types in terms of the speaker's intentions rather than the actual effects, and clearly distinguishes between the message's type and content. These attributes combine to produce a language that meets all the above requirements.

Expressive
The language is fully recursive, allowing any message to be embedded in any other message; this, combined with its broad range of message types, essentially allows it to express any message that would be needed to conduct electronic commerce. By electronic commerce I certainly include buying and selling, but also negotiating, searching, reporting, predicting, confirming, denying, and so on.
Modular interpretation mechanism
The MMS divides message interpretation into two pieces --- that which is specific to the force of the message (e.g., a request, an assert) and that which is specific to the content of the message. The benefit is that a significant portion of the effects of a message only depend on the force of the message (of which there are few). These "default" responses for each message type provide useful, though certainly limited, response mechanisms for all messages. Thus, many messages can be interpreted and responded to without writing any code specific to that particular combination of force and content. This should encourage the use of an iterative design and deployment strategy with communication systems (whereby responses to messages can and do become more complex over time) which have primarily required waterfall methodologies because of the complexity of the message structures.
Integrated with open standards
The messages are constructed in XML according to a DTD located on the Web.
Usable in a range of applications
I have shown that both all UN/EDIFACT messages and all Apple Events (the standard inter-application protocol for the MacOS) can be translated into the FLBC. I am also currently translating KQML's standard performatives into the FLBC.
Cooperative behavior is not assumed
Since a message is defined in terms of the speaker's intentions (which are clear since they are stated formally), the message recipient can determine what the effects of the message will be and how he can respond to it. This gives the recipient more control over the communication process and minimizes the damage that a speaker, either familiar or not, can inflict on the message's recipient.

Some people would argue that KQML is a language that meets all or even simply enough of the above requirements. I do not believe that it does. Its expressiveness is somewhat limited. For example, the language only allows KQML messages to be embedded in a limited number of KQML performatives.

Further, KQML is not extendable as easily as it appears. This has to do with its method of defining performatives as some combination of a force (i.e., the message type) and its content. The result of this is that a new message requires that a user define a new performative. For example, the performative delete-all is a request to delete terms from a database with a certain form. The performative evaluate is a request to evaluate a term and a request to inform the requestor of the result of the evaluation. When implementing the the code that will be used to respond to either of the two performatives (i.e., delete-all and evaluate), a KQML-based system does not take advantage of the overlap between the definitions of these two performatives --- i.e., that both performatives are requests. When defining a new message type (i.e., performative in KQML or force in FLBC), implementors should be able to use the request module and simply plug in the appropriate content-specific module (if it is even needed).

Certainly, KQML is used in many applications. However, it has a fairly limited range of messages in its standard set of performatives. In fact, most KQML messages can be classified as either informs or requests. KQML's designers state that this set can be extended, but these extensions are defined on an ad hoc basis --- applications defined by one programmer would not be able to understand messages sent by applications developed by another programmer unless they had previously coordinated their efforts. Because the FLBC has such a broad range of message types (that should not ever need to be extended) and because the MMS has a modular architecture (that should localize changes to the content vocabulary that is much more easily updated and communicated among conversants), any two FLBC-based systems should be able to communicate even if they were developed by programmers who didn't have knowledge of others' efforts.

I foresee many applications for the FLBC and the associated MMS. As mentioned above, EDI systems might use the language as its primary language or, more likely, the FLBC could be used as the "extension" language to define new, non-standard messages that companies need but that haven't (or won't) go through the standards process. The FLBC could also be used by agents that need to communicate with either people or other agents. I have demonstrated how the language can be automatically converted into human-understandable forms or even an English-like sentence. As for what the language could be used to do: just about anything that could be done with one or more straight-forward English sentences or forms. This includes, but is not limited to, standard business documents like purchase orders, negotiations, advertisements, as well as common tasks such as database access, monitoring and reporting, and coordinating activities.

The message interpretation mechanism of an application is rarely thought of as a "component" of a system. It is more generally considered an integral part that can only with great difficulty be extended or modified. This can and should change. Communications needs change and the underlying communication language should be able to adapt as necessary. The FLBC is a tool that can make this possible.