Introducing TemporalFeature, as a subclass to time:TemporalEntity and time:TemporalDuration, is a most interesting move.
The way it is (or is not) used raises questions.
In the case of topology: only Navigability has a property era:validity with range era:TemporalFeature. This should also apply to net elements (topology is not frozen for all times, and handling successive versions from inside the model is recommended). Maybe a common superclass for both NetElement and Navigability would make sense; it could be TopologicalObject provided that the locations are managed independently from topology (see other issue).
In the case of technical characteristics: you use era:Applicability as a subclass to establish a relationship between an infra object and its technical characteristics. This is broadly correct, and expresses the fact that a technical characteristic may be time-dependent. But, getting into more detail:
era:TechnicalCharacteristic in the diagram seems to be era:TechnicalCharacteristics in the model (a container class, so to say).
what varies with time is, usually, the value of the characteristics
Bottom line, won't it be more appropriate to subclass characteristics values from TemporalFeature?
The packaging of characteristics is well in line with yearly RINF releases, but if update frequency changes to daily, that bundling may become a burden.
Introducing TemporalFeature, as a subclass to time:TemporalEntity and time:TemporalDuration, is a most interesting move.
The way it is (or is not) used raises questions.
In the case of topology: only Navigability has a property era:validity with range era:TemporalFeature. This should also apply to net elements (topology is not frozen for all times, and handling successive versions from inside the model is recommended). Maybe a common superclass for both NetElement and Navigability would make sense; it could be TopologicalObject provided that the locations are managed independently from topology (see other issue).
In the case of technical characteristics: you use era:Applicability as a subclass to establish a relationship between an infra object and its technical characteristics. This is broadly correct, and expresses the fact that a technical characteristic may be time-dependent. But, getting into more detail:
The packaging of characteristics is well in line with yearly RINF releases, but if update frequency changes to daily, that bundling may become a burden.