!! Introduction
There seem to be four kinds of orderings of the events in an Orc execution: causal (<_c), execution (<_ex), real time (<_r) and virtual time (<_v) ordering.

!! Causal Ordering <_c
The intuition behind the causality relation e <_c e'  is that event e, in some way,  ''causes'' the event e' to happen. There is usually a flow of control or data from e to e'. The causality relation is a partial order. Concurrent events are causally unrelated. There seem to be two sources of causality in Orc:

__i). Causality ''internal'' to Orc:__
This is defined by the semantics of the Orc operators and site calls. Site calls are strict. So in a site call S(x), the events that define the value x causally precede the call to S(x). In f | g, there is no (direct) causal dependencies between the events of f and g. In f >x> g, a publication event in f causally precedes all the events in the new instance of g. In f<x< g, a publication in g causally precedes calls to sites in f with x as a parameter. In f ; g, all the halt events in f cause the execution of events in g. 
  This is a static relationship, which can be derived from the structure of an Orc program, as done in the event structure semantics paper (which did not consider the ; operator however). 

__ii). Causality imposed by sites:__
Sites in Orc can maintain state and are not purely functional. This can impose additional causalities between events. For example in the program c.get() | c.put(v), the call event to c.put(v) causally precedes the return event of the call to c.get().
The event structure semantics does not capture these causalities imposed by sites. We need a mechanism to express and capture these dependencies in Orc. This might be possible by letting a site specify its causal behaviour in some way.
   Note that if all the sites in an Orc program were purely functional, then the previous (static) causality would entirely capture the causal relationship between the execution events. 

!! Execution Ordering <_ex
The execution ordering extends the causal ordering to account for orderings imposed by architectural constraints. For e.g. in any execution of c.put(v1) | c.put(v2), the two puts on channel c have to be sequenced in some order. These puts however, are not causally dependent as in the previous sense, because they can occur in any order. This is the ''[happens before|http://en.wikipedia.org/wiki/Happened-before]'' relation defined by Lamport. Like <_c, <_ex is also a partial order.

The following axiom holds:
 e <_c e' => e <_ex e'. 

!! Real time Ordering <_r
This is the natural, total order imposed by physical time. We clearly have the axiom:
e <_ex e' =>  e \leq_r e'

!! Virtual time Ordering <_v
The central axiom here also is:
e <_ex e' =>  e \leq_v e'