Difference between revisions of "FirstManifestation"

From City Data Model Project Collaboratory
Jump to navigation Jump to search
Line 43: Line 43:
 
{{Supplementary Figures
 
{{Supplementary Figures
 
|Figure Row={{Figure Row
 
|Figure Row={{Figure Row
|Figure=atemporal rep
+
|Figure=Atemporal rep.png
 
|Caption=Figure 1: An atemporal representation.
 
|Caption=Figure 1: An atemporal representation.
 
}}{{Figure Row
 
}}{{Figure Row

Revision as of 21:56, 3 July 2021


Pattern

This class has been associated with the following pattern:

Pattern:Change Pattern

Subclass Of

Manifestation

Description

An English description of the definition (what distinguishes this sense of the term?).

The class FirstManifestation denotes the first manifestation of an individual. No prior manifestations (in time) exist for the individual.

Class Diagram Description

Figure 1 illustrates a simple representation of objects that does not account for changes over time. The veh_123 object is an instance of Vehicle that represents an individual vehicle. It has a model, model_x, an owner, alice, and a location, represented by the object loc_1. No changes to veh_123 are expressible with this representation. For example, any change to the associated location (via the hasLocation property) would be captured with a rewrite of the statement about veh_123. In this approach it is not possible to state that the value was loc_1 and is now loc_2. This representation supports a single “snapshot” of objects in its domain.

The default (atemporal) approach exemplified by the Vehicle class, may be adapted to a temporal approach (one that represents objects potentially changing over time) by introducing a relationship with the classes Manifestation, FirstManifestation, and owl:TemporalEntity) as follows:

- Step 1: Introduce classes "Manifestation" and "FirstManifestation". The class that will have a temporal representation (possibly changing properties) should be defined as a subclass of Manifestation. In this case (Figure 2), Vehicle is defined as a subclass of Manifestation. This means that any instances of Vehicle are now interpreted as snapshots of an object in time. Several different instances of Vehicle refer to the same object at different points in time.

Next we have to distinguish between invariant and variant properties.A consequence of Step 1 is that all of the property constraints that were associated with Vehicle are now interpreted as "time variant". In other words, the restrictions only apply at instants/intervals in time (to individual snapshots), so the values of these properties may change over time. In this particular example, the model of a Vehicle is invariant whereas the other two properties are not. It does not matter that the location will likely vary with much greater frequency than the owner of the vehicle (which may not vary at all). Both are interpreted as invariant properties, and any snapshot of the vehicle will allow for changes to either. The property hasModel will be annotated in the Vehicle class as an invariant property.

- Step 2: distinguish between invariant and variant properties for the class that will have a temporal representation. At minimum, this must be done by annotating the invariant property with the annotation 5087-1:hasInvariantProperty with a value of hasModel.

Existing instances of Vehicle are interpreted as representing the state of an Vehicle at some Instant or Interval in time, therefore as shown in Figure 3, an additional assertion should be made as to what TemporalEntity each Vehicle individual exists at.

Now that Vehicle is a subclass of Manifestation, each instance of Vehicle inherits the property ‘existsAt’. A temporal value, either an Instant or Interval, can be specified for which the individual is a temporal snapshot of.

- Step 3: assert an applicable TemporalEntity for which the instance is valid, for the existsAt property,. Implicitly, all existing instances of Vehicle are now the first manifestation in a possible series of changing snapshots.

At this point all instances of Vehicle represent separate vehicles, and are the first manifestation of the instance. To reflect this, we make each of the instances have the type FirstManifestation to reflect it is the first temporal snapshot of what are to be many snapshots for each instance.

- Step 4: assert all instances to be of type FirstManifestation (Figure 3).

With these revisions complete, subsequent instances may be asserted to describe changes that occur to a particular object over time. Each new snapshot of an instance, i.e., manifestation, will also be associated with a TemporalEntity. In addition, the first instance (manifestation) will be associated with all future instances via the precedesManifestation property. All instances will be related to any subsequent instance with the hasNextManifestation property. Examples of the assertion of subsequent instances are illustrated in Figure 4.

- Step 5: The initial, FirstManifestation instance will be related to all subsequent manifestations of an object via the precedesManifestation property.

- Step 6: Each manifestation will be related to its following manifestation (i.e., the instance representing the next change to the object) via the hasNextManifestation property. - Step 7: Each manifestation will be related to the first manifestation via the hasFirstManifestation property

Required by Use Case(s)

(why is this specialized definition needed?)


CDM References

What other classes or properties reference this term?

Interface Specification References

This class has been associated with the following interface specification items:


Sources

Sources considered when developing the class:


Status

Pending Approval

Has Subclass(es)



Annotations

Annotation Value


Manchester Syntax Specification

Property Restriction Value
HasLastManifestation exactly 1 Manifestation
PrecedesManifestation only Manifestation and not (FirstManifestation)


Supplementary Figures

Figure Caption
Atemporal rep.png
Figure 1: An atemporal representation.
Change-fig-2.png
Figure 2: Introducing the change ontology.
Change-fig-3.png
Figure 3: Adapting existing instances.
Change-fig-4.png
Figure 4: Asserting new instances.