RE: Request for info about contract implementations

[Bob Haugen <linkage@interaccess.com>]

Karsten Riemer wrote:
>I have been thinking of a construct as part of the metamodel:

>Contract and BusinessTransaction are or should both be non-abstract classes
>that you can instantiate. 

There will be concrete subclasses of Contract; Contract itself
should remain abstract in my opinion.

>Between them are two associations. One is
>called 'TransactedWithinTheBoundsOf' (or a more natural short name that
>says that). It is one to many from Contract to BusinessTransaction.
>The other is called 'Establishes'. It is one to one.

There is now an association from BusinessTransaction to
Contract called 'execute', which does the same thing as
'Establishes'.  

There is also a recursive relationship from Contract to Contract
that is yet unnamed.  That could carry the semantics of
'TransactedWithinTheBoundsOf' or maybe 'coveredBy'.
I think that would be better than having the relationship
be carried by BusinessTransaction (if that is what you meant).

There is also a relationship between Economic Event and
Contract called 'fulfills', wherein events like Shipments 
would fulfill Contractual commitments.

>So there might be a business transaction called 'LongTermContractNegotiation'
>specificed with a series of message exchanges, it would result in a
>Contract called 'LongTermContract'. 

Are you proposing a subclass of BusinessTransaction that
could cover many message exchanges?  My understanding
is that BusinessTransaction covers one exchange of two
messages, period, the end.  A series of messages would
be covered by a BusinessCollaboration realizing a 
BusinessProcess - or so I thought.  (In other words, I think 
BusinessCollaboration or BusinessProcess might be the correct 
container for a series of message exchanges.)
RosettaNet V2 has lots more details on contract formation.

>Transacted Within The Bounds Of the LongTermContract would be a series
>of Orders, each of which could establish 'Order' level contracts,
>against which a series of shipments could be transacted.

If 'TransactedWithinTheBoundsOf'  or maybe 'covered by' 
was a relationship of Order to LongTermContract, I think that
would do the trick.  The shipments already have the 'fulfill'
relationship to their Orders.

I have doubts whether long relationships like LongTermContract
and the resulting Orders and their resulting Shipments should be
contained in the same BusinessCollaboration.  That seems unwieldy,
and so maybe the BusinessCollaborations and BusinessTransactions
should just handle one shorter part of the long process, like
forming one Contract, placing one Order, sending one Shipment,
and the relationships between Contract, Order and Shipment
should be managed by those objects themselves. 

>If we then find a way to tie the economic events and obligations
>relative to economic resources tighter to the contract and business
>transaction, then we have what I was seeking earlier, a tighter
>integration of REA to the process model.

The current metamodel connects economic events
and contracts via the 'fulfill' relationship.  Economic resources
and events are tied by the 'resource flow' relationship.
There need to be ties between Contract and Economic
Resource Type and optionally Economic Resource.
REA's tie between  Contract and Economic Resource
is called 'reserves'.
The tie between Contract and Economic Resource Type
might be 'specifies'.
There is a tie between BusinessTransaction and BusinessEvent
in the current metamodel that is not named yet, that would be 
inherited by Economic Event.

>Will this work for you?

The scenario works for me, but not the subtype of BusinessTransaction
or having that subtype carry the 'TransactedWithinTheBoundsOf'  
relationship.  I think the relationship should be contract-to-contract,
and the series of exchanges involved in forming one contract might 
be covered by a BusinessCollaboration.  
The longer relationships of contract to contract could be 
managed by the contracts.  

But I await the reality check of actual implementations...
they could easily change my mind.

Regards,
Bob Haugen