Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 1 of 104 INSPIRE Infrastructure for Spatial Information in Europe DT Metadata – Draft Implementing Rules for Metadata Title Draft Implementing Rules for Metadata (D1.3) Creator DT Metadata Creation date 2007-02-02 Subject DT Metadata – Implementing Rules Status Draft Publisher DT Metadata Type Text Description Draft Implementing Rules for discovery, evaluation and use metadata and rules for extending the INSPIRE metadata set for specific spatial data themes Based on the text of the INSPIRE Directive agreed by Council and European Parliament, 21st November 2007 Contributor DT Metadata Format MS Word Source DT Metadata Rights Open access. Comments limited to registred SDICs and LMOs Identifier draftINSPIREMetadataIRv2_20070202 Language EN Relation Not applicable Coverage Project duration Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 2 of 104 TABLE OF CONTENTS Foreword ................................................................................................................................6 The Directive’s Requirements for Metadata.........................................................................7 The Broader Context..............................................................................................................8 Purpose of the document....................................................................................................10 1 Scope.............................................................................................................................11 2 Normative references ...................................................................................................12 3 Terms and definitions...................................................................................................13 3.1.1 catalogue..........................................................................................................13 3.1.2 coverage...........................................................................................................13 3.1.3 data ..................................................................................................................13 3.1.4 datasets............................................................................................................13 3.1.5 dataset series ...................................................................................................13 3.1.6 e-Government...................................................................................................13 3.1.7 feature ..............................................................................................................13 3.1.8 feature attribute.................................................................................................13 3.1.9 gazetteer service ..............................................................................................14 3.1.10 geographic identifier .........................................................................................14 3.1.11 geometric primitive............................................................................................14 3.1.12 lineage..............................................................................................................14 3.1.13 metadata...........................................................................................................14 3.1.14 metadata element.............................................................................................14 3.1.15 metadata entity .................................................................................................14 3.1.16 metadata for discovery .....................................................................................14 3.1.17 metadata for evaluation ....................................................................................14 3.1.18 metadata for use...............................................................................................15 3.1.19 portrayal............................................................................................................15 3.1.20 product specification.........................................................................................15 3.1.21 profile................................................................................................................15 3.1.22 quality ...............................................................................................................15 3.1.23 register..............................................................................................................15 3.1.24 registry..............................................................................................................15 3.1.25 resource............................................................................................................15 3.1.26 service ..............................................................................................................15 3.1.27 spatial data .......................................................................................................16 3.1.28 spatial resource ................................................................................................16 3.1.29 validity...............................................................................................................16 3.2 Abbreviations...........................................................................................................16 4 Vision on Metadata .......................................................................................................17 4.1 Metadata in few words.............................................................................................17 4.2 Why create metadata?.............................................................................................18 4.3 A standards based approach ...................................................................................18 4.4 Type of resources ....................................................................................................20 4.5 The INSPIRE Communities .....................................................................................20 4.5.1 Thematic scope ................................................................................................20 4.5.2 Parties ..............................................................................................................20 4.5.3 Link with other communities..............................................................................21 4.6 The INSPIRE Metadata Use Case...........................................................................21 4.7 Use case for temporal search and discovery ...........................................................23 4.7.1 Requirements for temporal metadata................................................................23 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 3 of 104 4.7.2 Temporal searches...........................................................................................24 4.7.3 Temporal user queries......................................................................................24 4.7.4 Distinguishing repositories by temporal metadata.............................................25 4.8 The INSPIRE Metadata ...........................................................................................26 5 Implementing Rules for Discovery ..............................................................................27 5.1 Introduction..............................................................................................................27 5.2 Discovery metadata elements..................................................................................29 5.2.1 Resource title....................................................................................................29 5.2.2 Temporal reference ..........................................................................................29 5.2.3 Geographic extent of the resource....................................................................30 5.2.4 Resource language...........................................................................................30 5.2.5 Resource topic category ...................................................................................30 5.2.6 Keyword............................................................................................................30 5.2.7 Service type......................................................................................................30 5.2.8 Resource responsible party ..............................................................................30 5.2.9 Abstract ............................................................................................................31 5.2.10 Resource locator...............................................................................................31 5.2.11 Constraint .........................................................................................................31 5.2.12 Lineage.............................................................................................................31 5.2.13 Service type version .........................................................................................31 5.2.14 Operation name................................................................................................32 5.2.15 Distributed computing platform .........................................................................32 5.2.16 Resource identifier............................................................................................32 5.2.17 Spatial resolution ..............................................................................................32 5.2.18 Conformity ........................................................................................................32 5.3 Basic Requirements.................................................................................................32 5.3.1 Notation ............................................................................................................32 5.3.2 Abstract discovery metadata element set – Discovery level - 1 ........................33 5.3.3 Abstract discovery metadata element set – Discovery level - 2 ........................33 5.3.4 Implementation instructions of the abstract discovery set .................................34 6 General Implementing Rules........................................................................................37 6.1 Metadata on metadata.............................................................................................37 6.1.1 Motivation of the abstract metadata on metadata set........................................37 6.1.2 Abstract metadata on metadata set .................................................................37 6.1.3 Implementation instructions of the abstract metadata on metadata set.............37 6.2 Identifiers .................................................................................................................38 6.3 Granularity ...............................................................................................................39 7 Implementing Rules for Evaluation .............................................................................41 8 Implementing Rules for Use.........................................................................................42 Annex A ISO 19115 / ISO 19119 implementation ........................................................43 A.1 INSPIRE Discovery Metadata ISO 19139 Encoding Template ................................43 A.1.1 Introduction.......................................................................................................43 A.1.2 Resource MetadataSet .....................................................................................44 A.2 Abstract discovery metadata element set – Discovery level - 1 ...............................47 A.2.1 Resource title....................................................................................................47 A.2.2 Temporal Reference.........................................................................................47 A.2.3 Geographic extent of the resource....................................................................49 A.2.4 Resource language...........................................................................................50 A.2.5 Resource topic category ...................................................................................51 A.2.6 Keyword............................................................................................................52 A.2.7 Service type......................................................................................................52 A.2.8 Resource responsible party ..............................................................................53 A.2.9 Abstract ............................................................................................................54 A.2.10 Resource locator ..........................................................................................54 A.3 Abstract discovery metadata element set – Discovery level - 2 ...............................55 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 4 of 104 A.3.1 Constraints .......................................................................................................55 A.3.2 Lineage.............................................................................................................55 A.3.3 Conformity ........................................................................................................56 A.3.4 Service type version .........................................................................................56 A.3.5 Operation name................................................................................................56 A.3.6 Distributed computing platform .........................................................................57 A.3.7 Resource Identifier............................................................................................57 A.3.8 Spatial resolution ..............................................................................................57 A.4 Metadata on metadata.............................................................................................58 A.4.1 Metadata point of contact..................................................................................58 A.4.2 Metadata date stamp........................................................................................59 A.4.3 Metadata language...........................................................................................59 Annex B Dublin Core implementation of discovery level-1 .......................................60 B.1 Resource title..........................................................................................................60 B.2 Reference date .......................................................................................................60 B.2.1 Extent - temporal extent...................................................................................60 B.2.2 Date.................................................................................................................60 B.2.3 Date – publication............................................................................................61 B.2.4 Date – revision.................................................................................................61 B.2.5 Date – creation ................................................................................................61 B.3 Geographic extent of the resource..........................................................................62 B.4 Resource language.................................................................................................63 B.5 Resource topic category .........................................................................................63 B.6 Keyword..................................................................................................................64 B.7 Service type............................................................................................................64 B.8 Resource responsible party ....................................................................................64 B.9 Abstract ..................................................................................................................65 B.10 Resource locator...............................................................................................65 Annex C Comparison of INSPIRE directive requirements and corresponding abstract discovery metadata set.........................................................................................67 Annex D Applicability of the available standards.......................................................68 D.1 Introduction.............................................................................................................68 D.2 Conceptual Spatial Standards.................................................................................68 D.2.1 Conceptual metadata standards for spatial resources ....................................68 D.2.2 Conceptual Spatial foundation standards ........................................................69 D.2.3 Complementary Conceptual Spatial standards ................................................69 D.3 Metadata applications.............................................................................................70 D.3.1 Interchange models .........................................................................................70 D.3.2 Data Structure Application schema..................................................................70 D.3.3 Data Content Application schema....................................................................72 D.4 The Implementation Standards...............................................................................72 D.4.1 Overview..........................................................................................................72 D.4.2 Standard encoding...........................................................................................72 D.4.3 Standard service specifications .......................................................................73 D.5 Other applicable standards .....................................................................................73 D.5.1 Dublin Core......................................................................................................73 D.5.2 Other ISO standards........................................................................................73 Annex E Mapping of the INSPIRE spatial data themes to code list B.5.27 of ISO 19115 74 Annex F The conformity of spatial resources with the implementing rules referred to in Article 7(1); (Art. 5-2 (a) and Art. 11-2 (d))..................................................................76 Annex G Quality and validity of spatial resources; (Art. 5-2 (c)) ...............................77 Annex H Guidelines for ISO/TS 19139 Metadata - Implementation specification.....82 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 5 of 104 H.1 From the conceptual schema to XML File instances................................................82 H.2 Polymorphism..........................................................................................................82 H.3 Management of polymorphism.................................................................................82 H.3.1 Management of community extensions.............................................................82 H.3.2 Parsing of metadata files ..................................................................................82 H.4 Management of by reference containment...............................................................83 H.5 ISO 19139 and multilingual metadata ......................................................................83 H.5.1 The default language ........................................................................................84 H.5.2 Alternate languages..........................................................................................84 H.5.3 Embedded translations .....................................................................................84 H.5.4 Use of translation files ......................................................................................84 H.6 Contexts of use........................................................................................................84 H.6.1 Use of ISO 19139 in the context of a Catalogue Service ..................................84 H.6.2 Use of ISO 19139 in the context of the standard interchange by transfer .........84 H.7 Character encoding..................................................................................................84 H.8 Temporal extent encoding .......................................................................................84 H.9 Spatial resolution encoding......................................................................................84 H.10 Example of ISO 19139 XML Metadata Sets......................................................84 H.10.1 Service metadata instance ..................................................................................84 H.10.2 Dataset metadata instance..................................................................................84 Annex I Guidelines for Catalogue implementation ...................................................84 I.1 Full text search...........................................................................................................84 Annex J Conformance with IR on Metadata ...............................................................84 Annex K Bibliography...................................................................................................84 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 6 of 104 Foreword INSPIRE is a Directive providing general rules for the establishment of an Infrastructure for Spatial Information in Europe. The purpose of such an infrastructure is to assist policy-making in relation to policies that may have a direct o indirect impact on the environment. INSPIRE should be based on the infrastructures for spatial information that are created by the Member States and are designed to ensure that spatial data are stored, made available and maintained at the most appropriate level; that it is possible to combine spatial data from different sources across the Community in a consistent way and share them between several users and applications; that it is possible for spatial data collected at one level of public authority to be shared between other public authorities; that spatial data are made available under conditions which do not unduly restrict their extensive use; that it is easy to discover available spatial data, to evaluate their suitability for the purpose and to know the conditions applicable to their use. For these reasons, the Directive focuses in particular on five key 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 and technologies; measures on sharing spatial data and services; coordination and monitoring measures. The text of the INSPIRE Directive agreed by Parliament and Council is available from the INSPIRE web site (www.ec-gis.org/inspire). The Directive, which is expected to be adopted in February 2007, identifies what needs to be achieved, and Member States have two years from the date of adoption to bring into force national legislation, regulations, and administrative procedures that define how the agreed objectives will be met taking into account the specific situation of each Member State. To ensure that the spatial data infrastructures of the Member States are compatible and usable in a Community and transboundary context, the Directive requires that common Implementing Rules (IR)are adopted in a number of specific areas. These IRs are adopted as Commission Decisions, and are binding in their entirety. The Commission is assisted in the process of adopting such rules by a regulatory committee composed by representatives of the Member States and chaired by a representative of the Commission (this is known as the Comitology procedure). The committee will be established within three months from the entry in force of the Directive. IRs on metadata need to be adopted within one year of the entry in force of the Directive, i.e. by early March 2008. The Commission will make a proposal to the committee, which has three months to deliver its opinion. If the committee agrees with the proposal, the IR is adopted. If the committee does not agree, or does not deliver an opinion, then the Commission needs to submit the proposal to the Council and inform the European Parliament. If Parliament considers that the proposal submitted by the Commission exceeds the implementing powers provided for by the INSPIRE Directive, it informs the Council of its position. The Council votes by qualified majority on the proposal. If the Council agrees with the proposal or does not indicate opposition, the IR is adopted by the Commission. If the Council opposes the measure, the Commission will have to submit a revised proposal1 . In order to prepare the Commission proposal, an international team of experts has been working since October 2005 to review available reference material and international standards to come to a draft proposal fulfilling the requirements of the Directive. This document presents this draft. The next three sections review the requirements as set in the Directive, explain the broader context within which the drafting team has operated, and define the scope of this document respectively. 1 A precise explanation of the regulatory procedure to be used for the IR on metadata and monitoring measures is contained in Article 5 of Council Decision 1999/468/EC, amended by Decision 2006/512EC of the 17 July 2006. IR for the interoperability and harmonisation of spatial data sets and services, network services, and data sharing need to follow the regulatory procedure with scrutiny detailed in Art. 5a of the same Council Decision. See: http://eur-lex.europa.eu/LexUriServ/site/en/consleg/1999/D/01999D0468-20060723-en.pdf Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 7 of 104 The Directive’s Requirements for Metadata The general principle informing the need for metadata is expressed in Paragraph (6) of the Directive’s preamble, i.e. that the “infrastructures for spatial information in the Member States should be designed to ensure that [….] it is easy to discover available spatial data, to evaluate their suitability for the purpose and to know the conditions applicable to their use”. Metadata is defined in Art. 3, point (6) as: “information describing spatial data sets and spatial data services and making it possible to discover, inventory and use them.” Art. 5 is dedicated to Metadata and requires the following: 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. 2.Metadata shall include information on the following: (a) the conformity of spatial data sets with the implementing rules provided for in Article 7(1); (b) conditions applying to access to, and use of, spatial data sets and services and, where applicable, corresponding fees; (c) the quality and validity of spatial data sets; (d) the public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services; (e) limitations on public access and the reasons for such limitations, in accordance with Article 13. 3.Member States shall take the necessary measures to ensure that metadata are complete and of a quality sufficient to fulfil the purpose set out in point (6) of Article 3. 4. Rules for the implementation of this Article shall be adopted by one year following the date of entry into force of this Directive in accordance with the regulatory procedure referred to in Article 22(2). These rules shall take account of relevant, existing international standards and user requirements, in particular with relation to validation metadata. The timetable for the creation of metadata is set out in Art. 6, and indicate that metadata for the data themes in Annexes I and II of the Directive should be created no later than 2 years following the adoption of the IRs (i.e. by March 2010) and for Annex III no later than 5 years following the adoption of the IR (i.e. March 2013). Additional requirements for Metadata come in Art. 11-1 (a) and 11-2 in which Member States are required to establish and operate discovery services making it possible to search for spatial data sets and services on the basis of the corresponding metadata, and to display the content of such metadata, based at a minimum on the following criteria: (a) keywords; (b) classification of spatial data and services; (c) the quality and validity of spatial data sets; (d) degree of conformity with the implementing rules provided for in Article 7(1); (e) geographical location; (f) conditions applying to the access to and use of spatial data sets and services; (g) the public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services. Separate IRs for discovery services are being prepared and are not the subject of this document. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 8 of 104 The Broader Context The implementation of INSPIRE should not be undertaken in isolation but should consider both international global initiatives such as GMES, Galileo and GEO to which many EU Member State institutions participate, and the harmonisation efforts ongoing at national level and across several thematic communities. With this in mind, the INSPIRE Work-programme 2005-06 introduced the concept of Spatial Data Interest Communities (SDICs) and Legally Mandated Organisations (LMOs) to provides a mechanism for stakeholders to participate in the development of the draft Implementing Rules. The Work Programme identified SDICs as self-organised communities bringing together the human expertise, technical competence, financial resources and policies of users, producers and transformers of spatial information organized by geographic region, societal sector or thematic issue. LMO represent instead those organizations at local, regional, national, or international level that have a formal legal mandate giving them the responsibility for specific thematic data resources. An open call was launched on March 11th 2005 for the registration of interest SDICs and LMOs. The roles of these organizations are: • to identify and describe user requirements; • to provide expertise to INSPIRE Drafting Teams; • to participate in the review process of the draft Implementing Rules; • to develop, operate and evaluate implementation pilot; • to develop initiatives for guidance, awareness raising and training in relation with the INSPIRE implementation. The call was enormously successful, and by the 29th April 2005, the following had registered on the INSPIRE web site2 : • Spatial Data Interest Communities (SDICs): 133 • Legally Mandate Organisations (LMOs): 82 • Proposed Experts: 180 • Referenced Materials: 90 • Identified Projects: 91 Drafting Teams were established on the basis of the proposal received, and the advice of the INSPIRE Expert Group, and started operating in October 2005. Their terms of reference are: • To analyse and review the reference material provided by the SDICs; • To demand further input from SDICs if required; • To write the draft INSPIRE Implementing Rules; • To provide recommendations to the Commission in case of conflicting technical specifications or issues; • To provide suggestions to the Commission regarding the testing of any proposed technical specifications. This document is a first public draft from the Drafting Team Metadata in writing the Implementing rules. By the realisation of this document the Drafting team has used the following information/projects: • Requirements for metadata for spatial resources (data and services) as expressed in the INSPIRE Directive (see previous section). • Metadata reference material from the SDICs and LMOs (Deliverable 1.2: Analysis of Reference Documentation, available on the INSPIRE web site) • Experience from the JRC Tender: Supply of software for distributed Metadata Catalogue services to support the EU Portal (period: February – May 2006) • Knowledge and reference material from the Drafting Team members • Exchange of information between the different Drafting Teams and the European Commission. 2 The call for registration remains open, and more organisations have registred since April 2005. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 9 of 104 This document represents the contribution of the Metadata Drafting Team. The document is organized into 7 chapters and 10 annexes. Chapters 1 to 3 set the scope of the document, list normative references and provide a glossary of relevant terms. Chapter 4 outlines the underlying vision on metadata. In accordance with the INSPIRE Directive, three different types or levels of metadata are distinguished: metadata for discovery, metadata for evaluation, and metadata for use. In addition, metadata on metadata are needed for the management of metadata catalogues. Chapter 5 specifies concrete implementing rules for metadata for discovery. They are followed by general implementing rules for metadata on metadata in chapter 6. Abstract implementing rules for evaluation-metadata and usemetadata are provided in chapters 7 and 8. Among others, the annexes provide a mapping between discovery-level metadata and the relevant international standards (ISO 15836-Dublin Core and ISO 19115/19119). The document is open for the review process described in Section: “Purpose of the Document”. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 10 of 104 Purpose of the document This document contains the Metadata Drafting Team's proposal for the technical content of the INSPIRE draft Implementing Rules for Metadata. A preliminary version of this draft (version 1) has already been revised in the light of comments from the other INSPIRE drafting teams, and the Commission. This draft (Version 2.) is published on the INSPIRE web site on 2nd February 2007 for public view, but comments are restricted at this stage to registred SDICs and LMOs, through their contact person, and the INSPIRE Expert Group. The individuals concerned have been notified of the procedure to comment on this draft. The period to provide comments is set at 8 weeks form the day of publication i.e. 2007-03-30. After the comments have been received and processed, a revised draft (Version 3) will be published on the INSPIRE web site by Summer 2007 for public consultation. There will be 8 weeks for anybody to comment following the procedure that will be published at the time. At the end of the phase of public consultation, the Commission will elaborate its proposal and submit it to the committee required by the Directive, and enter the process explained in the Foreword of this document. The document will be publicly available as a ‘non-paper’, as it does not represent an official position of the Commission, and as such can not be invoked in the context of legal procedures. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 11 of 104 1 Scope The scope of this document is the technical content of the Metadata Implementing Rules (IRs) that will detail the INSPIRE legislative requirements for metadata so that these can be implemented consistently across Europe. This document focuses on the semantic description of the metadata elements to describe spatial resources. The elements are described at an abstract level in order to make the IRs independent of any specific encoding or of any possible future changes to existing standards. The starting point is the text for the INSPIRE Directive agreed by Parliament and Council and published on the INSPIRE web site. The specific requirements for metadata have also been reported in a previous section of this document. These IRs apply to spatial resources (i.e. datasets, dataset series and services), and may be applicable to other resource types. The Metadata IRs are applicable to the functional concepts of discovery, evaluation and use. They define the minimum requirements and give a long term vision. The metadata for discovery include a minimum common denominator and the cross-walks between this minimum common denominator and the metadata sets in use by different communities. The Metadata IRs are based on the following principles: they are in conformance with European and international standards, current practices in stakeholder communities and relevant European eGovernment initiatives like the European Interoperability Framework for pan-European eGovernment services (http://europa.eu.int/idabc/en/document/2319/5644 ). In formulating the IRs, due regard is given to protecting existing investments and to minimizing costs. This document defines the necessary conditions for maintaining and updating metadata on an abstract level. Logical units are defined for coherent implementation of necessary elements for metadata management (see section 4.6). The Metadata IRs describe actions and material which are the basis needed to provide the requested metadata and to guarantee the consistent use over various physical implementations. An abstract test suite for conformance to the IRs is described in Annex J. The transfer to local conditions needed for implementation is the responsibility of the relevant authorities and is not in the scope of the Metadata IRs. So this document does not: a. prescribe to custodians of metadata how to manage metadata for spatial resources b. prescribe encoding for metadata c. define machine-readable metadata for services d. define any responsible organisation for maintaining and updating of guidelines, code lists or other material. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 12 of 104 2 Normative references These Implementation Rules (IRs) incorporate by dated or undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to these IRs only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies (including amendments). ISO 639-2:1998, Codes for the representation of names of languages - Part 2: Alpha-3 code ISO/IEC 2382-1:1993,Information technology – Vocabulary – Part 1: Fundamental terms ISO 8601:2000, Data elements and interchange formats - Information interchange Representation of dates and times ISO 15836: 2003, Information and documentation – The Dublin Core metadata element set ISO 19101: 2002, Geographic information – Reference model ISO/TS 19103:2005, Geographic information – Conceptual Schema Language ISO 19106:2004, Geographic information - Profiles ISO 19107:2003, Geographic information – Spatial Schema ISO 19108:2002, Geographic information – Temporal Schema ISO 19109:2005, Geographic information – Rules for application schema ISO 19110:2005, Geographic information – Methodology for feature cataloguing ISO 19111:2003, Geographic information – Spatial Referencing by coordinates ISO 19112:2003, Geographic information – Spatial Referencing by geographic identifiers ISO 19113:2002, Geographic information – Quality principles ISO 19114:2003, Geographic information – Quality evaluation procedures ISO 19115:2003, Geographic information - Metadata ISO 19115/Cor.1:2006, Geographic information – Metadata, Technical Corrigendum 1 ISO 19117:2005, Geographic information – Portrayal ISO 19119:2005, Geographic information - Services ISO 19119:2005 PDAM 1, Geographic information – Services ISO/CD2 19130, Geographic information – Sensor data model for imagery and gridded data, ISO/TC 211 N 1772 dated 2005-02-15 ISO/DIS 19131, Geographic information – Data product specification ISO 19135:2005, Geographic information – Procedures for item registration ISO/TS 19139:2006, Geographic information - Metadata - Implementation specification CSW 2.0.1, OpenGIS® Catalogue Services Specification 2.0.1, OGC, 2005 CSW2 AP ISO, ISO Metadata Application Profile of CS-W, Version 1.0, OGC, 2005 GSDI Cookbook, Developing Spatial Data Infrastructures, The SDI Cookbook, Version 2.0, 25 January 2004 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 13 of 104 3 Terms and definitions 3.1.1 catalogue A complete list of items arranged in alphabetical or other systematic order [Compact OED] Note 1: A catalogue is not significantly different from a register. 3.1.2 coverage Feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatio-temporal domain [ISO19123] Example: Examples include a raster image, polygon overlay or a digital elevation. Note: a coverage is a feature that has multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type. 3.1.3 data Reinterpretable representation of information in a formalised manner suitable for communication, interpretation, or processing (ISO/IEC 2382-1). Note: Data can be any form of information whether on paper or in electronic form. Data may refer to any electronic file no matter what the format: e.g. a database or binary data, text, images. Everything read and written by a computer can be considered data except for instructions in a program that are executed (software). 3.1.4 datasets Identifiable collection of data (ISO 19101). Note: A dataset may be a smaller grouping of data which, though limited by some constraint such as spatial extent or feature type, is located physically within a larger dataset. Theoretically, a dataset may be as small as a single feature or feature attribute contained within a larger dataset. A hardcopy map or chart may be considered a dataset. 3.1.5 dataset series Collection of datasets sharing the same product specification (ISO 19115). 3.1.6 e-Government Application of information and communication technology to enhance the effectiveness of a legislature, judiciary or administration, either to improve efficiency or to change the relationship between citizen and government, or both. [6] 3.1.7 feature Abstraction of real world phenomena. A feature may occur as a type or an instance. [ISO19101] 3.1.8 feature attribute Characteristic of a feature [ISO19101] Example 1: A feature attribute named “colour” may have an attribute value “green” which belongs to the data type “text”. Example 2: A feature attribute named “length” may have an attribute value “82.4” which belongs to the data type “real”. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 14 of 104 Note 1: “attribute” has many different meanings in different computer modelling contexts. In relational models; in XML; in UML and in network modelling attribute is interpreted in very specific and different ways. Even with feature attributes, the distinction between feature subtypes and feature attributes can be slight. 3.1.9 gazetteer service Functionality that provides a controlled vocabulary of place names and references the associated geographic locations as points, bounding boxes, or polygons, expressed as spatial coordinates. 3.1.10 geographic identifier Spatial reference in the form of a label or code that identifies a location (ISO 19112). Example: 'Spain' is an example of a country name, 'SW1P 3AD' is an example of a postcode. 3.1.11 geometric primitive Geometric object representing a single, connected, homogeneous element of space (ISO 19107). 3.1.12 lineage History of a dataset, and the life cycle from collection and acquisition through compilation and derivation to its current form [from ISO19101] 3.1.13 metadata Information describing spatial resources, making it possible to discover, inventory and use them3 . 3.1.14 metadata element Discrete unit of metadata (ISO 19115). Metadata elements are unique within a metadata entity. 3.1.15 metadata entity Set of metadata elements describing the same aspect of data (ISO 19115) 3.1.16 metadata for discovery The minimum amount of information that needs to be provided to convey to the inquirer the nature and content of the data resources. Note: The above definition falls into broad categories which answer the ”what, why, when, who, where and how” questions about spatial resources . 3.1.17 metadata for evaluation4 The amount of information sufficient to enable an inquirer to ascertain that a spatial resource fit for a given purpose exists, to evaluate its properties, and to reference some point of contact for more information (adapted from GSDI Cookbook). Note: metadata include those properties required to allow the prospective end user to know whether the spatial resource will meet the general requirements for a given purpose. 3 This definition of metadata originates from the directive. It is compatible with the general definition of metadata provided in ISO 19115 and the OGC abstract specification for metadata: “data about data”. It clarifies the expected role of metadata within the INSPIRE Infrastructure 4 In the directive the term inventory is used. However, in the geographic information community the term evaluation is used for the concept described by inventory. An authoritative description of the concept can be found in the GSDI Cookbook. Moreover, the Directive refers to evaluation in its Preamble, Para (6). Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 15 of 104 3.1.18 metadata for use Information required to access, transfer, load, interpret, and apply a spatial resource in the end application where it is exploited (adapted from GSDI Cookbook). Note: This class of metadata often includes the details of a data dictionary, the data organisation or schema, projection and geometric characteristics, and other parameters that are useful to human and machine in the proper use of spatial resources. 3.1.19 portrayal Presentation of information to humans (ISO 19117). 3.1.20 product specification Detailed description of a spatial resource of type dataset or dataset series together with additional information that will enable it to be created, supplied to and used by another party (adapted ISO 19131). 3.1.21 profile Set of one or more base standards or subsets of base standards, and, where applicable, the identification of chosen clauses, classes, options and parameters of those base standards, that are necessary for accomplishing a particular function (ISO 19106). 3.1.22 quality Totality of characteristics of a product that bear on its ability to satisfy stated and implied needs [ISO 19101]. The degree of excellence of something as measured against other similar things [Compact OED] 3.1.23 register Set of files containing identifiers assigned to items with descriptions of the associated items (ISO 19135). 3.1.24 registry Information system on which a register is maintained (ISO 19135). 3.1.25 resource Asset or means that fulfils a requirement. Example: dataset, service, document, person or organization. 3.1.26 service Distinct part of the functionality that is provided by an entity through interfaces (ISO 19119). In computing terms, a service is an application that provides information and/or functionality to other applications. Services are typically non-human-interactive applications that run on servers and interact with applications via an interface (from Microsoft) Note 1: This distinct part of the functionality is a computation performed on one side of an interface in response to a request made on the other side of the interface. Note 2: Services can provide things like WMS (a picture of a map), WFS (GML) and WCS (an image). Then there are services where a user supplies a coordinate and the service transforms it to another coordinate, or a user supplies an image and the service transforms or Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 16 of 104 performs image processing. These are all something that can be read and written by the computer and are in accord with the note in data. Note 3: Some services may be off-line, where data may be on off-line media. 3.1.27 spatial data Any data with a direct or indirect reference to a specific location or geographic area. 3.1.28 spatial resource Asset or means that fulfils a requirement and has a direct or indirect reference to a specific location or geographic area. Example: dataset, dataset series, service. 3.1.29 validity Validity may be related to the range of space and time that is pertinent to the data; to whether the data has been checked to a measurement or performance standard or to what extent the data is fit for purpose. 3.2 Abbreviations CEN Comité Européen de Normalisation CEN TC287 CEN Technical Committee 287 Geographic Information CSW OGC Catalog Service Web DCP Distributed Computing Platform EU European Union FGDC Federal Geographic Data Committee Galileo EU Satellite Navigation System GMES Global Monitoring for Environment and Security GEO United Nation’s Global Environment Outlook GML Geography Markup Language GSDI Global Spatial Data Infrastructure IRs Implementing Rules ISO International Standardization Organisation ISO/IEC ISO/International Electrotechnical Commission ISO/TC211 ISO Technical Committee 211 Geographic information/Geomatics JRC European Commission Directorate General Joint Research Centre LMO Legally Mandate Organisations OED Oxford English Dictionary OGC Open Geospatial Consortium OSF Open Software Foundation PSI Public Sector Information SDIC Spatial Data Interest Communities WCS Web Coverage Server WFS Web Feature Server WMS Web Map Server UML Unified Modelling Language URI Uniform Resource Identifier URL Uniform Resource Locator UUID Universally Unique IDentifier XML eXtensible Markup Language Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 17 of 104 4 Vision on Metadata 4.1 Metadata in few words ISO 19115 defines metadata as “data about data”. This basic definition implies an unlimited scope to what can be seen as metadata. It allows some experts to see information as data or metadata with an unrealistic border between both5 . The INSPIRE Directive clarifies the definition of metadata as information describing spatial resources, making it possible to discover, inventory, and use them. These Implementing Rules detail the definition of metadata and its expected role within in the INSPIRE Infrastructure. These Implementing Rules are applicable to spatial- and, to a certain extent, non-spatial resources (as described in section 4.4). The metadata for those resources comprise: - Identification information, i.e. information to uniquely identify the resource such as: - Title, abstract, reference dates, version, purpose, responsible parties, … - Data extent, - Browse graphics (overview, thumbnail, …), - Possible usage; - Legal and security constraints; - Content Description, i.e. information identifying the feature catalogue(s) used and/or information about the coverage content; - Reference system information, i.e. identification of the spatial and temporal system(s) used in the resource data; - Spatial Representation, i.e. information concerning the mechanisms used to represent spatially the resource data; - Quality and validity information6 , i.e. a general assessment of the quality of the resource data including: - quality measures related to the geometric, temporal and semantic accuracy, the completeness or the logical consistency of the data; - lineage information including the description of the sources and processes applied to the sources; 5 Some metadata, such as the results of quality evaluation may comprise real data and possibly spatial data, for example when the result of the evaluation is expressed as a spatial coverage. 6 The DT Metadata has taken quality for services in consideration although it is not mentioned in the Directive. For the following reasons it is not part of the implementing rules. Services, including web services, are routinely measured in terms of availability and performance. These parameters are easily quantified and users can easily agree on their value: services that are available more often (seeking the elusive 99.9% "up-time") are more desirable than services that are available less often, and services that provide faster response time are more desirable than similar services that are slower to respond. Similar to the case of testing the top speed of a CPU or a car, web services tests must be highly controlled. A car will not have the same top speed when overloaded, running uphill, against the wind, or in snow. In the same sense a given web service is normally affected by a wide range of external forces: network latency, software configurations, protocols used, etc. that need to be held constant and controlled. Given all the possible external influences it is not advisable to state that a certain web service is fast, or has high availability in general: the whole configuration needs to be tested in each unique situation. Despite those warnings, availability and performance parameters are quite objective, however the notion of quality quickly becomes subjective in nature, when we define quality as "fitness for use". The answer to the question "Is this service useful?" will often elicit the response, "It depends; useful for what purpose, and for which user?". Attempts to objectively rate (and publish in metadata) the "usefulness" of a service, such as that it produces correct responses or behaviours, will almost certainly create problems among service vendors, and would likely do more harm than good to consumers. Most other markets rely on informal user feedback as the ultimate test as to whether or not a product or service is useful, a good value, etc. This feedback appears spontaneously in news and mail forums, in the popular press, and by word-of-mouth. Service metadata should probably focus on objective aspects, and not attempt to document fitness for use. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 18 of 104 - validity information related to the range of space and time pertinent to the data; to whether the data has been checked to a measurement or performance standard or to what extent the data is fit for purpose. - Portrayal information, i.e. information identifying the portrayal catalogue used; - Distribution information, i.e. information about the distributor of, and options for obtaining the resource; - Maintenance information, i.e. information about the scope and frequency of updating of the resource data. A general use case described in section 4.6 defines the three major activities involving metadata: discovery, evaluation and use. A prerequisite is effectively the establishment and maintenance of metadata, i.e. the overall management of the metadata resources. The IRs do not regulate the way the metadata resources have to be managed, but the metadata resources concerned by the Directive have to be inventoried and the corresponding metadata have to be managed for the satisfaction of the users through the three main activities involving metadata. 4.2 Why create metadata? Any organisation providing information should provide some way that a non-specialised user can discover, evaluate and use that information. This may be done by providing buttons, menus, or navigational structures on a web site or by providing free-text search capabilities. However, simply searching for words or phrases in the contents resources is a hit-or-miss strategy. When the spatial resource of interest has some word or phrase uniquely associated with it, this can be quite successful; but in other cases, hundreds or thousands of irrelevant “hits” may be returned, as anyone can confirm who has spent frustrating hours searching for something whose name is a common word. An alternative is to use metadata to describe resources in terms of certain well-defined attributes, such as resource title, geographic extent of the resource, resource topic category, or keywords. This allows users to search for keywords, names and phrases in particular contexts or structured search. For example, an organisation’s name might be defined as a responsible party or as the distributor of a spatial dataset, in contrast to having no such information or being one of the many organisations that are described in a document linked to the spatial dataset. If this capability is combined with the use of “controlled vocabularies” (i.e. standardised lists of terms, such as abbreviations for countries or code lists for categories) and standardised formats for values such as dates or longitude/latitude, it can greatly improve the efficiency of discovery. For example, if all spatial resources are assigned metadata such as a resource topic category, it becomes much easier for a user to find resources that match a query for a specific topic. From the perspective of a government organisation, it is important to help users obtain accurate and appropriate information: if users suffer some kind of loss as a result of finding incorrect or inappropriate information, they will make wrong decisions. In order to improve the discovery, evaluation and use of government information throughout the EU Member States, the metadata created to describe resources at different websites and by different organizations must share a common form and meaning, so that users do not have to learn a different set of terms and search strategies for each site they visit. Such “interoperability” is especially important for users who need to combine or compare information from multiple resources, but it is useful for any user attempting to discover information provided by government. 4.3 A standards based approach The Metadata IRs have been defined at an abstract level, but the approach is based on existing standards. Many factors encourage the adoption of a standards based approach. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 19 of 104 Very detailed information on this topic is provided in the GSDI Cookbook, but the following information is more particularly applicable to the INSPIRE context: 1. The importance of using a dedicated metadata standard to support the implementation of a Global Spatial Data Infrastructure has been demonstrated by the different initiatives conducted since the early 90’s particularly in: - North America with the development of the Content Standard for Geospatial Metadata by the US Federal Geographic Data Committee (FGDC) and the Presidential Executive order that all Federal government agencies were required to produce metadata for their spatial data holdings, - Europe with the experimentation of ENV 12657 [5] and more recently with the emergence of national and sub-national Spatial Data Infrastructures and their increasing adoption of ISO 19115. 2. More than the lack of metadata, the lack of compatibility between the existing and upcoming metadata solutions is certainly one of the greatest challenges of the INSPIRE Directive. At this stage and due to the importance of the community, the use of a standard lexicon is a key to success. 3. The standardisation activity in this area has reached level of maturity. A metadata standard dedicated to Geographic Information is available with the publication of ISO 19115. Its applicability to the European context was established with its adoption by CEN in 2005. The reference materials provided by the INSPIRE community for the establishment of these IRs show a general endorsement of this international standard by the different European actors of the geographic information domain. Most of the Legally Mandated Organisations and SDIC have already adopted ISO 19115 or have on-going activities to adopt it as indicated by the results of the INSPIRE survey conducted in Spring 2006.7 The importance of standards is also stressed within the preamble of the INSPIRE Directive: In order to benefit from the state of the art and actual experience of information infrastructures, it is appropriate that the measures necessary for the implementation of this Directive should be supported by international standards and standards adopted by European standardisation bodies in accordance with the procedure laid down in Directive 98/34/EC of the European Parliament and of the Council of 22 June 1998 laying down a procedure for the provision of information in the field of technical standards and regulations and of rules on Information Society services. (Paragraph 28) Taking the above into account, the fact that the majority of the visited metadata reference material is standards-based, and the global dimension to which INSPIRE is linked (cf. INSPIRE, Preamble, Paragraph 10), the Metadata Drafting Team has decided to follow as much as possible a standards-based approach. The current or future adoption of relevant standards among the INSPIRE SDICs and LMOs illustrates the level of maturity and endorsement that in particular EN ISO 19115 has reached in the domain of geographic information. A standard based approach is certainly the best answer to the High Level Requirements of INSPIRE as it ensures the conformance to the European and International Standards, as well as the current practices in stakeholder communities which already use or consider the use of the emerging metadata standards. The applicability of the available standards is discussed in details in Annex D. The reference metadata standard for spatial resources is based on a set of foundation standards from the ISO 19100 series, e.g. ISO/TS 19103, ISO 19107 and ISO 19108. ISO 19119 extends ISO 19115 for spatial services. The applicable XML Schema Implementation of ISO 19115 is defined in ISO/TS 19139 which expresses encoding rules applicable to ISO 19119. Those standards satisfy fully the requirements for discovery and evaluation of spatial resources, but in term of use 8 , complementary standards from the ISO 19100 series have to be considered, e.g. ISO 19110, ISO 19111, ISO 19117 and others. 7 See http://www.ec-gis.org/inspire/reports/INSPIRE_Metadata_Survey_2006_final.pdf 8 It is recognised that metadata for use may be found most often in practice in formal documentation of individual applications or of data handlers, which may not easily be extended to on-line or web applications. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 20 of 104 Access to on-line metadata repository is fostered by standard interface specifications, such as the OGC CSW 2.0 which can accommodate the use of different abstract metadata standards and related encoding, such as: - ISO 19115 and ISO 19119 through their ISO/TS 19139 XML Schema implementation (CSW2 AP ISO ); - Dublin Core and its XML Implementation which are relevant to ensure the relationship with other communities. 4.4 Type of resources The INSPIRE Directive requires Member States to create and to keep up-to-date metadata for spatial resources, i.e. assets or means related to the earth either by terrestrial coordinates or by geographic identifiers attached to terrestrial coordinates. This version of the IRs does not deal with metadata at the data level (feature, attribute, etc.), but with metadata related to identifiable collections of spatial datasets and to services that may be used to process them. The wide scope of the term “spatial dataset” requires some consideration about dataset granularity (see section 6.3). For this purpose, this version of the IRs also introduce requirements related to “dataset series”, i.e. collection of datasets sharing the same product specification. These IRs can be applied to resources for which they are not mandated. Typically, non spatial datasets may be involved in the management and use of spatial information. Management of non geographic datasets in the context of the INSPIRE directive may be necessary, but in this case, relaxed constraints will be expressed on their metadata. 4.5 The INSPIRE Communities 4.5.1 Thematic scope The thematic scope of the INSPIRE Directive is defined by its Annexes I, II, and III. These annexes consists of more detailed classification of themes than the one published by ISO 19115. For consistency, the INSPIRE themes are mapped to the ISO 19115 topic categories in Annex E. 4.5.2 Parties The INSPIRE community is the aggregation of a set of thematic communities composed of wide range of parties, including: - Resource provider, i.e. a party supplying the resource; - Custodian, i.e. a party that accepts accountability and responsibility for the resources and ensures appropriate care and maintenance of the resource; - Owner, i.e. a party that owns the resource; - User, i.e. a party who uses the resource; - Distributor, i.e. a party who distributes the resource; - Originator, i.e. a party who created the resource; - Point Of Contact, i.e. a party who can be contacted for acquiring knowledge about or acquisition of the resource; - Principal investigator, i.e. a key party responsible for gathering information and conducting research; - Processor, i.e. a party who has processed the data in a manner such that the resource has been modified; - Publisher, i.e. party who published the resource; - Author, i.e. party who authored the resource. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 21 of 104 These responsible parties are identical with the content of a code list (CI_RoleCode) in ISO 19115. All those parties, including the users, may influence the content of the metadata and may consequently appear as such in the metadata. 4.5.3 Link with other communities The INSPIRE community is composed of all the parties involved in the management and use of European spatial resources. However, the users may not be involved directly in the activity related to one of the themes identified in section 4.5.1. These IRs are defined in order to ensure their conformance to the relevant European initiatives such as e-Government, and the EU interoperability framework. In particular, the Directives on the re-use of public sector information (2003/98/EC) and that on public access to environmental information (2003/4/EC) are of first interest because: - most data is collected and managed by public sector organisations; - a spatial public resource is an information resource which has to be inventoried, catalogued and made searchable online; - the cost and effort involved in the inventory, cataloguing and the development of search capabilities is high. It must be done consistently and well, avoiding the duplication of efforts. Of course, any organisation having a stake in one of the INSPIRE themes is concerned by these IRs as a user, independently of the specific role it may play in the management of the resources addressed by the INSPIRE Directive. There is consequently a wide range of potential users of these resources, including some users not specifically interested in spatial data. These IRs accommodate the need to have metadata for spatial resources available and the need for searching spatial resources and browsing their metadata using general search engines and metadata browsers. An initial set, level 1 (see section 5.3.2), of discovery metadata fulfils basic user requirements and is extended to a level 2 (see section 5.3.3) for richer metadata for spatial resources defined in a level 2 of discovery metadata and available for evaluation and use of the spatial resources. The simplicity of the level 1 of discovery metadata is associated with the applicability of general metadata standards such as Dublin Core. 4.6 The INSPIRE Metadata Use Case The INSPIRE Metadata Use Case creates a general context federating the existing and upcoming metadata based solutions around three base user activities: 1. The discovery of resources. The user expects to identify a set of resources satisfying a basic set of search criteria. The user interacts with a Search Engine connected to a set of metadata repositories which document available resources. The Search Engine transfers the search criteria to the metadata repository and expects a minimum set of metadata related to the matching resources. It consolidates the answers and provides them to the user through an adapted interface. 2. The evaluation of available resources. The user has now identified a candidate resource, potentially as a result of the discovery activity and wants to determine whether this resource satisfies his/her requirements or not. For this purpose it may use a Metadata Browser to examine more detailed metadata about the resource. 3. The use of adequate resources. The user has chosen a resource and some access and use rights have been granted to him/her. The resource is accessible and can be used through a series of dedicated tools. Metadata will support the user in fully understanding the data and using it properly resulting in more reliable analysis and more confidence in the results. These three base user activities are modelled in Figure 1. General IRs applicable independently of these three user activities are expressed in chapter 6. The IRs applicable to the discovery, evaluation and use activities are expressed in chapter 5, 6 and 8 respectively. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 22 of 104 user Search Engine Tools Metadata Browser Use Evaluation Discovery Metadata Repository Repository Figure 1 - The INSPIRE Metadata Use Case Different kinds of users may be involved in the different activities: some experts may evaluate the resources while operators may use them. There are cases where the user may be a software program performing automating searches. Depending on the users, different types of Search Engines, Metadata Browsers and Tools may be necessary. From this perspective, this use case does not constraint the software market and it even creates a general context fostering the emergence of new markets and the satisfaction of new user requirements. If the INSPIRE Directive implies that the discovery, evaluation and use activity be enabled online, these IRs, and particularly the use case presented herein is applicable also to the offline interchange of spatial data. The Search Engines, Metadata Browsers and Tools can be local applications acting on a simple transfer dataset stored on a medium (e.g., CD-ROM, DVD, and so on). This use case is based on the existence of a set of repositories. Different types of repositories can be distinguished: - The resource metadata repositories contain information about available resources. The content of a resource repository may be defined using external metadata repositories such as spatial item registers and catalogues. - The registers and catalogues contain information related to spatial information items such as geodetic codes and parameters, units of measure or codelists. More complex spatial resources, such as feature or portrayal catalogues, may be involved as well. - The resource repositories contain the available resources. The content of these repositories need to be accessible. This should happen preferably via a standard interface and/or standard encoding format such as XML. As shown in Figure 2, the hidden side of the INSPIRE Metadata Use Case is the management of those repositories. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 23 of 104 Resource Metadata Repository Register/Catalogue Resource RepositoryMetadata Repository RepositoryManagers Management Tools Management Figure 2 – The hidden side of the INSPIRE Metadata Use Case The management activity is the responsibility of managers, i.e. a wide range of actors involved in the establishment and maintenance of the repositories using Management Tools. This management activity is out of the scope of these IRs. As a consequence, they will not express any constraint concerning the effective content of those repositories, but: - some constraints will be expressed concerning the way this content can be accessed or interchanged; - the INSPIRE Directive expresses a requirement to inventory the existing spatial resources available. The INSPIRE Metadata Use Case is not specifically defined for spatial resources but the different software, interfaces, exchange formats and standards involved in the implementation of the use case activities may be specific depending on the users. The spatial resources are concerned as any other type of public information by the Directive on Public Sector Information (PSI). As defined, the INSPIRE Metadata Use Case meets the inventory, search and access requirements expressed in the PSI Directive whoever the user interested in the available spatial resources is. 4.7 Use case for temporal search and discovery 4.7.1 Requirements for temporal metadata The INSPIRE Directive says nothing about temporal metadata, either as a reference date or for temporal extent. The Directive does say that temporal information should be contained in the content for data specification, where it is important. Geo-information is information about phenomena directly or indirectly related to the Earth. These phenomena occur in a spatial-temporal domain and aggregation of geo-information can occur in both the spatial and temporal dimensions. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 24 of 104 The Directive also includes many themes which can have a temporal nature. In Annex III for Atmospheric conditions and Meteorological and Oceanographic geographic features these themes are fundamentally temporal and the features are mainly events, not locations. The temporal aspects can be more important than spatial. Horizontal spatial scales for these themes are seldom smaller than several kilometres, while time scales of hours (or even minutes and seconds) can be crucial. At the other end of the time scale, Geology is also an INSPIRE Theme in Annex II where time sequence and temporal identification are fundamental. Distinctive properties of temporal information are: • Temporal knowledge may be relative, and either the relative times are more precisely known than absolute times or they cannot be described by a date (e.g. geological eras); • Some temporal reference systems can have a moving reference time, (e.g. weather forecasts are relative to the issue time, and current weather is “now”); • Temporal knowledge may be uncertain, that is, the exact relationship between two times may be not known precisely; • Temporal information may be ordinal, where the periods are in sequence and are named (e.g. spring, summer, autumn, winter) and the transitions may not have specific dates; • The granularity of temporal information may vary significantly (e.g. geological eras vs. the duration of a solar eclipse). 4.7.2 Temporal searches A distinction must be made between temporal information within identification metadata (for search and discovery purposes) and temporal information within data content (for evaluation and use of the data). It is easy to find overriding requirements in environmental data for temporal information. Many themes require temporal content for selection within a chosen data repository which is a requirement for evaluation and use. Temporal metadata are required for use in discovery when the query is essentially temporal, and less importantly, spatial. There are two distinct discovery use cases for temporal extent: where the user query is specifically temporal; and where the data set repositories are distinguished by temporal classification or have temporal rather than spatial organisation. 4.7.3 Temporal user queries Some general user queries might be: • A travel company wishes to search for the January snow climatology for the Alps, for inclusion in a brochure. The full temporal coverage might be the summary statistics of snowfall and snow cover for the period 1971 to 2000 taken over all Januaries. Here the discovery metadata is specific for area and for temporal extent. The classification of temporal extent is and ordinal reference system of named months. • A hydrologist is looking for winter rainfall climatology in a catchment area. Here the ordinal classification of winter may be more important than a specific geographical position, as the hydrologist will expect to generalize to the catchment from whichever specific locations are found. • A geologist may wish to find surface beds of Tertiary minerals across Western Europe. Again the ordinal temporal classification is initially more important than location. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 25 of 104 • A marine investigator requires weather information for a specific period for an accident at sea, the location being only approximately known. • An archaeologist wishes to compare sites across a region which are known to be active in the same time period. The discovery is to find locations for a known period. • Anyone who wants a weather forecast for 3 days hence. For a weather forecast, the sequence of weather is usually more important and may be more accurately forecast than the expected weather at a specific location and time. 4.7.4 Distinguishing repositories by temporal metadata Repositories may be organised by temporal rather than geographic stratification: • It is notable that the INSPIRE themes mentioned above can all have enormous amounts of data extending into the petabyte range. If in the data repository, the data are identified and stored with a temporal organisation, there will be considerable service efficiencies if the search mechanisms reflect this. • Even more important is that many temporally organised repositories may hold data for a wide or global geographic extent, but only a restricted temporal extent. A dataset series may describe a range of specifications. In the life cycle of data, particularly for temporal data, the data may have different use cases at different stages, and the data held and the granularity of the metadata to describe it and the repository itself, may change across the life cycle of data as well as the processing sequence. In meteorological data, data are gathered by the hour and minute, exchanged around the world, and used in weather forecasting immediately. They are stored primarily by time, and only secondly by spatial position. As the data age, they are moved to intermediate caches, and are used for forensic purposes, what actually happened, how accurate were the forecasts etc. As this requirement passes, they are moved to climate datasets, where they are also held as time sequences. The data are normally processed across time classified by month or season, and time averages or extremes tend to be made. The temporal extent metadata will be different and will change character at different stages too. As the data are collected, temporal metadata might be “today” or forecasts for “the next 3 days”. As it transfers to cache it might be for “the last month”. In the archive it will be classified by date and time, but in the climatological summary repository, it will be described by an ordinal temporal reference system, such as “winter” rainfall summaries. These ordinal time periods may refer to times within a general or average year, but not to a specific year. Throughout this process sequence, data will be retained or discarded according to the requirements of the repository. Temporal weather related searches might be: for past climate summaries; for specific past or recent weather; for current weather; for short range forecasts for the next hour or day; for medium term forecasts for the next week; for extended range forecasts for the next month or season; or (at the extreme range) for climate change estimates for the next century. All of these classes of searches are likely to be directed to different reference systems in different repositories. Indeed, few organisations will be able to handle queries for all these classes, and the reference systems will be held across different organisations. On the other hand, spatial queries (even full globe searches) are likely to be possible in any specific reference system holding a specific temporal class. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 26 of 104 4.8 The INSPIRE Metadata Different levels of requirements are expressed in the following chapters concerning the availability of metadata elements related to spatial resources: • Metadata on metadata is needed to know what the status is of the metadata itself. It is described in the General IRs defined in chapter 6; • Discovery metadata is composed of two levels. Level 1 discovery metadata ensures the needed linked between the expert and the non expert users. Level 2 discovery metadata are detailed enough for high level discovery of spatial resources by expert users. • Evaluation metadata includes level 2 metadata and a set of metadata elements needed to evaluate the fitness for use of the spatial resource. The INSPIRE evaluation metadata elements is a minimum set to be extended by the different INSPIRE user communities to adapt the evaluation metadata to the resource specificity. The evaluation metadata is supported by ISO 19115 and ISO 19119, and possible user community extension of ISO 19115 and ISO 19119. • Use metadata involves complementary standards such as ISO 19110, ISO 19111, ISO 19117 and others. In practice use metadata may often be found in documentation for applications rather than associated with data. The interrelations between the different level metadata needed to cover the INSPIRE Implementing Rules and the user communities metadata is illustrated in Figure 3. Level 1 Discovery Level 2 Evaluation Metadata on metadata Mandatory/ Conditional Mandatory/ Conditional Optional (within an INSPIRE Spatial Data Theme community the possibility exists to make some metadata elements Mandatory or Conditional Soil1) Agriculturalandaquaculturefacilities Naturalriskzones Habitatsandbiotopes 1) The mentioned INSPIRE Spatial Data Themes are pointed out as examples to give an impression Chapter 5 Chapter 7 Conditional Chapter 6 Use Chapter 8IR Data specifications Figure 3 – The INSPIRE Metadata Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 27 of 104 5 Implementing Rules for Discovery 5.1 Introduction Metadata for discovery serve the following purposes: - to provide information about the resources a user is interested in - to enable organisations to publish their data holdings The discovery activity involves an interaction between a client application (e.g., a search engine) and a metadata repository. In this interaction, it is fundamental to consider: - the user query expressed through the search interface of the search engine and provided in a form compatible with the metadata repository interface; - the query analyser which evaluates each of the metadata sets of the metadata repository against the query criteria; - the resulting metadata sets (i.e., the metadata sets matching the query criteria expressed by the user) as they are provided first by the repository interface to the result interface, then by the result interface to the user. This interaction shown in Figure 4 is not specific to a distributed search over a network: it can be handled by a local Search Engine acting on a local Metadata Repository possibly as simple as a single metadata file. Search Interface Metadata Repository Result Interface user Query Analyser <> <> Repository Interface Figure 4 – Interaction between Search and Response The manager of the metadata repository is fully responsible for the repository content model which will not be discussed further. In the same way, the search engine providers are responsible for defining the user-side of the search interface and of the result interface. Consequently, these IRs focus on: - the content of the queries provided by the Search Interface to the Repository Interface; - the core content of the resulting metadata sets provided by the Repository Interface to the Result Interface. From this perspective, the metadata elements involved in the discovery of spatial resources can play two roles: metadata elements that constitute search-parameters and metadata elements whose main role is to describe a resource in response to a query. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 28 of 104 This IR therefore distinguishes between two categories of metadata: • Search metadata – Search metadata allow a user to formulate a query. They help specify what kind of data the user is looking for (e.g., which part of the world this data covers, and when the data was created). Search metadata will be a small set of metadata elements, which shall be supported by every metadata query tool and every metadata catalogue. • Response metadata – Response metadata constitute a documentary feedback from the data/service provider, more fully describing a resource. Response metadata can be used for evaluation and to answer questions like: - What data and/or service are available within an area of interest? - Who is responsible for the resource and the associated metadata? - Who can I contact to get access, use and pricing of the resource? - Does the identified resource contain sufficient information to enable a sensible analysis to be made for my purposes? - What is the quality of the identified resource? - How and where can I obtain the resource? Response metadata are documentation provided with a resource to ensure that users other than the data providers themselves use a resource correctly and wisely. They may also contain evaluation metadata that specify the necessary processes to obtain and use the data. Response metadata help end users as well as data providers to document, store, reuse, maintain and archive a resource effectively. The discovery metadata elements are defined at an abstract level in order to make the Implementing Rules independent of: - the specific encoding used to express the query or resulting metadata sets; - possible future changes in standards such as ISO 19115 / ISO 19119, Dublin Core or others. The full list of INSPIRE discovery metadata elements is provided in section 5.2. This abstract metadata set for discovery distinguishes two levels of conformance for the response metadata elements: • Discovery level 1 elements are metadata that provide basic and essential descriptions of a resource. • Discovery level 2 elements are metadata that describe a resource in more detail. Level 2 elements are not essential for the first response. They give additional information about a resource as specified in Article 5 and 11 of the INSPIRE directive or are essential for an evaluation of the metadata information itself. To a certain extent, the first level satisfies a low level of discovery while the second level satisfies more complex discoveries and a minimum evaluation of the resources. Both are complementary. The first level is appropriate to e-government bodies. The second level is more appropriate for users who have enough knowledge to use the search metadata consistently or for a first evaluation of the resource. A Search Engine or a query analyser has to comply with one of the discovery levels. Compliance to discovery level 2 also requires compliance to discovery level 1. These IRs only define a core set of metadata elements for discovery. Compliance must still allow more metadata elements to be supported than the minimum defined in these Implementing Rules. Any INSPIRE compliant Search Engine shall enable the expression of queries including search criteria related to any of the INSPIRE Search Metadata Elements of the targeted discovery level compliance. Any INSPIRE compliant query analyser shall be able to handle the query criteria related to the INSPIRE Search Metadata elements of the targeted discovery level compliance. When a Search Metadata element is not relevant for a resource or not part of the targeted discovery level compliance, the related search criteria are ignored. The complexity of the queries depends on the chosen encoding. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 29 of 104 In term of result, the discovery metadata elements are mandatory (they have to be provided) or conditional (a condition defines when the metadata element has to be provided in a resulting metadata set). These IRs define whether the response metadata elements may occur once or more in a given set. A Search Engine should enable an access to all the metadata related to the INSPIRE Metadata elements of the targeted compliance level. 5.2 Discovery metadata elements 5.2.1 Resource title This is a characteristic and often-unique name by which the resource is known. Because the name may contain basic information about a resource such as a geographic and/or thematic description of the resource, it is an important element for the identification of resources (by human users). 5.2.2 Temporal reference The temporal reference of a resource will vary depending on the resource. It should be included in the discovery metadata if it is an important element describing the resource, particularly if the resource is not properly identifiable without this information. There are a number of situations where temporal reference is important, and it may describe the following: o The time period covered by the content of the resource (also called the temporal extent of the resource) o The date of publication of the resource when available o The date of last revision of the resource if the resource has been revised o The date of creation of the resource if it has not been revised When temporal reference describes the time period covered by the content of the resource, it should be a primary descriptor identifying the resource and not just information relevant to the use of the data. Spatio-temporal data are located in a defined space and at a defined time interval (a time instant can be considered as an infinitesimal interval), and their temporal extent can be of primary importance. Particularly for time varying data, it is necessary to support searches by filtering resource content location in space and time. This is in contrast to other types of resources (e.g., publications), where the date of publication of the resource is typically used as search parameter. A location in the time domain is a temporal position measured relative to a temporal reference system. A common type of temporal reference system is a calendar (used with clocks for greater resolution). A calendar is a discrete temporal reference system that provides a basis for defining temporal position to a resolution of one day. A clock provides a basis for defining temporal position within a day. A clock must be used with a calendar in order to provide a complete description of a temporal position within a specific day. There is some temporal information which cannot be described by specific dates or periods. Temporal information may be known more accurately by relative position than by absolute time, and in such cases an ordinal temporal reference system would be used. Examples are geological eras (such as Jurassic, Triassic or Cretaceous) or climatological eras (spring, summer, autumn, winter). Names in an ordinal temporal reference system can be considered as equivalent to names in a gazetteer. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 30 of 104 Other temporal references are indeterminate, in that generally they cannot be pre-defined in metadata, but in use they are specific. A data set which contains only today’s data or data for the last 24 hours or forecasts for the next week (e.g. weather data) cannot have the dates exactly defined in metadata, but in use the dates and times can be defined precisely.9 5.2.3 Geographic extent of the resource This is the location and extent of a resource in geographic space, given as a bounding box with four coordinates or as a geographic identifier. Because spatial data describe real-world phenomena for specific areas on the surface of the earth, the location and geographic extent of a resource is of primary importance and is used in spatial search requests. Depending on the type of the search interface, either a bounding box or a geographic identifier can be used to resolve such requests. Place name lists or gazetteers provide a controlled vocabulary for place names, including a reference to the respective geographic location expressed in spatial coordinates. Gazetteer services may therefore be used to disambiguate geographic identifiers and link them to their spatial footprints, typically expressed as point coordinates, bounding boxes, or polygons. 5.2.4 Resource language The language(s) used within the resource using the standard language codes in ISO 639-2 often used by search engines for narrowing the search. This element is particularly important for searches in a multi-lingual environment. 5.2.5 Resource topic category The topic category is a high-level classification scheme to assist in the grouping and the topicbased search of available spatial resources . The applicable topic categories are defined in section 4.5.1.The specified topic category positions the resource within the framework of the INSPIRE themes given in Annexes I, II and III. 5.2.6 Keyword Commonly used word(s), formalized word(s) or phrase(s) 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. An ideal situation is to base this on an existing thesaurus or taxonomies. A keyword search represents a minimum search criteria defined by INSPIRE in Article 11-2 (a). 5.2.7 Service type If the resource itself is a service, this refers to an interface specification that the service implements. Well known service types published as standard are of course recommended (e.g. an OGC WMS). 5.2.8 Resource responsible party 9 The mechanisms in metadata searches for ordinal or indeterminate temporal references are not well defined. A pilot project for INSPIRE is in planning to investigate the best way to describe, code and use this type of temporal information. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 31 of 104 The public authority or any other citation to the organisation most responsible for the resource and the corresponding role(s) (the establishment, management, maintenance and distribution of spatial datasets and spatial data services organisation (INSPIRE Article 5-2 (d) and 11-2 (g). This element is also important for full text search. Depending on the applicable encoding and metadata standard, this element may be expressed as a text or as a structured set of information. In this last case, the full text search is applied to the individual textual components of the structured set. 5.2.9 Abstract This is a brief narrative summary of the content of the resource. 5.2.10 Resource locator The resource locator defines the location of the resource. It is used in order to access the resource or at least more information about the resource. It is commonly expressed as a Uniform Resource Locator (URL), particularly for an online linkage. 5.2.11 Constraint This metadata element defines a set of restrictions placed on a resource. It may be not exclusively a security or legal constraint. The basic form of such a constraint is a use limitation statement, which can be used for full text searches. For legal constraints, different types of restrictions can also be expressed in term of access to and use of the resource. For security constraints, a level of classification and related information can also be provided. Considering the importance of the legal constraints in term of protection of privacy or intellectual property, the absence of constraints on a resource would be unexpected. It is highly recommended to avoid the absence of constraints and to express at least one of special use limitation statements: instead of values use: o “unknown” if the constraints related to the resources have not been documented; o “no restriction applied” if the intent is effectively to release the resource without any constraint The use limitation statement is not expected to express the fitness for use of the resource, but it can express that a resource does not meet the requirements for certain application. Such a typical statement is “not to be used for navigation” for maritime maps or resources not satisfying the requirements for a safe navigation. 5.2.12 Lineage This is general information for reporting a non-qualitative statement on process history and/or overall quality report. It is an easy way of giving a short quality report, which INSPIRE requires in article 5-2 (c). Since this is an INSPIRE requirement it is recommended to use expressions such as “unknown” if no information is available. 5.2.13 Service type version This element is strongly associated with the service type element. While the service type element identifies the type of the service instance, the service type version specifies the version number of the underlying specification this service instance complies with. Both elements (service type and service type version) specify exactly a well known service type. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 32 of 104 5.2.14 Operation name This element specifies the name of one operation of the service instance. This name is used to invoke the service interface within the context of the distributed computing platform (DCP (see below). This information is necessary for a client to bind to the service. 5.2.15 Distributed computing platform This element describes the distributed computing platform(s) on which the service instance is deployed. This information is necessary for a client to bind to the service. 5.2.16 Resource identifier This element describes an unambiguous reference to the resource in a given context. The definition of identifier encoding is the task of the Drafting Team “Data Specification”. The information is useful to directly access the resource. See section 6.2 for further information on identifiers. 5.2.17 Spatial resolution The spatial resolution is an indicator of the level of detail of the data related to a spatial resource. It can be expressed as an equivalent scale (typically, for maps or map-derived products), or a resolution distance for gridded data and imagery-derived products. Spatial resolution provides a rough indication of the accuracy and potential quality of a spatial resource. It can be used, for example, to eliminate those resources that do not provide the minimum level of detail needed for a specific task. 5.2.18 Conformity Conformity refers to the requirement of the Directive in Article 5-2(a) that metadata shall include information on the conformity of spatial data sets with the IR provided in Art. 7-1 which refer to the interoperability and where practicable harmonization of spatial data sets and services. 5.3 Basic Requirements The previous section provides a general description of the metadata elements used for discovery. In this section, information regarding implementation of these elements as part of a set of metadata describing a resource is given. 5.3.1 Notation The basic requirements are expressed for each discovery level in a dedicated table providing for each metadata element the following information: • the name of the element • whether the element can be used as part of a search request. The discovery service supports these elements as queryables. • the multiplicity of a metadata element in the result set of a search request. The expression of the multiplicity follows the UML notation for multiplicity. 1 means that there shall be only one instance of this metadata element in a result set. 1..* means that there shall be at least one instance of this element in a result set. 0..1 indicates that the presence of the metadata element in a result set is conditional but can occur only once. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 33 of 104 0..* indicates that the presence of the metadata element in a result set is conditional but the metadata element may occur once or more. No multiplicity implies that the metadata element is not part of the response. • a conditional statement if the multiplicity of the element does not apply to all types of resources . 5.3.2 Abstract discovery metadata element set – Discovery level - 1 The abstract metadata elements for discovery level 1 are shown in Table 1. Table 1 - Abstract discovery metadata element set – level 1 Metadata element Search Response Condition Resource title X 1 Temporal reference X 1..* When the content selection by temporal extent is meaningful One of the dates of publication, last revision or creation of the resource is mandatory Geographic extent of the resource X 0..* Mandatory for datasets and dataset series Resource language X 0..* When dataset or dataset series has textual information Resource topic category X 0..* Mandatory for datasets and dataset series Keyword X 1..* Service type X 0..* If the resource is a service Resource responsible party 1..* Abstract 1 Resource locator 0..* When a linkage to the resource or a contact point for more information about the resource is available 5.3.3 Abstract discovery metadata element set – Discovery level - 2 The abstract metadata elements for discovery level 2 are shown in Table 2. Table 2 - Abstract discovery metadata element set – discovery level 2 Metadata element Search Response Condition Constraints 0..* When there are constraints regarding access or usage Lineage 0..1 When a quality report or other lineage statements are required Conformity 0..* Mandatory for datasets and dataset series Service type version 0..* If the service is a well known service type Operation name 0..* If the resource is a service Distributed computing platform 0..* If the resource is a service Resource Identifier 0..1 If an identifier is available Spatial resolution 0..1 Mandatory for datasets and dataset series if a unique equivalent scale or resolution distance can be specified10 10 For some datasets and dataset series, a unique spatial resolution cannot be specified. Examples are pointdatasets (e.g. measurement data attributed to a specific monitoring station) or complex dataset series that contain multiple datasets at different scales (e.g. a thematic atlas). Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 34 of 104 5.3.4 Implementation instructions of the abstract discovery set Because of the need to translate the abstract set to the implementation of ISO 19115/ISO 19119, Dublin Core and other standards, the abstract set needs more detail at the general level for the different implementations. These details are provided in Table 3. Table 3 - Implementation instructions for the abstract discovery metadata element Metadata element User instructions Example Domain Resource title It is recommended to use a meaningful and unique name, if possible. Mastermap free text Temporal reference11 Describe the temporal period the resource refers to and the reference date of the cited resource. Time locations are measured relative to a temporal reference system as specified by ISO 8601. 2006:01:01-2006:01:31 2006-01-20, publication ISO 19108, DateTime Geographic extent of the resource Describe the geographic area the resource refers to. Use a bounding box, polygon or a geographic identifier Long: -30.0 Lat: 35.0 Long: 50.0 Lat: 70.0 Europe ISO 19115 Resource language Describe the main language used for text in the resource by using ISO 639-2 standard. CEN member states should check if their language is represented on this list. Nor ISO 639-2 11 The DT Metadata has recognized that an requirement for specifies searches on named periods in an ordinal temporal reference system, or periods where one or more nodes are indeterminate but which on any specific search may be exactly specified as a date or time could be needed. This is because some temporal information is known more accurately by relative position than by absolute time, and in such cases an ordinal temporal reference system is used. Examples are geological eras (such as Jurassic, Triassic or Cretaceous) or climatologically eras (spring, summer, autumn, winter). Names in an ordinal temporal reference system are equivalent to names in a gazetteer. Some temporal references are indeterminate, in that generally they cannot be pre-defined in metadata, but in use they are specific. A data set which contains only today’s data or data for the last 24 hours or forecasts for the next week (e.g. weather data) cannot have the dates exactly defined in metadata, but in use the dates and times can be defined precisely. A pilot study in conjunction with DT Metadata, JRC and communities with a temporal use case as described here will be done in the first half year of 2007. The motivation for this pilot is to decide how this requirement should be implemented in the IR Metadata. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 35 of 104 Resource topic category Specify one or more high-level topic categories for the resource, using the respective ISO19115 code list. Annex E contains the mapping from the INSPIRE spatial data themes to the code list. Boundaries code list B.5.27 from ISO 19115 Keyword Give one or more keywords that describe the thematic content of the resource. It is strongly recommended that keywords are used from formalized thesaurus. topography, roads free text Service type12 Specify a service type in a standardized format (INSPIRE code list) WMS, WFS ISO 19119 Resource responsible party Use the full name of the responsible organisation. The abbreviations can be in addition to the organisation name. European Commission Directorate General Joint Research Centre (JRC) free text Abstract Provide a short but exact description of the resource Dataset contains large scale (1:1.000) topography, which covers the whole country free text Resource locator Specify a valid URL to a dataset/dataset series or a service. If no direct link to resource is available, provide a link to a responsible party of the resource where more information about resource is available. http://www.geonorge.no/ URL Constraints - Access13 Specify any legal or proprietary constraints that limit the free access to the resource. Copyright or other restrictions - unknown code list B.5.24 from ISO 19115 Constraints – use Limitations14 Specify any constraints in terms of feasibility or quality that limit the use of the resource Maritime map cannot be used for safe navigation free text 12 DT network services has been asked if it is possible to produce a code list. If yes, this will be a deliverable of the DT network services. 13 This is a task for the DT data sharing. 14 This is a task for the DT data sharing. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 36 of 104 Lineage In addition to general explanation of the data producer’s knowledge about the lineage of a dataset it’s possible to give here data quality statements. In this dataset, the boundaries between the North Sea and the provinces are the borders between land en water, not the administrative boundaries. or Data have been digitised from the standard 1:5.000 map. free text Conformity 15 Describes the conformity of the dataset and dataset series with the rules of Article 7(1) See Annex F See Annex F Service type version Specify the version number of a well known service type 1.1.0 ISO 19119 Operation name Specify the invocation name for a service interface GetCapabilities, GetMap, GetRecords ISO 19119 Distributed computing platform Specify the distributed computing platform(s) the service instance is deployed to. WebServices ISO 19119 Resource identifier Identifier of the resource urn:opengis:specification:gml:schema- xsd:coordinateSystems:3.1.1 or 64075d21-fa6a-43d5-9972- c75bd978304b free text Spatial resolution Use for equivalent scale denominator and for resolution distance metres Equivalent scale: 50000 Resolution distance: 3.0 Integer ISO/TS 19103 15 The conformity will be provided by DT Data specifications (see annex F) Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 37 of 104 6 General Implementing Rules 6.1 Metadata on metadata 6.1.1 Motivation of the abstract metadata on metadata set 6.1.1.1 Metadata point of contact Identifies the party or person responsible for the metadata creation and maintenance. It is important information to identify and communicate with the person(s) or organizations associated with the metadata of the resource (for example to find out if the metadata are upto-date or to ask for an update of the information). This metadata element is mandatory to be in conformance with ISO 19115. 6.1.1.2 Metadata date stamp Date, which specifies when the metadata record was created or updated. Gives an indication of the currency of the metadata. This metadata element is mandatory to be in conformance with ISO 19115. 6.1.1.3 Metadata language The main language used in the metadata record. This is an important element in multi-lingual environments and catalogues for the parameterisation of multi-lingual catalogue user- interfaces. 6.1.2 Abstract metadata on metadata set To deal with the system metadata and mandatory metadata needed for metadata management, the following metadata elements have to be supported. Table 5 - Abstract metadata on metadata element set – discovery level 2 Metadata element Search Response Condition Metadata point of contact 1..* Metadata date stamp 1 Metadata language 0..1 If not defined by encoding 6.1.3 Implementation instructions of the abstract metadata on metadata set Because of the need to translate the abstract set to the implementation of ISO 19115/ISO 19119, Dublin Core and other standards, the abstract set needs more detail at the general level for the different implementations. These details are pointed out in Table 6. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 38 of 104 Table 6 - Implementation instructions for the abstract metadata on metadata set Metadata element User instructions Example Domain Metadata point of contact Use the full name of the responsible organisation. The abbreviations can be in addition to the organisation name. When an organisation is not responsible but a person then the name of the person will be filled in European Commission Directorate General Joint Research Centre (JRC) free text Metadata date stamp Enter the date of creation or (if there was any) of the last update of the metadata record 2005-03-27 (YYYY-MM-DD) ISO 8601, Date Metadata language Specify the main language of the metadata record. This applies mainly to the elements Title, Abstract, and Keywords dut, nor ISO 639-2 6.2 Identifiers In the context of INSPIRE, identifiers may be of importance from various points of view: • Identifying a metadata record itself • Identifying parts of the metadata record (i.e. the identifier of the spatial reference system) • Identifying a resource in a given context • Provision of linkage between metadata record and resource • Provision of linkage of related metadata records (parent-child relationships, servicedataset coupling) In any case identifiers might be anonymous and/or unique. This depends strongly on the use cases in which an identifier is created and applied. Furthermore, identifiers have to be distinguished from locators. A locator provides direct access to a resource. In the case of an identifier, this is not necessarily true. An example for a locator is a Universal Resource Locators (URL) that is a subtype of Universal Resource Identifiers (URI). An URL is expected to provide access to an external resource, while this is not a requirement for a URI. The URI syntax is defined in RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt). This specification does not guarantee by itself the uniqueness of the URI, but the uniqueness can be ensured with a given context in a coordinated way. Universally Unique Identifier (UUID) is an identifier standard established by the Open Software Foundation (OSF). The intention of UUIDs is to enable distributed systems to uniquely identify information without significant central co-ordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 39 of 104 never be unintentionally used by anyone for anything else. Information labelled with UUIDs can therefore be later combined into a single database without need to resolve name conflicts. An identifier, even a unique identifier does not need necessarily to be anonymous. Typically, the URI of an XML namespace allows the identification of the responsible body. For example, ISO 19139 base namespace URI is http://www.isotc211.org/2005/gmx. Anybody can see through this identifier that information related to ISO 19139 can be found in the ISO/TC 211 web site. Yet, UUID are typically anonymous identifiers which may be useful in some context. UUIDs are very bad locators but very good unique identifiers, above all when the identifiers need to be anonymous. URLs are very good locators in a distributed environment, but they barely play a role in term of unique identification. In the context of this document, only resource identifiers are addressed. This means the identifier of a resource that is described by a metadata document might be referred within this document to provide a means to associate metadata documents with related resources. There is no need to define an identifier for the metadata record itself since this is more related to metadata management which is out of scope of the Implementing Rules. The identifier for a resource is a metadata element on discovery level 2. NOTE: It is assumed that the DT Data Specification will define the structure or protocol for identifier of resources. The DT Metadata will adopt this specification and harmonize it, if needed, with the requirements defined by this document. 6.3 Granularity The metadata Implementing Rules should define what constitutes a “dataset” as part of a spatial resource. In Article 4.2, the Directive clarifies that its provisions apply only to the reference version from which various copies are derived, in cases where multiple identical copies of the same spatial data set are held by or on behalf of various public authorities. In a similar way, in the life cycle of data, data may be at various times collected, transferred to intermediate cache, quality controlled, verified, backed-up, stored for use and re-use, then perhaps replaced with new data, retired, overwritten or transferred to archive. In this case a reference data set is that which the spatial data services use and which users access. Published metadata need only refer to the reference version of the data set, although if there are different uses of the data at different stages, then there may be a case for distinct metadata and distinct reference versions. INSPIRE metadata is intended for discovery. This needs sufficient information that a user can find out what data exists, where it is held and by whom, but not so much information that the user’s query is swamped by too many, essentially duplicated, responses. The first response should give sufficient information such that the user is likely to be able identify ways to narrow his/her search criteria. This will normally narrow the search to the repository which holds the data in question, so that the user can search for more detailed information about the target data. This more detailed information may no longer be “discovery” metadata, but will have extended into “evaluation” or “use” metadata. It is likely to be specific to the particular repository, and certainly specific to the spatial data theme, as defined in INSPIRE. In this model of a query hierarchy, the discovery metadata should refer to coherent sets or collections of data and datasets, and not to a range of nearly identical component datasets. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 40 of 104 In ISO19115 this is described as a dataset series - a “collection of datasets sharing the same product specification”. The discovery metadata should be created for datasets or dataset series, in a manner which would help a user to identify and home in on his or her particular requirements, in the sequence of queries. In practical terms the data will already be aggregated into an existing database or repository in a pre-defined level of organisation. The user is likely to be required to configure the request for data in a manner which matches the capability of applications to extract data from the repository. In many cases the organisation of the repository will be well aligned with purpose of the data. Again, in many cases this will be in reasonable accord with the user’s requirement. The granularity of the discovery metadata, therefore, should reflect the logical organisation of the data repository at a sufficiently coarse grained level. As an example, INSPIRE discovery metadata should describe the collection of bore-holes in a geological data repository, not bore-holes at individual sites. If at a geospatial repository, the data are organised in collections which reflect the resolution and coverage, and if the data retrieval mechanisms are organised in this way, then the metadata granularity should reflect this. On the other hand, if data from distinct and non-overlapping regions, perhaps where the data were collected at different times and to different standards, are easily distinguished, then it might be sensible to make the metadata distinct too. The choice of the metadata granularity may also be affected by the capability to gather and maintain the metadata. It will often be true that for very-fine grained data collections it may be impossible or prohibitively expensive to harvest a complete set of discovery metadata. The granularity of INSPIRE metadata should therefore be chosen to provide enough information to enable good dataset discovery, and to be able to keep the metadata up to date as required by the Directive (Art. 5-1). Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 41 of 104 7 Implementing Rules for Evaluation The metadata elements for evaluation are the full responsibility of the INSPIRE Spatial Data Themes communities. The evaluation metadata is supported by ISO 19115 and ISO 19119, and possible user community extension as defined in these standards. The IR for Metadata describes no profiles of these standards because different INSPIRE Spatial Data Themes communities can have different needs. This means that the metadata elements of ISO 19115 and ISO 19119 are, except from the elements mentioned in chapters 5 and 6, all optional. The IR for Metadata leaves it open to the specific INSPIRE Spatial Data Themes communities to define which elements should be made mandatory or mandatory by condition based on their requirements and practices. It is acknowledged that some of the resources in the scope of the INSPIRE Directive do not contain spatial data (an environmental report, for example), but in such a case they are georeferenced through their metadata, i.e. their geographic extent. The presence of metadata related to the reference system of the resource is highly recommended for the purpose of evaluation and use, except of course for those resources. Annex D gives an overview of the applicability of the ISO TC/211 and OGC standards for evaluation metadata. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 42 of 104 8 Implementing Rules for Use The metadata elements for use will be the outcome of the harmonization of the INSPIRE Spatial Data Themes of Annex I and II or non-harmonized data of Annex III. The metadata for use involves complementary standards such as ISO 19109, 19110, 19111, 19111 and others that are defined in the Implementing Rules for data specification. Annex D gives a brief overview of the applicability of the ISO TC/211 and OGC standards for use metadata. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 43 of 104 Annex A ISO 19115 / ISO 19119 implementation The XML encoding of ISO 19115 is based on ISO TS 19139. Within the ISO Metadata Application Profile document, a similar XML encoding based on ISO TS 19139 is defined that uses the same long name declaration. This ISO Metadata Application Profile encoding complies with the logical model of ISO 19119 including the elements defined by the ISO 19119 amendment (ISO 19119:2005 PDAM 1) and is used for the service elements of ISO 19119 because they are not specified by ISO TS 19139. According to ISO 19115, metadata can be defined at different hierarchical levels: dataset series, dataset, feature instance and attribute instance (as stated in Annex G of ISO 19115). ISO 19119 extends these hierarchical levels to services. For these Implementing Rules the following hierarchical levels are: • Dataset series • Dataset • Service Hierarchy levels shall be described by MD_ScopeCode codelist values (MD_Metadata.hierarchyLevel = ‘series’, ‘dataset’ or ‘service’). A metadata instance with the no hierarchy level or a different hierarchy level is out of the scope of the INSPIRE directive. This annex is organized as follows: • Clause A.1 presents the ISO 19139 instance template for INSPIRE Discovery Metadata Elements • Clauses A.2 and A.3 describe in more detail each INSPIRE metadata element for discovery at levels 1 and 2 A.1 INSPIRE Discovery Metadata ISO 19139 Encoding Template A.1.1 Introduction This clause presents the overall structure a metadata set both compliant with ISO 19115 and the INSPIRE abstract discovery metadata elements defined in Chapter 5. This structure is presented as a set of tables describing the properties that must be documented for Level 1 and Level 2 discovery. The description of each property is composed of: • The property stereotype expressing one of the following codes: + implies a property instance implemented as an XML Element - implies a property instance implemented as an XML Attribute. • The property label; • A presence requirement expressed with a cardinality statement between square brackets; • A colon; • The property type name. The property type is implemented as a sub element of the property. This sub element can be an instance of the property type or an instance of one of its derived types. In the latter case, the derived type is either an ISO type or an extension type defined in a profile. • A property instance statement which describes how the property type is implemented. Additional information is provided in a Note section, at the bottom of each table. Properties for Discovery Level 1 are in blue, properties for Discovery Level 2 are in red. This hierarchical set of labels acts as an instance Template. This template only shows the properties in the scope of the INSPIRE discovery metadata elements, which encompass the Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 44 of 104 mandatory properties of ISO 19115 and ISO 19115-2. The other optional properties of ISO 19115 are not described, but can be present in a real instance. Additional properties defined in a profile of ISO 19115 or ISO 19115-2 compliant with the INSPIRE abstract discovery metadata element set can be expressed but are not documented here. A.1.2 Resource MetadataSet An INSPIRE Discovery Metadata Set that complies to ISO 19139 and the INSPIRE Metadata Profile defined in this document is an instance of the class MD_Metadata (from ISO 19115), the class MI_Metadata (from ISO 19115-2) or an instance of any community specialisation of one of these two classes. The sub-elements of this root element are described hereafter. A.1.2.1 Instance template of the Metadata Entity Set Section The following instance template handles: • the metadata fields of the Metadata Entity Set section • the metadata fields of the Distribution Information section • the metadata fields of the Data Quality Information section • the entry point to the Identification Section +language [0..1] : CharacterString................................................. E.g. dut +hierarchyLevel [0..*] : MD_ScopeCode........................................ Values in the scope of INSPIRE: dataset, series or service +contact [1..*] : CI_ResponsibleParty + individualName [0..1] : CharacterString.................................... Mandatory if the responsible body is not an organisation + organisationName [0..1] : CharacterString............................... E.g. European Commission Directorate General Joint Research Centre (JRC). See 1 + role [1] : CI_RoleCode.............................................................. One of the value of the CodeList CI_RoleCode. E.g. custodian +dateStamp [1] : Date.................................................................... Format YYYY-MM-DD. E.g. 2005-03-27 +identificationInfo [1] : MD_DataIdentification See A.1.2.2 +distributionInfo [0..*] : MD_Distribution......................................... See 2 + transferOptions [0..*] : MD_Format + online [0..*] : CI_Onlineresource + linkage [1]: URL ................................................................. E.g. http://www.geonorge.no/ +dataQualityInfo [0..*] : DQ_DataQuality....................................... See 3 + lineage [0..1] : LI_Lineage + statement [0..1] : CharacterString......................................... Ex : Data have been digitised from the standard 1:5.000 map. See 4 Notes : 1. The abbreviation can be used in addition to the organization name. 2. Mandatory when a linkage to a resource or a contact point for more information about the resource is available. 3. Mandatory when a quality report or other lineage statements are required 4. In addition to general explanation of the data producer’s knowledge about the lineage of a dataset, it is possible to give here data quality statements A.1.2.2 Identification Section Depending on the value of the element hierarchyLevel (dataset, series or service), the Identification Section is either instantiated through: • an element named MD_DataIdentification or derived from MD_Identification (e.g., MI_DataIdentification from ISO 19115-2) in the case of a dataset or a series; or • an Element named MD_ServiceIdentification or derived from SV_ServiceIdentification These two cases are described hereafter. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 45 of 104 Sub-elements for dataset and series resources + citation [1] : CI_Citation +title [1] : CharacterString .............................................................. Name by which the cited resource is known. E.g. Mastermap +date [1] : CI_Date......................................................................... See 5 +date [1] : Date........................................................................... Format: YYYY-MM-DD. E.g. 2006-01-20 +dateType [1] : CI_DateTypeCode............................................. Either creation, revision or publication. E.g. publication +identifier [0..1] : MD_Identifier...................................................... Mandatory if an identifier is available +code [1] : CharacterString......................................................... E.g. urn:ogc:specification:gml:schema- xsd:coordinateSystems:3.1.1 +authority [0..1] : CI_Citation...................................................... Person or party responsible for maintenance of the namespace + abstract [1] : CharacterString....................................................... E.g. Dataset contains large scale (1:1.000) topography + pointOfContact [1..*]: CI_ResponsibleParty ................................ Organisation name or individual name is mandatory +individualName [1..*] : CharacterString........................................ See 6. E.g. Smith, John +organisationName [1..*] : CharacterString................................... See 7. E.g. European Commission Directorate General Joint Research Centre (JRC) +role [1] : CI_RoleCode ................................................................. E.g. owner + spatialResolution [0..1]: MD_Resolution...................................... See 8 + language [0..*]: CharacterString................................................... Language(s) used within the datasets. See 9. E.g. fin + topicCategory [1..*]: MD_TopicCategoryCode............................. Main theme(s) of the dataset. See 10. E.g. boundaries + resourceConstraints [0..*] : MD_LegalConstraints....................... Mandatory when there are constraints regarding access or usage +useLimitation [0..*] : CharacterString ........................................... E.g. Not to be used for navigation +accessConstraints [1] : MD_RestrictionCode .............................. E.g. copyright + extent [0..*] : EX_Extent +geographicElement [1..*] : EX_GeographicBoundingBox............ See 11 +westBoundLongitude [1] : Decimal........................................... E.g. 2.50 +eastBoundLongitude [1] : Decimal ........................................... E.g. 5.80 +southBoundLatitude [1] : Decimal ............................................ E.g. 51.80 +northBoundLatitude [1] : Decimal............................................. E.g. 54.60 +geographicElement [0..*] : EX_GeographicDescription............... See 12 +geographicIdentifier [1]: MD_Identifier + code [1] : CharacterString..................................................... E.g. Hannover + authority [0..1] : CI_Citation................................................... Person or party responsible for maintenance of the namespace. +temporalElement [0..*] : EX_TemporalExtent.............................. See 13 +extent [1] : TM_TimePeriod ...................................................... Interval expressed as two dates and times. + descriptiveKeywords [1..*] : MD_Keywords +keyword [1..*]: CharacterString................................................. E.g. climatological data Notes : 5. One date of type publication, last revision or creation of the resource is mandatory 6. Name of the responsible person - surname, given name, title separated by a delimiter. Use the full name of the responsible person. 7. Use the full name of the responsible organisation. The abbreviations can be in addition to the organisation name 8. Mandatory for datasets and dataset series if a unique equivalent scale or resolution distance can be specified. 9. In INSPIRE environment, use only three-letter codes defined in ISO639-2/B (bibliographic codes), defined at http://www.loc.gov/standards/iso639-2/. 10. Annex E defines the mapping from the INSPIRE spatial data themes to the ISO dataset topic category. 11. Mandatory for datasets and dataset series. The bounding box shall be as small as possible. ISO TS 19139 requires 2 decimals. 12. Mandatory for datasets and dataset series where the element EX_GeographicBoundingBox is not defined 13. Mandatory when it is meaningful for discovering and selecting the resource Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 46 of 104 Sub-elements for service resources + citation [1] : CI_Citation +title [1] : CharacterString .............................................................. E.g. GeoOgcWms +date [1] : CI_Date......................................................................... See 14 +date [1] : Date........................................................................... Format: YYYY-MM-DD. E.g. 2006-01-20 +dateType [1] : CI_DateTypeCode............................................. Either creation, revision or publication. E.g. publication +identifier [0..1] : MD_Identifier...................................................... Mandatory if an identifier is available +code [1] : CharacterString......................................................... E.g. urn:ogc:serviceType:WMS:1.0 +authority [0..1] : CI_Citation...................................................... Person or party responsible for maintenance of the namespace + abstract [1] : CharacterString....................................................... E.g. Tightly-coupled WMS serving large scale (1:1.000) topography + pointOfContact [1..*]: CI_ResponsibleParty ................................ Organisation name or individual name is mandatory +individualName [1..*] : CharacterString........................................ See 15. E.g. Smith, John +organisationName [1..*] : CharacterString................................... See 16. E.g. European Commission Directorate General Joint Research Centre (JRC) +role [1] : CI_RoleCode ................................................................. E.g. owner + serviceType [1]: CharacterString ................................................. See 17. E.g. WMS + serviceTypeVersion [0..*]: CharacterString.................................. See 18. E.g. 1.3.0 + extent [0..*] : EX_Extent +geographicElement [0..*] : EX_GeographicBoundingBox............ See 19 +westBoundLongitude [1] : Decimal........................................... E.g. 2.50 +eastBoundLongitude [1] : Decimal ........................................... E.g. 5.80 +southBoundLatitude [1] : Decimal ............................................ E.g. 51.80 +northBoundLatitude [1] : Decimal............................................. E.g. 54.60 +geographicElement [0..*] : EX_GeographicDescription............... See 20 +geographicIdentifier [1]: MD_Identifier ..................................... + code [1] : CharacterString..................................................... E.g. Hannover + authority [0..1] : CI_Citation................................................... Person or party responsible for maintenance of the namespace. +temporalElement [0..*] : EX_TemporalExtent.............................. See 21 +extent [1] : TM_Period .............................................................. Interval expressed as two dates and times. + couplingType [1]: SV_CouplingType............................................ Either loose, mixed or tight. E.g. tight + resourceConstraints [0..*] : MD_LegalConstraints....................... Mandatory when there are constraints regarding access or usage +useLimitation [0..*] : CharacterString ........................................... E.g. Serves images only +accessConstraints [1] : MD_RestrictionCode .............................. E.g. copyright + descriptiveKeywords [1..*] : MD_Keywords + keyword [1..*]: CharacterString................................................. E.g. OGC Web Map Service + containsOperations [1..*] : SV_OperationMetadata..................... Description of the operations offered by the service + operationName [1]: CharacterString......................................... E.g. GetMap + DCP [1..*]: DCPList .................................................................. E.g. WebServices + connectPoint [1..*]: CI_OnlineResource................................... Handle for accessing the service interface. + linkage [1]: URL .................................................................... E.g. http://www.geoserver.nrw.de/GeoOgcWms1.3/servlet/GEPNRW Notes : 14. One date of type publication, last revision or creation of the resource is mandatory 15. Name of the responsible person – surname, given name, title separated by a delimiter. Use the full name of the responsible person. 16. Use the full name of the responsible organization. The abbreviations can be in addition to the organization name. 17. Mandatory when the resource is a service. It is recommended to make use of a code list instead of a character string. This code list describes all the possible service types 18. Mandatory if the resource is a well-known service type 19. Mandatory for services in case the coupling type of the service instance equals "mixed" or "tight". The bounding box shall be as small as possible. ISO TS 19139 requires 2 decimals. 20. Mandatory for “mixed” or “tightly” coupled services where the element EX_GeographicBoundingBox is not defined 21. Mandatory when it is meaningful for discovering and selecting the resource Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 47 of 104 A.2 Abstract discovery metadata element set – Discovery level - 1 A.2.1 Resource title Metadata element name Resource title ISO definition Name by which the cited resource is known ISO 19115 number and name 360 title XPath .//identificationInfo//citation/*/title//text() INSPIRE obligation / condition Mandatory INSPIRE multiplicity [1] Data type CharacterString Domain Free text Implementing instructions Example Mastermap Comment A.2.2 Temporal Reference A.2.2.1 temporal extent Metadata element name Date – temporal extent ISO definition Date and time for the content of the dataset ISO 19115 number and name 351 extent XPath identificationInfo//extent//temporalElement INSPIRE obligation / condition C (mandatory when it is meaningful for discovering and selecting the resource) INSPIRE multiplicity [0..*] (because this is a set of intervals; each interval consists of 2 DateTimes [0..2] Data type Time Period or TimeInstant16 Domain Described in ISO 19108 and ISO 8601 Implementing instructions Example 1977-03-10T11:45:30 (YYYY-MM-DDThh:mm:ss) 2005-01-15T09:10:00 (YYYY-MM-DDThh:mm:ss) Comment A set of intervals (expressed as two dates and times) will be presented. Interval sub-types are supported, as follows: instant, set of instants, composite intervals, period, set of periods. A.2.2.2 date Metadata element name Date - date ISO definition Reference data for the cited resource ISO 19115 number and name 394 date XPath identificationInfo//*/citation/*/date/*/date INSPIRE obligation / condition M INSPIRE multiplicity [1] 16 ISO19108 describes other domains which might support the INSPIRE requirements for temporal metadata. There are no implementations currently known. ISO19108 allows ordinal temporal extents (TM_Position values of TM_OrdinalEras defined within a TM_OrdinalReferenceSystem) and an indeterminate value of “now” is valid under TM_Position. ISO 19108 TM_PeriodDuration also defines the distance in the temporal dimension Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 48 of 104 Data type Date (CI_Date) Domain Described in ISO 19108 and ISO 8601 Implementing instructions Example 1993-01-24 (YYYY-MM-DD) Comment This date has to be followed by a data type A.2.2.3 Date - publication Metadata element name Date - publication ISO definition event used for reference data ISO 19115 number and name 395 dateType XPath identificationInfo/*/citation/*/date[identificationInfo/*/dateType/*/te xt()='publication']/*/date INSPIRE obligation / condition C (Mandatory if a date- creation or date - revision not used) INSPIRE multiplicity [0..1] Data type code list Domain code list B 5.2 > CI_DateTypeCode=publication Implementing instructions Example The data when a dataset was published Comment The data type has to be followed by a date A.2.2.4 Date - revision Metadata element name Date - revision ISO definition event used for reference data ISO 19115 number and name 395 dateType XPath identificationInfo/*/citation/*/date[identificationInfo/*/dateType/*/te xt()='revision']/*/date INSPIRE obligation / condition C (Mandatory if a date- creation or date - publication not used) INSPIRE multiplicity [0..1] Data type code list Domain code list B 5.2 > CI_DateTypeCode=revision Implementing instructions Example The data when a dataset was revised Comment The data type has to be followed by a date A.2.2.5 Date - creation Metadata element name Date - creation ISO definition event used for reference data ISO 19115 number and name 395 dateType XPath identificationInfo/*/citation/*/date[identificationInfo/*/dateType/*/te xt()='revision']/*/date INSPIRE obligation / condition C (Mandatory if a date- publication or date - revision not used) INSPIRE multiplicity [0..1] Data type code list Domain code list B 5.2 > CI_DateTypeCode=revision Implementing instructions Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 49 of 104 Example The data when a dataset was revised Comment The data type has to be followed by a date A.2.3 Geographic extent of the resource The geographic extent of the resource describes the geographic location for which the resource applies. This metadata element is only mandatory for datasets and datasets series. A.2.3.1 EX_GeographicBoundingBox Metadata element name Geographic extent of the resource – EX_GeographicBoundingBox ISO definition 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) Southern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north) Northern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north) ISO 19115 number and name 344 westBoundLongitude 345 eastBoundLongitude 346 southBoundLatitude 347 northBoundLatitude XPath identificationInfo//extent//geographicElement/*/westBoundLongit ude//text() identificationInfo//extent//geographicElement/*/eastBoundLongitu de//text() identificationInfo//extent//geographicElement/*/southBoundLongit ude//text() identificationInfo//extent//geographicElement/*/northBoundLongit ude//text() INSPIRE obligation / condition C (EX_GeographicBoundingBox is mandatory for datasets, dataset series and for services in case that the coupling type of the service instance equals to "mixed" or "tight") INSPIRE multiplicity [0..*] Data type Decimal Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 50 of 104 Domain -180,00 <= West Bounding Longitude Value <= 180,00 -180,00 <= East Bounding Longitude Value <= 180,00 -90,00 <= South Bounding Latitude Value <= 90,00; South Bounding Latitude Value <= North bounding Latitude Value -90,00 <= North Bounding Latitude Value <= 90,00; North Bounding Latitude Value >= South Bounding Latitude Value Implementing instructions The bounding box shall be as small as possible. ISO TS 19139 requires 2 decimals. Example 2.50 5.80 51.80 54.60 Comment Two decimals should be used while describing the bounding box. A.2.3.2 EX_GeographicDescription Metadata element name Geographic extent of the resource - EX_GeographicDescription ISO definition spatial reference in the form of a label or code that identifies a location (ISO19112) ISO 19115 number and name 349 geographicIdentifier ISO TS 19139 path identificationInfo//extent//geographicElement/*/geographicIdentifi er/*/code//text() INSPIRE obligation / condition C (EX_GeographicDescription is mandatory for datasets, dataset series and “mixed” or “tightly” coupled services where neither the element EX_GeographicBoundingBox nor EX_BoundingPolygon is defined). INSPIRE multiplicity [0..*] Data type CharacterString Domain Free text Implementing instructions A geographic identifier shall be assigned on basis of a documented and generally accessible gazetteer service, code system, or other indirect spatial reference system. Example Hannover (City in Germany) D-30169 (Postal Code of Hannover) Comment A reference to a gazetteer or gazetteers or other encoding scheme used for the geographic identifier should be given. The gazetteer or encoding schema has to be identificable. A.2.4 Resource language Metadata element name Resource language ISO definition Language(s) used within the datasets ISO 19115 number and name 39 language ISO TS 19139 path identificationInfo/*/language/*/text() Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 51 of 104 INSPIRE obligation / condition C (mandatory when there is textual information in the resource) INSPIRE multiplicity [0..*] Data type Code list Domain Free text (preferable use of ISO 639-2 but other parts may be used) Implementing instructions In INSPIRE environment, use only three-letter codes defined in ISO639-2/B (bibliographic codes), defined at http://www.loc.gov/standards/iso639-2/. Example The list of codes for the 20 official EU languages specified at http://europa.eu/abc/european_countries/languages/ is: Czech – cze Danish – dan Dutch – dut English – eng Estonian – est Finnish – fin French – fre German – ger Greek – gre Hungarian – hun Italian – ita Latvian – lav Lithuanian – lit Maltese – mlt Polish – pol Portuguese – por Slovak – slo Slovenian – slv Spanish – spa Swedish – swe The following addition is announced for 1 January 2007: Irish – gle Comment In the case INSPIRE the concepts datasets can in this case be extended to also cover services i.e. the definition of the element is: Language(s) used within the resource A.2.5 Resource topic category Metadata element name Resource topic category ISO definition Main theme(s) of the dataset ISO 19115 number and name 41 topicCategory ISO TS 19139 path identificationInfo/*/topicCategory/*/text() INSPIRE obligation / condition C (mandatory for datasets and dataset series) INSPIRE multiplicity [0..*] Data type Code list Domain Code list B.5.27 in Annex B of ISO 19115:2003 Implementing instructions Annex E defines the mapping from the INSPIRE spatial data themes to the ISO dataset topic category. Example boundaries Comment Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 52 of 104 A.2.6 Keyword Metadata element name Keywords ISO 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 MD_Metadata.identificationInfo>MD_Identification.descriptiveKe ywords>MD_Keywords.keywords identificationInfo/*/descriptiveKeywords/*/keyword//text() INSPIRE obligation / condition M INSPIRE multiplicity [1..*] Data type CharacterString Domain Free text Implementing instructions Example Sweden, climatological data Comment A thesaurus will be recommended A.2.7 Service type Metadata element name Geographic service ISO definition A service type name from a registry of services. ISO 19119 name serviceType CSW2 AP ISO path MD_Metadata.identification.SV_ServiceIdentification.serviceType identificationInfo/*/serviceType//text() INSPIRE obligation / condition C (mandatory if a service is available) INSPIRE multiplicity [0..*] Data type Free text Domain CharacterString Implementing instructions Specify a service type in a standardized format (ISO code list) Example WMS WFS WCS Comment It is recommended to make use of a code list instead of a character string. This code list describes all the possible service types. When everyone uses this code list the user find all the services with “WMS” (instead of “Web Mapping Service”, “OGC_WMS” or “web mapping service“). Such a code list has to implemented and maintained as an electronic service by an authoritative organisation. NOTE: Possible values of this code list will be defined by DT Network services and referred by this IR. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 53 of 104 A.2.8 Resource responsible party A.2.8.1 Resource responsible party – individual name Metadata element name Resource responsible party – individual name ISO definition Name of the responsible person - surname, given name, title separated by a delimiter ISO 19115 number and name 375 individualName ISO TS 19139 path identificationInfo// pointOfContact// individualName/*/text() INSPIRE obligation / condition M (organisation name or individual name is mandatory) INSPIRE multiplicity [1..*] Data type CharacterString Domain Free text Implementing instructions Use the full name of the responsible person. Example Smith, John Comment A.2.8.2 Resource responsible party – organisation name Metadata element name Resource responsible party – organisation name ISO definition name of the responsible organisation ISO 19115 number and name 376 organisationName ISO TS 19139 path identificationInfo// pointOfContact// organisationName/*/text() INSPIRE obligation / condition M (organisation name or individual name is mandatory) INSPIRE multiplicity [1..*] Data type Character string Domain Free text Implementing instructions Use the full name of the responsible organisation. The abbreviations can be in addition to the organisation name. Example European Commission Directorate General Joint Research Centre (JRC) Comment A.2.8.3 Resource responsible party – role Metadata element name Resource responsible party – role ISO definition function performed by the responsible party ISO 19115 number and name 379 role ISO TS 19139 path identificationInfo// pointOfContact// role/*/text() INSPIRE obligation / condition M INSPIRE multiplicity [1] Data type code list Domain code list B.5.5 Implementing instructions Example Owner Comment Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 54 of 104 A.2.9 Abstract Metadata element name Abstract ISO definition Brief narrative summary of the content of the resource(s) ISO 19115 number and name 25 abstract ISO TS 19139 path identificationInfo// abstract/*/text() INSPIRE obligation / condition M INSPIRE multiplicity [1] Data type CharacterString Domain Free text Implementing instructions Example Dataset contains large scale (1:1.000) topography, which covers the whole country Comment A.2.10 Resource locator A.2.10.1 Resource locator – linkage Metadata element name Resource locator – linkage ISO 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/*/text() INSPIRE obligation / condition C (When a linkage to the resource or a contact point for more information about the resource is available) INSPIRE multiplicity [0..*] Data type URL Domain URL (IETF RFC1738 IETF RFC 2056) Implementing instructions Specify a valid URL to a dataset/dataset series or a service. If no direct link to a resource is available, provide link to a point of contact where more information about the resource is available. Example http://www.geonorge.no Comment A.2.10.2 Resource locator – connect point Metadata element name Resource locator - connect point ISO definition Handle for accessing the service interface. ISO 19119 name connectPoint CSW2 AP ISO path identificationInfo// containsOperations// connectPoint// linkage/*/text( INSPIRE obligation / condition C (mandatory if the resource is a service) INSPIRE multiplicity [0..*] Data type CharacterString Domain URL Implementing instructions Example http://www.geoserver.nrw.de/ GeoOgcWms1.3/servlet/GEPNRW Comment Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 55 of 104 A.3 Abstract discovery metadata element set – Discovery level - 2 A.3.1 Constraints A.3.1.1 Constraints – Access Metadata element name Constraints - Access ISO definition Access constraints applied to assure the protection of privacy or intellectual property, and any special restrictions or limitations on obtaining the resource or metadata ISO 19115 number and name 70 accessConstraints ISO TS 19139 path //identificationInfo//resourceConstraints//accessContraints/*/text() INSPIRE obligation / condition C (mandatory when there are constraints regarding access or usage) INSPIRE multiplicity [0..*] Data type Code list Domain Code list B.5.24 in Annex B of ISO 19115:2005 Implementing instructions Example copyright Comment An empty element means that there are no access constraints. A.3.1.2 Constraints – use limitations Metadata element name Constraints – use limitations ISO definition Limitation affecting the fitness for use of the resource or metadata. ISO 19115 number and name 68 useLimitations ISO TS 19139 path //identificationInfo//resourceConstraints//useLimitation/*/text() INSPIRE obligation / condition C (mandatory when there are constraints regarding access or usage) INSPIRE multiplicity [0..*] Data type CharacterString Domain Free text Implementing instructions Example Not to be used for navigation Comment A.3.2 Lineage Metadata element name Lineage ISO 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 C (when a quality report or other lineage statements are required) INSPIRE multiplicity [0..1] Data type CharacterString Domain Free text Implementing instructions In addition to general explanation of the data producer’s knowledge about the lineage of a dataset it’s possible to give here data quality statements. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 56 of 104 Example In this dataset, the boundaries between the North Sea and the provinces are the borders between land and water, not the administrative boundaries Comment A.3.3 Conformity Metadata element name Conformity ISO definition 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 ISO 19115 number and name 107 result ISO TS 19139 path //dataQualityInfo//DQ_DomainConsistency//result INSPIRE obligation / condition C (mandatory for datasets and dataset series) INSPIRE multiplicity [0..*] Data type Code list Domain Code list implemented as an URI for INSPIRE Implementing instructions Example http://www.inspire.eu/conformance Comment A.3.4 Service type version Metadata element name serviceTypeVersion ISO definition Specify the version number of a well known service type ISO 19119 name serviceTypeVersion CSW2 AP ISO path //identificationInfo//serviceTypeVersion INSPIRE obligation / condition C (mandatory if the resource is a well-known service type) INSPIRE multiplicity [0..*] Data type CharacterString Domain Free text Implementing instructions Versions separated by . No . at the end Example 1.1.0 Comment Provides for evaluation based on the version of serviceType. For example, a user may only be interested in OGC Catalogue services with version 2.0.1. A.3.5 Operation name Metadata element name operationName ISO definition A unique identifier for this interface. ISO 19119 name operationName CSW2 AP ISO path // identificationInfo// containsOperations// operationName/*/text() INSPIRE obligation / condition C (mandatory if the resource is a service) INSPIRE multiplicity [0..*] Data type CharacterString Domain Free text Implementing instructions Can be related with serviceType and serviceTypeVersion. Defaults can be loaded automatically by application. There Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 57 of 104 should be a possibility to add additional operations. Example GetCapabilities, GetMap, GetRecords Comment A.3.6 Distributed computing platform Metadata element name Distributed computing platform ISO definition Distributed Computing Platforms on which the operation has been implemented. ISO 19119 name DCP CSW2 AP ISO path // identificationInfo//containsOperations//DCP/*/text() INSPIRE obligation / condition C (mandatory if the resource is a service) INSPIRE multiplicity [0..*] Data type CharacterString Domain Code list Implementing instructions Example WebServices Comment A.3.7 Resource Identifier Metadata element name Resource identifier ISO definition value uniquely identifying an object within a namespace ISO 19115 number and name 207 code ISO TS 19139 path /identificationInfo// citation//identifier//code INSPIRE obligation / condition C (mandatory if an identifier is available) INSPIRE multiplicity [0..1] Data type CharacterString Domain Free text Implementing instructions Example 527c4cac-070c-4bca-9aaf-92bece7be902 Comment A.3.8 Spatial resolution A.3.8.1 Equivalent scale Metadata element name Equivalent scale ISO definition level of detail expressed as the scale of a comparable hardcopy map or chart ISO 19115 number and name 60 equivalentScale ISO TS 19139 path //identificationInfo//spatialResolution//equivalentScale//denomina tor INSPIRE obligation / condition C (mandatory for datasets and dataset series for which a unique equivalent scale or resolution distance can be specified ) INSPIRE multiplicity [0..1] Data type Integer Domain > 0 Implementing instructions Example 50000 Comment Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 58 of 104 A.3.8.2 Resolution distance Metadata element name Resolution distance ISO definition ground sample distance ISO 19115 number and name 61 distance ISO TS 19139 path //identificationInfo//spatialResolution//distance INSPIRE obligation / condition C (equivalent scale or resolution distance has to be mandatory for dataset and dataset series) INSPIRE multiplicity [0..1] Data type Integer Domain Metres Implementing instructions Example 3.0 Comment A.4 Metadata on metadata A.4.1 Metadata point of contact A.4.1.1 Metadata point of contact – individual name Metadata element name Metadata point of contact – individual name ISO definition Name of the responsible person - surname, given name, title separated by a delimiter ISO 19115 number and name 375 individualName ISO TS 19139 path ./contact//individualName INSPIRE obligation / condition M (organisation name or individual name is mandatory) INSPIRE multiplicity [1..*] Data type CharacterString Domain Free text Implementing instructions Use the full name of the responsible person. Example Smith, John Comment A.4.1.2 Metadata point of contact – organisation name Metadata element name Metadata point of contact – organisation name ISO definition Name of the responsible organisation ISO 19115 number and name 376 organisationName ISO TS 19139 path ./contact//organisationName INSPIRE obligation / condition M (organisation name or individual name is mandatory) INSPIRE multiplicity [1..*] Data type CharacterString Domain Free text Implementing instructions Use the full name of the responsible organisation. The abbreviations can be in addition to the organisation name. Example European Commission Directorate General Joint Research Centre (JRC) Comment Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 59 of 104 A.4.1.3 Metadata point of contact – role Metadata element name Metadata point of contact – role ISO definition Function performed by the responsible party ISO 19115 number and name 379 role ISO TS 19139 path ./contact//role INSPIRE obligation / condition M INSPIRE multiplicity [1] Data type CharacterString Domain Code list B.5.5 in Annex B of ISO 19115:2005 Implementing instructions Example owner, distributor or pointOfContact Comment A.4.2 Metadata date stamp Metadata element name Metadata date stamp ISO definition Date that the metadata was created ISO 19115 number and name 9 dateStamp ISO TS 19139 path .//dateStamp INSPIRE obligation / condition M INSPIRE multiplicity [1] Data type Date Domain ISO 8601 Implementing instructions Example 2005-03-27 (YYYY-MM-DD) Comment A.4.3 Metadata language Metadata element name Resource language ISO definition Language used for documenting metadata ISO 19115 number and name 3 language ISO TS 19139 path .//language INSPIRE obligation / condition C (mandatory if not defined by the encoding) INSPIRE multiplicity [0..1] Data type Code list Domain Free text (preferable use of ISO 639-2 but other parts may be used) Implementing instructions Member states should check if their language is represented on this list. Example dut, nor Comment Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 60 of 104 Annex B Dublin Core implementation of discovery level-1 B.1 Resource title Metadata element name Resource title DC definition A name given to the resource. DC label Title DC path dc:title INSPIRE obligation / condition Mandatory INSPIRE multiplicity [1] Data type SimpleLiteral Domain Implementing instructions Example Mastermap DC comment Typically, a Title will be a name by which the resource is formally known. B.2 Reference date B.2.1 Extent - temporal extent Metadata element name Extent – temporal extent DC definition Temporal characteristics of the intellectual content of the resource. DC label Temporal DC path dcterms:temporal INSPIRE obligation / condition C (mandatory when it is meaningful for discovering and selecting the resource) INSPIRE multiplicity [0..1] Data type datetime (ISO 8601) Domain http://www.w3.org/TR/NOTE-datetime Implementing instructions DCMI Period (dcterms:period), W3CDTF (dcterms:W3CDTF) DCMI Period and W3CDTF are syntax encoding schemes, not elements or refinements. Example 1977-03-10 (YYYY-MM-DD) 2005-01-15 (YYYY-MM-DD) DC comment B.2.2 Date Metadata element name Date - date DC definition A date associated with an event in the life cycle of the resource. DC label Date DC path dc:date INSPIRE obligation / condition M INSPIRE multiplicity [1] Data type datetime (ISO 8601) Domain http://www.w3.org/TR/NOTE-datetime Implementing instructions W3CDTF (dcterms:W3CDTF) Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 61 of 104 Example 1993-01-24 (YYYY-MM-DD) DC comment Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format. B.2.3 Date – publication Metadata element name Date – publication DC definition Date of formal issuance (e.g., publication) of the resource. DC label Issued DC path dcterms:issued INSPIRE obligation / condition C (Mandatory if a date- creation or date - revision not used) INSPIRE multiplicity [0..1] Data type datetime (ISO 8601) Domain http://www.w3.org/TR/NOTE-datetime Implementing instructions W3CDTF (dcterms:W3CDTF) Example 1977-03-10 (YYYY-MM-DD) DC comment B.2.4 Date – revision Metadata element name Date – revision DC definition Date on which the resource was changed. DC label Modified DC path dcterms:modified INSPIRE obligation / condition C (Mandatory if a date- creation or date - publication not used) INSPIRE multiplicity [0..1] Data type datetime (ISO 8601) Domain http://www.w3.org/TR/NOTE-datetime Implementing instructions W3CDTF (dcterms:W3CDTF) Example 1977-03-10 (YYYY-MM-DD) DC comment B.2.5 Date – creation Metadata element name Date – creation DC definition Date of creation of the resource. DC label Created DC path dcterms:created INSPIRE obligation / condition C (Mandatory if a date- publication or date - revision not used) INSPIRE multiplicity [0..1] Data type datetime (ISO 8601) Domain http://www.w3.org/TR/NOTE-datetime Implementing instructions W3CDTF (dcterms:W3CDTF) Example 1977-03-10 (YYYY-MM-DD) DC comment - Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 62 of 104 B.3 Geographic extent of the resource In Dublin Core, the geographic extent of the resource can be defined using either a bounding box or a geographic identifier.17 Metadata element name Geographic extent of the resource DC definition Spatial characteristics of the intellectual content of the resource. DC label Spatial DC path dcterms:spatial INSPIRE obligation / condition C INSPIRE multiplicity [0..1] (1 bounding box) Data type CharacterString Domain -180.0 <= West Bounding Longitude Value <= 180.0 -180.0 <= East Bounding Longitude Value <= 180.0 -90.0 <= South Bounding Latitude Value <= 90.0; South Bounding Latitude Value <= North bounding Latitude Value -90.0 <= North Bounding Latitude Value <= 90.0; North Bounding Latitude Value >= South Bounding Latitude Value Implementing instructions See http://dublincore.org/documents/dcmi-box/ for instructions Examples Western Australia: name=Western Australia; northlimit=-13.5; southlimit=-35.5; westlimit=112.5; eastlimit=129 The Western Hemisphere: westlimit=180; eastlimit=0 The Tropics: northlimit=23.5; southlimit=-23.5 Metadata element name Geographic extent of the resource DC definition Spatial characteristics of the intellectual content of the resource. DC label Spatial DC path dcterms:spatial INSPIRE obligation / condition C INSPIRE multiplicity [0..1] Data type CharacterString Domain Free Text Implementing instructions A geographic identifier shall be assigned on basis of a documented and generally accessible gazetteer service, code system, or other indirect spatial reference system. Example City of London .......... (borough) (World, Europe, United Kingdom, England, Greater London, London) [7018906] NB. In Dublin Core the datatype of both variants above is CharacterString. The fact that DCMI Box is specified as the encoding scheme allows the receiver to interpret the string as a structured value according to the DCMI Box syntax. 17 It is not possible to define the geographic extent by using a bounding polygon. This is only possible in ISO 19115 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 63 of 104 B.4 Resource language Metadata element name Resource language DC definition A language of the intellectual content of the resource. DC label Language DC path dc:language INSPIRE obligation / condition C (mandatory when there is textual information in the resource) INSPIRE multiplicity [0..*] Data type SimpleLiteral Domain Implementing instructions In INSPIRE environment, use only three-letter codes defined in ISO639-2/B (bibliographic codes), defined at http://www.loc.gov/standards/iso639-2/. Example The list of codes for the 20 official EU languages specified at http://europa.eu/abc/european_countries/languages/ is: Czech – cze Danish – dan Dutch – dut English – eng Estonian – est Finnish – fin French – fre German – ger Greek – gre Hungarian – hun Italian – ita Latvian – lav Lithuanian – lit Maltese – mlt Polish – pol Portuguese – por Slovak – slo Slovenian – slv Spanish – spa Swedish – swe The following addition is announced for 1 January 2007: Irish – gle DC comment Recommended best practice is to use RFC 3066 [RFC3066], which, in conjunction with ISO 639 [ISO639], defines two- and three-letter primary language tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian, and "en-GB" for English used in the United Kingdom. B.5 Resource topic category Metadata element name Resource topic category DC definition The topic of the content of the resource. DC label Subject and Keywords DC path dc:subject INSPIRE obligation / condition C (mandatory for datasets and dataset series) INSPIRE multiplicity [0..*] Data type SimpleLiteral Domain Implementing instructions Take values from the enumeration class MD_TopicCategory defined by ISO 19115 Example boundaries Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 64 of 104 DC comment Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme. B.6 Keyword Metadata element name Keyword DC definition The topic of the content of the resource. DC label Subject and Keywords DC path dc:subject INSPIRE obligation / condition C (mandatory for datasets and dataset series) INSPIRE multiplicity [0..*] Data type SimpleLiteral Domain Implementing instructions Example Sweden, climatological data DC comment Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme. B.7 Service type Metadata element name Geographic service DC definition The nature or genre of the content of the resource. DC label Type DC path dc:type INSPIRE obligation / condition C (mandatory if a service is available) INSPIRE multiplicity [0..*] Data type SimpleLiteral Domain Implementing instructions Always use an instance of dc:type with an appropriate value taken from the DCMI Type Vocabulary (e.g. Service, Dataset etc.). See: http://dublincore.org/documents/dcmi-terms/#H5. If the type is Service, repeat dc:type with a service type in a standardized format (ISO code list) Example WMS, WFS, WCS DC comment Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMI Type Vocabulary). To describe the physical or digital manifestation of the resource, use the Format element. B.8 Resource responsible party To express the role of people and organizations related to the resources, Dublin Core has three elements: dc:creator, dc:contributor and dc:publisher. The elements dc:contributor and dc:publisher can be further refined using relator terms that are maintained by the Library of Congress (See: http://memory.loc.gov/cocoon/loc.terms/relators/dc-relators.html). The following mapping can be used between ISO 19115 role codes and relators: ISO 19115 Code Relator term Refined Dublin Core Element resourceProvider http://www.loc.gov/loc.terms/relators/APP (Applicant) Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 65 of 104 custodian http://www.loc.gov/loc.terms/relators/RPY (Responsible party) dc:contributor owner http://www.loc.gov/loc.terms/relators/OWN (Owner) dc.contributor (see note) user 18 http://www.loc.gov/loc.terms/relators/CMM (Commentator) dc:contributor distributor http://www.loc.gov/loc.terms/relators/DST (Distributor) dc:publisher originator http://www.loc.gov/loc.terms/relators/ORG (Originator) dc:contributor pointOfContact http://www.loc.gov/loc.terms/relators/EXP (Expert) dc.contributor (see note) principalInvestigator http://www.loc.gov/loc.terms/relators/ORG (Originator) dc:contributor processor http://www.loc.gov/loc.terms/relators/CTB (Contributor) dc:contributor publisher http://www.loc.gov/loc.terms/relators/PBL (Publisher) dc:publisher author http://www.loc.gov/loc.terms/relators/AUT (Author) dc:contributor Note: The relators ‘Owner’ and ‘Expert’ (corresponding to the ISO 19115 role codes owner and pointOfContact) have no pre-defined refinement relationship with Dublin Core elements. In the case of INSPIRE, these should both be defined as refinements of dc:contributor. B.9 Abstract Metadata element name Abstract DC definition A summary of the content of the resource. DC label Abstract DC path dcterms:abstract INSPIRE obligation / condition M INSPIRE multiplicity [1] Data type SimpleLiteral Domain Implementing instructions Example Dataset contains large scale (1:1.000) topography, which covers the whole country DC comment B.10 Resource locator Metadata element name Resource locator DC definition An unambiguous reference to the resource within a given context. DC label Identifier DC path dc:identifier INSPIRE obligation / condition C (mandatory when the resource or more information about the resource is available) INSPIRE multiplicity [0..*] Data type SimpleLiteral Domain URI 18 This role is mostly dedicated to the documentation of user feedback (e.g., through the MD_Usage class of ISO 19115). In this context, the inputs of the user are comments about the use of the resource. So, the user can be considered as a Dublin Core commentator. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 66 of 104 Implementing instructions Example http://www.geonorge.no DC comment Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Example formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL)), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN). Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 67 of 104 Annex C Comparison of INSPIRE directive requirements and corresponding abstract discovery metadata set In articles 5, 8 and 11, the INSPIRE directive specifies which information about a spatial resource (spatial data set, spatial data set series, service) should be provided by a set of metadata. This Annex gives a comparison of INSPIRE directive requirements and corresponding abstract metadata set. Table C.1 - Comparison of INSPIRE directive requirements and corresponding abstract metadata set Requirement of INSPIRE Directive Corresponding abstract metadata element Discovery metadata category The conformity of spatial data sets with the implementing rules referred to in Article 7(1); (Art. 5-2 (a) and Art. 11-2 (d)) See Annex F Discovery level 2 Conditions applying to access to, and use of, spatial data sets and services (Art. 11-2(f)), and where applicable, corresponding fees; (Art. 5-2 (b)) Constraints (access and use limitations) Discovery level 2 Quality and validity of spatial data; (Art. 5-2 (c) and 11-2c)) See Annex G Public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services; (Art. 5-2(d) and 11-2(g)) Resource responsible party Discovery level 1 Limitations on public access and the reasons for such limitations in accordance with Article 13 (Art. 5-2(e)) Constraints (access) Discovery level 2 Keywords describing a resource (Art. 11- 2 (a)) Keyword Discovery level 1 Classification of spatial data and services (Art. 11-2 (b)) Resource topic category Service type Discovery level 1 Geographical location; (Art. 11- 2 (e)) Geographic extent of the resource Discovery level 1 Temporal domain; (Art 8-2 (d)) 19 Temporal extent of the resource Discovery level 1 19 The Directive mentions “information on the temporal domain of the data” in Chapter III Article 8.2 (d), on the Interoperability of Spatial Data sets and Services, though not in Chapter II on Metadata. It also includes themes which are completely time dependent in Annex III (13, Atmospheric conditions; 14, Meteorological geographic features and 15, Oceanographic geographic features) and in Annex II (theme 4, Geology). These themes have primary requirements for metadata on temporal extent for discovery purposes. Other themes may have less or no need of temporal extent for discovery. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 68 of 104 Annex D Applicability of the available standards D.1 Introduction ISO/TC 211 and OGC have both initiated an important standardisation activity related to geographic information and more generally spatial information. If OGC and ISO/TC 211 have their own autonomy and have undertaken overlapping work by the past, a close co-ordination ensures today the consistency between the respective standards. More and more OGC Implementation Specifications are revised by joint ISO/TC 211 and OGC project teams guaranteeing the equivalence of the OGC and ISO publications. OGC Implementation specifications will be referenced hereafter only when they have not been published as ISO standards yet. The geographic information standards applicable to these Implementing Rules can be seen as presented in Figure D.1. Foundation Standards Discovery Evaluation Use Figure D.1 – Overview of the geographic information standards Different implementation standards presented in D.4 serve the different discovery, evaluation and use requirements. They act on a set of conceptual standards through rules for application schema documented in ISO 19109 and summarised in D.3. In the context of these Implementation Rules, the conceptual standards comprise: - Foundation standards providing base data types (see D.2.2); - Metadata standards satisfying fully the discovery and evaluation requirements, but partially the use requirements (see D.2.1); - Complementary standards involved in the use scenario (see D.2.3). D.2 Conceptual Spatial Standards D.2.1 Conceptual metadata standards for spatial resources ISO 19115 specifies a conceptual schema for geospatial information metadata covering the different metadata sections defined in section 4.1. It is the keystone of these Implementing Rules and is consequently applicable with the following restriction. A set of minor Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 69 of 104 inconsistencies related directly to ISO 19115 have been reported in ISO 19115/Cor.1 which also defines how to interpret them. ISO 19115/Cor.1 supersedes ISO 19115. ISO 19115/Cor.1 is particularly important when dealing with spatial services. The class MD_ServiceIdentification has been renamed SV_ServiceIdentification for consistency with ISO 19119 which defines a full conceptual schema for spatial service metadata. The root of this conceptual schema is SV_ServiceIdentification which creates a strong link between ISO 19115 and ISO 19119. ISO 19119 is applicable to these Implementing Rules when dealing with spatial services. The quality principles documented in ISO 19113 have driven the establishment of ISO 19115 conceptual schema, particularly but not only its quality section. These quality principles have to be followed when quality information is included in the metadata. ISO 19114 standard specifies a methodology for evaluating the quality of geographic information and expresses requirements in term of reporting of the evaluation results. It is acknowledged for the goodness of geographic information users that the quality evaluation proceeded by the managers of the spatial information is generally not provided in details within the metadata. As a result, several quality measures can be aggregated into a single quality measure which is reported in the metadata while the other quality measures have to be expressed in a quality report. ISO/CD 19115-2 [9] is not applicable in this version of the Implementing Rules because the draft specification is not mature enough. This does not impact the discovery activity, but the minimum cataloguing requirements expressed in this version of the Implementing Rules excludes the imagery specificity. D.2.2 Conceptual Spatial foundation standards The conceptual schema for metadata resources defined through ISO 19115 and ISO 19119 are based on the following foundation standards: - ISO/TS 19103 defines the conceptual schema language of the ISO 19100 series of standards including ISO 19115 and ISO 19119. It specifies a set of basic types widely used in conceptual schemas of the ISO 19100 series of standards. - ISO 19107 defines particularly a set of geometric primitives used in ISO 19115, for example for describing the spatial extent of a metadata resource. - ISO 19108 defines particularly a set of temporal primitives used in ISO 19115, for example for describing the temporal extent of a metadata resource. The part of those standards involved in the implementation of ISO 19115 and ISO 19119 are applicable to these Implementing Rules. D.2.3 Complementary Conceptual Spatial standards The conceptual schema defined by ISO 19115, ISO 19119 and the foundation standards (see D.2.2) fully addresses the discovery and evaluation requirements. As soon as the use of the data is envisioned, it is necessary to consider complementary conceptual Spatial standards. Typically: - ISO 19115 in its content information section allows the citation of feature catalogues, but the conceptual schema of feature catalogues is defined in ISO 19110. - ISO 19115 provides in its reference system information section a means for identification of the reference systems applicable to a resource, but the conceptual schema for spatial reference using coordinates is defined in ISO 19111 and the conceptual schema for spatial reference by identifiers is defined in ISO 19112; - ISO 19115 in its portrayal catalogue information section allows the citation of portrayal catalogues, but the conceptual schema of a portrayal catalogues is defined in ISO 19117. The applicability of those complementary conceptual standards is limited to the use activity of the INSPIRE Metadata Use Case. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 70 of 104 - ISO/CD2 19130 extends ISO 19115-2 [9] with a conceptual schema for sensor and data modelling which would be necessary for computation of the location of the cells of non georectified imagery. - ISO/TS 19139 define conceptual extensions of ISO 19115 which are particularly relevant in a use scenario. It is consequently seen as a complementary conceptual standards even if it is primary an implementation standards and if it addresses also discovery and evaluation requirements D.3 Metadata applications D.3.1 Interchange models ISO 19109 defines two interchange models: - In the traditional data transfer model, the data supplier creates a dataset that is transferred to the user. The structure and the content of data are described in the application schema for the dataset. The dataset is sent in a transfer format. - In the interoperability model, the user application communicates with the supplier application through a common communication protocol. In this scenario, the user invokes services that result in data being passed from the service provider to the user application. The application schema describes not only the structure and content of the exchanged data but also the structure of the interfaces involved in the transaction. The key issue in the traditional data transfer models is the organisation of the datasets. It is generally as complex as the potential uses that the provider envisioned (while the users generally do not find in the dataset all the expected information). A well defined structure of the dataset is necessary to help the interpretation of the dataset by the user applications. The aspects of organisation of the datasets are generally twofold: - the structure of the dataset is its organisation in spatial datasets and aggregation of spatial datasets, as well as their interrelation with their metadata entity sets and related information (feature catalogues, portrayal catalogues, …); - the content of the dataset is defined by the conceptual schemas defined by the standards described in D.2 and the definition of its feature types which is potentially documented in the feature catalogues. These two organisational aspects are detailed respectively in D.3.2 and D.3.3. In the interoperability model the structure of the exchanged data is generally deeply reduced to a minimum hiding the underlying structure of the spatial data managed in the repository to which the services provide access. So the focus is, on one hand on the exchanged data content with a lot of similarity with the transfer model (see D.3.3), and on the other hand on the structure of the interfaces. D.3.2 Data Structure Application schema Figure 3 of ISO 19115 is a UML class diagram defining the classes of geographic information to which metadata applies. More particularly, it specifies that: - a spatial dataset (DS_DataSet) must have one or more related metadata entity sets (MD_Metadata). - a spatial dataset aggregates (DS_Aggregate) is composed of one or more datasets and can be a superset or a subset of other spatial dataset aggregates. A dataset aggregate must have one or more related Metadata entity sets. This base data structure application schema is illustrated in Figure D.2. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 71 of 104 MD_Metadata (from ISO 19115 - Metadata entity set information) DS_Dataset (from ISO 19115 - Metadata application schema) DS_Aggregate (from ISO 19115 - Metadata application schema) <> + partOf 0..* + composedOf 1..* + describes0..* + has 1..* +seriesMetadata1..* +series0..* +superset 0..* 0..* +subset MultipleAggregation Figure D.2 – Base application schema for spatial datasets and aggregates ISO/TS 19139 goes a bit further by defining a Standard Transfer Interchange Structure presented in Figure D.3. MD_Metadata (from Metadata entity set information) DS_Aggregate (from Metadata application information) <> DS_Dataset (from Metadata application information) +seriesMetadata 1..* +superset 0..* +subset 0..* MultiAggregation +series 0..* +partOf +composedOf0..* 1..* +describes 0..* +has 1..* MX_Aggregate MX_Dataset CT_Catalogue (from Catalogue) +datasetCatalogue +aggregateCatalogue 0..* 0..* 0..* 0..* 1 +dataFile1..* MX_DataFile +supportFile 0..* MX_SupportFile +aggregateFile 0..* Figure D.3 – Standard Transfer Interchange Structure The transfer dataset (MX_Dataset) data is organised in data files (MX_DataFile). Both transfer datasets and aggregates may be accompanied by support files (MX_SupportFile) which may contain resources needed to exploit them or complementary information. The data files and the support files are described in section 7.4.3 of ISO/TS 19139. In practice, the information needed to exploit a spatial dataset or an aggregate is not limited to their metadata. Particularly: - the metadata cites the feature and portrayal catalogues but does not embed them; - the metadata instances reference information such as codelists, unit of measures and coordinate reference systems that all need to be accessed. All of those resources may be managed externally in on-line registries, but it is usually necessary, in the context of interchange by transfer, to be able to provide that information within the transfer datasets and transfer aggregates. The abstract concept of catalogue (CT_Catalogue) corresponds exactly to those resources needed to exploit the datasets, aggregates and their metadata. This concept is more deeply detailed in D.3.3. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 72 of 104 D.3.3 Data Content Application schema ISO 19109 defines a General Feature Model that defines how metadata and quality elements relate to geographic features. This interrelation is considered more widely in the overall context of the specification Implementing Rules and is not discussed hereafter. The concept of catalogue introduced in D.3.2 is detailed in section 7.4.4 of ISO/TS 19139 which also proposes three concrete subtypes: - CRS catalogue (CT_CrsCatalogue) contains the description of the Coordinate Reference Systems used in the transfer dataset or transfer aggregate as well as the description of their components (datum, coordinate system, etc.); - An UoM catalogue (CT_UomCatalogue) contains the description of the Units of Measure used in the transfer dataset or transfer aggregate. - A codelist catalogue (CT_CodelistCatalogue) contains the description of the codelists used in the transfer dataset or transfer aggregate, including their name, definition as well as the description of their values; The abstract concept of catalogue has also been defined as the basis for harmonisation of the different ISO 19100 series catalogue concepts, such as PF_PortrayalCatalogue (ISO 19117) and FC_FeatureCatalogue (ISO 19110). It is potentially the root concept of any set of information related to spatial resources (e.g., quality measures, …). The abstract concept of catalogue has been defined in the specific context of data interchange by transfer, but it is also applicable more widely to interchange by transaction either through a general access services to catalogues or through access services dedicated to each of the individual types of catalogues (portrayal, feature, …). D.4 The Implementation Standards D.4.1 Overview The INSPIRE Metadata Use Case implies the existence of a range of repositories which have to be managed by the managers and accessed by the users. A repository can be implemented within a registry as a set of registers. This should conform to ISO 19135 in order to ease the management of the repository content, but the main concern of these Implementing Rules is the way the content of the repository can be accessed. First, concepts described in D.2 and more generally the concepts expressed in the application schema have to be formatted, preferably using a standard encoding (see D.4.2). The encoded data can then be stored on local or remote locations or be accessed via services. Standard service specifications are described in D.4.3. D.4.2 Standard encoding ISO/TS 19139 defines a set of encoding rules which can generally be applied to any of the spatial conceptual standards. It proposes an XML Schema Implementation of ISO 19115 and the parts of the conceptual foundation standards involved when implementing ISO 19115. CSW2 AP ISO proposes an XML Schema Implementation of ISO 19119 based on ISO/TS 19139 encoding rules. ISO/TS 19139 also propose a standard encoding of CRS catalogues, Catalogues of Unit of Measures and code list catalogues. These ISO/TS 19139 based XML Schema implementations are applicable to interchanges of metadata and related information by transfer. They are also applicable more generally for a local or remote storage of the information when they are not accessed via a standard service. It is also recommended that XML Schemas implementation based on ISO/TS 19139 encoding rules should be adopted when no standard XML Schema Implementation are available. A standard XML Schema implementation is expected through an amendment of ISO 19110, but there are already some valid XML Schema Implementations of ISO 19110 available. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 73 of 104 For interchanges by transmission, the implementation of the service interface is generally part of the service specification. D.4.3 Standard service specifications CSW 2.0 is the reference service specification for discovery, evaluation and use. It proposes an XML encoding based on a profile of Dublin Core which is suitable for discovery. More generally, a service compliant to the base CSW 2.0 will address discovery requirements. It is necessary to use CSW 2.0 application profiles to go further: - CSW2 AP ISO is an ISO 19115/ISO 19139 application profile of CSW 2.0. It is based on an ISO/TS 19139 compliant encoding of ISO 19115 and ISO 19119. It addresses evaluation requirements and it is applicable in this context. - OGC is working on an application profile of CSW 2.0 for accessing the content of on-line registers. - OGC is also working on an application profile of CSW 2.0 based on the ebRIM Standard of the OASIS Consortium. These two last application profiles are not mature enough to be recommended. There are also some on-going work within OGC to define a way to access any kind of data through WFS. D.5 Other applicable standards D.5.1 Dublin Core Dublin Core is an international initiative focusing on discovery aspect of metadata for information. The initiative has gained a broad cross-sectoral support and Dublin Core Metadata Element Set have been published in 2003 as the ISO 15836 standard. The wide use of Dublin Core does not limit the importance of sector-specific metadata standards such as ISO 19115. Metadata repositories of spatial resources are generally not set up to address discovery only requirements and Dublin Core metadata elements will not satisfy the wide range of requirements covered by the INSPIRE Metadata Use Case. Yet, the interface between the INSPIRE community and the overall European Community has to be considered. The PSI Directive applies to spatial information and it is important not to duplicate the existing effort for documenting public resources. These Implementing Rules define in Annex B specific rules for expressing an INSPIRE Profile of Dublin Core called the INSPIRE Core. The INSPIRE Core ensures a common Dublin Core expression of metadata for spatial resources. This INSPIRE Core is compatible with the OGC Core defined in CSW 2.0 and these Implementing Rules adopt the XML encoding of the OGC Core has defined in CSW 2.0. The availability of a CSW 2.0 service delivering the content of a repository of metadata for spatial resources in OGC Core is not required, but it may be implied by the PSI Directive. D.5.2 Other ISO standards Different ISO standards are applicable in the conditions defined by ISO 19115, typically: - ISO 639-2 three letter codes for the expression of languages; ISO/IEC 2382-1:1993,Information technology – Vocabulary – Part 1: Fundamental terms - ISO 8601 for the expression of date and times. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 74 of 104 Annex E Mapping of the INSPIRE spatial data themes to code list B.5.27 of ISO 19115 In principle, all INSPIRE spatial data themes can be mapped to code list B.5.27 of ISO 19115. Table E.1 suggests a mapping between the ISO 19115 topic categories and the INSPIRE spatial data themes. It should be noted that the INSPIRE spatial data themes may change in title and definition over time. This mapping is based on the proposal for the INSPIRE directive 10553/05 of 29 June 2005, Brussels. The annexes mentioned in Table E.1 refer to those in the proposal for the INSPIRE directive. Table E.1 - Mapping of the INSPIRE spatial data themes Name (ISO 19115) INSPIRE spatial data themes Domain code Definition 1. MD_TopicCategoryCode From Annex I, II and III TopicCatCd high-level geographic data thematic classification to assist in the grouping and search of available geographic data sets. Can be used to group keywords as well. Listed examples are not exhaustive. NOTE It is understood there are overlaps between general categories and the user is encouraged to select the one most appropriate. 2. Farming - Agricultural and aquaculture facilities (III.9) 001 rearing of animals and/or cultivation of plants Examples: agriculture, irrigation, aquaculture, plantations, herding, pests and diseases affecting crops and livestock 3. Biota - Bio-geographical regions (III.17) - Habitats and biotopes (III.18) - Species distribution (III.19) 002 flora and/or fauna in natural environment Examples: wildlife, vegetation, biological sciences, ecology, wilderness, sea life, wetlands, habitat 4. boundaries - Administrative units (I.4) - Statistical units (III.1) 003 legal land descriptions Examples: political and administrative boundaries 5. ClimatologyMeteorologyAt mosphere - Atmospheric conditions (III.13) - Meteorological geographical features (III.14) 004 processes and phenomena of the atmosphere Examples: cloud cover, weather, climate, atmospheric conditions, climate change, precipitation 6. Economy - Energy resources (III.20) - Mineral resources (III.21) 005 economic activities, conditions and employment Examples: production, labour, revenue, commerce, industry, tourism and ecotourism, forestry, fisheries, commercial or subsistence hunting, exploration and exploitation of resources such as minerals, oil and gas 7. Elevation - Elevation (II.1) 006 height above or below sea level Examples: altitude, bathymetry, digital elevation models, slope, derived products 8. Environment - Protected sites (I.9) 007 environmental resources, protection and conservation Examples: environmental pollution, waste storage and treatment, environmental impact assessment, monitoring environmental risk, nature reserves, landscape 9. GeoscientificInformation - Soil (III.3) - Geology (II.4) - Natural risk zones (III.12) 008 information pertaining to earth sciences Examples: geophysical features and processes, geology, minerals, sciences dealing with the composition, structure and origin of the earth’s rocks, risks of earthquakes, volcanic activity, landslides, gravity information, soils, permafrost, hydrogeology, erosion Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 75 of 104 Name (ISO 19115) INSPIRE spatial data themes Domain code Definition 10. Health - Human health and safety (III.5) 009 health, health services, human ecology, and safety Examples: disease and illness, factors affecting health, hygiene, substance abuse, mental and physical health, health services 11. ImageryBaseMapsEarthC over - Orthoimagery (II.3) - Land cover (II.2) 010 base maps Examples: land cover, topographic maps, imagery, unclassified images, annotations 12. intelligenceMilitary 011 military bases, structures, activities Examples: barracks, training grounds, military transportation, information collection 13. inlandWaters - Hydrography (I.8) 012 inland water features, drainage systems and their characteristics Examples: rivers and glaciers, salt lakes, water utilization plans, dams, currents, floods, water quality, hydrographic charts 14. location - Geographical names (I.3) - Addresses (I.5) 013 positional information and services Examples: addresses, geodetic networks, control points, postal zones and services, place names 15. oceans - Sea regions (III.16) - Oceanographic geographical features (III.15) 014 features and characteristics of salt water bodies (excluding inland waters) Examples: tides, tidal waves, coastal information, reefs 16. planningCadastre - Cadastral parcels (I.6) - Land use (III.4) - Area management/ restriction/regulation zones & reporting units (III.11) 015 information used for appropriate actions for future use of the land Examples: land use maps, zoning maps, cadastral surveys, land ownership 17. society - Population distribution – demography (III.10) 016 characteristics of society and cultures Examples: settlements, anthropology, archaeology, education, traditional beliefs, manners and customs, demographic data, recreational areas and activities, social impact assessments, crime and justice, census information 18. structure - Buildings (III.2) - Production and industrial facilities (III.8) - Environmental monitoring facilities (III.7) 017 man-made construction Examples: buildings, museums, churches, factories, housing, monuments, shops, towers 19. transportation - Transport networks (I.7) 018 means and aids for conveying persons and/or goods Examples: roads, airports/airstrips, shipping routes, tunnels, nautical charts, vehicle or vessel location, aeronautical charts, railways 20. utilitiesCommunication - Utility and governmental services (III.6) 019 energy, water and waste systems and communications infrastructure and services Examples: hydroelectricity, geothermal, solar and nuclear sources of energy, water purification and distribution, sewage collection and disposal, electricity and gas distribution, data communication, telecommunication, radio, communication networks NOTE The INSPIRE spatial themes “Coordinate reference systems (I.1)” and “Geographical grid systems (I.2)” are not mapped with the ISO dataset topic category. From the topic category viewpoint these INSPIRE spatial themes are not themes because there is no thematic classification, and both can be considered as reference systems. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 76 of 104 Annex F The conformity of spatial resources with the implementing rules referred to in Article 7(1); (Art. 5-2 (a) and Art. 11-2 (d)) The way in which conformity is expressed in the INSPIRE IR will be defined in a subsequent draft based on discussions being held with the Drafting Team on Data specifications and harmonization. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 77 of 104 Annex G Quality and validity of spatial resources; (Art. 5-2 (c)) In the INSPIRE Directive Art. 5-2 (c) and 11-2(c) there is a requirement for information about the quality and validity of a resource. This annex describes how this requirement is interpreted and the confrontation of this interpretation with the discovery set. The following description will illustrate the relation and connection between the discovery set of metadata elements and the process of a rough data quality evaluation of environmental data resources from the user perspective. The term quality is used from a user perspective and is described as a first estimate of whether or not a resource is relevant or usable for a specific problem. That means that quality and validity of a resource are not used in the context of ISO 19113 Geographic information – Quality principles and ISO 19114 Geographic information – Quality evaluation procedures. From user perspective the first estimation of quality of an environmental resource is the usefulness for a specific purpose and includes aspects of validity. The validity of a resource depends on the actual problem or question. The quality in terms of validity is defined by the actual situation and can not be given by a detailed description in advance. The usefulness of a resource for a specific purpose is based on ‘quality indicators’ which give the user the ability to assess the resource according to the user’s actual situation defined by time, budget, available resources etc Therefore in general a user will evaluate the relevance and usability of a resource on metadata elements delivered by discovery service as a search result. Metadata information is used as ‘quality indication’. This is a specific user action and the focus and weighting of metadata will vary between the resources and will depend on the problem. Resource 1 Resource 2 Resource 3 Resource n Search result, list of resources First evaluation of relevance/quality In depth evaluation for selected sources Figure G.1 The two main user actions to evaluate resources Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 78 of 104 Figure G.1 illustrates the two main processes of quality evaluation. It illustrates, that the first evaluation is based on the list of results from a search and an in depth analysis will be done in a second step for specific resources. In table G.1 an impression is given of the connection between user actions, the first quality assessment and the relevant metadata elements. The general use case describes the situation that for actual question or problem the availability of additional environmental, georeferenced information has to be checked. The initial and most important issue is to find any available resource through one metadata search. The expectation from a user perspective is to get a list of resources. Search criteria will be chosen in most cases as wide as possible to cover all possible resources. In case of to many hits the criteria will be more specific in a second step. The availability of metadata is set as given for the use case and is core for the following steps. From a user perspective the display of relevant information for each resource in a clear structured way where the user can recognise immediately the relevant information is the most important aspect. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 79 of 104 Table G.1: schematic procedure of resource evaluation User action Expected System response Evaluation of relevance/quality by user Requirements for metadata content Metadata elements Searching for resources in a specific thematic and geographical context List of resources with rough categorisation; list includes a ranking Support discovery service for semantic and spatial context Resource title Resource topic category Keywords Going over the list of results Short summary of each resource is listed Listed sources have a connection to the thematic area and to the geographic extent of search Looking for availability Text item with description of access and use restrictions Is the resource accessible to me and (if any) what cost are connected to use the source (licence)? The information is up to date and valid; contact information is available Clear categories of access and use restrictions Constraints – Access Constraints – use limitations Looking for thematic relevance Text description for the thematic content Is the resource thematic relevant? Can I as user (in most cases not an expert in the specific field) understand the description? Is the description detailed enough? Alternatively, can I reject this resource as unsuitable on the basis of the description? Text document (ideally structured and easy to read) with understandable description for non experts and links to more detailed information for interested or experts content definition clear; target group clear; ideally examples for administration Resource topic category Keywords Abstract Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 80 of 104 User action Expected System response Evaluation of relevance/quality by user Requirements for metadata content Metadata elements Looking for timeliness Information about the currency of the information Is the resource useable in terms of its currency? Is this the most recent version of the information available. Is there a more relevant past version of the data (for example different publication dates)? Can I restrict the temporal extent of the data? Text description of currency is given or the temporal period covered by the data, information is according to content Date – temporal reference Looking for relevance on spatial context Visualisation of the graphical extent of the resource (ideally in combination with my search criteria) Is the spatial relation between resource and area of interest sufficient (full coverage, most relevant part, only a small part…)? Definition of the geographic extent of the resource Geographic extent of the resource - EX_GeographicBoundingBox Geographic extent of the resource - EX_GeographicDescription Looking for equivalent scale, spatial resolution Information of spatial resolution, equivalent scale Is the resource usable in terms of equivalent scale or resolution distance 1X1km grid, 1:25000)? Rough categorisation of either equivalent scale or resolution distance Equivalent scale Resolution distance Lineage Description of the ‘history’ of a resource in a text document Are there any methods or sources used, which restrict the use for my specific requirements? Description of use methods and used sources (like elevation models, ...) content definition clear; target group clear; ideally examples for administration (when to use a link) Lineage evaluating a specific source in detail Contact information and other links to additional information is listed Is there an address, phone number mail address to ask for more detailed information and clarification? Actual contact information Resource responsible party Resource locator The columns ‘user action’ and ‘expected system response’ should give a rough indication of the process. The column ‘Evaluation of relevance/quality’ describes the interpretation/estimation from user side of metadata content. ‘Requirements for metadata’ contains a rough description of what is important in metadata description. And the column ‘metadata element’ gives the link to the used element of description. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 81 of 104 The steps following the initial search are schematically described. The importance of single aspects can vary in a concrete case and will also depend on the number of possible available resources. In most cases there will be for the time being not too many results if the search is either thematically or geographical very specific. But assuming that implementing INSPIRE a much higher number of resources will be described and available for search the more important will this kind of ‘pre-selection’ be for any user in the field of environmental data and information. For the evaluation process of available resources the schematic procedure shows, that the most important aspect is the availability and completeness of metadata description. As more detailed the question is as higher is the probability that no information is available. For all cost free spatial information the key question is “Can I combine the different resources with my tools?”. For all use restricted resources especially if they are connected to costs the cost benefit evaluation is the most important aspect. To have consistent results and a full usability of metadata the common understanding of metadata description and a minimum of mandatory core elements are crucial. The use case provides a view from a user perspective why these elements are so important and what is the risk if there is no common understanding or different definition and structuring is used for metadata. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 82 of 104 Annex H Guidelines for ISO/TS 19139 Metadata Implementation specification H.1 From the conceptual schema to XML File instances Due to the use envisioned for the geographic metadata XML Schema, it is fundamental to keep the organisation of the data, its associated metadata and the related information in very flexible files. It is very important to understand that the MD_Metadata XML element will rarely be the root element of an XML File, but depending on the context it may appear one or many times in a single XML File describing one or many different types of resources. H.2 Polymorphism It is even possible to have an XML file containing a metadata set without containing a single MD_Metadata XML element. This is a consequence of the polymorphism, which may imply that an XML element representing a subclass of MD_Metadata, potentially defined in a user community profile, occurs instead of the MD_Metadata XML element. This is true for MD_Metadata as well as for any of the concepts defined in the ISO 19100 series of International Standards. H.3 Management of polymorphism H.3.1 Management of community extensions In order to ensure the understanding of user profiled metadata sets, a specific requirement has been expressed in A.3 of ISO 19139. The XML element of any new metadata element has to support a mandatory XML attribute called isoType that is expected to contain the name of the ISO class it derives from directly or indirectly. Whatever text H.3.2 Parsing of metadata files To accommodate the polymorphism of the data types, parsing of the metadata files has to be driven by the XML elements corresponding to the properties of the UML models (rather look for the metadata elements named identificationInfo, than the metadata elements named MD_DataIdentification or SV_ServiceIdentification). The elements corresponding to the data type can generally be skipped. When it is necessary to evaluate the XML element representing data types (e.g., because the application needs to consider the data identification info, but not the service identification info), it is important to look for the XML element corresponding to the expected ISO data type (e.g., gco:MD_DataIdentification) or the XML element for which the value of gco:isotype is the expected data type (e.g. MD_DataIdentification). There is no namespace indication in the value of the isoType attribute. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 83 of 104 H.4 Management of by reference containment Any instance of a UML property can be implemented: • by value, i.e. the instance of its datatype is a subelement of the property instance; … … • by reference, i.e. the property instance handles a xlink:href attribute which value is a reference (typically URL) to the instance of its datatype. In this case, the instance of the datatype handles an id XML attribute serving as an identifier. … The use of by reference containment is of course a very good way to ensure the consistency of the XML data and to reduce the maintenance cost. However it complicates the parsing of the XML file. It is recommended that the parser use a generic mechanism to manage the by-reference containment. H.5 ISO 19139 and multilingual metadata Per corrigendum, an optional but repeatable attribute locale has been added to the class MD_Metadata. Two cases of to be considered: - When this attributes is not implemented, the metadata set is expected to be monolingual: the language of the metadata is defined by the language attribute of MD_Metadata. - When this attribute is implemented, each instance represents a locale (language, country and character encoding) in which the metadata elements may be translated. The language attribute still defines the default language of the metadata, i.e. the language in which all the metadata elements are expressed. Then each metadata element can be translated in some of the locales define for the metadata set. MD_Metadata + fileIdentifier [0..1] : CharacterString + language [0..1] : CharacterString + characterSet [0..1] : MD_CharacterSetCode = "utf8" + parentIdentifier [0..1] : CharacterString + hierarchyLevel [0..*] : MD_ScopeCode = "dataset" + hierarchyLevelName [0..*] : CharacterString + contact [1..*] : CI_ResponsibleParty + dateStamp : Date + metadataStandardName [0..1] : CharacterString + metadataStandardVersion [0..1] : CharacterString + datasetURI [0..1] : CharacterString MD_Metadata + fileIdentifier [0..1] : CharacterString + language [0..1] : CharacterString + characterSet [0..1] : MD_CharacterSetCode = "utf8" + parentIdentifier [0..1] : CharacterString + hierarchyLevel [0..*] : MD_ScopeCode = "dataset" + hierarchyLevelName [0..*] : CharacterString + contact [1..*] : CI_ResponsibleParty + dateStamp : Date + metadataStandardName [0..1] : CharacterString + metadataStandardVersion [0..1] : CharacterString + datasetURI [0..1] : CharacterString MD_Metadata + fileIdentifier [0..1] : CharacterString + language [0..1] : CharacterString + characterSet [0..1] : MD_CharacterSetCode = "utf8" + parentIdentifier [0..1] : CharacterString + hierarchyLevel [0..*] : MD_ScopeCode = "dataset" + hierarchyLevelName [0..*] : CharacterString + contact [1..*] : CI_ResponsibleParty + dateStamp : Date + metadataStandardName [0..1] : CharacterString + metadataStandardVersion [0..1] : CharacterString + datasetURI [0..1] : CharacterString + locale [0..*] : PT_Locale MD_Metadata + fileIdentifier [0..1] : CharacterString + language [0..1] : CharacterString + characterSet [0..1] : MD_CharacterSetCode = "utf8" + parentIdentifier [0..1] : CharacterString + hierarchyLevel [0..*] : MD_ScopeCode = "dataset" + hierarchyLevelName [0..*] : CharacterString + contact [1..*] : CI_ResponsibleParty + dateStamp : Date + metadataStandardName [0..1] : CharacterString + metadataStandardVersion [0..1] : CharacterString + datasetURI [0..1] : CharacterString + locale [0..*] : PT_Locale PT_Locale + language : LanguageCode + country [0..1] : CountryCode + characterEncoding : MD_CharacterSetCode PT_Locale + language : LanguageCode + country [0..1] : CountryCode + characterEncoding : MD_CharacterSetCode PT_Locale + language : LanguageCode + country [0..1] : CountryCode + characterEncoding : MD_CharacterSetCode LanguageCode (from ISO 00639 Human Language) <> MD_CharacterSetCode (from ISO 19115 Identification information) <> CountryCode (from ISO 03166 Country Codes) <> LanguageCode (from ISO 00639 Human Language) <> LanguageCode (from ISO 00639 Human Language) <> MD_CharacterSetCode (from ISO 19115 Identification information) <> MD_CharacterSetCode (from ISO 19115 Identification information) <> CountryCode (from ISO 03166 Country Codes) <> CountryCode (from ISO 03166 Country Codes) <> The metadata elements which may require translations are those of type CharacterString having a free text domain. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 84 of 104 Support of free text is enabled via a subtype of CharacterString called PT_FreeText which aggregates a set of localised character strings through its textGroup property. Each localised character string provides a translation of the character string in the related locale. 1..* +locale LocalisedCharacterString 1 1 PT_Locale + language : LanguageCode + country [0..1] : CountryCode + characterEncoding : MD_CharacterSetCode +textGroup1..* +locale LocalisedCharacterString 1 1 PT_Locale + language : LanguageCode + country [0..1] : CountryCode + characterEncoding : MD_CharacterSetCode +textGroup PT_FreeText CharacterString (from Text) <> PT_FreeTextPT_FreeText CharacterString (from Text) <> CharacterString (from Text) <> The following clauses define the way multilingual metadata are implemented. H.5.1 The default language The default language of a metadata set is defined by the language property of MD_Metadata while the characterSet property defines the corresponding character encoding. Here is a sample instance of the class MD_Metadata illustrating the use of both properties. English UTF-8 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 85 of 104 H.5.2 Alternate languages Each metadata alternate language of the metadata is defined through the locale property of MD_Metadata. In the following example, some of these metadata are translated into French: French UTF 8 H.5.3 Embedded translations Any metadata element having a free text domain (e.g. the abstract property of MD_DataIdentification) can then be instantiated like this: Brief narrative summary of the content of the resource Résumé succinct du contenu de la ressource The xsi:type attribute indicates that this instance of the abstract property is not instantiated through a simple CharacterString, but rather as a free text. As a consequence, the element contains a complementary PT_FreeText subelement containing one or more textGroup elements (one per translation). H.5.4 Use of translation files In the preceding example, the definition of the locale property is provided by value which implies that the translations are embedded with default language metadata. It is also possible to store the translations corresponding to a given language into a translation file using the PT_LocaleContainer class. In such case, it is easier to define the locale within the translation file (e.g. fr-fr.xml) and to express the instance of the MD_Metadata locale property by reference. The content of the fr-fr.xml file would look like this: Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 86 of 104 French UTF 8 Résumé succinct du contenu de la ressource The multilingual instance of the abstract property now implements the translation by reference to the translation file: Brief narrative summary of the content of the resource H.6 Contexts of use H.6.1 Use of ISO 19139 in the context of a Catalogue Service When the data being passed through a cataloguing service is XML encoded, the catalogue service interface defines the different XML Schemas to be used as a response to the user queries. When the geographic metadata XML Schema is used, there should be one or many MD_Metadata instances in the returned XML File. H.6.2 Use of ISO 19139 in the context of the standard interchange by transfer The transfer aggregate and transfer dataset concepts are the two major components of an interchange by transfer. There may be one or many XML Files composing the interchange, but the root element of at least one of the files is an XML instance of MX_Dataset, MX_Aggregate or one of their extensions. From such an element, the parsing of the interchange is model driven and it follows the principles described in 7.4 of ISO 19139. See ISO 19139 for details about MX_Dataset and MX_Aggregate. H.7 Character encoding Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 87 of 104 As defined in MD_Metadata.characterEncoding and MD_Metadata.locale. Preferably UTF-8 if the XML files contains multilingual metadata. H.8 Temporal extent encoding In ISO 19115, temporal extents are of type TM_Primitive (abstract type from ISO 19108). In ISO 19139, this type (and its sub-types) are mapped to ISO 19136 temporal types and W3C built-in types. In the INSPIRE Discovery Metadata Element Set, the concrete TM_Period subtype of TM_Primitive is used as type for the XML element temporalExtent. It is implemented as type TimePeriod from ISO 19136. TimePeriod offers three options to express a time interval: • Use two TimePosition elements for beginPosition and endPosition. Date and time information is contained inline and cannot be referenced from another XML Element. Only the TimePeriod element can, through its gml:id. 1977-03-10T11:45:30 2005-01-15T09:10:00 • Use two TimeInstant elements: Date and time information is here contained by reference and the TimeInstant elements can be re-used through a reference from another XML element in the XML file. The TimePeriod element can also be re-used. ......... ............ ............... …............... ..................... ........................1977-03- 10T11:45:30 ..................... .................. .................. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 88 of 104 ..................... ........................2005-01- 15T09:10:00 ..................... .................. ............... ............ ......... ...... ... • The two previous methods can be used in combination: one TimePeriod limit can be expressed as a TimePosition and the other as a TimeInstant: 1977-03- 10T11:45:30 2005-01-15T09:10:00 H.9 Spatial resolution encoding A dataset or dataset series’ spatial resolution can be expressed as an equivalent scale or as a resolution distance: • Expression as an equivalent scale: Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 89 of 104 25000 In this case, the spatial resolution is expressed as the denominator of the scale of a comparable hardcopy map or chart. • Expression as a resolution distance: ..........25 In this case, the spatial resolution is expressed as the ground sample distance, implemented through the gco:Distance type. The unit of measure is either a conventional unit of measure symbol or a link to a definition. The latter case is illustrated above. • If needed, the two options can be used in conjunction: 25 25000 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 90 of 104 NB: The property spatialResolution needs to be instantiated twice. H.10 Example of ISO 19139 XML Metadata Sets The following XML instances include the mandatory INSPIRE Level 2 Discovery Metadata elements. They also include other ISO 19115 optional elements, as examples of what can be implemented in real cases. H.10.1 Service metadata instance This clause is an XML Metadata instance describing a service resource. eng service Nicolas Lesage Institut Géographique National (IGN) +33.1.4398.8596 … +33.1.4398.8171 2/4, avenue Pasteur Saint-Mandé 94160 FRANCE Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 91 of 104 nicolas.lesage@ign.fr author 2005-12-14 ETRS89 EUREF Sample service 2005-12-14 publication This service does not exist. This is an ISO 19119 sample metadata set encoded in XML using ISO 19139 encoding rules and XML Schema implementation of ISO 19115. Nicolas Lesage Institut Géographique National (IGN) +33.1.4398.8596 +33.1.4398.8171 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 92 of 104 2/4, avenue Pasteur Saint-Mandé 94160 FRANCE nicolas.lesage@ign.fr author SERVICE OPERATION WFS 1.0 loose Op1 XML http://anywhere.com/Sample_Service/Op1 http://anywhere.com/Sample_Service Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 93 of 104 http://www.alternate-site.com/Sample_Service http://www.alternate-transfer-options.com/Sample_Service The table below described the values of INSPIRE elements contained in the sample instance.. Metadata element Value in the metadata example Resource title Sample service Temporal reference 2005-12-14 (type : publication) Resource language eng Keyword SERVICE Keyword OPERATION Service type WFS Resource responsible party Nicolas Lesage Institut Géographique National (IGN) +33.1.4398.8596 +33.1.4398.8171 2/4, avenue Pasteur Saint-Mandé 94160 France nicolas.lesage@ign.fr author Abstract This service does not exist. This is an ISO 19119 sample metadata set encoded in XML using ISO 19139 encoding rules and XML Schema implementation of ISO 19115. Resource locator http://anywhere.com/Sample_Servic e Resource locator http://www.alternate- site.com/Sample_Service Service type version 1.0 Operation name Op1 Distributed computing platform XML Resource Identifier http://anywhere.com/Sample_Servic e/Op1 Metadata element Value in the metadata example Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 94 of 104 Metadata element Value in the metadata example Metadata point of contact Nicolas Lesage Institut Géographique National (IGN) +33.1.4398.8596 +33.1.4398.8171 2/4, avenue Pasteur Saint-Mandé 94160 France nicolas.lesage@ign.fr author Metadata date stamp 2005-12-14 Metadata language eng H.10.2 Dataset metadata instance This clause is an XML instance describing a dataset resource. eng dataset Nicolas Lesage Institut Géographique National (IGN) +33.1.4398.8596 +33.1.4398.8171 2/4, avenue Pasteur Saint-Mandé 94160 FRANCE Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 95 of 104 nicolas.lesage@ign.fr author 2007-01-12 ETRS89 EUREF A200000P000P2001VT2 ORTHO-N2 image #001VT2 from GEOBASE 2004-03-11 creation 2004-11-07 publication 3 2005-11-07 A200000P000P2001VT2 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 96 of 104 IGN Espace 6, avenue de l’Europe Ramonville Saint- Agne 31520 FRANCE author ORTHO-N2 Sample french product Sample coverage product supporting users of the PRODARC specification EMA/BGI ARMEES 0450 FRANCE pointOfContact Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 97 of 104 PRODARC FRENCH PRODUCT INSPIRE Gamme de produits CARGENE – Caractéristiques générales 2005-06-20 publication 1.0 CARGENE 1.0 No constraint copyright grid 25000 Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 98 of 104 eng imageryBaseMapsEarthCover boundingBox 44.36363636 44.45454545 33.28571429 33.35714286 dataExtent 2007-01-16 2007-01-25 SHAPEFILE 1 http://anywhere.com/Sample_Service Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 99 of 104 http://www.alternate-site.com/Sample_Service http://www.alternate-transfer- options.com/Sample_Service dataset comes from IGN photogrammetric chain The table below described the values of INSPIRE elements contained in the sample instance.. Metadata element Value in the metadata example Resource title A200000P000P2001VT2 Temporal reference 2004-03-11 (type : creation) Temporal reference 2004-11-07 (type : publication) Temporal reference 2007-01-16 to 2007-01-25 Geographic extent of the resource 44.36363636 (West Bound Longitude) 44.45454545 (East Bound Longitude) 33.28571429 (South Bound Latitude) 33.35714286 (North Bound Latitude) Resource language eng Resource topic category imageryBaseMapsEarthCover Keyword PRODARC Keyword FRENCH PRODUCT Keyword INSPIRE Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 100 of 104 Metadata element Value in the metadata example Resource responsible party IGN Espace 6, avenue de l’Europe Ramonville Saint-Agne 31520 France author Abstract Sample french product Metadata element Value in the metadata example Constraints No constraint (use limitation) Constraints Copyright (access) Lineage comes from IGN photogrammetric chain Spatial resolution 1/25000 Metadata element Value in the metadata example Metadata point of contact Nicolas Lesage Institut Géographique National (IGN) +33.1.4398.8596 +33.1.4398.8171 2/4, avenue Pasteur Saint-Mandé 94160 France nicolas.lesage@ign.fr author Metadata date stamp 2007-01-12 Metadata language eng Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 101 of 104 Annex I Guidelines for Catalogue implementation I.1 Full text search Full text search is a capability of a discovery service to query the repository for any character data types. In a full text search, the discovery service examines all of the words in every stored document as it tries to match search words supplied by the user. This is very useful, if the user does not want to match a specific queryable and rather wants to determine if a specific word is stored anywhere in a repository. Almost all common search engines on the Web provide such capabilities (Google, Yahoo, etc), either by employing full text search techniques, or by just indexing a portion of the documents (Web Pages) examined by the indexing system. Full text search capabilities are part of the implementation of the specific discovery service as this technique depends heavily on the underlying storage system (e.g. each database provides its own techniques and algorithms). In case of OGC Catalogue services, the full text search is part of the query filter in that the specification defines an appropriate queryable to enable full text search by the user. This queryable is called ‘AnyText’. The semantics of this queryable is defined as follows: “A target for full-text search of character data types in a catalogue”. In the context of this IR ‘AnyText’ could be understood as a virtual metadata element that is dedicated to full text searches. It is used only to express the search criteria to be applied to any metadata element for full text searches of character data types in a catalogue. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 102 of 104 Annex J Conformance with IR on Metadata Metadata packages, classes, attributes and relationships will hereafter be called metadata elements. J.1 Conformance requirements In order to be in conformance with the Implementing Rules for metadata, metadata shall be provided as specified in Chapter 5, 6, 7, 8 and Annexes A, B and E. Any metadata claiming conformance with these Implementing Rules shall pass the requirements described in the abstract test suite presented in J.3. J.2 Obligation and condition For the purposes of conformance testing using the abstract test suite in J.3, metadata elements shall be considered to be mandatory, conditional or optional as specified in section J.3.1. J.3 Test suite The completion of this test ensures that the rules specified in these Implementing Rules have been applied. The test suite comprises of several different tests, and these tests shall be described in the following clauses. J.3.1 Completeness test a) Test Purpose: to determine conformance by the inclusion of all metadata elements that are specified with an obligation of “mandatory” or mandatory under the conditions specified. NOTE: Many elements designated as mandatory are contained within optional elements. These elements become mandatory only when their containing element is used. b) Test Method: a comparison between these Implementing Rules and a subject metadata set or service to be tested shall be performed to determine if all metadata defined as mandatory in chapters 6, 7 and 8 are present. A comparison test shall also be performed to determine if all metadata elements defined as conditional in chapters 6, 7 and 8 are present if the conditions set out in these Implementing Rules apply. c) Reference: chapters 6, 7 and 8. d) Test Type: Basic. The following test cases apply at all levels of obligation – mandatory, conditional, and optional. J.3.2 Maximum occurrence test a) Test Purpose: to ensure each metadata element occur no more than the number of times specified in these Implementation Rules. b) Test Method: examine a subject metadata set for the number of occurrences of each metadata element provided. The number of occurrences for each shall be compared with its “Maximum Occurrences” attribute specified in chapters 6, 7 or 8. c) Reference: Chapters 6, 7 and 8. d) Test Type: Basic. J.3.3 Data type test a) Test Purpose: to determine if each metadata element within a subject metadata set uses the specified data type. b) Test Method: the value of each provided metadata element is tested to ensure its data type adheres to the data type specified. Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 103 of 104 c) Reference: Chapter 6, 7 and 8. d) Test Type: Basic. J.3.4 Domain test a) Test Purpose: to determine if each provided metadata element within a subject metadata set falls within the specified domain. b) Test Method: the values of each metadata element are tested to ensure they fall within the specified domain. c) Reference: Chapters 6, 7 and 8. d) Test Type: Basic. J.3.5 Schema test a) Test Purpose: to determine if a subject metadata set follows the schema specified in these Implementation Rules. b) Test Method: test each metadata element and ensure it is contained within the specified metadata element. c) Reference: Chapters 6, 7 and 8. d) Test Type: Basic. J.3.5 Definitional test a) Test purpose: to determine if a metadata element is used rightfully according to the definition b) Test Method: Compare the way a metadata element is used with the definition given in chapters 6, 7 and 8, in order to decide whether a metadata element is used correctly. c) Reference: Chapters 6, 7 and 8. d) Test Type: Basic Infrastructure for Spatial Information in Europe Reference: draftINSPIREMetadataIRv2_20070202.doc DT Metadata Draft Implementing Rules Metadata 2007-02-02 Page 104 of 104 Annex K Bibliography [1] Hans Dufourmont (ESTAT), Alessandro Annoni (JRC), Hugo De Groof (ENV), 05-07-2004, INSPIRE - work programme Preparatory Phase 2005 – 2006 [2] European Commission DG Joint Research Centre, Institute for Environment and Sustainability, Land Management Unit, ESDI Action, 2005-09-23, Draft Guidelines for the Development of the INSPIRE Implementing Rules [3] European Commission DG Joint Research Centre-Institute for Environment and Sustainability, 2005-09-24, Requirements for the definition of the INSPIRE Implementing Rules for Metadata [4] ISO TC 211, 2005-05-21, Requirements for revision of ISO/TC 211 Standards, PT 19140, (211n1833) [5] CEN TC/287, ENV 12657:1998, Geographic information – Data description – Metadata [6] wikipedia (2006): http://en.wikipedia.org/wiki/EGovernment [7] RFC 2396 (1998): http://www.ietf.org/rfc/rfc2396.txt [8] ISO/DIS 19132, Geographic information – Location based services [9] ISO/CD 19115-2, Geographic information – Metadata – Part 2: Metadata for imagery and gridded data, ISO/TC 211 N 1931 dated 2005-11-14