metaABM Acts

The next diagram depicts the most novel part of the metaABM system, "Acts". (Click on diagram to zoom in.)

Acts are a key aspect of the metaABM representational scheme, as they allow the definition of arbitrary but high level behavior for agents. They are also conceptually more challenging as unlike the metaABM structure they have no direct analogies to past agent representation approaches. But a few basic ideas should clarify matters. Again, we are omitting the 'A' part of each meta-object name from the description below.

All of the above meta-objects except Input, Literal, and the enumerators (lists of options) are Acts. Blue Acts are concrete (you can create and use them directly). Red indicates a key Act meta-object feature.
An Act is anything that might happen during the execution of an Agent-Based Model.
Acts are targets and sources of one another, but an Act can never have itself as a source. (That is, Acts are acyclic, but branches can re-converge. When we refer to an Act source or target, we typically mean to include all ancestors or descendants, not just the immediately connected Act.)
Acts reference an Select, referred to as the "selected" relation. An Select represents the model aspects that the Act is working within; that is, the spatial, temporal and type (agent) "world" that is currently being selected.
Commands trigger some model state change (ASet) or spatial transformation (ATransform).
Transforms also specify a "destination" Select. This represents aspects that the selected agent(s) will transform to. For example, an Move may use an Rule to select all SugarAgents (type) in the SugarGrid (space) every period (time) and move them to a destination of a neighboring SugarCell (type) in the SugarGrid (space, with time implicit).
All Acts have as their root-most source Act an Root. These are added first to any agent behavior and act as triggers for all target behavior. For example, an Watch will fire (execute) any time the watched attribute is modified. (As the diagrams do not refer to elements outside of the current package, we cannot see here that Accessor includes a reference to some SAttribute, but it does. To see these kinds of relationships you will want to refer to the metaabm.ecore file itself.)
Sinks are Acts which use some FFunction (see next section) to interpret state in the form of Inputs. Inputs can come from selected agent attributes, other Acts, or literal values.
Controls determine wether target acts are executed and against what agents. They are in some sense query terms.

Future documentation will discuss the ideas behind the metaABM Act approach in greater detail, but in brief, the system can be thought of as a very high-level quasi-declarative query and transformation language. As we define metaABM itself through another meta-model (a meta-meta-model!) we leave typical language features such as syntax undefined. Here we are only interested in the core of what can and cannot be done with the language and leave specific implementation flavors up to implementations.