Manifestation
Pattern
This class has been associated with the following pattern:
Subclass Of
Description
An English description of the definition (what distinguishes this sense of the term?).
Many of the concepts identified in the urban system ontologies are subject to change. For example, a Vehicle will have one location at one time, and another location at a later time; it may have only one passenger at one time, and four passengers at a later time. Similarly, many attributes of Persons, Households, and even Transportation Networks are subject to change. Change over time plays a role in many domains and is by no means a new research topic. In fact, several approaches for capturing change in OWL have been proposed. Despite these solutions, we have found that Semantic Web practitioners currently lack clear and precise methods for how to apply these approaches to capture change at a domain level, whether reusing an atemporal ontology or developing an ontology from scratch. The Change Pattern serves as a clear guide to support a consistent approach to representing change over time. Manifestations may be interpreted as “snapshots” of an object at some point in time. This enables the representation of changing attributes of an object, without losing information about its past values/relationships. The properties of the class can then be identified as properties that are (and aren't) subject to change, in order to distinguish between the static and dynamic aspects of a particular entity. The Manifestation class is defined using the following properties: • existsAt: identifies the TemporalEntity that reflects the time Instant of Interval during which the snapshot of the object holds (is valid). • hasNextManifestation: identifies the immediate successor Manifestation (i.e., the subsequent snapshot of the object). • hasPreviousManifestation: identifies the immediate prior Manifestation (i.e., the prior snapshot of the object). • hasFirstManifestation: identifies the First Manifestation that is related to a particular Manifestation (i.e., for some snapshot of an object, it identifies the first such snapshot of the object).
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?
- Tpso:Arc (← links)
- FirstManifestation (← links)
- ManifestationState (← links)
- ISO5087-1:Allocation (← links)
- ISO5087-2:Building (← links)
- ISO5087-2:BuildingUnit (← links)
- LandArea (← links)
- Person (← links)
- Family (← links)
- Household (← links)
- ISO5087-2:BusinessEstablishment (← links)
- Occupation (← links)
- Pattern:Change Pattern (← links)
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 |
|---|---|---|
| ExistsAt | exactly 1 | time:TemporalEntity |
| HasNextManifestation | max 1 | Manifestation |
| HasPreviousManifestation | max 1 | Manifestation |
| HasFirstManifestation | max 1 | Manifestation |
Supplementary Figures
| Figure | Caption |
|---|---|
| Figure 1: An atemporal representation. | |
| Figure 2: Introducing the change ontology. | |
| Figure 3: Adapting existing instances. | |
| Figure 4: Asserting new instances. |
