The amount of data is vast (10**9 events/year) and so most of the data is held in persistent storage. We make the immediate simplification that the data is immutable, i.e. once written to disk the data do not change. However, an event may grow with time as more algorithms are run and more data is produced.
Here I would like to limit the scope of the event model to be the methods by which users access event data. How does a user identify an event and then how is that identifier used to read existing data or write new data? More generally, how do users identify a collection of events and read and write to each?
I will try to exclude the persistence mechanism from the discussion. Of course data will have to be put in a form suitable for persistence and so the discussion here is limited to ensuring that the event data interface is consistent with any requirements of the persistence mechanism. I note that ATLAS present plan is to use StoreGate (ref?).
I also exclude details of what is stored and how it is arranged i.e. the content of raw data, clusters, tracks, jets and physics objects. This is the data model. The persistency mechanism will likely place constraints on the format of the data. The event model may add to these constraints but must be flexible enough to meet the requirements of the data model. In particular the event model (in conjunction with the persistence mechanism) must allow data objects to reference one another in a persistent manner.
Similarly the details of the algorithms are not discussed here. These are primary (but not the only) event users and so their interface depends on the event model. Any event access code duplicated between different algorithms likely belongs in the event model or data model.
Another important piece that is not considered here is the control framework. This allows users to specify the algorithms and their input data. It is a manager that fetches the input data, runs the algorithms and writes out the generated data. Again this is a user of the event model. ATLAS plans to use the athena framework.
The lines between all the above systems (event model, persistency, data model, algorithms and framework) are not easily drawn but it is important to make this division of responsibilities. In the future we will add new data and algorithms and may replace the the persistency mechanism or framework. If the divisions have been made correctly and the interfaces defined with sufficient foresight, there will be minimal impact on the event model and other systems.