A flexible navigation in time requires to 1) select a specific version of a model element and 2) a time-relative navigation concept for traversing the temporal data model.
4.4.1
Selecting model element versions
Based on the idea that it is necessary for intelligent systems to consider not only the current context but also historical data to correlate or investigate potential causalities between two phenomena, we provide means to enable an efficient navigation into time. Therefore, we define three basic operations, which can be called on each model element:
• The shift operation is the main possibility to navigate a model element through time. It takes a timestamp as parameter, looks for the context element version of itself, which is valid at the required timestamp, loads the corresponding ver- sion of the element from storage (can be main memory) and returns the loaded version. Due to the definition of a continuous validity of model elements, the shift operation always returns a valid version, i.e., the last version relative to the timestamp for which the shift operation was called.
• The previous operation is a shortcut to retrieve the direct predecessor (in terms of time) of the current context element.
• The next method is similar to the previous operation but retrieves the direct successor of the current context element.
These operations allow to shift context elements, independently from each other, through time.
4.4.2
Time-relative navigation
Traversing an object graph composed of elements from different timestamps is complex, since a relationship r from an element me1 to an element me2 is no longer uniquely
defined. Thus, the navigation between context elements cannot rely on relations (in space) only. Instead—depending on the timestamps t1 and t2 of me1 and me2, and
depending on the set of versions of me1 and me2—a relationship r from me1 to me2 can
link different versions of me2. This means, which version of me2 is related to me1 by r
depends on the timestamp t of me1. Processing this time-relative navigation manually
is complicated and error-prone. Therefore, we provide a concept to automatically resolve relationships, taking the time aspect into account, while traversing the context model. This time-relative resolution is completely transparent and hidden behind methods to navigate in the graph. Hereby, each context element is resolved relative to the time where the navigation is performed from.
smart meter id: 2 time: t1 consumption: 15 customers: [3] concentrators: [1] time customer id: 3 time: t1 meters: [2] concentrator id: 1 time: t1 meters: [2] t1 t2 smart meter id: 2 time: t2 consumption: 28 customers: [3] concentrators: [1] concentrator id: 1 time: t1 meters: [2] smart meter id: 2 time: t3 consumption: 83 customers: [3] concentrators: [1] concentrator id: 1 time: t1 meters: [2] t3 customer id: 3 time: t1 meters: [2] customer id: 3 time: t1 meters: [2] … …
Figure 4.4: Time-evolving context model
relationship r
c(t1): [t1, t∞)
concentrator smart meter
sm(t1): [t1, t2)
navigation context
sm(t2): [t2, t3) sm(t2): [t3, t ∞)
Figure 4.5: Time-relative navigation using a navigation context
Figure 4.4 shows a concrete example of a time evolving context model. The context is again represented as an object graph. As can be seen in the figure, the object graph consists of three different objects (context elements). The smart meter element evolves at t1, t2, and t3, all other objects remain unchanged. This leads to one version of the
concentrator and customer object and to three versions of the smart meter object. The different versions of the smart meter object differ in the consumption values and the timestamps. The relationship from the concentrator to the smart meter object is, therefore, not uniquely defined. Instead, traversing a temporal data model is thus only defined by two dimensions: space and time.
To cope with this problem, we define what we call a navigation context. Selecting or navigating context elements is always relative to a navigation context. The navigation context is either set globally before a context model is traversed, or is implicitly set when one of the basic temporal operations is used. If we consider again the example presented in Figure 4.4 and assume that the navigation context is set to a time ti, where
ti ≥ t2∧ < t3, navigating the context model from the concentrator to the smart meter
object would yield the latest valid version of the smart meter relative to the navigation context, which is the smart meter object with, id: 3, time: t2, and consumption: 28.
This time-relative navigation in context models is depicted in Figure 4.5.
Considering model elements in the context of a specific time interval creates a nav- igable time dimension for context models. This time-relative data resolution is one of the novel concepts of this contribution. Unlike in previous approaches (e.g., rela-
object id timestamp serialised object
key value
Figure 4.6: Key/value structure for time-relative storage
tionships in MOF [238] or predicates in RDF [217]), the navigation function is not constant but yields different results depending on the navigation context (i.e., the current observation timepoint).