Fusion Registry Wiki - User contributions [en]

Structural Usage - Structure References

2019-11-29T12:50:51Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview == The Registry provides the ability to see how structures relate to each other. On an individual structure pages, sele..."

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

The Registry provides the ability to see how structures relate to each other. On an individual structure pages, selecting an item in the table shows information about that structure beneath it. For example, on the Data Structure Definitions page, selecting an individual Data Structure shows which Structures are Cross Referenced by it and also the number of Dataflows that reference this DSD.

Fusion Registry also provides a dedicated page to explore the relationships between structures. This Structure References page allows the navigation from one structure to any of its dependencies.

Use the two drop-downs on the page to select the type of structure to view and optionally filter by agency. A list of structures matching those selections will be displayed in the list on the left. Selecting an item in the list shows the Structures that Reference it and those Structures that are referenced by it.

[[File:DS&DF Maps 2.jpg‎|frameless|700px]]

''Figure 1 showing the Structure References page and the references to and from a DSD''

Clicking on a structure displayed in the list on the right, will display that structure in the list on the left. The structures referencing and referenced by this structure will of course be displayed in the list on the right. By clicking on the items on the right hand side, the user can navigate around the structures, observing the relationships between them.

This page also provides the ability to generate reports about all of the structures in the system. There are currently 2 reports that can be generated.

== All Structures Cross-Reference Report ==

This report has 3 worksheets. The first worksheet (titled “Overview”) lists all of the Structures in the Registry that have references and for each structure lists the count of how many structures it references (the “Reference Count”) and how many structures are referenced by it (the “Referenced By Count”). For a structure such as a DSD you would expect a high number for the “Reference Count” (as it probably references a number of Concepts) and a low number for the “Referenced By Count” (only Constraints and Dataflows may reference a DSD). A Codelist will always have zero for the “Reference Count” as it does not reference any other structures. From this worksheet the popularity of particular structures can be observed.

The second worksheet (titled “Consolidated”) lists all of the Maintinables in the system that reference another Maintainable and explicitly states what that reference is. A single row only shows a single relationship, so if a single Maintainable references a number of items (e.g. a DataStructure references a number of ConceptSchemes) then this Maintainable is repeated with each relationship stated on a different row.

The third worksheet (titled “Granular”) is very similar to the second worksheet, but shows the relationships at the Identifiable level. E.g. a Dimension might reference a Codfelist and a Concept. A single row only shows a single relationship, so if a single Identifiable references a number of items, that identifiable is repeated on a number of rows against the different references. From this worksheet the actual relationships can be observed. Since this worksheet is likely to be long, there are filters on the first row to aid in identifying the structures you may be interested in.

== Structures with no Cross-References Report ==

This is a single worksheet report which lists Maintainables that are not cross-referenced and do not cross-reference any other structure. From this report it is easy to see which structures in the Registry are not used and are candidates for deletion.

File:Structural Usage 1.jpg

2019-11-29T12:48:35Z

Mbaird:

Annotations - Structural Metadata Management

2019-11-29T12:40:04Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview == Annotations are used to provide extra information to structures, almost every structure can be annotated, and can co..."

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

Annotations are used to provide extra information to structures, almost every structure can be annotated, and can contain zero to many annotations. Annotations provide placeholders for Annotation Id, Annotation Title, Annotation Type, Annotation Text, Annotation URI all of which are optional fields.

== Annotation Wizard ==

To create annotations, ensure you are logged into the system as an admin user or an Agency user. Navigate to the structure to be annotated (or the parent structure, for example to annotate a Code, navigate to the Codelist that owns the Codes). On structure selection, click the maintenance icon at the top left of the page, to select '''Manage Annotations''' to open up an Annotation Wizard.

[[File:Annotations 1.jpg‎|frameless|700px]]

''Figure 1 showing the Manage Annotations menu option''

The first step of the wizard is to add annotations to the parent structure that was selected, this is the top level parent structure, for example the Codelist. The subsequent steps relate to annotating the sub structures, such as the Codes that belong to the Codelist.

The second step allows Annotations to be imported against the sub structures, these are known as Identifiable structures, for example a Code in a Codelist. The step provides the means to import the annotation(s) as CSV.

[[File:Annotations 2.jpg‎|frameless|700px]]

''Figure 2 showing step 2 of the Annotation Wizard''

The only required fields are Identifiable Id (which must reference an item in the Maintainable parent), and Annotation Id.

The third step allows Annotations to be manually created, edited, and deleted against the sub structures (Identifiable), i.e import for Codes in a Codelist.

This step provides a table view of all the current annotations against the sub-structures, with the means to edit the selected structure, or to create new or delete existing annotations.

== Viewing Annotations ==

If a structure, or its Identifiable sub-structures, contains annotations, then this will be displayed in the table of details section for the selected structure (under the main table).

The '''View Annotations''' button will be present, and on clicking will open a pop up which will show all the annotations against the structure, or any of its sub-structures.

[[File:Annotations 3.jpg‎|frameless|700px]]

''Figure 3 showing the Codelists page, the selected Codelist (FREQ) has annotations for it''

File:Annotations 3.jpg

2019-11-29T12:34:51Z

Mbaird:

File:Annotations 2.jpg

2019-11-29T12:34:41Z

Mbaird:

File:Annotations 1.jpg

2019-11-29T12:34:29Z

Mbaird:

Codelist and Concept Scheme Maps - Structural Metadata Management

2019-11-29T12:27:51Z

Mbaird:

__NOTOC__
[[Category:Structural Metadata]]
== Overview =

Concept Scheme Maps are almost identical to a Codelist Map, except that the mapping is performed between two Concept Schemes as oppose to two Codelists. The remainder of this section refers to Codelist Maps, however all statements hold true for a Concept Scheme map.

Codelist Maps are used to map Codes from one Codelist to another. This relationship between two Codelists can be used when mapping between Dataflows or Data Structures (see [[Data Structure and Dataflow Maps - Structural Metadata Management|Data Structure and Dataflow Maps]]). This information may also be used for reference or processing from external applications.

[[File:Codelist&Concept Scheme 1.jpg‎|frameless|350px]]

== Codelist Map Wizard ==

The Codelist Map wizard includes the first generic step for information.

The second step of the wizard is to pick a source and target Codelist, this defines which two Codelists will be mapped. To pick (or edit) a source or target Codelist, click in the input box and a pop up window will appear showing all the Codelists in the system, allowing one of them to be selected.

The third step allows Code mapping information to be imported from CSV. This step is optional if Manual Mapping is preferred (step 4) then this can be used.

The CSV is expected to have 2 entries per line, one for the source Code Id, and one for the target Code Id. This is shown in the image below.

[[File:Codelist&Concept Scheme 2.jpg|frameless|700px]]

''Figure 1 showing step 3 of the Codelist Map Wizard''

The final step allows codes to be manually mapped to the source code. To manually map a code, select the source code, the current '''Target''' and a list of '''Available''' targets will be presented, as shown in the image below. On selecting an available target, it can be moved to be a target by clicking on the left arrow. Current Targets can be moved into the Available target by clicking on the right arrow.

[[File:Codelist&Concept Scheme 3.jpg|frameless|700px]]

''Figure 2 showing step 4 of the Codelist Map Wizard''

File:Codelist&Concept Scheme 3.jpg

2019-11-29T12:24:49Z

Mbaird:

File:Codelist&Concept Scheme 2.jpg

2019-11-29T12:24:37Z

Mbaird:

File:Codelist&Concept Scheme 1.jpg

2019-11-29T12:24:26Z

Mbaird:

Codelist and Concept Scheme Maps - Structural Metadata Management

2019-11-29T12:19:44Z

Mbaird:

Codelist and Concept Scheme Maps - Structural Metadata Management

2019-11-29T12:18:21Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview = Concept Scheme Maps are almost identical to a Codelist Map, except that the mapping is performed between two Concept..."

Data Structure and Dataflow Maps - Structural Metadata Management

2019-11-29T12:14:17Z

Mbaird: /* Data Structure Map Wizard */

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

Dataflow Maps are almost identical to a Data Structure Map, except that the mapping is performed between two Dataflows. The remainder of this section describes Data Structure Maps, however all statements hold true for a Dataflow map.
Data Structure Maps are used to map Components (Dimensions and Attributes) from one Data Structure to another. This relationship between two Data Structures can be used to map data queries, or datasets from the source Data Structure to the target Data Structure.

[[File:DS&DF Maps 1.jpg‎|frameless|350px]]

[[File:DS&DF Maps 2.jpg‎|frameless|700px]]

''Figure 1 showing the view of a Data Structure Map''

== Data Structure Map Wizard ==

The Data Structure Map Wizard includes the first generic step for information.

The second step of the wizard is to pick a source and target Data Structure; this defines which two Data Structures will be mapped. To add or modify a source or target, click in the input field to open a list of available structures.

[[File:DS&DF Maps 3.jpg‎|frameless|700px]]

''Figure 2 showing the selected source and target Data Structures''

The third step is used to define how the Components of the source Data Structure map to the Components of the target Data Structure. The '''Source''' table on the left of the page shows the available Components of the source Data Structure. Selecting a source will update the '''Target''' table in the middle of the page, which shows all currently mapped targets. The '''Available''' table on the right of the page shows all the Components of the target Data Structure which are not yet mapped to the selected Source. Components can be moved from Available to Target and vice versa by selecting the component in the target or available table and clicking the left or right arrow.

[[File:DS&DF Maps 4.jpg‎|frameless|700px]]

''Figure 3 showing step 3 of the Data Structure Map Wizard''

The last step of the wizard provides a mechanism to define, for each mapped Component, how their representation is mapped. For example if two Reference Area Components are being mapped, with the source Reference Area using an ISO 2 character country Codelist and the target using the ISO 3 character Country Codelist, this step of the wizard provides the mechanism to define the mapping used between each Code in the source and target Reference Area Codelists.

[[File:DS&DF Maps 5.jpg‎|frameless|700px]]

''Figure 4 showing step 4 of the Data Structure Map Wizard''

The above image shows the Component Maps on the left of the page, as defined in step 3 of the wizard. Each mapped Component can have a Representation Map defined. A Representation Map falls into one of the following three categories:

#'''Implicit''' – this type of mapping states that the source and targets values will be the same and therefore there is no need explicitly define the mapping. For example if the content is textual, or if the components use the same Codelist, or the source and target Codelists share the same Code Ids then implicit mapping can be used.
#'''Explicit (Value Map)''' – this type of mapping is ‘inlne’ and stored as part of this Data Structure Map. A value map is imported using CSV, of source to target (as shown below). A Value Map can be used to map any text content and therefore does not have to be a valid Id ($, £, % can all be mapped for example).
#:[[File:DS&DF Maps 6.jpg‎|frameless|700px]]
#:''Figure 5 Creating a Value Map from CSV''
#: [[File:DS&DF Maps 7.jpg‎|frameless|700px]]
#:''Figure 6 The resulting Value Map in a Table''
#'''Explicit (Codelist Map)''' – this type of mapping references an existing Codelist Map, which is created and maintained separately of this Data Structure Map. This option is only available if there is a Codelist Map defined for the Agency which maps between the source and target Codelist as used by the source and target Components that are being mapped. Codelist Maps are discussed in the next section of this document.
#:[[File:DS&DF Maps 8.jpg‎|frameless|700px]]
#:''Figure 7 showing the use of an Explicit Mapping to define how the values between two Components map''

Data Structure and Dataflow Maps - Structural Metadata Management

2019-11-29T12:13:00Z

Mbaird: /* Data Structure Map Wizard */

File:DS&DF Maps 8.jpg

2019-11-29T12:01:24Z

Mbaird:

File:DS&DF Maps 7.jpg

2019-11-29T12:01:10Z

Mbaird:

File:DS&DF Maps 6.jpg

2019-11-29T12:00:54Z

Mbaird:

Data Structure and Dataflow Maps - Structural Metadata Management

2019-11-22T13:00:58Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview == Dataflow Maps are almost identical to a Data Structure Map, except that the mapping is performed between two Dataflo..."

File:DS&DF Maps 5.jpg

2019-11-22T12:59:56Z

Mbaird:

File:DS&DF Maps 4.jpg

2019-11-22T12:59:38Z

Mbaird:

File:DS&DF Maps 3.jpg

2019-11-22T12:58:29Z

Mbaird:

File:DS&DF Maps 2.jpg

2019-11-22T12:50:52Z

Mbaird:

File:DS&DF Maps 1.jpg

2019-11-22T12:49:07Z

Mbaird:

Metadata Structure Definition - Structural Metadata Management

2019-11-22T12:42:35Z

Mbaird:

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

The Metadata Structure Definition (MSD) is analogous to the Data Structure Definition (DSD), it defines the structure and allowable content of a '''Metadata Report''' (a DSD defines the structure and allowable content of a Dataset). The MSD also defines what types of artefact in the Fusion Registry the Metadata Report can be reported for.

::[[File:MSD 1.jpg‎|frameless|750px]]

::''Figure 1 showing (simplified) UML for a Metadata Structure Definition''

The Metadata Structure Definition (MSD) provides a template for Metadata Reports, and is used to assist in authoring and validation of a Metadata Report. When a user authors a Metadata Report, the report must conform to the MSD this is analogous to a user reporting data which must conform to the Data Structure Definition (DSD). There are a few main differences between a DSD and a MSD. Once such difference is that a MSD contains the definition of allowable Targets, these define what the Metadata Report can be authored against, a DSD does not have this concept. The MSD contains a hierarchy of Reported Attributes, a Reported Attribute is almost identical to a DSD Component (Dimension or Attribute) however a DSD Component is not hierarchical.

::[[File:MSD 2.jpg‎|frameless|750px]]

::''Figure 2 showing the view of an MSD''

'''Note''': Details on authoring Reference Metadata can be found in the Reference Metadata Management guide.

== Metadata Structure Definition Wizard ==

The Metadata Structure Definition Wizard includes the first generic step for information.

The second step requires information on the Report and allowable Targets. Targets can include Data related targets, this includes:

* Observation
* Series
* Code in the context of a Dataflow
* Concept in the context of a Dimension

Structure targets can include any Identifiable Structure, or specific structures can be selected.

::[[File:MSD 3.jpg‎|frameless|700px]]

::''Figure 3 showing the Report Attachments step of the Metadata Structure Definition Wizard''

The third step is used to build the report template definition, by building the Report Attributes hierarchy. Each Reported Attribute must reference a Concept (which provides the name and description). This step can be used to build a hierarchy by using drag and drop.

The final step in the Metadata Structure Wizard is to specify the allowable content for each Metadata Attribute. Content type includes formats such as HTML, String, Numerical and enumerated formats, amongst others. For textual content (HTML, String) the MSD can also define if multilingual text is supported. If multilingual support is set to true in the definition then Metadata can be reported for the Attribute in multiple languages.

If the Metadata Attribute is used simply as a presentational node then it can be set to allow no content. A presentational node can be used if an Attribute has child Attributes, as shown in the following example:

::[[File:MSD 4.jpg‎|frameless|700px]]

::''Figure 4 showing the allowable content step of the MSD Wizard. The hierarchy from the previous step is replicated in this step of the Wizard''

As shown in the above contact report, this step also allows the user to specify the minimum number of times the Attribute can appear in the Report. A Min Occurs of 1 would indicate that the Attributes appearance is mandatory. If Max Occurs is left empty then this will be interpreted as unbounded (it can be reported multiple times with no imposed limit). In the above example there is no upper limit on the number of Contacts, but there must be at least one. In the above example each Contact must have 1 Address but no more than 2. Each Address must have a house number or name, a Street, Country and post/zip code. The list of countries will be provided by the Reference Area Codelist that the COUNTRY Attribute has been linked to.

Metadata Structure Definition - Structural Metadata Management

2019-11-22T12:41:52Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview == The Metadata Structure Definition (MSD) is analogous to the Data Structure Definition (DSD), it defines the structur..."

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

The Metadata Structure Definition (MSD) is analogous to the Data Structure Definition (DSD), it defines the structure and allowable content of a '''Metadata Report''' (a DSD defines the structure and allowable content of a Dataset). The MSD also defines what types of artefact in the Fusion Registry the Metadata Report can be reported for.

::[[File:MSD 1.jpg‎|frameless|750px]]

''Figure 1 showing (simplified) UML for a Metadata Structure Definition''

The Metadata Structure Definition (MSD) provides a template for Metadata Reports, and is used to assist in authoring and validation of a Metadata Report. When a user authors a Metadata Report, the report must conform to the MSD this is analogous to a user reporting data which must conform to the Data Structure Definition (DSD). There are a few main differences between a DSD and a MSD. Once such difference is that a MSD contains the definition of allowable Targets, these define what the Metadata Report can be authored against, a DSD does not have this concept. The MSD contains a hierarchy of Reported Attributes, a Reported Attribute is almost identical to a DSD Component (Dimension or Attribute) however a DSD Component is not hierarchical.

::[[File:MSD 2.jpg‎|frameless|750px]]

''Figure 2 showing the view of an MSD''

'''Note''': Details on authoring Reference Metadata can be found in the Reference Metadata Management guide.

== Metadata Structure Definition Wizard ==

The Metadata Structure Definition Wizard includes the first generic step for information.

The second step requires information on the Report and allowable Targets. Targets can include Data related targets, this includes:

* Observation
* Series
* Code in the context of a Dataflow
* Concept in the context of a Dimension

Structure targets can include any Identifiable Structure, or specific structures can be selected.

::[[File:MSD 3.jpg‎|frameless|700px]]

''Figure 3 showing the Report Attachments step of the Metadata Structure Definition Wizard''

The third step is used to build the report template definition, by building the Report Attributes hierarchy. Each Reported Attribute must reference a Concept (which provides the name and description). This step can be used to build a hierarchy by using drag and drop.

The final step in the Metadata Structure Wizard is to specify the allowable content for each Metadata Attribute. Content type includes formats such as HTML, String, Numerical and enumerated formats, amongst others. For textual content (HTML, String) the MSD can also define if multilingual text is supported. If multilingual support is set to true in the definition then Metadata can be reported for the Attribute in multiple languages.

If the Metadata Attribute is used simply as a presentational node then it can be set to allow no content. A presentational node can be used if an Attribute has child Attributes, as shown in the following example:

::[[File:MSD 4.jpg‎|frameless|700px]]

''Figure 4 showing the allowable content step of the MSD Wizard. The hierarchy from the previous step is replicated in this step of the Wizard''

As shown in the above contact report, this step also allows the user to specify the minimum number of times the Attribute can appear in the Report. A Min Occurs of 1 would indicate that the Attributes appearance is mandatory. If Max Occurs is left empty then this will be interpreted as unbounded (it can be reported multiple times with no imposed limit). In the above example there is no upper limit on the number of Contacts, but there must be at least one. In the above example each Contact must have 1 Address but no more than 2. Each Address must have a house number or name, a Street, Country and post/zip code. The list of countries will be provided by the Reference Area Codelist that the COUNTRY Attribute has been linked to.

File:MSD 4.jpg

2019-11-22T12:38:40Z

Mbaird:

File:MSD 3.jpg

2019-11-22T12:36:56Z

Mbaird:

File:MSD 2.jpg

2019-11-22T12:24:39Z

Mbaird:

File:MSD 1.jpg

2019-11-22T12:21:16Z

Mbaird:

Pre-Defined Queries - Structural Metadata Management

2019-11-22T12:18:47Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview == A Pre-Defined query is stored in the Fusion Registry as an SDMX Content Constraint. In SDMX the Content Constraint..."

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

A Pre-Defined query is stored in the Fusion Registry as an SDMX Content Constraint. In SDMX the Content Constraint can be used to define allowable content (see section [[Reporting Constraints - Structural Metadata Management|Reporting Constraints]]) or to define data present. The latter type of Content Constraint has been termed Pre-Defined Query in the Fusion Registry. The creation of a Pre-Defined query follows the same steps as a Reporting Constraint, with the exception that the constrained structure must be a Dataflow.

The view of the Pre-Defined Query is the same as the Reporting Constraint, with the additional feature of being able to run the query.

::[[File:PreDefined Queries 1.jpg‎|frameless|750px]]

''Figure 1 showing the view of a Pre-Defined Query, with the Run Query button in the details header''

Running the query loads the browse data page with the Codes pre-selected based on the Pre-Defined Query definition.

::[[File:PreDefined Queries 2.jpg‎|frameless|750px]]

''Figure 1 showing the resultant data table after running the Pre-Defined Query above''

File:PreDefined Queries 2.jpg

2019-11-22T12:17:45Z

Mbaird:

File:PreDefined Queries 1.jpg

2019-11-22T12:15:34Z

Mbaird:

Reporting Constraints - Structural Metadata Management

2019-11-22T12:12:24Z

Mbaird:

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

Reporting Constraints are used to further restrict the allowable content of a '''Codelist''' in the context of a '''DSD, Dataflow, Provision Agreement,''' or '''Data Provider'''. Collectively these are termed as Constrainable Structures. The restrictions imposed by Reporting Constraints are taken into account when validating a dataset reported by a '''Data Provider'''. A Reporting Constraint defines restrictions against Dimensions and Attributes of a DSD which take allowable content from an enumerated list (e.g Codelist).

::[[File:Reporting Constraints 1.jpg‎|frameless|500px]]

The Codelists which can be constrained are determined from the Constrainable structures that the Reporting Constraint is referencing.

A Reporting Constraint can impose a rule on any of the available Codelists to remove any number of allowable Codes, therefore reducing the universe of the enumerated list. A Codelist is constrained by either defining which Codes in the Codelist are included (remain valid) or which codes are excluded (are not valid). An included or excluded Code may also be marked as cascade, which means any Codes which are children of that Code also inherit the rule of inclusion or exclusion.

When viewing a Reporting Constraint, the Included Cube shows which Codes remain valid for any of the Constrained Components. The excluded Cube shows which Codes are no longer valid.

::[[File:Reporting Constraints 2.jpg‎|frameless|750px]]

::''Figure 1 showing the view of the included Cube for a Reporting Constraint''

A Constrainable Structure, such as a Provision Agreement will inherit any Reporting Constraints which are attached to lower level structures that it references. For example the Provision Agreement will inherit any Reporting Constraints against the Dataflow it uses, and the DSD that the Dataflow uses. It will also inherit any Reporting Constraints against the Data Provider it references.

The rules defined by Reporting Constraints will be enforced when performing data validation. The rules are also reflected when viewing a DSD, Dataflow, or Provision Agreement, as shown below.

::[[File:Reporting Constraints 3.jpg‎|frameless|750px]]

::''Figure 2 showing a constrained Reference Area Codelist in the Context of a Data Provider and Dataflow combination (Provision Agreement)''

== Report Constraint Wizard ==

The Reporting Constraint Wizard includes the first generic step for information.

The second step is used to define what Structures are being constrained and of the constrained structures, which Components will be included in the Constraints. Only Components which reference a Codelist are included in the available list. If the Constrained structure is a Data Provider, the list of Components will be derived from all the Dataflows the Data Provider has a Provision Agreement for.

::[[File:Reporting Constraints 4.jpg‎|frameless|750px]]

::''Figure 3 showing the Constrained Structure and selected Components to include in the Constraint''

The third and fourth steps are to define the included and excluded values respectively. A Component can only be defined to contain included codes or excluded Codes not both.

::[[File:Reporting Constraints 5.jpg‎|frameless|750px]]

::''Figure 4 showing step 3 of the Reporting Constraint Wizard''

File:Reporting Constraints 5.jpg

2019-11-22T12:11:12Z

Mbaird:

File:Reporting Constraints 4.jpg

2019-11-22T12:08:32Z

Mbaird:

Reporting Constraints - Structural Metadata Management

2019-11-22T12:06:35Z

Mbaird:

Reporting Constraints - Structural Metadata Management

2019-11-22T12:05:31Z

Mbaird:

File:Reporting Constraints 3.jpg

2019-11-22T12:04:09Z

Mbaird:

File:Reporting Constraints 2.jpg

2019-11-22T12:01:26Z

Mbaird:

File:Reporting Constraints 1.jpg

2019-11-22T12:00:03Z

Mbaird:

Provision Agreements - Structural Metadata Management

2019-11-22T11:57:54Z

Mbaird: Created page with "__NOTOC__ Category:Structural Metadata == Overview == A Provision Agreement is the union of a '''Dataflow''' with a '''Data Provider'''. A Provision Agreement is a defin..."

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

A Provision Agreement is the union of a '''Dataflow''' with a '''Data Provider'''. A Provision Agreement is a definition that the '''Data Provider''' is allowed to provide data for the '''Dataflow'''. Data is always reported by a Data Provider against the Provision Agreement.

::[[File:Provision Agreements 1.jpg‎|frameless|300px]]

When viewing a Provision Agreement, it is the underlying DSD that is shown, however it is shown in the context of the Provision Agreement and therefore any additional restrictions which have been applied to the Provision Agreement (see section 12 Reporting Constraints) will be reflected in this view.

== Provision Agreement Wizard ==

The Provision Agreement wizard includes the first generic step for information about the Provision Agreement.

The second step requires the selection of both the Dataflow and Data Provider the Provision Agreement is combining. The Dataflow provides the definition of the allowed data. The Data Provider defines which Organisation can report data for the Dataflow.

It is possible to define the data reporting mechanism for that is allowed for this Provision Agreement on the second step of the wizard. The default reporting mechanism is for the Data Provider to supply a URL to an external data file, or SDMX web service.

'''Note''': When viewing a Provision Agreement it is possible to modify the linked data store as shown in the image below.

::[[File:Provision Agreements 2.jpg‎|frameless|750px]]

''Figure 1 showing the Provision Agreements view, where the details section allows modification to the linked data store''

File:Provision Agreements 2.jpg

2019-11-22T11:56:30Z

Mbaird:

File:Provision Agreements 1.jpg

2019-11-22T11:53:55Z

Mbaird:

Dataflow - Structural Metadata Management

2019-11-22T11:48:49Z

Mbaird:

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==

A Dataflow is a structure on which data is collected and disseminated. A Dataflow references a Data Structure Definition (DSD) which is used as the underlying template to which the data must conform.

::[[File:Dataflow 1.jpg‎|frameless|300px]]

When viewing a Dataflow, it is the underlying DSD that is shown, however it is shown in the context of the Dataflow and therefore any additional restrictions which have been applied to the Dataflow (see section [[Reporting Constraints - Structural Metadata Management|Reporting Contraints]]) will be reflected in this view.

== Dataflow Wizard ==

The Dataflow Wizard includes the first generic step for information about the Dataflow.

The second step requires the selection of the Data Structure Definition (DSD) the Dataflow will use. To select or modify the DSD selection click in the input field, this will open a list of available DSDs to select from. The details of the selected DSD are shown on this step.

The third step is are optional and are only required if setting up a data collection environment. The information in these steps can be managed form the Provision Agreements page however for convenience the management is also included in the Dataflow Wizard.

The third step allows the user to define which Data Providers have permission to submit data for this Dataflow. The output of this step is to create a Provision Agreement for each Data Provider linked to this Dataflow.

::[[File:Dataflow 2.jpg‎|frameless|750px]]

::''Figure 1 showing step 3 of the Dataflow Wizard – choose Data Providers for Dataflow''

For more information about data stores, please refer to the Data Collection Management guide.

Dataflow - Structural Metadata Management

2019-11-22T11:48:08Z

Mbaird: /* Dataflow Wizard */

__NOTOC__
[[Category:Structural Metadata]]
== Overview ==
A Dataflow is a structure on which data is collected and disseminated. A Dataflow references a Data Structure Definition (DSD) which is used as the underlying template to which the data must conform.

::[[File:Dataflow 1.jpg‎|frameless|300px]]

When viewing a Dataflow, it is the underlying DSD that is shown, however it is shown in the context of the Dataflow and therefore any additional restrictions which have been applied to the Dataflow (see section [[Reporting Constraints - Structural Metadata Management|Reporting Contraints]]) will be reflected in this view.

== Dataflow Wizard ==

The Dataflow Wizard includes the first generic step for information about the Dataflow.

The second step requires the selection of the Data Structure Definition (DSD) the Dataflow will use. To select or modify the DSD selection click in the input field, this will open a list of available DSDs to select from. The details of the selected DSD are shown on this step.

The third step is are optional and are only required if setting up a data collection environment. The information in these steps can be managed form the Provision Agreements page however for convenience the management is also included in the Dataflow Wizard.

The third step allows the user to define which Data Providers have permission to submit data for this Dataflow. The output of this step is to create a Provision Agreement for each Data Provider linked to this Dataflow.

::[[File:Dataflow 2.jpg‎|frameless|750px]]

::''Figure 1 showing step 3 of the Dataflow Wizard – choose Data Providers for Dataflow''

For more information about data stores, please refer to the Data Collection Management guide.

File:Dataflow 2.jpg

2019-11-22T11:45:47Z

Mbaird:

Reporting Constraints - Structural Metadata Management

2019-11-22T11:44:06Z

Mbaird: Created page with "Reporting Constraints"

Reporting Constraints

Dataflow - Structural Metadata Management

2019-11-22T11:43:45Z

Mbaird:

File:Dataflow 1.jpg

2019-11-22T11:40:32Z

Mbaird:

Dataflow - Structural Metadata Management

2019-11-20T13:01:07Z

Mbaird: