FRAGMOS - Structured Products - Child Story 1.2. - ObservationBasis 2 : ObservationConditions

[JBZ-Fragmos]

OVERVIEW

ObservationConditions is designed to represent "HOW" an item represented in CDM is observed in all meaning of the word "how" e.g. in terms of aggregation if multiple values, in terms of data source, time of observation, determination method, etc.

Thehere are two kinds of model components to which ObservationConditions may relate to :

• either an ObservableValue (as described in ), thus as part of an ObservationBasis, as below

• else, any other object to which ObservationConditions may be attached to, mainly when multiple instances exist so the aggregation method shall be specified and it is an attribute of ObservationConditions, so this type would be re-used in such place, though with another label name, say "multiple[XXX]AggregationFeatures" where "[XXX]" referes to the name of the main multiple item at stake - see an example below in a node where multiple instance of "[return]" may exist :

CDM TYPE DESCRIPTION

• observation dates are described with two types of dates : (a) obervationPeriods or (b) observationDates ; else both types may be used together as described below (c) :
  (a) observationPeriods permits to define the parameters for building a schedule of periods i.e. segments in series, each made of a pair : period start observation date ; period end observation date
  (b) observationDates permits either to define observation dates in alternate way i.e. as a list of individual dates (instead of periods) explicit lists of dates as dates in series, that being alternate way to define observation,
  (c) else, given observationPeriods, then the particular observationDates component relativeDates->dateIsRaltiveToEnum (further described in FRAGMOS * whole Model benefit + required for Struct * - Enum type refactoring 2 - DateIsRelativeToEnum #2523) can be used to specify which date to refer to for anchoring e.g. each Observation Date, etc.

• aggregatedFeatures are described in FRAGMOS - Structured Products - Child Story 3 - AggregationFeatures #2498

• cumulativeObservationConditions are of same type being nested as an attribute, that is for the purpose of representing successive sets of observations also with ensuring priority order for resolving purposes is properly described i.e. which is actually represented by considering the nesting series of cumulativeObservationConditions as playing same role that parenthesis are playing in standard algebra e.g. say ObsB is nested in ObsA i.e. ObsB is the "cumulative" attribute of ObsA, then this is equivalent to " ObsA**(ObsB)** " (As an information, there is a detailed example of business case using "cumulative" attribute, inside previous item Child Story above mentioned for aggregatedFeatures)

• remaining set of attributes is straightforward e.g. determinationMethod, source, etc.

[jiahaodengbb]

For the observationDates, just want to confirm the behavior of case (c) when both observationPeriods and observationDates are used. Is it right that the observationPeriods will be treated as anchor and the dateIsRelativeTo will be applied against every date in the observationPeriods?

[jiahaodengbb]

Could you clarify a little more about the cumulativeObservationConditions? I didn't understand " ObsA**(ObsB)** "

say ObsB is nested in ObsA i.e. ObsB is the "cumulative" attribute of ObsA, then this is equivalent to " ObsA**(ObsB)** "

[JBZ-Fragmos]

any item related to this Issue is either closed or re-open under this one :
#2941