Difference between revisions of "FirstManifestation"
(Created page with "{{Class Definition |Subclass Of=Manifestation |Description=The class FirstManifestation denotes the first manifestation of an individual. No prior manifestations (in time) exi...") |
|||
(15 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{Class Definition | {{Class Definition | ||
+ | |Pattern Of=Ptest | ||
|Subclass Of=Manifestation | |Subclass Of=Manifestation | ||
− | |Description=The class FirstManifestation denotes the first manifestation of an individual. No prior manifestations (in time) exist for the individual. | + | |Description=The class FirstManifestation denotes the first manifestation of an individual. No prior manifestations (in time) exist for the individual. It is a subclassOf Manifestation and contains the following additional properties: |
+ | * precedesManifestation: identifies all subsequent Manifestations that follow a First Manifestation. In other words, the First Manifestation is related to each and every subsequent manifestation via the precedesManifestation. | ||
+ | * hastLastManifestation: identifies the most recent Manifestation that is related to a particular FirstManifestation (i.e., for some snapshot of an object, it identifies the most recent 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 | ||
+ | |Interface Specification References=ISO 5087-1 City data model — Part 1: Foundation level concepts | ||
|Definition Status=Pending Approval | |Definition Status=Pending Approval | ||
− | |||
}} | }} | ||
{{Annotation Specification}} | {{Annotation Specification}} | ||
{{Manchester Specification | {{Manchester Specification | ||
|Manchester Row={{Manchester Row | |Manchester Row={{Manchester Row | ||
+ | |Property=HasLastManifestation | ||
+ | |Restriction=exactly 1 | ||
+ | |Value=Manifestation | ||
+ | }}{{Manchester Row | ||
|Property=PrecedesManifestation | |Property=PrecedesManifestation | ||
|Restriction=only | |Restriction=only | ||
− | |Value=Manifestation | + | |Value=Manifestation and not (FirstManifestation) |
+ | }} | ||
+ | }} | ||
+ | {{Supplementary Figures | ||
+ | |Figure Row={{Figure Row | ||
+ | |Figure=Atemporal rep.png | ||
+ | |Caption=Figure 1: An atemporal representation. | ||
+ | }}{{Figure Row | ||
+ | |Figure=Change-fig-2.png | ||
+ | |Caption=Figure 2: Introducing the change ontology. | ||
+ | }}{{Figure Row | ||
+ | |Figure=Change-fig-3.png | ||
+ | |Caption=Figure 3: Adapting existing instances. | ||
+ | }}{{Figure Row | ||
+ | |Figure=Change-fig-4.png | ||
+ | |Caption=Figure 4: Asserting new instances. | ||
}} | }} | ||
}} | }} | ||
− |
Latest revision as of 04:45, 28 September 2021
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?).
The class FirstManifestation denotes the first manifestation of an individual. No prior manifestations (in time) exist for the individual. It is a subclassOf Manifestation and contains the following additional properties:
- precedesManifestation: identifies all subsequent Manifestations that follow a First Manifestation. In other words, the First Manifestation is related to each and every subsequent manifestation via the precedesManifestation.
- hastLastManifestation: identifies the most recent Manifestation that is related to a particular FirstManifestation (i.e., for some snapshot of an object, it identifies the most recent 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?
Interface Specification References
This class has been associated with the following interface specification items: ISO 5087-1 City data model — Part 1: Foundation level concepts
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 |
---|---|
Figure 1: An atemporal representation. | |
Figure 2: Introducing the change ontology. | |
Figure 3: Adapting existing instances. | |
Figure 4: Asserting new instances. |