INSPIRE data/service linking simplification - 14-06-2019 Teleconference

They provided a series of test cases.

As approach, they choose follow their Dutch metadata profile, which implements INSPIRE MD TG, documenting all the different elements they applied, such as:

• in line with INSPIRE SDS, for dataset metadata they distinct access points from endpoints, through different codelist values ("-protocol" and "-mediatypes").
• added applicationProfile element (for this test only, not used in Dutch profile)
• regarding the services
  • the Capabilities document contains the minimal set of elements as defined in the DOC7
  • they provide the recommended MetadataURL

Provided test cases:

1. Kadaster
   1. The most simple situation: one dataset metadata, "Administratieve Eenheden", with two links to WMS and WFS. The services provide only one dataset.
2. CBS
   1. A little bit more complex situation: one dataset metadata, "Wijk- en Buurtkaart 2018 versie 1" with six links, some of them do not intented to fullfil INSPIRE requirements.
   2. The URLs point to:
      1. HTTP direct zip file download (description elem: endpoint)
      2. WMS service (description elem: accesspoint)
      3. WFS service, no INSPIRE compliant (with no applicationProfile, description elem: accesspoint)
      4. ATOM service with one dataset (description elem: accesspoint)
      5. ATOM feed to a dataset with CRS (description elem: endpoint)
      6. ATOM feed (description elem: accesspoint)
3. RWS
   1. WMS and WFS services, both providing 3 datasets.
   2. Each of them contains 4 links to a:
      1. WMS (with description elem: accesspoint)
      2. WMS via a GetMap request (with description elem: endpoint)
      3. WFS (with description elem: accesspoint)
      4. WFS via a GetFeature request (with description elem: endpoint)

Their conclusion / future plans:

The coming months, all INSPIRE metadata will be migrated to a new Dutch metadata profile to fulfil the requirements of the INSPIRE Metadata TG, before the deadline of December 2019. This metadata profile is being implemented in the Dutch catalog software (geonetwork)  at this moment.

Only thing we miss in this new Dutch metadata profile is the element applicationProfile, specifying that the URL is a INSPIRE view or download service. We can add this optional in our catalog and in the instructions at this moment, although it is not required yet. Agreement on the exact content of this element for INSPIRE use soon, is more than welcome. Changes on the protocol code list have more consequences since this is well implemented in all metadata. Agreement on the exact content of this code list for INSPIRE use soon is more than welcome. We like to change our metadata in one go.

So for us it is relative simple to provide view and download access to INSPIRE data via the online resource metadata elements in the dataset metadata, compared to the current situation.

1.1      Agreement on values of the protocol codelist used for INSPIRE

1.2      we provide in the protocol element additional via the anchor the location of the specification f.i. http://www.opengeospatial.org/standards/wms, instead of an URI to a value in a codelist.  is this useful for INSPIRE?

1.3      in the applicationProfile element we provide additional via the anchor the location of the specification f.i. https://inspire.ec.europa.eu/documents/technical-guidance-implementation-inspire-view-services-1 instead of an URI to a value in a codelist. Is this useful for INSPIRE?

1.4      Making the examples we had most problems with the ATOM example. What should we provide as we consequently follow the simplification rules? (no duplication, no INSPIRE specific extensions) Is an ATOM service feed necessary or is the dataset feed enough?

1.5      Providing the name (requirement of the Dutch profile) of a layer or featuretype in the element name is not necessary if this is part of the URL requesting the described dataset in a service containing more datasets. But it can be an alternative or additional to those complex URLs, specifying the layer or featuretype containing the described dataset. There are a lot of possible combinations of CRS, outputformats etc. I guess we don’t like to provide URL’s to all those endpoints. What should be provided if an INSPIRE service contains more datasets? All possible combinations?

1.6      In the service capabilities we provide the recommended MetadataURL, we think this is still valuable.

1.7      Should we allow zip as mediatype, or should the mediatype describe what is inside the zip.

Provided 2 examples, only with WMS and WFS services. They differ in the linking method.

Their conclusion / future plans:

As far as we have already implemented data-service linking in our national MD profile, this change will not be dramatic for us and we are ready to implemented it. But we prefer to preserve complete service MD in our Discovery service and suggest that only the mandatory elements (Resource title and Responsible organisation) are selected and harvested to EU Geoportal.

We keep information about services in its metadata rather than in capabilities documents. We are linking to service metadata in extended capabilities. This new approach will mean for us to keep this information also in capabilities documents because we want to preserve also our national metadata profile which is widely used. This could lead to some inconsistences in the future.

Provided 2 examples:

1. With the first one, they follow the proposal including also a GetFeature request.
2. With the second one, they proposed a discussion about including only GetCapabilities requests for composed data sets. (ref. Question column)

Their conclusion / future plans:

Concerning the future plans, we are finalizing the revision of the national metadata TGs (keeping the Italian extensions and including the metadata elements required for the simplified option) to align them to the INSPIRE metadata TGs 2.0 and, consequently, our national catalogue and the linked tools (such as the editor and the validation system) will be updated. In order to provide you with more precise information on the overall approach that we would like to follow with regard to the linking simplification option, data and services providers feeding the national catalogue are required to provide us with their proper feedback. We’ll inform you on that in the next days.

They provide one example.

They copied-then-adapted Capabilities documents, therefore they wonder if this approach could still work for our tests.

Their conclusion / future plans:

I think this is a very good way forward for the Inspire-implementation. But still we have a number of issues we need to understand better and discuss. I hope we can do that coming months.
In Sweden we have already proposed this model of adding useful  Resource Locators to datasets so most of our metadata have this information already now. But not to the extent that is needed by new simplified model.
But we hope we solve the bulk work with automatic transformations.

Protocols  

In our Swedish profile we already use protocol to separate different types of links. Even though our protocols use different code lists we can probably in transformation automatically add the Anchor-element in protocol and also the application-profile. We have not be sure of the protocol-values to use. The URL to Inspire-registry is not yet published so I have looked into the Check version.

http://inspire.ec.europa.eu/metadata-codelist/ProtocolValue/

https://services.cuzk.cz/registry/codelist/OnlineResourceProtocolValue

All these protocol values are a bit complex since there many codelists for this. We know some are using this one codelist for protocols

https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv

Restrictions

Regarding Restrictions on access and use we see some possible problems that it will be different restrictions for View and Download-services. So we might add some encoding of separate restrictions for each Online-link. We are doing some tests on this by trying to encode the description element with information on restrictions.

Reference to dataset-metadata in WFS-services

I could not see that MetadatURL linking to datasets are mandatory for Featuretypes. But we have anyhow added this.

They provide one example, as new metadata (provided as-is), for this exercise, following the DOC7 proposal.

Their conclusion / future plans:

The Hellenic NSDI and INSPIRE infrastructure is currently being built and evolving. We are open to new simplified approaches, because for now we do not have many records in our catalog and we have not included yet external data and service providers.

Some of the metadata elements that is proposed to be removed, remain in the caps, due to internal Geoserver settings.

Apparently, they can be removed but at a later stage, because the testing was made at the production environment and any changes would affect the whole official implementation.

They provided one example, with the potential/encountered issues (see next column).

In their feedback, they also included a discussion about a particular type of dataset type they (want to) offer. They called it "specific" maps. They propose the definition of an "invoke" service (with the keyword "infoMapAccessService"), in order to identify those "specific" maps. They improve this model in 2018 with "infoChartAccessService". This extension of the codelist will be stored in the French registry.

Their conclusion / future plans:

There is currently an update of the national metadata guidelines so we plan to integrate those new recommendations to the guidelines.

The new implantations (mostly simple cases where a small dataset is served by its own services), especially for priority dataset will be mainly based on this new approach.

However for some more complicated cases, other kind of interests (as explained upper in the document) or existing metadata we would still be using the old data-service linking approach.

Encountered issues

• On both WFS and WMS services are key protected. On WMS I think we could work on that, allowing a general picture without key but on WFS I think it is not an option to remove the key as querying the whole dataset at once is not really resource-demanding.
• The number of features that can be requested at once is limited in the WFS. I was wondering if this limitation should be shown by adding a MafFeature parameter in the GetFeatureRequest.

• It seemed to me that a generic GetFeature request will be more easy to reuse by applications as it provides a feature types list.

• Sometimes the dataset is so huge that viewing the whole dataset at once might not be seen (the limit is currently around 1:10 000 000 for this dataset so it is really at the limit).

They provided one example, "Addresses", with WMS and ATOM services linked to the dataset metadata.

Their conclusion / future plans:

[not provided]