md_2_final.adoc

:important-caption: :closed_book:
:tip-caption: :ledger:
:note-caption: :blue_book:
:toc: macro
:toc-title:
:toclevels: 4
:sectnumlevels: 4

image:.\media/image1.png[image,width=107,height=107]
**INSPIRE**
*Infrastructure for Spatial Information in Europe*

[discrete]
= Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007

[width="100%",cols="24%,76%",]
|===
|*Title* |Technical Guidelines for implementing dataset and service metadata based on ISO/TS 19139:2007
|*Creator* |Temporary MIG subgroup for action MIWP-8
|*Date of publication* |2017-03-02
|*Subject* |Technical Guidance for INSPIRE metadata for datasets and services
|*Status* a|
Version 2.0.1

This document has been endorsed by the INSPIRE maintenance and implementation group (MIG) in its meeting on 30/11-1/12/2016 (see meeting minutes at https://ies-svn.jrc.ec.europa.eu/projects/mig-p/wiki/5th_MIG-P_meeting).

|*Publisher* |INSPIRE Maintenance and Implementation Group (MIG)
|*Type* |Text
|*Description* |Implementation specification for defining metadata for INSPIRE datasets and services in ISO/TS 19139 based XML format in compliance with the INSPIRE Implementing Rules for metadata.
|*Format* |MS Word (doc)
|*Licence* |Creative Commons Attribution (cc-by) 4.0 (https://creativecommons.org/licenses/by/4.0/)
|*Identifier* a|
http://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0 (latest bugfix version of v2.0)

http://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0.1 (this bugfix version)

|*Corrigenda* |http://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0/corrigenda
|*Language* |EN
|===

== Table of Contents
toc::[]

== Acknowledgements
Many individuals and organisations have contributed to the development of these Guidelines.

The original INSPIRE Drafting Team on Metadata (2006-08) included: Marcel Reuvers (Netherlands), Nicolas Lesage (France), Kristian Senkler (Germany), Michael Gould (Spain), Gil Ross (UK), Stefano Nativi (Italy), Jan Hjelmager (Denmark), Franz Daffner (European Environment Agency), Per Ryghaud (Norway), Thomas Vögele and Fred Kruse (Germany), David Danko (USA).

This version 2.0 is an extensive revision of the previous version 1.3 both in structure and content based on the work of the INSPIRE Maintenance and Implementation Group (MIG) subgroup for the Work Package 8: Metadata (MIWP-8). The editing work including restructuring of the text into Conformance Class chapters and TG Requirement text revisions for added XML element level precision was done by Ilkka Rinne of Spatineo Inc under contract for the European Commission Joint Research Centre (JRC) in January - April 2016.

We wish to thank the members of the MIWP-8 group as well as Michael Lutz, Angelo Quaglia and Freddy Fierens of the JRC for the thorough groundwork, insightful feedback and contributions to document during the editing work.The MIWP-8 group was chaired by Michael Östling (Sweden), and included the following members (in alphabetical order): Christian Ansorge (EEA), Lars Inge Arnevik (Norway), Vincent Bombaerts (Belgium), Pierluigi Cara (Italy), Radoslav Chudý (Czech Republic), Ine de Visser (Netherlands), Daniele Francioli (JRC), Christine Gassner (Austria), Alejandro Guinea de Salas (Spain), Paul Hasenohr (EEA), Željko Hecimovic (Croatia), Frédéric Houbie (France), Lucie Kondrova (Czech Republic), Peter Kochmann (Germany), Marc Léobet (France), Marie Lambois (France), Darja Lihteneger (EEA), Manfred Mittelboeck, (Austria), Javier Nogueras Iso (Spain), Geraldine Nolf (Belgium), Andrea Perego (JRC), Tomas Reznik (Czech Republic), James Reid (UK), Eliane Roos (France), Antonio Rotundo, (Italy), Martin Seiler (Germany), Kristian Senkler (Germany), André Schneider (Switzerland), Age Sild (Estonia), and Pawel Soczewski (Poland).

*Contact information*

European Commission Joint Research Centre

B.6 Digital Economy

inspire-info@ec.europa.eu

== Foreword
Directive 2007/2/EC of the European Parliament and of the Council [INS DIR], adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment. INSPIRE will make available relevant, harmonised and quality geographic information to support the formulation, implementation, monitoring and evaluation of policies and activities, which have a direct or indirect impact on the environment.

INSPIRE is based on the infrastructures for spatial information established and operated by the 28 Member States of the European Union. The Directive addresses 34 spatial data themes needed for environmental applications, with key components specified through technical implementing rules. This makes INSPIRE a unique example of a legislative “regional” approach.

To ensure that the spatial data infrastructures of the Member States are compatible and usable in a Community and trans-boundary context, the Directive requires that common Implementing Rules (IR) are adopted in the following areas.

* Metadata;
* The interoperability and harmonisation of spatial data and services for selected themes (as described in Annexes I, II, III of the Directive);
* Network Services;
* Measures on sharing spatial data and services;
* Co-ordination and monitoring measures.

The Implementing Rules are adopted as Commission Decisions or Regulations, and are legally binding.

In addition to the Implementing Rules, non-binding Technical Guidance documents describe detailed implementation aspects and relations with existing standards, technologies and practices in order to support the technical implementation process. They may need to be revised during the course of implementing the infrastructure to take into account the evolution of technology, new requirements, and cost benefit considerations. In other words, these Technical Guidance documents are supporting material to assist in the technical implementation of the INSPIRE Directive but no additional obligations can be derived from these documents over and above the obligations set out in the Directive and the Implementing Rules. The Technical Guidance documents are also not intended to interpret legal obligations. Figure 1 illustrates the relationship between the INSPIRE Regulations containing Implementing Rules and their corresponding Technical Guidance documents.

This Technical Guidance document relates to the implementation of the requirements related to metadata for spatial data sets and series and spatial data services (including network services) included in [Regulation 1205/2008] and [Regulation 1089/2010].

Implementing this Technical Guidance are designed to maximise the interoperability of INSPIRE services. Technical Guidance documents describe how Member States might implement the Implementing Rules described in a Commission Regulation. The technical provisions and the underlying concepts are often illustrated by use case diagrams and accompanied by examples. Technical Guidance documents may also include non-binding technical recommendations that should be satisfied if a Member State chooses to conform to the Technical Guidance. However, these recommendations have no legally binding effect.

image:.\media/image2.png[TG vs IR,width=600,height=450]

*Figure* *1:* Relationship between the INSPIRE Implementing Rules and the associated Technical Guidance.

[width="100%",cols="100%",options="header",]
|===
a|
*Disclaimer*

This document has been developed collaboratively through the INSPIRE maintenance and implementation framework, involving experts of the European Commission services, the European Environment Agency, EU Member States, the Accession and EFTA Countries. The document should be regarded as presenting an informal consensus position on best practice agreed by all partners. However, the document does not necessarily represent the official, formal position of any of the partners. To the extent that the European Commission's services provided input to this technical document, such input does not necessarily reflect the views of the European Commission and its services. This document does not bind the Commission and its services, nor can the Commission and its services be held responsible for any use which may be made of the information contained herein.

The technical document is intended to facilitate the implementation of Directive 2007/2/EC and is not legally binding. Any authoritative reading of the law should only be derived from Directive 2007/2/EC itself and other applicable legal texts or principles such as the related Implementing Rules. Only the Court of Justice of the European Union is competent to authoritatively interpret Union legislation.

|===

== Foreword to this version
The previous version 1.3 of this Technical Guidelines document has been widely used since its publication in 2013. It has led to a lot of feedback concerning unclear TG Requirements and implementation choices, which this version aims to answer and clarify. This work has been done under INSPIRE Maintenance and Implementation Group (MIG) temporary sub-group for work package 8 (MIWP-8: Metadata). According to its terms of referencefootnote:[Terms of Reference for the MIWP-8 group: https://ies-svn.jrc.ec.europa.eu/attachments/download/780/Inspire%20MIG%20ToR%20Update%20TG%20Metadata%20final.pdf], this new version of the TG document addresses the following issues:

* Integrate metadata for Spatial Data Services
* Integrate metadata for interoperability
* Integrate theme-specific metadata
* Language neutral identifiers – more use of Anchors
* Review and possibly revise guidelines for implementing the _Unique Resource Identifier_ element
* Review and possibly revise guidelines for implementing “data-service-coupling” (coupled resources)
* Guidelines for implementing the element _conditions applying to access and use_ are not in line with EN ISO 19115:2005.

Possible future work related to metadata (in relation also to other actions in the MIWP 2016-2020) not necessarily involving an update of these guidelines:

* Harmonized restrictions/licenses
* Relation to ISO19115-1:2014
* References to conformance classes in registry (see action 2016.3)
* Using metadata for INSPIRE monitoring and reporting (see action 2016.2)
* Add Abstract Test suite (see action 2016.3)
* Revising the XPaths used in the document to be less restrictive, so that they also match the corresponding elements in all profiles conformant with [ISO 19139]

Another important driver for this revision has been the activities of the group MIWP-5: Validation & conformity testing concerning the Conformance Classes and Abstract Test Suites for the INSPIRE metadata. Several issues concerning the testability and interpretation of technical requirements of the Implementation Rules for metadata expressed in version 1.3 of this document were raised during the drafting of the Test Cases for INSPIRE metadata.

This new version aims at clarifying and expressing technical requirements for INSPIRE metadata, improving the readability of the document, and combining the metadata related technical requirements for INSPIRE data sets, data set series and Spatial Data Services in one document. The technical requirements have been organised into Conformance Classes based on both the type of the described resources (data sets & services) and the different INSPIRE Regulations containing the legal requirements for providing INSPIRE metadata.

In the versions 1.0 - 1.3 of this document the definition of a formal INSPIRE profile of ISO 19115 combined with elements from ISO 19119 formed the basis of the presented technical requirements. The ISO 19115 Core element set was extended with INSPIRE specific constraints and extensions. The mapping from the ISO 19115/19119 elements into XML elements according to ISO/TS 19139 was then implicitly given in the text of the technical requirements and the mapping tables for each of the required metadata element described in the INSPIRE Implementing Rule documents. This hybrid approach of presenting the INSPIRE requirements as an abstract ISO 19115 profile while at the same time stating explicit XML element level requirements in the technical requirements, led to some confusion to what is actually required by the technical specification.

The technical requirements in this version of the specification are presented within the context of the corresponding INSPIRE Regulations, and expressed by mentioning the required XML elements and attributes explicitly. Thus the document aims to provide a clear guidance on how to use the ISO 19139 XML Schemas combined with the XML Schema implementation of ISO 19119 as published by the Open Geospatial Consortium (OGC) for providing all the required metadata elements of the relevant INSPIRE Regulations in an XML format. This clarification in the level of abstraction of the technical requirements was carried out to emphasise that the XML encoding of the metadata based on ISO 19139 standard is required in order to be compliant with this technical specification.

Special care has been taken to not make any unnecessary changes in the required metadata elements in between the version 1.3 and 2.0. The goal has been to only clarify the existing requirements in cases where more than one interpretation of the Implementation Rules existed, or where the required XML encoding was unclear or ambiguous. Some harmonisation between the XML encodings of the elements required by different INSPIRE Regulations has also been done to make the work of the metadata providers and INSPIRE metadata handling software providers easier.

Reading guidance and transition period

As the structure of the document and the expressions have changed considerably from the previous version of the document, the following sections have been included to help the readers in locating the specific elements and technical requirements in this version of the document:

* {blank}
+

The informative Annex B contains the mapping between the ISO 19115:2003 Core elements and INSPIRE Implementing Rules for metadata in section 1.1 of version 1.3.

* {blank}
+

The informative Annex C contains detailed tables for all the INSPIRE metadata elements described in the INSPIRE Regulations for discovery and interoperability metadata. The first section of this annex contains on overview table for these elements with the Regulation references and required INSPIRE multiplicities and conditions of each element.

* {blank}
+

Annex D contains a listing of the code lists referenced in this document including the URI’s of the code lists and their current content.

* {blank}
+

Annex E contains a mapping table between the Implementation Rule sections containing the required metadata elements and the TG Requirements as expressed in the indicated sections in this document.

* {blank}
+

Annex F contains a mapping table between the TG Requirements contained in the version 1.3 and the corresponding TG Requirements in this document. This table also contains the mapping between the Implementation Requirements and Recommendations contained in [TG SDS] and the TG Requirements and Recommendations concerning Spatial Data Services in this document.


As many Member States have already implemented the previous version of the Technical Guidance for metadata, the transition between version 1.3 and 2.0 will require some developments. It is especially true for elements where it has been necessary to modify or clarify the structure or content of the required XML elements. The metadata handling and validating tools created to comply with the Technical Guidance version 1.3 may need updating to fully comply with this version.

To facilitate a smooth transition from version 1.3 to version 2.0, a transitional period of 3 years has been defined, starting from 19 December 2016. During this period, the metadata records compliant with both version 1.3 and 2.0 implementations will be considered as “compliant with the INSPIRE Technical Guidelines for Metadata”. During the transitional period, the validator used in the INSPIRE geoportal will validate against and will provide validation reports for both versions 1.3 and 2.0. The better result will be used for the value of the compliance meter. After the transitional period, the geoportal will only validate against version 2.0.

== Revision history
Changes from the version 1.3 to 2.0

Due to the extensiveness of the structural changes and revision of the textual content for this version, the following list only includes changes directly affecting the TG Requirements and Recommendations.

*+++Requirements/recommendations removed (compared to version 1.3):+++*

* {blank}
+

Section 1.2 INSPIRE specific constraints (SC) has been removed. The restrictions have been integrated into the relevant TG Requirements in the document.

* {blank}
+

TG Recommendation 6 has been removed.

* {blank}
+

TG Recommendations 7 and 8 have been removed.

* {blank}
+

TG Requirement 6 concerning the use of RS_Identifier has been removed.

* {blank}
+

TG Requirement 11 has been removed as redundant due to the required values being specified as an enumeration in the XML Schema.

* {blank}
+

TG Recommendation 13 concerning using both code and human-readable keywords has been removed.


*+++New requirements/recommendations in version 2.0:+++*

* {blank}
+

A new _TG Requirement C.1_ has been added to explicitly require using one of the listed XML Schemas for encoding the [ISO 19115] and [ISO 19119] metadata elements.

* {blank}
+

A new _TG Requirement C.2_ has been added to require the use of MD_Metadata as the parent element for the metadata records.

* {blank}
+

A new _TG Requirement C.3_ has been added to specify encoding the code list values.

* {blank}
+

A new _TG Requirement C.4_ has been added to specify encoding the Non-empty Free Text Elements.

* {blank}
+

New _TG Recommendation 1.8_ and _TG Recommendation 3.4_ have been added to recommend the use on name, description and function properties of CI_OnlineResource element in providing the Resource locator element.

* {blank}
+

A new _TG Recommendation 1.2_ for using resolvable URIs for the data set identification has been added.

* {blank}
+

A new _TG Requirement C.13_ was added to explicitly require that at most one date of last revision is given.

* {blank}
+

A new _TG Requirement C.14_ was added to require the XML encoding of the temporal extent, if given.

* {blank}
+

New _TG Requirement 1.9_ and _TG Requirement 3.8_ have been created to cover the INSPIRE specific constraint SC6 concerning declaring the scope of the _dataQualityInfo_.

* {blank}
+

A new _TG Requirement C.7_ has been added to explicitly require the Metadata date element described in section 2.11.2 of the version 1.3.

* {blank}
+

New _TG Requirement 2.1_ and _TG Requirement 2.2_ were added for requiring describing the Coordinate Reference System (interoperability metadata).

* {blank}
+

A new _TG Requirement 2.3_ was added for requiring describing the Temporal reference systems (interoperability metadata).

* {blank}
+

A new _TG Requirement 2.4_ was added for requiring describing the Spatial representation type (interoperability metadata).

* {blank}
+

A new _TG Requirement 2.5_ was added for requiring describing the Character encoding (interoperability metadata).

* {blank}
+

A new _TG Requirement 2.6_ was added for requiring describing the Data encoding (interoperability metadata).

* {blank}
+

New _TG Requirement 2.7_ and _TG Requirement 2.8_ were added for requiring describing the topological consistency (interoperability metadata).

* {blank}
+

A new _TG Requirement 3.2_ was added to explicitly require _srv:SV_ServiceIdentification_ element to be used for identifying Spatial Data Services.

* {blank}
+

A new _TG Requirement 3.3_ was added to require describing restrictions on spatial resolution for Spatial Data Services within the abstract element.


*+++Changed requirements/recommendations:+++*

* {blank}
+

Providing a non-empty Resource title element (section 2.2.1) is now explicitly required in _TG Requirement C.8_.

* {blank}
+

Providing a non-empty Resource abstract element (section 2.2.2) is now explicitly required in _TG Requirement C.9_.


*+++Renumbered, moved, combined requirements/recommendations:+++*

* {blank}
+

Section 1.1 ISO Core Metadata Elements has been moved into Annex B.

* {blank}
+

TG Requirement 3 concerning the Resource locator element for data sets and dataset series is now the _TG Requirement 1.8._ This requirement also now contains explicit XML element required.

* {blank}
+

TG Requirement 4 concerning the Resource locator element for Services is now the _TG Requirement 3.7_. This requirement also now contains explicit XML element required. The list of the possible resource types the provided URL should point to has been moved into _TG Recommendation 3.5_.

* {blank}
+

TG Requirement 5 concerning the Unique Resource Identifier for data sets and data set series is now the _TG Requirement 1.3_. The IR Requirement for providing both the code and the code space has been interpreted as integrated parts of a single URI character string.

* {blank}
+

TG Recommendation 9 about deleting the Unique Resource Identifiers has been clarified as _TG Recommendation 1.3_.

* {blank}
+

TG Recommendations 3, 4 and 5 have been combined as _TG Recommendation C.4_.

* {blank}
+

The _hierachyLevel_ element required in TG Requirements 1 and 2 is now stated in _TG Requirement 1.1_ (for data sets and data set series) and _TG Requirement 3.1_ (for Spatial Data Services)

* {blank}
+

The content of the TG Requirement 7 concerning Coupled resource for services has been clarified and is now the _TG Requirement 3.6_.

* {blank}
+

The TG Requirements 8 and 9 concerning Resource language are now combined in _TG Requirement 1.6_.

* {blank}
+

The TG Recommendation 10 about the default value for Resource language has now been integrated in _TG Requirement 1.6_. For data sets and series containing non-textual information only, the ISO 639-2/B value "zxx" is now required instead of the previous recommendation for using the metadata language.

* {blank}
+

TG Requirement 10 concerning Topic category is now the _TG Requirement 1.7._

* {blank}
+

TG Requirement 12 concerning the Spatial data service type is now stated as _TG Requirement 3.5_, _TG Requirement 4.1_ (Network services) and _TG Requirement 5.1_ (Invocable Spatial Data Services).

* {blank}
+

TG Requirements 13, 14 and 15 concerning using at least one keyword are now stated as _TG Requirement 1.4_ (for data sets and data set series) and _TG Requirement 3.4_ (for Spatial Data Services).

* {blank}
+

TG Requirement 16 concerning keywords from controlled vocabularies is now integrated into _TG Requirement C.15_.

* {blank}
+

TG Recommendation 11 has been reworded into _TG Recommendation C.7_.

* {blank}
+

TG Recommendation 12 has been split into _TG Recommendation 1.5_ (for data sets and data set series) and _TG Recommendation 3.3_ (for Spatial Data Services).

* {blank}
+

TG Requirements 17 and 18 concerning Originating controlled vocabularies of keywords are now combined in _TG Requirement C.15_.

* {blank}
+

TG Requirement 19 concerning grouping of the keywords referring to the same controlled vocabulary is now stated as the _TG Requirement C.16_.

* {blank}
+

TG Requirements 20 and 21 concerning the Geographic bounding box are now combined into _TG Requirement C.19_. The INSPIRE specific constraint SC13 for specifying the use of any coordinate reference system with Greenwich Prime Meridian has been removed, as the ISO 19139 XML Schema explicitly requires the use in WGS 84 coordinate reference system coordinates in the EX_GeographicBoundingBox element.

* {blank}
+

The TG Requirements 22, 23 and 24 concerning Temporal references have been combined in _TG Requirement C.11_.

* {blank}
+

The TG Requirement 25 has been rephrased as _TG Requirement C.12_ to clarify that the creation date is not mandatory, but one of date of publication, date of creation or date of last revision.

* {blank}
+

TG Requirement 26 concerning the Lineage element is now stated in _TG Requirement 1.11_.

* {blank}
+

TG Requirement 27 concerning Spatial resolution is now stated in _TG Requirement 1.5_ (for data sets and data sets series) and in _TG Requirement 3.3_ (for Spatial Data Services).

* {blank}
+

TG Requirements 28 and 29 concerning the conformity declarations against the INSPIRE Implementation Rules for interoperability of spatial data sets and services is now stated in _TG Requirement 1.10_ (for data sets and data set series) and _TG Requirement 5.3_ (for Invocable Spatial Data Services). TG Recommendation 19 concerning the conformity declarations against the INSPIRE Implementation Rules for network services is now stated in _TG Recommendation 4.1_. The common structure for declaring the conformity against a specification is given in _TG Requirement C.20_, _TG Requirement C.21_ and _TG Requirement C.22_.

* {blank}
+

The TG Requirements 30, 31, 32, 33 and 34 concerning the Limitations on public access and the Conditions applying to access and use elements have been revised and split into _TG Requirement C.17_ about Limitations on public access, and _TG Requirement C.18_ about Conditions applying to access and use. The XML encoding of these elements have been clarified and harmonised. For both elements only the _MD_LegalConstraints_ shall now be used containing a combination of _accessConstraints_, _useConstraints_ and _otherConstraints_ as described in sections 2.3.6 and 2.3.7. Referring to the new INSPIRE code lists for the reason of the Limitations on public access as well as Conditions applying to access and use ("no conditions" or "unknown") is now mandatory using the _gmx:Anchor_ element.

* {blank}
+

TG Requirements 35 and 36 as well as the INSPIRE specific constraint SC14 concerning the responsible organisation are now covered by _TG Requirement C.10_.

* {blank}
+

TG Requirements 37 and 38 concerning the Metadata point of contact are now given as _TG Requirement C.6_.

* {blank}
+

TG Requirement 39 concerning the Metadata language is now stated as _TG Requirement C.5_.


== Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. For ISO standards that have also been adopted as EN by CEN, the relevant CEN reference and adoption date are given, with the ISO number and adoption date in parentheses.

[ISO/IEC Directives Part 2] ISO/IEC Directives Part 2: Principles to structure and draft documents intended to become International Standards, Technical Specifications or Publicly Available Specifications, 7^th^ edition, 2016.

[ISO 19105] EN ISO 19105:2005, Geographic Information – Conformance and testing (ISO 19105:2000)

[ISO 19108] EN ISO 19108:2005, Geographic Information – Temporal Schema (ISO 19108:2002)

[ISO 19112] EN ISO 19112:2005, Geographic Information – Spatial referencing by geographic identifiers (ISO 19112:2003)

[ISO 19115] EN ISO 19115:2005, Geographic information – Metadata (ISO 19115:2003)

[ISO 19119] EN ISO 19119:2005, Geographic information – Services (ISO 19119:2005)

[ISO 19139] ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation

[ISO 639-2] ISO 639-2:1998, Codes for the representation of names of languages – Part 2: Alpha-3 code

[ISO 8601] ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times

[CSW2 AP ISO] OpenGIS Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile, Version 1.0.0, OGC 07-045, 2007

[INSPIRE Directive] Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

[Regulation 1205/2008] Commission Regulation (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata.

NOTE [Regulation 1205/2008] is informally also known as "Implementing Rules for metadata".

[Regulation 976/2009] Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services, as amended by

* Commission Regulation (EC) No 1088/2010 of 23 November 2010 amending Regulation (EC) No 976/2009 as regards download services and transformation services; and
* Commission Regulation (EU) No 1311/2014 of 10 December 2014 amending Regulation (EC) No 976/2009 as regards the definition of an INSPIRE metadata element

NOTE [Regulation 976/2009] is informally also known as "Implementing Rules for network services".

[Regulation 1089/2010] Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services, as amended by

* Commission Regulation (EU) No 102/2011 of 4 February 2011 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services;
* Commission Regulation (EU) No 1253/2013 of 21 October 2013 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services; and
* Commission Regulation (EU) No 1312/2014 of 10 December 2014 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data services.

NOTE [Regulation 1089/2010] is informally also known as "Implementing Rules for interoperability of spatial data sets and services" or IR-ISDSS for short.

[OGC Specification Model] The Specification Model – A Standard for Modular specifications, Open Geospatial Consortium, OGC 08-131r3, https://portal.opengeospatial.org/files/?artifact_id=34762

== Other references
[TG SDS] Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked, version 4.0, http://inspire.ec.europa.eu/id/document/tg/sds/4.0

[TG DiscoveryS] Technical Guidance for INSPIRE Discovery Services, version 3.1, http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_v3.1.pdf

[TG ViewS] Technical Guidance for the implementation of INSPIRE View Services, version 3.11, http://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf

[TG DownloadS] Technical Guidance for the implementation of INSPIRE Download Services, version 3.1, http://inspire.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf

[TG DS] Technical Guidelines – INSPIRE data specifications, http://inspire.ec.europa.eu/index.cfm/pageid/2

[ISO 19115-1] ISO 19115-1:2014, Geographic information – Metadata – Part 1: Fundamentals

[ISO 19115-3] ISO/TS 19115-3:2016, Geographic information – Metadata – Part 3: XML schema implementation for fundamental concepts

[ISO 19157] ISO 19157:2013, Geographic information -- Data quality.

NOTE This document is not listed under normative references because it is only referred as an inspiration for the ISO 19139 encoding of the INSPIRE metadata elements Topological consistency and Data quality. The ISO 19157:2013 standard should be used together with a newer version of ISO metadata standard for geographic information, [ISO 19115-1].

[ISO 10646] ISO/IEC 10646:2014, Information technology -- Universal Coded Character Set (UCS)

[ISO 15836] ISO 15836:2009, Information and documentation – The Dublin Core metadata element set

== Terms and abbreviations
The terms concerning requirements, conformance test classes and tests are based on the OGC document The Specification Model - A Standard for Modular specifications (08-131r3)footnote:[See http://www.opengeospatial.org/standards/modularspec]. Note that the intermediate structuring entities "requirements module" and "conformance module" are not included here for simplicity. Instead, the requirements are directly included in requirements classes and conformance tests in conformance test classes.

*Abstract test suite (ATS)* is a set of _conformance classes_ that define tests for all requirements of a specification [derived from OGC Specification Model and ISO 19105]

*Access point* (of a Spatial Data Service) is an URL for retrieving a detailed description of a _Spatial Data Service_, including a list of _end points_ to allow its execution.

*Conformance class* is a set of _conformance test modules_ that must be applied to receive a single certificate of conformance [OGC Specification Model]

*Conformance test module* (or abstract test module) is a set of related _conformance test cases_, all within a single _conformance class_ [OGC Specification Model]

*Conformance test case* (or abstract test case) is a test for a particular _requirement_ or a set of related requirements [OGC Specification Model].

NOTE An abstract or conformance test case is a formal basis for deriving executable test cases. It should be complete in the sense that it is sufficient to enable a test verdict to be assigned unambiguously to each potentially observable test outcome.

*(Spatial) data set* is an identifiable collection of (spatial) data [INSPIRE Directive].

*(Spatial) data set series* is a collection of (spatial) data sets sharing the same product specification [Regulation 1205/2008].

*Discovery Service* is a service that makes it possible to search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata [INSPIRE Directive, Art. 11].

*Download Service* is a service enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly [INSPIRE Directive, Art. 11].

*End point* (of a Spatial Data Service) is an URL used for directly calling an operation provided by the _Spatial Data Service_.

*Executable test suite* (ETS) is a set of executable test cases [ISO 19105].

*Harmonised Spatial Data Service* is an interoperable spatial data service which fulfils the requirements of Annex VII [Regulation 1089/2010, Art. 1].

*Interoperable Spatial Data Service* is an invocable spatial data service which fulfils the requirements of Annex VI [Regulation 1089/2010, Art. 1].

*Invocable Spatial Data Service* is a spatial data service that (a) has metadata which fulfils the requirements of [Regulation 1205/2008], (b) has at least one resource locator that is an access point, (c) is conformant with a documented and publicly available set of technical specifications providing the information necessary for its execution [Regulation 1089/2010, Art. 1].

*Network Services* are services provided for in Article 11(1) of [INSPIRE Directive] for the discovery, viewing, download and transformation of spatial data sets and services. The service shall be conformant regarding the specific requirements in [Regulation 976/2009].

*Non-empty Free Text Element* is an XML element with textual content encoded either using _gco:CharacterString_, _gmx:Anchor_ or _gmd:PT_FreeText_ element of the ISO 19139 XML Schema. See section 2.2 for more information.

NOTE The technical specifications could e.g. be a web site documentation explaining how to use the service, or they could be more formal, e.g. a WSDL document or a description of a RESTful interface.

*Recommendation* is an expression in the content of a document conveying a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others. In the negative form, a recommendation is the expression that a suggested possible choice or course of action is not preferred but it is not prohibited [ISO/IEC Directives Part 2].

*Requirement* is an expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted. [ISO/IEC Directives Part 2].

*Spatial Data Services* are the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata [INSPIRE Directive, Art. 3].

*Statement of conformity* is the result of running an _executable test suite_, and it contains statements about the conformity of the particular _conformance subject_ against the _conformance test classes_ implemented in the used _executable test suite._ The statement of conformity has no legal significance as itself, but it can be a useful tool for evaluating the conformity of the particular _conformity subject_ against the legal regulations the tests in the _conformance test classes_ of the particular _conformance test suites_ are founded on.

*Transformation Service* is a service enabling spatial data sets to be transformed with a view to achieving interoperability [INSPIRE Directive, Art. 11].

*View Service* is a service making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata [INSPIRE Directive, Art. 11].

== Verbal forms for expression of provisions
In accordance with the ISO rules for drafting, the following verbal forms shall be interpreted in the given way:

* “shall” / “shall not”: a requirement, mandatory to comply with the technical guidelines
* “should” / “should not”: a recommendation, but an alternative approach may be chosen for a specific case if there are reasons to do so
* “may” / “need not”: a permission

Requirements and recommendations notation

Requirements and the recommendations for INSPIRE Metadata Implementing Rules within this specification are highlighted and numbered as shown below:

[IMPORTANT]
====
*TG Requirement #.#: metadata/2.0/req/<conformance-class-id>/<requirement-id>*

Technical Guidelines Requirements are shown using this style
====

[TIP]
====
*TG Recommendation #.#: metadata/2.0/rec/<conformance-class-id>/<requirement-id>*

Technical Guidelines Recommendations are shown using this style.
====

The requirements and recommendations are grouped into Conformance Classes containing all the requirements specific to a particular type of metadata record or a requirement set originating with a particular Implementation Rule document.

The Conformance Class definitions in this specification are highlighted and numbered as shown below:

[NOTE]
====
*Conformance Class #*: *metadata/2.0/<conformance-class-id>*

Conformance Classes are shown using this style.
====

Recommendations and requirements are prefixed with the number of their conformance class and numbered consecutively. Requirements and recommendations that are common to several conformance classes (see section 2) are prefixed with C (for “Common”).

Each conformance class, requirement and recommendation also have a unique identifier consisting of a common namespace (*metadata/2.0/, metadata/2.0/req/* and *metadata/2.0/rec/*, respectively), the id of the conformance class and the id of the requirement or recommendation.

NOTE Requirements as specified in the INSPIRE Regulations and Implementing Rules are legally binding, and that requirements and recommendations as specified in INSPIRE Technical Guideline are not legally binding. Therefore, within this technical guideline we have used the terms ‘TG requirement’ and ‘TG recommendation’ to indicate what is technically required or recommended to conform to this Technical Guidelines specification.

Quoted INSPIRE Regulation text

Directed quotations from INSPIRE Implementation Rules and other legally mandated regulations are expressed as quoted text blocks using the following style:

{empty}
____
5. TEMPORAL REFERENCE

This metadata element addresses the requirement to have information on the temporal dimension of the data as referred to in Article 8(2)(d) of Directive 2007/2/EC. At least one of the metadata elements referred to in points 5.1 to 5.4 shall be provided. The value domain of the metadata elements referred to in points 5.1 to 5.4 is a set of dates. Each date shall refer to a temporal reference system and shall be expressed in a form compatible with that system. The default reference system shall be the Gregorian calendar, with dates expressed in accordance with ISO 8601.
____

XPath expressions

XML Path Language (XPath) is a W3C Recommendation for addressing parts of an XML documentfootnote:[XML Path Language (Xpath), version 1.0, https://www.w3.org/TR/xpath/]. This compact notation allows many defaults and abbreviations for common cases. The simplest XPath takes a form such as /A/B/C which selects C elements that are children of B elements that are children of the A element that forms the outermost element of the model. More complex expressions can be constructed by specifying an axis other than the default 'child' axis, a node test other than a simple name, or predicates, which can be written in square brackets after any step. The main rules are the following ones:

* selects all element children of the context node;

text() selects all text node children of the context node;

@name selects the name attribute of the context node;

@* selects all the attributes of the context node;

. selects the context node;

.//para selects the para element descendants at any level of the context node;

.. selects the parent of the context node.

In this document XPath expressions are used for exactly specifying the locations of the required and recommended XML elements within the XML document structure containing the metadata content. Sometimes, in order to manage the polymorphism, the XPath expression deals with some elements in the path in a generic way (e.g., property_element_name/*/datatype_property_name). This is done for example for some requirements and examples to be applicable to both data set and service identification elements.

Where profiles conformant to [ISO 19139] are being used to encode INSPIRE metadata records, the XPath expressions used in the text of TG requirements may need to be adapted to match the profile.

XML examples

The XML examples are numbered for easier referencing and shown as text blocks with a fixed-width font on a grey background:

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:hierarchyLevel:**

<gmd:hierarchylevel>
  <gmd:md_scopecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" codelistvalue="dataset">
  </gmd:md_scopecode>
</gmd:hierarchylevel>
----
*Example X.Y*: Resource type "dataset" given using gmd:hierarchyLevel property

The location of the XML elements within the document structure is given using XPath syntax at the top of the text block in bold font.

NOTE XML Examples are informative and are provided for information only and are expressly not normative.

Numbering of requirements, examples, figures and tables

The TG Requirements, TG Recommendations, XML examples, tables and figures are numbered using two-part, dot-separated identifiers: The first part refers to the containing Conformance Class and the second is a running number within the Conformance Class. In the chapter 2 "Common requirements for ISO/TC 19139:2007 based INSPIRE metadata records" which does not comprise a Conformance Class, but is referred to from the Conformance Class chapters, the first part is a letter "C". This numbering style is used to help associating the referred requirements with their containing Conformance Classes.

XML namespaces and prefixes used in this document

XML element prefixes are used in this document to refer to the namespaces as follows:

[width="100%",cols="16%,84%",]
|===
|*prefix* |*Namespace URI*
|gmd |http://www.isotc211.org/2005/gmd
|gco |http://www.isotc211.org/2005/gco
|gmx |http://www.isotc211.org/2005/gmx
|srv |http://www.isotc211.org/2005/srv
|gml |http://www.opengis.net/gml/3.2 (for GML 3.2.1) or +
http://www.opengis.net/gml (for GML 3.2.0)
|xsi |http://www.w3.org/2001/XMLSchema-instance
|xlink |http://www.w3.org/1999/xlink
|===

:sectnums:

== Overview

=== Introduction

Data sets and the Spatial Data Services providing them need to be discoverable by the people requiring the provided information to be available. In INSPIRE the discoverability of these resources is based on two equally important things: the data and service providers describing their resources using the metadata elements according to rules mandated by the INSPIRE Regulations, and on the other hand, the Discovery Services providing online access to query the provided metadata.

Both of the components mentioned above need to be functional and kept up-to-date to enable the Infrastructure of Spatial Information in Europe. The technical requirements for providing Discovery Services are given in [TG DiscoveryS], and the requirements for the metadata content and structure in this document.

[INSPIRE Directive], recital 15:

{empty}
____
(15) The loss of time and resources in searching for existing spatial data or establishing whether they may be used for a particular purpose is a key obstacle to the full exploitation of the data available. Member States should therefore provide descriptions of available spatial data sets and services in the form of metadata.
____

[INSPIRE Directive], Article 5(1):

{empty}
____
1. Member States shall ensure that metadata are created for the spatial data sets and services corresponding to the themes listed in Annexes I, II and III, and that those metadata are kept up to date.
____

According to Article 5(4) of [INSPIRE Directive], Implementing Rules shall be adopted taking account of relevant, existing international standards and user requirements. In the context of metadata for spatial data and Spatial Data Services, the standards [ISO 19115], [ISO 19119], [ISO 19139] and [ISO 15836] (Dublin Core) have been identified as important standards or technical specifications.

[Regulation 1205/2008] containing the legal requirements for providing the INSPIRE metadata was adopted on of 3^rd^ December 2008, and published on the Official Journal of the European Union on 4^th^ December (_OJ L 326, 4.12.2008, p. 12–30)_. Any reference in this document to “Implementing Rules for Metadata” refers to the above-mentioned regulation.

The [Regulation 1205/2008] sets out the requirements for the creation and maintenance of metadata for spatial data sets, spatial data set series and Spatial Data Services corresponding to the themes listed in Annexes I, II and III of the [INSPIRE Directive]footnote:[The metadata elements defined in the Implementing Rules for Metadata are usually called discovery metadata.]. It defines a number of metadata elements, their multiplicities and the value domains to be used in the metadata.

In addition to [Regulation 1205/2008], [Regulation 1089/2010] and its first two sub-sequent amendmentsfootnote:[Commission Regulation (EU) No 102/2011 of 4 February 2011 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services (OJ L 31, 05/02/2011, p. 13–34)],^,^footnote:[Commission Regulation (EU) No 1253/2013 of 21 October 2013 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services (Annex II+III amendment).] define six additional _metadata elements for interoperability_ as well as some theme-specific requirements for the discovery metadata elementsfootnote:[The metadata elements defined in the Implementing Rules for interoperability of spatial data sets and services are also sometimes referred to as evaluation and use metadata.]. Any reference in this document to “Implementing Rules for interoperability of spatial data sets and services” refers to the above-mentioned Regulation.

The third of the most relevant documents concerning INSPIRE metadata is [Regulation 1312/2014] amending [Regulation 1089/2010]. It contains additional requirements for the metadata of INSPIRE Spatial Data Services categorised in three levels of harmonisation: Invocable, Interoperable and Harmonised Spatial Data Services. The additional requirements for each category were added as Annexes V to VII of [Regulation 1089/2010].

The aim of this document is to define how the requirements of the mentioned INSPIRE regulations for metadata can be implemented using an XML format defined in [ISO 19139] based on data models of [ISO 19115] and [ISO 19119] to achieve harmonised technical access and use of the INSPIRE metadata for spatial data sets from all INSPIRE themes and Spatial Data Services used for providing and processing them across all EU Member States.

==== Roadmap and timelines for provisioning INSPIRE metadata

The timelines relevant for the provision of discovery metadata are different from those for metadata for interoperability. The former need to be provided according to the deadlines specified in the INSPIRE Directive for the Implementing Rules for Metadata (2 years after adoption for Annex I and II and 5 years after adoption for Annex III), while the latter need to be provided according to the deadlines specified in the INSPIRE Directive for the Implementing Rules for interoperability of spatial data sets and services (2 years after adoption for newly created or extensively restructured data sets, and 7 years for all other data sets).

Figure 2 gives an overview of the dates at which the requirements included in the two Implementing Rules for data sets related to Annex I, II or III have to be metfootnote:[Dates in this figure are accurate at the time of publication. For definitive dates refer to the roadmap published on the INSPIRE website (http://inspire.ec.europa.eu/inspire-roadmap/61).].

image:.\media/image3.png[image,width=563,height=424]

*Figure* *2:* Illustration of Implementation Roadmap for discovery metadata, metadata for interoperability, and metadata for Invocable Spatial Data Services.

==== Categories of INSPIRE Spatial Data Services

The spatial data services covered by the INSPIRE Directive are defined in Art. 4(3) as follows:


____
“This Directive shall also cover the spatial data services relating to the data contained in the spatial data sets referred to in paragraph 1.”
____

This means, the Directive covers all SDS that relate to INSPIRE-relevant data as defined in Art. 4(1) of [INSPIRE Directive]. In addition, an SDS could also include other data.

According to Art. 5(1) of [INSPIRE Directive], all SDSs within INSPIRE shall be described with metadata in conformity with [Regulation 1205/2008].

The SDSs that Member States establish and operate according to Art. 11 of [INSPIRE Directive] are called _network services_. All network services shall meet the requirements specified in [Regulation 976/2009].

Those SDS that are not network services, but fulfil the requirements of [Regulation 1205/2008], have at least one resource locator and follow a publicly available technical specification are called _invocable spatial data services_. All invocable SDS shall meet the requirements specified in [Regulation 1089/2010]. All other SDS are referred to in this document as _other SDS_.

SDS regulated by [Regulation 1089/2010] are further divided into three different categories depending on level of interoperability: Invocable SDS, Interoperable SDS and Harmonised SDS. SDS regulated by [Regulation 976/2009] (i.e. _network services_) consist of four different types of services: discovery services, view services, download services and transformation services.

Figure 3 gives an overview of the different types of spatial data services.

image:.\media/image4.png[image,width=563,height=307]

*Figure* *3*: Spatial data services in the context of INSPIRE and their relationships to different types and categories of services. * Discovery Services also take the role as making it possible to invoke a service. [TG SDS]

=== XML Encoding of ISO metadata

This encoding of the INSPIRE metadata in this technical specification is based on the ISO Standards [ISO 19115], [ISO 19119] and [ISO 19139]. The abstract standards [ISO 19115] and [ISO 19119] provide a structural model and specify the content of the set of metadata elements used in this specification, but they do not specify the encodings of those elements. The [ISO 19139] specifies an XML encoding of [ISO 19115] elements, but not for the service-specific metadata elements contained in [ISO 19119]. To provide an XML encoding also for the INSPIRE service metadata, XML Schemas implementing the [ISO 19119] model have been published by the OGCfootnote:[http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd]. These XML Schemas, though not officially endorsed by ISO, are widely used within the metadata community, and have been chosen to be used also in INSPIRE since version 1.0 of this specification.

NOTE Currently, the _gmx_ namespace is not included in the referenced schema for [ISO 19119]. Consequently, all elements defined in the gmx namespace (e.g. gmx:Anchor) are not valid according to this schema. This issue has been raised with OGCfootnote:[See OGC change request at http://ogc.standardstracker.org/show_request.cgi?id=435]. Until the OGC agrees to host a version of the xml schema that fixes the known problems, these will be hosted by JRCfootnote:[The schemas are made available as draft schemas on the INSPIRE schema repository at http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/apiso-inspire/apiso-inspire.xsd and http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/srv/1.0/].

The requirements defined in this document are based on [ISO 19139], which in turn is an implementation of the [ISO 19115], and OGC XML Schema implementation of the [ISO 19119].

NOTE ISO 19115:2003 has been recently replaced by the new Standard named 19115-1:2014, describing general-purpose metadata. This new revision is a part of an overall ISO standard 19115 on geographic metadata, along with 19115-2, regarding the extensions for acquisition and processing, and 19115-3 defining the XML schema implementation of metadata fundamentals. In relation with the issues addressed in this document, the main changes in the new standard are the following:

* {blank}
+

The concept of ‘Core metadata’ was removed and was translated into the normative Annex F (of [ISO 19115-1]) describing the discovery metadata for geographic resources (datasets, series and services);

* {blank}
+

Metadata for services deriving from ISO 19119 was included;

* {blank}
+

Metadata concerning data quality was moved to the new specific Standard ISO 19157.


It was decided in the MIWP-8 sub-group that new versions of the ISO 19115 standard were out of scope for this version of this specification. The future versions of this Technical Guidelines may be revised taking into account the new ISO 19115 family standards.

A comparison between the core metadata given in [ISO 19115], the INSPIRE metadata elements for spatial datasets, spatial dataset series and services as defined in [Regulation 1205/2008], and the discovery metadata for geographic datasets, series and services defined in [ISO 19115-1] is available in the Annex III of the GeoDCAT-AP specificationfootnote:[See https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/geodcat-ap-v10].

=== INSPIRE Validator Service

A RESTful Web service that can be invoked by http request to validate INSPIRE Metadata has been created by the JRC (http://inspire-geoportal.ec.europa.eu/validator2/).

NOTE The validator is not intended to be an operational tool, and at the time of writing only supports validation against version 1.3 of the metadata technical guidelines.

All the files of the Validator including documentation are available under EU Public License from the JoinUp Platform (https://joinup.ec.europa.eu/software/validator/home). Interested stakeholders are welcome to adapt the current Validator to their own language, and contribute it back through JoinUp to enrich the collective portfolio of tools supporting the implementation of INSPIRE.

At the time of writing, the design and implementation of a new, more comprehensive INSPIRE validator containing validation functionality for data sets, services and metadata is in progress under the work of the MIG temporary sub group MIWP-5: Validation and conformity testing, with support through the ISA Action ARE3NA (A Reusable INSPIRE Reference Platform, https://joinup.ec.europa.eu/community/are3na/description). This new validator will implement the Conformance Classes for requirements in versions 1.3 and 2.0.

=== Position and structure of this document

This document is a technical specification for implementing the legal requirements of the [INSPIRE Directive] and related Commission Regulations for providing the spatial data sets and Spatial Data Services metadata. The purpose of this specification is to provide a standards compliant and unambiguous technical method for providing all the required metadata required by INSPIRE Regulations using XML encoding based on [ISO 19139] standard.

In addition to the structural requirements formalized through required XML elements in the Technical Guidelines Requirements of this specification, the conformance to INSPIRE is a matter of semantics of the information provided. The minimum requirements expressed in the Implementing Rules also have to be met semantically, i.e. with metadata contents strictly satisfying the INSPIRE requirements.

The INSPIRE Maintenance and Implementation Group (MIG) strongly recommends the EU Member States follow the technical requirements given in this specification for providing the metadata describing the INSPIRE spatial data sets and Spatial Data Services. Harmonisation beyond the abstract level of requirements contained in the INSPIRE Regulations is necessary for reaching the goals of data set and service interoperability and information reuse set for the Infrastructure of Spatial Information in Europe.

This specification consists of 7 Conformance Classes (see also *Figure 4*):

* Conformance Class 1: INSPIRE data sets and data set series baseline metadata (section 3.1),
** {blank}
+

Conformance Class 2: INSPIRE data sets and data set series interoperability metadata (section 3.2),

* Conformance Class 3: INSPIRE Spatial Data Service baseline metadata (section 4.1),
** {blank}
+

Conformance Class 4: INSPIRE Network Services metadata (section 4.2),

** {blank}
+

Conformance Class 5: INSPIRE Invocable Spatial Data Services metadata (section (4.3),

*** {blank}
+

Conformance Class 6: INSPIRE Interoperable Spatial Data Services metadata (section 4.4), and

*** {blank}
+

Conformance Class 7: INSPIRE Harmonised Spatial Data Services metadata (section 4.5).


The indention of the above list indicates the requirement inclusion hierarchy between Conformance Classes: A Conformance Class intended as sub-element in the list also includes all the TG Requirements of the parent level Conformance Classes. Section 2 contains TG Requirements and Recommendations describing metadata elements that shall be used in the same way in more than one of the mentioned Conformance Classes.

image:.\media/image5.png[image,width=604,height=344]

*Figure* *4*: Structure of the conformance classes in this Technical Guidance document.

==== TG Requirements, TG Recommendations and conformance

The TG Requirements of this specification have been selected to cover all the requirements of the INSPIRE Implementing Rule regulations for the metadata descriptions of the INSPIRE data set and services. All the TG Requirements included in each of the Conformance Classes of this specification shall be fulfilled in order for conformance subject (metadata record) to be considered compliant with the Conformance Class. Furthermore, any metadata record fulfilling all the TG Requirements included in a Conformance Class shall be considered compliant with that Conformance Class.

In addition to the TG Requirements, the document sections defining the Conformance Classes also include TG Recommendations. These recommendations suggest additional, non-mandatory methods for increasing the interoperability, and harmonisation of the provided metadata, or propose good defaults to content of structure of the metadata, where several options for expression are allowed. The TG Recommendations should be followed if there are no compelling reasons not to. Following or not following TG Recommendations shall not be considered as measure of conformance against their containing Conformance Classes.

The conformity with a Conformance Class shall be evaluated as defined in the Abstract Test Suites in Annex A, which shall include Test cases for each of the TG Requirements included in the Conformance Class. The Abstract Test Suites may also include tests for fulfilling the TG Recommendations to provide further interoperability improvement or deprecation hints to help both the metadata providers and the INSPIRE metadata handling software developers. If included, the failure or success of passing these TG Recommendation tests shall not have an effect of the evaluated conformance measure of the metadata record under test.

== Common requirements for ISO/TC 19139:2007 based INSPIRE metadata records

=== Metadata structure and encoding

[IMPORTANT]
====
*TG Requirement C.1: metadata/2.0/req/common/xml-schema*

INSPIRE metadata records shall be encoded in XML format valid against one of the following XML Schemas:- [*CSW2 AP ISO*] XML Schemafootnote:[http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/ importing the _srv_ namespace for encoding service metadata and referring to GML version 3.2.1 available in the OGC schema repository (as defined in the schemas at http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/srv/1.0/), or an unmodified copy.],- [*ISO 19139*] XML Schema as available in the ISO repositoryfootnote:[_http://www.isotc211.org/2005/gmd/gmd.xsd_ referring to GML version 3.2.1 available in the ISO schema repository, or an unmodified copy.], or- [*ISO 19139*] XML Schema as available in the OGC schema repositoryfootnote:[_http://schemas.opengis.net/iso/19139/20070417/gmd/gmd.xsd_ referring to GML version 3.2.1 available in the OGC schema repository, or _http://schemas.opengis.net/iso/19139/20060504/gmd/gmd.xsd_ referring to GML version 3.2.0 available in the OGC schema repository, or unmodified copies of either of these.].

All three of these XML Schemas declare the same namespace http://www.isotc211.org/2005/gmd[_http://www.isotc211.org/2005/gmd_].

The metadata identification info property for INSPIRE Spatial Data Services shall be encoded using the service metadata XML Schema available in the OGC schema repository. This schema is an XML implementation of the [ISO 19119] service metadata, and it declares the namespace http://www.isotc211.org/2005/srv.
====

NOTE These guidelines extensively use XPath expressions in the requirements and recommendations. If profiles conformant to [ISO 19139] are being used to encode INSPIRE metadata records, these XPath expressions may need to be adapted to match the profile.

The choice of which XML Schemas to use for encoding the metadata records depends on the existing technical solutions available, as well as on the GML version wished to be used:

* {blank}
+

If the delivery of the metadata records is done via a Discovery Service supporting the [CSW2 AP ISO] standard, using the XML Schema of this specification is a natural choice. The [CSW2 AP ISO] XML Schema imports the OGC version 2006-05-04 of the _gmd_ namespace, and through it the OGC GML XML Schema version 3.2.0. The [CSW2 AP ISO] XML Schema also imports the _srv_ namespace for describing service metadata. Note that GML 3.2.0 has target namespace _http://www.opengis.net/gml,_ the same as GML version 3.1.1.

* {blank}
+

If using GML version 3.2.1 in the metadata (namespace _http://www.opengis.net/gml/3.2_), then it is recommended to use either the official [ISO 19139] XML Schema available at the ISO schema repository, or the nearly identical version “2007-04-07” available in the OGC schema repository. Note that in this case, the same _srv_ namespace elements referring to GML 3.2.0 would still be required for describing service metadata. This means that for service metadata records there may two versions of GML in use at the same time from namespaces _http://www.opengis.net/gml_ and _http://www.opengis.net/gml/3.2_.


[IMPORTANT]
====
*TG Requirement C.2: metadata/2.0/req/common/root-element*

The metadata for an INSPIRE data set, data set series or service shall be encoded using exactly one gmd:_MD_Metadata_ element as specified in the XML Schema rules and in the TG Requirements of the Conformance Classes in this specification.

Additionally the requirements of [ISO 19139], [ISO 19115] and [ISO 19119] shall be followed for describing the metadata records in cases where neither the XML Schemas nor the TG Requirements in this specification require otherwise.
====

Note that the use of these guidelines to create INSPIRE metadata ensures that the metadata is not in conflict with [ISO 19115] or [ISO 19119]. However, full conformance to [ISO 19115] implies the provision of additional metadata elements which are not required by the INSPIRE Implementing Rules and thus out-of-scope of this specification.

==== Encoding of code list values

INSPIRE metadata elements that are mapped to code lists from [ISO 19139], the relevant requirements mention the code list to be used.

[IMPORTANT]
====
*TG Requirement C.3: metadata/2.0/req/common/code-list-value*

The code list value shall be encoded using the _codeListValue_ attribute of the relevant ISO 19139 element. The value shall be the identifier of the code list value, as defined in the name column of the tables in [ISO 19115], Annex B.
====

Note that [ISO 19115] allows code lists to be extended. In cases, where, for the INSPIRE metadata elements, only the values defined in [ISO 19115, Annex B] (or a subset thereof), can or should be used, this is stated in the relevant requirement or recommendation. Additional extended values may still be used, but may be ignored by INSPIRE metadata clients.

Both the value of the codeList attribute (a URL that references a code list definition within a register or a code list catalogue) and the textual content of the ISO 19139 element are purely informative. The codeList value may e.g. point to the code list dictionary in the ISO 19139 repository at http://standards.iso.org/iso/19139/resources/codelist/, and if a text is provided, it may contain the translation of the code list value in the language of the metadata.

[source,xml,subs="+quotes"]
----
<ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/codelist/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="creation">
  Creazione
</ci_datetypecode>
----
*Example* *2.1*: An instance of CI_DateTypeCode expressed in the default language of the metadata (here: Italian).

In some cases, an INSPIRE metadata element is mapped to a free-text element in ISO 19139, but these TGs recommend or require the use of a code list value through an _gmx:Anchor_ element (see section 2.1.2). In these cases, the relevant requirements/recommendations specify how to use the _gmx:Anchor_ element.

==== Encoding of free text values

The ISO 19139 XML Schemas allow using alternative ways of encoding free text. The basic element for providing text of unrestricted length with no internal XML structure is _gco:CharacterString_. This element is appropriate when the text does not refer to a specific external resource or registry, and it is not necessary to highlight the fact that the text is provided using a particular natural language or locale.

[source,xml,subs="+quotes"]
----
<gmd:keyword>
  <gco:characterstring>
    weather data
  </gco:characterstring>
</gmd:keyword>
----
*Example* *2.2*: A (user-defined) keyword declared using gco:CharacterString.

When the provided text is a term or code referring to an externally defined explanation or registry value, _gmx:Anchor_ element is recommended over _gco:CharacterString_. It contains and additional attribute group enabling linking the provided piece of text with an external describing resource. The most important of these attributes in this context is _xlink:href_, which contains the actual reference in URIfootnote:[Unique Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. In the Internet related technical context the URI is defined by the IETF Internet Standard "Uniform Resource Identifier (URI): Generic Syntax" (RFC 3986).] format.

[source,xml,subs="+quotes"]
----
<gmd:keyword>
  <gmx:anchor xlink:href="http://inspire.ec.europa.eu/theme/mf">
    Meteorological geographical features
  </gmx:anchor>
</gmd:keyword>
----
*Example* *2.3*: A keyword declared using gmx:Anchor element pointing to the controlled vocabulary from which it is taken (in this case, the INSPIRE theme register).

The text value of the _gmx:Anchor_ element should be still be given in addition to the _xlink:href_ attribute, and it should be given in a form intended for human observation. If the text is a natural language term, and there is well-known translation of it in the language of the metadata record, the translation could be used as the value of the element.

In the ISO 19139 XML Schema the _gmx:Anchor_ element is defined as substitution to _gco:CharacterString_ meaning that it is syntactically allowed to use _gmx:Anchor_ element instead of _gco:CharacterString_ in any parts of the XML document where _gco:CharacterString_ element is required by the XML Schema rules.

There is also a third element defined in the ISO 19139 XML Schema for expressing free text: _gmd:PT_FreeText_. This element is intended for providing textual data with an explicit mention of the locale of the provided text. The _gmd:PT_FreeText_ element is not defined as the head of the substitution group for _gco:CharacterString element_, and thus cannot be used as a drop-in replacement for it in the way that the _gmx:Anchor_ element can. However, its structure can still be re-used by dynamically re-typing the parent element using _xsi:type_ attribute. Through this mechanism it is possible to narrow down the type of an XML element to a type derived from the one originally defined for the element in the XML Schema rules. In this case the parent elements containing the _gco:CharacterString_ element (of type _gco:CharacterString_PropertyType_) can be locally re-typed to _gmd:PT_FreeText_PropertyType_ (see Example 2.4).

[source,xml,subs="+quotes"]
----
<gmd:organisationname xsi:type="gmd:PT_FreeText_PropertyType">
  <gco:characterstring>
    Ilmatieteen laitos
  </gco:characterstring>
  <gmd:pt_freetext>
    <gmd:textgroup>
      <gmd:localisedcharacterstring locale="#locale-swe">
        Meteorologiska institutet
      </gmd:localisedcharacterstring>
    </gmd:textgroup>
    <gmd:textgroup>
      <gmd:localisedcharacterstring locale="#locale-en">
        Finnish Meteorological Institute
      </gmd:localisedcharacterstring>
    </gmd:textgroup>
  </gmd:pt_freetext>
</gmd:organisationname>
----
*Example* *2.4*: gmd:organisationName element dynamically re-typed to gmd:PT_FreeText_PropertyType allowing gmd:PT_FreeText to be added in addition to gco:CharacterString child element.

When re-typed, the property element allows both _gco:CharacterString_ and _gmd:PT_FreeText_ children to be provided. A _gmd:PT_FreeText_ element may in turn contain zero or more _gmd:textGroup_ elements, each containing a localised textual content with an explicit locale attribute referring to a locale _description_ with a language code and a character set, and optionally a country. The element _gmd:MD_Metatada/gmd:locale_ may be used for defining the referred locale definitions within the metadata record using a local XPointer URLfootnote:[Uniform Resource Locator is a reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI).] reference (see Example C.4). Note that providing the _gco:CharacterString_ element in addition to the _gmd:PT_FreeText_ element is required to make it easier for automatic metadata processing systems to find the free text content even if they are not able to understand the _gmd:PT_FreeText_ structure.

Note that using explicitly localised free text is usually not required in INSPIRE metadata records, as the entire metadata record must be provided using the same natural language (see section 2.3.1). Localised versions of the metadata records are provided by using the language selection mechanism of the INSPIRE Discovery Servicefootnote:[Technical Guidance for the implementation of INSPIRE Discovery Services, version 3.1, section 4.5 Language Requirements].

[IMPORTANT]
====
*TG Requirement C.4: metadata/2.0/req/common/free-text*

Free text elements of type _gco:CharacterString_PropertyType_ in INSPIRE metadata shall be expressed in one of the following ways:1. using the _gco:CharacterString_ child element,2. using _gmx:Anchor_ child element, or3. re-typing the containing element to _gmd:PT_FreeText_PropertyType_ using the _xsi:type_ attribute and providing both _gco:CharacterString_ and _gmd:PT_FreeText_ child elements.

For options 1 and 2 the character string content of elements shall be provided in the language of the metadata. For option 3 the definition of the used locale shall be provided either using an URI pointing to a _gmd:MD_Metadata/gmd:locale_ element within the same document or to an externally provided _gmd:PT_Locale_ element. The character string content shall not be empty unless explicitly allowed in the element specific TG Requirements.
====

For convenience and requirement text brevity reasons a special reserved term "Non-empty Free Text Element" is used in this document where any of these three options is allowed.


[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:locale:**

<gmd:locale>
  <gmd:pt_locale id="locale-swe">
    <gmd:languagecode>
      <gmd:languagecode codelist="http://www.loc.gov/standards/iso639-2" codelistvalue="swe">
        Swedish
      </gmd:languagecode>
    </gmd:languagecode>
    <gmd:characterencoding>
      <gmd:md_charactersetcode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_CharacterSetCode" codelistvalue="utf8">
        UTF-8
      </gmd:md_charactersetcode>
    </gmd:characterencoding>
  </gmd:pt_locale>
</gmd:locale>
----
*Example* *2.5*: Locale definition for Swedish language provided for referencing using the gmd:locale element. The gmd:PT_Locale child element has the id attribute "locale-swe" which can be used as the URL fragment identifier in a local XPointer referring to this element from within the same XML document.

=== General requirements

==== File identifier

When regularly harvesting metadata from discovery services of several Member States (as done by the EU INSPIRE geoportal), it is helpful to be able to identify duplicate metadata elements and updates of metadata records. This can be ensured by providing a globally unique and persistent identifier of the metadata record through the _fileIdentifier_ element.

[TIP]
====
*TG Recommendation C.1: metadata/2.0/rec/common/fileIdentifier*

The metadata record should contain a globally unique and persistent _fileIdentifier_ element.
====

Global uniqueness of the _fileIdentifier_ can be ensured, for example, by

* using UUIDs, e.g. 123e4567-e89b-12d3-a456-426655440000, or
* using an identifier scheme including a country coce prefix, e.g. FR_IGNF_BDCARTOr_3-1_TOPONYMIE (FR_<producer>_<product>_<version>_<theme>)

NOTE The fileIdentifier element is mandatory in [CSW2 AP ISO], which also requires that “to simplify catalogue mining, each _MD_DataIdentification_ instance being part of a _MD_Metadata_ instance must have an identifier having a code value that is equal to the _fileIdentifier_ of the owning _MD_Metadata_ instance”.

==== Metadata language

The element for the language in which the metadata content is provided, is described in [Regulation 1205/2008], Part B, 10.3:


____
10.3. Metadata language

This is the language in which the metadata elements are expressed.The value domain of this metadata element is limited to the official languages of the Community expressed in conformity with ISO 639-2.
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is exactly one for both data sets and services.

[IMPORTANT]
====
*TG Requirement C.5: metadata/2.0/req/common/metadata-language-code*

The language of the provided metadata content shall be given. It shall be encoded using _gmd:MD_Metadata_/_gmd:language_/_gmd:LanguageCode_ element pointing to one of the three-letter language codes of the ISO 639-2/B code listfootnote:[Attribute codeList shall be "http://www.loc.gov/standards/iso639-2/" and the attribute codeListValue shall contain one of the three-letter bibliographic language code values.].

Only the code values for the official languages of the European Unionfootnote:[At the time of writing there are 24 official languages of the EU, see http://ec.europa.eu/languages/policy/linguistic-diversity/official-languages-eu_en.htm] shall be used.

The multiplicity of this element is 1.
====

[TIP]
====
*TG Recommendation C.1: metadata/2.0/rec/common/metadata-language-name*

The name of the language(s) of the described resource in the language of the metadata should be used as the text content of the _gmd:LanguageCode_ element.
====

==== Metadata point of contact

The element for providing the name and contact information for the organisation responsible for the creation of maintenance of the metadata is described in [Regulation 1205/2008], Part B, 10.1:


____
10.1. Metadata point of contact

This is the description of the organisation responsible for the creation and maintenance of the metadata.

This description shall include:

— the name of the organisation as free text,

— a contact e-mail address as a character string
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is one or more for both data sets and services.

[IMPORTANT]
====
*TG Requirement C.6: metadata/2.0/req/common/md-point-of-contact*

Point of contact for the responsible party for the provided metadata shall be given using element _gmd:MD_metadata_/__gmd:__contact/_gmd:CI_ResponsibleParty_.The multiplicity of this element is 1..*.The _gmd:CI_ResponsibleParty_ element shall contain the following child elements: The name of the responsible organisation shall be provided as the value of _gmd:organisationName_ element with a Non-empty Free Text Element content.

The email address of the organisation shall be provided as the value of _gmd:contactInfo_/_gmd:CI_Contact_/_gmd:address_/_gmd:CI_Address_/_gmd:electronicMailAddress_ element with a Non-empty Free Text Element containing a functioning email address of the responsible party. The value of _gmd:role_/_gmd:CI_RoleCode_ shall point to the value "pointOfContact" of [ISO 19139] code list CI_RoleCodefootnote:[Attribute codeList shall be "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_RoleCode" and value of codeListValue attribute "pointOfContact"].
====

[TIP]
====
*TG Recommendation C.2: metadata/2.0/rec/common/organisation-name*

The name of the organisation should be given in full, without abbreviations. It is recommended to use an email address of the organisation instead of personal email address.
====

Example fragment of the metadata document fulfilling TG Requirement C.6 is given as Example 2.6.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:contact:**

<gmd:contact>
  <gmd:ci_responsibleparty>
    <gmd:organisationname>
      <gco:characterstring>
        European Commission, Joint Research Centre
        <gco:characterstring>
        </gco:characterstring>
      </gco:characterstring>
    </gmd:organisationname>
    <gmd:contactinfo>
      <gmd:ci_contact>
        <gmd:address>
          <gmd:ci_address>
            <gmd:electronicmailaddress>
              <gco:characterstring>
                ies-contact@jrc.ec.europa.eu
              </gco:characterstring>
            </gmd:electronicmailaddress>
          </gmd:ci_address>
        </gmd:address>
      </gmd:ci_contact>
    </gmd:contactinfo>
    <gmd:role>
      <gmd:ci_rolecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_RoleCode" codelistvalue="pointOfContact">
      </gmd:ci_rolecode>
    </gmd:role>
  </gmd:ci_responsibleparty>
</gmd:contact>
----
*Example* *2.6*: Providing metadata point of contact information.

==== Metadata date

The metadata date element is described in [Regulation 1205/2008], Part B, 10.2:


____
10.2. Metadata date

The date which specifies when the metadata record was created or updated. This date shall be expressed in conformity with ISO 8601.
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is exactly one for both data sets and services.

[IMPORTANT]
====
*TG Requirement C.7: metadata/2.0/req/common/md-date*

The latest update date of the metadata description shall be given for each metadata record. It shall be encoded using the _gmd:MD_Metadata_/_gmd:dateStamp_ element. If no updates to the metadata have been made since publishing it, the creation date of the metadata shall be used instead.

The multiplicity of this element is 1.
====

=== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo_ property of _gmd:MD_Metadata_ element.

Note that _gmd:MD_DataIdentification_ object shall be used as the value of _gmd:identificationInfo_ property for data sets and series and _srv:SV_ServiceIdentification_ object used for services, as described in sections 3.1 and 4.1 correspondingly.

==== Resource title

The elements for the resource is described in [Regulation 1205/2008], Part B, 1.1:


____
1.1. Resource title

This a characteristic, and often unique, name by which the resource is known.The value domain of this metadata element is free text
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is exactly one for both data sets and services. The Implementation Rules requirements above are reflected in this specification as the following Requirement:

[IMPORTANT]
====
*TG Requirement C.8: metadata/2.0/req/common/resource-title*

A human readable, non-empty title of the described data set, data set series or service shall be provided. It shall be encoded using the _gmd:citation_/_gmd:CI_Citation/gmd:title_ element with a Non-empty Free Text Element content in the language of the metadata.

The multiplicity of the element is 1.
====

[TIP]
====
*TG Recommendation C.3: metadata/2.0/rec/common/resource-title*

The Resource title should be concise and clearly understandable. It should not contain unexplained acronyms or abbreviations. It is recommended a maximum length of 250 characters and keeping the similarity with the original title of the resource, in the sense of the ‘official naming’.

If the data or service is part of a larger project, it is recommended to indicate the Project at the end of the title, in brackets. In case of Project names, abbreviations are allowed, as long as the rest of the title follows the guidelines above and the abbreviation is spelled out immediately in the abstract.
====

==== Resource abstract

The element for the resource abstract is described in [Regulation 1205/2008], Part B, 1.2:


____
1.2. Resource abstract

This is a brief narrative summary of the content of the resource. The value domain of this metadata element is free text
____

In the Tables 1 and 2 of [Regulation 1205/2008, Part C], the multiplicity of this element is exactly one for both data sets and services. The Implementation Rules requirements above are reflected in this specification as the following Requirement:

[IMPORTANT]
====
*TG Requirement C.9: metadata/2.0/req/common/resource-abstract*

A non-empty brief narrative summary of the content of the described data set, data set series or service shall be provided. It shall be encoded using the _gmd:abstract_ element with a Non-empty Free Text Element content in the language of the metadata.

The multiplicity of this element is 1.
====

[TIP]
====
*TG Recommendation C.4: metadata/2.0/rec/common/resource-abstract*

The resource abstract is a succinct description that can include:- A brief summary with the most important details that summarise the data or service- Coverage: linguistic transcriptions of the extent or location in addition to the bounding box- Main attributes- Data sources- Legal references- Importance of the workThe most important details of the description should be summarised in the first sentence or the first 256 characters.

Unexplained acronyms should not be used.
====

==== Responsible organisation and point of contact for the described resource

The [INSPIRE Directive], Article 5 requires the information about the public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services to be included in the metadata. [INSPIRE Directive, Article 11(2)(g)] requires this information to be provided also as search criteria in INSPIRE Discovery Services. The element for describing the responsible party for the resource is given in [Regulation 1205/2008, Part B 9.1 and 9.2]:


____
9.1. Responsible party

This is the description of the organisation responsible for the establishment, management, maintenance and distribution of the resource.

This description shall include:

— the name of the organisation as free text,

— a contact e-mail address as a character string.

9.2. Responsible party role

This is the role of the responsible organisation.

The value domain of this metadata element is defined in Part D.
____

In the Tables 1 and 2 of [Regulation 1205/2008, Part C], the multiplicity of this element is defined as at least one.

[IMPORTANT]
====
*TG Requirement C.10: metadata/2.0/req/common/responsible-organisation*

The point of contact for the organisation responsible for the establishment, management, maintenance and distribution of the described resource shall be given using element _gmd:pointOfContact_/_gmd:CI_ResponsibleParty_.The multiplicity of this element is 1..*.The _gmd:CI_ResponsibleParty_ element shall contain the following child elements: The name of the organisation shall be given as the value of _gmd:pointOfContact_/_gmd:CI_ResponsibleParty_/_gmd:organisationName_ element with a Non-empty Free Text Element content.

The email address of the organisation shall be provided as the value of _gmd:pointOfContact_/_gmd:CI_ResponsibleParty_/_gmd:contactInfo_/_gmd:CI_Contact_/_gmd:address_/_gmd:CI_Address_/_gmd:electronicMailAddress_ element with a Non-empty Free Text Element containing a functioning email address of the responsible party.

The value of _gmd:pointOfContact_/_gmd:CI_ResponsibleParty_/_gmd:role_/_gmd:CI_RoleCode_ shall point to the most relevant value of ISO 19139 code list CI_RoleCodefootnote:[Attribute codeList shall be "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_RoleCode".].
====

[TIP]
====
*TG Recommendation C.5: metadata/2.0/rec/common/responsible-organisation*

The name of the organisation should be given in full, without abbreviations. It is recommended to use an email address of the organisation instead of personal email address.
====

The structure and content of the _gmd:pointOfContact_ property is the same as the property with same name used for the metadata point of contact (_gmd:MD_Metadata_/_gmd:contact_). The only exception is the role code, which is restricted only to value "pointOfContact" for metadata point of contact. In here on the contrary the most appropriate value from the code list shall be used for the role code.For an XML example of the responsible party element, see section 2.2.3.

==== Temporal references

The Implementation Rule text in [Regulation 1205/2008], Part B 5, and the Tables 1 and 2 in its Part C require at least one of the following temporal references to be given for INSPIRE data sets and services:

{empty}
____
5. TEMPORAL REFERENCE

This metadata element addresses the requirement to have information on the temporal dimension of the data as referred to in Article 8(2)(d) of Directive 2007/2/EC. At least one of the metadata elements referred to in points 5.1 to 5.4 shall be provided. The value domain of the metadata elements referred to in points 5.1 to 5.4 is a set of dates. Each date shall refer to a temporal reference system and shall be expressed in a form compatible with that system. The default reference system shall be the Gregorian calendar, with dates expressed in accordance with ISO 8601.
____

Thus one of the following information is required by [Regulation 1205/2008]:

* {blank}
+

temporal extent of the described resource,

* {blank}
+

date of publication,

* {blank}
+

date of last revision or,

* {blank}
+

date of creation.


ISO 19115 data model is more demanding than INSPIRE in this respect. Therefore, whilst providing a temporal extent for the resource would suffice to satisfy the [Regulation 1205/2008], it is not enough to be compliant with ISO 19115, which requires to use at least one of date of publication, date of last revision, or the date of creation. Additionally the XML Schema of [ISO 19139] requires the date or time expression to be encoded using [ISO 8601].

To fulfil both INSPIRE and ISO 19115/19139 requirements the following is required in this specification:

[IMPORTANT]
====
*TG Requirement C.11: metadata/2.0/req/common/temporal-reference*

At least one temporal reference describing the resource shall be given using _gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:date_ element, with one of the following date types:- _publication_ for date of publication of the resource,- _revision_ for the date of last revision of the resource, or- _creation_ for the date of creation of the resource__.__The date type shall be given using the _gmd:citation_/_gmd:CI_Citation_/_gmd:date_/_gmd:CI_Date_/_gmd:dateType_/_gmd:CI_DateTypeCode_ element and it shall point to the corresponding value of [ISO 19139] code list CI_DateTypeCode mentioned abovefootnote:[Attribute codeList shall have value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute codeListValue one of "publication", "revision" or "creation".].

The date values shall be expressed using Gregorian calendar and in accordance with [ISO 8601] with either date precision or date and time precision. For date precision the _gmd:CI_Date_/_gmd:date_/_gco:Date_ element, and for date and time precision _gmd:CI_Date_/_gmd:date_/_gco:DateTime_ element shall be used.
====

Additionally the [Regulation 1205/2008] restricts the multiplicity of the date of last revision and the date of creation to the maximum of one. To comply with these Implementation Rules, the following two Requirements must be fulfilled:

[IMPORTANT]
====
*TG Requirement C.12: metadata/2.0/req/common/max-1-date-of-creation*

Not more than one date of creation for the described resource shall be given.
====

[IMPORTANT]
====
*TG Requirement C.13: metadata/2.0/req/common/max-1-date-of-last-revision*

Not more than one date of last revision for the described resource shall be given.
====

[TIP]
====
*TG Recommendation C.6: metadata/2.0/rec/common/date-of-last-revision-dataset*

In case of spatial data set, at least the date of the last revision of the spatial data set should be reported.
====

[IMPORTANT]
====
*TG Requirement C.14: metadata/2.0/req/common/temporal-extent*

If a temporal reference is provided using the temporal extent, it shall be encoded using the _gmd:extent/gmd:EX_Extent_ element with one or more _gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent_ child elements. The value of each of these element may be an individual date or a time period between two dates.

The multiplicity of this element is 0..*.A single individual date or a time period shall be encoded using one _gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent_ element. For individual dates this element shall contain a _gml:TimeInstant/gml:timePosition_ element with the date value given according to [ISO 8601].

For a single time period the _gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent_ element shall contain a _gml:TimePeriod_ element containing start and end dates of the period. In case the time period is open-ended with either the start or the end date unknown, the elements _gml:startPosition_ or _gml:endPosition_ may be used with an empty value and the attribute _indeterminatePosition_ with value "unknown". If the temporal extent is on-going, the _gml:endPosition_ may be used with an empty value and the attribute _indeterminatePosition_ with value "now".Individual dates and time periods may be combined to form a complex temporal extent using multiple _gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent_ elements.
====

An example XML fragment with only a _gmd:CI_Citation_ element with the revision date of a service provided as the temporal reference, is given as Example 2.7.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/*/gmd:citation/gmd:CI_Citation:**

<gmd:ci_citation>
  <gmd:title>
    <gco:characterstring>
      INSPIRE compliant View Service for the Finnish Cadastral Parcels
    </gco:characterstring>
  </gmd:title>
  <gmd:date>
    <gmd:ci_date>
      <gmd:date>
        <gco:date>
          2013-02-21
        </gco:date>
      </gmd:date>
      <gmd:datetype>
        <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="revision">
          révision
        </gmd:ci_datetypecode>
      </gmd:datetype>
    </gmd:ci_date>
  </gmd:date>
</gmd:ci_citation>
----
*Example* *2.7*: Revision date for a View Service provided as the only mandatory temporal reference. Note the use of localised French term "révision" as the textual value of the date type code element pointing to the non-localised code list value "revision".

[source,xml,subs="+quotes"]
----
<gmd:md_metadata <gmd:identificationinfo="" …="">
  <gmd:md_dataidentification>
    …
    <gmd:extent>
      <gmd:ex_extent>
        <gmd:temporalelement>
          <gmd:ex_temporalextent>
            <gmd:extent>
              <gml:timeperiod gml:id="IDd2febbb4-e66f-4ac8-ba76-8fd9bc7c8be6">
                <gml:beginposition>
                  2008-01-01T11:45:30
                </gml:beginposition>
                <gml:endposition>
                  2008-12-31T09:10:00
                </gml:endposition>
              </gml:timeperiod>
            </gmd:extent>
          </gmd:ex_temporalextent>
        </gmd:temporalelement>
      </gmd:ex_extent>
    </gmd:extent>
    …
  </gmd:md_dataidentification>
  …
  …
</gmd:md_metadata>
----
*Example* *2.8*: Temporal extent

==== Using keywords

The keyword value is a commonly used word, formalised word or phrase used to describe the subject. While the topic category is too coarse for detailed queries, keywords help narrowing a full text search and they allow for structured keyword search. [INSPIRE Directive], Article 11(2)(a) requires keyword information to be provided as search criteria in INSPIRE Discovery Services.

Exact references to the controlled vocabulary keywords are necessary for using the keywords in cross-data set and cross-service searches. Specifying the origin of a keyword originating from a controlled vocabulary is described in [Regulation 1205/2008], Part B, 3.2:


____
3.2. Originating controlled vocabulary

If the keyword value originates from a controlled vocabulary (thesaurus, ontology), for example GEMET, the citation of the originating controlled vocabulary shall be provided. This citation shall include at least the title and a reference date (date of publication, date of last revision or of creation) of the originating controlled vocabulary.
____

[IMPORTANT]
====
*TG Requirement C.15: metadata/2.0/req/common/keyword-originating-cv*

When using keywords originating from a controlled vocabulary, the originating controlled vocabulary shall be cited using _gmd:descriptiveKeywords_/_gmd:MD_Keywords/gmd:thesaurusName/gmd:CI_Citation_ element.

The title of the vocabulary shall be given using _gmd:title element_ with a Non-empty Free Text Element content. _The publication date of the vocabulary shall be given using the gmd:date/gmd:CI_Date/gmd:date/gco:Date_ and __gmd:dateType/gmd:CI_DateTypeCode__footnote:[Attribute codeList shall have value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute codeListValue value "publication".] elements.
====

NOTE Specifying the correct publication date of the thesaurus is important for knowing which version of the thesaurus has been used.

[TIP]
====
*TG Recommendation C.7: metadata/2.0/rec/common/use-cvs*

If keyword values are made available as a collection of specific, well-defined terms (controlled vocabularies), those should be preferred over free-text terms.
====

[TIP]
====
*TG Recommendation C.8: metadata/2.0/rec/common/use-anchors-for-cv-keywords*

If the keywords from controlled vocabularies are used and the individual keywords have a specified canonical URI within that controlled vocabulary, these keywords should be encoded using the _gmd:keyword/gmx:Anchor_ element. The _xlink:href_ attribute of the _gmx:Anchor_ element should be used for referring to the canonical URI of the keyword.
====

[TIP]
====
*TG Recommendation 1.9: metadata/2.0/rec/common/use-anchors-for-thesauri*

For references to well-known thesauri or controlled vocabularies, the _title_ element of the _thesaurusName_ should be encoded using the _gmd:title/gmx:Anchor_ element. The _xlink:href_ attribute of the _gmx:Anchor_ element should be used for referring to the URI of the thesaurus or controlled vocabulary.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:thesaurusName**

<gmd:thesaurusname>
  <gmd:ci_citation>
    <gmd:title>
      <gmx:anchor xlink:href="http://www.eionet.europa.eu/gemet/inspire_themes">
        GEMET - INSPIRE themes, version 1.0
      </gmx:anchor>
    </gmd:title>
    <gmd:date>
      <gmd:ci_date>
        <gmd:date>
          <gco:date>
            2008-06-01
          </gco:date>
        </gmd:date>
        <gmd:datetype>
          <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            publication
          </gmd:ci_datetypecode>
        </gmd:datetype>
      </gmd:ci_date>
    </gmd:date>
  </gmd:ci_citation>
</gmd:thesaurusname>
----
*Example* *2.9:* Use of gmx:Anchor elements for the vocabulary title, with a reference to the vocabulary, the GEMET – INSPIRE themes thesaurus in this case.

In addition, XML fragment documents containing the _CI_Citation_ elements for commonly used thesauri and controlled vocabularies will be made available in the http://inspire.ec.europa.eu/id/citation/ namespace. References to these _CI_Citation_ fragment documents may be used to encode the specification element by reference, using the _xlink:href_ attribute of the _gmd:thesaurusName_ element (see Example 2.10).

NOTE 1 The pre-defined _CI_Citation_ elements will be designed to fulfil TG requirement C.15 and will be made available in different languages. The appropriate language version of the _CI_Citation_ element can be accessed using content negotiation (using the _Accept-Language_ HTTP header).

NOTE 2 In order to ensure compatibility with all clients (including those that cannot resolve xlinks**)**, the _gmd:thesaurusName_ can also contain the _CI_Citation_ fragment (see Example 2.11**Example 2.19**). In this case, according to [ISO 19136], _"if both a link and content are present in an instance of a property element, then the object found by traversing the xlink:href link shall be the normative value of the property. The object included as content shall be used by the data recipient only if the remote instance cannot be resolved; this may be considered to be a "cached" version of the object."_

The use of _gmx:Anchor_ elements and pre-defined XML fragments for _CI_Citations_ will help avoid issues with spelling errors or similar mistakes when providing the _thesaurusName_ elements. They will also allow the unique identification of controlled vocabularies in the metadata.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:thesaurusName**

<gmd:thesaurusname xlink:href="http://inspire.ec.europa.eu/id/citation/voc/gemet-inspire-themes-1.0">
</gmd:thesaurusname>
----
*Example* *2.10:* Encoding the thesaurusName by reference to an XML fragment document containing the CI_Citation element.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:thesaurusName**

<gmd:thesaurusname xlink:href="http://inspire.ec.europa.eu/id/citation/voc/gemet-inspire-themes-1.0">
  <gmd:ci_citation>
    <gmd:title>
      <gmx:anchor xlink:href="http://www.eionet.europa.eu/gemet/inspire_themes">
        GEMET - INSPIRE themes, version 1.0
      </gmx:anchor>
    </gmd:title>
    <gmd:date>
      <gmd:ci_date>
        <gmd:date>
          <gco:date>
            2008-06-01
          </gco:date>
        </gmd:date>
        <gmd:datetype>
          <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            publication
          </gmd:ci_datetypecode>
        </gmd:datetype>
      </gmd:ci_date>
    </gmd:date>
  </gmd:ci_citation>
</gmd:thesaurusname>
----
*Example* *2.11:* Including the CI_Citation element in addition to a reference to a pre-defined XML fragment document.

The following keyword grouping requirement is added for ISO 19115 compliance:

[IMPORTANT]
====
*TG Requirement C.16: metadata/2.0/req/common/group-keywords-by-cv*

All keywords originating from the same controlled vocabulary, or its version, shall be grouped under one _gmd:descriptiveKeywords_/_gmd:MD_Keywords_ element. A single _gmd:MD_Keywords_ element may only contain keywords originating from the one cited controlled vocabulary, or its version.
====

Further requirements for using keywords are given in the Conformance Class 1 data sets and data set series (section 3.1.2.2), Conformance Class 2 Spatial Data Services (section 4.1.2.2).

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/*/gmd:descriptiveKeywords/gmd:MD_Keywords:**

<gmd:md_keywords>
  <gmd:keyword>
    <gmx:anchor xlink:href="http://inspire.ec.europa.eu/theme/ac">
      Atmospheric conditions
    </gmx:anchor>
  </gmd:keyword>
  <gmd:keyword>
    <gmx:anchor xlink:href="http://inspire.ec.europa.eu/theme/mf">
      Meteorological geographical features
    </gmx:anchor>
  </gmd:keyword>
  <gmd:thesaurusname>
    <gmd:ci_citation>
      <gmd:title>
        <gmx:anchor xlink:href="http://www.eionet.europa.eu/gemet/inspire_themes">
          GEMET - INSPIRE themes, version 1.0
        </gmx:anchor>
      </gmd:title>
      <gmd:date>
        <gmd:ci_date>
          <gmd:date>
            <gco:date>
              2008-06-01
            </gco:date>
          </gmd:date>
          <gmd:datetype>
            <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            </gmd:ci_datetypecode>
          </gmd:datetype>
        </gmd:ci_date>
      </gmd:date>
    </gmd:ci_citation>
  </gmd:thesaurusname>
</gmd:md_keywords>
----
*Example* *2.12*: Using and grouping keywords from controlled vocabularies

==== Limitations on public access

The element for the limitations on public access is described in [Regulation 1205/2008], Part B, 8.2:


____
8.2. Limitations on public access

When Member States limit public access to spatial data sets and spatial data services under Article 13 of Directive 2007/2/EC, this metadata element shall provide information on the limitations and the reasons for them.

If there are no limitations on public access, this metadata element shall indicate that fact.

The value domain of this metadata element is free text.
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is one or more for both data sets and services.

The Article 13 of the [INSPIRE Directive] contains a list of cases where limitations to public access can be set. Concerning providing the metadata for the data sets and services through Discovery services, the limitations on public access can be set on the base of reasons of international relations, public security or national defence.

Concerning providing View, Download or Transformation Services, or e-commerce services referred to in Article 14(3) of [INSPIRE Directive], limitations on public access can be set on the base of the following reasons ([INSPIRE Directive], Article 13):


_(a) the confidentiality of the proceedings of public authorities, where such confidentiality is provided for by law;_

_(b) international relations, public security or national defence;_

_(c) the course of justice, the ability of any person to receive a fair trial or the ability of a public authority to conduct an enquiry of a criminal or disciplinary nature;_

_(d) the confidentiality of commercial or industrial information, where such confidentiality is provided for by national or Community law to protect a legitimate economic interest, including the public interest in maintaining statistical confidentiality and tax secrecy;_

_(e) intellectual property rights;_

_(f) the confidentiality of personal data and/or files relating to a natural person where that person has not consented to the disclosure of the information to the public, where such confidentiality is provided for by national or Community law;_

_(g) the interests or protection of any person who supplied the information requested on a voluntary basis without being under, or capable of being put under, a legal obligation to do so, unless that person has consented to the release of the information concerned;_

_(h) the protection of the environment to which such information relates, such as the location of rare species._


ISO 19115 provides a general mechanism for documenting different categories of constraints applicable to the resource (or its metadata). In ISO 19139 XML Schema this mechanism is supported by the element _gmd:MD_Constraints_ and its specifications:

* {blank}
+

_gmd:MD_LegalConstraints_ for legal constraints;

* {blank}
+

_gmd:MD_SecurityConstraints_ for security constraints.


Since _gmd:MD_SecurityConstraints_ has for many countries only military use, only the element _gmd:MD_LegalConstraints_ is used for this information in the context of this specification.

To make the references to the allowed reasons in Article 13 for limiting public access explicit, an INSPIRE code list (Annex D.1 “Limitations on public access) with all the reason values is used in _gmd:otherConstraints_ elements. However, because the domain of the _gmd:otherConstraints_ is a character string (free text), the references to the code list values are done using _gmx:Anchor_ and its _xlink:href_ attribute with the URL pointing to the specified code list value in the INSPIRE Registry.

[IMPORTANT]
====
*TG Requirement C.17: metadata/2.0/req/common/limitations-on-public-access*

Limitations on public access (or lack of such limitations) for the described resource shall be described using exactly one _gmd:resourceConstraints/gmd:MD_LegalConstraints_ element. This element shall not be the same one as used for describing conditions applying to access and use (see 2.4.7).

The limitations on public access (or lack of such limitations) based on reasons referred to in point (a) or in points (c) to (h) of Article 13(1) of INSPIRE Directive quoted above, the gmd:resourceConstraints/gmd:MD_LegalConstraints element shall include a combination of

- one instance of _gmd:accessConstraints_/_gmd:MD_RestrictionCode_ element with code list value "otherRestrictions"footnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml" and attribute codeListValue "otherRestrictions".] and- at least one instance of _gmd:otherConstraints_/_gmx:Anchor_ pointing to one of the values from the code list for LimitationsOnPublicAccessfootnote:[INSPIRE Registry, attribute xlink:href with URL value starting with "http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/" and postfixed with one of values of code list LimitationsOnPublicAccess, see Annex D.1]. If there are no limitations on public access, the element shall point to the code list value "noLimitations".
====

Example 2.13 shows a fragment of the metadata document declaring limitation on public access based on Article 13(1) a of the [INSPIRE Directive].

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/*/gmd:resourceConstraints:**

<gmd:resourceconstraints>
  <gmd:md_legalconstraints>
    <gmd:accessconstraints>
      <gmd:md_restrictioncode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode" codelistvalue="otherRestrictions">
      </gmd:md_restrictioncode>
    </gmd:accessconstraints>
    <gmd:otherconstraints>
      <gmx:anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1a">
        Limitation d’accés public basé sur l’article 13(1) de la directive INSPIRE
      </gmx:anchor>
    </gmd:otherconstraints>
  </gmd:md_legalconstraints>
</gmd:resourceconstraints>
----
*Example* *2.13*: Limitations on public access based on the Article 13(1) a described using a combination of gmd:accessConstraints and gmd:otherConstraints with the xlink:href attribute of the Anchor element pointing to the non-localized code list in the INSPIRE Registry. The textual content of the gmx:Anchor element is given in the language of the metadata (French in this case).

==== Conditions applying to access and use

The information about conditions for accessing the spatial data sets and services are discussed in [INSPIRE Directive], Article 5 (b), stating that metadata shall include:

{empty}
____
(b) conditions applying to access to, and use of, spatial data sets and services and, where applicable, corresponding fees;
____

[INSPIRE Directive], Article 11(2)(f) requires these conditions to be provided also as search criteria in INSPIRE Discovery Services.

The element for the limitations on public access is described in [Regulation 1205/2008], Part B, 8.1:


____
8.1. Conditions applying to access and use

This metadata element defines the conditions for access and use of spatial data sets and services, and where applicable, corresponding fees as required by Article 5(2)(b) and Article 11(2)(f) of Directive 2007/2/EC.

The value domain of this metadata element is free text.

The element must have values. If no conditions apply to the access and use of the resource, ‘no conditions apply’ shall be used. If conditions are unknown, ‘conditions unknown’ shall be used.

This element shall also provide information on any fees necessary to access and use the resource, if applicable, or refer to a uniform resource locator (URL) where information on fees is available.
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is one or more for both data sets and services.

[IMPORTANT]
====
*TG Requirement C.18: metadata/2.0/req/common/conditions-for-access-and-use*

Conditions for access and use of the described resource shall be described using exactly one _gmd:resourceConstraints/gmd:MD_LegalConstraints_ element. This element shall not be the same used for describing limitations on public access (see 2.4.6).

The _gmd:resourceConstraints/gmd:MD_LegalConstraints_ element for conditions for access and use shall be encoded as follows:One instance of either _gmd:accessConstraints_ or _gmd:useConstraints_ element shall be given. In both cases this element shall contain a _gmd:MD_RestrictionCode element_ with code list value "otherRestrictions"footnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml" and attribute codeListValue "otherRestrictions".].

Additionally at least one instance of _gmd:otherConstraints shall be given_ describing the actual conditions.

If no conditions apply the _gmd:otherConstraints_ shall include a __gmx:Ancho__r element pointing to the value "noConditionsApply" in the code list ConditionsApplyingToAccessAndUsefootnote:[INSPIRE Registry, attribute xlink:href with URL value "http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse/noConditionsApply", see Annex D.2.].

If the conditions are unknown _gmd:otherConstraints_ shall include a _gmx:Anchor_ element pointing to the value "conditionsUnknown" in the code list ConditionsApplyingToAccessAndUsefootnote:[INSPIRE Registry, attribute xlink:href with URL value "http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse/conditionsUnknown", see Annex D.2.].

In other cases _gmd:otherConstraints_ shall include a Non-empty Free Text Element with a textual description of the conditions in the language of the metadata. This text shall include descriptions of terms and conditions, including where applicable, the corresponding fees or an URL pointing to an online resource where these terms and conditions are described.
====

NOTE the _gmd:otherConstraints_ element shall NOT contain an _gmx:Anchor_ link to the code list for LimitationsOnPublicAccess, because it is reserved only for documenting LimitationsOnPublicAccess (see 2.4.6).

[TIP]
====
*TG Recommendation C.10: metadata/2.0/rec/common/licences*

For detailed information about the licensing of the resource it is recommended to provide a link to a license type (e.g. http://creativecommons.org/licenses/by/3.0), a website or to a document containing the necessary information.
====

Example 2.14 shows an XML fragment of a data set metadata record with both limitations on public access and conditions applying to access and use described using separate _gmd:resourceConstraints_ elements.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/*/gmd:resourceConstraints:**

<gmd:resourceconstraints>
  <gmd:md_legalconstraints>
    <gmd:accessconstraints>
      <gmd:md_restrictioncode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode" codelistvalue="otherRestrictions">
      </gmd:md_restrictioncode>
    </gmd:accessconstraints>
    <gmd:otherconstraints>
      <gmx:anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/noLimitations">
        No limitations on public access
      </gmx:anchor>
    </gmd:otherconstraints>
  </gmd:md_legalconstraints>
</gmd:resourceconstraints>
<gmd:resourceconstraints>
  <gmd:md_legalconstraints>
    <gmd:useconstraints>
      <gmd:md_restrictioncode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode" codelistvalue="otherRestrictions">
      </gmd:md_restrictioncode>
    </gmd:useconstraints>
    <gmd:otherconstraints>
      <gmx:anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/


ConditionsApplyingToAccessAndUse/noConditionsApply">
        No conditions apply to access and use
      </gmx:anchor>
    </gmd:otherconstraints>
  </gmd:md_legalconstraints>
</gmd:resourceconstraints>
----
*Example* *2.14*: Limitations on public access together with conditions of access and use are provided using two gmd:resourceConstraints elements. In this case there are no limitations on public access nor conditions for access and use. The gmd:useConstraints element is used in this example for declaring conditions for access and use.

==== Geographic bounding box

Defining the geographic containing boundary of the described resource enables searches for resources using their area or location of interest. [INSPIRE Directive, Article 11(2)(e)] therefore requires this information to be provided also as search criteria in INSPIRE Discovery Services.

[Regulation 1205/2008, Part B, 4.1] describes an element intended for this purpose as follows:


____
4.1. Geographic bounding box

This is the extent of the resource in the geographic space, given as a bounding box.

The bounding box shall be expressed with westbound and eastbound longitudes, and southbound and northbound latitudes in decimal degrees, with a precision of at least two decimals.
____

The multiplicity of this element is one or more for data sets or data set series as defined in Table 1 and zero or more for services as defined in Table 2 of [Regulation 1205/2008], Part C. For services this information is only required if the described Spatial Data Service has an explicit geographic extent.

[IMPORTANT]
====
*TG Requirement C.19: metadata/2.0/req/common/bounding-box*

A minimal containing geographic bounding box of the data set or data set series shall be described. This bounding box shall be encoded using one or more _gmd:extent_/_gmd:EX_Extent_/_gmd:geographicElement_/_gmd:EX_GeographicBoundingBox_ elements.

The multiplicity of this element is 1..* for data sets and data set series, and 0..n for services.

The bounding coordinate values for west and east bound longitudes and south and north bound latitudes shall be given in decimal degree values using WGS 84 Coordinate Reference System, as specified for the EX_GeographicBoundingBox class of the [ISO 19115] data model. The coordinates shall be given with at least 2 decimal precision.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/*/gmd:extent:**

<gmd:extent>
  <gmd:ex_extent>
    <gmd:geographicelement>
      <gmd:ex_geographicboundingbox>
        <gmd:westboundlongitude>
          <gco:decimal>
            -15.00
          </gco:decimal>
        </gmd:westboundlongitude>
        <gmd:eastboundlongitude>
          <gco:decimal>
            45.00
          </gco:decimal>
        </gmd:eastboundlongitude>
        <gmd:southboundlatitude>
          <gco:decimal>
            35.00
          </gco:decimal>
        </gmd:southboundlatitude>
        <gmd:northboundlatitude>
          <gco:decimal>
            72.00
          </gco:decimal>
        </gmd:northboundlatitude>
      </gmd:ex_geographicboundingbox>
    </gmd:geographicelement>
  </gmd:ex_extent>
</gmd:extent>
----
*Example* *2.15:* Geographic bounding box for a data set or service provided using gmd:EX_GeographicBoundingBox.

=== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

==== Conformity

The declared conformity of the described resource to INSPIRE Implementing Rules and other specifications shall be given in the metadata element Specification and Degree as stated in [Regulation 1205/2008], Part B 7:


____
7.1. Specification

This is a citation of the implementing rules adopted under Article 7(1) of Directive 2007/2/EC or other specification to which a particular resource conforms.

A resource may conform to more than one implementing rules adopted under Article 7(1) of Directive 2007/2/EC or other specification.

This citation shall include at least the title and a reference date (date of publication, date of last revision or of creation) of the implementing rules adopted under Article 7(1) of Directive 2007/2/EC or of the specification.

7.2. Degree

This is the degree of conformity of the resource to the implementing rules adopted under Article 7(1) of Directive 2007/2/EC or other specification.

The value domain of this metadata element is defined in Part D.
____

In the Tables 1 and 2 of [Regulation 1205/2008], Part C, the multiplicity of this element is one or more for both data sets and services.

These conformity declarations help the users of the Discovery services in finding spatial data sets and services conforming to the INSPIRE or other specifications in the use cases where such conformity is required or preferred. Discovery services may contain metadata for both conforming and not conforming to these specifications. [INSPIRE Directive], Article 11(2)(d) requires this information to be provided as search criteria in INSPIRE Discovery Services.

In this specification the above Implementing Rule text is interpreted to mean that the conformity shall be declared at least to the following regulations depending on the described INSPIRE resource type:

* {blank}
+

*Data sets and data set series* shall declare conformity to [Regulation 1089/2010].

* {blank}
+

*Network Services* should declare conformity to [Regulation 976/2009].

* {blank}
+

*Invocable Spatial Data Services* (including interoperable and harmonised Spatial Data Services) shall declare conformity to [Regulation 1089/2010].


The specific TG Requirements for adding these conformity declarations are included in the corresponding Conformance Classes for these resource type. The TG Requirements below shall be followed for encoding the conformity for all of these resource types.

[IMPORTANT]
====
*TG Requirement C.20: metadata/2.0/req/common/conformity*

The degree of conformity of the described resource with an INSPIRE Implementing Rule, specification document or Conformance Class, shall be given using one or several _gmd:DQ_ConformanceResult_ elements under _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result_. For each conformity statement (i.e. for each specification), a separate _gmd:DQ_ConformanceResult_ element shall be used.

The multiplicity of this element is 1..*.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/:**

<dataqualityinfo>
  <dq_dataquality>
    <scope (…)="">
    </scope>
    <report>
      <dq_domainconsistency>
        <result>
          <dq_conformanceresult>
            (…)
          </dq_conformanceresult>
        </result>
      </dq_domainconsistency>
    </report>
    <report>
      <dq_domainconsistency>
        <result>
          <dq_conformanceresult>
            (…)
          </dq_conformanceresult>
        </result>
      </dq_domainconsistency>
    </report>
  </dq_dataquality>
</dataqualityinfo>
----
*Example* *2.16:* Providing several conformity statements

[IMPORTANT]
====
*TG Requirement C.21: metadata/2.0/req/common/conformity-specification*

Each _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult_ element shall include a citation of the INSPIRE Implementing Rule, specification document or Conformance Class, including its official title and the date of publication of the document, using _gmd:specification_/_gmd:CI_Citation_ element.

The title shall be given using the _gmd:title_ child element of the citation element with a Non-empty Free Text Element content. For the INSPIRE Implementation Rule documents the value of the title element shall match exactly the official title of the cited document in the language of the metadata.

The publication date of the cited document shall be given using _gmd:date_ child element. The date value shall be expressed in accordance with ISO 8601 with only the date part included.

The date type code element _gmd:date_/_gmd:CI_Date_/_gmd:dateType_/_gmd:CI_DateTypeCode_ shall be given and it shall point to the value "publication" of the ISO 19139 code list CI_DateTypeCodefootnote:[Attribute codeList shall have value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute codeListValue value "publication".].
====

[TIP]
====
*TG Recommendation C.11: metadata/2.0/rec/common/use-anchors-for-specifications*

For references to well-known INSPIRE legal acts, technical guidance documents or conformance classes, the title element of the specification should be encoded using the _gmd:title/gmx:Anchor_ element. The _xlink:href_ attribute of the _gmx:Anchor_ element should be used for referring to the URI of the specification.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result/gmd:specification**

<gmd:specification>
  <gmd:ci_citation>
    <gmd:title>
      <gmx:anchor xlink:href="http://data.europa.eu/eli/reg/2010/1089">
        COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
      </gmx:anchor>
    </gmd:title>
    <gmd:date>
      <gmd:ci_date>
        <gmd:date>
          <gco:date>
            2010-12-08
          </gco:date>
        </gmd:date>
        <gmd:datetype>
          <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            publication
          </gmd:ci_datetypecode>
        </gmd:datetype>
      </gmd:ci_date>
    </gmd:date>
  </gmd:ci_citation>
</gmd:specification>
----
*Example* *2.17:* Using an gmx:Anchor element for the specification title

In addition, XML fragment documents containing the _CI_Citation_ elements for the INSPIRE legal acts, technical guidance documents and conformance classes will be made available in the http://inspire.ec.europa.eu/id/citation/ namespace. References to these _CI_Citation_ fragment documents may be used to encode the specification element by reference, using the _xlink:href_ attribute of the _gmd:specification_ element (see Example 2.18).

NOTE 1 The pre-defined _CI_Citation_ elements will be designed to fulfil TG requirement C.21 and will be made available in different languages. The appropriate language version of the _CI_Citation_ element can be accessed using content negotiation (using the _Accept-Language_ HTTP header).

NOTE 2 In order to ensure compatibility with all clients (including those that cannot resolve xlinks**)**, the _gmd:specification_ can also contain the _CI_Citation_ fragment (see Example 2.19). In this case, according to [ISO 19136], _"if both a link and content are present in an instance of a property element, then the object found by traversing the xlink:href link shall be the normative value of the property. The object included as content shall be used by the data recipient only if the remote instance cannot be resolved; this may be considered to be a "cached" version of the object."_

The use of _gmx:Anchor_ elements and pre-defined XML fragments for _CI_Citations_ will help avoid issues with spelling errors or similar mistakes when providing the specification elements. They will also allow the unique identification of specifications in the metadata.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result/gmd:specification**

<gmd:specification xlink:href="http://inspire.ec.europa.eu/id/citation/ir/reg-1089-2010">
</gmd:specification>
----
*Example* *2.18:* Encoding the specification by reference to an XML fragment document containing the CI_Citation element.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result/gmd:specification**

<gmd:specification xlink:href="http://inspire.ec.europa.eu/id/citation/ir/reg-1089-2010">
  <gmd:ci_citation>
    <gmd:title>
      <gco:characterstring>
        COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
      </gco:characterstring>
    </gmd:title>
    <gmd:date>
      <gmd:ci_date>
        <gmd:date>
          <gco:date>
            2010-12-08
          </gco:date>
        </gmd:date>
        <gmd:datetype>
          <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            publication
          </gmd:ci_datetypecode>
        </gmd:datetype>
      </gmd:ci_date>
    </gmd:date>
  </gmd:ci_citation>
</gmd:specification>
----
*Example* *2.19:* Including the CI_Citation element in addition to a reference to a pre-defined XML fragment document.

[IMPORTANT]
====
*TG Requirement C.22: metadata/2.0/req/common/conformity-degree*

Each _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult_ element containing a specification citation described in Requirement C.21 shall also include the degree of declared conformity against this specification using _gmd:pass_ property with _gco:Boolean_ value of "true" for a conformant resource and "false" for non-conformant resource. If the conformity has not yet been evaluated, the _gmd:pass_ element shall be empty and contain a nil reason attribute with value "unknown"footnote:[Attribute gco:nilReason="unknown".].
====

== Conformance Classes for data sets

=== Baseline metadata for data sets and data set series

[NOTE]
====
*Conformance Class 1: metadata/2.0/datasets-and-series*

*Title:* INSPIRE data sets and data set series baseline metadata.

**Conformance subject**: Metadata records describing an INSPIRE data set or data set series encoded in ISO 19139 based XML format.

A metadata record fulfilling all the TG Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for data sets and data set series as defined in [*Regulation 1205/2008*].

This Conformance Class includes TG Requirements C.1 – C.22 and TG Requirements 1.1 – 1.11 from this specification.
====

The metadata elements described in the section 3.1.1 are direct child elements of _gmd:MD_Metadata_ element. The metadata elements contained within properties _gmd:identificationInfo_, _gmd:distributionInfo_ and _gmd:dataQualityInfo_ are described in sections 3.1.2 - 3.1.4 correspondingly.

==== Direct properties of MD_Metadata element

===== Resource type

The element for declaring the type of the resource is described in [Regulation 1205/2008], Part B, 1.3:


____
1.3. Resource type

This is the type of resource being described by the metadata. The value domain of this metadata element is defined in Part D.1
____

Table 1 contained in Part C of the same document defines the multiplicity of this element to exactly one for data sets and data set series. The resources conforming to this Conformance Class are either datasets or data set series, and thus this Implementation Rule requirement is reflected into the following technical Requirement:

[IMPORTANT]
====
*TG Requirement 1.1: metadata/2.0/req/datasets-and-series/resource-type*

The resource type shall be declared as "dataset" or "series" using the first _gmd:hierarchyLevel_ child element of _gmd:MD_Metadata._ The _gmd:hierarchyLevel_ shall contain a _gmd:MD_ScopeCode_ elementfootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" and the attribute codeListValue with value "dataset" or "series".].
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:hierarchyLevel:**

<gmd:hierarchylevel>
  <gmd:md_scopecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" codelistvalue="dataset">
  </gmd:md_scopecode>
</gmd:hierarchylevel>
----
*Example* *3.1:* Resource type "dataset" given using gmd:hierarchyLevel property.

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo_ property of the _gmd:MD_Metadata_ element.

[IMPORTANT]
====
*TG Requirement 1.2: metadata/2.0/req/datasets-and-series/only-one-md-data-identification*

The first gmd:_identificationInfo_ property of _gmd:MD_Metadata_ element shall contain only one _gmd:MD_DataIdentification_ element for identifying the described INSPIRE data set or data set series.
====

The ISO 19139 XML Schema allows more than one _gmd:IdentificationInfo_ properties to be given for each _gmd:MD_Metadata_ element. The purpose of this requirement is to harmonise the structure of the ISO 19139 based INSPIRE metadata records by declaring that while more than one instance can be given, readers can safely assume that only the first instance is used for INSPIRE resource identification.

[TIP]
====
*TG Recommendation 1.1: metadata/2.0/rec/datasets-and-series/md-element-id*

The _gmd:MD_DataIdentification_ elements should contain a unique identifier of the element itself to be used for referring from within the Spatial Data Service metadata records to indicate a coupled resource. This identifier should be provided as the value of attribute i__d__ of _gmd:MD_DataIdentification_ element.

This identifier should be persistent for a particular data set or service, and unique within the all the _id_ elements of the metadata record document and other XML documents it may appear in (like GetRecords responses of Discovery Service). The persistence of the _id_ attributes is important to prevent breaking the coupled resource links between the service metadata and the data set metadata.
====

NOTE A unique identifier of the _gmd:MD_DataIdentification_ element is not necessary when building the coupled resource link by providing a Unique Resource Identifier that is resolved to a URL containing an abstract pointer to the gmd:MD_DataIdentification element (see section 4.1.2.4).

See Example 3.2 for an example of providing the _id_ attribute.

===== Unique resource identifier

The [Regulation 1205/2008], Part B, 1.5 describes an element for uniquely identifying the described resource:


____
1.5. Unique resource identifier

A value uniquely identifying the resource.

The value domain of this metadata element is a mandatory character string code, generally assigned by the data owner, and a character string namespace uniquely identifying the context of the identifier code (for example, the data owner).
____

Table 1 contained in Part C of the same document defines the multiplicity of this element to one or more for data sets and data set series.

[IMPORTANT]
====
*TG Requirement 1.3: metadata/2.0/req/datasets-and-series/dataset-uid*

A unique identifier shall be given for each described dataset or data sets series. This identifier shall be a URI consisting of a namespace uniquely identifying a naming context governed by an identifier authority, and a code unique within this namespace.

The identifying URI shall be encoded using _gmd:citation_/_gmd:CI_Citation_/_gmd:identifier_/_*_/_gmd:code_ element with a Non-empty Free Text Element content.

The multiplicity of this element is 1..*.
====

NOTE The [ISO 19139] xml schemas allow the use of either the _MD_Identifier_ type or its sub-type _RS_Identifier_, which, in addition to the mandatory _code_ property, also contains an optional _codeSpace_ property. Since many applications only consider the code attribute and semantically _RS_Identifier_ is intended as an _"identifier (…) for reference systems"_ [ISO 19115], the _MD_Identifier_ type should be used wherever possible and the complete URI should be encoded in the code element. This also facilitates the implementation of data-service-coupling based on the unique resource identifier (see also 4.1.2.4).

[TIP]
====
*TG Recommendation 1.1: metadata/2.0/rec/datasets-and-series/use_md_identifier*

It is strongly recommended to use the _MD_Identifier_ instead of the the _RS_Identifier_ type and to encode the complete URI in the code element.
====

In accordance with the Best Practices that are currently being developed for (spatial) data on the webfootnote:[See https://www.w3.org/TR/dwbp/ and https://www.w3.org/TR/sdw-bp/], it is recommended to use resolvable and persistent identifiers (in particular, HTTP URIs). This will also make it easier to provide direct links to data sets and their descriptions from outside the INSPIRE infrastructure.

[TIP]
====
*TG Recommendation 1.2: metadata/2.0/rec/datasets-and-series/resolvable-uid*

It is recommended to make the unique resource identifier resolvable into a document providing information about described data set or data sets series. In the case of HTTP URIsfootnote:[HTTP URIs in the text also include HTTPS URIs], the public DNS and the usual HTTP URI resolving mechanisms should be used for implementing this resolvability. For other types of URIs, a resolving service should be provided implementing similar functionality.

This document retrieved as the result of the resolving process may be, but is not required to be, the metadata description of the described resource. It is also recommended that viewing of the provided document does not require user authentication, authorisation or specialised viewing tools beyond a typical web browser.
====

[TIP]
====
*TG Recommendation 1.3: metadata/2.0/rec/datasets-and-series/persistent-uid*

The providers of unique resource identifiers should take great care in ensuring that the issued identifiers remain valid and available for the entire availability period of the identified resource, and preferably also after the data set or the data set series has been made unavailable.

If a published unique identifier for a resource must be changed during the availability time of the resource, both the old and the new identifier should resolve to the same document described in TG Recommendation 1.2. If this is not possible, the old identifier should resolve to document providing information about the change in the unique identifier and provide the new unique identifier of the described resource.

Assigning a published unique resource identifier to another or an extensively restructured data set or data set series should be avoided. Instead a new unique resource identifier should be assigned to the data set in these cases.

The persistence and process of preventing breaking the identifier resolvability is crucial for keeping the links between the services and the provided data sets functional.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification:**

<gmd:md_dataidentification id="md-so-1002001">
  <gmd:citation>
    <gmd:ci_citation>
      <gmd:title>
        <gco:characterstring>
          INSPIRE_Flurstücke_ALKIS_NRW
        </gco:characterstring>
      </gmd:title>
      <gmd:date>
        <gmd:ci_date>
          <gmd:date>
            <gco:date>
              2016-07-01
            </gco:date>
          </gmd:date>
          <gmd:datetype>
            <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            </gmd:ci_datetypecode>
          </gmd:datetype>
        </gmd:ci_date>
      </gmd:date>
      <gmd:identifier>
        <gmd:md_identifier>
          <gmd:code>
            <gmx:anchor <="" gmx:anchor="" xlink:href="https://registry.gdi-de.org/id/de.nw/inspire-cp-alkis">
            </gmx:anchor>
          </gmd:code>
        </gmd:md_identifier>
      </gmd:identifier>
    </gmd:ci_citation>
  </gmd:citation>
  ...
</gmd:md_dataidentification>
----
*Example* *3.2:* Unique identifier for a INSPIRE ProtectedSites data set given using gmd:identifier element within the gmd:citation element. Note also the recommended id attribute of the gmd:MD_DataIdentifier to be used for couple resource linking

===== Keywords for Spatial Data Theme(s)

The [Regulation 1205/2008], Part B, 3 describes how the Keyword elements shall be used for describing the relevant INSPIRE spatial data themes for the described data set or data set series:

{empty}
____
3. KEYWORD

(…)

If a resource is a spatial data set or spatial data set series, at least one keyword shall be provided from the general environmental multilingual thesaurus (GEMET) describing the relevant spatial data theme as defined in Annex I, II or III to Directive 2007/2/EC.
____

[IMPORTANT]
====
*TG Requirement 1.4: metadata/2.0/req/datasets-and-series/inspire-theme-keyword*

The INSPIRE Spatial Data Theme(s), to which the data set belongs to, shall be declared using at least one keyword from the INSPIRE Spatial Data Themes vocabulary of the general environmental multilingual thesaurus (GEMET). The keyword values shall be the exact text values of the terms in this vocabulary.

These keywords shall be encoded using an _gmd:descriptiveKeywords_/_gmd:MD_Keywords_ element referring to the GEMET INSPIRE themes controlled vocabulary as specified in section 2.4.5. The value of the _gmd:thesaurusName/gmd:CI_Citation/gmd:title_ element shall contain value "GEMET - INSPIRE themes, version 1.0".For each INSPIRE Spatial Data Theme, a _gmd:keyword_ element shall be included with the title of the theme as a Non-empty Free Text Element content in the language of the metadata.
====

[TIP]
====
*TG Recommendation 1.4: metadata/2.0/rec/datasets-and-series/use-anchors-for-gemet*

For references to the GEMET – INSPIRE themes controlled vocabulary, the _title_ element of the _thesaurusName_ should be encoded using the _gmd:title/gmx:Anchor_ element, with the _xlink:href_ attribute referring to http://www.eionet.europa.eu/gemet/inspire_themes.

The INSPIRE themes keywords should be encoded using the _gmd:keyword/gmx:Anchor_ element, with the _xlink:href_ attribute referring to the URI of the theme defined in the GEMET – INSPIRE themes controlled vocabulary.
====

NOTE The URIs of the INSPIRE themes are also available in the INSPIRE theme register at http://inspire.ec.europa.eu/theme.

See Example 3.3 for an example of the XML fragment containing GEMET keywords for INSPIRE themes.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords:**

<gmd:md_keywords>
  <gmd:keyword>
    <gmx:anchor xlink:href="http://inspire.ec.europa.eu/theme/ac">
      Atmospheric conditions
    </gmx:anchor>
  </gmd:keyword>
  <gmd:keyword>
    <gmx:anchor xlink:href="http://inspire.ec.europa.eu/theme/mf">
      Meteorological geographical features
    </gmx:anchor>
  </gmd:keyword>
  <gmd:thesaurusname>
    <gmd:ci_citation>
      <gmd:title>
        <gmx:anchor xlink:href="http://www.eionet.europa.eu/gemet/inspire_themes">
          GEMET - INSPIRE themes, version 1.0
        </gmx:anchor>
      </gmd:title>
      <gmd:date>
        <gmd:ci_date>
          <gmd:date>
            <gco:date>
              2008-06-01
            </gco:date>
          </gmd:date>
          <gmd:datetype>
            <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            </gmd:ci_datetypecode>
          </gmd:datetype>
        </gmd:ci_date>
      </gmd:date>
    </gmd:ci_citation>
  </gmd:thesaurusname>
</gmd:md_keywords>
----
*Example* *3.3:* Keywords element for a data set belonging to two INSPIRE Spatial Data Themes: Atmospheric conditions and Meteorological geographical features.

[TIP]
====
*TG Recommendation 1.5: metadata/2.0/rec/datasets-and-series/additional-keywords*

In addition to the required keywords from the GEMET - INSPIRE themes vocabulary, it is recommended to provide at least two other keywords describing the data set or data set series.
====

===== Spatial resolution

Spatial resolution refers to the level of detail of the data set. It shall be expressed as a set of zero to many resolution distances (typically for gridded data and imagery-derived products) or equivalent scales (typically for maps or map-derived products).


____
6.2. Spatial resolution

Spatial resolution refers to the level of detail of the data set. It shall be expressed as a set of zero to many resolution distances (typically for gridded data and imagery-derived products) or equivalent scales (typically for maps or map-derived products).

An equivalent scale is generally expressed as an integer value expressing the scale denominator.

A resolution distance shall be expressed as a numerical value associated with a unit of length.
____

The [Regulation 1205/2008], Part B, 6.2 describes an element intended for describing this information:

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 1 is zero or more, and it is "mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified."

[IMPORTANT]
====
*TG Requirement 1.5: metadata/2.0/req/datasets-and-series/spatial-resolution*

Spatial resolution for data set or data set series shall be given using either equivalent scale or a resolution distance, provided that these have been specified for the described data sets. If both ways have been specified, only one of the ways shall be used. The spatial resolution as equivalent scale shall be encoded using _gmd:spatialResolution_/_gmd:MD_Resolution_/_gmd:equivalentScale_/_gmd:MD_RepresentativeFraction_/_gmd:denominator_/_gco:Integer_ element.

The spatial resolution as resolution distance shall be encoded using _gmd:spatialResolution_/_gmd:MD_Resolution_/_gmd:distance_/_gco:Distance_ element.

The multiplicity of this element is 0..n.
====

[TIP]
====
*TG Recommendation 1.6: metadata/2.0/rec/datasets-and-series/spatial-resolution-interval*

If the spatial resolution is an interval, both bounding values of the interval should be given (either as equivalent scale or resolution distance) as two instances of the _gmd:spatialResolution_/_gmd:MD_Resolution_ element.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:spatialResolution:**

<gmd:spatialresolution>
  <gmd:md_resolution>
    <gmd:equivalentscale>
      <gmd:md_representativefraction>
        <gmd:denominator>
          <gco:integer>
            50000
          </gco:integer>
        </gmd:denominator>
      </gmd:md_representativefraction>
    </gmd:equivalentscale>
  </gmd:md_resolution>
</gmd:spatialresolution>
----
*Example* *3.4:* Spatial resolution of a data set expressed using equivalent scale.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:spatialResolution:**

<gmd:spatialresolution>
  <gmd:md_resolution>
    <gmd:distance>
      <gco:distance uom="dd">
        0.25
      </gco:distance>
    </gmd:distance>
  </gmd:md_resolution>
</gmd:spatialresolution>
----
*Example* *3.5:* Spatial resolution of a data set expressed using distance.


[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:spatialResolution:**

<gmd:spatialresolution>
  <gmd:md_resolution>
    <gmd:distance>
      <gco:distance uom="dd">
        0.24
      </gco:distance>
    </gmd:distance>
  </gmd:md_resolution>
  <gmd:md_resolution>
    <gmd:distance>
      <gco:distance uom="dd">
        0.26
      </gco:distance>
    </gmd:distance>
  </gmd:md_resolution>
</gmd:spatialresolution>
----
*Example* *3.6:* Spatial resolution of a data set expressed using an interval of distances.

===== Resource language

The [Regulation 1205/2008], Part B, 1.7 describes an element for the language(s) used within the resource:


____
1.7. Resource language

The language(s) used within the resource.

The value domain of this metadata element is limited to the languages defined in ISO 639-2.
____

Table 1 contained in Part C of [Regulation 1205/2008] defines the multiplicity of this element to zero or more for data sets and data set series, allowing it to be left out if the resource does not contain textual information. However, the _gmd:language_ property used for encoding this element has multiplicity 1..* in ISO 19115 and in ISO 19139 XML Schema. To comply with ISO 19155 and the XML Schema rules, the element must always be given.

[IMPORTANT]
====
*TG Requirement 1.6: metadata/2.0/req/datasets-and-series/resource-language*

For data sets or data set series containing textual information, the language(s) used in the resource shall be given. The language(s) used shall be encoded using one or more _gmd:language_/_gmd:LanguageCode_ elements pointing to one of the three-letter language codes of the ISO 639-2/B code listfootnote:[attribute codeList shall be "http://www.loc.gov/standards/iso639-2/" and the attribute codeListValue shall contain one of the three-letter bibliographic language code values.].

The multiplicity of the _gmd:language_ element is 1..*.If the described resource does not contain textual information expressed in a natural language the special code value "zxx" of the ISO 639-2/B reserved for "no linguistic content; not applicable" shall be used.
====

[TIP]
====
*TG Recommendation 1.7: metadata/2.0/rec/datasets-and-series/language-name*

The name of the language(s) of the described resource in the language of the metadata should be used as the text content of the _gmd:LanguageCode_ element.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:language:**

<gmd:language>
  <gmd:languagecode codelist="http://www.loc.gov/standards/iso639-2/" codelistvalue="fin">
    Suomi
  </gmd:languagecode>
</gmd:language>
----
*Example* *3.7:* Resource language for a data set provided in Finnish. Note the content of the gmd:LanguageCode "Suomi": it is the name of the Finnish language in Finnish (the language of the metadata).

===== Topic category

The topic category is a high-level classification scheme to assist in the grouping and topic-based search of available spatial data resources. A correct categorisation is very important to help users to search and find the resources they are looking for.

The [Regulation 1205/2008], Part B, 2.1 describes the topic category element as follows:


____
2.1. Topic category

The topic category is a high-level classification scheme to assist in the grouping and topic-based search of available spatial data resources.

The value domain of this metadata element is defined in Part D.2.
____

The topic categories defined in Part D 2 of the [Regulation 1205/2008] are derived directly from the topic categories defined in MD_TopicCategoryCode (B.5.27 of ISO 19115).

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 1 is one or more.

[IMPORTANT]
====
*TG Requirement 1.7: metadata/2.0/req/datasets-and-series/topic-category*

The main theme(s) of the data set shall be described using of the ISO 19115 topic category code list values. The topic categories shall be encoded using _gmd:topicCategory_/_gmd:MD_TopicCategoryCode_ elementfootnote:[See Part D 2 of [Regulation 1205/2008] for the mapping between topics and INSPIRE themes.].

The multiplicity of this element is 1..*.
====

Note that contrary to many other code lists which are defined in the ISO 19139 XML Schema as references to an external code list, _gmd:MD_TopicCategoryCode_ element is defined as a string enumeration.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:topicCategory:**

<gmd:topiccategory>
  <gmd:md_topiccategorycode>
    environment
  </gmd:md_topiccategorycode>
</gmd:topiccategory>
----
*Example* *3.8:* Topic category element with enumeration value "environment".

==== Distribution info section

The metadata elements described in this section are contained within the _gmd:distributionInfo/gmd:MD_Distribution_ child element of _gmd:MD_Metadata_ element.

===== Resource locator for data set or series

The Resource Locator is the ‘navigation section’ of a metadata record which point users to the location (URL) where the data can be downloaded, or to where additional information about the resource may be provided.

Setting up the correct resource locators is important for the connection between the data and the services that provide access to them or for providing additional information concerning the resource.

The [Regulation 1205/2008], Part B, 1.4 describes an element intended for describing this information:


____
1.4. Resource locator

The resource locator defines the link(s) to the resource and/or the link to additional information about the resource.

The value domain of this metadata element is a character string, commonly expressed as uniform resource locator (URL).
____

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 1 is zero or more, and it is "mandatory if a URL is available to obtain more information on the resource, and/or access related services."

[IMPORTANT]
====
*TG Requirement 1.8: metadata/2.0/req/datasets-and-series/resource-locator*

A Resource locator linking to the service(s) providing online access to the described data set or data set series shall be given, if such online access is available.

If no online access for the data set or data set series is available, but there is a publicly available online resource providing additional information about the described data set or data set series, the URL pointing to this resource shall be given instead.

These links shall be encoded using _gmd:transferOptions_/_gmd:MD_DigitalTransferOptions_/_gmd:onLine_/_gmd:CI_OnlineResource_/_gmd_: _linkage_/_gmd:URL_ element.

The multiplicity of this element is 0..n.
====

A Resource Locator encoded using the gmd:CI_OnlineResource element may also include _gmd:name_, _gmd:description_, and _gmd:function_ properties.

[TIP]
====
*TG Recommendation 1.8: metadata/2.0/rec/datasets-and-series/resource-locator-additional-info*

The _gmd:name_, _gmd:description_, and _gmd:function_/_gmd:CI_OnLineFunctionCode_ child elements of _gmd:CI_OnlineResource_ element containing the given _gmd:linkage_ element should also be provided, if possible, to give additional information about the provided URL link. The _gmd:name_ and the _gmd:description_ elements should contain Non-empty Free Text Elements.

If provided, the _gmd:CI_OnLineFunctionCode_ element should point to one of the values of the ISO 19139 code list CI_OnLineFunctionCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode".]_._
====

[TIP]
====
*TG Recommendation 1.9__: metadata/2.0/rec/datasets-and-series/resource-locator-url__*

The URL provided as the value of the _gmd:transferOptions_/_gmd:MD_DigitalTransferOptions_/_gmd:onLine_/_gmd:CI_OnlineResource_/_gmd_: _linkage_/_gmd:URL_ element should point to one of following type of resources:- direct access for downloading the described data set,- a service metadata (capabilities) document of a Spatial Data Service used for providing this data set,- a service WSDLfootnote:[W3C Web Services Description Language, https://www.w3.org/TR/wsdl] document of a Spatial Data Service used for providing this data set (if SOAPfootnote:[W3C Simple Object Access Protocol, or more recently, just SOAP, https://www.w3.org/TR/soap/] binding is available), - a client application that directly accesses the described data set, or- a web page with further instructions for accessing the described data set.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions:**

<gmd:transferoptions>
  <gmd:md_digitaltransferoptions>
    <gmd:online>
      <gmd:ci_onlineresource>
        <gmd:linkage>
          <gmd:url>
            http://example.com/wfs?VERSION=2.0.0&amp;SERVICE=WFS&amp;REQUEST=GetFeature&amp;STOREDQUERY_ID=urn:ogc:def:query:OGC-WFS::GetFeatureById&amp;ID=123345
          </gmd:url>
        </gmd:linkage>
        <gmd:name>
          <gco:characterstring>
            WFS GetFeature request for downloading the data set
          </gco:characterstring>
        </gmd:name>
        <gmd:function>
          <gmd:ci_onlinefunctioncode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode" codelistvalue="download">
          </gmd:ci_onlinefunctioncode>
        </gmd:function>
      </gmd:ci_onlineresource>
    </gmd:online>
  </gmd:md_digitaltransferoptions>
</gmd:transferoptions>
----
*Example* *3.9:* Data set resource locator pointing directly to a WFS GetFeature operation for downloading the described data set.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:scope/gmd:DQ_Scope:**

<gmd:dq_scope>
  <gmd:level>
    <gmd:md_scopecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" codelistvalue="dataset">
    </gmd:md_scopecode>
  </gmd:level>
</gmd:dq_scope>
----
*Example* *3.10:* Scope of the Data quality info is set to the entire described data set by giving the code (gmd:level) with value "dataset".

==== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

===== Scope

[IMPORTANT]
====
*TG Requirement 1.9: metadata/2.0/req/datasets-and-series/one-data-quality-element*

There shall be exactly one _gmd:dataQualityInfo/gmd:DQ_DataQuality_ element scoped to the entire described data set or data set series.

The scoping shall be encoded using _gmd:scope_/_gmd:DQ_Scope_/_gmd:level/gmd:MD_ScopeCode_ element referring to value "dataset" or "series" of ISO 19139 code list MD_ScopeCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" and the attribute codeListValue with "service".].
====

===== Conformity

In conformance to [INSPIRE Directive], the metadata shall include a statement on the degree of conformity with the specifications against which its conformity has been evaluated.

[IMPORTANT]
====
*TG Requirement 1.10: metadata/2.0/req/datasets-and-series/conformity*

Metadata for an INSPIRE data set or data set series shall declare conformity to the Implementing Rules for interoperability of spatial data sets and services, and it shall be encoded using _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult_ element as specified in TG Requirement C.20footnote:[TG Requirement C.20: degree of conformity using _gmd:DQ_ConformanceResult._]. This element shall contain citation of the [Regulation 1089/2010] encoded according to TG Requirement C.21footnote:[TG Requirement C.21: _gmd:DQ_ConformanceResult_ shall include a citation of the specification document, ...]. The degree of conformity shall be encoded as according to TG Requirement C.22footnote:[TG Requirement C.22: … _gmd:DQ_ConformanceResult …_ shall also include the degree of declared conformity…].
====

[TIP]
====
*TG Recommendation 1.10: metadata/2.0/rec/datasets-and-series/uri-for-regulation-1089-2010*

If providing the specification title as an _gmx:Anchor_ element (as recommended in TG Recommendation C.10), the following URI should be used to refer to [Regulation 1089/2010]: http://data.europa.eu/eli/reg/2010/1089.
====

NOTE A pre-defined XML fragment containing the corresponding _CI_Citation_ element for [Regulation 1089/2010] will be provided at http://inspire.ec.europa.eu/id/citation/ir/reg-1089-2010.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification xlink:href="http://inspire.ec.europa.eu/id/citation/ir/reg-1089-2010">
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href="http://data.europa.eu/eli/reg/2010/1089">
            COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2010-12-08
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This data set is conformant with the INSPIRE Implementing Rules for the interoperability of spatial data sets and services
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *3.11:* Conformity declaration against the [Regulation 1089/2010].

Metadata for an INSPIRE data set or data set series can also include additional declarations of conformity, in particular to the abstract test suites and conformance classes defined for the INSPIRE data specifications.

[TIP]
====
*TG Recommendation 1.11: metadata/2.0/rec/datasets-and-series/uris-for-ats-and-cc*

If declaring conformity to an abstract test suite or a conformance class using an _gmx:Anchor_ element (as recommended in TG Recommendation C.11), the URI identifying the abstract test suite or a conformance class should be used in the _xlink:href_ attribute of the specification title element.
====

NOTE It is not currently planned to provide pre-defined XML fragments containing the _CI_Citation_ elements for the INSPIRE TG documents in the http://inspire.ec.europa.eu/id/citation/ namespace. However, such fragments can be added if this is deemed useful by INSPIRE data providers.


[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification>
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href="http://inspire.ec.europa.eu/id/ats/data-hy/3.1">
            D2.8.I.8 Data Specification on Hydrography – Technical Guidelines, version 3.1
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2014-04-17
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This data set is conformant with the INSPIRE Data Specification on Hydrography – Technical Guidelines, version 3.1
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *3.12:* Conformity declaration against an Abstract Test Suite.

===== Lineage

The processing history of result data set or data set series can provide valuable information about the applicability of the data for a particular use. This information may include information on the source data used and the main transformation steps that took place in creating the current data set or data set series.


____
6.1. Lineage

This is a statement on process history and/or overall quality of the spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity.

The value domain of this metadata element is free text.
____

The [Regulation 1205/2008], Part B, 6.1 describes an element intended for describing this information:

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 1 is one.

[IMPORTANT]
====
*TG Requirement 1.11: metadata/2.0/req/datasets-and-series/lineage*

The lineage statement for the described data set or data set series shall be given. It shall be included in the _gmd:dataQualityInfo_/_gmd:DQ_DataQuality_ element scoped to the entire described data sets or data sets series as specified by TG Requirement 1.9.

The lineage shall be encoded using the _gmd:lineage_/_gmd:LI_Lineage_/_gmd:statement_ element with a Non-empty Free Text Element content, and it shall contain the description of the lineage of the described data set or series.

The multiplicity of this element is 1.
====

[TIP]
====
*TG Recommendation 1.12: metadata/2.0/rec/datasets-and-series/use-iso-dq-elements-and-measures*

If a data provider has a procedure for the quality management of their spatial data set (series) then the appropriate ISO data quality elements and measures should be used to evaluate and report (in the metadata) the results in addition to the Lineage metadata element.
====

[TIP]
====
*TG Recommendation 1.13: metadata/2.0/rec/datasets-and-series/lineage-avoid-acronyms*

The use of abbreviations (including acronyms) should be avoided. If used, their meaning should be explained.
====

=== Interoperability metadata for data sets and data set series

[NOTE]
====
*Conformance Class 2: metadata/2.0/_isdss_*

*Title:* INSPIRE data sets and data set series interoperability metadata.

**Conformance subject**: Metadata records describing INSPIRE data sets or data set series encoded in ISO 19139 based XML format.

Metadata record fulfilling all the Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for data sets and data set series as defined in [Regulation 1205/2008] and Article 13 "Metadata required for Interoperability" of [Regulation 1089/2010] and its amendment [Regulation 1253/2013].

This Conformance Class includes TG Requirements C.1 – C.22, TG Requirements 1.1 – 1.11 and TG Requirements 2.1 – 2.8 from this specification.
====

The metadata elements described in the section 3.2.1 are direct child elements of _gmd:MD_Metadata_ element. The metadata elements contained within elements _gmd:identificationInfo_, _gmd:distributionInfo_ and _gmd:dataQualityInfo_ are described in sections 3.2.2 - 3.2.4 correspondingly.

==== Direct properties of MD_Metadata element

===== Coordinates reference systems

Describing the coordinate reference system(s) used in the data set makes discovering data sets with spatial coordinates provided in desired reference systems possible.

The [Regulation 1089/2010], Article 13 (1) describes an element intended for describing this information:

{empty}
____
1. Coordinate Reference System: Description of the coordinate reference system(s) used in the data set.
____

The multiplicity of this element is one or more.

The [Regulation 1089/2010], Annex II, 1.5 states that the coordinate reference system identifiers used must originate from a common register:


____
1.5. Coordinate Reference System Identifiers

{empty}1. Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.

{empty}2. Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.
____

[IMPORTANT]
====
*TG Requirement 2.1: metadata/2.0/req/isdss/crs*

The coordinate reference system(s) used in the described data set or data set series shall be given using element _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier_.The multiplicity of this element is 1..*.The _gmd:code_ child element of _gmd:RS_Identifier_ is mandatory. The _gmd:codeSpace_ child element shall be used if the code alone does not uniquely identify the referred coordinate reference system. Both _gmd:code_ and _gmd:codeSpace_ element (if given) shall contain Non-empty Free Text Elements.

Only the coordinate reference system identifiers specified in a well-known common register shall be used.
====

[TIP]
====
*TG Recommendation 2.1: metadata/2.0/rec/isdss/source-crs*

If the data set is provided through a download service that provides coordinate transformation functionality (i.e. allows to provide the data set in any coordinate reference system supported by the service), the source coordinate reference system(s) of the data set should be documented in the metadata.
====

[IMPORTANT]
====
*TG Requirement 2.2: metadata/2.0/req/isdss/crs-id*

If the coordinate reference system is listed in the table Default Coordinate Reference System Identifiers in Annex D.4, the value of the HTTP URI Identifier column shall be used as the value of _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/ +
gmd:referenceSystemIdentifier/gmd:RS_Identifier/gmd:code_ element.

The _gmd:codeSpace_ element shall not be used in this case.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:referenceSystemInfo:**

<gmd:referencesysteminfo>
  <gmd:md_referencesystem>
    <gmd:referencesystemidentifier>
      <gmd:rs_identifier>
        <gmd:code>
          <gmx:anchor xlink:href="http://www.opengis.net/def/crs/EPSG/0/4258">
            EPSG:4258
          </gmx:anchor>
        </gmd:code>
      </gmd:rs_identifier>
    </gmd:referencesystemidentifier>
  </gmd:md_referencesystem>
</gmd:referencesysteminfo>
----
*Example* *3.13:* The coordinate reference system ETRS89-GRS80 declared as used in the provided data set using the gmx:Anchor free text element.

Some data sets (e.g. polulation distribution or health statistics) may have no direct spatial reference (i.e. a geometry attribute), but only an indirect one (e.g. to a statistical or administrative unit). In such cases, the data set providing the spatial reference (e.g. a data set of the NUTS statistical regions) should be considered as the spatial reference system for the data set. According to [ISO 19112], such reference systems are called “spatial reference systems using geographic identifiers”, but these are not conisered by [ISO 19139].

[TIP]
====
*TG Recommendation 2.2: metadata/2.0/rec/isdss/srs-using-geographic-identifiers*

Also spatial reference systems using geographic identifiers should be identified using the element _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/ +
gmd:referenceSystemIdentifier/gmd:RS_Identifier/gmd:code_. A _gmx:Anchor_ element should be used, whose _xlink:href_ attribute refers to a URI that provides further information about the spatial reference systems using geographic identifiers.
====

NOTE Best practices and examples on what URIs to use for spatial reference systems using geographic identifiers should be discussed on the thematic clusters platformfootnote:[e.g. in the Statistical Cluster (https://themes.jrc.ec.europa.eu/groups/profile/45/statistical-units-population-distribution-human-health-and-safety)].

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:referenceSystemInfo:**

<gmd:referencesysteminfo>
  <gmd:md_referencesystem>
    <gmd:referencesystemidentifier>
      <gmd:rs_identifier>
        <gmd:code>
          <gmx:anchor xlink:href="http://publications.europa.eu/resource/authority/atu">
            Administrative territoral units NAL
          </gmx:anchor>
        </gmd:code>
      </gmd:rs_identifier>
    </gmd:referencesystemidentifier>
  </gmd:md_referencesystem>
</gmd:referencesysteminfo>
----
*Example* *3.14:* Anchor element referring to a spatial reference systems using geographic identifiers (the list of the various administrative territorial units of the EU Member States, published by the EU Publications Office).

===== Temporal reference systems

Describing the temporal reference system(s) used in the data set makes discovering data sets with temporal coordinates provided in desired reference systems possible.

The [Regulation 1089/2010], Article 13 (2) describes an element intended for describing this information:

{empty}
____
2. Temporal Reference System: Description of the temporal reference system(s) used in the data set.This element is mandatory only if the spatial data set contains temporal information that does not refer to the default temporal reference system.
____

The multiplicity of this element is zero or more: it is not required if all temporal information in the data set uses the default temporal reference system. The default temporal reference system as regards to the INSPIRE metadata is Gregorian Calendar as defined in [Regulation 1205/2008], Annex, Part B, point 5.

[IMPORTANT]
====
*TG Requirement 2.3: metadata/2.0/req/isdss/temportal-rs*

The temporal reference system(s) used in the described data set or data set series shall be given using element _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier_.The multiplicity of this element is 0..n.

The _gmd:code_ child element of _gmd:RS_Identifier_ is mandatory. The _gmd:codeSpace_ child element shall be used if the code alone does not uniquely identify the referred coordinate reference system. Both _gmd:code_ and _gmd:codeSpace_ element (if given) shall contain Non-empty Free Text Elements.
====

[TIP]
====
*TG Recommendation 2.1: metadata/2.0/rec/isdss/*

If a commonly known unique identifier for the referred temporal reference system is available in a common register, the registered identifier should be used as the value of the _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier/gmd:code_ element.
====

NOTE The OGC Temporal Domain Working Group (TemporalDWG)footnote:[OGC TemporalDWG wiki: http://external.opengeospatial.org/twiki_public/TemporalDWG/WebHome] is working on an OGC Best Practice document covering temporal coordinate reference systems and their identifiers. Unfortunately at the time of writing this document was still in early draft version. It is expected that the unambiguous identification of temporal reference systems will become easier in the future as the OGC Naming Authority will endorse HTTP URI format identifiers for the most typically used temporal reference systems.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:referenceSystemInfo:**

<gmd:referencesysteminfo>
  <gmd:md_referencesystem>
    <gmd:referencesystemidentifier>
      <gmd:rs_identifier>
        <gmd:code>
          <gco:characterstring>
            Julian calendar
          </gco:characterstring>
        </gmd:code>
      </gmd:rs_identifier>
    </gmd:referencesystemidentifier>
  </gmd:md_referencesystem>
</gmd:referencesysteminfo>
----
*Example* *3.15:* Julian calendar declared as the temporal reference system used in the provided data set.

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo/gmd:MD_DataIdentification_ child element of the _gmd:MD_Metadata_ element.

===== Spatial representation type

The type in which the spatial data is represented may be of importance when evaluating the fit for purpose of the data set. The [Regulation 1089/2010], Article 13 (6) amended by [Regulation 1253/2013] describes an element intended for describing this information:

{empty}
____
6. Spatial Representation Type: The method used to spatially represent geographic information.
____

The multiplicity of this element is one or more. From the values allowed in [ISO 19139], only the values vector, grid, TINfootnote:[TIN stands for triangulated irregular network. TIN is a digital data structure used in a geographic information system (GIS) for the representation of a surface.] and textTablefootnote:[The value textTable was added to the values originally suggested in the data specifications, for data sets with an indirect spatial reference.] should be used.

[IMPORTANT]
====
*TG Requirement 2.4:* *metadata/2.0/req/isdss/spatial-representation-type*

The spatial representation type shall be given using element _gmd:spatialRepresentationType/gmd:MD_SpatialRepresentationTypeCode_ referring to one of the values of ISO 19139 code list MD_SpatialRepresentationTypeCode and one of the code list values "vector", "grid", "tin" or “textTable”footnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_SpatialRepresentationTypeCode" and attribute codeListValue with value "vector", "grid", "tin" or “textTable”.].

Multiplicity of this element is 1..*.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:spatialRepresentationType**

<gmd:spatialrepresentationtype>
  <gmd:md_spatialrepresentationtypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_SpatialRepresentationTypeCode" codelistvalue="vector">
  </gmd:md_spatialrepresentationtypecode>
</gmd:spatialrepresentationtype>
----
*Example* *3.16*: Spatial representation type of the described data set described as vector.

===== Character encoding

The character encoding describes the way the characters of the textual information are encoded in the described data set. The [Regulation 1089/2010], Article 13 (5) describes an element intended for describing this information:

{empty}
____
5. Character Encoding: The character encoding used in the data set.

This element is mandatory only if an encoding is used that is not based on UTF-8.
____

The multiplicity of this element is zero or more: this element is only required if there are non UTF-8 based character encodings used in the data set. UTF-8 is an 8-bit variable size Universal Coded Character Set (UCS) transfer format specified in [ISO 10646]footnote:[ISO 10646:2014 is downloadable from ISO/IEC Information Technology Task Force (ITTF) web site, http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html], section 9.2.

[IMPORTANT]
====
*TG Requirement 2.5: metadata/2.0/req/isdss/character-encoding*

The character encoding(s) shall be given for data sets and data sets series which use encodings not based on UTF-8 by using element _gmd:characterSet/gmd:MD_CharacterSetCode_ referring to one of the values of ISO 19139 code list MD_CharacterSetCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_CharacterSetCode".].

The multiplicity of this element is 0..n.

If more than one character encoding is used within the described data set or data sets series, all used character encodings, including UTF-8 (code list value "utf8"), shall be given using this element.
====

NOTE UTF-8 should be used for character encoding of INSPIRE data sets and data set series unless there are compelling and overriding reasons not to use it.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:characterSet**

<gmd:characterset>
  <gmd:md_charactersetcode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_CharacterSetCode" codelistvalue="8859part1">
  </gmd:md_charactersetcode>
</gmd:characterset>
----
*Example* *3.17*: ISO/IEC 8859-1 (also known as Latin 1) declared as the character encoding of the described data set.

==== Distribution info section

The metadata elements described in this section are contained within the _gmd:distributionInfo/gmd:MD_Distribution_ child element of _gmd:MD_Metadata_ element.

===== Data encoding

To be able to determine if the data is encoded in a structure and format the can be accessed using the tools and data processing systems available in users' environments, it is necessary to declare the encoding in metadata. The [Regulation 1089/2010], Article 13 (3) describes an element intended for describing this information:

{empty}
____
3. Encoding: Description of the computer language construct(s) specifying the representation of data objects in a record, file, message, storage device or transmission channel.
____

The multiplicity of this element is one or more.

[IMPORTANT]
====
*TG Requirement 2.6: metadata/2.0/req/isdss/data-encoding*

The encoding and the storage or transmission format of the provided data sets or data set series shall be given using the _gmd:distributionFormat/gmd:MD_Format_ element.

The multiplicity of this element is 1..*.The _gmd:name_ and _gmd:version_ child elements of _gmd:MD_Format_ are mandatory. Both of these elements shall contain Non-empty Free Text Elements.

If the version of the encoding is unknown or if the encoding is not versioned, the _gmd:version_ shall be left empty and the nil reason attribute shall be provided with either value "unknown" or "inapplicable" correspondinglyfootnote:[Attribute gco:nilReason="unknown" or "inapplicable".].
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:distributionInfo/gmd:distributionFormat:**

<gmd:distributionformat>
  <gmd:md_format>
    <gmd:name>
      <gco:characterstring>
        Addresses GML Application Schema
      </gco:characterstring>
    </gmd:name>
    <gmd:version>
      <gco:characterstring>
        3.0
      </gco:characterstring>
    </gmd:version>
    <gmd:specification>
      <gco:characterstring>
        D2.8.I.5 Data Specification on Addresses – Technical Guidelines
      </gco:characterstring>
    </gmd:specification>
  </gmd:md_format>
</gmd:distributionformat>
<gmd:distributionformat>
  <gmd:md_format>
    <gmd:name>
      <gmx:anchor xlink:href="http://inspire.ec.europa.eu/media-types/application/x-shapefile">
        Esri Shapefile
      </gmx:anchor>
    </gmd:name>
    <gmd:version gco:nilreason="unknown">
    </gmd:version>
  </gmd:md_format>
</gmd:distributionformat>
----
*Example* *3.18:* Data set has been declared to be available both in the INSPIRE Addresses GML Application Schema (encoded in XML) and in Esri Shapefile format. The gmx:Anchor is used to describe the latter, as the format is included in the code list for supported INSPIRE media types.

==== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

===== Topological consistency

Topological consistency is an important aspect of the data quality of a spatial data set: it describes trustworthiness and consistency of the geometry property values of the data set. Examples of such consistency measures would be number of incorrect line intersections, incorrectly closed polygons, duplicate curves or gaps in curves. These measures fall under a wider category of logical consistency of the data set. Topological consistency metadata element is described in [Regulation 1089/2010], Article 13 (4):

{empty}
____
4. Topological Consistency: Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.
____

The multiplicity of this element is zero or more with the following condition: The element is mandatory if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.

While the [Regulation 1089/2010] does not provide further guidance on how this element should be reported, the INSPIRE Data specifications include guidance on reporting topological consistency in two ways based on [ISO 19157]: by providing quantitative and descriptive results of the tests or checks done for the described data set. The former are expressed as numerical result values of specific topological consistency tests, and the latter by textual descriptions of the topological consistency checks.

*Providing quantitative results*

[IMPORTANT]
====
*TG Requirement 2.7: metadata/2.0/req/isdss/topological-consistency-quantitative-results*

The quantitative results for topological consistency measures shall be reported using the _gmd:report/gmd:DQ_TopologicalConsistency_ element with a _gmd:DQ_QuantitativeResult_ element as the value of its mandatory _gmd:result_ property.

The multiplicity of the element is 0..*.The _gmd:valueUnit_ and _gmd:value/gco:Record_ child elements of _gmd:DQ_QuantitativeResult_ are mandatory and shall be used for giving a numerical or otherwise quantitative value of the evaluated topology consistency measure for the described data set or data set series.

The type of the _gmd:value/gco:Record_ element shall be chosen based on the result type of the particular measure, and it shall be declared using the _xsi:type_ attribute of the _gco:Record element_.
====

[TIP]
====
*TG Recommendation 2.2: metadata/2.0/rec/isdss/topological-consistency-measure-name*

The name of the topology consistency measure should be provided using the _gmd:nameOfMeasure_ child element of each of the _gmd:DQ_QuantitativeResult_ elements__.__ This element is a Non-empty Free Text Element. In the case where the result reflects more than one measure, a separate _gmd:nameOfMeasure_ should be given to identify each included measure.
====

[TIP]
====
*TG Recommendation 2.3: metadata/2.0/rec/isdss/topological-consistency-evaluation-method*

It is recommended to provide a short description of the evaluation method used for topological consistency check using the gmd:evaluationMethodDescription child element of _gmd:DQ_QuantitativeResult_ element__.__ This element is a Non-empty Free Text Element.

If applicable, the evaluation method type should be declared using the _gmd:evaluationMethodType/gmd:DQ_EvaluationMethodTypeCode_ child element of _gmd:DQ_QuantitativeResult_ element referring to one of the values of ISO 19139 code list DQ_EvaluationMethodTypeCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#DQ_EvaluationMethodTypeCode"].
====

[TIP]
====
*TG Recommendation 2.4: metadata/2.0/rec/isdss/topological-consistency/date*

It is recommended to provide the date of evaluating the topological consistency check using the _gmd:dateTime/gco:DateTime_ child element of _gmd:DQ_QuantitativeResult_ element__.__ The value shall be expressed using Gregorian calendar and in accordance with [ISO 8601] date and time precision.
====

Example 3.19 contains an example of the quantitative results of one measure for the topological consistency evaluated for a data set in the INSPIRE Hydrography theme.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_TopologicalConsistency:**

<gmd:dq_topologicalconsistency>
  <gmd:nameofmeasure>
    <gco:characterstring>
      number of faulty point-curve connections
    </gco:characterstring>
  </gmd:nameofmeasure>
  <gmd:evaluationmethodtype>
    <gmd:dq_evaluationmethodtypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#DQ_EvaluationMethodTypeCode" codelistvalue="indirect">
      Indirect
    </gmd:dq_evaluationmethodtypecode>
  </gmd:evaluationmethodtype>
  <gmd:evaluationmethoddescription>
    <gco:characterstring>
      A point-curve connection exists where different curves touch. These curves have an intrinsic topological relationship that shall reflect the true constellation. If the point-curve connection contradicts the universe of discourse, the point-curve connection is faulty with respect to this data quality measure. The data quality measure counts the number of errors of this kind.
    </gco:characterstring>
  </gmd:evaluationmethoddescription>
  <gmd:datetime>
    <gco:datetime>
      2015-04-01T16:20:00
    </gco:datetime>
  </gmd:datetime>
  <gmd:result>
    <gmd:dq_quantitativeresult>
      <gmd:valueunit xlink:href="http://www.opengis.net/def/uom/OGC/1.0/unity">
      </gmd:valueunit>
      <gmd:value>
        <gco:record xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:integer">
          12
        </gco:record>
      </gmd:value>
    </gmd:dq_quantitativeresult>
  </gmd:result>
</gmd:dq_topologicalconsistency>
----
*Example* *3.19:* Topological consistency reported using the quantitative result of one measure "number of faulty point-curve connections". The measure has been evaluated on 1st April 2015, and the type of resulting gco:Record element has been defined as integer using the local typing (xsi:type attribute).

*Providing descriptive results*

The descriptive topological consistency measure is properly described in [ISO 19157], but unfortunately there is no obvious element for encoding it in the [ISO 19139] XML Schemas. To make it possible to encode the descriptive results without extending the [ISO 19139] XML Schema, the _gmd:DQ_TopologicalConsistency_ element is used with a specific type of _gmd:DQ_ConformanceResult_ element referring to the INSPIRE Generic Network Model. The actual textual description of the consistency result is reported using the _gmd:explanation_ property.

[IMPORTANT]
====
*TG Requirement 2.8: metadata/2.0/req/isdss/topological-consistency-descriptive-results*

If the data set includes types from the Generic Network Model, it does not assure the centreline topology for the network, and the value of the topological consistency checks is not available as quantitative results, the result of the topological consistency shall be reported using the descriptive results.

The descriptive topological consistency measures shall be reported using the _gmd:report/gmd:DQ_TopologicalConsistency/gmd:result +
/gmd:DQ_ConformanceResult_ element citing to the INSPIRE Generic Network Model.

The _gmd:DQ_ConformanceResult/gmd:specification/gmd:CI_Citation/ +
gmd:title/gco:CharacterString_ element shall have the value "INSPIRE Data Specifications - Base Models - Generic Network Model" regardless of the metadata language.

The _gmd:DQ_ConformanceResult/gmd:specification/gmd:CI_Citation/ gmd:date/gmd:CI_Date/gmd:date_ shall contain the publication date of the INSPIRE Generic Network Model document containing the geometry types used in the data set.

The date type code element _gmd:DQ_ConformanceResult/ +
gmd:specification/gmd:CI_Citation/_ gmd:date/gmd:CI_Date/gmd:dateType/gmd:CI_DateTypeCode shall be given and it shall point to the value "publication" of the ISO 19139 code list CI_DateTypeCode.

The value of the _gmd:DQ_ConformanceResult/gmd:pass_ element shall always be "false" in this element to indicate that the data set does not assure the centreline topology for the network.

The multiplicity of _gmd:report/gmd:DQ_TopologicalConsistency/gmd:result/ +
gmd:DQ_ConformanceResult_ elements as described above is 0..*.The textual description of the results of the topological consistency check shall be given using the _gmd:DQ_ConformanceResult/gmd:explanation_ element. This element is a Non-empty Free Text Element.
====

Example 3.20 contains an example of the descriptive results of the topological consistency for a data set in the INSPIRE Transport networks theme.

NOTE The value "true" of gmd:report/gmd:DQ_TopologicalConsistency/gmd:result/ gmd:DQ_ConformanceResult/gmd:pass shall not be used to indicate a successful passing of the topological consistency checks. Only gmd:report/gmd:DQ_TopologicalConsistency/gmd:result/ gmd:DQ_ConformanceResult elements with the value of gmd:pass equal "false" are considered as implementations of the descriptive results of the topological consistency as defined in [Regulation 1089/2010].

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_TopologicalConsistency:**

<gmd:dq_topologicalconsistency>
  <gmd:nameofmeasure>
    <gco:characterstring>
      Network connectivity
    </gco:characterstring>
  </gmd:nameofmeasure>
  <gmd:evaluationmethodtype>
    <gmd:dq_evaluationmethodtypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#DQ_EvaluationMethodTypeCode" codelistvalue="directInternal">
      Direct, internal
    </gmd:dq_evaluationmethodtypecode>
  </gmd:evaluationmethodtype>
  <gmd:evaluationmethoddescription>
    <gco:characterstring>
      Check that wherever a connection exists in a transport network, all connected link ends and the optional node that take part in this connection are positioned at a distance of less than the connectivity tolerance from each other. Check that link ends and nodes that are not connected are always separated by a distance that is greater than the connectivity tolerance. Check if in data sets where both transport links and nodes are presented, the relative position of nodes and link ends in relation to the specified connectivity tolerance corresponds to the associations that exist between them in the data set.
    </gco:characterstring>
  </gmd:evaluationmethoddescription>
  <gmd:datetime>
    <gco:datetime>
      2015-04-01T16:20:00
    </gco:datetime>
  </gmd:datetime>
  <gmd:result>
    <gmd:dq_conformanceresult>
      <gmd:specification>
        <gmd:ci_citation>
          <gmd:title>
            <gco:characterstring>
              D2.10.1 INSPIRE Data Specifications - Base Models - Generic Network Model
            </gco:characterstring>
          </gmd:title>
          <gmd:date>
            <gmd:ci_date>
              <gmd:date>
                <gco:date>
                  2013-04-05
                </gco:date>
              </gmd:date>
              <gmd:datetype>
                <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                  publication
                </gmd:ci_datetypecode>
              </gmd:datetype>
            </gmd:ci_date>
          </gmd:date>
        </gmd:ci_citation>
      </gmd:specification>
      <gmd:explanation>
        <gco:characterstring>
          Topological consistency has been verified following the requirements of the INSPIRE Data Specification on Transport Networks - Technical Guidelines. No errors have been found.
        </gco:characterstring>
      </gmd:explanation>
      <gmd:pass>
        <gco:boolean>
          false
        </gco:boolean>
      </gmd:pass>
    </gmd:dq_conformanceresult>
  </gmd:result>
</gmd:dq_topologicalconsistency>
----
*Example* *3.20:* Topological consistency reported using the descriptive result of one measure "Network connectivity".

==== Recommended theme-specific metadata elements

The INSPIRE data specifications [TG DS] include a number of “recommended theme-specific metadata elements” in their sections 8.3. All of them are optional but recommended for certain INSPIRE annex themes.

*TG Recommendation 2.5: metadata/2.0/rec/isdss/recommended-theme-specific-md-elements*

The recommended metadata elements should be included to metadata describing a spatial dataset or spatial dataset series related to the annex themes specified for the relevant element in Annex C.7.

Many of these theme-specific metadata consider details of particular INSPIRE annex themes in definitions and examples. These are listed in Annex C.7.

== Conformance Classes for Spatial Data Services

=== Baseline metadata for Spatial Data Services

[NOTE]
====
*Conformance Class 3: metadata/2.0/_sds_*

*Title:* INSPIRE Spatial Data Service baseline metadata.

**Conformance subject**: Metadata records describing INSPIRE Spatial Data Services encoded in ISO 19139 based XML format.

Metadata record fulfilling all the Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for Spatial Data Services as defined in [*Regulation 1205/2008*].

This Conformance Class includes TG Requirements C.1 – C.22 and TG Requirements 3.1 – 3.8 of this specification.
====

This Conformance Class covers all the Technical Guidance Requirements concerning metadata contained in [TG SDS].

The metadata elements described in the section 4.1.1 are direct child elements of _gmd:MD_Metadata_ element. The metadata elements contained within elements _gmd:identificationInfo_, _gmd:distributionInfo_ and _gmd:dataQualityInfo_ are described in sections 4.1.2 - 4.1.4 correspondingly.

==== Direct properties of MD_Metadata element

===== Resource type

This is the type of resource being described by the metadata and it is filled in with a value from a classification of the resource based on its scope.

The element for declaring the type of the resource is described in [Regulation 1205/2008], Part B, 1.3:


____
1.3. Resource type

This is the type of resource being described by the metadata. The value domain of this metadata element is defined in Part D.1
____

Table 2 contained in Part C of the same document defines the multiplicity of this element to exactly one for Spatial Data Services.

To comply with ISO 19115 the _hierarchyLevelName_ element shall also be given, if the value of _hierarchyLevel_ is not "dataset".

[IMPORTANT]
====
*TG Requirement 3.1: metadata/2.0/req/sds/resource-type*

Resource type shall be declared as "service" using _gmd:hierarchyLevel/gmd:MD_ScopeCode_ elementfootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" and the attribute codeListValue with value "service".].

Additionally the name of the hierarchy level shall be given using element _gmd:hierarchyLevelName_ element with a Non-empty Free Text Element containing the term "service" in the language of the metadata.

The multiplicity of both of these elements is 1.
====

Example 4.1 gives an example of the XML code for these elements.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:hierarchyLevel:**

<gmd:hierarchylevel>
  <gmd:md_scopecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" codelistvalue="service">
  </gmd:md_scopecode>
</gmd:hierarchylevel>
<gmd:hierarchylevelname>
  <gco:characterstring>
    Service
  </gco:characterstring>
</gmd:hierarchylevelname>
----
*Example* *4.1:* Resource type indicating a service given using gmd:hierarchyLevel and gmd:hierarchyLevelName properties.

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo_ property of the _gmd:MD_Metadata_ element.

[IMPORTANT]
====
*TG Requirement 3.2: metadata/2.0/req/sds/service-identification-element*

The first _gmd:identificationInfo_ property of _gmd:MD_Metadata_ element shall contain a _srv:SV_ServiceIdentification_ element for identifying an INSPIRE Spatial Data Service.
====

===== Restriction on the spatial resolution

Spatial resolution refers to the level of detail of the data set. It shall be expressed as a set of zero to many resolution distances (typically for gridded data and imagery-derived products) or equivalent scales (typically for maps or map-derived products).

The [Regulation 1205/2008], Part B 6.2 describes the element for expressing the spatial resolution of provided data sets:


____
6.2. Spatial resolution

Spatial resolution refers to the level of detail of the data set. It shall be expressed as a set of zero to many resolution distances (typically for gridded data and imagery-derived products) or equivalent scales (typically for maps or map-derived products).

An equivalent scale is generally expressed as an integer value expressing the scale denominator.

A resolution distance shall be expressed as a numerical value associated with a unit of length.
____

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 2 is zero or more, with the following condition: "Mandatory when there is a restriction on the spatial resolution for this service".

For services, it is not possible to express the restriction of a service concerning the spatial resolution in using the ISO 19139 XML Schema. This problem has been solved in the [ISO 19115-3] standard expected to be published in summer 2016. This slightly inconvenient way of declaring the Spatial resolution for Spatial Data Services shall be used until this specification has been revised to comply with XML Schema rules of [ISO 19115-3].

[IMPORTANT]
====
*TG Requirement 3.3: metadata/2.0/req/sds/spatial-resolution*

For services with restriction on the spatial resolution, these restrictions shall be expressed in the _gmd:abstract_ element with a Non-empty Free Text Element content.

The spatial resolution restriction text shall include either an equivalent scale as integer valued scale denominator or a resolution distance using a numerical length value and with a unit of length.
====

[TIP]
====
*TG Recommendation 3.1: metadata/2.0/rec/sds/spatial-resolution-interval*

If the spatial resolution is an interval, both bounding values of the interval should be given.
====

===== Spatial Data Service category keywords

Each INSPIRE Spatial Data Service must be classified using ISO 19119 based list of categories and subcategories as defined in the [Regulation 1205/2008], Part D 4. This classification helps users in evaluating if the described service is useful in a particular use case. [INSPIRE Directive], Article 11(2)(b) requires this classification information to be provided also as search criteria in INSPIRE Discovery Services.

The element for giving this information is described in [Regulation 1205/2008], Part B 3:

{empty}
____
3. KEYWORD

If the resource is a spatial data service, at least one keyword from Part D.4 shall be provided.
____

[IMPORTANT]
====
*TG Requirement 3.4: metadata/2.0/req/sds/sds-category*

At least one Spatial Data Service category or subcategory for the described service shall be given using the language-neutral keyword values as defined in Part D 4 “Classification of Spatial Data Services” of [Regulation 1205/2008].
====

[TIP]
====
*TG Recommendation 3.2: metadata/2.0/rec/sds/sds-category-cv*

To make the reference to the keywords values in [Regulation 1205/2008], Part D 4 clear, these keywords should be expressed as keywords from a controlled vocabulary and using _gmx:Anchor_ elements with references to the _Classification of spatial data services_ code list in the INSPIRE registryfootnote:[http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory]. The _gmd:thesaurusName_ element of the enclosing _gmd:MD_Keywords_ element should be added and it should contain the citation to the [Regulation 1205/2008], Part D 4 and its publication date according to section 2.4.5.
====

[TIP]
====
*TG Recommendation 3.3: metadata/2.0/rec/sds/additional-keywords*

In addition to the required keyword from the categories from part D 4 of the [Regulation 1205/2008], it is suggested to choose a minimum of two additional keywords describing the service or the data sets provided by it.
====

For an XML example, see Example 4.2.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords:**

<gmd:md_keywords>
  <gmd:keyword>
    <gmx:anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/humanCatalogueViewer">
      humanCatalogViewer
    </gmx:anchor>
  </gmd:keyword>
  <gmd:thesaurusname>
    <gmd:ci_citation>
      <gmd:title>
        <gco:characterstring>
          COMMISSION REGULATION (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata, Part D 4, Classification of Spatial Data Services
        </gco:characterstring>
      </gmd:title>
      <gmd:date>
        <gmd:ci_date>
          <gmd:date>
            <gco:date>
              2008-12-03
            </gco:date>
          </gmd:date>
          <gmd:datetype>
            <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
            </gmd:ci_datetypecode>
          </gmd:datetype>
        </gmd:ci_date>
      </gmd:date>
    </gmd:ci_citation>
  </gmd:thesaurusname>
</gmd:md_keywords>
----
*Example* *4.2:* Declaring Spatial Data Service category or subcategory as a keyword.

===== Spatial Data Service type

The [Regulation 1205/2008], Part B 2.2 describes the element for providing a classification to assist in the search of available Spatial Data Services.


____
2.2. Spatial data service type

This is a classification to assist in the search of available spatial data services. A specific service shall be categorised in only one category.The value domain of this metadata element is defined in Part D.3.
____

The list of language-neutral values as in Part D3 of the [Regulation 1205/2008].

NOTE The value "invoke" should no longer be used, since the obligation to provide (network) “services allowing spatial data services to be invoked” is being fulfilled through the provision of the additional metadata elements defined in Annexes V-VII of [Regulation 1089/2010]. See [SDS TG, section 4.2.2] for further details.

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 2 is one.

[IMPORTANT]
====
*TG Requirement 3.5: metadata/2.0/req/sds/sds-type*

Spatial Data Service type shall be given using element _srv:serviceType_/_gco:LocalName_.The multiplicity of this element is 1.
====

The specific TG Requirements for the allowed Spatial Data Service type values are given in Requirement Classes for Network Services (section 4.2) and Invocable Spatial Data Services (section 4.3).

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/srv:serviceType:**

<srv:servicetype>
  <gco:localname codespace="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType">
    view
  </gco:localname>
</srv:servicetype>
----
*Example* *4.3:* Spatial Data Service type "view"

NOTE Since the value domain of this metadata element is restricted to the values defined in Part D3 and the multiplicity of the element is 1, it is not possible to provide a more detailed type for the service (e.g. OGC:WMS or OGC:WMTS for a view service). Such addirional information can be provided in several ways in the metadata, e.g. using keywords, the _srv:serviceTypeVersion_ element or the _gmd:protocol_ element nested inside the _gmd:transferOptions_.

===== Linking to provided data sets using coupled resource

This metadata element refers to, where relevant, the target spatial data set(s) of the described service. It is implemented by reference, i.e. through a URL that points to the metadata record of the data on which the service operates. It helps therefore linking services to the relevant datasets.

The element for giving this information is described in [Regulation 1205/2008], Part B 1.6:


____
1.6. Coupled resource

If the resource is a spatial data service, this metadata element identifies, where relevant, the target spatial data set(s) of the service through their unique resource identifiers (URI).

The value domain of this metadata element is a mandatory character string code, generally assigned by the data owner, and a character string namespace uniquely identifying the context of the identifier code (for example, the data owner).
____

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 2 is zero or more, with the following condition: "Mandatory if linkage to data sets on which the service operates are available". According to [ISO 19119] the coupled resource is encoded using operatesOn property and it is value is the MD_DataIdentification element of the data set.

[IMPORTANT]
====
*TG Requirement 3.6: metadata/2.0/req/sds/coupled-resource*

Links pointing to the online metadata descriptions of data sets provided by the described service shall be given using _srv:operatesOn_ element.

The multiplicity of this element is 0..n.

This property shall be implemented by reference. The _xlink:href_ attribute of each of the _srv:operatesOn_ elements shall contain a URI pointing to the _gmd:MD_DataIdentification_ element of the metadata record of the provided the data set or data set series.
====

“Implementation by reference” means that the xlink:href attribute is pointing to an XML document that contains a _gmd:MD_DataIdentification_ object.

The reference to the _gmd:MD_DataIdentification_ element can be implemented e.g. in the following ways:

* Point to the _gmd:MD_DataIdentification_ elements using so called fragment identifiers added at the end of the URL address of the metadata document separated by a hash mark "#"footnote:[See IETF RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, https://tools.ietf.org/html/rfc3986]. The value of the fragment identifier should either match the value of the _id_ attribute of the referred _gmd:MD_DataIdentification_ element or be another valid XPointer expression referring to the _gmd:MD_DataIdentification_ element. This kind of URL forms a valid XPointerfootnote:[W3C Recommendation: XPointer Framework, https://www.w3.org/TR/xptr-framework/] that can be understood and resolved and verified precisely by clients. (see Example 4.4 and Example 4.5).Note that the _id_ attribute of _gmd:MD_DataIdentification_ is optional, so it may not always exist in the referred metadata record. See TG Recommendation 1.1 for more info.
* Point to the _gmd:MD_DataIdentification_ element by using the Unique Resource Identifier of the target spatial dataset itself. The URI needs to resolve to the _gmd:MD_DataIdentification_ element, e.g. through a dedicated resolver service translating the URI into a CSW request. (see Example 4.6).

NOTE The INSPIRE metadata element 1.6 _Coupled resource_ is not mapped to the _srv:coupledResource_/_srv:SV_CoupledResource_ element.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/srv:operatesOn:**

<srv:operateson xlink:href="http://example.com/csw?SERVICE=CSW&amp;VERSION=2.0.2&amp;REQUEST=GetRecordById&amp;ID=f9ee6623-cf4c-11e1-9105-0017085a97ab&amp;OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&amp;ELEMENTSETNAME=full#md-so-1002001">
</srv:operateson>
----
*Example* *4.4:* Coupled resource link given using the srv:operatesOn element with URL containing a fragment identifier pointing to the gmd:MD_DataIdentification element with the corresponding id attribute value "md-so-1002001".

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/srv:operatesOn:**

<srv:operateson xlink:href=" http://example.com/csw?SERVICE=CSW&amp;VERSION=2.0.2&amp;STARTPOSITION=1&amp;MAXRECORDS=10&amp;REQUEST=GetRecords&amp;RESULTTYPE=results&amp;OUTPUTFORMAT=application/xml&amp;OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&amp;TYPENAMES=gmd:MD_Metadata&amp;ELEMENTSETNAME=brief&amp;CONSTRAINT_LANGUAGE_VERSION=1.1.0&amp;CONSTRAINTLANGUAGE=CQL_TEXT&amp;NAMESPACE=xmlns%28ogc=http://www.opengis.net/ogc%29,xmlns%28gml=http://www.opengis.net/gml%29,xmlns%28apiso=http://www.opengis.net/cat/csw/apiso/1.0%29,xmlns%28csw=http://www.opengis.net/cat/csw/2.0.2%29&amp;constraint=apiso:identifier%20Like%20%27%26\{Identifier of the resource}%26%27&amp;#MD_DataIdentification">
</srv:operateson>
----
*Example* *4.5:* Coupled resource link given using the srv:operatesOn element with URL containing a CSW GetRecords request including a query for the resource identifier (shown as \{Identifier of the resource}).

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/srv:operatesOn:**

<srv:operateson xlink:href="https://registry.gdi-de.org/id/de.nw/inspire-cp-alkis">
</srv:operateson>
----
*Example* *4.6:* Coupled resource link given using the Unique resource identifier URL of the referred data set as the value of the xlink:href attribute of srv:operatesOn element. The given URL automatically redirects to another URLfootnote:[http://gdk.gdi-de.org/gdi-de/srv/eng/csw?REQUEST=GetRecords&SERVICE=CSW&VERSION=2.0.2&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&constraintLanguage=CQL_TEXT&constraint=ResourceIdentifier+like+%27https://registry.gdi-de.org/id/de.nw/inspire-cp-alkis%27&constraint_language_version=1.1.0&typenames=csw:Record&resulttype=results&elementsetname=full#xpointer%28//gmd:identificationInfo[1]/gmd:MD_DataIdentification%29[http://gdk.gdi-de.org/gdi-de/srv/eng/csw?REQUEST=GetRecords&SERVICE=CSW&VERSION=2.0.2&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&constraintLanguage=CQL_TEXT&constraint=ResourceIdentifier+like+%27https://registry.gdi-de.org/id/de.nw/inspire-cp-alkis%27&constraint_language_version=1.1.0& +
typenames=csw:Record&resulttype=results&elementsetname=full#xpointer%28//gmd:identificationInfo[1]/gmd:MD_DataIdentification%29]] returning the gmd:MD_DataIdentification element

==== Distribution info section

The metadata elements described in this section are contained within the _gmd:distributionInfo/gmd:MD_Distribution_ child element of _gmd:MD_Metadata_ element.

===== Resource locator for services

The Resource Locator for Spatial Data Services, if available, provides the access point of the service, that is an Internet-resolvable address containing a detailed description of a Spatial Data Service, including a list of endpoints to allow an automatic execution.

The [Regulation 1205/2008], Part B, 1.4 describes an element intended for this information:


____
1.4. Resource locator

The resource locator defines the link(s) to the resource and/or the link to additional information about the resource.

The value domain of this metadata element is a character string, commonly expressed as uniform resource locator (URL).
____

The multiplicity of this element as defined in [Regulation 1205/2008], Part C, Table 2 is zero or more, and it is "mandatory if linkage to the service is available".

[IMPORTANT]
====
*TG Requirement 3.7: metadata/2.0/req/sds/resource-locator*

A Resource locator linking to the described Spatial Data Service shall be given, if online access to this service is available.

If no online access to the described Spatial Data Service is available, but there is a publicly available online resource providing additional information about the described service, the URL pointing to this resource shall be given instead.

These links shall be encoded using _gmd:transferOptions_/_gmd:MD_DigitalTransferOptions_/_gmd:onLine_/ +
_gmd:CI_OnlineResource_/_gmd_:_linkage_/_gmd:URL_ element.

The multiplicity of this element is 0..n.
====

A Resource Locator encoded using the _gmd:CI_OnlineResource_ element may also include _gmd:name_, _gmd:description_, and _gmd:function_ properties.

[TIP]
====
*TG Recommendation 3.4: metadata/2.0/rec/sds/resource-locator-additional-info*

It is recommended that in addition to the mandatory _gmd:linkage_ element also _gmd:name_, _gmd:description_, and _gmd:function_/_gmd:CI_OnLineFunctionCode_ child elements of _gmd:CI_OnlineResource_ element are provided to give additional information about the provided URL link. The _gmd:name_ and the _gmd:description_ elements should contain Non-empty Free Text Elements.

If provided, the _gmd:CI_OnLineFunctionCode_ element should point to one of the values of the ISO 19139 code list CI_OnLineFunctionCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode".]_._

*_TG Recommendation 3.5: metadata/2.0/rec/sds/resource-type-url-target_*

The URL provided as the value of the _gmd:transferOptions_/_gmd:MD_DigitalTransferOptions_/_gmd:onLine_/_gmd:CI_OnlineResource_/_gmd_: _linkage_/_gmd:URL_ element should point to one of following type of resources:- a service metadata (capabilities) document of described Spatial Data Service,- a service WSDLfootnote:[W3C Web Services Description Language, https://www.w3.org/TR/wsdl] document of the described Spatial Data Service (if SOAPfootnote:[W3C Simple Object Access Protocol, or more recently, just SOAP, https://www.w3.org/TR/soap/] binding is available), or - a web page with further instructions for accessing the described service.
====


[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions:**

<gmd:transferoptions>
  <gmd:md_digitaltransferoptions>
    <gmd:online>
      <gmd:ci_onlineresource>
        <gmd:linkage>
          <gmd:url>
            http://example.com/wfs?VERSION=2.0.0&amp;SERVICE=WFS&amp;REQUEST=GetCapabilities
          </gmd:url>
        </gmd:linkage>
        <gmd:name>
          <gco:characterstring>
            WFS GetCapabilities request providing machine readable service metadata
          </gco:characterstring>
        </gmd:name>
        <gmd:function>
          <gmd:ci_onlinefunctioncode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode" codelistvalue="download">
          </gmd:ci_onlinefunctioncode>
        </gmd:function>
      </gmd:ci_onlineresource>
    </gmd:online>
  </gmd:md_digitaltransferoptions>
</gmd:transferoptions>
----
*Example* *4.7:* Resource locator pointing to the GetCapabilities operation of the described WFS service.

==== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

===== Scope

[IMPORTANT]
====
*TG Requirement 3.8: metadata/2.0/req/sds/only-one-dq-element*

There shall be exactly one _gmd:dataQualityInfo/gmd:DQ_DataQuality_ element scoped to the entire described service.

The scoping shall be encoded using _gmd:scope_/_gmd:DQ_Scope_/_gmd:level_/_gmd:MD_ScopeCode_ element referring to value "service" of [ISO 19139] code list MD_ScopeCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" and the attribute codeListValue with value "service".].

Additionally the level shall be named using element _gmd:scope/gmd:DQ_Scope/gmd:levelDescription/gmd:MD_ScopeDescription/gmd:other_ element with a Non-empty Free Text Element containing the term "service" in the language of the metadata.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:scope/gmd:DQ_Scope:**

<gmd:dq_scope>
  <gmd:level>
    <gmd:md_scopecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode" codelistvalue="service">
    </gmd:md_scopecode>
  </gmd:level>
  <gmd:leveldescription>
    <gmd:md_scopedescription>
      <gmd:other>
        <gco:characterstring>
          Service
        </gco:characterstring>
      </gmd:other>
    </gmd:md_scopedescription>
  </gmd:leveldescription>
</gmd:dq_scope>
----
*Example* *4.8:* Scope of the Data quality info is set to the entire described Spatial Data Service by giving both the code (gmd:level) and the corresponding description of the level (gmd:levelDescription).

=== Metadata for Network Services

[NOTE]
====
*Conformance Class 4: metadata/2.0/_ns_*

*Title:* INSPIRE Network Services metadata.

**Conformance subject**: metadata record describing an INSPIRE Network Service encoded in ISO 19139 based XML format.

Metadata record fulfilling all the Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for Spatial Data Services as defined in [*Regulation 1205/2008*].footnote:[The [Regulation 976/2009] containing Implementing Rules for Network services does not contain any additional requirements for metadata. The requirements in this Requirements Class originate from the Network Services specific parts of [Regulation 1205/2008].]This Conformance Class includes TG Requirements C.1 – C.22, TG Requirements 3.1 – 3.8, and TG Requirement 4.1 of this specification.
====

Most of the metadata requirements for INSPIRE Network Services are contained in Conformance Class 3: INSPIRE Spatial Data Service baseline metadata. Though brief, this Conformance Class is added here to make clear which metadata requirements apply to Network Services.

The metadata elements contained within elements _gmd:identificationInfo_ and _gmd:dataQualityInfo_ are described in sections 4.2.1 and 4.2.2 correspondingly.

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo/srv:SV_ServiceIdentification_ child element of the _gmd:MD_Metadata_ element.

===== Spatial Data Service type

[IMPORTANT]
====
*TG Requirement 4.1: metadata/2.0/req/ns/sds-type*

Spatial Data Service type shall be given encoded as specified in TG Requirement 3.5. The value for the element shall be "view", "download", "discovery" or "transformation" depending on the kind of the described Network Service.

The multiplicity of the _srv:serviceType/gco:LocalName_ element used for the above purpose is 1.
====

==== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

===== Conformity

In conformance to [INSPIRE Directive], the metadata shall include a statement on the degree of conformity with the specifications against which its conformity has been evaluated.

[TIP]
====
*TG Recommendation 4.1: metadata/2.0/rec/ns/conformity*

Metadata for an INSPIRE Network Services should declare the conformity to the Network Services Implementation Rules, and it should be encoded using _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/ +
gmd:DQ_ConformanceResult_ element as specified in the TG Requirement C.20footnote:[TG Requirement C.20: degree of conformity using _gmd:DQ_ConformanceResult._]. This element should contain a citation for the [Regulation 976/2009] encoded according to TG Requirement C.21footnote:[TG Requirement C.21: _gmd:DQ_ConformanceResult_ shall include a citation of the specification document, ...]. The degree of conformity should be encoded according to TG Requirement C.22footnote:[TG Requirement C.22: … _gmd:DQ_ConformanceResult …_ shall also include the degree of declared conformity…].

The multiplicity of the _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/ +
gmd:DQ_ConformanceResult_ element used for the above purpose is 1.
====

[TIP]
====
*TG Recommendation 4.2: metadata/2.0/rec/ns/uri-for-regulation-976-2009*

If providing the specification title as an _gmx:Anchor_ element (as recommended in TG Recommendation C.11), the following URI should be used to refer to [Regulation 976/2009]: http://data.europa.eu/eli/reg/2009/976.
====

NOTE A pre-defined XML fragment containing the corresponding _CI_Citation_ element for [Regulation 976/2009] will be provided at http://inspire.ec.europa.eu/id/citation/ir/reg-976-2009

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification xlink:href="http://inspire.ec.europa.eu/id/citation/ir/reg-976-2009">
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href="http://data.europa.eu/eli/reg/2009/976">
            COMMISSION REGULATION (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2010-12-08
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This data set is conformant with the INSPIRE Implementing Rules for Network Services
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *4.9:* Conformity declaration against the [Regulation 976/2009].

Metadata for an INSPIRE network services can also include additional declarations of conformity, in particular to the abstract test suites and conformance classes defined for the INSPIRE technical guidance documents.

[TIP]
====
*TG Recommendation 4.3: metadata/2.0/rec/ns/uris-for-ats-and-cc*

If declaring conformity to an abstract test suite or a conformance class using an _gmx:Anchor_ element (as recommended in TG Recommendation C.11), the URI identifying the abstract test suite or a conformance class should be used in the _xlink:href_ attribute of the specification title element.
====

NOTE It is not currently planned to provide pre-defined XML fragments containing the _CI_Citation_ elements for the INSPIRE TG documents in the http://inspire.ec.europa.eu/id/citation/ namespace. However, such fragments can be added if this is deemed useful by INSPIRE data providers.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification>
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href="http://inspire.ec.europa.eu/id/ats/download-service/3.1/wfs-pre-defined">
            Technical Guidance for Download Services, version 3.1 - Conformance class: Pre-defined WFS
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2014-04-17
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This data set is conformant with Conformance class: Pre-defined WFS of the INSPIRE Technical Guidance for Download Services, version 3.1
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *4.10:* Conformity declaration against a conformance class.

=== Metadata for Invocable Spatial Data Services

[NOTE]
====
*Conformance Class 5: metadata/2.0/sds-invocable*

*Title:* INSPIRE Invocable Spatial Data Services metadata.

**Conformance subject**: metadata record describing a Spatial Data Service encoded in ISO 19139 based XML format.

Metadata record fulfilling all the Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for Spatial Data Services as defined in [*Regulation 1205/2008*], and the Article 14b "Interoperability arrangements and harmonisation requirements for invocable spatial data services" of amendment [Regulation 1312/2014] to [Regulation 1089/2010] adding its Annex V.

This Conformance Class includes TG Requirements C.1 – C.22, TG Requirements 3.1 – 3.8, and TG Requirements 5.1 – 5.5 of this specification.
====

The metadata elements contained within elements _gmd:identificationInfo_, _gmd:distributionInfo_ and _gmd:dataQualityInfo_ are described in sections 4.3.1 - 4.3.3 correspondingly.

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo/srv:SV_ServiceIdentification_ child element of the _gmd:MD_Metadata_ element.

===== Spatial Data Service type

[IMPORTANT]
====
*TG Requirement 5.1: metadata/2.0/req/sds-invocable/sds-type*

Spatial Data Service type shall be given encoded using element _srv:serviceType_/_gco:LocalName_ as specified in TG Requirement 3.5. The value for the element shall be "other" for all Invocable Spatial Data Services.
====

==== Distribution info section

===== Resource locator 

This Conformance Class extends the requirements in section 4.1.3.1 by requiring explicit declarations of the access points of the Spatial Data Service. The [Regulation 1312/2014], Annex I, Part D 1 describes these additional requirements:

{empty}
____
1. Resource Locator

The Resource Locator metadata element set out in Regulation (EC) No 1205/2008 shall also contain all access points from the spatial data service provider and these access points shall be unambiguously identified as such.
____

[IMPORTANT]
====
*TG Requirement 5.2: metadata/2.0/req/sds-invocable/access-point*

Each access point of the described Invocable Spatial Data Service shall be described in the metadata record using a _gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/ +
gmd:CI_OnlineResource_ element.

The _gmd:linkage/gmd:URL_ child element of _gmd:CI_OnlineResource_ shall contain the URL of the described access point containing a detailed description of a spatial data service, including a list of end points to allow its execution.

The _gmd:linkage/gmd:description_ child element _gmd:CI_OnlineResource_ shall contain a _gmx:Anchor_ element pointing to the value "accessPoint" of the code list OnLineDescriptionCode in the INSPIRE Registryfootnote:[Attribute xlink:href with value "http://inspire.ec.europa.eu/metadata-codelist/OnLineDescriptionCode/accessPoint"].

The multiplicity of the _gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/ +
gmd:CI_OnlineResource_ element used for the above purpose is 1..*.
====

[TIP]
====
*TG Recommendation 5.4: metadata/2.0/rec/sds-invocable/access-point-additional-info*

It is recommended that in addition to the mandatory _gmd:linkage_ and _gmd:description_ elements, also the _gmd:name_, the _gmd:function_/_gmd:CI_OnLineFunctionCode_ child elements of _gmd:CI_OnlineResource_ element are provided to give additional information about the provided URL link. The _gmd:name_ element should contain a Non-empty Free Text Element.

If provided, the _gmd:CI_OnLineFunctionCode_ element should point to value "information" of the ISO 19139 code list CI_OnLineFunctionCodefootnote:[Attribute codeList with value "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode" and the attribute codeListValue with "information".]_._
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions:**

<gmd:transferoptions>
  <gmd:md_digitaltransferoptions>
    <gmd:online>
      <gmd:ci_onlineresource>
        <gmd:linkage>
          <gmd:url>
            http://www.dinoservices.nl:80/geo3dmodelwebservices-1/Geo3DModelService?wsdl
          </gmd:url>
        </gmd:linkage>
        <gmd:description>
          <gmx:anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/OnLineDescriptionCode/accessPoint">
            accessPoint
          </gmx:anchor>
        </gmd:description>
        <gmd:function>
          <gmd:ci_onlinefunctioncode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode" codelistvalue="information">
            information
          </gmd:ci_onlinefunctioncode>
        </gmd:function>
      </gmd:ci_onlineresource>
    </gmd:online>
  </gmd:md_digitaltransferoptions>
</gmd:transferoptions>
----
*Example* *4.11*: Resource locator pointing the access point of the described Invocable Spatial Data Service.

==== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

===== Conformity to INSPIRE Implementation Rules

Invocable Spatial Data Services shall declare conformity to the [Regulation 1089/2010].

[IMPORTANT]
====
*TG Requirement 5.3: metadata/2.0/req/sds-invocable/conformity*

Metadata for an INSPIRE Invocable Spatial Data Services shall declare the conformity to the Implementing Rules for interoperability of spatial data sets and services, and it shall be encoded using _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/ +
gmd:DQ_ConformanceResult_ element as specified in **TG Requirement C.20TG Requirement C.20**TG Requirement C.20footnote:[TG Requirement C.20: degree of conformity using _gmd:DQ_ConformanceResult._]. This element shall contain citation of the [Regulation 1089/2010] encoded according to TG Requirement C.21footnote:[TG Requirement C.21: _gmd:DQ_ConformanceResult_ shall include a citation of the specification document, ...]. The degree of conformity shall be encoded as according to TG Requirement C.22footnote:[TG Requirement C.22: … _gmd:DQ_ConformanceResult …_ shall also include the degree of declared conformity…].

The multiplicity of the _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/ +
gmd:DQ_ConformanceResult_ element used for the above purpose is 1.
====

[TIP]
====
*TG Recommendation 5.5: metadata/2.0/rec/sds-invocable/uri-for-regulation-1089-2010*

If providing the specification title as an _gmx:Anchor_ element (as recommended in TG Recommendation C.11), the following URI should be used to refer to [Regulation 1089/2010]: http://data.europa.eu/eli/reg/2010/1089.
====

NOTE A pre-defined XML fragment containing the corresponding _CI_Citation_ element for [Regulation 1089/2010] will be provided at http://inspire.ec.europa.eu/id/citation/ir/reg-1089-2010.

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification xlink:href="http://inspire.ec.europa.eu/id/citation/ir/reg-1089-2010">
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href="http://data.europa.eu/eli/reg/2010/1089">
            COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2010-12-08
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This Spatial Data Service set is conformant with the INSPIRE Implementing Rules for the interoperability of spatial data sets and services
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *4.12:* Conformity declaration against the [Regulation 1089/2010].

Metadata for Invocable Spatial Data Services can also include additional declarations of conformity, in particular to the abstract test suites and conformance classes defined for the INSPIRE technical guidance documents.

[TIP]
====
*TG Recommendation 5.6: metadata/2.0/rec/datasets-and-series/uris-for-ats-and-cc*

If declaring conformity to an abstract test suite or a conformance class using an _gmx:Anchor_ element (as recommended in TG Recommendation C.11), the URI identifying the abstract test suite or a conformance class should be used in the _xlink:href_ attribute of the specification title element.
====

NOTE It is not currently planned to provide pre-defined XML fragments containing the _CI_Citation_ elements for the INSPIRE TG documents in the http://inspire.ec.europa.eu/id/citation/ namespace. However, such fragments can be added if this is deemed useful by INSPIRE data providers.

===== Category of the Spatial Data Service

To discover the harmonisation level of the described Invocable Spatial Data Service, the users must able to find out if the service fulfils the additional requirements specified for an Interoperable or a Harmonised Spatial Data Service. The Category element for providing information is described in [Regulation 1312/2014], Annex I, Part B 1:

{empty}
____
1. Category

This is a citation of the status of the spatial data service versus invocability. The value domain of this metadata element is as follows:

1.1. Invocable (invocable)

The spatial data service is an invocable spatial data service.

1.2. Interoperable (interoperable)

The invocable spatial data service is an interoperable spatial data service.

1.3. Harmonised (harmonised)

The interoperable spatial data service is a harmonised spatial data service.
____

In Table 1 of [Regulation 1312/2014], Annex I, Part C, the element is defined as mandatory for an invocable spatial data services.

The Category element is mapped in to [ISO 19139] using the _gmd:DQ_DomainConsistency_ and _gmd:DQ_ConformanceResult_ elements citing the Conformance Classes for the Invocable Spatial Data Service categories mentioned above.

[IMPORTANT]
====
*TG Requirement 5.4: metadata/2.0/req/sds-invocable/sds-category*

The category of the Invocable Spatial Data Service shall be given. It shall be encoded using the _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult_ element as specified in TG Requirement C.20footnote:[TG Requirement C.20: degree of conformity using _gmd:DQ_ConformanceResult._]. This element shall contain a citation for one of the three Conformance Classes for Invocable Spatial Data Service categories, and it shall be encoded according to TG Requirement C.21footnote:[TG Requirement C.21: _gmd:DQ_ConformanceResult_ shall include a citation of the specification document, ...].

The title of the cited Conformance Class shall be encoded using the _gmd:DQ_ConformanceResult/gmd:specification/gmd:CI_Citation/gmd:title/gmx:Anchor_ element. The attribute _xlink:href_ of this element shall contain the permanent unique identifier of the Conformance Class, and the textual content of the _gmx:Anchor_ element shall contain the corresponding language-neutral name of the category. The language-neutral names and the permanent unique identifiers are given in Table 5.1.

The degree of conformity as specified by TG Requirement C.22footnote:[TG Requirement C.22: … _gmd:DQ_ConformanceResult …_ shall also include the degree of declared conformity…] shall indicate that the service is fully conformant with the cited Conformance Classfootnote:[Element gmd:DQ_ConformanceResult/gmd:pass/gco:Boolean shall have value "true".].

The multiplicity of the _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult_ element used for the above purpose is 1.
====


*Table* *4.1:* The language-neutral names and the URIs of the Invocable Spatial Data Service categories.

[width="100%",cols="16%,84%",]
|===
|*Language-neutral name* |*Permanent unique identifier of the Requirements Class*
|invocable |http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-invocable
|interoperable |http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-interoperable
|harmonised |http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-harmonised
|===

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification>
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href=" http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-invocable" xlink:title="INSPIRE Invocable Spatial Data Services metadata">
            invocable
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2016-05-01
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This Spatial Data Service set is conformant with the INSPIRE requirements for Invocable Spatial Data Services
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *4.13:* Conformity declaration against the Requirements Class "INSPIRE Invocable Spatial Data Services metadata".

===== Conformity to technical specifications

The requirement of declaring conformity not only to the INSPIRE Implementation Rules, but also to technical specifications, including the INSPIRE Technical Guidelines, is made more explicit for the Invocable Spatial Data Services in [Regulation 1312/2014], Annex I, Part D 2:

{empty}
____
2. Specification

The Specification metadata element set out in Regulation (EC) No 1205/2008 shall also refer to or contain technical specifications (such as INSPIRE technical guidance but not only), to which the invocable spatial data service fully conforms, providing all the necessary technical elements (human, and wherever relevant, machine readable) to allow its invocation.
____

The mentioned Specification element together with the Degree element form the Conformity element as defined in [Regulation 1205/2008], Part B 7. The [ISO 19139] mapping for this element is defined in section 2.5.1 of this specification.

The specification metadata element described above and the access point given as the resource locator element (see section 4.3.2.1) together shall to provide sufficient information to actually invoke the service and enable its usage. If the specification metadata element does not refer to or contain at least one technical specification to which the Invocable Spatial Data Service fully conforms, providing all the necessary technical elements, the service is not considered an INSPIRE Invocable Spatial Data Service.

[IMPORTANT]
====
*TG Requirement 5.5: metadata/2.0/req/sds-invocable/conformity-to-technical-specifications*

An Invocable Spatial Data Service shall declare full compliance with at least one technical specification providing all the necessary technical elements to actually invoke the service and enable its usage. This declaration shall be encoded using _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/ +
gmd:DQ_ConformanceResult_ element as specified in TG Requirement C.20footnote:[TG Requirement C.20: degree of conformity using _gmd:DQ_ConformanceResult._]. This element shall contain a citation for the technical specification encoded according to TG Requirement C.21footnote:[TG Requirement C.21: _gmd:DQ_ConformanceResult_ shall include a citation of the specification document, ...].

The degree of conformity as specified by TG Requirement C.22footnote:[TG Requirement C.22: … _gmd:DQ_ConformanceResult …_ shall also include the degree of declared conformity…] shall indicate that the service is fully conformant with the given specificationfootnote:[Element gmd:DQ_ConformanceResult/gmd:pass/gco:Boolean shall have value "true".].

The multiplicity of the _gmd:report_/_gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult_ element used for the above purpose is 1..*.
====

[TIP]
====
*TG Recommendation 5.7: metadata/2.0/rec/sds-invocable/specification-title-anchor*

In order to be machine readable, the specification title element should be provided using the _gmx:Anchor_ element referring to an official publication URL address of the particular specification. The text content of this element should contain the official title of the referred technical specification.
====

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result:**

<gmd:result>
  <gmd:dq_conformanceresult>
    <gmd:specification>
      <gmd:ci_citation>
        <gmd:title>
          <gmx:anchor xlink:href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32546">
            EN ISO 19128:2005(E): Geographic information — Web map server interface
          </gmx:anchor>
        </gmd:title>
        <gmd:date>
          <gmd:ci_date>
            <gmd:date>
              <gco:date>
                2005-12-01
              </gco:date>
            </gmd:date>
            <gmd:datetype>
              <gmd:ci_datetypecode codelist="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#gmxCodelists.xml#CI_DateTypeCode" codelistvalue="publication">
                publication
              </gmd:ci_datetypecode>
            </gmd:datetype>
          </gmd:ci_date>
        </gmd:date>
      </gmd:ci_citation>
    </gmd:specification>
    <gmd:explanation>
      <gco:characterstring>
        This Spatial Data Service set is conformant with the ISO 19128:2005 specification
      </gco:characterstring>
    </gmd:explanation>
    <gmd:pass>
      <gco:boolean>
        true
      </gco:boolean>
    </gmd:pass>
  </gmd:dq_conformanceresult>
</gmd:result>
----
*Example* *4.14:* Conformity declaration against the Web Map Service specification (ISO 19128:2005).

=== Metadata for Interoperable Spatial Data Services

[NOTE]
====
*Conformance Class 6: metadata/2.0/sds-interoperable*

*Title:* INSPIRE Interoperable Spatial Data Services metadata.

**Conformance subject**: metadata record describing a Spatial Data Service encoded in ISO 19139 based XML format.

Metadata record fulfilling all the Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for Spatial Data Services as defined in [*Regulation 1205/2008*], and the Article 14b "Interoperability arrangements and harmonisation requirements for invocable spatial data services" of amendment [Regulation 1312/2014] to [Regulation 1089/2010] adding its Annex VI.

This Conformance Class includes TG Requirements C.1 – C.22, TG Requirements 3.1 – 3.8, TG Requirements 5.1 – 5.5, and TG Requirements 6.1 – 6.5 of this specification.
====

The metadata elements described in section 4.4.1 are direct child elements of _gmd:MD_Metadata_ element. The metadata elements contained within elements _gmd:identificationInfo_ and _gmd:dataQualityInfo_ are described in sections 4.4.2 – 4.4.3 correspondingly.

==== Direct properties of MD_Metadata element

===== Coordinate Reference System Identifier

It is mandatory for Interoperable Spatial Data Services indicate the coordinate reference system identifiers supported by the service. The element for describing this information is given in

[Regulation1312/2014], Annex II, Part B 3:

{empty}
____
3. Coordinate Reference System Identifier

Where appropriate, this is the list of coordinate reference systems supported by the spatial data service.

Each supported coordinate reference system shall be expressed using an identifier.
____

[IMPORTANT]
====
*TG Requirement 6.1: metadata/2.0/req/sds-interoperable/crs*

The coordinate reference system(s) supported by the described Spatial Data Service shall be given using element _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/ +
gmd:referenceSystemIdentifier/gmd:RS_Identifier_.The multiplicity of this element is 1..*.The _gmd:code_ child element of _gmd:RS_Identifier_ is mandatory. The _gmd:codeSpace_ child element shall be used if the code alone does not uniquely identify the referred coordinate reference system. Both _gmd:code_ and _gmd:codeSpace_ element (if given) shall contain Non-empty Free Text Elements.

Only the coordinate reference system identifiers specified in a well-known common register shall be used.
====

[IMPORTANT]
====
*TG Requirement 6.2: metadata/2.0/req/sds-interoperable/crs-http-uris*

If the coordinate reference system is listed in the table Default Coordinate Reference System Identifiers in Annex D.4, the value of the HTTP URI Identifier column shall be used as the value of _gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/ +
gmd:referenceSystemIdentifier/gmd:RS_Identifier/gmd:code_ element.

The _gmd:codeSpace_ element shall not be used in this case.
====

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo/srv:SV_ServiceIdentification_ child element of the _gmd:MD_Metadata_ element.

===== Conditions applying to access and use – technical restrictions

In addition to the generic, often policy and licensing based restrictions discussed in section 2.4.7, also possible technical restrictions applying to the access and use of the Spatial Data Services shall be declared in the metadata for Interoperable Spatial Data Services, as described in [Regulation1312/2014], Annex II, Part A 1:

{empty}
____
1. Conditions applying to access and use

The technical restrictions applying to the access and use of the spatial data service shall be documented in the metadata element “CONSTRAINT RELATED TO ACCESS AND USE” set out in Regulation (EC) No 1205/2008.
____

[IMPORTANT]
====
*TG Requirement 6.3: metadata/2.0/req/sds-interoperable/conditions-applying-to-access-and-use*

The technical restrictions applying to access and use of an Interoperable Spatial Data Service shall be given in the metadata. This information shall be encoded as described in the TG Requirement C.18.

The multiplicity of the _gmd:resourceConstraints/gmd:MD_LegalConstraints_ element used for the above purpose is 1..*.This information may be combined within the same _gmd:resourceConstraints_ element used for describing the non-technical conditions applying to access and use of the Spatial Data Service.
====

===== Responsible party – custodian

In addition to the information about the organisation responsible for the establishment, management, maintenance and distribution described in section 2.4.3, the metadata for Interoperable Spatial Data Service shall contain the information about the responsible party for the service in the role of the custodian. A custodian accepts accountability and responsibility for the resource and ensures appropriate care and maintenance of the resource. This additional requirement is described in [Regulation1312/2014], Annex II, Part A 2:

{empty}
____
2. Responsible party

The responsible party set out in Regulation (EC) No 1205/2008 shall at least describe the custodian responsible organisation, corresponding to the Custodian responsible party role set out in Regulation (EC) No 1205/2008.
____

[IMPORTANT]
====
*TG Requirement 6.4: metadata/2.0/req/sds-interoperable/responsible-party*

The responsible party for the Interoperable Spatial Data Service in the role of the custodian shall be given. This element shall be encoded as described in TG Requirement C.10.

The value of _gmd:pointOfContact_/_gmd:CI_ResponsibleParty_/_gmd:role_/ +
_gmd:CI_RoleCode_ shall point to the value "custodian" of ISO 19139 code list CI_RoleCodefootnote:[Attribute codeList shall be "http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_RoleCode" and the attribute codeListValue shall be "custodian".]The multiplicity of the _gmd:pointOfContact/gmd:CI_ResponsibleParty_ element used for the above purpose is 1..*.
====

In the TG Requirement C.9 the freedom of selecting the best fitting code for the responsible party role is left to the metadata provider. In cases when the responsible organisation responsible for the establishment, management, maintenance and distribution of the Spatial Data Service, is also responsible for the service in the role of the custodian, it may be sufficient to use the same responsible party element with only the role code custodian to represent the responsible party for both roles. Note that if it is desirable to express all of the distinct roles, a separate _gmd:pointOfContact/gmd:CI_ResponsibleParty_ element must be used for each role as only one _gmd:role_ child element is allowed for _gmd:CI_ResponsibleParty by the [ISO 19139] XML Schema_.

==== Data quality info section

The metadata elements described in this section are contained within the _gmd:dataQualityInfo/gmd:DQ_DataQuality_ child element of _gmd:MD_Metadata_ element.

===== Minimum estimated Quality of Service

The minimum Quality of Service criteria values for the Interoperable Spatial Data Service shall be given in the metadata. These criteria are described in [Regulation1312/2014], Annex II, Part B 4:


____
4.1. Criteria

These are the criteria to which the measurements refer. The value domain of this metadata element is as follows:

4.1.1. Availability (availability)It describes the percentage of time the service is available.

4.1.2. Performance (performance)

It describes how fast a request to the spatial data service can be completed.

4.1.3. Capacity (capacity)

It describes the maximum number of simultaneous requests that can be completed with the declared performance.

4.2. Measurement

4.2.1. Description

It describes the measurement for each criterion.

The value domain of this metadata element is free text.

4.2.2. Value (value)

It describes the value of the measurement for each criterion.

The value domain of this metadata element is free text.

4.2.3. Unit (unit)

It describes the Unit of the measurement for each criterion.

The value domain of this metadata element is free text.
____

In Table 1 of [Regulation 1312/2014], Annex II, Part C, the multiplicity for the quality of service elements is defined as 3..*.

[IMPORTANT]
====
*TG Requirement 6.5: metadata/2.0/req/sds-interoperable/quality-of-service*

The minimum values for each of the Quality of Service criteria given in Table 6.1 shall be given in the metadata. They shall be encoded using one _gmd:report/gmd:DQ_ConceptualConsistency_ element within the _gmd:DQ_DataQuality_ element scoped for the entire service.

The value of _gmd:DQ_ConceptualConsistency/gmd:nameOfMeasure_ shall be shall be an _gmx:Anchor_ element referring to the code list value for the criterion in the INSPIRE Registryfootnote:[Attribute xlink:href with URL value starting with "http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/" and postfixed with one of values of code list QualityOfServiceCriteriaCode, see Annex D.4] and expressing the name of the criterion in the language of the metadata.

The description of the measurement of the criterion shall be encoded using the _gmd:DQ_ConceptualConsistency/gmd:measureDescription_ element.

The value of the measurement of the criterion shall be encoded using the _gmd:DQ_ConceptualConsistency/gmd:result/gmd:DQ_QuantitativeResult_ element.

The _gmd:valueUnit_ child element shall describe the unit of measure of the criteria as given in Table 6.1. The numerical value of the criteria shall be encoded using the _gmd:value/gco:Record_ element. The value type of shall be declared using the _xsi:type_ attribute of the _gco:Record_ element as given in the Table 6.1.
====

The purpose of these quality of service metadata elements is to describe the minimum provided service level for the given Spatial Data Service over a long period of time. These values are not intended to be used for publishing the real-time or short-term results of measured quality of service criteria for the service. They should however reflect the true Quality of Service of the particular service evaluated in realistic test scenarios rather than the expected goals to reach for these criteria.

*Table* *4.2:* The Quality of Service criteria for Interoperable Spatial Data Services.

[width="100%",cols="24%,26%,50%",options="header",]
|===
|Minimum availability |Definition |Lower limit of the percentage of time the service is estimated to be available on a yearly basis.
| |Identifier URI |http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/availability
| |Value type |xsi:double between 0..100
| |Unit of measure |urn:ogc:def:uom:OGC::percent
|Minimum performance |Definition |The maximum response time within which a typical request to the Spatial Data Service can be carried out in a normal situation, by returning at least the initial part of the response. The normal situation represents periods out of peak load. It is set at 90% of the time.
| |Identifier URI |http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/performance
| |Value type |xsi:double
| |Unit of measure |http://www.opengis.net/def/uom/SI/second
|Minimum capacity |Definition |Lower limit of the maximum number of simultaneous requests that can be completed within the limits of the declared performance.
| |Identifier URI |http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/capacity
| |Value type |xsi:integer
| |Unit of measure |http://www.opengis.net/def/uom/OGC/1.0/unity
|===

[source,xml,subs="+quotes"]
----
**/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report:**

<gmd:report>
  <gmd:dq_conceptualconsistency>
    <gmd:nameofmeasure>
      <gmx:anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/performance">
        performance
      </gmx:anchor>
    </gmd:nameofmeasure>
    <gmd:measuredescription>
      <gco:characterstring>
        The maximum time in which a typical request to the Spatial Data Service can be carried out in a off-peak load situation
      </gco:characterstring>
    </gmd:measuredescription>
    <gmd:result>
      <gmd:dq_quantitativeresult>
        <gmd:valueunit xlink:href="http://www.opengis.net/def/uom/SI/second">
        </gmd:valueunit>
        <gmd:value>
          <gco:record xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:double">
            1.56
          </gco:record>
        </gmd:value>
      </gmd:dq_quantitativeresult>
    </gmd:result>
  </gmd:dq_conceptualconsistency>
</gmd:report>
----
*Example* *4.15:* Declared Quality of Service for the criteria minimum performance. Similar gmd:report elements shall be given also for the other criteria minimum availability and minimum capacity. The type of the gco:Record element has been defined as a double precision floating point number using the local typing (xsi:type attribute).

=== Metadata for Harmonised Spatial Data Services

[NOTE]
====
*Conformance Class 7: metadata/2.0/sds-harmonised*

*Title:* INSPIRE Harmonised Spatial Data Services metadata.

**Conformance subject**: metadata record describing a Spatial Data Service encoded in ISO 19139 based XML format.

Metadata record fulfilling all the Requirements of this Conformance Class is compliant with the INSPIRE metadata Implementation Rules for Spatial Data Services as defined in [*Regulation 1205/2008*], and the Article 14b "Interoperability arrangements and harmonisation requirements for invocable spatial data services" of amendment [Regulation 1312/2014] to [Regulation 1089/2010] adding its Annex VII.

This Conformance Class includes TG Requirements C.1 – C.22, TG Requirements 3.1 – 3.8, TG Requirements 5.1 – 5.5, TG Requirements 6.1 – 6.5, and TG Requirements 7.1 – 7.3 of this specification.
====

The metadata elements described in the section 4.5.1 are direct child elements of _gmd:MD_Metadata_ element.

==== Identification info section

The metadata elements described in this section are contained within the first _gmd:identificationInfo/srv:SV_ServiceIdentification_ child element of the _gmd:MD_Metadata_ element.

===== Invocation metadata

A harmonised spatial data service shall have well documented interfaces and list the end points for each operation to enable machine to machine communication. This invocation metadata element is described in [Regulation1312/2014], Annex III, Part B 3:

{empty}
____
3. Invocation metadataThe invocation metadata element documents the interfaces of the harmonised spatial data service and lists the end points to enable machine-to machine communication.
____

[IMPORTANT]
====
*TG Requirement 7.1: metadata/2.0/req/sds-harmonised/invocation-metadata*

The invocation metadata shall be given for Harmonised Spatial Data Services. This information shall be encoded using one of the following two options:*Option 1*: All operations and the list of end points for them along with the information about the required and optional parameters for each operation shall be provided within the metadata record using the _srv:containsOperations/srv:SV_OperationMetadata/srv:connectPoint_ element. This element shall be the same as the element describing the access point (see TG Requirement 5.2). In this option the information provided by calling the access point together with the information about the conformity with the technical specifications described according to TG Requirement 5.5 shall fulfil the invocation metadata requirements.*Option 2*: All operations and the list of end points for them along with the information about the required and optional parameters for each operation shall be provided within the metadata record using one _srv:containsOperations/srv:SV_OperationMetadata_ element for each provided operation. The contents of these element shall be given according to [ISO 19119, Section C.2].

When the metadata record contains at least one _srv:containsOperations/srv:SV_OperationMetadata_ element, it is assumed that the option 2 has been chosen, otherwise it is assumed that the option 1 has been chosen.
====

[IMPORTANT]
====
*TG Requirement 7.2: metadata/2.0/req/sds-harmonised/operation-metadata*

If the metadata contains at least one the _srv:containsOperations/srv:SV_OperationMetadata_ element the invocation metadata within shall be encoded using at least the following child elements__:srv:operationName__ element shall contain a unique identifier for interface described by the _srv:SV_OperationMetadata_ element. The value of this element is a Non-empty Free Text Element. The multiplicity of this element is 1._srv:DCP/srv:DCPList_ shall contain a reference to the Distributed Computing Platform on which the operation has been implemented. The multiplicity of this element is 1..*._srv:parameters/srv:SV_Parameter_ shall contain a description of a single request parameter to be used in invoking the operation. The content for this element shall be encoded as described in TG Requirement 7.3. The multiplicity of this element is 0..*, and it is mandatory for all required and optional parameters provided by the operation._srv:connectPoint/gmd:CI_OnlineResource/gmd:URL_ shall contain an end point URL to be used for accessing the service for executing the operation. The multiplicity of the element is 1..*.
====

[IMPORTANT]
====
*TG Requirement 7.3: metadata/2.0/req/sds-harmonised/operation-metadata-parameters*

For all the required and optional request parameters of all the operations described using _srv:containsOperations/srv:SV_OperationMetadata_ elements, the following child elements of s__rv:parameters/srv:SV_Parameter__ element shall be given__:srv:name/gco:aName__ shall contain the name of the parameter as used by the service. The content of this element is a Non-empty Free Text Element. The element _srv:name/gco:attributeType_ shall contain the record or the type part of the attribute name. The multiplicity of the _srv:name_ element is 1._srv:optionality_ shall contain information about whether the attribute is required or optional. The content of this element is a Non-empty Free Text Element. The multiplicity of this element is 1.srv:repeatability/gco:Boolean shall contain indicate whether the attribute can be given more than once in one operation. The value "true" shall be used indicate that the attribute may be repeated, "false" that only it may be given only once._srv:valueType/gco:TypeName/gco:Name_ shall indicate the data type of the attribute.
====

== Annex A Abstract Test Suites

This Annex only contains the structure of the Abstract Test Suites and the contained Conformance Classes for testing the metadata records against the requirements of this specification. The Test Cases for the Conformance Classes are provided in a separate repositoryfootnote:[At the time of writing, the test cases for these Conformance Classes were not yet published. The repository for the Conformance Classes will be made available at http://inspire.ec.europa.eu/id/ats/metadata/2.0.].

=== ATS: Metadata for INSPIRE datasets and data set series

==== Conformance Class 1: Baseline metadata for data sets and data set series

This section contains test cases covering all the TG Requirements of Conformance Class 1: INSPIRE data sets and data set series baseline metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/datasets-and-series).

==== Conformance Class 2: Interoperability metadata for data sets and data set series

This section contains test cases covering all the TG Requirements of Conformance Class 2: INSPIRE data sets and data set series interoperability metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/isdss).

=== ATS: Metadata for INSPIRE Spatial Data Services

==== Conformance Class 3: Baseline metadata for Spatial Data Services

This section contains test cases covering all the TG Requirements of Conformance Class 3: INSPIRE Spatial Data Service baseline metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds).

==== Conformance Class 4: Metadata for INSPIRE Network Services

This section contains test cases covering all the TG Requirements of Conformance Class 4: INSPIRE Network Services metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/ns).

==== Conformance Class 5: Metadata for Invocable Spatial Data Services

This section contains test cases covering all the TG Requirements of Conformance Class 5: INSPIRE Invocable Spatial Data Services metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-invocable).

==== Conformance Class 6: Metadata for Interoperable Spatial Data Services

This section contains test cases covering all the TG Requirements of Conformance Class 6: INSPIRE Interoperable Spatial Data Services metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-interoperable).

==== Conformance Class 7: Metadata for Harmonised Spatial Data Services

This section contains test cases covering all the TG Requirements of Conformance Class 7: INSPIRE Harmonised Spatial Data Services metadata (http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-harmonised).

== Annex B Mapping of ISO 19115:2003 Core elements and INSPIRE Implementing Rules for metadata (informative)

=== Spatial dataset and spatial dataset series

The table below compares the core elements of ISO 19115 (see Table 3 in 6.5 of EN ISO 19115:2003) to the requirements of INSPIRE for spatial dataset and spatial dataset series as defined in the Implementing Rules for metadata.

[width="100%",cols="26%,26%,48%",options="header",]
|===
|ISO 19115 Core |INSPIRE Implementing Rules for Metadata |Comments
|Dataset title (M) |Part B 1.1 Resource Title |-
|Dataset reference date (M) |Part B 5 Temporal Reference |ISO 19115 is more demanding. The metadata shall contain a date of publication, revision or creation of the resource, while in INSPIRE the Temporal Reference can also be expressed through Temporal Extent.
|Dataset responsible party (O) |Part B 9 Responsible organisation |INSPIRE is more demanding by mandating both the name of the organisation, and a contact e-mail address
|Geographic location of the dataset (C) |Part B 4.1 Geographic Bounding Box |INSPIRE is more restrictive. A Geographic bounding box is mandated
|Dataset language (M) |Part B 1.7 Resource Language |ISO 19115 is more demanding. It mandates the dataset language, even if the resource does not include any textual information. The ISO 19115 Dataset language is defaulted to the Metadata language.
|Dataset character set (C) |- a|
ISO 19115 is more demanding. The dataset character set has to be documented in ISO 19115 when ISO 10646-1 is not used.

The ISO 19115 element maps to the conditional “Character Encoding” metadata element defined in Art. 13(5) of the Implementing Rules on interoperability of spatial data sets and services. This element is mandatory only if an encoding is used that is not based on UTF-8 (the dominant encoding of ISO 10646-1).

|Dataset topic category (M) |Part B 2.1 Topic Category |-
|Spatial resolution of the dataset (O) |Part B 6.2 Spatial Resolution |-
|Abstract describing the dataset (M) |Part B 1.2 Resource abstract |-
|Distribution format (O) |- |The ISO 19115 element maps to the mandatory “Encoding” metadata element defined in Art. 13(3) of the Implementing Rules on interoperability of spatial data sets and services.
|Additional extent information for the dataset (vertical and temporal) (O) |Part B 5.1 Temporal extent |INSPIRE is more demanding. A temporal reference is mandated, and can be expressed as a temporal extent.
|Spatial representation type (O) |- |The ISO 19115 element maps to the mandatory “Spatial Representation Type” metadata element defined in Art. 13(6) of the Implementing Rules on interoperability of spatial data sets and services.
|Reference system (O) |- |The ISO 19115 element maps to the mandatory “Coordinate Reference System” and the conditional “Temporal Reference System” metadata elements defined in Art. 13(1) and (2) of the Implementing Rules on interoperability of spatial data sets and services set.
|Lineage (O) |Part B 6.1 Lineage |INSPIRE is more demanding. A general lineage statement is mandated.
|On-line resource (O) |Part B 1.4 Resource Locator |-
|Metadata file identifier (O) |- |-
|Metadata standard name (O) |- |-
|Metadata standard version (O) |- |-
|Metadata language (C) |Part B 10.3 Metadata Language |INSPIRE is more demanding. The metadata language is mandated even if it is defined by the encoding.
|Metadata character set (C) |- |ISO 19115 is more demanding. The metadata character set has to be documented in ISO 19115 when ISO 10646-1 is not used.
|Metadata point of contact (M) |Part B 10.1 Metadata point of contact |INSPIRE is more demanding by mandating both the name of the organisation, and a contact e-mail address.
|Metadata date stamp (M) |Part B 10.2 Metadata Date |ISO is more restrictive because this element shall contain the “date that the metadata was created” and INSPIRE may contain the “date when the metadata record was created or updated
|- |Part B 1.3 Resource Type |INSPIRE is more demanding
| |Part B 1.5 Unique Resource Identifier |INSPIRE is more demanding
| |Part B 3 Keyword |INSPIRE is more demanding
|- |Part B 7 Conformity |INSPIRE is more demanding
|- |Part B 8.1 Conditions for access and use |INSPIRE is more demanding
|- |Part B 8.2 Limitations on public access |INSPIRE is more demanding
|===

=== Services

The table below compares the core requirements of ISO 19115 (see Table 3 in 6.5 of ISO 19115:2003) to the requirements of INSPIRE for services as defined in the Implementing Rules for metadata. The greyed lines correspond to core metadata elements not applicable to services.

[width="100%",cols="26%,26%,48%",options="header",]
|===
|ISO 19115 Core |INSPIRE |Comments
|Dataset title (M) |Part B 1.1 Resource Title |-
|Dataset reference date (M) |Part B 5 Temporal Reference |ISO 19115 is more demanding. Despite its name, this ISO 19115 Core metadata element applies to services. A reference date of the service (date of publication, revision or creation …) is mandated.
|Dataset responsible party (O) |Part B 9 Responsible organisation |-
|Geographic location of the dataset (C) |- |See INSPIRE Geographic Bounding Box
|- |Part B 4.1 Geographic Bounding Box |The Geographic Bounding Box is handled in ISO 19119 with a different metadata element from the one corresponding to “Geographic location of the dataset”
|Dataset language (M) |- |Not applicable to services
|Dataset character set (C) |- |Not applicable to services
|Dataset topic category (M) |- |Not applicable to services
|Spatial resolution of the dataset (O) |Part B 6.2 Spatial Resolution |In the current version of ISO 19119, it is not possible to express the restriction of a service concerning the spatial resolution
|Abstract describing the dataset (M) |Part B 1.2 Resource abstract |-
|Distribution format (O) |- |-
|Additional extent information for the dataset (O) |- |-
|Spatial representation type (O) |- |-
|Reference system (O) |- |-
|Lineage (O) |- |-
|On-line resource (O) |Part B 1.4 Resource Locator |-
|Metadata file identifier (O) |- |-
|Metadata standard name (O) |- |-
|Metadata standard version (O) |- |-
|Metadata language (C) |Part B 10.3 Metadata Language |INSPIRE is more demanding. The metadata language is mandated.
|Metadata character set (C) |- |ISO 19115 is more demanding. The metadata character set has to be documented in ISO 19115 when ISO 10646-1 is not used.
|Metadata point of contact (M) |Part B 10.1 Metadata point of contact |-
|Metadata date stamp (M) |Part B 10.2 Metadata Date |ISO is more restrictive because this element shall contain the “date that the metadata was created” and INSPIRE may contain the “date when the metadata record was created or updated
|- |Part B 1.3 Resource Type |INSPIRE is more demanding
|- |Part B 1.6 Coupled Resource |Optional in INSPIRE
|- |Part B 2.2 Spatial Data Service Type |INSPIRE is more demanding
| |Part B 3 Keyword |INSPIRE is more demanding
|- |Part B 7 Conformity |INSPIRE is more demanding
|- |Part B 8.1 Conditions for access and use |INSPIRE is more demanding
|- |Part B 8.2 Limitations on public access |INSPIRE is more demanding
|===

=== Conclusion

* The conformance of an ISO 19115 metadata set to the ISO 19115 Core does not guarantee the conformance to INSPIRE;
* The use of these guidelines to create INSPIRE metadata ensures that the metadata is not in conflict with ISO 19115. However, full conformance to ISO 19115 implies the provision of additional metadata elements which are not required by the INSPIRE Implementing Rule on Metadata.

== Annex C INSPIRE metadata element catalog (informative)

The following tables describe the mapping between the metadata elements of INSPIRE, as defined in the [Regulation 1205/2008] and [Regulation 1089/2010] (including its amendments [Regulation 1253/2013] and [Regulation 1312/2014]) and ISO 19115/ISO 19119. For each of the INSPIRE Metadata element, the mapping is composed of the main characteristics of the metadata element as they are defined in the INSPIRE implementing rules (IR) for metadata and the main characteristics of the corresponding metadata element of ISO 19115 or ISO 19119:

* {blank}
+

The metadata element name as used in the INSPIRE implementing rules;

* {blank}
+

The reference to the paragraph of the INSPIRE implementing rules describing the metadata element;

* {blank}
+

The definition, which gives the current ISO 19115 or ISO 19119 terms for describing the metadata element (Annex B of ISO 19115 standard: Data Dictionary for geographic metadata or Annex C of ISO 19119: Data dictionary for geographic service metadata);

* {blank}
+

The number and the name that identifies the metadata element inside tables in ISO 19115 (or ISO 19119) published standard;

* {blank}
+

An XPath expression indicating the metadata element within the ISO 19115 / ISO 19119 UML model (see 2.1.1);

* {blank}
+

The INSPIRE obligation/condition applicable to the metadata element;

* {blank}
+

The INSPIRE multiplicity of the metadata element;

* {blank}
+

The Data Type and the Domain required by the metadata element;

* {blank}
+

An example that illustrates the description of the metadata element by providing a concrete case

* {blank}
+

Some comments, which give more information about the metadata element


Apart from the tables collecting the main significant aspects, additional information is provided regarding: the description of the metadata element, advices on its fulfilment and important requirements and recommendations.

The first section C.1 gives a list of all INSPIRE metadata elements for spatial data sets and data set series as well as for Spatial Data Services as described in the INSPIRE Implementing Rules [Regulation 1205/2008] and [Regulation 1089/2010] (including its amendments [Regulation 1253/2013] and [Regulation 1312/2014]). Details of each elements as well as its mapping to [ISO 19115] or [ISO 19119] and [ISO 19139] is given in sections C.2 - C.6.

Section C.7 contains a collection of theme-specific metadata elements described in the INSPIRE Data Specifications.

=== Overview of the required INSPIRE metadata elements

==== Spatial data sets and data sets series

[arabic]
. {blank}

[width="100%",cols="20%,13%,24%,15%,28%",options="header",]
|===
|Implementing rule |Section / article |Element name |INSPIRE multiplicity |INSPIRE obligation / condition / note
|[Regulation 1205/2008] |Part B 1.1 |Resource title |1 |Mandatory
|[Regulation 1205/2008] |Part B 1.2 |Resource abstract |1 |Mandatory
|[Regulation 1205/2008] |Part B 1.3 |Resource type |1 |Mandatory
|[Regulation 1205/2008] |Part B 1.4 |Resource locator |0..* |Mandatory if a URL is available to obtain more information on the resources and/or access related services.
|[Regulation 1205/2008] |Part B 1.5 |Unique resource identifier |1..* |Mandatory
|[Regulation 1205/2008] |Part B 1.7 |Resource language |0..* |Mandatory if the resource includes textual information.
|[Regulation 1205/2008] |Part B 2.1 |Topic category |1..* |Mandatory
|[Regulation 1205/2008] |Part B 3.1 |Keyword value |1..* |Mandatory
|[Regulation 1205/2008] |Part B 3.2 |Originating controlled vocabulary |0..1 |Conditional: Mandatory for each keyword if the keyword value originates from a controlled vocabulary
|[Regulation 1205/2008] |Part B 4.1 |Geographic bounding box |1..* |Mandatory
|[Regulation 1205/2008] |Part B 5 |Temporal reference | |At least one of Temporal extent, Date of publication, Date of last revision or Date of creation must be given
|[Regulation 1205/2008] |Part B 5.1 |Temporal extent |0..* |Conditional
|[Regulation 1205/2008] |Part B 5.2 |Date of publication |0..* |Conditional
|[Regulation 1205/2008] |Part B 5.3 |Date of last revision |0..1 |Conditional
|[Regulation 1205/2008] |Part B 5.4 |Date of creation |0..1 |Conditional
|[Regulation 1205/2008] |Part B 6.1 |Lineage |1 |Mandatory
|[Regulation 1205/2008] |Part B 6.2 |Spatial resolution |0..* |Mandatory if an equivalent scale or a resolution distance can be specified
|[Regulation 1205/2008] |Part B 7 |Conformity |1..* |Mandatory
|[Regulation 1205/2008] |Part B 7.1 |Specification |1 |Mandatory for each conformity statement
|[Regulation 1205/2008] |Part B 7.2 |Degree |1 |Mandatory for each conformity statement
|[Regulation 1205/2008] |Part B 8.1 |Conditions applying to access and use |1..* |Special values for unknown conditions or no applying conditions may be used
|[Regulation 1205/2008] |Part B 8.2 |Limitations on public access |1..* |Special value for no limitations may be used
|[Regulation 1205/2008] |Part B 9 |Responsible organisation |1..* |Mandatory
|[Regulation 1205/2008] |Part B 9.1 |Responsible party |1 |Mandatory for each responsible organisation
|[Regulation 1205/2008] |Part B 9.2 |Responsible party role |1 |Mandatory for each responsible organisation
|[Regulation 1205/2008] |Part B 10.1 |Metadata point of contact |1..* |Mandatory
|[Regulation 1205/2008] |Part B 10.2 |Metadata date |1 |Mandatory
|[Regulation 1205/2008] |Part B 10.3 |Metadata language |1 |Mandatory
|[Regulation 1089/2010] |Article 13, clause 1 |Coordinate Reference System |1..* |Mandatory to comply with [Regulation 1089/2010]
|[Regulation 1089/2010] |Article 13, clause 2 |Temporal Reference System |0..* |Mandatory for compliance with [Regulation 1089/2010] only if a non-default temporal reference system (i.e. Gregorian Calendar or the Coordinated Universal Time) is used
|[Regulation 1089/2010] |Article 13, clause 3 |Encoding |1..* |Mandatory to comply with [Regulation 1089/2010]
|[Regulation 1089/2010] |Article 13, clause 4 |Topological consistency |0..* |Mandatory for compliance with [Regulation 1089/2010] only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network
|[Regulation 1089/2010] |Article 13, clause 5 |Character Encoding |0..* |Mandatory for compliance with [Regulation 1089/2010] only if the data set is not using UTF-8 encoding
|[Regulation 1089/2010] amended by [Regulation 1253/2013] |Article 13, clause 6 |Spatial representation type |1..* |Mandatory to comply with [Regulation 1089/2010]
|===

==== Spatial Data Services

[width="100%",cols="20%,13%,24%,15%,28%",options="header",]
|===
|Implementing rule |Section / article |Element name |INSPIRE multiplicity |INSPIRE obligation / condition / note
|[Regulation 1205/2008] |Part B 1.1 |Resource title |1 |Mandatory
|[Regulation 1205/2008] |Part B 1.2 |Resource abstract |1 |Mandatory
|[Regulation 1205/2008] |Part B 1.3 |Resource type |1 |Mandatory
|[Regulation 1205/2008] |Part B 1.4 |Resource locator |0..* |Conditional, mandatory if linkage to service is available
|[Regulation 1205/2008] |Part B 1.6 |Coupled resource |0..* |Conditional, mandatory if linkage to data sets on which the service operates are available.
|[Regulation 1205/2008] |Part B 2.2 |Spatial data service type |1 |Mandatory
|[Regulation 1205/2008] |Part B 3.1 |Keyword value |1..* |Mandatory
|[Regulation 1205/2008] |Part B 3.2 |Originating controlled vocabulary |0..1 |Conditional, mandatory for each keyword if the keyword value originates from a controlled vocabulary
|[Regulation 1205/2008] |Part B 4.1 |Geographic bounding box |0..* |Conditional, mandatory for services with an explicit geographic extent.
|[Regulation 1205/2008] |Part B 5 |Temporal reference | |At least one of Temporal extent, Date of publication, Date of last revision or Date of creation must be given
|[Regulation 1205/2008] |Part B 5.1 |Temporal extent |0..* |Conditional
|[Regulation 1205/2008] |Part B 5.2 |Date of publication |0..* |Conditional
|[Regulation 1205/2008] |Part B 5.3 |Date of last revision |0..1 |Conditional
|[Regulation 1205/2008] |Part B 5.4 |Date of creation |0..1 |Conditional
|[Regulation 1205/2008] |Part B 6.2 |Spatial resolution |0..* |Mandatory when there is a restriction on the spatial resolution for this service
|[Regulation 1205/2008] |Part B 7 |Conformity |1..* |Mandatory
|[Regulation 1205/2008] |Part B 7.1 |Specification |1 |Mandatory for each conformity statement
|[Regulation 1205/2008] |Part B 7.2 |Degree |1 |Mandatory for each conformity statement
|[Regulation 1205/2008] |Part B 8.1 |Conditions applying to access and use |1..* |Special values for unknown conditions or no applying conditions may be used
|[Regulation 1205/2008] |Part B 8.2 |Limitations on public access |1..* |Special value for no limitations may be used
|[Regulation 1205/2008] |Part B 9 |Responsible organisation |1..* |Mandatory
|[Regulation 1205/2008] |Part B 9.1 |Responsible party |1 |Mandatory for each responsible organisation
|[Regulation 1205/2008] |Part B 9.2 |Responsible party role |1 |Mandatory for each responsible organisation
|[Regulation 1205/2008] |Part B 10.1 |Metadata point of contact |1..* |Mandatory
|[Regulation 1205/2008] |Part B 10.2 |Metadata date |1 |Mandatory
|[Regulation 1205/2008] |Part B 10.3 |Metadata language |1 |Mandatory
|[Regulation 1089/2010], Annex V, (Invocable SDS) |Part B 1 |Category |0..1 |Conditional, mandatory for an Invocable Spatial Data Service in order to comply with Annex V of [Regulation 1089/2010]
|[Regulation 1089/2010], Annex VI, (Interoperable SDS) |Part B 3 |Coordinate Reference System Identifier |1..* |Mandatory if relevant for an Interoperable Spatial Data Service in order to comply with Annex VI of [Regulation 1089/2010]
|[Regulation 1089/2010], Annex VI, (Interoperable SDS) |Part B 4 |Quality of service |3..* |Mandatory for an Interoperable Spatial Data Service. Three criteria for minimum quality of service shall be given to comply with Annex VI of [Regulation 1089/2010]: Availability, Performance and Capacity
|[Regulation 1089/2010], Annex VII, (Harmonised SDS) |Part B 3 |Invocation metadata |1..* |Mandatory for a Harmonised Spatial Data Service in order to comply with Annex VII of [Regulation 1089/2010]
|===

=== INSPIRE Implementing Rules for metadata (regulation 1205/2008)

==== Resource title

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Resource title
|Reference |Part B 1.1
|Definition |Name by which the cited resource is known
|ISO 19115 number and name |360. title
|ISO/TS 19139 path |identificationInfo[1]/*/citation/*/title
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |CharacterString
|Domain |Free text
|Example |SPI: Standardized Precipitation Index
|Comments |
|===

==== Resource abstract

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Resource abstract
|Reference |Part B 1.2
|Definition |Brief narrative summary of the content of the resource(s)
|ISO 19115 number and name |25. abstract
|ISO/TS 19139 path |identificationInfo[1]/*/abstract
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |CharacterString
|Domain |Free text
|Example |The Standardized Precipitation Index (SPI-n) is a statistical indicator comparing the total precipitation received at a particular location during a period of n months with the long-term rainfall distribution for the same period of time at that location. SPI is calculated on a monthly basis for a moving window of n months, where n indicates the rainfall accumulation period, which is typically 1, 3, 6, 9, 12, 24 or 48 months. The corresponding SPIs are denoted as SPI-1, SPI-3, SPI-6, etc. In order to allow for the statistical comparison of wetter and drier climates, SPI is based on a transformation of the accumulated precipitation into a standard normal variable with zero mean and variance equal to one. SPI results are given in units of standard deviation from the long-term mean of the standardized distribution. In 2010 WMO selected the SPI as a key meteorological drought indicator to be produced operationally by meteorological services
|Comments |
|===

==== Resource type

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Resource type
|Reference |Part B 1.3
|Definition |Scope to which metadata applies
|ISO 19115 number and name |6. hierarchyLevel
|ISO/TS 19139 path |hierarchyLevel
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |MD_ScopeCode
|Domain |CodeList (see annex B.5.25 of ISO 19115)
|Example |dataset
|Comments |
|===

==== Resource locator

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Resource locator
|Reference |Part B 1.4
|Definition |Location (address) for on-line access using a Uniform Resource Locator address or similar addressing scheme
|ISO 19115 number and name |397. linkage
|ISO/TS 19139 path |distributionInfo/*/transferOptions/*/onLine/*/linkage
|INSPIRE obligation / condition a|
* Conditional for spatial dataset and spatial dataset series: Mandatory if a URL is available to obtain more information on the resources and/or access related services.

|INSPIRE multiplicity |[0..*]
|Data type (and ISO 19115 no.) |URL
|Domain |URL (IETF RFC1738 and IETF RFC 2056)
|Example a|
http://edo.jrc.ec.europa.eu/chm/ows.php?VERSION=1.3.0&SERVICE=WMS&REQUEST=GetCapabilities

http://www.eea.europa.eu/data-and-maps/data/wise-river-basin-districts-rbds-1

|Comments a|
A Resource Locator could be described, moreover, by other additional elements as a Title, a Description and a Function. In that case, the Title and the Description shall be free text and the Function shall be filled by the CI_OnLineFunctionCode (ISO 19115 code list).

Examples of Resource Locator with these additional elements:

* JRC EDO (European Drought Observatory) - Drought Indexes WMS
** {blank}
+

Linkage: http://edo.jrc.ec.europa.eu/chm/ows.php?VERSION=1.3.0&SERVICE=WMS&REQUEST=GetCapabilities

** {blank}
+

Title: JRC EDO (European Drought Observatory) - Drought Indexes WMS

** {blank}
+

Description: WMS delivering maps of drought indexes provided by the European Drought Observatory (EDO).

** {blank}
+

Function: information

* WISE River basin districts (RBDs)
** {blank}
+

Linkage: http://www.eea.europa.eu/data-and-maps/data/wise-river-basin-districts-rbds-1

** {blank}
+

Title: WISE River basin districts (RBDs)

** {blank}
+

Description: Version 1.4 (06/2011) - River Basin Districts (RBDs) and/or their subunits (RBDSUs) are the main units for the management of river basins and have been delineated by Member States under Article 3 and updated by reporting to Article 13 of the Water Framework Directive.

** {blank}
+

Function: information


|===

==== Unique resource identifier

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Unique resource identifier
|Reference |Part B 1.5
|Definition |Value uniquely identifying an object within a namespace
|ISO 19115 number and name |365. identifier
|ISO/TS 19139 path |identificationInfo[1]/*/citation/*/identifier
|INSPIRE obligation / condition |Mandatory for dataset and dataset series
|INSPIRE multiplicity |[1..*] for dataset and series
|Data type (and ISO 19115 no.) |205. MD_Identifier
|Domain |URI (IETF RFC 3986)
|Example a|
The Unique resource identifier semantically consisting of

+++namespace+++: *https://example.org/*

and +++identifier+++: *ab749859*

and is provided together in element _code:_

https://example.org/ab749859

|Comments |The unique resource identifier is needed to provide a queryable information when following data-service-coupling (see also 4.1.2.4). Therefore it is necessary to have the identifier itself together with the namespace in element code. The use of RS_Identifier (with a separate element codeSpace) is not suitable here
|===

==== Coupled resource

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Coupled resource
|Reference |Part B 1.6
|Definition |Provides information about the datasets that the service operates on.
|ISO 19119 number and name |9 of table C.1. operatesOn
|ISO/TS 19139 path |identificationInfo[1]/*/operatesOn
|INSPIRE obligation / condition a|
* Not applicable to dataset and dataset series
* Conditional to services: Mandatory if linkage to datasets on which the service operates are available.

|INSPIRE multiplicity a|
[0] for datasets and series

[0..*] for services

|Data type (and ISO 19115 no.) |36. MD_DataIdentification
|Domain |A unique resource identifier or locator (URL) of the MD_DataIdentification object
|Example |http://vap-xgeodev.jrc.ec.europa.eu/geonetwork/srv/eng/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecordById&ID=f9ee6623-cf4c-11e1-9105-0017085a97ab&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&ELEMENTSETNAME=full#lakes[+++http://vap-xgeodev.jrc.ec.europa.eu/geonetwork/srv/eng/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecordById&ID=f9ee6623-cf4c-11e1-9105-0017085a97ab&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&ELEMENTSETNAME=full#lakes+++]
|Comments a|
The implementation of this element by reference means that the xlink:href element are pointing to a metadatarecord that contains a MD_DataIdentification object. The reference to the MD_DataIdentification object is done using the xpointer reference using the #-sign. The example above points to #lakes which is the ID of this object. Check example on xml encoding in section 0.

The Unique Resource Identifier for the can be explicilty defined for the target dataset using the optional uuidref.attribute.

|===

==== Resource language

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Resource language
|Reference |Part B 1.7
|Definition |Language(s) used within the datasets
|ISO 19115 number and name |39. language
|ISO/TS 19139 path |identificationInfo[1]/*/language
|INSPIRE obligation / condition a|
* Conditional for spatial dataset and spatial dataset series: Mandatory if the resource includes textual information.
* Not applicable to services

|INSPIRE multiplicity a|
[0..*] for datasets and series

[0] for services

|Data type (and ISO 19115 no.) |LanguageCode (ISO/TS 19139)
|Domain a|
Codelist (See ISO/TS 19139) based on alpha-3 codes of ISO 639-2. Use only three-letter codes from in ISO 639-2/B (bibliographic codes),

The list of codes for the 24 official EU languages is:

Bulgarian – bul Irish – gle

Croatian – hrv Italian – ita

Czech – cze Latvian – lav

Danish – dan Lithuanian – lit

Dutch – dut Maltese – mlt

English – eng Polish – pol

Estonian – est Portuguese – por

Finnish – fin Romanian – rum

French – fre Slovak – slo

German – ger Slovenian – slv

Greek – gre Spanish – spa

Hungarian – hun Swedish – swe

The list of all the codes is defined at http://www.loc.gov/standards/iso639-2/[+++http://www.loc.gov/standards/iso639-2/+++]

Regional languages also are included in this list.

|Example |eng
|Comments a|
[arabic]
. {blank}

|===

==== Topic category

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Topic category
|Reference |Part B 2.1
|Definition |Main theme(s) of the dataset
|ISO 19115 number and name |41. topicCategory
|ISO/TS 19139 path |identificationInfo[1]/*/topicCategory
|INSPIRE obligation / condition a|
* Mandatory for datasets and dataset series
* Not applicable to services

|INSPIRE multiplicity a|
[1..*] for datasets and dataset series

[0] for services

|Data type (and ISO 19115 no.) |MD_TopicCategory
|Domain |Enumeration (See B.5.27 of ISO 19115 or Part D 2 of [Regulation 1205/2008])
|Example |climatologyMeteorologyAtmosphere
|Comments |The topic categories defined in Part D 2 of [Regulation 1205/2008] are derived directly from the topic categories defined in MD_TopicCategoryCode (B.5.27 of ISO 19115)
|===

==== Spatial data service type

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Spatial data service type
|Reference |Part B 2.2
|Definition |A service type name from a registry of services
|ISO 19119 number and name |1 of table C.1. serviceType
|ISO/TS 19139 path |identificationInfo[1]/*/serviceType
|INSPIRE obligation / condition a|
* Not applicable to datasets and dataset series
* Mandatory for services

|INSPIRE multiplicity a|
[1] for services

[0] for datasets and dataset series

|Data type (and ISO 19115 no.) |GenericName
|Domain |Code list. See Part D 3 of [Regulation 1205/2008]
|Example |view
|Comments |
|===

==== Keyword value

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Keyword value
|Reference |Part B 3.1
|Definition |Commonly used word(s) or formalised word(s) or phrase(s) used to describe the subject
|ISO 19115 number and name |53. keyword
|ISO/TS 19139 path |identificationInfo[1]/*/descriptiveKeywords/*/keyword
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1..*]
|Data type (and ISO 19115 no.) |CharacterString
|Domain |Free text
|Example a|
Atmospheric conditions (INSPIRE Spatial Data Theme)

humanCatalogueViewer (spatial data service subcategory)

water springs (AGROVOC)

rain water (GEMET Concepts)

|Comments |Each instance of ISO 19115 keyword may originate from a controlled vocabulary described through the thesaurusName property of the instance of descriptiveKeywords to which the keyword pertains
|===

==== Originating controlled vocabulary

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Originating controlled vocabulary
|Reference |Part B 3.2
|Definition |Name of the formally registered thesaurus or a similar authoritative source of keywords
|ISO 19115 number and name |55. thesaurusName
|ISO/TS 19139 path |identificationInfo[1]/*/descriptiveKeywords/*/thesaurusName
|INSPIRE obligation / condition |Conditional: Mandatory if the keyword value originates from a controlled vocabulary
|INSPIRE multiplicity |[0..1] relative to a single Keyword, but there may be many keywords originating from different controlled vocabularies
|Data type (and ISO 19115 no.) |CI_Citation
|Domain a|
The following properties are expected:

* Title (characterString and free text)
* Reference date (CI_Date):
** {blank}
+

dateType: creation, publication or revision

** {blank}
+

date: an effective date


|Example a|
Identification for a keyword originating from GEMET- INSPIRE themes:

* title: GEMET - INSPIRE themes, version 1.0
* date:
** {blank}
+

dateType: publication

** {blank}
+

date: 2008-06-01


Identification for a keyword originating from GEMET - Concepts:

* title: GEMET - Concepts, version 2.4
* date:
** {blank}
+

dateType: publication

** {blank}
+

date: 2010-01-13


Identification for a keyword originating from AGROVOC:

* title: AGROVOC
* date:
** {blank}
+

dateType: publication

** {blank}
+

date: 2008-04-14


|Comments |
|===

==== Geographic bounding box

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Geographic bounding box
|Reference |Part B 4.1
|Definition a|
Western-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east).

Eastern-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east)

Northern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north)

Southern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north).

|ISO 19115 number and name a|
{empty}344. westBoundLongitude

{empty}345. eastBoundLongitude

{empty}346. southBoundLatitude

{empty}347. northBoundLatitude

|ISO/TS 19139 path a|
identificationInfo[1]/*/extent/*/geographicElement/*/westBoundLongitude

identificationInfo[1]/*/extent/*/geographicElement/*/eastBoundLongitude

identificationInfo[1]/*/extent/*/geographicElement/*/southBoundLatitude

identificationInfo[1]/*/extent/*/geographicElement/*/northBoundLatitude

|INSPIRE obligation / condition a|
* Mandatory for datasets and spatial dataset series
* Conditional for spatial services: mandatory for services with an explicit geographic extent

|INSPIRE multiplicity a|
[1..*] for spatial data sets and spatial dataset series

[0..*] for spatial data services

|Data type (and ISO 19115 no.) |Decimal
|Domain a|
-180.00 ≤ westBoundLongitude ≤ 180.00

-180.00 ≤ eastBoundLongitude ≤ 180.00

-90.00 ≤ southBoundingLatitude ≤ 90.00

-90.00 ≤ northBoundingLatitude ≤ 90.00

|Example a|
-15.00 (westBoundLongitude )

45.00 (eastBoundLongitude )

35.00 (southBoundLatitude)

72.00 (northBoundLatitude)

|Comments a|
* There may be as many bounding boxes defining the geographic location of the resource as instances of identificationInfo[1]/*/extent/*/geographicElement having the westBoundLongitude, eastBoundLongitude, southBoundLatitude and northBoundLatitude properties. The four coordinates of the bounding box originate from the same instance.
* If the bounding box crosses the 180 meridian, then the value of the westBoundLongitude will be greater than the eastBoundLongitude value.

|===

==== Temporal extent

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Temporal extent
|Reference |Part B 5.1
|Definition |Time period covered by the content of the dataset
|ISO 19115 number and name |351. extent
|ISO/TS 19139 path |identificationInfo[1]/*/extent/*/temporalElement/*/extent
|INSPIRE obligation / condition |Conditional: At least one temporal reference is required
|INSPIRE multiplicity |[0..*] for temporal extent but at least one temporal reference is required
|Data type (and ISO 19115 no.) |TM_Primitive
|Domain |As described in ISO 19108
|Example |From 2008-01-01T11:45:30 to 2008-12-31T09:10:00
|Comments |The overall time period covered by the content of the resource may be composed of one or many instances
|===

==== Date of publication

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Date of publication
|Reference |Part B 5.2
|Definition |Reference date for the cited resource - publication
|ISO 19115 number and name |362. date
|ISO/TS 19139 path |identificationInfo[1]/*/citation/*/date[./*/dateType/*/text()='publication']/*/date
|INSPIRE obligation / condition |Conditional: at least one date of publication / date of creation / date of revision is required
|INSPIRE multiplicity |[0..*] but at least one date of publication / date of creation / date of revision or one temporal extent is required
|Data type (and ISO 19115 no.) |393. CI_Date
|Domain |Described in ISO 19108 and ISO 8601
|Example a|
2009-03-15

2009-03-15T11:15:00

|Comments |
|===

==== Date of last revision

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Date of last revision
|Reference |Part B 5.3
|Definition |Reference date for the cited resource - revision
|ISO 19115 number and name |362. date
|ISO/TS 19139 path |identificationInfo[1]/*/citation/*/date[./*/dateType/*/text()='publication']/*/date
|INSPIRE obligation / condition |Conditional: at least one date of publication / date of creation / date of revision is required
|INSPIRE multiplicity |[0..1] but at least one date of publication / date of creation / date of revision or one temporal extent is required
|Data type (and ISO 19115 no.) |393. CI_Date
|Domain |Described in ISO 19108 and ISO 8601
|Example a|
2009-04-15

2009-04-15T11:15:00

|Comments |There may be more than one revision date provided in an ISO 19115 metadata, but INSPIRE will consider as date of last revision the more recent one
|===

==== Date of creation

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Date of creation
|Reference |Part B 5.4
|Definition |Reference date for the cited resource - creation
|ISO 19115 number and name |362. date
|ISO/TS 19139 path |identificationInfo[1]/*/citation/*/date[./*/dateType/*/text()='publication']/*/date
|INSPIRE obligation / condition |Conditional: at least one date of publication / date of creation / date of revision is required
|INSPIRE multiplicity |[0..1] but at least one date of publication / date of creation / date of revision or one temporal extent is required
|Data type (and ISO 19115 no.) |393. CI_Date
|Domain |Described in ISO 19108 and ISO 8601
|Example a|
2009-02-15

2009-02-15T11:15:00

|Comments |
|===

==== Lineage

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Lineage
|Reference |Part B 6.1
|Definition |General explanation of the data producer’s knowledge about the lineage of a dataset
|ISO 19115 number and name |83. statement
|ISO/TS 19139 path |dataQualityInfo/*/lineage/*/statement
|INSPIRE obligation / condition a|
* Mandatory for spatial dataset and spatial dataset series.
* Not applicable to services.

|INSPIRE multiplicity a|
[1] for datasets and data set series

[0] for spatial data services

|Data type (and ISO 19115 no.) |CharacterString
|Domain |Free text
|Example |Computation of the SPI involves fitting a probability density function to a given frequency distribution of precipitation totals for a station or grid point and for an accumulation period. We use the gamma probability density function. The statistics for the frequency distribution are calculated on the basis of a reference period of at least 30 years. The parameters of the probability density function are then used to find the cumulative probability of the observed precipitation for the required month and temporal scale. This cumulative probability is then transformed to the standardised normal distribution with mean zero and variance one, which results in the value of the SPI. The SPI values are computed using the so-called MARS weather stations as rainfall input data. Refer the MARS weather catalogue for characteristics of the quality and quantity of these data. We only rely on the rainfall data input
|Comments |
|===

==== Spatial resolution

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Spatial resolution
|Reference |Part B 6.2
|Definition a|
* Equivalent scale: level of detail expressed as the scale denominator of a comparable hardcopy map or chart
* Distance: ground sample distance

|ISO 19115 number and name a|
* {empty}60. equivalentScale
* {empty}61. distance

|ISO/TS 19139 path a|
* identificationInfo[1]/*/spatialResolution/*/equivalentScale/*/denominator (equivalent scale)
* identificationInfo[1]/*/spatialResolution/*/distance (distance)

|INSPIRE obligation / condition a|
* Conditional: Mandatory if an equivalent scale or a resolution distance can be specified.
* Conditional: Mandatory when there is a restriction on the spatial resolution for service.

|INSPIRE multiplicity |[0..*]
|Data type (and ISO 19115 no.) a|
* Integer (equivalent scale)
* Distance (distance)

|Domain a|
* positive integer (equivalent scale)
* number expressing the distance value and a unit of measure of the distance value (distance)

|Example a|
50000 (e.g. 1:50000 scale map)

0.25 (degrees)

|Comments |For services, it is not possible to express the restriction of a service concerning the spatial resolution in the current version of ISO 19119. While the problem is addressed by the standardization community, spatial resolution restrictions for services shall be expressed in the Abstract
|===

==== Specification

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Specification
|Reference |Part B 7.1
|Definition |Citation of the product specification or user requirement against which data is being evaluated
|ISO 19115 number and name |130. specification
|ISO/TS 19139 path |dataQualityInfo/*/report/*/result/*/specification
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement
|Data type (and ISO 19115 no.) |359. CI_Citation
|Domain a|
The following properties are expected:

* Title (characterString and free text)
* Reference date (CI_Date):
** {blank}
+

dateType: creation, publication or revision


date: an effective date

|Example a|
* title: COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
* date:
** {blank}
+

dateType: publication

** {blank}
+

date: 2010-12-08


|Comments |
|===

==== Degree

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Degree
|Reference |Part B 7.2
|Definition |Indication of the conformance result
|ISO 19115 number and name |132. pass
|ISO/TS 19139 path |dataQualityInfo/*/report/*/result/*/pass
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement
|Data type (and ISO 19115 no.) |Boolean
|Domain a|
* true if conformant
* false if not conformant
* null (with nilReason = “unknown”) if not evaluated

|Example |true
|Comments |
|===

==== Conditions applying to access and use

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Conditions applying to access and use
|Reference |Part B 8.1
|Definition |Restrictions on the access of a resource or metadata
|ISO 19115 number and name |70. accessConstraints
|ISO/TS 19139 path |identificationInfo[1]/*/resourceConstraints/*/accessConstraints
|INSPIRE obligation / condition |Conditional. Mandatory if useConstraints is not documented.
|INSPIRE multiplicity |[0..*] for accessConstraints per instance of MD_LegalConstraints
|Data type (and ISO 19115 no.) |MD_RestrictionCode
|Domain |Codelist (strictly limited to the value defined in B.5.24 of ISO 19115)
|Example |otherRestrictions (limitation not listed).
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Conditions applying to access and use (other constraints)
|Reference |Part B 8.1
|Definition |Other restrictions and legal prerequisites for accessing the resource or metadata
|ISO 19115 number and name |72. otherConstraints
|ISO/TS 19139 path |identificationInfo[1]/*/resourceConstraints/*/otherConstraints
|INSPIRE obligation / condition |Conditional: referring to conditions applying to access. Mandatory if accessConstraints is set at the value “otherRestrictions”
|INSPIRE multiplicity |[0..*] for otherConstraints per instance of MD_LegalConstraints
|Data type (and ISO 19115 no.) |CharacterString
|Domain a|
Free text or if the values “no conditions apply” or “conditions unknown” is used then an Anchor to the code list http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse

in the Inspire Registry should be used. See also Annex D.2 in this document for the code list.

|Example a|
Example if no conditions apply:

http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/NoConditionsApply[+++http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse/NoConditionsApply+++]

Example if there is information about restrictions:

Reproduction for non-commercial purposes is authorised, provided the source is acknowledged. Commercial use is not permitted without prior written consent of the JRC. Reports, articles, papers, scientific and non-scientific works of any form, including tables, maps, or any other kind of output, in printed or electronic form, based in whole or in part on the data supplied, must contain an acknowledgement of the form: Data re-used from the European Drought Observatory (EDO) http://edo.jrc.ec.europa.eu The SPI data were created as part of JRC's research activities. Although every care has been taken in preparing and testing the data, JRC cannot guarantee that the data are correct; neither does JRC accept any liability whatsoever for any error, missing data or omission in the data, or for any loss or damage arising from its use. The JRC will not be responsible for any direct or indirect use which might be made of the data. The JRC does not provide any assistance or support in using the data

|Comments |The domain of the metadata element otherConstraints is Free text. This makes it hard to unambiguous define some common values in all official languages in the Communiy.Therefore it is required to refer to code lists in the Inspire registry for some specific values like “no conditions apply” and “conditions unknown” (see TG Requirement 8).
|===

[width="100%",cols="30%,70%",options="header",]
|===
|*Metadata element name* |*Conditions applying to use*
|Reference |Part B 8.1
|Definition |Restrictions on the use of a resource or metadata
|ISO 19115 number and name |71. useConstraints
|ISO/TS 19139 path |identificationInfo[1]/*/resourceConstraints/*/useConstraints
|INSPIRE obligation / condition |Conditional. Mandatory if accessConstraints is not documented.
|INSPIRE multiplicity |[0..*] for useConstraints per instance of MD_LegalConstraints
|Data type (and ISO 19115 no.) |MD_RestrictionCode
|Domain |Codelist (strictly limited to the value defined in B.5.24 of ISO 19115)
|Example |*otherRestrictions* (limitation not listed).
|Comments |
|===

[width="100%",cols="30%,70%",options="header",]
|===
|*Metadata element name* |*Conditions applying to use (other constraints)*
|Reference |Part B 8.1
|Definition |Other restrictions and legal prerequisites for accessing and using the resource or metadata
|ISO 19115 number and name |72. otherConstraints
|ISO/TS 19139 path |identificationInfo[1]/*/resourceConstraints/*/otherConstraints
|INSPIRE obligation / condition |Conditional: referring to conditions applying to use. Mandatory if useConstraints is set at the value “otherRestrictions”
|INSPIRE multiplicity |[0..*] for otherConstraints per instance of MD_LegalConstraints
|Data type (and ISO 19115 no.) |CharacterString
|Domain |Free text +
or +
if the values “no conditions apply” or “conditions unknown” is used then an Anchor to the codelist in the Inspire Registry should be used.
|Example a|
Example if no conditions apply:

http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse/noConditionsApply

Example if there is information about restrictions:

*Reproduction for non-commercial purposes is authorised, provided the source is acknowledged. Commercial use is not permitted without prior written consent of the JRC. Reports, articles, papers, scientific and non-scientific works of any form, including tables, maps, or any other kind of output, in printed or electronic form, based in whole or in part on the data supplied, must contain an acknowledgement of the form: Data re-used from the European Drought Observatory (EDO) http://edo.jrc.ec.europa.eu The SPI data were created as part of JRC's research activities. Although every care has been taken in preparing and testing the data, JRC cannot guarantee that the data are correct; neither does JRC accept any liability whatsoever for any error, missing data or omission in the data, or for any loss or damage arising from its use. The JRC will not be responsible for any direct or indirect use which might be made of the data. The JRC does not provide any assistance or support in using the data*

|Comments |The domain of the metadata element otherConstraints is Free text. This makes it hard to unambiguous define some common values in all official languages in the Community. +
Therefore it is required to refer to codelists in the Inspire registry for some specific values like “no conditions apply” and “conditions unknown” (see TG Requirement 8).
|===

==== Limitations on public access

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Limitations on public access (access constraints)
|Reference |Part B 8.2
|Definition |access constraints applied to assure the protection of privacy or intellectual property, and any special restrictions or limitations on obtaining the resource
|ISO 19115 number and name |70. accessConstraints
|ISO/TS 19139 path |identificationInfo[1]/*/resourceConstraints/*/accessConstraints
|INSPIRE obligation / condition |Conditional: referring to limitations on public access. Mandatory if classification is not documented
|INSPIRE multiplicity |[0..*] for accessConstraints per instance of MD_LegalConstraints
|Data type (and ISO 19115 no.) |MD_RestrictionCode
|Domain |Codelist (strictly limited at the value defined in B.5.24 of ISO 19115)
|Example |otherRestrictions
|Comments |
|===

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Limitations on public access (other constraints)
|Reference |Part B 8.2
|Definition |Other restrictions and legal prerequisites for accessing and using the resource or metadata
|ISO 19115 number and name |72. otherConstraints
|ISO/TS 19139 path |identificationInfo[1]/*/resourceConstraints/*/otherConstraints
|INSPIRE obligation / condition |Conditional: referring to limitations on public access. Mandatory if classification is not documented
|INSPIRE multiplicity |[0..*] for otherConstraints per instance of MD_LegalConstraints
|Data type (and ISO 19115 no.) |Gmx:anchor
|Domain |A code list value from the code list at %20http://inspire.ec.europa.eu/metadata-codelist%20/LimitationsOnPublicAccess[http://inspire.ec.europa.eu/metadata-codelist /LimitationsOnPublicAccess]/. See also Annex D.1 of this document for this code list.
|Example |<gmx:Anchor link:href=" http://inspire.ec.europa.eu/ metadata-codelist /LimitationsOnPublicAccess//NoLimitations"> no limitations</gmx:Anchor>
|Comments |
|===

==== Responsible party

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Responsible party
|Reference |Part B 9.1
|Definition |Identification of, and means of communication with, person(s) and organization(s) associated with the resource(s)
|ISO 19115 number and name |29. pointOfContact
|ISO/TS 19139 path |identificationInfo[1]/*/pointOfContact
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1] Relative to a responsible organisation, but there may be many responsible organisations for a single resource
|Data type (and ISO 19115 no.) |374. CI_ResponsibleParty
|Domain a|
The following properties are expected:

* organisationName (characterString and free text)
* contactInfo (CI_Contact):
** {blank}
+

address:

*** {blank}
+

electronicMailAddress [1..*] (characterString)


|Example a|
* organisationName: European Commission, Joint Research Centre
* contactInfo:
** {blank}
+

address:

*** {blank}
+

electronicMailAddress: ies-contact@jrc.ec.europa.eu


|Comments |
|===

==== Responsible party role

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Responsible party role
|Reference |Part B 9.2
|Definition |Function performed by the responsible party
|ISO 19115 number and name |379. role
|ISO/TS 19139 path |identificationInfo[1]/*/pointOfContact/*/role
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1] relative to a responsible organisation, but there may be many responsible organisations for a single resource
|Data type (and ISO 19115 no.) |CI_RoleCode
|Domain |Codelist (see B.5.5 of ISO 19115)
|Example |custodian
|Comments |There is a direct mapping between the responsible party roles defined in Part D 6 of [Regulation 1205/2008] and the values of the CI_RoleCode code list of ISO 19115
|===

==== Metadata point of contact

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Metadata point of contact
|Reference |Part B 10.1
|Definition |Party responsible for the metadata information
|ISO 19115 number and name |8. contact
|ISO/TS 19139 path |contact
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1..*]
|Data type (and ISO 19115 no.) |374. CI_ResponsibleParty
|Domain a|
The following properties are expected:

* organisationName (characterString and free text)
* contactInfo (CI_Contact):
** {blank}
+

address:

*** {blank}
+

electronicMailAddress [1..*] (characterString)


|Example a|
* organisationName: European Commission, Joint Research Centre
* contactInfo:
** {blank}
+

address:

*** {blank}
+

electronicMailAddress: ies-contact@jrc.ec.europa.eu


|Comments |
|===

==== Metadata date

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Metadata date
|Reference |Part B 10.2
|Definition |Date that the metadata was created
|ISO 19115 number and name |9. dateStamp
|ISO/TS 19139 path |dateStamp
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |Date
|Domain |ISO 8601
|Example |2012-02-20
|Comments |
|===

==== Metadata language

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Metadata language
|Reference |Part B 10.3
|Definition |Language used for documenting metadata
|ISO 19115 number and name |3. language
|ISO/TS 19139 path |language
|INSPIRE obligation / condition |Mandatory
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |LanguageCode (ISO/TS 19139)
|Domain a|
Codelist (See ISO/TS 19139) based on alpha-3 codes of ISO 639-2. Use only three-letter codes from in ISO 639-2/B (bibliographic codes),

The value domain for this element is limited to the official languages of the EU member states.

The list of valid codes for the 24 official EU languages is:

Bulgarian – bul Irish – gle

Croatian – hrv Italian – ita

Czech – cze Latvian – lav

Danish – dan Lithuanian – lit

Dutch – dut Maltese – mlt

English – eng Polish – pol

Estonian – est Portuguese – por

Finnish – fin Romanian – rum

French – fre Slovak – slo

German – ger Slovenian – slv

Greek – gre Spanish – spa

Hungarian – hun Swedish – swe

These values are part of the list defined at http://www.loc.gov/standards/iso639-2/[+++http://www.loc.gov/standards/iso639-2/+++]

|Example |Eng
|Comments |
|===

=== Implementing Rules for interoperability of spatial data sets and services (regulations 1089/2010 and 1253/2013)

==== Coordinate Reference System

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Coordinate Reference System
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 1
|Definition |Description of the coordinate reference system(s) used in the data set.
|ISO 19115 number and name |13. referenceSystem
|ISO/TS 19139 path |referenceSystemInfo
|INSPIRE obligation / condition a|
Mandatory for dataset and dataset series;

not applicable to Network services;

|INSPIRE multiplicity |[1..*] for dataset and dataset series;
|Data type (and ISO 19115 no.) |186. MD_ReferenceSystem
|Domain a|
To identify the reference system, the referenceSystemIdentifier (RS_Identifier) shall be provided.

RS_Identifier itself is a complex type (lines 206-207 and 208.1-208.2 from ISO 19115).

At least the following element that is mandatory for ISO should be used (the multiplicity according to ISO 19115 is shown in parentheses):

* {blank}
+

{empty}207. code [1] / domain value: free text


TG Requirement 2 in INSPIRE Data specifications states that a URI identifier listed in a table provided there shall be used for referring to the Coordinate reference system.

This table is provided as Annex D.5 of this document.

If the code is given as an URI as shown above, the element codespace is not needed. The identifiers can be accessed via gmx:Anchor (see XML example).

For regions outside of continental Europe, Member States may define suitable coordinate reference systems

|Example |code: http://www.opengis.net/def/crs/EPSG/0/4258[+++http://www.opengis.net/def/crs/EPSG/0/4258+++]
|Comments |ISO 19115 lists several elements which build MD_ReferenceSystem. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the element listed above is sufficient.
|===

==== Temporal Reference System

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Temporal Reference System
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 2
|Definition |Description of the temporal reference system(s) used in the data set.
|ISO 19115 number and name |13. referenceSystemInfo
|ISO/TS 19139 path |referenceSystemInfo
|INSPIRE obligation / condition a|
Conditional for dataset and dataset series: Only required if a non-default temporal reference system (i.e. Gregorian Calendar or the Coordinated Universal Time) is used;

not applicable to services.

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |186. MD_ReferenceSystem
|Domain a|
No specific type is defined in ISO 19115 for temporal reference systems. Thus, the generic MD_ReferenceSystem element and its referenceSystemIdentifier (RS_Identifier) property shall be provided.

RS_Identifier itself is a complex type (lines 206-207 and 208.1-208.2 from ISO 19115).

At least the following element that is mandatory for ISO should be used (the multiplicity according to ISO 19115 is shown in parentheses):

* {blank}
+

{empty}207. code [1] / domain value: free text


|Example |JulianCalendar
|Comments a|
The primary temporal reference system for use with geographic information is the Gregorian Calendar and 24 hour local or Coordinated Universal Time (UTC), but special applications may entail the use of alternative reference systems. So this element is mandatory only if the spatial data set contains temporal information that does not refer to the default temporal reference system.

ISO 19115 lists several elements which build MD_ReferenceSystem. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the element listed above is sufficient.

Further elements like authority, codeSpace and version are optional but may be included for completeness if required.

|===

==== Encoding

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Encoding
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 3
|Definition |Description of the computer language construct(s) specifying the representation of data objects in a record, file, message, storage device or transmission channel.
|ISO 19115 number and name |271.distributionFormat
|ISO/TS 19139 path |distributionInfo/MD_Distribution/distributionFormat
|INSPIRE obligation / condition a|
Mandatory for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[1..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |284. MD_Format
|Domain a|
This is a complex type (lines 285-290 from ISO 19115).

At least the following elements that are mandatory for ISO should be used (the multiplicity according to ISO 19115 is shown in parentheses):

* {blank}
+

{empty}285. name [1] / domain value: free text

* {blank}
+

{empty}286. version [1] / domain value: free text


Content for name could also be taken from INSIPRE Registry using the code list available here: http://inspire.ec.europa.eu/media-types/[+++http://inspire.ec.europa.eu/media-types/+++] and can be accessed via gmx:Anchor (see XML example).

|Example a|
name: GML

version: 3.2.1

|Comments a|
ISO 19115 lists several elements which build MD_Format. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements listed above are sufficient.

Instead of using element specification here the documentation of the supported data scheme inside the distributed dataset (as mentioned in INSPIRE Data specification) can be given either in conformity statement (see link:#Ref419875521[2.8]) or the maybe existing metadata element applicationSchemaInfo (see ISO 19115, B.2.1, No. 21).

|===

==== Character Encoding

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Character Encoding
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 5
|Definition |Full name of the character coding standard used for the dataset
|ISO 19115 number and name |40. characterSet
|ISO/TS 19139 path |identificationInfo[1]/*/characterSet
|INSPIRE obligation / condition a|
Conditional for dataset and dataset series: mandatory if NOT using standard UTF-8 encoding;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |MD_CharacterSetCode
|Domain |CodeList (see B.5.10 of ISO 19115)
|Example |usAscii
|Comments |
|===

==== Spatial representation type

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Spatial representation type
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 6 (element added by amendment 1253/2013)
|Definition |The method used to spatially represent geographic information
|ISO 19115 number and name |37. SpatialRepresentationType
|ISO/TS 19139 path |identificationInfo[1]/*/spatialRepresentationType
|INSPIRE obligation / condition a|
Mandatory for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[1..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |MD_SpatialRepresentation TypeCode
|Domain |Codelist (see B.5.26 of ISO 19115), following INSPIRE Data specifications only vector, grid and tin should be used.
|Example |vector
|Comments |This element is used to broadly categorise a spatial data resource being described.
|===

==== Topological Consistency

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Topological Consistency – +++Quantitative+++ results
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 4
|Definition |Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.
|ISO 19115 number and name |80. report
|ISO/TS 19139 path |dataQualityInfo/DQ_DataQuality/report/
|INSPIRE obligation / condition a|
Conditional for dataset and dataset series: mandatory if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |115. DQ_TopologicalConsistency
|Domain a|
DQ_TopologicalConsistency is a forming of the abstract complex type DQ_Element. See B.2.4.3 in ISO 19115:2003 for further information.

The following ISO 19115 elements are the corresponding ones to express quantitative results of the data quality evaluation as given in INSPIRE Data specifications sections 8.3.2 which in fact focus on ISO 19157:

* {blank}
+

{empty}100. nameOfMeasure [0..*]: name of the test applied to the data / domain value: free text

* {blank}
+

{empty}103. evaluationMethodType [0..1]: type of method used to evaluate quality of the dataset/ domain value: DQ_EvaluationMethod TypeCode

* {blank}
+

{empty}104. evaluationMethodDescription [0..1]: description of the evaluation method / domain value: free text

* {blank}
+

{empty}106. dateTime [0..*]: date or range of dates on which a data quality measure was applied / domain value: DateTime (ISO 19103)

* {blank}
+

{empty}107. result [1..2]: value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level / domain value: DQ_Result (abstract)

* {blank}
+

{empty}133. DQ_QuantitativeResult, consisting of

* {blank}
+

{empty}137. value [1..*]: quantitative value or values, content determined by the evaluation procedure used / domain value: Record (ISO 19103)


Due to making use of DQ_QuantitativeResult subset there is a mandatory element in ISO 19115 to be considerer too:

* {blank}
+

{empty}135. valueUnit [1]


|Example |
|Comments a|
ISO 19115 lists several elements which build DQ_Element. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements won by mapping from ISO 19157 are sufficient.

This element is mandatory only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.

|===

[width="100%",cols="30%,70%",]
|===
|Metadata element name |Topological Consistency – +++Descriptive+++ results
|Reference |COMMISSION REGULATION (EU) No 1089/2010, article 13, clause 4
|Definition |Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.
|ISO 19115 number and name |80. report
|ISO/TS 19139 path |dataQualityInfo/DQ_DataQuality/report/
|INSPIRE obligation / condition a|
Conditional for dataset and dataset series: mandatory if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |115. DQ_TopologicalConsistency
|Domain a|
DQ_TopologicalConsistency is a forming of the abstract complex type DQ_Element. See B.2.4.3 in ISO 19115:2003 for further information.

To provide the descriptive results of Topological consistency evaluation DQ_ConformanceResult containing the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):

* {blank}
+

{empty}130. specification [1..1]: citation of product specification or user requirement against which data is being evaluated / domain value: CI_Citation

* {blank}
+

{empty}131. explanation [1..1]: explanation of the meaning of conformance for this result / domain value: free text

* {blank}
+

{empty}132. pass [1..1]: indication of the conformance result / domain value: Boolean


|Example a|
specification: INSPIRE Data Specifications - Base Models - Generic Network Model–

pass: false

|Comments |To provide the descriptive results of Topological consistency evaluation DQ_ConformanceResult should be used because there is no well matching element for descriptive results at all. The specification to be cited in this case will be the Generic Network Model and pass will be FALSE. This is exactly the condition when to have this statement at all (see reference above).
|===

=== Implementing Rules for Invocable Spatial Data Services (Regulation 1312/2014, Annex I)

Metadata elements for Invocable Spatial Data Services in [Regulation 1089/2010], Annex V as added in amending [Regulation 1312/2014].

==== Category

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Category
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part B 1
|Definition |Citation of the product specification or user requirement against which data is being evaluated
|ISO 19115 number and name |130. specification
|ISO/TS 19139 path |dataQualityInfo/*/report/*/result/*/specification
|INSPIRE obligation / condition |Mandatory for invocable spatial data services
|INSPIRE multiplicity |[1] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement
|Data type (and ISO 19115 no.) |359. CI_Citation
|Domain a|
invocable

http://inspire.ec.europa.eu/RequirementsClass/TG-Metadata/2.0/SDS-invocable

interoperable http://inspire.ec.europa.eu/RequirementsClass/TG-Metadata/2.0/SDS-interoperable

harmonized

http://inspire.ec.europa.eu/RequirementsClass/TG-Metadata/2.0/SDS-harmonised

|Example |<**gmx:Anchor xlink:href=" http://inspire.ec.europa.eu/id/ats/metadata/2.0/sds-invocable"** xlink:title="conformanceClass_Invocable">invocable</gmx:Anchor>
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Degree
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part B 1
|Definition |Indication of the conformance result
|ISO 19115 number and name |132. pass
|ISO/TS 19139 path |dataQualityInfo/*/report/*/result/*/pass
|INSPIRE obligation / condition |Mandatory for invocable spatial data services
|INSPIRE multiplicity |[1] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement
|Data type (and ISO 19115 no.) |Boolean
|Domain a|
* true if conformant

|Example |true
|Comments |If conformant, the domain in this case can only have the value *true*
|===

==== Resource locator 

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Resource locator
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part D 1
|Definition |Location (address) for on-line access using a Uniform Resource Locator address or similar addressing scheme
|ISO 19115 number and name |397. linkage
|ISO/TS 19139 path |distributionInfo/*/transferOptions/*/onLine/*/linkage
|INSPIRE obligation / condition |Mandatory for invocable spatial data services
|INSPIRE multiplicity |[1..*]
|Data type (and ISO 19115 no.) |URL
|Domain |URL (IETF RFC1738 and IETF RFC 2056)
|Example |http://www.dinoservices.nl/geo3dmodelwebservices-1/Geo3DModelService
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Function
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part D 1
|Definition |Detailed text description of what the online resource is/does
|ISO 19115 number and name |401. description
|ISO/TS 19139 path |distributionInfo/*/transferOptions/*/onLine/*/description
|INSPIRE obligation / condition |Mandatory for invocable spatial data services
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |Free text
|Domain |The _gmd:linkage/gmd:description_ child element _gmd:CI_OnlineResource_ shall contain a _gmx:Anchor_ element pointing to the value "accessPoint" of the code list OnLineDescriptionCode in the INSPIRE Registry.
|Example |<gmx:Anchor xlink:href="http://inspire.ec.europa.eu /metadata-codelist/OnLineDescriptionCode/accessPoint">accessPoint</gmx:Anchor>
|Comments |
|===

==== Specification

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Specification
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part D 2
|Definition |Citation of the product specification or user requirement against which data is being evaluated
|ISO 19115 number and name |130. specification
|ISO/TS 19139 path |dataQualityInfo/*/report/*/result/*/specification
|INSPIRE obligation / condition |Mandatory for invocable spatial data services
|INSPIRE multiplicity |[1..*] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement
|Data type (and ISO 19115 no.) |359. CI_Citation
|Domain a|
The following properties are expected:

* Title (characterString and free text)
* Reference date (CI_Date):
** {blank}
+

dateType: creation, publication or revision


date: an effective date

|Example a|
* title: EN ISO 19128:2005(E) : Geographic information — Web map server interface
* date:
** {blank}
+

dateType: publication

** {blank}
+

date: 2005-12-01


|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Degree
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part D 2
|Definition |Indication of the conformance result
|ISO 19115 number and name |132. pass
|ISO/TS 19139 path |dataQualityInfo/*/report/*/result/*/pass
|INSPIRE obligation / condition |Mandatory for invocable spatial data services
|INSPIRE multiplicity |[1] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement
|Data type (and ISO 19115 no.) |Boolean
|Domain a|
* true if conformant

|Example |true
|Comments |If conformant, the domain in this case can only have the value *true*
|===

=== Implementing Rules for Interoperable Spatial Data Services (Regulation 1312/2014, Annex II)

Metadata elements for Interoperable Spatial Data Services in [Regulation 1089/2010], Annex VI as added in amending [Regulation 1312/2014].

==== Coordinate Reference System

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Coordinate Reference System
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VI, Part B 3
|Definition |Description of the coordinate reference system(s) used in the data set.
|ISO 19115 number and name |13. referenceSystem
|ISO/TS 19139 path |referenceSystemInfo
|INSPIRE obligation / condition |Mandatory if relevant for interoperable spatial data services
|INSPIRE multiplicity |[0..*]
|Data type (and ISO 19115 no.) |186.MD_ReferenceSystem
|Domain a|
To identify the reference system, the referenceSystemIdentifier

(RS_Identifier) shall be provided.

|Example |code: http://www.opengis.net/def/crs/EPSG/0/4258[+++http://www.opengis.net/def/crs/EPSG/0/4258+++]
|Comments |Despite the definition of the ISO element, this is used to provide the CRS of the service
|===

==== Criteria

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Criteria
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part B 4.1
|Definition |Name of the test applied to the data
|ISO 19115 number and name |100. nameOfMeasure
|ISO/TS 19139 path |dataQualityInfo/*/report/DQ_ConceptualConsistency/nameOfMeasure
|INSPIRE obligation / condition |Mandatory for interoperable spatial data services
|INSPIRE multiplicity |[1] For each criteria
|Data type (and ISO 19115 no.) |Free text
|Domain a|
Availability (availability)

Performance (performance)

Capacity (capacity)

|Example |availability
|Comments |The identifier of the measure is enough to retrieve all information about the quality measure. This element enable direct understanding of the metadata
|===

==== Measurement

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Description
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part B 4.2.1
|Definition |Code identifying a registered standard procedure
|ISO 19115 number and name |101. measureIdentification
|ISO/TS 19139 path |dataQualityInfo/*/report/DQ_ConceptualConsistency/measureIdentification
|INSPIRE obligation / condition |Mandatory for interoperable spatial data services
|INSPIRE multiplicity |[1] For each criteria
|Data type (and ISO 19115 no.) |MD_Identifier/code
|Domain |http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/availability
|Example |INSPIRE QoS2
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Value
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part B 4.2.2
|Definition |Quantitative value or values, content determined by the evaluation procedure used
|ISO 19115 number and name |137. value
|ISO/TS 19139 path |dataQualityInfo/*/report/DQ_ConceptualConsistency/result/DQ_QuantitativeResult/value
|INSPIRE obligation / condition |Mandatory for interoperable spatial data services
|INSPIRE multiplicity |[1..*] for each criteria
|Data type (and ISO 19115 no.) |As defined for each measure in the quality measure tables
|Domain |
|Example |1
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Unit
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part B 4.2.3
|Definition |Value unit for reporting a data quality result.
|ISO 19115 number and name |135. valueUnit
|ISO/TS 19139 path |dataQualityInfo/*/report/DQ_ConceptualConsistency/result/DQ_QuantitativeResult/valueUnit
|INSPIRE obligation / condition |Mandatory for interoperable spatial data services
|INSPIRE multiplicity |[1] for each criteria
|Data type (and ISO 19115 no.) |UnitOfMeasure
|Domain |Value unit for the measure as described in the quality measure tables
|Example a|
second

(implemented by reference in XML : <gmd:valueUnit xlink:href=" http://www.opengis.net/def/uom/SI/second[+++http://www.opengis.net/def/uom/SI/second+++]"/>)

|Comments |
|===

=== Implementing Rules for Harmonised Spatial Data Services (Regulation 1312/2014, Annex III)

Metadata elements for Harmonised Spatial Data Services in [Regulation 1089/2010], Annex VII as added in amending [Regulation 1312/2014].

==== Invocation metadata

[width="100%",cols="31%,69%",]
|===
|Metadata element name |operationName
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VII Part B 3
|Definition |A unique identifier for this interface
|ISO 19119 number and name |Table C2 1. operationName
|CSW ISO Metadata AP path |identificationInfo[1]/*/containsOperations/*/operationName
|INSPIRE obligation / condition |Mandatory for harmonised spatial data services
|INSPIRE multiplicity |[1]
|Data type (and ISO 19115 no.) |CharacterString
|Domain |
|Example |GetSampleColumn
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |DCP
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VII Part B 3
|Definition |Distributed computing platforms on which the operation has been implemented.
|ISO 19119 number and name |Table C2 2. DCP
|CSW ISO Metadata AP path |identificationInfo[1]/*/containsOperations/*/DCP
|INSPIRE obligation / condition |Mandatory for harmonised spatial data services
|INSPIRE multiplicity |[1..*]
|Data type (and ISO 19115 no.) |DCPlist
|Domain |XML, CORBA, JAVA, COM, SQL, WebServices
|Example |WebServices
|Comments |
|===

[width="100%",cols="31%,69%",]
|===
|Metadata element name |connectPoint
|Reference |COMMISSION REGULATION (EU) No 1089/2010, Annex VII Part B 3
|Definition |Handle for accessing the service interface.
|ISO 19119 number and name |Table C2 6. connectPoint
|CSW ISO Metadata AP path |identificationInfo[1]/*/containsOperations/*/connectPoint/*/linkage
|INSPIRE obligation / condition |Mandatory for harmonised spatial data services
|INSPIRE multiplicity |[1..*]
|Data type (and ISO 19115 no.) |CI_OnlineResource
|Domain |IETF RFC1738 and IETF RFC 2056
|Example |http://www.dinoservices.nl:80/geo3dmodelwebservices-1/Geo3DModelService
|Comments |
|===

=== Theme-specific metadata elements from INSPIRE Data Specifications

This section describes the details on the “recommended theme-specific metadata elements” included in sections 8.3 of INSPIRE Data specifications. All of them are optional but recommended for certain INSPIRE annex themes.

Many of these theme-specific metadata consider details of particular INSPIRE annex themes in definitions and examples. These are listed in the following sub-sections.

The tables below gives an overview of the INSPIRE theme-specific metadata in combination with the INSPIRE annex themes they are recommended for.

image:.\media/image6.png[image,width=792,height=579]

image:.\media/image7.png[image,width=792,height=587]

==== Maintenance information

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Maintenance information
|Reference |INSPIRE Data specifications, sections 8.3.1
|Definition |Information about the scope and frequency of updating
|ISO 19115 number and name |30. resourceMaintenance
|ISO/TS 19139 path |identificationInfo[1]/MD_DataIdentification/resourceMaintenance/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|*Recommended for themes* |*all*
|INSPIRE multiplicity |[0..1] for dataset and dataset series
|Data type (and ISO 19115 no.) |142. MD_MaintenanceInformation
|Domain a|
This is a complex type (lines 143-148 from ISO 19115).

At least the following element should be used (the multiplicity according to ISO 19115 is shown in parentheses):

* {blank}
+

{empty}143. maintenanceAndUpdateFrequency [1]: frequency with which changes and additions are made to the resource after the initial resource is completed / domain value: MD_MaintenanceFrequencyCode


In addition the following elements are recommended, but in contrast to ISO each of them should not appear multiple but single only:

* {blank}
+

{empty}146. updateScope [0..*]: scope of data to which maintenance is applied / domain value: MD_ScopeCode

* {blank}
+

{empty}148. maintenanceNote [0..*]: information regarding specific requirements for maintaining the resource / domain value: free text


|Example a|
maintenanceAndUpdateFrequency: annually

updateScope: dataset

|Comments |ISO 19115 lists several elements which build MD_MaintenanceInformation. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the three elements listed above are sufficient.
|===

==== Spatial representation information

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Spatial representation information
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Digital representation of spatial information in the dataset
|ISO 19115 number and name |12. spatialRepresentationInfo
|ISO/TS 19139 path |spatialRepresentationInfo/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Elevation*
|Data type (and ISO 19115 no.) |156. MD_SpatialRepresentation
|Domain a|
MD_SpatialRepresentation is an abstract complex type and has to be expressed as MD_GridSpatialRepresentation, MD_Georectified, MD_Georeferenceable or MD_VectorSpatialRepresentation.

See B.2.6 in ISO 19115:2003 for further information.

|Example |
|Comments |This metadata information is only applicable to vector and grid spatial representations. Hence it should be informed only when the data set adopt any of these spatial representation types.
|===

==== Supplemental information

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Supplemental information
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Any other descriptive information about the dataset
|ISO 19115 number and name |46. supplementalInformation
|ISO/TS 19139 path |identificationInfo[1]/MD_DataIdentification/supplementalInformation
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..1] for dataset and dataset series
|*Recommended for themes* |*Elevation*
|Data type (and ISO 19115 no.) |CharacterString
|Domain |Free text
|Example |
|Comments on theme ELEVATION a|
This metadata element is recommended to concisely describe general properties of the spatial data set which should be traced here. As illustration, depending on the spatial representation types of the data set:

+++Vector+++

- Contour line vertical intervals (i.e. equidistance parameters), indicating in which geographic areas and/or conditions they are used (if any) within the data set.

+++Grid or Tin+++

- Interpolation method recommended by the data provider in order to calculate the elevation values at any direct position within the DEM extent (either a grid coverage or TIN surface. The calculation involves the interpolation of the elevation values known for the grid coverage range set points or TIN control points, respectively). The values defined for the CV_InterpolationType code list defined in ISO 19123:2005 should be re-used where possible.

- Description of the geographic features that are included (measured) within the DEM surface. Organizations very often have discrepancies to what it is considered as a pure DTM or DSM. Data providers should explain here any existing deviations from the concepts of pure DTM / DSM. As illustration, declaration of any known dynamic features included within the DEM surface, limitations due to the data capture process (e.g. trees or bridges not included within a DSM), if water body surfaces have been flattened or not, etc.

|===

==== Process step

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Process step
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Information about an event or transformation in the life of a dataset including the process used to maintain the dataset
|ISO 19115 number and name |84. processStep
|ISO/TS 19139 path |dataQualityInfo/DQ_DataQuality/lineage/LI_Lineage/processStep/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Elevation, Orthoimagery*
|Data type (and ISO 19115 no.) |86. LI_ProcessStep
|Domain a|
This is a complex type (lines 87-91 from ISO 19115).

The description (87., free text) property shall be provided.

|Example |
|Comments a|
ISO 19115 lists several elements which build LI_ProcessStep. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the element listed above is sufficient.

Note that the path for dataQualityInfo/DQ_DataQuality/lineage/ will already exist in metadata because of being used for carrying information about lineage itself (see link:#Ref419892471[2.7.1]). Therefore an addition of these information into the same entity of LI_Lineage may be useful.

|Comments on theme ELEVATION a|
This metadata element aims to supplement the _Lineage_ metadata element defined in Regulation 1205/2008/EC with a precise description of a process or operation that has been applied to the elevation dataset.

As illustration, the following processing steps may be traced here:

- Data acquisition.

- Data editing.

+++For vector data:+++

- Aero-triangulation.

- Stereo-plotting.

+++For grid data:+++

- Grid calculation / sampling.

Note that such information may convey, most often implicitly, supplementary indications of the expected quality of a dataset, which often depends on the nature of the production process.

In the case of the data acquisition process it is important to highlight any known limitations which may lead to quality problems, for example the description of the geographical areas where the reliability of geographic information is reduced or limited due to limitations of the data capture technology used. Information relative to the geometry of low reliability areas (e.g. links to elsewhere such geometries may be obtained) can be particularly helpful to assess the accuracy and the reliability of the elevation data set.

|Comments on theme ORTHOIMAGERY a|
This metadata element aims to supplement the _Lineage_ metadata element defined in Regulation 1205/2008/EC with a precise description of a process or operation that has been applied to the orthoimagery dataset.

For example, the following processing steps, which are common in orthoimagery, may be traced here:

- data acquisition

- aero/spatio-triangulation

- orthorectification

- mosaicking

- radiometric correction

Note that such information may convey, most often implicitly, supplementary indications of the expected quality of a dataset (e.g. the radiometric aspect of a mosaic), which often depends on the nature of the production process.

|===

==== Data source

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Data source
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Information about the source data used in creating the data specified by the scope
|ISO 19115 number and name |85. source
|ISO/TS 19139 path |dataQualityInfo/DQ_DataQuality/lineage/LI_Lineage/source/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Elevation, Orthoimagery*
|Data type (and ISO 19115 no.) |92. LI_Source
|Domain a|
This is a complex type (lines 93-98 from ISO 19115).

Either the description (93., free text) or the sourceExtent (97., EX_Extent) elements shall be provided.

|Example |
|Comments a|
ISO 19115 lists several elements which build LI_Source. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements listed above are sufficient.

Note that the path for dataQualityInfo/DQ_DataQuality/lineage/ will already exist in metadata because of being used for carrying information about lineage itself (see link:#Ref419892607[2.7.1]). Therefore an addition of these information into the same entity of LI_Lineage may be useful.

|Comments on theme ELEVATION a|
This metadata element aims to supplement the _Lineage_ metadata element defined in Regulation 1205/2008/EC with a precise description of data sources that have been used as input to generate the elevation dataset.

For example, the following data sources may be described and referenced here:

- image sources and orientations

- calibration data

- control data (e.g. aero-triangulation control points)

- data sources used to infer break lines

Metadata on data sources may as well include any specifications available and the conditions of data acquisition (e.g. sensors characteristics, data properties like image overlaps, known lacks of source data, etc).

|Comments on theme ORTHOIMAGERY a|
This metadata element aims to supplement the _Lineage_ metadata element defined in Regulation 1205/2008/EC with a precise description of data sources that have been used as input to generate the orthoimagery dataset.

For example, the following data sources may be described and referenced here:

- image sources

- calibration data

- control data (e.g. control points)

- image positions and orientations

- elevation data

- seamlines used to build the mosaic elements

Metadata on image sources may as well include the specifications and the conditions of data acquisition (e.g. sensors characteristics, image overlap, solar elevation, et.).

Concerning elevation data, it is recommended to provide information about the following basic characteristics of the Digital Elevation Models (DEM) used to rectify images:

- structure (grid or TIN data)

- for grid data: surface type (Digital Terrain Model or Digital Surface Model)

- for grid data: DTM/DSM spacing (distance)

- for grid data: water bodies flattened (yes/no)

- for DSM: modelling of buildings (yes/no)

- for DSM: modelling of trees (yes/no)

- additional breaklines (yes/no)

- vertical datum information

- vertical accuracy (rmse)

- positional accuracy (rmse)

Information relative to the seamlines carrying the geometry of the mosaic elements can be particularly helpful to assess the accuracy and the reliability of the acquisition times provided through these mosaic elements. Seamlines may have been slightly generalized, so that the exact race between adjoining pixels from neighbouring images is lost. Or feathering may have been applied to mosaick images, so that some range values in the mosaic can be defined as a combination of values stemming from several input images with different capture time.

|===

==== Browse graphic information

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Browse graphic information
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Graphic that provides an illustration of the dataset (should include a legend for the graphic)
|ISO 19115 number and name |31. graphicOverview
|ISO/TS 19139 path |identificationInfo[1]/MD_DataIdentification/graphicOverview/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Elevation, Orthoimagery*
|Data type (and ISO 19115 no.) |48. MD_BrowseGraphic
|Domain a|
This is a complex type (lines 49-51 from ISO 19115).

The following element is mandatory (the multiplicity according to ISO 19115 is shown in brackets):

* {blank}
+

{empty}49. filename [1]: name of the file that contains a graphic that provides an illustration of the dataset / domain value: free text


|Example |
|Comments |ISO 19115 lists several elements which build MD_BrowseGraphic. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the element listed above is sufficient.
|===

==== Image description

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Image description
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Information about an image‘s suitability for use
|ISO 19115 number and name |16. contentInfo
|ISO/TS 19139 path |contentInfo/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Orthoimagery*
|Data type (and ISO 19115 no.) |243. MD_ImageDescription
|Domain a|
This is a complex type (lines 244-255 and 249-242 from ISO 19115).

At least the following element should be used:

* {blank}
+

{empty}248. cloudCoverPercentage [1]: area of the dataset obscured by clouds, expressed as a percentage of the spatial extent/ domain value: Real


ISO 19115 itself demands two mandatory elements in MD_ImageDescription:

* {blank}
+

{empty}240. attributeDescription [1]

* {blank}
+

{empty}241. contentType [1]


|Example |
|Comments |ISO 19115 lists several elements that build MD_ImageDescription. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements listed above are sufficient.
|===

==== Content information

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Content information
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Description of the content of a dataset
|ISO 19115 number and name |16. contentInfo
|ISO/TS 19139 path |contentInfo/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..1] for dataset and dataset series
|*Recommended for themes* |*Buildings*
|Data type (and ISO 19115 no.) |233. MD_FeatureCatalogueDescription
|Domain a|
This is a complex type (lines 234-238 from ISO 19115).

Data specification on Buildings does not give a minimum element.

ISO 19115 itself demands two mandatory elements in MD_ FeatureCatalogueDescription:

* {blank}
+

{empty}236. includedWithDataset [1]


* {blank}
+

{empty}238. featureCatalogueCitation [1]


|Example |
|Comments |ISO 19115 lists several elements that build MD_ FeatureCatalogueDescription. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements listed above are sufficient.
|Comments on theme BUILDINGS a|
The purpose of this metadata element is to inform the user about the feature types and properties that are populated in the data set.

This has to be done by a reference to a feature catalogue including only the populated feature types and properties. It may be done by referencing the tables supplied *in annex E of data specification* for additional information once they have been filled by the data producer, just by ticking the populated features and properties.

|===

==== Digital transfer options information

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Digital transfer options information
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Technical means and media by which a resource is obtained from the distributor
|ISO 19115 number and name |273. transferOptions
|ISO/TS 19139 path |distributionInfo/MD_Distribution/transferOptions/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Hydrography, Elevation, Orthoimagery*
|Data type (and ISO 19115 no.) |274. MD_DigitalTransferOptions
|Domain a|
This is a complex type (lines 275-278 from ISO 19115).

At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):

For Elevation and Orthoimagery:

* {blank}
+

{empty}275. unitsOfDistribution [0..1]: tiles, layers, geographic areas, etc., in which data is available / domain value: free text

* {blank}
+

{empty}278. offLine [0..1]: information about offline media on which the resource can be obtained / domain value: MD_Medium


For Hydrography:

* {blank}
+

{empty}276. transferSize [0..1]: estimated size of a unit in the specified transfer format, expressed in megabytes. The transfer size is > 0.0/ domain value: Real


|Example |
|Comments a|
ISO 19115 lists several elements that build MD_DigitalTransferOptions. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements listed above are sufficient.

Note that the path for distributionInfo/MD_Distribution/transferOptions/ may already exist in metadata if being used for carrying information about online access (277. online, see 3.1.3). Therefore an addition of these information into the same entity of MD_DigitalTransferOptions may be useful.

|===

==== Extent

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Identification - Extent
|Reference |INSPIRE Data specifications, sections 8.3.x
|Definition |Extent information including the bounding box, bounding polygon, vertical, and temporal extent of the dataset
|ISO 19115 number and name |45. extent
|ISO/TS 19139 path |identificationInfo[1]/MD_DataIdentification/extent
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|*Recommended for themes* |*Hydrography*
|Data type (and ISO 19115 no.) |334. EX_Extent
|Domain a|
This is a complex type (lines 335-338 from ISO 19115).

In addition to the Geographic bounding box (see 2.3.8) the following element should be used to provide a common "name" for the extent (the multiplicity according to ISO 19115 is shown in parentheses):

* {blank}
+

{empty}335. description [0..1]: spatial and temporal extent for the referring object/ domain value: free text


|Example a|
Use e.g. NAME_ENGL and EUCD_RBD values like

description: "East Estonia, A6018" or

description: "Rhine, A5001"

|Comments |ISO 19115 lists several elements that build EX_Extent. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the element listed above is sufficient in addition to the geographic extent.
|Comments on theme HYDROGRAPHY a|
Use e.g. WISE River basin districts (RBDs)

Use the terms provided here:

<http://dataservice.eea.europa.eu/dataservice/metadetails.asp?id=1041>

In future the use of a common register (gazetteer) of e.g. river names is expected to be useful

|===

==== Data Quality

[width="100%",cols="31%,69%",]
|===
|Metadata element name |Data Quality – +++Quantitative+++ results
|Reference |INSPIRE Data specifications, sections 8.3.2
|Definition |Several, theme specific aspects of Data Quality - See corresponding Data Specfication for further information
|ISO 19115 number and name |80. report
|ISO/TS 19139 path |dataQualityInfo/DQ_DataQuality/report/
|INSPIRE obligation / condition a|
optional for dataset and dataset series;

not applicable to services

|INSPIRE multiplicity |[0..*] for dataset and dataset series
|Data type (and ISO 19115 no.) |99. DQ_Element
|Domain a|
DQ_Element is an abstract complex type and has to be expressed by a corresponding DQ_xxx subelement concerning the particular data quality issue e.g. DQ_ConceptualConsistency.

See B.2.4.3 in ISO 19115:2003 for further information.

The following ISO 19115 elements are the corresponding ones to express quantitative results of the data quality evaluation as given in INSPIRE Data specifications sections 8.3.2 which in fact focus on ISO 19157:

* {blank}
+

{empty}100. nameOfMeasure [0..*]: name of the test applied to the data / domain value: free text

* {blank}
+

{empty}103. evaluationMethodType [0..1]: type of method used to evaluate quality of the dataset/ domain value: DQ_EvaluationMethod TypeCode

* {blank}
+

{empty}104. evaluationMethodDescription [0..1]: description of the evaluation method / domain value: free text

* {blank}
+

{empty}106. dateTime [0..*]: date or range of dates on which a data quality measure was applied / domain value: DateTime (ISO 19103)

* {blank}
+

{empty}107. result [1..2]: value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level / domain value: DQ_Result (abstract)

* {blank}
+

{empty}133. DQ_QuantitativeResult, consisting of

* {blank}
+

{empty}137. value [1..*]: quantitative value or values, content determined by the evaluation procedure used / domain value: Record (ISO 19103)


Due to making use of DQ_QuantitativeResult subset there is a mandatory element in ISO 19115 to be considerer too:

* {blank}
+

{empty}135. valueUnit [1]


|Example |
|Comments |ISO 19115 lists several elements which build DQ_Element. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the elements won by mapping from ISO 19157 are sufficient.
|===

== Annex D Referenced code lists and code list values

=== Limitations on public access

Code list URI: http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess

[arabic]
. {blank}

[width="100%",cols="40%,23%,37%",options="header",]
|===
|Code value |Label |Definition
|INSPIRE_Directive_Article13_1a |public access limited according to Article 13(1)(a) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect the confidentiality of the proceedings of public authorities, where such confidentiality is provided for by law.
|INSPIRE_Directive_Article13_1b |public access limited according to Article 13(1)(b) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect international relations, public security or national defence.
|INSPIRE_Directive_Article13_1c |public access limited according to Article 13(1)(c) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect the course of justice, the ability of any person to receive a fair trial or the ability of a public authority to conduct an enquiry of a criminal or disciplinary nature.
|INSPIRE_Directive_Article13_1d |public access limited according to Article 13(1)(d) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect the confidentiality of commercial or industrial information, where such confidentiality is provided for by national or Community law to protect a legitimate economic interest, including the public interest in maintaining statistical confidentiality and tax secrecy.
|INSPIRE_Directive_Article13_1e |public access limited according to Article 13(1)(e) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect intellectual property rights.
|INSPIRE_Directive_Article13_1f |public access limited according to Article 13(1)(f) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect the confidentiality of personal data and/or files relating to a natural person where that person has not consented to the disclosure of the information to the public, where such confidentiality is provided for by national or Community law.
|INSPIRE_Directive_Article13_1g |public access limited according to Article 13(1)(g) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect the interests or protection of any person who supplied the information requested on a voluntary basis without being under, or capable of being put under, a legal obligation to do so, unless that person has consented to the release of the information concerned.
|INSPIRE_Directive_Article13_1h |public access limited according to Article 13(1)(h) of the INSPIRE Directive |Public access to spatial data sets and services would adversely affect the protection of the environment to which such information relates, such as the location of rare species.
|noLimitations |no limitations to public access |There are no limitations on public access to spatial data sets and services
|===

=== Conditions Applying To Access And Use

Code list URI: http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse

[width="100%",cols="25%,36%,39%",options="header",]
|===
|Code value |Label |Definition
|noConditionsApply |no conditions to access and use |No conditions apply to access and use.
|conditionsUnknown |conditions to access and use unknown |The conditions applying to access and use are unknown
|===

=== Quality of Service criteria code

Code list URI: http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteria

[width="100%",cols="19%,17%,64%",options="header",]
|===
|Code Value |Label |Definition
|availability |availability |The percentage of time the service is available.
|performance |performance |How fast a request to the spatial data service can be completed.
|capacity |capacity |The maximum number of simultaneous requests that can be completed with the declared performance.
|===

=== Default Coordinate Reference Systems

This list of default coordinate reference system identifiers is included here as specified in the INSPIRE Data Specification on Coordinate Reference Systems, version 3.2, Table 1 in section 5.5 Identifiers. In the case that this set of identifiers should be changed or corrected in the later versions of the INSPIRE Data Specification on Coordinate Reference Systems, the changed version of the identifier set should be preferred over the one provided here.

[width="100%",cols="32%,21%,47%",options="header",]
|===
|Description |Short name |HTTP URI Identifier
a|
3D Cartesian in ETRS89

(X,Y,Z)

|ETRS89-XYZ |http://www.opengis.net/def/crs/EPSG/0/4936
|3D geodetic in ETRS89 on GRS80 (Latitude, Longitude, Ellipsoidal height) |ETRS89-GRS80h |http://www.opengis.net/def/crs/EPSG/0/4937
|2D geodetic in ETRS89 on GRS80 (Latitude, Longitude) |ETRS89-GRS80 |http://www.opengis.net/def/crs/EPSG/0/4258
|2D LAEA projection in ETRS89 on GRS80 (Y,X) |ETRS89-LAEA |http://www.opengis.net/def/crs/EPSG/0/3035
|2D LCC projection in ETRS89 on GRS80 (N,E) |ETRS89-LCC |http://www.opengis.net/def/crs/EPSG/0/3034
|2D TM projection in ETRS89 on GRS80, zone 26N (30°W to 24°W) (N,E) |ETRS89-TM26N |http://www.opengis.net/def/crs/EPSG/0/3038
|2D TM projection in ETRS89 on GRS80, zone 27N (24°W to 18°W) (N,E) |ETRS89-TM27N |http://www.opengis.net/def/crs/EPSG/0/3039
|2D TM projection in ETRS89 on GRS80, zone 28N (18°W to 12°W) (N,E) |ETRS89-TM28N |http://www.opengis.net/def/crs/EPSG/0/3040
|2D TM projection in ETRS89 on GRS80, zone 29N (12°W to 6°W) (N,E) |ETRS89-TM29N |http://www.opengis.net/def/crs/EPSG/0/3041
|2D TM projection in ETRS89 on GRS80, zone 30N (6°W to 0°) (N,E) |ETRS89-TM30N |http://www.opengis.net/def/crs/EPSG/0/3042
|2D TM projection in ETRS89 on GRS80, zone 31N (0° to 6°E) (N,E) |ETRS89-TM31N |http://www.opengis.net/def/crs/EPSG/0/3043
|2D TM projection in ETRS89 on GRS80, zone 32N (6°E to 12°E) (N,E) |ETRS89-TM32N |http://www.opengis.net/def/crs/EPSG/0/3044
|2D TM projection in ETRS89 on GRS80, zone 33N (12°E to 18°E) (N,E) |ETRS89-TM33N |http://www.opengis.net/def/crs/EPSG/0/3045
|2D TM projection in ETRS89 on GRS80, zone 34N (18°E to 24°E) (N,E) |ETRS89-TM34N |http://www.opengis.net/def/crs/EPSG/0/3046
|2D TM projection in ETRS89 on GRS80, zone 35N (24°E to 30°E) (N,E) |ETRS89-TM35N |http://www.opengis.net/def/crs/EPSG/0/3047
|2D TM projection in ETRS89 on GRS80, zone 36N (30°E to 36°E) (N,E) |ETRS89-TM36N |http://www.opengis.net/def/crs/EPSG/0/3048
|2D TM projection in ETRS89 on GRS80, zone 37N (36°E to 42°E) (N,E) |ETRS89-TM37N |http://www.opengis.net/def/crs/EPSG/0/3049
|2D TM projection in ETRS89 on GRS80, zone 38N (42°E to 48°E) (N,E) |ETRS89-TM38N |http://www.opengis.net/def/crs/EPSG/0/3050
|2D TM projection in ETRS89 on GRS80, zone 39N (48°E to 54°E) (N,E) |ETRS89-TM39N |http://www.opengis.net/def/crs/EPSG/0/3051
|Height in EVRS (H) |EVRS |http://www.opengis.net/def/crs/EPSG/0/5730
|Depth referred to LAT (D) |LAT |http://www.opengis.net/def/crs/EPSG/0/5861
|Depth referred to MSL (D) |MSL |http://www.opengis.net/def/crs/EPSG/0/5715
|Pressure coordinate in the free atmosphere (ICAO international standard atmosphere) (P) |ISA |http://codes.wmo.int/grib2/codeflag/4.2/_0-3-3
|3D compound: 2D geodetic in ETRS89 on GRS80, and EVRS height(Latitude, Longitude, H) |ETRS89-GRS80- EVRS |http://www.opengis.net/def/crs/EPSG/0/7409
|===

== Annex E Mapping between IR element numbers and TG Requirements

[width="99%",cols="20%,13%,24%,25%,18%",options="header",]
|===
|*Implementing rule* |*Section / article* |*Element name* |*TG Requirement(s)* |*Sections*
|[Regulation 1205/2008] |Part B 1.1 |Resource title |TG Requirement C.8 |2.3.1
|[Regulation 1205/2008] |Part B 1.2 |Resource abstract |TG Requirement C.9 |2.3.2
|[Regulation 1205/2008] |Part B 1.3 |Resource type |TG Requirement 1.1, TG Requirement 3.1 a|
3.1.1.1,

4.1.1.1

|[Regulation 1205/2008] |Part B 1.4 |Resource locator |TG Requirement 1.8, TG Requirement 3.7 a|
3.1.3.1,

4.1.3.1

|[Regulation 1205/2008] |Part B 1.5 |Unique resource identifier |TG Requirement 1.3 |3.1.2.1
|[Regulation 1205/2008] |Part B 1.7 |Resource language |TG Requirement 1.6 |3.1.2.4
|[Regulation 1205/2008] |Part B 1.6 |Coupled resource |TG Requirement 3.6 |4.1.2.4
|[Regulation 1205/2008] |Part B 2.1 |Topic category |TG Requirement 1.7 |3.1.2.5
|[Regulation 1205/2008] |Part B 2.2 |Spatial data service type |TG Requirement 3.5, TG Requirement 4.1, TG Requirement 5.1 a|
4.1.2.3,

4.2.1.1,

4.3.1.1

|[Regulation 1205/2008] |Part B 3.1 |Keyword value |TG Requirement 1.4, TG Requirement 3.4 a|
3.1.2.2,

4.1.2.2

|[Regulation 1205/2008] |Part B 3.2 |Originating controlled vocabulary |TG Requirement C.15 |2.3.5
|[Regulation 1205/2008] |Part B 4.1 |Geographic bounding box |TG Requirement C.19 |2.3.8
|[Regulation 1205/2008] |Part B 5 |Temporal reference |TG Requirement C.11, TG Requirement C.12, TG Requirement C.13 |2.3.4
|[Regulation 1205/2008] |Part B 5.1 |Temporal extent |TG Requirement C.14 |2.3.4
|[Regulation 1205/2008] |Part B 5.2 |Date of publication |TG Requirement C.11 |2.3.4
|[Regulation 1205/2008] |Part B 5.3 |Date of last revision |TG Requirement C.11, TG Requirement C.13 |2.3.4
|[Regulation 1205/2008] |Part B 5.4 |Date of creation |TG Requirement C.11, TG Requirement C.12 |2.3.4
|[Regulation 1205/2008] |Part B 6.1 |Lineage |TG Requirement 1.11 |3.1.4.3
|[Regulation 1205/2008] |Part B 6.2 |Spatial resolution |TG Requirement 1.5, TG Requirement 3.3 a|
3.1.2.3,

4.1.2.1

|[Regulation 1205/2008] |Part B 7 |Conformity |TG Requirement C.20, TG Requirement C.22, TG Requirement C.21, TG Requirement 1.10, TG Requirement 5.3, TG Requirement 5.5 a|
2.4.1,

3.1.4.2,

4.2.2.1,

4.3.3.1,

4.3.3.3

|[Regulation 1205/2008] |Part B 7.1 |Specification |TG Requirement C.20, TG Requirement C.22, TG Requirement C.21, TG Requirement 1.10, TG Requirement 5.3, TG Requirement 5.5 a|
2.4.1,

3.1.4.2,

4.2.2.1,

4.3.3.1,

4.3.3.3

|[Regulation 1205/2008] |Part B 7.2 |Degree |TG Requirement C.20, TG Requirement C.22, TG Requirement C.21, TG Requirement 1.10, TG Requirement 5.3, TG Requirement 5.5 a|
2.4.1,

3.1.4.2,

4.2.2.1,

4.3.3.1,

4.3.3.3

|[Regulation 1205/2008] |Part B 8.1 |Conditions applying to access and use |TG Requirement C.18 |2.3.7
|[Regulation 1205/2008] |Part B 8.2 |Limitations on public access |TG Requirement C.17 |2.3.6
|[Regulation 1205/2008] |Part B 9 |Responsible organisation |TG Requirement C.10 |2.3.3
|[Regulation 1205/2008] |Part B 9.1 |Responsible party |TG Requirement C.10 |2.3.3
|[Regulation 1205/2008] |Part B 9.2 |Responsible party role |TG Requirement C.10 |2.3.3
|[Regulation 1205/2008] |Part B 10.1 |Metadata point of contact |TG Requirement C.6 |2.2.3
|[Regulation 1205/2008] |Part B 10.2 |Metadata date |TG Requirement C.7 |2.2.4
|[Regulation 1205/2008] |Part B 10.3 |Metadata language |TG Requirement C.5 |2.2.2
|[Regulation 1089/2010]/[Regulation 1089/2010], Annex VI |Article 13, clause 1/ Part B 3 |Coordinate Reference System (Identifier) |TG Requirement 2.1, TG Requirement 2.2, TG Requirement 6.1, TG Requirement 6.2 a|
3.2.1.1,

4.4.1.1

|[Regulation 1089/2010] |Article 13, clause 2 |Temporal Reference System |TG Requirement 2.3 |3.2.1.2
|[Regulation 1089/2010] |Article 13, clause 3 |Encoding |TG Requirement 2.6 |3.2.3.1
|[Regulation 1089/2010] |Article 13, clause 4 |Topological consistency |TG Requirement 2.7, TG Requirement 2.8 |3.2.4.1
|[Regulation 1089/2010] |Article 13, clause 5 |Character Encoding |TG Requirement 2.5 |3.2.2.2
|[Regulation 1089/2010] amended by [Regulation 1253/2013] |Article 13, clause 6 |Spatial representation type |TG Requirement 2.4 |3.2.2.1
|[Regulation 1089/2010], Annex V, (Invocable SDS) |Part B 1 |Category |TG Requirement 3.4, TG Requirement 5.4 a|
4.1.2.2,

4.3.3.2

|[Regulation 1089/2010], Annex VI, (Interoperable SDS) |Part B 4 |Quality of service |TG Requirement 6.5 |4.4.3.1
|[Regulation 1089/2010], Annex VII, (Harmonised SDS) |Part B 3 |Invocation metadata |TG Requirement 7.1, TG Requirement 7.2, TG Requirement 7.3 |4.5.1.1
|===

== Annex F Mapping for Requirements in previous TG versions

[width="100%",cols="44%,30%,26%",options="header",]
|===
|*Originating document & requirement* |*TG Metadata 2.0 requirement* |*TG Metadata 2.0 section*
|TG Metadata 1.3, TG Requirement 1 |TG Requirement 1.1 |3.1.1.1
|TG Metadata 1.3, TG Requirement 2 |TG Requirement 1.1, +
TG Requirement 3.1 a|
3.1.1.1,

4.1.1.1

|TG Metadata 1.3, TG Requirement 3 |TG Requirement 1.8 |3.1.3.1
|TG Metadata 1.3, TG Requirement 4 |TG Requirement 3.7 |4.1.3.1
|TG Metadata 1.3, TG Requirement 5 |TG Requirement 1.3 |3.1.2.1
|TG Metadata 1.3, TG Requirement 6 |- |
|TG Metadata 1.3, TG Requirement 7 |TG Requirement 3.6 |4.1.2.4
|TG Metadata 1.3, TG Requirement 8 |TG Requirement 1.6 |3.1.2.4
|TG Metadata 1.3, TG Requirement 9 |TG Requirement 1.6 |3.1.2.4
|TG Metadata 1.3, TG Requirement 10 |TG Requirement 1.7 |3.1.2.5
|TG Metadata 1.3, TG Requirement 11 |- |
|TG Metadata 1.3, TG Requirement 12 a|
TG Requirement 3.5,

TG Requirement 4.1,

TG Requirement 5.1

a|
4.1.2.3,

4.2.1.1,

4.3.1.1

|TG Metadata 1.3, TG Requirement 13 a|
TG Requirement 1.4,

TG Requirement 3.4

a|
3.1.2.2,

4.1.2.2

|TG Metadata 1.3, TG Requirement 14 a|
TG Requirement 1.4,

TG Requirement 3.4

a|
3.1.2.2,

4.1.2.2

|TG Metadata 1.3, TG Requirement 15 a|
TG Requirement 1.4,

TG Requirement 3.4

a|
3.1.2.2,

4.1.2.2

|TG Metadata 1.3, TG Requirement 16 |TG Requirement C.15 |2.3.5
|TG Metadata 1.3, TG Requirement 17 |TG Requirement C.15 |2.3.5
|TG Metadata 1.3, TG Requirement 18 |TG Requirement C.15 |2.3.5
|TG Metadata 1.3, TG Requirement 19 |TG Requirement C.16 |2.3.5
|TG Metadata 1.3, TG Requirement 20 |TG Requirement C.19 |2.3.8
|TG Metadata 1.3, TG Requirement 21 |TG Requirement C.19 |2.3.8
|TG Metadata 1.3, TG Requirement 22 |TG Requirement C.11 |2.3.4
|TG Metadata 1.3, TG Requirement 23 |TG Requirement C.11 |2.3.4
|TG Metadata 1.3, TG Requirement 24 |TG Requirement C.11 |2.3.4
|TG Metadata 1.3, TG Requirement 25 |TG Requirement C.12 |2.3.4
|TG Metadata 1.3, TG Requirement 26 |TG Requirement 1.11 |3.1.4.3
|TG Metadata 1.3, TG Requirement 27 a|
TG Requirement 1.5,

TG Requirement 3.3

a|
3.1.2.3,

4.1.2.1

|TG Metadata 1.3, TG Requirement 28 a|
TG Requirement C.20,

TG Requirement C.21,

TG Requirement C.22,

TG Requirement 1.10,

TG Requirement 5.3

a|
2.4.1,

3.1.4.2,

4.2.2.1,

4.3.3.1,

4.3.3.3

|TG Metadata 1.3, TG Requirement 29 a|
TG Requirement C.20,

TG Requirement C.21,

TG Requirement C.22,

TG Requirement 1.10,

TG Requirement 5.3

a|
2.4.1,

3.1.4.2,

4.2.2.1,

4.3.3.1,

4.3.3.3

|TG Metadata 1.3, TG Requirement 30 a|
TG Requirement C.17,

TG Requirement C.18

a|
2.3.6,

2.3.7

|TG Metadata 1.3, TG Requirement 31 a|
TG Requirement C.17,

TG Requirement C.18

a|
2.3.6,

2.3.7

|TG Metadata 1.3, TG Requirement 32 |TG Requirement C.17 |2.3.6
|TG Metadata 1.3, TG Requirement 33 |TG Requirement C.18 |2.3.7
|TG Metadata 1.3, TG Requirement 34 |TG Requirement C.18 |2.3.7
|TG Metadata 1.3, TG Requirement 35 |TG Requirement C.10 |2.3.3
|TG Metadata 1.3, TG Requirement 36 |TG Requirement C.10 |2.3.3
|TG Metadata 1.3, TG Requirement 37 |TG Requirement C.6 |2.2.3
|TG Metadata 1.3, TG Requirement 38 |TG Requirement C.6 |2.2.3
|TG Metadata 1.3, TG Requirement 39 |TG Requirement C.5 |2.2.2
|TG SDS 3.1, Implementation Requirement 1 |TG Requirement 5.4 |4.3.3.2
|TG SDS 3.1, Implementation Requirement 2 |TG Requirement 5.2 |4.3.2.1
|TG SDS 3.1, Implementation Requirement 3 |TG Requirement 5.2 |4.3.2.1
|TG SDS 3.1, Implementation Requirement 4 |TG Requirement 5.5 |4.3.3.3
|TG SDS 3.1, Implementation Requirement 5 |TG Requirement 5.3 |4.3.3.1
|TG SDS 3.1, Implementation Requirement 6 a|
TG Requirement 6.1,

TG Requirement 6.2

|4.4.1.1
|TG SDS 3.1, Implementation Requirement 7 a|
TG Requirement 6.1,

TG Requirement 6.2

|4.4.1.1
|TG SDS 3.1, Implementation Requirement 8 |TG Requirement 6.5 |4.4.3.1
|TG SDS 3.1, Implementation Requirement 9 |TG Requirement 6.5 |4.4.3.1
|TG SDS 3.1, Implementation Requirement 10 |TG Requirement 6.5 |4.4.3.1
|TG SDS 3.1, Implementation Requirement 11 |TG Requirement 6.4 |4.4.2.2
|TG SDS 3.1, Implementation Requirement 12 |TG Requirement 6.3 |4.4.2.1
|TG SDS 3.1, Implementation Requirement 13 |[Not relevant to metadata] |-
|TG SDS 3.1, Implementation Requirement 14 |[Not relevant to metadata] |-
|TG SDS 3.1, Implementation Requirement 15 a|
TG Requirement 7.1,

TG Requirement 7.2

|4.5.1.1
|TG SDS 3.1, Implementation Requirement 16 |[Not relevant to metadata] |-
|TG SDS 3.1, Implementation Requirement 17 |TG Requirement 5.5 |4.3.2.1
|TG SDS 3.1, Implementation Requirement 18 |[Not relevant to metadata] |-
|===

== Annex G Examples of complete INSPIRE metadata records

A web site with examples of complete metadata records compliant with this technical guidance is available at http://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0/examples.