INSPIRE

Infrastructure for Spatial Information in Europe

 

Discussion Paper on possible simplification of data-service linking in INSPIRE

 

Type

Document for information and discussion

Creator

EC and EEA INSPIRE Team

Date/status/version

12/11/2018 / DRAFT / version 0.5

Addressee

MIG

Identifier

MIG/9/2018/DOC7

Description

This paper reflects discussions in the MIG-T on the topic of data-service linking in INSPIRE. These discussions are related to the agreed ad-hoc MIG-T actions on

  • preparing a guidance document on how data sets and services are being linked in current ISO metadata and how links are created in the INSPIRE geoportal and
  • drafting a proposal to amend the use of the resource locator metadata element in the Metadata IR,

as well as recent discussions in the temporary sub-group 2017.4 on validation and conformity testing. It also integrates elements from the discussion paper "IR on metadata – Change proposal(s) on the 'Resource Locator' element" presented to the 8 th MIG meeting.

The current version was discussed at the 52 nd MIG-T meeting in October, and a number of conclusions and recommendations have been agreed to be presented to the 9 th MIG meeting, for further discussion and endorsement.

Actions

MIG to:

  • Take note of the document and the conclusions and recommendations from the 52nd MIG-T meeting
  • Discuss and endorse the proposed action mandate 2019.2 [DOC7annex]


Preface

This paper reflects discussions in the MIG-T on the topic of data-service linking in INSPIRE. These discussions are related to the agreed ad-hoc MIG-T actions on

  • preparing a guidance document on how data sets and services are being linked in current ISO metadata and how links are created in the INSPIRE geoportal and
  • drafting a proposal to amend the use of the resource locator metadata element in the Metadata IR,

as well as recent discussions in the temporary sub-group 2017.4 on validation and conformity testing [1] . It also integrates elements from the discussion paper "IR on metadata – Change proposal(s) on the 'Resource Locator' element" presented to the 8 th MIG meeting [2] .

The initial version was drafted by a small MIG-T ad-hoc group with members from DK, FR, NL, JRC and DG ENV, based on a workshop on 1-2 August 2018 in Ispra, and updated in September based on a first round of comments by the MIG-T.

The current version was discussed at the 52 nd MIG-T meeting in October [3] . Before the discussion, participants were asked about their level of agreement to a number of assumptions and aspects of the simplification proposals using Sli.do polls. The results are available on the meeting page.

A number of conclusions and recommendations have been agreed to be presented to the 9 th MIG meeting, for further discussion and endorsement (see next section).

Conclusions and recommendations from the 52nd MIG-T meeting

The MIG-T recognises that

  • the level of data-service linking [4] in INSPIRE is insufficient , and many organisations seem to have difficulties to provide implementations in line with the current TGs (even though almost all MS provide at least some data sets with correct data-service linking);
  • this already has negative impacts on the accessibility of INSPIRE data sets (through the INSPIRE geoportal) and hence the overall usability of the INSPIRE infrastructure;
  • this will also lead to poor indicators in the future (metadata-based) approach for monitoring and reporting;
  • the current approach for data-service linking described in the TGs for metadata and network services is complicated , and there are different interpretations of the related requirements, even by implementation/standards experts;
  • the current approach for service metadata, which requires extensions to base standards , is posing an obstacle to the implementation of INSPIRE requirements for network services (because the required extensions are not widely implemented in off-the-shelf software); and
  • there is a clear overlap / duplication of data set and service metadata (e.g. bounding box, INSPIRE theme), which in some cases leads to inconsistencies.

The MIG-T supports  the new data-centric approach (already underlying the new geoportal and the proposed revision of the M&R IRs), which focuses on data and how they can be accessed through network services rather than considering data and network services as stand-alone components of the infrastructure. However, it might still be useful for application developers to be able to access a directory/register of the services available in the infrastructure.

The MIG-T further recommends that there should be one "source of truth" for service metadata , ideally as provided by the service itself (e.g. in its Capabilities document).

Concretely, the MIG-T recommends to the MIG that

  • the alternative approach for documenting data-service linking in the data set metadata (as proposed in the discussion paper) should be further elaborated and become the preferred option in the Metadata TGs (and/or in a stand-alone guidance document on data-service linking); this guidance should include an explanation how the IR requirements for network service metadata are mapped to the new approach;
  • the current approach should still be supported for a transition period (to be determined by the MIG) as an alternative option that will be used by the geoportal if no links to network services can be established based on the data set metadata; at the end of the transition period the necessity to further support the current approach should be reviewed;
  • the Network Service TGs shall be reviewed to reflect the proposed simplification of service metadata (including the elements that could be dropped) and the new approach to document data-service linking;

The MIG-T further asks the Commission to investigate whether the proposed simplifications would require changes in the IRs or whether they could be implemented by other means, e.g. through a Common Implementation Strategy .

 

 

1          Introduction

This discussion paper aims to explore the feasibility of (and options for) simplifying the approach for documenting and using the linkage between data sets and download and view services in INSPIRE.

The paper is motivated mainly by the following issues and assumptions:

  • Users of the INSPIRE infrastructure are mainly interested in accessing data; services are just a means to this end. Therefore, the focus should be on data.
  • MS are experiencing difficulties to implement the current TG requirements and recommendations, partly because they require extensions to existing standards that are not (widely) supported by existing software products.
  • During the development of the Thematic Viewer, it has been difficult to establish working links for downloading and viewing data sets for all MS, e.g. because
    • the requirements currently prescribed in the TGs for documenting these links are difficult to implement and understand and therefore not widely (correctly) implemented by MS;
    • some information (e.g. restrictions on public access) is documented for both data and services; and
    • there is some duplication between the metadata required for services in the Metadata and the Network Services IRs.
  • The MIG and its sub-groups (mainly 2017.4) are experiencing difficulties in drafting clear and unambiguous requirements and tests in the TGs.

Therefore, a simplified approach for data-service linking should ideally

  • be centred on data (rather than treating data and services as equally important resources),
  • not require extensions to existing standards, in order to allow implementation based on off-the-shelf products,
  • limit the implementation options,
  • remove duplicate or unnecessary elements in metadata descriptions (mainly for services),

and lead to the following benefits:

  • Make it easier for client application to implement discovery of and access to data sets, which is the current trend in many geoportal (including the new INSPIRE geoportal);
  • Reduce the duplication of metadata by requiring just one metadata record per data set rather than three or more (data, view, download and possibly direct access / WFS);
  • Make it easier for software developers to implement network services and metadata.

In the remainder of the paper, we will outline a proposal for such a simplified approach, a number of open (technical) issues for further discussions, as well as possible scenarios on how the approach could be implemented (if endorsed) in the INSPIRE legal and technical framework and by the data and service providers in the MS.

2          A simplified approach for data-service linking

INSPIRE metadata aim at supporting (at least) the following user stories:

  • As a user, I want to be able to search relevant data sets using a discovery service (via a geoportal) based on at least the search criteria defined in Art. 11(2) of the Directive [5] .
  • As a user, once I have discovered a data set in the discovery service, I want to be able to find in the metadata sufficient information to directly access the service metadata of the download/view service(s) that provide access to the selected/discovered data.
  • As a user, once I have discovered a data set in the discovery service, I want to be able to find in the metadata sufficient information to directly download/view the selected/discovered data.

The proposed approach aims at implementing these requirements in the simplest possible way.

2.1          Conceptual model

To illustrate the approach, we focus on the relationships between data sets, network services and (identifiable) representations of data that are provided by these services (e.g. spatial object types [6] for WFS-based download services or layers for WM(T)S-based view services) shown in the conceptual model in Figure 1 .

NOTE The relationship between spatial object types or layers and the data sets they represent can be inferred in some cases from the other relationships. However, this depends on the implementation approach chosen by data / service providers. Particularly when a service provides access to more than one data set, the relationship between spatial object type / layer and data set may not always be clear. See the Annex for how the data-service relationships can be expressed for some typical implementation approaches.

Figure 1 . Conceptual model – relationships between data sets, network services and spatial object types / layers

2.2          Overview

The main ideas of the proposed approach and the main changes compared to the current one are outlined below:

(1)     Data set metadata ( Figure 2 )

  1. Data sets are documented in metadata as currently proposed in the TGs, with the minor modifications for documenting data-service linkage described in (1.b).
  2. In the metadata for each data set, resource locator elements are provided for at least one view and one download service, pointing to a Get Download/View Service Metadata request [7] .

(2)     Service metadata ( Figure 3 )

  1. Download and view services are no longer documented in stand-alone (ISO 19119) service metadata records, but exclusively through the metadata returned by the service itself as a response to a Get Download/View Service Metadata request.
  2. The metadata returned by a network service are drastically reduced and now only include metadata elements that do not duplicate data set metadata and are useful to users; all other metadata elements defined in the Metadata IRs for spatial data services do not have to be provided [8] . This will remove the need for an extension of the base standard, namely the need for the extended capabilities section.
  3. Optionally, where a view/download service provides access to more than one data set and to facilitate the development of client applications, additional resource locator elements can be provided, pointing directly to a Get Map or Get Spatial Data Set request.

 

Figure 2 . Data set metadata

Figure 3 . Service metadata

2.3          Detailed requirements and recommendations

The following detailed requirements and recommendations define the proposed approach in more detail.

(1)     The following requirement should be modified for data set metadata from currently (Metadata TG v2.0.1):

TG Requirement 1.8: metadata/2.0/req/datasets-and-series/resource-locator

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

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

These links shall be encoded using gmd:transferOptions / gmd:MD_DigitalTransferOptions / gmd:onLine / gmd:CI_OnlineResource / gmd : linkage / gmd:URL element.

The multiplicity of this element is 0..n.

 

to (new proposal):

TG Requirement 1.8 : metadata/2.0/req/datasets-and-series/resource-locator

One or more resource locators linking to the view service(s) providing online access to the described data set or data set series shall be given.

One or more resource locators linking to the download service(s) providing online access to the described data set or data set series shall be given.

These links shall be encoded using gmd:transferOptions / gmd:MD_DigitalTransferOptions / gmd:onLine / gmd:CI_OnlineResource / gmd : linkage / gmd:URL element.

The multiplicity of this element is 2..n.

The URLs provided as the value of the gmd:transferOptions / gmd:MD_DigitalTransferOptions / gmd:onLine / gmd:CI_OnlineResource / gmd : linkage / gmd:URL element shall point to the response of a Get View/Download Service Metadata request of the service providing access to this data set.

The gmd:CI_OnlineResource element containing the given gmd:linkage element shall contain a gmd:protocol/gmx:Anchor element pointing to one of the values of the Protocol code list [9] .

The gmd:CI_OnlineResource element containing the given gmd:linkage element shall contain a gmd:applicationProfile/gmx:Anchor element pointing to one of the values of the ApplicationProfile code list [10] .

and:

TG Recommendation 1.x : metadata/2.0/rec/ datasets-and-series /resource-locator-additional-info

If there is a publicly available online resource providing additional information about the described data set or data set series, including further options for downloading or viewing the data set, the URL pointing to this resource shall be given as well, again encoded using the gmd:transferOptions / gmd:MD_DigitalTransferOptions / gmd:onLine / gmd:CI_OnlineResource / gmd : linkage / gmd:URL element.

 

Open issue: In the application profile element, do we need to distinguish "pre-defined" and "direct access" download services?

 

(2)     The following recommendations should be added for data set metadata:

TG Recommendation 1. x : metadata/2.0/rec/ datasets-and-series /resource-locator-network-service-with-multiple-datasets

For cases, where a network service provides more than one data set, resource locators should also be given that contain links for the direct access for downloading and/or viewing the described data set [11] .

The resource locator elements should be encoded as specified in Requirement 1.8.

 

(3)     A general recommendation should be added for cases, where a network service provides download or view access to several data sets, without physically aggregating the individual data sets  (e.g. a regional/national service providing access to several local/regional data sets). In these cases, the "virtual data set" to which the service provides access should also be described with metadata including the links to the network services. The relationship to the component data sets that make up this "virtual data set" should be described textually in the lineage element.

Open issues: How will this be evaluated when calculating monitoring indicators? Do we need additional recommendations (as an offer) for more formal/structured description of aggregation, e.g. using LI_Lineage/LI_Source (aggregate component data sets) or MD_Identification/MD_AggregateInformation (component aggregate data set)?

 

(4)     Requirements to document download and view services in stand-alone (ISO 19119) service metadata records are removed. Instead, network services shall be exclusively documented through the metadata returned by the service itself as a response to a Get Download/View Service Metadata request. The metadata elements to be provided should be simplified as specified in the "Proposed simplification" column in the table below. The "Comment / Justification" column explains the rationale for the proposal, and the Atom, WFS and WMS columns indicate whether a mapping to a standard field has been defined for this metadata element in the relevant TGs.

NOTE The simplification proposed in the table only refers to the INSPIRE requirements. Where the base standard (e.g. WMS, WFS) requires additional metadata elements, these have to be provided as well (to be compliant with the base standard).

NOTE This new proposal makes it crucial to ensure that the links to the service endpoints in the dataset metadata are correct and kept up-to-date.


 

Section / article

Element name

INSPIRE multiplicity

INSPIRE obligation

Proposed simplification

Comment / Justification

Atom

WFS

WMS

Part B 1.1

Resource title

1

Mandatory

Keep

This may be useful for aggregated services and for displaying in the user interface

Part B 1.2

Resource abstract

1

Mandatory

Remove

The abstract of the service is often not useful and seldom used

 

 

 

Part B 1.3

Resource type

1

Mandatory

Remove

If service metadata is available only through the given service, the type is implicit

 

 

 

Part B 1.4

Resource locator

0..*

Conditional, mandatory if linkage to service is available

Remove

If service metadata is available only through the given service, the resource locator is implicit; furthermore, more detailed information is available in the operations metadata of the service

 

 

 

Part B 1.6

Coupled resource

0..*

Conditional, mandatory if linkage to data sets on which the service operates are available.

Turn into a recommendation

This is not strictly necessary, but might be useful, especially for aggregated services providing access to more than one data set

Part B 2.2

Spatial data service type

1

Mandatory

Keep, but implement in data set metadata

This is implemented by providing the application profile element on the data set's resource locator

Part B 3

Keyword

1..*

Mandatory

Remove

 

 

Service keywords (if they are at all necessary) can be covered by data set keywords or the name or description elements of the resource locator

 

 

 

Part B 4.1

Geographic bounding box

0..*

Conditional, mandatory for services with an explicit geographic extent.

Remove

This is covered by the bounding box of the data set (or virtual data set)

 

 

 

Part B 5

Temporal reference

 

At least one of Temporal extent, Date of publication, Date of last revision or Date of creation must be given

Remove

This is covered by the temporal reference of the data set

 

 

 

Part B 6.2

Spatial resolution

0..*

Mandatory when there is a restriction on the spatial resolution for this service

Remove

This is covered by the spatial resolution of the data set. Service-specific restrictions could be expressed through conditions on access and use

 

 

 

Part B 7

Conformity

1..*

Mandatory

Remove

This is mainly relevant for Spatial Data Services that are not network services; using a value from the INSPIRE code list for the application profile of the resource locator could be interpreted as having an INSPIRE-compliant network service.

 

 

 

Part B 8.1

Conditions applying to access and use

1..*

Special values for unknown conditions or no applying conditions may be used

Keep, but implement in data set metadata

Conditions specific to the access to the data set through a specific service can be expressed in the data set metadata.

This would also help users to decide already when looking at the data set metadata whether the data set is useful for their purposes or not.

Note that this requires good coordination in cases where different (departments inside) organisations are responsible for data and service provision.

Part B 8.2

Limitations on public access

1..*

Special value for no limitations may be used

Keep, but implement in data set metadata

Limitations specific to the access to the data set through a specific service can be expressed in the data set metadata.

This would also help users to decide already when looking at the data set metadata whether the data set is useful for their purposes or not.

Note that this requires good coordination in cases where different (departments inside) organisations are responsible for data and service provision.

Part B 9

Responsible organisation

1..*

Mandatory

Keep

This may be different from the organisation responsible for the data set.

Part B 10.1

Metadata point of contact

1..*

Mandatory

Remove

No longer relevant if service metadata are no longer used.

 

 

 

Part B 10.2

Metadata date

1

Mandatory

Remove

The date of last update of the service would be more relevant.

 

 

 

Part B 10.3

Metadata language

1

Mandatory

Remove

Automatic translation tools can nowadays figure out the language used in a document.

 

Open issue: More guidance (and probably simplification) is needed for the usage of languages in network services.

 

 

 


These following code snippet illustrates these requirements using examples of ISO 19115/19139 metadata for data sets and service capabilities / Atom feed elements for services.

 

<gmd:MD_Metadata ... >

   <gmd:contact ... >

      <!-- Responsable party for the spatial data set -->

      <gmd:CI_ResponsibleParty> ...

         <gmd:role>

            <gmd:CI_RoleCode codeList = " http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/ML_gmxCodelists.xml#CI_RoleCode "

                             codeListValue = "pointOfContact" />

         </gmd:role>

      </gmd:CI_ResponsibleParty>      

   ...

   <!-- Data Identification incl. use constraints and limitations -->

   <gmd:identificationInfo ... >

      <gmd:MD_DataIdentification>

      ...

         <!-- Conditions applying to access and use on the data set (through network services) -->

         <gmd:resourceConstraints>

            <gmd:MD_Constraints>

               <gmd:useLimitation>

                  <gco:CharacterString> ... </gco:CharacterString>

               </gmd:useLimitation>

               ...

            </gmd:MD_Constraints>

         </gmd:resourceConstraints>

        <!-- Limitations on public access on the data set (through network services) -->

        <gmd:resourceConstraints>

            <gmd:MD_LegalConstraints>

               <gmd:useLimitation>

                  <gco:CharacterString> ... </gco:CharacterString>

               </gmd:useLimitation>

               ...

               <gmd:accessConstraints> ...  </gmd:accessConstraints>

               ...

               <gmd:otherConstraints> ... </gmd:otherConstraints>

            </gmd:MD_LegalConstraints>

         </gmd:resourceConstraints>

         ...

      </gmd:MD_DataIdentification>

   </gmd:identificationInfo>

   <!-- Distribution info -->

   <gmd:distributionInfo ... >

      <gmd:MD_Distribution>

         ...

         <!-- Responsable party for distributing the spatial data set e.g. through network services -->

         <gmd:distributor xlink:type = "simple" >

            <gmd:MD_Distributor>

               <gmd:distributorContact xlink:type = "simple" >

                  <gmd:CI_ResponsibleParty>

                     ...

                     <gmd:role>

                        <gmd:CI_RoleCode codeList = " http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/ML_gmxCodelists.xml#CI_RoleCode "

                                         codeListValue = "distributor" />

                     </gmd:role>

                  </gmd:CI_ResponsibleParty>

               ...

               </gmd:distributorContact>

            </gmd:MD_Distributor>

         </gmd:distributor>

         <!-- Transfer options - description of the spatial data view service -->

         <gmd:transferOptions>

            <gmd:MD_DigitalTransferOptions>

               ...

               <!-- Links to service metadata -->

               <gmd:onLine>

                  <gmd:CI_OnlineResource>

                     <gmd:linkage>

                        <gmd:URL> https://xxx.xxx.xxx/wms?request=GetCapabilities&amp;version=1.3.0&amp;service=wms </gmd:URL>

                     </gmd:linkage>

                     <gmd:protocol>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ProtocolValue/OGC:WMS-1.3.0-http-get-capabilities "> OGC:WMS-1.3.0-http-get-capabilities </gmx:Anchor>

                     </gmd:protocol>

                     <gmd:applicationProfile>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ApplicationProfile/view "> INSPIRE View Network Service </gmx:Anchor>

                     </gmd:applicationProfile>

                     <gmd:name>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:name>

                     <gmd:description>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:description>

                  </gmd:CI_OnlineResource>

               </gmd:onLine>

            </gmd:MD_DigitalTransferOptions>

            <!-- (Optional) description of the spatial data download service for direct access download -->

            <gmd:MD_DigitalTransferOptions>

            ...

            <!-- Generic service endpoint -->

            <gmd:onLine>

                  <gmd:CI_OnlineResource>

                     <gmd:linkage>

                        <gmd:URL> https://xxx.xxx.xxx/wfs? </gmd:URL>

                     </gmd:linkage>

                     <gmd:protocol>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ProtocolValue/OGC:WFS-2.0.0 "> OGC:WFS-2.0.0 </gmx:Anchor>

                     </gmd:protocol>

                     <gmd:applicationProfile>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ApplicationProfile/view "> INSPIRE Download Network Service </gmx:Anchor>

                     </gmd:applicationProfile>

                     <gmd:name>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:name>

                     <gmd:description>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:description>

                  </gmd:CI_OnlineResource>

               </gmd:onLine>

               ....

            </gmd:MD_DigitalTransferOptions>

            <!-- (Optional) description of the spatial data download service for predefined data download-->         

            <gmd:MD_DigitalTransferOptions>

               ...

               <gmd:onLine>

                  <gmd:CI_OnlineResource>

                     <!-- URL to the feed or, where one Atom contains several data sets, sub-feed, of the data set -->

                     <gmd:linkage>

                        <gmd:URL> http://xxx.xxx.xxx/atom.xml </gmd:URL>

                     </gmd:linkage>

                     <gmd:protocol>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ProtocolValue/WWW:LINK-1.0-http-atom "> WWW:LINK-1.0-http-atom </gmx:Anchor>

                     </gmd:protocol>

                     <gmd:applicationProfile>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ApplicationProfile/view "> INSPIRE Download Network Service </gmx:Anchor>

                     </gmd:applicationProfile>

                     <gmd:name>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:name>

                     <gmd:description> xxx <gco:CharacterString/></gmd:description>

                  </gmd:CI_OnlineResource>

               </gmd:onLine>

            </gmd:MD_DigitalTransferOptions>

            <!-- (Optional) description of another (non-INSPIRE) data file download capability -->         

            <gmd:MD_DigitalTransferOptions>

               ...

               <gmd:onLine>

                  <gmd:CI_OnlineResource>

                     <gmd:linkage>

                        <gmd:URL> http://xxx.xxx.xxx/file.zip </gmd:URL>

                     </gmd:linkage>

                     <gmd:protocol>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ProtocolValue/WWW:DOWNLOAD-1.0-http-download "> WWW:DOWNLOAD-1.0-http-download </gmx:Anchor>

                     </gmd:protocol>

                     <gmd:applicationProfile>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ApplicationProfile/view "> INSPIRE Download Network Service </gmx:Anchor>

                     </gmd:applicationProfile>

                     <gmd:name>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:name>

                     <gmd:description> xxx <gco:CharacterString/></gmd:description>

                  </gmd:CI_OnlineResource>

               </gmd:onLine>

            </gmd:MD_DigitalTransferOptions>

            <!-- (Optional) description of a site providing addition information on the data set -->         

            <gmd:MD_DigitalTransferOptions>

               ...

               <gmd:onLine>

                  <gmd:CI_OnlineResource>

                     <gmd:linkage>

                        <gmd:URL> http://xxx.xxx.xxx/information.html </gmd:URL>

                     </gmd:linkage>

                     <gmd:protocol>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ProtocolValue/WWW:LINK-1.0-http--link "> WWW:LINK-1.0-http--link </gmx:Anchor>

                     </gmd:protocol>

                     <gmd:applicationProfile>

                        <gmx:Anchor xlink:href =" http://inspire.ec.europa.eu/metadata-codelist/ApplicationProfile/info "> Additional information </gmx:Anchor>

                     </gmd:applicationProfile>

                     <gmd:name>

                        <gco:CharacterString> xxx </gco:CharacterString>

                     </gmd:name>

                     <gmd:description> xxx <gco:CharacterString/></gmd:description>

                  </gmd:CI_OnlineResource>

               </gmd:onLine>

            </gmd:MD_DigitalTransferOptions>

         </gmd:transferOptions>

      </gmd:MD_Distribution>

   </gmd:distributionInfo>

   ...

</gmd:MD_Metadata>

 

 

3          Approach for implementation of new approach

3.1          Changes in MS implementations – Common Implementation Strategy

The proposed changes, while drastically simplifying the implementation of network service metadata, require some additional metadata to be created for data sets, in particular for the resource locator elements.

To keep the impact on MS low, implementation of the new approach could initially be agreed and tested for priority and national/regional data sets.

To document this (and possibly other) agreements, a Common Implementation Strategy could be defined in INSPIRE that outlines which aspects of the current Implementing Rules (and TGs) implementation should focus on over the coming years.

3.2          Changes in the legal and technical framework

The proposed approach would require limited changes in the TGs for metadata (as outlined above), but considerable changes (simplifications) in the TGs for network services.

Whether / how the IRs also would need to be amended, will still need to be analysed. Possibly, it would be sufficient to introduce some minor modifications

  • in the MD IRs clarifying that the service metadata do not apply to spatial data services that are network services, and
  • in the NS IRs clarifying the metadata elements that have to be provided as a response to the Get Download/View Service Metadata request.

Open issue: Should a possible amendment of the network services IRs also clarify the option mentioned in the directive of offering "download of parts of data sets"? Should "whole data set download" still be required even if "direct access download is provided"? Or do we need additional guidance for how to implement "pre-defined data set" download for large data sets (e.g. how to advertise query limits and how to page through results)?

 


Annex – Examples for different implementation/aggregation options

The following example outlines a number of different options for how data sets can be provided through download services, including options where one download services offers more than one data set and options where a data set can be accessed through more than one download service.

For each data set, the resource locator elements and their values are described below.

Data set #1 (pre-defined dataset download and direct access through WFS)

  • Resource locator #1
    • URL: WFS #1 GetCapabilities request
    • protocol: OGC:WFS-2.0.0
    • application profile: download
  • Resource locator #2
    • URL: GetFeature request with stored query for data set #1
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: pre-defined-dataset-download
  • Resource locator #3
    • URL: GetFeature request with spatial object types 1.1 and 1.2
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: direct-access-download

Data set #2 (pre-defined dataset download and direct access through WFS)

  • Resource locator #1
    • URL: WFS #1 GetCapabilities request
    • protocol: OGC:WFS-2.0.0
    • application profile: download
  • Resource locator #2
    • URL: GetFeature request with stored query for data set #2
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: pre-defined-dataset-download
  • Resource locator #3
    • URL: GetFeature request with spatial object type 2
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: direct-access-download

Data set #3 (pre-defined dataset download through Atom, direct access through WFS)

  • Resource locator #1
    • URL: WFS #1 GetCapabilities request
    • protocol: OGC:WFS-2.0.0
    • application profile: download
  • Resource locator #2
    • URL: Atom feed #1
    • protocol: WWW:LINK-1.0-http-atom
    • application profile: download
  • Resource locator #3
    • URL: Atom sub-feed #3
    • protocol: WWW:LINK-1.0-http-atom
    • application profile: pre-defined-dataset-download
  • Resource locator #4
    • URL: GetFeature request with spatial object type 3
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: direct-access-download

Data set #4 (only pre-defined dataset download through Atom)

  • Resource locator #1
    • URL: Atom feed #1
    • protocol: WWW:LINK-1.0-http-atom
    • application profile: download
  • Resource locator #2
    • URL: Atom sub-feed #4
    • protocol: WWW:LINK-1.0-http-atom
    • application profile: pre-defined-dataset-download

 

The following example describes a scenario where several data sets, e.g. at regional or municipality level, are distributed through one download service that aggregates all lower level data sets into a national or regional data set. In this case, the data made available by the service should be described through a data set metadata record, even if it only exists "virtually" as the data offered by the service.

 

National data set (pre-defined dataset download and direct access through WFS)

  • Resource locator #1
    • URL: WFS #1 GetCapabilities request
    • protocol: OGC:WFS-2.0.0
    • application profile: download
  • Resource locator #2
    • URL: GetFeature request with stored query for the national data set
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: pre-defined-dataset-download
  • Resource locator #3
    • URL: GetFeature request with spatial object type 1
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: direct-access-download

Data set region #1 and #2

  • no resource locator or a resource locator pointing to the national data set
  • Open issue: How to express the relationship to the national data set? Which options are offered by ISO standards? Which options are commonly implemented by tools? Should the relationship be expressed in each regional data set or in the national one or in both?

Data set region #3

  • Resource locator #1
    • URL: Atom feed #1
    • protocol: WWW:LINK-1.0-http-atom
    • application profile: download
  • Resource locator #2
    • URL: Atom sub-feed #3
    • protocol: WWW:LINK-1.0-http-atom
    • application profile: pre-defined-dataset-download
  • Resource locator #3
    • URL: WFS #1 GetCapabilities request
    • protocol: OGC:WFS-2.0.0
    • application profile: download
  • Resource locator #4
    • URL: GetFeature request with stored query for the national data set
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: pre-defined-dataset-download
  • Resource locator #5
    • URL: GetFeature request with spatial object type 1
    • protocol: OGC:WFS-2.0.0-get-feature
    • application profile: direct-access-download
    •  
  • Open issue: Is this the correct way to express that this data set is also shared through the national download service?

[1] See e.g. the minutes of the 6 th sub-group meeting: https://webgate.ec.europa.eu/fpfis/wikis/x/nZugE

[4] "data-service linking" means that, based on the data set and service metadata available in national discovery services and by following the requirements laid down in the INSPIRE TGs for metadata and network services, a link can be established between a data set and the download and view services that are providing access to it, i.e. that enable the data set to be downloaded and viewed.  .

[5] (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 on data interoperability; (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.

[6] Precisely speaking, this data representation should be called "collection of spatial objects belonging to a certain spatial object type".

[7] For OGC web service (OWS)-based services, this is the GetCapabilities request.

[8]  According to the INSPIRE requirements. Some of them may still be required by the relevant base standard.

[11] e.g., for OWS-based services, a GetFeature/GetMap with the relevant feature types/layers or, for Atom-based download services, the relevant atom sub-feed.