13. Executive summary

13. Executive summary.

This report is part of a package of projects financed by the Danish Government for the support of the European Environment Agency. The aim of the project is to utilise the experiences from the use of the Danish STANDAT system for exchange of environmental edp-based data.

Main principles of STANDAT.

STANDAT is a standardised data exchange format, developed in Denmark in the late 1980'ies to facilitate the exchange of large amounts of environmental information. The STANDAT concept has four main component elements: the code list system, the file format, the organisational set-up for the administration and development of STANDAT, and the edp-based support programmes.

STANDAT is a dynamic system in being under constant development as to the contents of the code lists. This development is user-driven via the organizational set-up.

STANDAT has a relatively simple and pragmatic set-up and is relatively easy to understand and use.

STANDAT ensures unambiguity in form and content of the data transferred, and ensures independence of hardware and software solutions between the different users.

Code lists.

There are four different kinds of code lists that together form the code list system.

The subject code list defines the subjects on which data can be transferred and supplies a code for each subject. The subject code list is hierarchical (for an example please refer to figure 3.2). This fact is related to the way that the file format is structured (see below).

The information code list defines what information can be exchanged on each subject and supplies the relevant codes (for an example please refer to figure 3.3).

The combination code list defines the possible connections between the subjects and the information types. This makes it possible to have a relatively small set of information types, as an information type (eg measurement method) can be associated to more than one subject.

Finally the value code lists supplies the predefined values for some of the information types (other information types are numbers, text strings or date-information).

Together the code lists define a 'view of the world' with regards to structure, content and connections between the different pieces of information on the environment.

File format.

There are three component elements of the file format:

• the HEADER section that contains administrative information on sender and recipient etc.
• the DEFINITION section that defines what data are to be transferred and how they are to be structured. This section is the key to interpreting the DATA section.
• the DATA section supplies the relevant information as specified in the DEFINITION section. The different subjects can be embedded in one another so that you can refer to the same parent-information for several subsets of data.

Edp-based support programmes.

STANDAT has two kinds of related edp-based support programmes:

The STANDAT Service Programme (SSP) that was developed for the support of the producers of STANDAT files. This programme provides an overview of the code list system and has facilities for loading new code list versions as well as search facilities. Even more important, it offers complete syntactic test features for STANDAT files with warning and error messages and it can generate simple tabular reports on STANDAT files.

The STANDAT load system is used in parts of the Danish Ministry of Environment and Energy and it uses a generalized specification of semantic requirements that can be used with very few specifications for any relevant file transfer. Files are controlled before they are loaded into the relevant databases.

Transferring information via STANDAT.

When you want to have data delivered in the STANDAT format you provide the suppliers of data with a general description of the data to be transferred, an exact description of the STANDAT file with examples, exact description of KEY data, description of value codes to be used and specification of the time for delivery.

If needed, new codes and code lists can be established via the STANDAT secretariat. New codes and code lists have to be assessed by the national Danish data topic centres.

When the supplier of data has retrieved the relevant data from her / his database it should be tested via the SSP, STANDAT Support Programme. Data are then transferred to the recipient on diskette or via network.

The recipient should make a final check of the file before down-loading it into his / her database. Here the STANDAT load programme is used for data delivered to the Danish EPA.

Organisational set-up.

The organisational set-up uses the organisation for collecting data on the environment in Denmark. This comprises a set of national data topic centres, that are some of the most important users of the STANDAT format. In the administration of STANDAT the topic centres are responsible for assessing requests for new codes and code lists in STANDAT.

The whole administration is coordinated by the secretariat placed in the Danish EPA. There is a steering committee with representatives for all the main user groups, eg counties, municipalities, Kommunedata and the topic centres. Kommunedata is responsible for the technical part of the updating of the code lists.

Scenarios for data transfer.

The conclusions of this report has ao been based on a set of scenarios for the process of data transfer within the EEA network. It is quite feasible that more than one solution will be necessary, as different solutions may be necessary for the different areas of work of the EEA. The scenarios envisaged in this report are:

Scenario I: The centralised model / standardised hardware and software.

Scenario II: The decentralised model / standardised format (and code lists).

Scenario III: The open model / flat files / flat files and common code lists.

Scenario IV: The all-data-are-shared-data model / network based model.

Scenario V: The ad-hoc-model.

Conclusions and recommendations.

Based on the experience of developing and using the STANDAT system and based on other points from this report some of the conclusions and recommendations are:

• Common, global solutions are preferable.
• Elements / experience from existing environmental data exchange concepts should be utilised in the Agency's development of a common solution.
• A set of requirements for the development of an EIONET exchange format.
• Solutions should use - or at least be based on - suitable, existing code lists.
• A set of requirements for developing / deciding on a set of common code lists.
• The development of user friendly high-quality edp-based support programmes is a necessity when introducing a transfer format.
• Information, education, seminars, guide books and hot line services are important when introducing a concept for data transfer.
• The EEA has in its EIONET a suitable organisational set-up for the development and implementation of a common exchange format for the whole network.
• The questions of need for resources is important to take into account.
• Pilot projects to test recommendations and possible solutions are important.
• It is important to set up a working group to make recommendations on the exact solution to apply.
• The global format should respect the individual national solutions that exist already.