Additional rules for coded values 48

General principles for code lists in INSPIRE are documented in Annex G. These principles provide the background for the requirements and recommendations in this document in 9.4.5 and 9.5.2.

9.4.5.2 Enumerations vs. code lists

Recommendation 4 In the case of an attribute type with coded values, an enumeration or code list

should be used. If the set of allowed values is fixed, an enumeration should be used. If the set of allowed values may be extended by user communities or without a major revision of the data specification, a code list should be used.

EXAMPLE 1 For the origin of a hydrographic feature, two values are distinguished: - man-made

- natural

As this list of possible values may be considered as exhaustive, it is not likely to change; i.e., it may be specified as an enumeration in the application schema.

EXAMPLE 2 To describe the hydrological persistence of a body of water, the following values are currently in use:

- dry - ephemeral - intermittent - perennial

As this list of possible values may be considered as non-exhaustive (e.g. the user requirements may evolve and this list may have to be enriched), it should be specified as a code list in the application schema.

During the Annex II+III development process, a distinction has been proposed for code lists with and without internal structure (see EXAMPLE 3). According to this proposal, both simple lists (or, more precisely, sets) of values as well as collections of values that have some internal (e.g. a hierarchical) structure should be referred to as code lists – even if, conceptually, this is not entirely correct. The issue will be discussed in the relevant ISO TC 211 committees (notably on the revision of ISO 19103 and ISO 19109), and any decision taken there will be adopted by INSPIRE.

EXAMPLE 3 The code list currentUse from BU would have the following structure. 1 Residential

1.1 Individual – One dwelling 1.2 Collective – Multi-dwelling 2 Primary sector 3 Secondary sector 3.1 Basic supply 3.1.1 Water 3.1.2 Energy 3.1.3 Telecommunication 3.2 Other industrial activity 4 Tertiary sector

(…)

9.4.5.3 External code lists

9.4.5.3.1 General rules

Often, existing code lists exist that are well established and already used in a thematic community. The re-use of such code lists helps improve interoperability between INSPIRE and other (global and/or

non-spatial) initiatives and systems and also eases the burden on data providers (who can use the existing code list values also when making data available under INSPIRE).

EXAMPLE The four values of the AerodromeTypeValue code list in the Air Transport Network application schema was derived from AIXM 5.0.

Recommendation 5 If for a specific property in an INSPIRE application schema, there is already

an existing, well-established code list that is maintained by an international organisation, this code list should be referenced from the INSPIRE application schema.

Ideally, an externally managed code list should meet the following requirements: 1. It should be managed by a competent international organisation.

2. It should be well maintained, i.e. all its values must remain available forever, even if they have been deprecated, retired or superseded.

3. The code list and each of its values should be identifiable through a persistent URI7 in the „http‟ scheme.

4. The code list should be available in HTML plus at least one of the following machine-readable representations:

o GML dictionary o SKOS

However, not all external code lists will meet these requirements. If an external code list is used in an INSPIRE application schema, but does not meet the requirements, the values will be made available through the common INSPIRE code list registry.

NOTE This representation has to be maintained and updated if the reference in the INSPIRE application schema is updated to a new version of the external code list. A workflow for this should be defined as part of the terms of reference for maintenance and implementation.

9.4.5.3.2 Versions

References to external code lists from INSPIRE data specifications can be either to a specific version (identified by a date or version number) of the code list or to the code list in general – without referring to a specific version (see “Version” column in Figure 1).

Recommendation 6 The reference to the code list should not be to a specific version.

Open issue 2: Where a reference to an external code list is intended to be included in the Implementing Rule, it may only be possible to refer to a specific version. This will need to be discussed with the EC legal service.

9.4.5.3.3 Subsets

Recommendation 7 To reference only a subset of an externally managed code list (e.g. only the

top level(s) of a hierarchical code list or a certain thematic subset), the subset to be re-used in INSPIRE should be specified in additional requirements.

NOTE For pragmatic reasons, the subset could additionally be made available through the common INSPIRE code list registry.

EXAMPLE 6 Different subsets of the NACE codes

(http://ec.europa.eu/competition/mergers/cases/index/nace_all.html) may be relevant for different themes, e.g. Section A: Agriculture, hunting and forestry for AF, section C: Mining and quarrying for MR, sub-section CA: Mining and quarrying of energy producing materials for PF and ER and section O: Other community, social and personal service activities for US.

7 _{In INSPIRE, Uniform Resource Identifiers (URIs) as defined in IETF RFC 3986 are intended to serve as these} persistent, location-independent resource identifiers. See also D2.7, Annex C.

9.4.5.3.4 Dependencies

The adoption of a third-party register creates a dependency and requires a discussion between INSPIRE and the organisation managing the external register. This includes intellectual property rights aspects, notification of changes, etc. The outcome of this discussion could be documented in an (informal) agreement between the external organisation and the Commission/Member States.

Open issue 3: It will be important to discuss with DG ENV and the EC Legal Service whether/how references to external lists are permissible in the Implementing Rule and how dependencies should be formally agreed and/or documented