The CEL is a general purpose language that can be used to express contractual agreements in an unambiguous, machine interpretable form. It is designed to provide an extensible architectural framework. It also includes a set of baseline common and application-specific vocabularies for specifying contracts in many potential applications. The role of contracts written in the CEL is to describe the business agreements (generally contractual) between or among parties participating in the business value chain in a way that, when the contracts are specified, the interests and obligations of the value chain participants can be communicated, interpreted, and executed by machines.
A. Basic Concepts
What is a contract? One definition is that a contract is “a promise, or set of promises, for the breach of which the law gives a remedy, or the performance of which the law in some way recognizes as a duty.” Two or more parties can draft a contract to declare their consent to any act or thing to be done or forborne by some of them or others.
In the CEL, a contract is considered as an agreement between two or more parties over a number of promises made by some parties. The nature of being an agreement requires that a valid contract be signed by all parties involved. Each promise contains several clauses, each of which states a relationship as follows:
- some parties possess a right (or permission) to what the other grants,
- some parties bind an obligation to what theother requires,
- some parties follow a prohibition to what the other imposes,
- some parties see an intention to what the other expresses, or
- some parties know an assertion to what the other makes.
A right (or permission), an obligation or a prohibition means performance or non-performance of some act. The difference among them is on the types of modality of the act they address. A right or permission is of type of modality characterized by the word “may”, an obligation categorized by the word “must”, and a prohibition by “must not”. In contrast, an intention means a desire to perform some act, and an assertion describes a fact about the state of affair as to whether or not some act was performed, is being performed, or will be performed.
The relationship stated in a clause may be contingent upon some event to occur or some condition to be true. An event captures the changes in a system context or environment that may require the examination or execution of the clause. For instance, an obligation clause can be triggered when an event occurs, and when this is the case, the parties must fulfill the obligation. Event driven processing makes it possible to build more efficient systems to manage (e.g., consult, execute and enforce) contracts.
Clauses may be also mutually dependent. Simple kinds of dependency are the ones based on the existence and validity of another. More complex ones are the ones based on performance or non-performance of others. These kinds of dependency can be used to model rewards for fulfilling contracts and remedies for breaching contracts.
It is also important that a contract is modeled as a dynamic object with its lifecycle, and operations of creating, negotiating, executing and revoking contracts themselves need also be managed in a trusted manner.
B. Approach :
The CEL uses the XML technology to define its syntax and semantics. It is based on the MPEG REL (Rights Expression Language). It uses relevant concepts, elements and types defined in the REL as building blocks. It also adopts REL’s extensibility mechanisms provided by the XML schema, which, for instance, enables the separation of the CEL core elements and their relationships specified in the form of its data model from the application specific vocabularies captured in the forms of a variety of extensions to the core. This kind of design consistency ensures interoperability with the MPEG REL.
Like the MPEG REL, the CEL is defined as a declarative language. What this means is that the semantics of expressions written in CEL has no dependency on procedural or control aspects of interpreting the expressions, and the interpretation of CEL expressions yields no side effects – that is, the state of a system that uses CEL does not change because of the evaluation of any CEL expression.
C. Data Model
The following diagram illustrates the CEL data model:
Figure 01 : CEL data model
In this model, the root element of a CEL expression is the Contract element. It contains one or more Promise elements and one or more Signers elements representing parties who pledge to abide by the statements made by the Promise elements in the Contract. Each Promise is further defined as a conglomeration of Clauses and may contain one or more Issuers, each of which issues and optionally signs the statements conveyed by the Clauses within the Promise. An Issuer is different from a Signer in that the former makes the statement in the Clause it issues, whereas the latter agrees to that statement. Each of the Clauses may contain Event, Principal, Act, Resource, and Condition elements, but all these 3 elements are optional except for Act. The general framework of the CEL is based on this EPARC model of a Clause. More specifically, “EPARC” represents the following key components:
- Event: an optional element representing a triggering event.
- Principal: an optional element representing a party or a set of parties that may perform the act specified in the peer element Act.
- Act: a required element representing an act or a set of acts.
- Resource: an optional element representing a resource or a set of resources to which the Act applies.
- Condition: an optional element representing a condition, subject to which the Act may be performed.
Currently CEL has provided five specific types of Clauses that are syntactic and semantic extensions to the Clause: Grant, Duty, Ban, Intent and Claim. Their semantics are as follows:
- Grant: whenever the Event is triggered, permits the Principal the right to perform the specified Act over the Resource provided the Condition is met.
- Duty: whenever the Event is triggered, demands an obligation on the Principal to perform the Act on the Resource when the Condition is met.
- Ban: whenever the Event is triggered, imposes a prohibition on the Principal to perform the Act on the Resource under the Condition.
- Intent: whenever the Event is triggered, expresses the Principal’s intent to perform the Act on the Resource under the Condition.
- Claim: whenever the Event is triggered, asserts a fact that the Principal has performed the Act on the Resource when the Condition was met.
These specific Clauses make individual contractual statements to convey permissive, obligatory, prohibitory, intentional, and assertive information, and that, when grouped into Promises made by their Issuers.