Re: Syntax Free Models

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Bob

>However, in operation, the process chains
> are even more variable than that: they vary by individual product and
> even by individual event.

Agreed.

> 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.

REA is at a much higher level in the modelling than I am trying to work at.
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. Types seem to be something that aggregates Commitments, but I can't
work out how this generalization works at present.

> 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.) 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.)
>
> 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.

>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.)

> 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.
>
> 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.

> 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.

> >I still have doubts about the relevance of using state to record the
> >relationship between information units, as [Keith Finkelde] propound[ed].
>
> Keith and I may have different ideas about state in this context -
> mine comes from material flow processes, Keith's comes from
> workflow.  But my idea would be similar to the name of the
> last material flow process the material went through.

I can buy this.

>That
> is an oversimplification, because the state might be something
> like "off spec", too.  But 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!)

Martin