# Union Models for Model Families: Efficient Reasoning over Space and Time
## 4 Spatio-Temporal Annotation Language (STAL)  
With an appropriate formalization of model families (as discussed in Section 3), the challenging part of constructing a union model is not necessarily in the union operation itself. Rather, the challenge is in being able to distinguish the models to which a particular element belongs. For example, in the goal model family shown in Figure 1, we need to distinguish that Fence rule 3 belongs only to aerodromes of TYPE 1 (i.e., configuration 1), Fence rule 2 belongs only to TYPE 2, etc. In addition, if there are common elements among all models (such as ACS rule 2) we need to indicate this in \(M_{U}\) in a precise and exploitable manner. To achieve this, we propose a _Spatio-Temporal Annotation Language (STAL)_ to annotate elements of each individual model with information about their versions and/or configurations in the form of \(<\)ver\({}_{\text{num}}\), conf\({}_{\text{info}}\)>, where ver\({}_{\text{num}}\) denotes the version number (time dimension) of a particular model (e.g., 1 st version, 2 nd version, etc. ), while conf\({}_{\text{info}}\) denotes space dimension-related information (e.g., organization type, size, location). In the time dimension, models can evolve independently and asynchronously over distinct timepoints. Because timepoints can be correlated and compared, they naturally form a chronological order. Considering this inherent chronological nature of models evolution, a sequence of versions of a particular model can be annotated with sequential version numbers: ver\({}_{1}\), ver\({}_{2}\),... ver\({}_{n}\). This creates an implicit temporal validity between model versions; for instance, we can say that ver\({}_{1}\) happened before ver\({}_{2}\). The timing information embedded in the \(<\)ver\({}_{\text{num}}\)> format in STAL can represent version numbers or dates, a hierarchical version numbering scheme (e.g., versions 2.3.1 and 4.3.2, etc. ), or ranges thereof. The space dimension, on the other hand, is different and somewhat more complex. This stems from the fact that the space dimension is flat and has neither a chronological order nor a hierarchical nature (except in very specific domains, such as in provinces and their cities). In STAL, we usually use the naming conventions confA, confB,..., confZ instead of conf1, confZ,..., confn to reflect the lack of ordering semantics. If a configuration is simple, we use its syntactical description as a name for that configuration. For example, confA=\"airports in Ontario\" and confB=\"airports in Quebec\" are the names of the two different configurations of airports. However, it is worth mentioning that information about configurations can be composite, i.e., it may consist of several pieces of information. For example, TYPE1 aerodromes may refer to those airports that are of medium-size, located in Ontario, and with national flights only. To represent this type of composite information in STAL in a way that keeps annotated models as simple as possible, we propose the use of look-up tables, and approach that provides mappings between configuration names and their real descriptions. Please note that, in this example, the numbering suffixes of TYPEs do not hold any ordering meanings; they are only descriptions of the configuration. Table 1 shows an example of a look-up table for the configurations in Figure 1.  
In addition, in a model family it is possible that one model element belongs to several or all family members; see the full STAL grammar in Appendix A. For instance, assume that there is a model family with one model configuration (confA) that evolves into five versions (i.e., \(\text{ver}_{1}\) to \(\text{ver}_{5}\)). Moreover, assume a node \(n\) that belongs to the five versions of that model. In this case, \(n\) will typically be annotated in the union model with five annotations: \(<\)ver\({}_{1}\), confA\(>\), \(<\)ver\({}_{2}\), confA\(>\), \(<\)ver\({}_{3}\), confA\(>\), \(<\)ver\({}_{4}\), confA\(>\), \(<\)ver\({}_{5}\), confA\(>\).