RE: Syntax Free Models

[Bob Haugen <linkage@interaccess.com>]

Bob Haugen:
>> Commitments are records of agreement on events that are supposed
>> to happen in the future.

Martin Bryan:
>Interesting you should stress the future. A message normally implies a
>future event, but the timescale is undefined. You seem to be talking about
>something (a commitment) that is within, for example, a 1 day to 1year time
>frame, whereas the general case is within a 1sec to 1 century time frame.

Not really,  could be 1 second.  My point is that a commitment
only makes sense for economc events that have not happened.  
Economic events can also happen without prior commitments,
of course.

It might help to reiterate what REA means by economic events:
only actual increments and decrements of economic resources,
that is, consumption, production or transfer of ownership.
Messages that send purchase orders, for example, are
commitments in the REA ontology, not economic events.

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

>I am in the process of splitting these two out. Later today I'll post a
>revised version at http://www.sgml.u-net.com/neutral.htm. 

Good, I'll look for it.  I am on the road for a couple of days,
and so will not reply again until the weekend.

>What is important
>though is that material flows (processes) are triggered by info flows
>(messages)

I agree.

>The question of direction of message travel is to me irrelevant.
>The point is that there is an event that generates a message that triggers
>another event that .... Whether the first event starts in company A and ends
>in company B, or vice versa, is irrelevant. 

I don't understand that perspective.  Maybe we just need to agree
to disagree on this point, and see how it works out as ebXML
evolves.

>My message name and your state name seem to coincide. The question is should
>the name be that of the state that generated the message or that the message
>is designed to trigger. As the state to be triggered can vary from scenario
>to scenario my preference is to record the name of the state that generated
>the message, and then for "listening event processors" to identify that that
>type of message is one that they can use to trigger an event.

I think we are in agreement here.

Thanks again,
Bob Haugen