Changes for page Possible Ways of Implementing the Observation Status Concept
Last modified by Artur K. on 2026/05/29 14:28
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -4,9 +4,10 @@ 4 4 5 5 = Document History = 6 6 7 -|**Version**|**Date**|**Comment** 8 -|1.0|1/10/2014|Initial version 9 -|2.0|1/5/2019|Guideline title change (more accurate); add new OBS_STATUS codes to hierarchy; changed 3.1 approach to include OBS_STATUS code (this compatibility break is the major version change); text clarification; include a document history 7 +(% style="width:972.446px" %) 8 +|**Version**|**Date**|(% style="width:773px" %)**Comment** 9 +|1.0|1/10/2014|(% style="width:773px" %)Initial version 10 +|2.0|1/5/2019|(% style="width:773px" %)Guideline title change (more accurate); add new OBS_STATUS codes to hierarchy; changed 3.1 approach to include OBS_STATUS code (this compatibility break is the major version change); text clarification; include a document history 10 10 11 11 = 1) Introduction = 12 12 ... ... @@ -24,28 +24,29 @@ 24 24 25 25 Example: From now on, value x is compiled on the basis of a methodology diverging from the previous one (e.g. following an alignment with international standards), which generates a break in time series. However, the value in this period is suppressed, e.g. for confidentiality reasons. In this case, two flags, namely B (//Time series break//) and Q (missing value; suppressed), should be used. If only one flag is to be indicated, then use should be made of the hierarchy below to determine which flag to use. In this case, this would be B since B has precedence over Q in the hierarchy. 26 26 27 -|(% rowspan="2" %)**Observation status hierarchy**|(% colspan="2" %)**Relevant in conjunction with...** 28 -|**numeric values**|**missing values** 29 -|**B** / time series break (highest importance)|Yes|Yes 30 -|**O** / missing value| |Yes 31 -|**M** / missing value; data cannot exist| |Yes 32 -|**L** / missing value; data exist but were not collected| |Yes 33 -|**H** / missing value; holiday or weekend| |Yes 34 -|**Q** / missing value; suppressed| |Yes 35 -|**J** / derogation|Yes|Yes 36 -|**S** / strike and other special events|Yes|Yes 37 -|**D** / definition differs|Yes| 38 -|**K** / data included in another category| |Yes 39 -|**W** / Includes data from another category|Yes| 40 -|**I** / imputed value|Yes| 41 -|**F** / forecast value|Yes| 42 -|**E** / estimated value|Yes| 43 -|**P** / provisional value|Yes| 44 -|**N** / not significant|Yes| 45 -|**U** / low reliability|Yes| 46 -|**V** / unvalidated value|Yes| 47 -|**G** / experimental value|Yes| 48 -|**A** / normal value|Yes| 28 +(% style="width:1157.45px" %) 29 +|(% rowspan="2" style="width:512px" %)**Observation status hierarchy**|(% colspan="2" style="width:642px" %)**Relevant in conjunction with...** 30 +|(% style="width:281px" %)**numeric values**|(% style="width:361px" %)**missing values** 31 +|(% style="width:512px" %)**B** / time series break (highest importance)|(% style="width:281px" %)Yes|(% style="width:361px" %)Yes 32 +|(% style="width:512px" %)**O** / missing value|(% style="width:281px" %) |(% style="width:361px" %)Yes 33 +|(% style="width:512px" %)**M** / missing value; data cannot exist|(% style="width:281px" %) |(% style="width:361px" %)Yes 34 +|(% style="width:512px" %)**L** / missing value; data exist but were not collected|(% style="width:281px" %) |(% style="width:361px" %)Yes 35 +|(% style="width:512px" %)**H** / missing value; holiday or weekend|(% style="width:281px" %) |(% style="width:361px" %)Yes 36 +|(% style="width:512px" %)**Q** / missing value; suppressed|(% style="width:281px" %) |(% style="width:361px" %)Yes 37 +|(% style="width:512px" %)**J** / derogation|(% style="width:281px" %)Yes|(% style="width:361px" %)Yes 38 +|(% style="width:512px" %)**S** / strike and other special events|(% style="width:281px" %)Yes|(% style="width:361px" %)Yes 39 +|(% style="width:512px" %)**D** / definition differs|(% style="width:281px" %)Yes|(% style="width:361px" %) 40 +|(% style="width:512px" %)**K** / data included in another category|(% style="width:281px" %) |(% style="width:361px" %)Yes 41 +|(% style="width:512px" %)**W** / Includes data from another category|(% style="width:281px" %)Yes|(% style="width:361px" %) 42 +|(% style="width:512px" %)**I** / imputed value|(% style="width:281px" %)Yes|(% style="width:361px" %) 43 +|(% style="width:512px" %)**F** / forecast value|(% style="width:281px" %)Yes|(% style="width:361px" %) 44 +|(% style="width:512px" %)**E** / estimated value|(% style="width:281px" %)Yes|(% style="width:361px" %) 45 +|(% style="width:512px" %)**P** / provisional value|(% style="width:281px" %)Yes|(% style="width:361px" %) 46 +|(% style="width:512px" %)**N** / not significant|(% style="width:281px" %)Yes|(% style="width:361px" %) 47 +|(% style="width:512px" %)**U** / low reliability|(% style="width:281px" %)Yes|(% style="width:361px" %) 48 +|(% style="width:512px" %)**V** / unvalidated value|(% style="width:281px" %)Yes|(% style="width:361px" %) 49 +|(% style="width:512px" %)**G** / experimental value|(% style="width:281px" %)Yes|(% style="width:361px" %) 50 +|(% style="width:512px" %)**A** / normal value|(% style="width:281px" %)Yes|(% style="width:361px" %) 49 49 50 50 = 3) Multiple flagging = 51 51 ... ... @@ -89,16 +89,14 @@ 89 89 90 90 Although not recommended as the preferred solution, this approach can be implemented in cases where the general solution cannot be applied, or is not the appropriate solution, in a particular context. 91 91 92 - |(((94 +{{box}} 93 93 **Comments on the choice of the recommended solution** 94 94 95 -//Both "Decomposition" and "Duplication" options provide acceptable workarounds to the problem of multiple flagging, and appear to be quite similar in practice. The t//rade-off in this context was between orthodoxy and ease of implementation. 97 +Both "Decomposition" and "Duplication" options provide acceptable workarounds to the problem of multiple flagging, and appear to be quite similar in practice. The trade-off in this context was between orthodoxy and ease of implementation. 98 +Conceptually the "Decomposition" approach is the strongest of the two as it not only allows separating concepts, but also helps arranging codes into more homogeneous code lists. It also requires that implementers define pure concepts and name them accordingly. 99 +This document recommends the "Duplication" approach mainly on the practical grounds of ease of implementation because its use of “OBS_STATUS” is compatible with the cross-domain concept scheme, whereas the Decomposition approach is not. The recommended approach could be reconsidered in the future, would the technical standard better accommodate the decomposition approach. 100 +{{/box}} 96 96 97 -//Conceptually the "Decomposition" approach is the strongest of the two as it not only allows separating concepts, but also helps arranging codes into more homogeneous code lists. It also requires that implementers define pure concepts and name them accordingly.// 98 - 99 -//This document recommends the "Duplication" approach mainly on the practical grounds of ease of implementation because its use of “OBS_STATUS” is compatible with the cross-domain concept scheme, whereas the Decomposition approach is not. The recommended approach could be reconsidered in the future, would the technical standard better accommodate the //decomposition //approach.// 100 -))) 101 - 102 102 == 3.3) Extended single code list approach (strongly discouraged) == 103 103 104 104 The extended version of CL_OBS_STATUS (see below) provides the full list of logically possible combinations of codes in a specific SDMX implementation.