automated generation of electronic procedures: -...

"Automated Generation of Electronic Procedures: Procedure Constraint Grammars" by R.Lee (May 8, 2023) p. 1for DSS Special Issue on Formal Models of Electronic Commerce

Automated Generation of Electronic Procedures:

Procedure Constraint GrammarsRonald M. Lee

email: [email protected], Erasmus University Rotterdam

PO 1738, 3000 DR Rotterdam, The Netherlandswww.euridis.fbk.eur.nl

Abstract

Electronic trade procedures or 'scenarios' are ready-made, generic and re-usable transaction models for trade communities such as seaports, banking, logistics, etc. They are made available to parties for downloading from repositories provided by international, regional, or industry organizations. However, current workflow-like representations of trade scenarios do not provide for situation-specific customization of the transaction model.

Instead of designing specific trade procedures for each possible variation of a transaction, we develop a generative grammar formalism that defines entire families of related trade procedures. Since trade procedures are influenced by various situation-specific factors from multiple sources, we have been led to modify the usual grammar formalism to take into account a variety of constraints. The formalism is therefore called a procedure constraint grammar (PCG). The resulting functionality allows for a far greater level of flexibility for customized electronic trade procedures than current approaches provide. Numerous examples are provided.

Keywords: electronic commerce; electronic trade procedures; electronic trade scenarios; transaction modeling; transaction contracting; Open-EDI; EDI; XML; Petri-nets


1. Motivation: Global Commerce

Business-to-business electronic commerce has so far been realized mainly through the use of Electronic Document Interchange (EDI) implemented in closed, typically in bi-lateral linkages that are relationship specific. As the demand for electronic trading relationships among businesses becomes greater, there is a need to make these electronic linkages more generic and re-usable. Furthermore, the scope of the modeling needs to encompass not only simple two-party links, but the entire trade or supply chain transaction model, which may include as many as a dozen different parties. These aspects are captured in the notion of open electronic commerce. The most complex challenges are in the area of international trade. This is also the area where incredible economic benefits might be found. The international trade industry is fragmented, labor intensive and paper-based, and its processes are costly and time consuming. The United Nations estimates that processing the paperwork of international trade costs US$420 billion a year, or about 6 percent of the US$7 trillion in goods and services that cross borders each year [43, p. 10] This is one of the more conservative estimates. Others estimate the transaction costs to be more than 10 percent. Therefore, assuming just 30 percent savings, the potential savings in transaction costs in the area of international trade is at least US$100 billion per year [6]. This does not include the potential entry of many new small to medium-sized businesses into international trading. Figure 1 illustrates the complexity of such international trade transactions. This is a typical trade procedure, based on the Port of Rotterdam [51]. There are 19 roles (boxes), and more than 40 documents (lines).

[INSERT FIGURE HERE]

Figure 1: Typical International Trade Procedure

Current developments in wide area networking (e.g. Extranets) and related component technologies make the notion of global repositories for generic, re-usable transaction models increasingly more feasible. Needed, however, is effective design representations and methodologies for representing complex trade and supply chain transactions. The focus here is on open electronic commerce: doing business among parties having no prior trading relationship. What we hope to achieve is computerized support for commerce that is trustworthy in the sense that trading partners who do not know each other, and may even come from different countries and cultures, may conduct business with the assurance that their interests will be protected in the event that "things go wrong", whether by accident, negligence, or intentional fraud.


In order to conduct electronic commerce, parties have to know about each other's "way of doing business" before they can start exchanging data electronically. Extra knowledge about the preferred way of doing business of one trading partner has to be conveyed to the other; in other words, the parties have to agree upon the trade procedure they are going to follow [50; 19]. A trade procedure is the mutually agreed upon sequence of actions, documents and rules that govern the activities of all parties involved in a set of related business transactions. Thus, a trade procedure controls all interactions between the roles involved. A trade procedure stipulates which actions should be undertaken by which parties, the order in which these actions should be performed as well as the deadlines and other timing constraints on the performance of these actions. Actions of parties include the sending and/or receiving of goods, documents or funds.

Trade procedures have been developed and have evolved for centuries, especially in support of international trade. For instance, the documentary credit procedure (illustrated later), was developed to manage the timing of payments for goods transported by sea as early as the fifteenth century. Our interest here is the electronic version of trade procedures, called trade scenarios. The need and usefulness of trade scenarios is easy to demonstrate. Consider only a simple post-payment contract for goods. The buyer assumes that an invoice will be sent after delivery to trigger the payment obligation. The seller, on the other hand, abides by the practice that payment becomes due from the time of delivery, and does not send an invoice. Thus, the goods arrive, and the buyer does not pay, waiting for an invoice. Meanwhile the seller becomes irked, and initiates collection proceedings. This is an example of the so-called "battle of the forms". Each party utilizes standardized documents such as a purchase order, delivery agreement, etc. which contain (typically on the backside, in small print) the terms and conditions that are their style of doing business. Unfortunately, the small print is often ignored by the receiving party.

For trade in a well-established industry area, standardized practice becomes generally accepted, and there usually is not a problem. In some cases, guidelines by international bodies such as the International Chamber of Commerce or the UNCID have been established (for instance the Uniform Customs and Practices for Documentary Credits, issued by the ICC [16]). However, in more open trading situations, that cross national, cultural or sectorial boundaries, such conflicts are much more likely to arise. Many existing EDI applications of course embed the types of document exchange sequencing of a trade scenario. However, these sequences are normally 'hard-coded' into the application programs, as specified in the terms of the trading partner agreement, a legal, textual document. A key aspect of the architecture presented here is that trade scenarios are 'soft-coded', in a declarative, rule-based form. This has the virtue that they may be downloaded from e.g. a central library to meet the needs of a particular contractual situation (see Figure 2). Soft-coding enables customization. Based on a


set of rules or generic templates, a specific inter-organizational procedure is constructed. Despite the standardization efforts of international bodies such as UNCID, WTO, WCO, UNCITRAL, UNCTAD, UN/CEFACT, IMO and ICAO most processes cannot be supported by standard hard-coded procedures. Even for well-defined processes such as the export of goods there is a need for customization based on differences between countries, changes of law, and safety requirements.

[INSERT FIGURE HERE]Figure 2: A repository serves as a central library containing (fragments) of trade procedures

Here we have emphasized applications for business and trade. However, it is easy to see that the problems mentioned are not limited to business-to-business commerce: governments are facing similar challenges. The integration of authorities at the local, regional, national, European, and global levels leads to cross-organizational processes that need to be supported systematically in a harmonized way. Consider labor mobility in Europe: serious problems arise because of the multiple national administrations for health insurance and pensions. The goal of harmonization is to identify and remove conflicts and redundancies among the procedures, and to reduce the transaction costs for the clients that must navigate among them. To harmonize the various procedures, the differences need to be identified and, if possible, a unifying or cooperating procedure needs to be established. In some cases, a harmonization may be synthesized automatically. In other cases, especially where merging of the rule systems creates conflicts or dilemmas, harmonization may be semi-automatic, with the assistance of human experts.

In this paper, we focus on one key aspect of these challenges: the de-composition of procedures into re-usable, generic 'chunks' that provide a kind of knowledge base of procedural control knowledge for the generation of procedures customized to the specific trade situation.

2. Trade Scenarios for Open Electronic Commerce

In the past, the introduction of Electronic Data Interchange (EDI) has offered important benefits for the efficiency of trade and accuracy of trade, especially for business-to-business electronic commerce. On the other hand it can also been observed that EDI usually requires substantial implementation efforts, which must be re-programmed for each new type of transaction. As a result, most successful EDI implementations have been realized in what could be called 'closed trading relationships', i.e. long-lasting trading relationships, involving


a high number of transactions, between parties that have a high level of trust and possibly a close coordination of the parties' business processes.

Recent developments in XML-based technologies promise to improve this situation somewhat [34]. A key benefit of XML (Extensible Markup Language) over previous EDI approaches is due to the fact that the structure of the document is also defined in a computer-interpretable form: so-called Data Type Definitions, and more recently, XML Schemas [47], which provide additional data-typing information. In this way, 'chunks' of document definitions can be re-used in the definition of other documents. For example, a purchase order document may contain fields for delivery address and billing address. These in turn contain fields for street, city, postal zone, which are reused in each address structure definition. Furthermore, the syntax for data items such as postal zone vary from one country to another, and can be given specific, reusable datatype definitions within the XML Schema language. This reusability facilitates the flexible re-design of electronic documents. The work on the eBusiness XML standard (ebXML), [10], incorporates the semantics of the earlier UN/EDIFACT documents standards into the new syntax of XML. Beyond this, Kimbrough [21,22] along with Moore [23] propose an even more flexible approach to business messaging with their Formal Language for Business Communication (FLBC). This is a logic-based representation capable of representing not only data, but also legal aspects, as in contracting communications.

However, these improved messaging approaches solve only part of the problem for open electronic commerce: the parties also need to know about each other's "way of doing business" -- the trade procedure they are going to follow. As noted earlier, a trade procedure is the mutually agreed upon set of actions, documents, and associated rules that governs the activities of all parties involved in a set of related business transactions. A trade scenario, the computational version of a trade procedure, thus needs to stipulate which actions should be undertaken by which parties, the order in which these actions should be performed and possibly the timing constraints on the performance of these actions. Actions of parties include the sending and/or receiving of goods, documents or funds.

The notion of trade scenarios has been evolving for over a decade. It first began to gain publicity through the activities of the International Standards Organization Open-EDI group, (ISO SC30) [19] in the early 1990's. (It was this group that introduced the term 'scenario'.) These interests and activities expanded by the United Nations Center for eBusiness and Facilitation of Trade (UN/CEFACT), especially its working groups on Techniques and Methodologies (TMWG), Business Process Analysis (BPAWG), and International Trade Procedures (ITPWG) [43,44,45,46]. Several commerical organizations are investigating and developing scenarios, the most successful of which is RosettaNet [40], for trading within the


electronics industry. Another interesting commercial development for scenarios is the OASIS initiative in Business Transaction Protocols (BTP), [37].

A key aspect shared by these various trade scenarios architectures is that they are generic and resuable among different sets of trading parties. This has the virtue that they may be down-loaded from e.g. a central library to meet the needs of a particular contractual situation. Also they are (usually) 'soft-coded' in a declarative, rule-based form1. More significant, however, is that such soft-coded scenarios can be analyzed and managed using computational tools. For example, analytical techniques can be applied to check for formal correctness (boundedness, etc.), as well as fraud potential and other audit controls. Further, soft-coding allows for the representation of generic models that are parameterized for specific circumstances. Additionally, generic trade procedures enable the navigation, synthesis and negotiation of procedures from different trading sectors or regulatory environments. These aspects are discussed further, below.

3. Representation: Documentary Petri Nets

A central problem for the management of electronic trade procedures is the question of how they should be represented both from the modeler's perspective, and as well as from a computational perspective. The representation we have developed is an extended form of petri net, called a documentary petri net (DPN), [3,8,9,29,30,31,32]. Petri nets are a graphical representation for modeling discrete concurrent processes (like a PERT or marked graph), that also represent choice (like a state-transition diagram, or decision tree.) A classical petri net is a bi-partite, directed graph. It has two disjunct sets of nodes: places (represented as circles) and transitions (represented as bars). Arcs connect places with transitions or vice versa (it is not allowed to connect two places or two transitions). The dynamic behavior of the modeled system is represented by tokens flowing through the net (represented as dots). Each place may contain several tokens (the marking of the place); a transition is enabled if all its input places (i.e., arcs exist from those places to the transition) contain at least one token. If this is the case, the transition removes one token from each input place and instantaneously produces one in each output place (i.e., an arc exists from the transition to the place). This is called the 'firing' of a transition. For further background see for instance [38,39]. Other, extended forms of petri nets are discussed in [1,11,12,52].

The main extensions of documentary petri nets (DPN's) over the classical form are as follows. One important aspect of modeling complex scenarios is the ability to model roles as separate documentary petri nets. This allows the decomposition of a trade procedure into a number of logically separate sub-nets. This modeling style results in a clear "geographical" separation

1 Note: 'soft-coded' is not to be confused with 'soft computing' which refers to fuzzy-logic computing approaches.


between the roles -- both visually, as well as literally, in actual operation [30]. In documentary petri nets transitions represent actions, labeled to indicate the agent(s) of the action as well as the kind of action performed:

<role> : <action>[<role>, ..., <role>] : <action>

Various place types and predicate labels are also used in documentary petri nets to specify the different document types, goods, funds and deontic states.

• The conventional places in a classical petri net are called control places in DPNs. These model the flow of control with a particular role in the transaction.

• The sending and receiving of documents is modeled using document places. A document place is represented by a square box. These kind of places have labels that identify the sender/recipient role, as well as one or more document types (thus, a collection of documents may also be sent as a single unit). Note: in these document places, no distinction is made between informative documents and performative documents [20]. For instance, thesending and receiving of funds is modeled in the same fashion as other document exchanges. However, performative documents will typically have more and stronger control activities related to them, for instance, acknowledgements of receipt, authenticity checks.

• The sending and receiving of physical goods is also represented in a similar way to documents, though the place is sometimes drawn as a cube or special icon for visual distinction. Nonetheless, semantically, they function in the same way as document places in the DPN formalism. Typically, a separate activity is shown to indicate the physical transportation.

• Deontic states are represented as predicate labels on a control place. As such, they are local to a role. The marking of the control place indicates the deontic predicate becomes true. This state persists until it is explicitly negated by another deontic state predicate.

A DPN transition (action) is enabled when its input places (control places or document places) are marked (darkened), indicating the fulfillment of its pre-conditions. Firing the transition causes its input places to be un-marked, and all of its output places to become marked, indicating the initialization of its post-conditions.

From a formal standpoint, the two most significant extensions of the DPN notation over the basic, classical form are the addition of document places, and predicate labels on control


places. Since documents can carry data, the addition of document places makes DPN's similar to 'colored' petri nets, where tokens may carry data parameters (colors). Aalst [1] gives an in-depth discussion of colored petri nets. A difference in DPN's is that the data of a document, once received, becomes persistent to that role. This is equivalent to a colored petri net where data from input tokens is copied to output tokens. The marking of places with predicates is analogous to the predicate/transition nets of Genrich and Lautenbach [11,12]. While not discussed further here, this aspect features more prominently in applications involving deontic reasoning such as electronic contracting, or governmental regulatory procedures.

There are several variations in the DPN notation. One form, called a joint DPN, shows the entire transaction in a single graph, as shown in Figure 3. In this example the Buyer sends a request for quotation to the Seller, who upon receiving the quotation prepares the quote and sends it to the Buyer. An alternate notation, called role DPN's, uses a separate sub-net for each role. This is shown in Figures 4a and 4b for the same transaction. Figure 4a shows the view of the transaction from the Buyer standpoint, of sending a 'request_quote' document, and later receiving a 'quote' document. Figure 4b shows the transaction from the Seller's viewpoint: first a 'request_quote' document is received from the Buyer; next the Seller does the task, 'prepare-quote'; next the Seller sends the 'quote' to the Buyer. It is the role procedure form of DPN, illustrated by Figures 4a and 4b, that is used for distributing scenarios among geographically remote contracting parties. A feature of this form is that each of the role scenarios executes autonomously, with no central control of the transaction. The only coordinating communications are done by means of the (electronic) documents. This accurately reflects the legal assumptions for contracting and trade procedures.

[INSERT FIGURE ABOUT HERE]

Figure 3. Joint DPN


Figure 4a. Buyer Role DPN


Figure 4b. Seller Role DPN

4. Customized Generation of Electronic Trade Scenarios


The approach generally taken for the design of trade scenarios may be characterized as a kind of workflow modeling applied to the inter-organizational case. As with workflow, the entire sequence of steps to be taken by the various parties is specified as a single transaction model, which is then stored in a repository, and made available for general use. A limitation of this approach is that the scenarios available from the repository are fixed; that is, they cannot be adapted or adjusted to meet additional needs of a given situation. In this part of the project, we address this problem with an expert system approach, by which scenario components are broken down into reusable component parts, which can be flexibly reassembled to meet the needs of a wide variety of situations. The computational formalism we introduce is called a procedure constraint grammar (PCG). As its name suggests, this approach has two aspects: constraints and grammars. We present the grammar aspects first, then explain how constraints are incorporated.

The notion of a formal grammar is originally due to the linguist Chomsky [4]. Chomsky wanted to give an analytical account of the mechanisms for generating language, an abstraction he called the language acquisition device (LAD). He discovered that the sophistication of such a device would vary depending on the complexities of the language. Some years prior to Chomsky, Turing was specifying the formal properties of computational devices. It is one of the interesting coincidences of science that these two theories, developed quite independently and in quite different fields, yielded analytical descriptions that were nearly identical [33]:

Chomsky Languages Turing Devices 0. Recursively Enumerable Turing Machine1. Context-Sensitive Linear Bounded Automata2. Context-Free Push Down Automata3. Regular Finite Automata

This coincidence of analytical form eventually gave rise to the topic of computational linguistics. Originally, computational linguistics was conceived as a joint area between linguistics and computer science, but eventually it became subsumed more in the latter field, focusing on AI topics of natural language parsing and machine translation. A further development was the notion of computational grammars. Significant among these was the augmented transition network (ATN) formalism of Woods [49]. An ATN was based on the formal graph model of a state transition network (STN) augmented with re-write rules (production rules) on the arcs. ATN's were invented for use as a means to specify the grammars for natural language parsing interfaces. However, they were also discovered to be useful in other applications where sequential pattern matching was involved, e.g. in diagnosing heartbeat patterns in electro-cardiograms. ATN's were based on STN graph structures. Another non-linguistic variation of this development came in the work of Zisman


[52], who generalized the underlying graph structure of ATN's from state transition network to petri nets, yielding an augmented petri net (APN) formalism. Zisman did not use APN's as grammars, in the sense of recognizing dynamic patterns, but rather as a formalism to specify office automation systems, better known today as workflow systems. The impact of this work is still seen today in the influence of petri nets as a reference framework for the Workflow Management Consortium [13]. Concurrent to this work, developments in logic programming were also associated with computational grammar formalisms. Colmerauer, one of the founders of logic programming, also invented metamorphosis grammars [5], which later evolved into definite clause grammars (DCG's), which were shown to have comparable expressive power to ATN's [36]. Indeed, a subsequent generalization, known as attribute grammars, has been proposed as a unifying framework for various forms of logic programming proof techniques [18; 7]. The formalism presented here, procedure constraint grammars (PCG's), originated as a petri net generalization of the DCG formalism, much like Zisman generalized ATN's to a petri net form, APN's. Thus, there is a close analogy -- PCG is to DCG as APN is to ATN. For example, a typical DCG rule looks like this:

sentence([NP, VP]) --> noun_phrase(NP), verb_phrase (VP).

noun_phase([N]) --> noun(N).noun_phrase([D, N]) --> determiner(D), noun(N).

verb_phase([V]) --> verb(V).

determiner('the').determiner('a').

noun('dog').noun('cat').

verb('eats') .verb('sleeps') .verb('sits') .

In the DCG notation, multiple rules of the same type (same functor) indicate a choice. The comma separating constituents on the right hand side indicates sequence -- so, a 'noun_phrase' is followed by a 'verb_phrase'. Thus, this little grammar recognizes 12 (2*2*3) sentences such as 'the cat sleeps', or 'a dog eats'. As seen just in this tiny example, grammars can offer a huge combinatoric representation capability. In procedure constraint grammars, we represent trade scenarios rather than language sentences. A simple PCG might look like this:

[Buyer, Seller]: purchase_goods([Goods, Money]) ==> A :: Seller: delivery(Goods);B :: Buyer: payment (Money);

A .<. B.


X:delivery(Goods) ==> X:self_delivery(Goods).X:delivery(Goods) ==> X:postal_delivery(Goods).

X:payment (Money) ==> X:cash_payment(Money).X:payment (Money) ==> X:credit_card_payment(Money).X:payment (Money) ==> X:money_order(Money).

In this example, the '[Buyer, Seller]: purchase_goods' scenario may have two different

alternative forms of delivery and three alternative forms of payment. As illustrated in this

little PCG example, there are three notational differences compared to DCG. The first is that

constituent actions are labeled with the agent of the actions (as in the DPN notation). The

second is the symbol '::', which is merely an assignment of a variable name to an action. The

third and most important difference is the symbol '.<.', read precedes. In PCG, the right-hand

comma no longer indicates sequence. Rather, sequence is indicated separately by the precedes

('.<.') predicate; constituents are presumed to be unordered, except according to the temporal

ordering constraints explicitly noted by precedes. Also, the precedes ('.<.') predicate does not

necessarily imply immediate precedence -- the indicated actions might be separated by other

actions. More specifically, the precedes predicate is used to specify an explicit ordering

constraint on two actions:

<action-label> .<. <action-label>

However, considering that actions may have pre-conditions or post-conditions, ordering

constraints may also be specified 'implicitly' as a condition (state predicate) in either position:

<condition> .<. <action-label>

<action-label> .<. <condition>

Unlike a natural language sentence, where the words are always totally ordered, a PCG

generated procedure can have concurrencies, that is, partially ordered actions, reflected in the

precedes predicate, which allows actions in a rule to be partially ordered. This difference also

has ramifications for the processing of these rules. In a DCG, processing the grammar to

generate (or recognize) a sentence can be done using a depth-first search. This is because the

right hand constituents are totally ordered in each rule. In the PCG form, this is only a partial

ordering. Because of this, the processing of PCG rules involves constraint resolution. The


actions in the PCG rules may be either basic or non-basic, that is, defined in terms of other

constraints. Based on these constraint specifications, the constraint solver expands non-basic

constraints into lowest level, basic constraints. It then creates a partial ordering of actions

based on explicit temporal ordering constraints. It then adds additional constraints to satisfy

implicit temporal ordering constraints, based on state conditions (like a state space search in

AI). Where multiple actions need to occur simultaneously, these are replaced by a joint action.

4. PCG Examples

4.1 Example 1: get quotation

As a starting example we present a tiny grammar that generates the example DPN procedure introduced previously:

[Buyer, Seller]: get_quotation ==>A:: [Buyer, Seller]: transmit([request_quote]),B:: Seller: prepare_quote,C:: [Seller, Buyer]: transmit([quote]),

A .<. B, B .<. C.

This example makes use of a sub-procedure, 'transmit', that is re-used quite often. It is defined graphically as a joint-DPN as shown in Figure 5. In that figure, 'DocList' represents a package of one or more documents being sent. The resulting procedure generated from this grammar is identical to the DPN's shown in Figures 3 or 4 (a,b) above.


Figure 5. Template DPN: transmit

In the remainder of this section, however, we will use another variant of the DPN notation, called a single-flow DPN, which provides a more compact presentation. Like the joint-DPN, a single-flow DPN shows the activities of all roles in a single graph, but compressed to show just a single flow of transaction control. In order to reduce the detail of the graph, paired actions, such as 'transmit' above, are not expanded, but presented as a single action. Thus, in Figure 6, the simple transaction shown as a joint DPN in Figure 3, and as role DPN's in Figures 4a and 4b, is now presented in this more abstract form: first there is a 'transmit' from Buyer to Seller of a 'request_quote' document; then Seller does 'prepare_quote'; then there is a 'transmit' from Seller to Buyer of the 'quote' document.



Figure 6. Example 1: Single-flow DPN for 'get_quotation'

4.2 Example 2: choice of payment mode

This example illustrates how parameters may be inserted in the grammar to provide customization options to the end user. In this example the parameter '@pay_mode' offers three different choices of payment. Figure 7 shows a dialogue where the user selects a single choice. The resulting procedure is shown in Figure 8. In that case, the generate procedure has a linear flow consisting of two steps: first, there is a 'transmit' from Seller to Buyer of Goods; then there is a 'transmit' from Buyer to Seller of document 'money_order' in the amount, Price.

[Buyer, Seller]: postpaid_sale(Goods, Price) ==>A:: [Seller, Buyer]: transmit([Goods]),B:: [Buyer, Seller]: payment(Price),

A .<. B.

/* further payment details */[X,Y]: payment( Price) ==>

{ @pay_mode == 'bank_check'},[X,Y]: transmit(bank_check( Price )).

[X,Y]: payment( Price) ==>{ @pay_mode == 'money_order'},[X,Y]: transmit(money_order( Price )).

[X,Y]: payment( Price) ==>{ @pay_mode == 'electronic_funds_transfer'},[X,Y]: transmit(digital_cash(Price)).



Figure 7. Example 2: Dialogue for choice of payment mode


Figure 8. Example 2: Expanded procedure after single choice

4.3 Example 3: multiple choices of payment mode

This example illustrates the difference between design time choices and execution time choices. By selecting multiple modes at design time, as shown in Figure 9, the generated procedure will offer these choices to the end-user when the procedure is executed. The generate procedure is shown in Figure 10. This procedure begins with a 'transmit' from Seller to Buyer of Goods; next there is a choice between two actions: either a 'transmit' from Buyer to Seller of 'digital_cash' in the amount Price, or otherwise a 'transmit' from Buyer to Seller of a 'money_order' in the amount Price.

[INSERT FIGURE HERE]Figure 9. Example 3: Dialogue for multiple choices of payment mode

[INSERT FIGURE HERE]Figure 10. Example 3: Expanded procedure after multiple choice

4.4 Example 4: sales contract with carrier subcontract

The following scenario grammar illustrates a concurrency situation. The resulting procedure is shown in Figure 11. As shown, the payments of the DeliveryPrice and SalePrice are done concurrently.

[Buyer, Seller, Carrier]:carrier_contract(Goods, SalePrice, DeliveryPrice) ==>A :: Seller to Carrier:

delivery_order(Goods, Buyer, DeliveryPrice) ,B :: Carrier: transport(loc(Buyer), Goods),C :: Seller to Carrier: payment(DeliveryPrice),D :: Buyer to Seller: payment(SalePrice),

A .<. B, B .<. C, B .<. D.


[INSERT FIGURE ABOUT HERE]Figure 11. Example 4: Expanded procedure with concurrency

4.5 Example 5. transport contract with performance evidence requirement

The following scenario grammar illustrates heuristic search, based on evidence requirements, to assemble the controls of the procedure. In this example, a third party Carrier is contracted to make delivery to the Buyer. The Seller will pay the Carrier, but only after having received a receipt for the Goods from the Buyer. Figure 12 shows the basic steps of the procedure, delivery and payment. However, these are not connected, since the pre-condition for the Seller's payment to the Carrier, having a receipt from the Buyer evidencing the delivery, has not been met. This suggests that some additional step(s) will be needed. In Figure 13, the step of a heuristic step has been inserted: the Carrier transmits (gives) the needed receipt to the Seller. However, there is still the unfilled pre-condition that the Carrier must have the receipt. (This is somewhat like the Monkey and Banana problem used as an AI exercise.) In Figure 14, the delivery step is transformed into a joint action, where the Buyer gives a receipt for the Goods to the Carrier. This allows the procedure to be connected and completed.

[Seller, Carrier] : carrier_transport(Goods, DeliveryPrice) ==>A :: Carrier: delivery(loc(Buyer), Goods),B :: Seller to Carrier: payment_for(A, DeliveryPrice).

/* 'payment_for' constraint*/X to Y: payment_for(Action, Amt) ==>A :: X to Y: payment(Amt),

has(X, evidence(Action)) .<. A.


Figure 12. Example 5: Initial constraints


Figure 13. Example 5: Add transmit of receipt



Figure 14. Example 5: Final procedure, after replace delivery constraint.


6.6 Example 6: documentary credit procedure


Figure 15. Example 6: Roles and Document Flows for Documentary Credit

A documentary credit is a common trade procedure used when goods are being transported long distances, and the seller (in the role of Shipper) wants to be paid immediately, whereas the buyer (in the role of Consignee) does not want to pay until the goods arrive. Guidelines for this procedure are set forth in the Uniform Customs and Practice for Documentary Credits [16]. In the simplified form presented here, a credit for the price of the goods is made by a bank, called the Issuing Bank (typically in the buyer's country), which is conveyed to the Shipper (seller) by another bank, called the Coordinating Bank. A sketch of the document flows is shown in Figure 13. A scenario grammar is as follows:

[Buyer, Seller, Carrier, Bank]:letter_credit_payment(Goods, SalePrice, DeliveryPrice,Interest) ==>A :: Seller to Carrier: dispatch(Goods),B :: Bank to Seller: payment_for(A, SalePrice),C :: Carrier: transport(warehouse(city(Buyer)), Goods),D :: Carrier to Buyer: notify(A),E :: Buyer to Bank: payment(SalePrice + Interest).F :: Carrier to Buyer: give(Goods).G :: Seller to Carrier: payment_for(F, DeliveryPrice),

D .<. E,has(Carrier, evidence(own(Buyer, Goods))) .<. F.

/* 'payment_for' constraint*/X to Y: payment_for(Action, Amt) ==>A :: X to Y: payment(Amt),

has(X, evidence(Action)) .<. A.

/* documentary evidence rules */evidence_for X to C: dispatch(Goods) is doc bill_lading(C, Goods).evidence_for own(X, Z) is doc title(X, Z).evidence_for own(X, Z) is doc bill_lading(X, Z).evidence_for X to Y: give(Z) is doc receipt(Y, Z).

/* issuance rules */X to Y: dispatch(Goods) ==>

X to Y: dispatch(Goods) &Y to X: issue(bill_lading(Y, Goods).

X to Y: give(Goods) ==>X to Y: give(Goods) &Y to X: issue(receipt(Y, Goods).


As before, the generation of this procedure relies on heuristics to satisfy evidence pre-conditions. These are three evidence requirements, indicated by the following constraints:

1. Bank to Seller: payment_for(A, SalePrice)2. has(Carrier, evidence(own(Buyer, Goods))) .<. F3. Seller to Carrier: payment_for(F, DeliveryPrice)

Because of the definition of 'payment_for' (see earlier) the first of these constraints requires that the Bank received evidence of action A, that the Seller has dispatched the Goods. The second of these constraints requires that prior to the Carrier handing over the Goods to the Buyer, the Carrier needs to receive evidence that the Buyer owns the Goods. The third of these constraints requires that prior to the Seller paying the Carrier, the Seller needs evidence that the Carrier has delivered the Goods to the Buyer. The initial constraint set is shown in Figure 16. At this point, the constraint solver sets about trying to satisfy the first evidence condition, and determines, using the first evidence rule, that a 'bill_lading' document constitutes evidence of dispatch. This is combined with the issuance rule that allows the recipient of a dispatch action to issue a 'bill_lading' so that the initial action is transformed to generate the needed bill of lading. This is shown in Figure 17. Figure 18 shows the next step in this process, which shows the heuristic result to satisfy the second constraint, that the Seller have evidence of ownership prior to receiving the Goods. This can be provided by a bill_lading, which the Seller receives after paying for the Goods. In Figure 19 the results of the satisfying the third constraint are shown. This involves an inference similar to the previous example, where the Buyer issues a receipt to the Carrier, providing evidence of delivery, which is the precondition for the Seller's payment to the Carrier.


Figure 16. Example 6, step 0: initial constraint set


Figure 17. Example 6, step 1: add bill of lading as evidence of dispatch


Figure 18. Example 6, step 2: add bill of lading as evidence of ownership.


Figure 19. Example 6, Step 3: Final procedure, after add receipt as evidence of delivery


5. Implementation Status

The focus of this paper has been on procedure constraint grammars (PCG's). These generate

procedures using the documentary petri net (DPN) representation. However, as mentioned,

DPN's can also be designed directly, using a graphical interface. The graphical modeling and

prototype simulation of DPN trade procedures is supported in the system called

INTERPROCS, which is available over the Internet [17]. This is a Java-based system, and

DPN models can be viewed directly from Web pages using applet mode, but design of new

models requires stand-alone operation. The PCG functionality described here has been

implemented separately using Prolog. This is presently being integrated into the Java version.

6. Conclusions, Further Challenges

Electronic trade procedures or 'scenarios' are ready-made, generic and re-usable transaction models for trade communities such as seaports, banking, logistics, etc. They are made available to parties for downloading from repositories provided by international, regional, or industry organizations. These electronic trade scenarios provide a means of achieving "plug and play" capabilities for complex, business to business trade transactions, especially for international trading. However, the trade scenarios retrieved from repositories are fixed in the sense that they cannot be adapted to exceptional needs of a given situation, and do not allow trading parties the flexibility to adapt them to different circumstances. In this paper, the notion of a scenario grammar was introduced as a means to provide this flexibility. The specific formalism introduced here is called a procedure constraint grammar (PCG).

In the modeling experiments we have done so far, the PCG formalism has proven to be adequately expressive, and least for examples from the international trade domain. However, it is already clear that further organizing mechanisms will be needed to structure the rule base as it grows in complexity. For instance, there appear to be at least two abstraction hierarchies needed: one for doing tasks, and another for control tasks. The latter abstraction hierarchy will also have branches based on the communication technology employed. This suggests that perhaps even a third hierarchy may be needed, for these technologies.

A generalization of the problem of modeling international trade transactions is to include the pertinent governmental regulations that apply to the transaction being generated. In the current version, such constraints are presumed to be included in the scenario grammar as additional rules. However, more realistically, one must cope with the problem of 'distributed


governance' -- that such regulations are under the control of distant government agencies, and are subject to change. A desirable solution would be to poll these agencies 'on the fly' as the transaction procedure is being synthesized. An approach for this, utilizing computational agents called messengers, builds on the PCG formalism described here [27].

References

[1] Aalst, W.M.P. van der "Timed coloured Petri Nets and their application to logistics", PhD thesis Eindhoven University of Technology, 1992

[2] Austin, J.L. "How to DO Things with Words", Harvard University Press, Cambridge, MA, 1962[3] Bons, R.W.H., Lee, R.M., Wagenaar, R.W. and Wrigley, C.D. "Computer Aided Designs of Inter-

organizational Trade Procedures", Proceedings of the Seventh International Conference Electronic Commerce and Electronic Partnerships, Bled, Slovene, June 6-8, 1994.

[4] Chomsky, N. Syntactic Structures, Mouton Publishing, 1957.[5] Colmerauer, Alain. "Metamorphosis Grammars" in L. Bolc (ed.) Natural Language Communication with

Computers, Lecture Notes in Computer Science, Vol 63, 1978, pp. 133-189.[6] Crowhurst, R. "Trade Facilitation...Reducing the Economic Frictions that Get in the Way of Trading

Across Borders", SITPRO News, July 2000. (See also www.sitpro.org.uk)[7] Deransart, Pierre and Maluszynski, Jan. A Grammatical View of Logic Programming, MIT Press, 1993.[8] Dewitz, S. K. and Lee, R. M. "Legal Procedures as Formal Conversations: Contracting on a Performative

Network", Proceedings of International Conference on Information Systems, Boston, December 1989, pp. 53 - 65

[9] Dewitz, S.D. "Contracting on a Performative Network: using IT as a legal intermediary", PhD Thesis, University of Texas, Austin, 1992.

[10] ebXML, www.ebxml.org[11] Genrich, H.J. and Lautenbach, K. "System Modelling with High-level Petri Nets", Theoretical Computer

Science, Vol. 13 pp 109-136, New York: North-Holland, 1981.[12] Genrich, H.J. and Lautenbach, K. "The Analysis of Distributed Systems by Means of Predicate/Transition

Nets", Semantics of Concurrent Computation: Lecture Notes in Computer Science, Kahn G. (Ed.), Vol. 70 pp 123-146, Springer Verlag, 1979

[13] Hollingsworth, D., "The Workflow Reference Model", Workflow Management Coalition, www.wfmc.org. TC00-1003, 1995.

[14] Hopcroft, J.E. and Ullman, J. D. Formal Languages and Their Relation to Automata, 1969.[15] ICC, "Incoterms 1990", International Chamber of Commerce publication 461, 1990[16] ICC, "The Uniform Customs and Practices for Documentary Credit Procedures", International Chamber

of Commerce publication 500, Paris, France, January 1994[17] INTERPROCS, http://abduction.euridis.fbk.eur.nl/projects/InterProcs.html[18] Isakowitz, Tomas. "On the Relationship Between Logic Programs and Attribute Grammars", Masters

thesis, University of Pennsylvania, December 1985.[19 ISO, The Open-EDI Reference Model, IS 14662, ISO/IEC JTC1/SC30, 1996.[20] Kimbrough, S., Lee, R.M. and Ness, D.N. "Performative, Informative and Emotive Systems: The First

Piece of the PIE", Proceedings of the Fifth International Conference on Information Systems, Fall, 1984, pp.141-148.

[21] Kimbrough, S.,O. "On Representation Schemes for Promising Electronically", Decision Support Systems, 6(2):99-122, 1990.

[22] Kimbrough, S.O. "Formal Language for Business Communication: Sketch of a Basic Theory", International Journal of Electronic Commerce, 3(2): 23-44, Winter 1998-99.

[23] Kimbrough, S.O. and Moore, S.A. "On Automated Message Processing in Electronic Commerce and Work Support Systems": Speech Act Theory and Expressive Felicity", ACM Transactions on Information Systems, 15(4): 321-367, October 1997.

[24] Knoppers, J "Importance of the "OPEN-EDI" reference model from a user and business perspective", Proceedings Conference on Interorganizational Systems in the Global Environment, Bled, 1992.

[25] Lee, Dongwon, Wesley W. Chu, "Comparative Analysis of Six XML Schema Languages", ACM SIGMOD Record Volume 29, Number 3 (September, 2000).

[26] Lee, R.M. "A Logic Model for Electronic Contracting", Decision Support Systems, Vol. 4, No. 1, 1988, pp. 27-44

http://www.ebxml.org/


[27] Lee, R.M. "A Messenger Model for Navigating Among Bureaucratic Requirements", Proceedings of the Hawaii International Conference on System Sciences, January, 1997, Vol IV, pp. 468-477.

[28] Lee, R.M. "INTERPROCS: A Java-based Prototyping Environment for Distributed Electronic Trade Procedures", Proceedings of the Hawaii International Conference on System Sciences, January, 1998.

[29] Lee, R.M , "Towards Open Electronic Contracting" Journal of Electronic Markets Special Issue on Electronic Contracting, Vol 2, No 1, 1998.

[30] Lee, R.M and Bons, R.W.H, "Soft-Coded Trade Procedures for Open-EDI" Journal of Electronic Commerce, Vol 1, No 1, 1996, pp. 27-49.

[31] Lee, R.M. and Dewitz, S.D. "Facilitating International Contracting: AI Extensions to EDI", International Information Systems, January, 1992.

[32] Lee, R.M. and Dewitz, S.D. "Finding International Contracting Opportunities: AI Extensions to EDI," Proceedings of the International Conference on Information Systems, Copenhagen, Denmark, December 16-19, pp. 1-13, 1990.

[33] Levelt, W.J.M. Formal Grammars in Linguistcs and Psycholinguistics, Vol. I, An Introduction of the Theory of Formal Languages and Automata Mouton, 1974.

[34] Megginson, D. Structuring XML Documents, Prentice-Hall, 1998.[35] Mitrikas, A. "Model Trading Partner Agreements", Euridis Working Paper, 94-12-01.[36] Pereira, F.C.N. and Warren, D.H.D "Definite Clause Grammars for Language Analysis -- A Survey of the

Formalism and a Comparison with Augmented Transition Networks", Artificial Intelligence, 13, 1980, pp. 231-278.

[37] OASIS Technical Committee on Business-Transaction Protocol (BTP), www.oasis-open.org/committees/business-transactions/index.shtml

[38] Peterson, J. L. "Petri Net Theory and the Modeling of Systems", Prentice-Hall, 1981[39] Petri, C.A. "Kommunikation mit Automaten", PhD thesis University of Bonn, Germany, 1962.[40] RosettaNet, www.rosettanet.org[41] Searle, J. "Speech Acts: An Essay in the Philosophy of Language", Cambridge University Press, London,

1969[42] UN/CEFACT, United Nations, Center for eBusiness and Facilitation of Trade, www.unece.org/cefact[43] UN/ITPWG, , "Facilitation Measures Related to International Trade Procedures: Recommendation No.

18", United Nations, International Trade Procedures Working Group, TRADE/CEFACT/2001/18, available at www.unece.org/cefact/wg/itpwg/itpwg_main.htm

[44] UN/BPAWG. United Nations / Business Process Analysis Working Group, "BPAWG Model of the Interrnational Supply Chain Domain", UN/CEFACT/BPAWG/BPA015; available at www.unece.org/cefact/docum/sessdocs/bawg0398.htm

[45] UN/ITT United Nations / International Trade Transaction Modeling Group www.unece.org/trade/itt/itt_tip.htm (now superceded by UN/BPAWG).

[46] UN/TMWG. United Nations / Techniques and Methodologies Working Group, "The UN/CEFACT Modelling Methodology - An Introduction, TMWG/N097; available at www.gefeg.com/tmwg/

[47] W3C XML Schema, http://www.w3.org/XML/Schema[48] Wagenaar, R. W. "Business network redesign - Lessons from the Port of Rotterdam Simulation game",

Proceedings Conference on interorganizational systems in the global environment, Bled, 1992.[49] Woods, W.A. "Transition Network Grammars for Natural Language Analysis", Communications of the

ACM, 13, 1970, pp. 591-606.[50] Wrigley, C.D. "EDI transaction protocols in international trade", Proceedings Conference on

interorganizational systems in the global environment, Bled, 1992[51] Wrigley, C.D. and Wagenaar, R.W. and Clarke, R.A. "EDI in International Trade: Frameworks for the

Strategic Analysis of Ocean Port Communities", Journal of Strategic Information Systems, Volume 3, number 3, 1994

[52] Zisman, Michael. 1977. "Representation, Specification and Automation of Office Procedures". PhD Dissertation, Dept. of Decision Sciences, University of Pennsylvania, Philadelphia, PA. (Also available as Working Paper 77-09-04).

http://www.gefeg.com/tmwg/

http://www.unece.org/trade/itt/itt_tip.htm

http://www.unece.org/cefact/docum/sessdocs/bawg0398.htm

http://www.rosettanet.org/

http://www.oasis-open.org/committees/business-transactions/index.shtml


Appendix: PCG Syntax

PCG Syntax:

<constraint-definition> ::=<action> ==>

{<conditions>}<rule-constraints>.


{<conditions>}<DPN template>.

Note: <DPN template> is DPN graph, possibly including variables.


{<conditions>}from <pre-conditions>next <post-conditions>.

<rule-constraint> ::=<label> :: <actions>

| <label> :: <label-or-cond> .=. <label-or-cond>| <label> :: <label-or-cond> .<. <label-or-cond>| <label> :: <label-or-cond> .=<. <label-or-cond>

<rule-constraints> ::= <rule-constraint><rule-constraints> ::=<rule-constraint >, <rule-constraints>

<pre-conditions> ::= <conditions><post-conditions> ::= <conditions>

<conditions> ::= <condition><conditions> ::= <condition>, <conditions>

<condition> ::= <predicate>

<actions> ::= <action><actions> ::= <action>, <actions>

<action> ::= <agents> : <condition>

<agents> ::= <agent><agents> ::= <agent> to <agent><agents> ::= [<agent>, ..., <agent>]

<agent> ::= <variable> | <atom>

<label-or-cond> ::= <label><label-or-cond> ::= <condition>

<label> ::= <variable>