Changes for page Possible Ways of Implementing the Observation Status Concept

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-xwiki:XWiki.helena
	1	+xwiki:XWiki.arturkryazhev

Content

...	...	@@ -25,28 +25,29 @@
25	25
26	26	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.
27	27
28		-|(% rowspan="2" %)**Observation status hierarchy**|(% colspan="2" %)**Relevant in conjunction with...**
29		-|**numeric values**|**missing values**
30		-|**B** / time series break (highest importance)|Yes|Yes
31		-|**O** / missing value| |Yes
32		-|**M** / missing value; data cannot exist| |Yes
33		-|**L** / missing value; data exist but were not collected| |Yes
34		-|**H** / missing value; holiday or weekend| |Yes
35		-|**Q** / missing value; suppressed| |Yes
36		-|**J** / derogation|Yes|Yes
37		-|**S** / strike and other special events|Yes|Yes
38		-|**D** / definition differs|Yes|
39		-|**K** / data included in another category| |Yes
40		-|**W** / Includes data from another category|Yes|
41		-|**I** / imputed value|Yes|
42		-|**F** / forecast value|Yes|
43		-|**E** / estimated value|Yes|
44		-|**P** / provisional value|Yes|
45		-|**N** / not significant|Yes|
46		-|**U** / low reliability|Yes|
47		-|**V** / unvalidated value|Yes|
48		-|**G** / experimental value|Yes|
49		-|**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" %)
50	50
51	51	= 3) Multiple flagging =
52	52
...	...	@@ -90,16 +90,14 @@
90	90
91	91	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.
92	92
93		-|(((
	94	+{{box}}
94	94	**Comments on the choice of the recommended solution**
95	95
96		-//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}}
97	97
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		-
100		-//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.//
101		-)))
102		-
103	103	== 3.3) Extended single code list approach (strongly discouraged) ==
104	104
105	105	The extended version of CL_OBS_STATUS (see below) provides the full list of logically possible combinations of codes in a specific SDMX implementation.