[legalxml-econtracts] Basic Contract Structure

I have spoken previously about the fact that a given document represents multiple information models simultaneously. We have discussed at length the notion that a document has a Logical Model and a Physical Model, the physical model being that which corresponds to formatted pages of information. I am not reopening the discussion of whether it is worthwhile that LegalXML develop markup to represent a document's Physical Model. Rather, I am interested here in feedback on my view that there are at least several different logical information models that are represented by or within a Contract.

We know that a Contract is first and foremost composed of Clauses (and other items) that are necessary when formatting the document -- this is what I think of as the Clause Model for the contract. This Clause Model however does not usefully or conveniently capture much other information in the document, that is, the information contained within clauses. This memo isnt concerned with the Clause Model. Rather, it is concerned with the Term Model of a contract.

My view is that contract information is as equally organized by the TERMS mentioned in the contract as it is by its Clauses.

I use the term TERM in two ways simultaneously -- something that is both a definition of an item of agreement in the contract, and something that has a relationship to time. In my view, contract terms include recurring terms, non-recurring terms, and dated terms, most especially the term that covers the contract as a whole, what I call the ContractTerm,. A contract can be agreed (executed) on Date1, but its content is applicable to events contemplated and contingent as they occur during the period Date2 through Date3. This span of time, Date2 through Date3, is what I am referring to by the ContractTerm., and this span of time can be decomposed into subordinate ContractTerms. Information applicable to specific contemplated events and contingent events is provided in the context of non-recurring terms. Information applicable to certain recurring terms (e.g., monthly payments) which is not specific to any dated time period, is represented within the context of a RecurringTerm.

As an example of how this works, think of a contract that details stepped payments for some obligation. In PaymentTerm #1, the payment is X, and in Payment Term #2, the payment is Y.

<ContractDate><gDate>2004-02-29</gDate></ContractDate>

<PaymentTerm><Payment><usd>X</usd></Payment></PaymentTerm>

<PaymentTerm><Payment><usd>Y</usd></Payment></PaymentTerm>

</PaymentTerms>

</LegalContract>

An Obligation Model is another interesting information model, corresponding to Dr. Leff's work in contracts. Applied practically, a <ContractObligation> element could have child <ContractTerm> elements that represent terms that (would serve to) satisfy the obligation. These <ContractTerm> elements are merely a "base class" (that is, a superclass or supertype) for elements such as <PaymentTerm>, resulting that a <PaymentTerm> would equally satisfy content validation requirements of a <ContractObligation> element.

What this means is that a <Contract> element may contain <Clauses>, <Terms>, and <Obligations>. Within in a dictionary, we identify generic types of clauses, terms, and obligations for a generic contract, and those for specific subtypes of Contract. Within a dictionary, one or more sets of elements can be identified that are to be explicitly or implicitly inserted, for instance, whenever a <PaymentTerms> element contains a <PaymentTerm> element -- in this way we bridge to an unambiguous RDF encoding of the same information:

<rdf:RDF>

<LegalContract>

   <is><Dated><on><Date rdf:ID='ContractDate.1'><gDate>2004-02-29</gDate>...</is>

   <is><Agreed on="#ContractDate.1"/></is>
   <is><Described><with><PaymentTerms>

<is><Composed><of>

<rdf:Bag>

<rdf:li><PaymentTerm><is><Composed><of><Payment><usd>X</usd>...</PaymentTerm></rdf:li>

<rdf:li><PaymentTerm><is><Composed><of><Payment><usd>Y</usd>...</PaymentTerm></rdf:li>

</rdf:Bag>

....</is>...</is>

</LegalContract>

</rdf:RDF>

A dictionary can map two adjactent nouns, as might be defined in an XML Schema data structure, to RDF's more precise, expressive subject/predicate model. The nouns in an XML Schema are ones that would normally be separated by a "period" in object programming environments. These dotted names can be used within, say, an XHTML document :

<html>

<body>

<form names='LegalContract.en'>

<p>On <input names='ContractDate.gDate'>2004-02-29</span></p>

<p names='Clause.1.en'>

<span names='ClauseTitle.en'>Payments.</span>

<span names='ClauseBody.en'>Two payments, of

$<input names='PaymentTerm.1.PaymentAmount.usd'>237.45</input> and

$<input names='PaymentTerm.2.PaymentAmount.usd'>286.00</input> are

          obligated under this contract to be paid on

         <input names="PaymentTerm.1.PaymentDueDate.gDate">2004-02-29</input> and

         <input names="PaymentTerm.2.PaymentDueDate.gDate>2004-03-31</input>,

respectively.</span></p>

</form>

</body>

</html>

or in a native XML document, using a DTD such as that referenced below:

<rdf:RDF>

<Document names='LegalContract.en'>

<en>On <gDate names='LegalContract.DublinCore.date'>2004-02-29</gDate></en>

<en names='LegalContract.Clause.1.Title'>Payments.</en>

<en names='LegalContract.Clause.1.Body'>Two payments, of

$<usd names='LegalContract.PaymentTerm.1.Payment.Amount'>237.45</usd> and

$<usd names='LegalContract.PaymentTerm.2.Payment.Amount'>286.00</usd> are

obligated under this contract to be paid on

<gDate names="LegalContract.PaymentTerm.1.Payment.DueDate">2004-02-29</gDate> and

<gDate names="LegalContract.PaymentTerm.2.Payment.DueDate">2004-03-31</gDate>,

respectively.</en>

</Document>

</rdf:RDF>

John McClure

New publications by Hypergrove Engineering!

http://www.hypergrove.com/Publications/Symbols.html

http://www.hypergrove.com/Publications/DC200DTD.ZIP

soon: Information Models for Commercial Lease Contracts

legalxml-econtracts message