RE: Comments on process MetaModel

[Bob Haugen <linkage@interaccess.com>]

Cory Casanave wrote:
>I also wonder if the assertion is that every EbXml interaction is a
>realization of the REA model or that the REA model is one potential set of
>core related roles.  We may have a buy-in problems if we attempt to impose
>the REA view on existing processes (To intrusive on "business modeling"). 

No, nobody is asserting that every ebXML interaction is a realization
of the REA model.  The REA model only applies to economic 
exchanges and their contractual commitments.  However,
those are the main processes of business and thus the 
reason-for-being of ebXML - otherwise it's just generic data transfers.  

There are important aspects of electronic commerce
that cannot be modeled without their business semantics.
For example, one of the main focuses of RosettaNet,
the source for a lot of the interaction aspects of the metamodel,
was adherence the rules for legal contract formation over
the Internet.  And one of the main focuses of REA is
that economic exchanges have long processes 
where individual data transfers have relationships to
one another -for example, the exchange is not finished
until the consideration is received.

These long-process considerations can be ignored
in standalone data transfers.  But if you look at the 
auto component procurement example, how would 
you make sense of any element in isolation from
the whole long process?

>We may have a buy-in problems if we attempt to impose
>the REA view on existing processes (To intrusive on "business modeling"). 

REA intends to be a distillation of existing economic exchange and 
transformation processes.  (Only the exchanges are part of the
ebXML metamodel as it stands today.)

Do you have any examples of such processes that the REA model 
would *not* fit? If so, the business domain part of the ebXML 
metamodel and probably also the REA ontology should be changed.

(However, to be explicit, nobody is saying that any business process
whether new or existing needs to use every class and
relationship in the metamodel.)

>On
>the other hand, I do find the REA framework to be excellent as an abstract
>framework on which to build a new self-consistent set of protocols.

And so do I. But it is also intended as a framework into which existing
protocols can fit.  For example, "Contract" applies to any kind
of prior commitment that future economic events will happen -
Purchase Orders would be a form of Contract.  ("Contract"
is not the REA term, by the way - REA uses "Commitment",
but the semantics are equivalent and Contract resonated
better with the metamodel work group as a whole.
Nor is the whole REA ontology included in the metamodel -
only those parts that the whole work group found to be
necessary for external business exchanges.)

The metamodel certainly contains different aspects that can be
partitioned, but if you look at the use cases identified in the 
workshop, only one was focused on data transfer.

Another critical use is as abstractions for core components -
but that does not necessarily mean to delete stuff from the
metamodel and say "these are core components". 
The REA classes are more like the abstract superclasses
that core components can be subclassed from, but then
that is true for all the other parts of the metamodel, too.

>Could there not be non-financial business interactions 
>(or at least those we do not want to think about in that way)?

Yes, for example the Business Event class in the metamodel
represents many kinds of business interactions; Economic
Events (part of REA) are a constrained subset of Business Events.

>So, would not the elements of the business framework - such as partner,
>contract and economic resource be the "core components" that are instances
>of the first Meta model and would be specialized for specific processes?
[...]
>If so, the Meta model for the interaction would be much simpler as just the
>"core" and the REI framework would have a clear relationship with this Meta
>model - it would be an instance of it.

The partner and REA sections of the metamodel have their own semantics
that are not captured by the technical interaction part.  They use each
other, but are not instances of each other.  None of them make much
sense as standalones if the problem domain is business processes 
as opposed to generic data exchange processes.

As I noted above, a lot of the interaction part of the metamodel was 
designed to cope with legal contract formation, so even in the part 
you are nominating as "core" there is business semantics.

This has been one of the ongoing arguments over the metamodel:
whether it should contain any business semantics, or just be a
generic data transfer model.  The ongoing resolution has been
that some business semantics are necessary.

Regards,
Bob Haugen