Difference between revisions of "Validation behaviour using item validity"

From FMR Knowledge Base
Jump to navigation Jump to search
m (Glenn moved page Validation behaviour using item validity to Validation behavior using item validity without leaving a redirect: Typo)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
[[Category:Behaviour]]
+
[[Category:How_To]]
 +
[[Category:How_To V11]]
 
== Overview ==
 
== Overview ==
Fusion Registry's [[Structural data validation|Structural Data Validation]] function checks that data submitted conforms to the Dataflow's [[Data Structure Definition]], and also detects other potential problems like conflicting duplicate observations. For [[Enumerated component|enumerated components]], dimension or attribute values submitted must match those in the specified [[Codelist]].
+
Fusion Registry's [[Data_Validation|Structural Data Validation]] function checks that data submitted conforms to the Dataflow's [[Data Structure Definitions]], and also detects other potential problems like conflicting duplicate observations. For [[Component|enumerated components]], dimension or attribute values submitted must match those in the specified [[Codelists]].
 
<br><br>
 
<br><br>
 
When creating a Codelist, the designer has the option of defining the period in time during which the Code is considered valid - the ''validity period'' for the Code item. If no validity period is set, the Code is considered to be valid for all time. Note that a Code may have multiple validity periods.
 
When creating a Codelist, the designer has the option of defining the period in time during which the Code is considered valid - the ''validity period'' for the Code item. If no validity period is set, the Code is considered to be valid for all time. Note that a Code may have multiple validity periods.

Latest revision as of 03:35, 13 May 2024

Overview

Fusion Registry's Structural Data Validation function checks that data submitted conforms to the Dataflow's Data Structure Definitions, and also detects other potential problems like conflicting duplicate observations. For enumerated components, dimension or attribute values submitted must match those in the specified Codelists.

When creating a Codelist, the designer has the option of defining the period in time during which the Code is considered valid - the validity period for the Code item. If no validity period is set, the Code is considered to be valid for all time. Note that a Code may have multiple validity periods.

Series referencing Codes which have specific validity periods are only valid if all of the observations fall within those periods.

Example

Validation behaviour using item validity.jpg


The above example illustrates a simple dataset using a Data Structure Defintion (DSD) with three dimensions: INDICATOR, REF_AREA and FREQ.


REF_AREA is an enumerated country dimension with the CL_REF_AREA Codelist containing three codes:

  • GE - Gilbert and Ellice Islands
  • KI - Kiribati
  • TV - Tuvulu

CL_REF_AREA has item validity periods defined for each of the three codes as follows:

  • GE - valid between 1916 and 1976
  • KI - valid from 1977
  • TV - valid from 1977

The first three series in the example dataset are valid because the observation values all fall within the validity period for the REF_AREA code 'GE'.

A_IND:GE:A is invalid because the series has observations for 1977 and 1978, years when the REF_AREA code GE is not valid.
Similarly A_IND:KI:A and A_IND:TV:A are also invalid beacuse the item validity periods for both the 'KI' and 'TV' REF_AREA codes extend from 1977 to date meaning that the observations provided for 1970,1971 and 1972 cannot be correct.