RE: Syntax Free Models

[Bob Haugen <linkage@interaccess.com>]

(This is almost a repeat message - I left Martin Bryan's name off
the last one, and wanted to make clear who was the other author.
There is a historical record being built here, and it could get pretty
confusing who wrote what when...)

>Bob Haugen:
>> If you look at the REA ontology which I described for the ebXML BP
>> group at http://homepage.interaccess.com/~linkage/REA4ebXML.htm,
>> you will find three layers of classes:
>> * Type, or knowledge infrastructure
>> * Commitment, or operational plans and agreements
>> * Event, or actual consumption, production and transfer of resources.

Martin Bryan:
>REA is at a much higher level in the modelling than I am trying to work at.

Or less detailed, which I think is more the case.  As stated before,
REA is designed to be a minimal model that can be extended as
required in different contexts.

The reason for posing the Type, Commitment and Event levels is
that it was not always clear which level you were talking about,
and it seemed to me to be a good way to clarify concepts -
as it helps to distinguish class from instance in object modeling.

>What I'm looking at is the relationships between various information units
>that make up one or more of the messages sent between two REA commitment
>processes. (Your model does not seem to go low enough to show such
>relationships.) If I read you right Commitments are records of agreed
>Events. 

Commitments are records of agreement on events that are supposed
to happen in the future.
I concur that your information units are about the messages 
involved in commitments.  Your process chains are are something
else again - a mixture of material and info flows.

>Types seem to be something that aggregates Commitments, but I can't
>work out how this generalization works at present.

Types are (as the name implies) metadata, or the types of objects
that live in the Commitment or Event levels.  For example, 
CommitmentType might be Purchase or Sale or ProductionSchedule -
or more concretely, the type of Purchasing agreement used by
Ford when it buys oxygen sensors from Bosch.  An instance
of that type would govern such purchases.

Your process chains to be working at the Type level, if I understood
correctly.  They were normative descriptions, not instances of
commitments or events.

>> The process chains you describe might live at the highest Type level,
>> as generic scripts for process chains across companies.

>The process chains I was looking at were of a type that I don't seem to see
>covered in your models. What I am looking for, but do not see is the "Event
>A must be followed by Event B before Event C can take place". (Maybe this is
>what your first figure is trying to represent.)

I'm working on a supply chain diagram that expresses those relationships
in terms of the REA ontology concepts. I'll post it by tomorrow morning.

> At present you seem to be
>working in A-B mode, without allowing for A-C type dependencies. (I suspect
>this is due to the simplification of your summary and the use of two
>dimensional diagrams. My simplified listings suffer from the same problem.)

It was "simplification of summary". See supply chain diagram tomorrow.

>> But the process chains you describe are analogous to manufacturing
>> routings, spread out across multiple companies (an idea I heartily
>> endorse).

>To me messages must be designed first to work across multiple company
>scenarios. If they work here they will normally also work intracompany.

You're singing my song!  I agree wholeheartedly!
Single-company models don't often work for multi-company collaboration.

>>And routings vary by product:  e.g. some products may be
>> go through distribution centers, some delivered directly from
>> manufacture to retail or customer.

>Agreed. Each scenario needs a variant of the messaging sequence (as opposed
>to the information sequence, which can be invariant. (This clarifies
>something I need to do - introduce a clarification between messaging
>sequence and information sequence: they are not the same.)

I think I understand and agree, but will wait for the clarification.
(Please point it out in case I miss it.)

>> Likewise at the commitment level, when operational plans are made,
>> for example replenishing retail stocks based on point of sale events:
>> the demand flow travels backward along the process chain for the
>> product-to-be-replenished until it (possibly) hits some inventory-on-hand
>> sufficient to satisfy the demand - possibly at a distribution center.
>> In this case, the replenishment process chain starts at the
>> distribution center.

>> You may have these levels of variation in  mind as well.
>> I'd be interested to know.

Did you answer this question and I missed it?

>> On another topic, I am still having difficulty believing the message
>> interactions.  I think one problem is the mixing up of material flow
>> processes with message-interaction processes.  For example,
>> the same material flow process (e.g. manufacture-distribute-retail)
>> might be use a variety of message conversations, depending on
>> any number of variations in the situation.

>I would hope so, but I would also expect those messages to share core
>components.

Agreed.  Overall, I think the plan of core components that can be
assembled flexibly as the situation requires is a workable plan.
We'll see in real ebXML life, of course, but that is what I do for
a living and so I believe from experience that it works.

>> I do not think it is wise
>> to mix the two.  In particular, the material flow processes do form
>> chains, the message conversations go back-and-forth usually
>> between two stations in the material process chain.

>What is important to me is the order in which the messages are exchanged
>(the A before B before C scenario), rather than the fact that they are
>shared by two stations.

This statement is an example of mixing the message sequence
with the material-flow sequence.  My supply chain diagram, for
example, will deal with A-B-C in terms of material flows.  REA
has not gotten to the message sequence details, and I doubt
that it ever will.  In my business practice, I need to deal with
message sequences, but will probably happy to follow your
lead on that.

>> the state tells the next processing
>> agent what needs to happen next, without getting into the
>> details of the previous process inside some other company.

>Does it tell you "what needs to happen next" or "what set of information the
>processor expects to get before performing any further actions"? (You can
>tell I am a information flow modeller, not a process engineer!)

Well, I did not state that very clearly.  The collaborating process
agents need to agree on the state names that they will use
to collaborate.  That is much simpler than agreeing on internal
processes.  When one processing agent gets something with
an agreed state name from another, the processing agent
can determine from the state name what to do next.  But
the state name does not directly tell that, it just gets 
mapped to something in the internal systems of the
processing agent.

And I am speaking of material flow, not information flow.
I work with both, but usually focus on modeling resource
flows and their accompanying info flows, rather than any
other kind of info flows, which do not interest me as much.

Thanks for the interesting discussion (as always),
Bob Haugen