inspire-mif / gp-data-service-linking-simplification

Good Practice on a consensus-based simplified approach for INSPIRE data and service linkages

Good Practice: Data and Service Linking Simplification

This repository includes the output of the work of the temporary sub-group of the INSPIRE MIG, aimed to create a Good Practice for a consensus-based simplified approach for INSPIRE data-service linkages.

Context & issue

The current level of accessibility of INSPIRE data sets through view and download services is low. One of the reasons are problems with implementing the data-service linking approach currently described in the TGs for metadata and network services, which is considered complicated and partly ambiguous, even by implementation/standards experts. Many organisations are therefore facing difficulties to provide implementations in line with these requirements, which in turn has reflects negatively on the overall usability of the INSPIRE infrastructure, as shown by the low values (on average) of the Monitoring indicators about the data set accessibility.

Scope of the work

This work, framed within Action 2.3 "Simplification of INSPIRE implementation" of the INSPIRE MIWP 2021-2024, aims to develop a shared, consensus-based approach for the simplification of data-service linking that is proven to be implementable by de facto standard web applications, to be further submitted as an INSPIRE Good Practice. The new approach will be alternative to (not substituting) the current approach which is already recognised by the INSPIRE Geoportal.

This work is coordinated by the JRC and involves representatives of the following Member States: AT, DE, DK, EL, ES, FR, IT, LT, NL, PL, SE and SK.

---

Please create the proposals according to the template.

gp-data-service-linking-simplification's Issues

Part B - Remapping of Extended Capabilities - About Metadata date

As some information about the network service will be moved to the data set metadata with the simplification approach, then it is reasonable to assume that the metadata date for the service is the one provided in the data set metadata.
In case the network service serves more layers/feature types, the metadata date could correspond to the most recent metadata date among those ones documented in the corresponding data sets metadata as the TG Requirement C.7 requires that the latest update date of the metadata description shall be given.

TG Metadata - Data-service linking simplification for ISO/TS 19139:2007 metadata

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the TG Metadata.

Addressed TG

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

Location

Section 3. Conformance Classes for data sets

Section 1.4 Position and structure of this document

Issue faced

Section 3. Conformance Classes for data sets should be updated to contain an additional requirements class, “INSPIRE data set metadata resource locator”.

(original image from https://github.com/inspire-eu-validation/metadata/blob/2.0/README.md)

In addition, in section “Position and structure of this document”, it should be clarified that service metadata can be made in accordance with other TGs.

Proposed solution

Add the description of the requirements class, as created by the Subgroup 2.3.2 (Data and Service Linking simplification).

Pull request

New requirement class: TODO.

Section “Position and structure of this document”: INSPIRE-MIF/technical-guidelines#75.

Additional information

Relevant legislation

IR metadata

Impact on IR

No impact.

Impact on INSPIRE validator

TODO

Linked issue

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/

Spatial data service category

How about the required keyword indicating the spatial data service category, has that been discussed earlier?

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02008R1205-20081224#tocId24:

3. KEYWORD

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

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02008R1205-20081224#tocId81

4. CLASSIFICATION OF SPATIAL DATA SERVICES

The keywords are based on the geographic services taxonomy of EN ISO 19119. This taxonomy is organised in categories, the subcategories defining the value domain of the classification of spatial data services.

This may be related to #46. E.g., for a WFS service:

      <ows:Keywords>
         <ows:Keyword>Feature access service</ows:Keyword>
         <ows:Type codeSpace="https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory">spatial data service category</ows:Type>
      </ows:Keywords>

or

      <ows:Keywords>
         <ows:Keyword>infoFeatureAccessService</ows:Keyword>
         <ows:Type codeSpace="https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory">spatial data service category</ows:Type>
      </ows:Keywords>

or

      <ows:Keywords>
         <ows:Keyword>http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/infoFeatureAccessService</ows:Keyword>
         <ows:Type codeSpace="https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory">spatial data service category</ows:Type>
      </ows:Keywords>

Use of the `gmd:function` element to distinguish the INSPIRE operations

In the consolidated approach presented during the third meeting on 11 May, JRC proposed to use the gmd:function element to distinguish the INSPIRE operations. The element would contain information or download values available in the ISO 19139 codelist.

During the meeting it was mentioned that getCapabilities request is always information, so if we agree on its mandatory presence in the Resource Locator, then the gmd:function element could be avoided.

JRC pointed some practical disadvantages of the removal of the gmd:function, i.e. with several resource locators it would need to iterate to discover and distinguish the mandatory linkage element. We would therefore propose to keep the gmd:function for practical reasons.

Figure in 7.2 Resources

I have a few questions / comments regarding the figure in 7.2 Resources:

I tried to create an adapted version – for discussion – and of course the contents of a new figure would depend on the answers to some of my questions.

(as powerpoint)

Scenary 2: Avoiding Service Metadata files and use <inspire_common:Conformity>

Hello,

Last meeting we were talking about avoiding service metadata files for Network Services.
We (the National Centre of Geographical Information - CNIG) agree on that, applying the scenario 2 described in the document TG_ViewServices_v3.11.pdf.

In our opinion the <inspire_vs:ExtendedCapabilities> is useful and, as you can see in the TG_ViewServices_v3.11.pdf, we can express the conformity with Regulation (EU) No 976/2009 using the element <inspire_common:Conformity> within the <inspire_vs:ExtendedCapabilities> and calculate the NSi4-indicators . The idea of using the element gmd:applicationProfile ( within the dataset metadata file) to express the conformity with the Regulation is not very precise and it implies some new unnecessary changes in the dataset metadata files.

predefined <versus> direct download

Hi,

there is an open issue in the discussion paper regarding a distinction between predefined and direct download datasets;
I think we need this distinction, especially in the context of the new ODPSI-DIR where a difference between API/services and bulk-download is made.

Erik

Keyword mapping for keywords from thesauri (WFS)

This issue is a follow-up on a part of the discussion in #39 (repeating the relevant parts here), as this is important for the mapping of keywords.

The mapping of keywords is not really described in the TG download, it only has the table below, and gives an example for inspire_common:Keyword, not for ows:Keywords/ows:Keyword.

(from @heidivanparys)

Regarding the text in ows:Type, its meaning is the same as MD_Identification.keywords.type from ISO 19115/ISO 19119 – see the table below from the OGC Web Services Common Specification – which is "Method used to group similar keywords" (ISO 19115:2003) or "subject matter used to group similar keywords" (ISO 19115-1:2014), and its domain value is a code list with some example values on this diagram from the ISO/TC 211 harmonized model.

So that text could in our case be e.g. "EU legal document", "EU legal document", "degree of conformity", see examples above. It should not be "URI". I noticed that the examples in http://schemas.opengis.net/wfs/2.0/examples/GetCapabilities/ use <ows:Type>String</ows:Type>, but that seems to be a mistake...

(from @AntoRot)

FS specification, but @heidivanparys said

that seems to be a mistake...

I have no elements to say that value is a mistake. If so, I think that also "EU legal document", "EU legal document", "degree of conformity" could be a mistake (e.g. because those values don't come from the code list MD_KeywordTypeCode seen the mapping in the mentioned table D.5).

In any case as the ows:Type element is optional and doesn't provide any added value in my opinion, it can be omitted.

I did some more research, and found OGC Best Practice OGC 08-167r2, Semantic annotations in OGC standards. I added the relevant sections here. They seem to confirm what I wrote earlier. However, I've written a mail to the WFS standard editor to ask about this.

Note the following from those pages:

[...] Here the Keywords element is shown as part of the ServiceIdentification element [...] It must be noted that there can be only one ‘Type’ element per ‘Keywords’ section, hence having all keywords within a ‘Keywords’ section belonging to the same thesaurus (if any). If keywords from different thesauri are needed, multiple ‘Keywords’ sections can be used. [...] there is no way to express a conceptURI that is not an extension of its thesaurusURI. Therefore, a change request should be issued to add the ability to have full-fledged annotations in OGC capabilities, i.e. having each a mandatory concept URI, and optional label, language and thesaurus URI/label. Much like what gmx:Anchor offers.

Of course, the group can choose to require URIs as keyword instead of labels, as also discussed in #39.

It is not required, but quite some data providers add the INSPIRE theme in the service metadata as well, so an example for doing that in the Capabilities would be good, I think:

      <ows:Keywords>
         <ows:Keyword>Administrative Units</ows:Keyword>
         <ows:Type codeSpace="http://www.eionet.europa.eu/gemet/inspire_themes">INSPIRE theme</ows:Type>
      </ows:Keywords>

or

      <ows:Keywords>
         <ows:Keyword>http://inspire.ec.europa.eu/theme/au</ows:Keyword>
         <ows:Type codeSpace="http://www.eionet.europa.eu/gemet/inspire_themes">INSPIRE theme</ows:Type>
      </ows:Keywords>

Italian approach

I agree with the proposal shared by France which is in line with what agreed under the action 2019.2. I add the clarification that the protocol values register is already published in the INSPIRE registry.

In Italy the metadata elements and the codes agreed under the mentioned action are all included in the latest national metadata profile aligned with and extending the INSPIRE one, i.e.:

• linkage element with the URL to the access point of the service (e.g. Get Capabilities document);
• protocol element with a value coming from the register https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue;
• applicationProfile element with a value coming from the register http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType ;
• description element with the value coming from the register http://inspire.ec.europa.eu/metadata-codelist/OnLineDescriptionCode.

Consequently, all metadata records published in the national catalogue and conformant with the latest national metadata profile (and with INSPIRE metadata TGs 2.0) already include the metadata elements above.

The national profile also includes some extensions to what above, i.e.:

• the metadata elements listed above are mandatory for all datasets and, consequently, regardless the type of service;
• we extended the INSPIRE protocol values register by adding two values to cover the following cases:
  • a web page with further instructions for accessing the data set described through metadata;
  • direct access for downloading the data set described through metadata.
    For the former:

...
<gmd:protocol>
   <gmx:Anchor xlink:href="http://www.w3.org/TR/xlink/">WWW:LINK</gmx:Anchor>
</gmd:protocol>
<gmd:applicationProfile>
   <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other">other</gmx:Anchor>
</gmd:applicationProfile>
...

For the latter:

...
<gmd:protocol>
   <gmx:Anchor xlink:href="https://registry.geodati.gov.it/metadata-codelist/ProtocolValue/www-download">WWW:DOWNLOAD</gmx:Anchor>
</gmd:protocol>
<gmd:applicationProfile>
   <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other">other</gmx:Anchor>
</gmd:applicationProfile>
...

In this case we added an internal item as no reference code is published in a controlled vocabulary/register yet.

Recently the national community proposed to add also the name element (as a recommended element).

I proposed a change to add the two items above in the INSPIRE Protocol Value register (see the issue submitted), but the control body preferred not to approve the change as the addition of new values would have implied a change in the definition and reasoning behind the code list.

I ask the group to discuss the possible addition of those items in the INSPIRE register in order to reopen the issue if agreed, as the control body suggested.

I also share an example of a metadata record published in the national catalogue including the information about both an Atom service and a link to directly download the dataset: https://geodati.gov.it/RNDT/rest/document?id=p_tn:EPC4EU_APRIE_all.

Implementation of service linking: evidence, concerns, and recommendation

Esri expects that describing INSPIRE View and Download services as additional distributions in the dataset metadata will simplify implementation for all users (not specific to a particular software) and will have an immediate and positive effect on usability, monitoring, and reporting. This new work recognizes the importance of aligning technical requirements as much as possible to functionalities that are already supported (out-of-the-box) by existing tools. Based on the scope of this activity to be proven to be implementable by de facto standard web applications, we submit the following evidence, concerns, and recommendation.

Evidence/currently supported in production:
ArcGIS (ArcGIS Pro, ArcGIS Enterprise, ArcGIS Online) supports today the ability to define additional distributions, including linkage, protocol, applicationProfile, and function (with the declared gmd: namespace) and, where applicable, to define exact code list values from the INSPIRE domain list:

<linkage>
    <URL>https://services9.arcgis.com/UILu2wREgFBEuDZW/arcgis/rest/services/AU_AdministrativeUnit_4thOrder_Luxembourg_AU_View_demo/MapServer/WMTS/1.0.0/WMTSCapabilities.xml</URL>
</linkage>
<protocol>
    <gco:CharacterString>OGC:WMTS</gco:CharacterString>
</protocol>
<applicationProfile>
    <gco:CharacterString>view</gco:CharacterString>
</applicationProfile>
<name>
    <gco:CharacterString>INSPIRE View service (OGC WMTS)</gco:CharacterString>
</name>
<function>
    <CI_OnLineFunctionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue="information" codeSpace="ISOTC211/19115">information</CI_OnLineFunctionCode>
</function>

Above excerpt of additional distribution information from a sample INSPIRE dataset metadata record. We offer a demonstration Hub with multiple sample datasets as supporting evidence proving this approach.

Practicable limitations/not supported:
However, introduction of gmx:Anchor as a new mandatory method for describing protocol and applicationProfile (shown below) would extend current metadata to impose new requirements not already supported (out-of-the-box) by a range of existing tools. Thus, it will pose practical limitations for implementation.

	<protocol>
              <gmx:Anchor xlink:href="http://www.opengis.net/def/serviceType/ogc/wmts">OGC:WMTS</gmx:Anchor>
        </protocol>
        <applicationProfile>
              <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view">view</gmx:Anchor>
        </applicationProfile>

Recommendation:
When data service linking simplification is used as an alternative to INSPIRE service metadata, the definition of protocol and applicationProfile shall use INSPIRE domain code list values described using either CharacterString or gmx:Anchor.

TG Download - Data-service linking simplification for WFS

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the WFS implementation in the TG Download.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

Section 6.6 Publishing INSPIRE metadata using ows:ExtendedCapabilities.

Issue faced

Section 6.6 Publishing INSPIRE metadata using ows:ExtendedCapabilities should be updated to contain a third option (also called scenario), in which the Download Service metadata elements are published in the WFS capabilities without using the ows:ExtendedCapabilities part.

Proposed solution

1 – Add introductory text describing the third option:

2 – Update TG Requirement 53 from

to

The INSPIRE Metadata for the Download Service shall be linked to in one of the following ways:

1. via an <inspire_common:MetadataURL> in an extended capabilities section;
2. the extended capabilities section shall contain all the INSPIRE Metadata for the Download Service in accordance with Table 19 and the inspire_dls:ExtendedCapabilities schema;
3. the capabilities section shall contain the INSPIRE Metadata for the Download Service in accordance with Table x

3 – Add Table x with the following contents: TODO (see #50 (comment) for a first draft).

4 – Update Table 6 in section 4.1.2:

Pull request

TODO (note: the TG download is not yet available as Asciidoc in https://github.com/INSPIRE-MIF/technical-guidelines/, see the conversion plan)

Additional information

Relevant legislation

Get Download Service Metadata operation

Impact on IR

No impact.

Impact on INSPIRE validator

TODO

Linked issue

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification

Add a requirement about the combination of protocol and applicationProfile

The values to be used for the <gmd:protocol> element and for <gmd:applicationProfile> element are strongly connected, in the sense that if a certain value is used for the protocol then a well specific value shall be used for the application profile. In other words, if I use "wms" for the protocol element then I'm required to use "view" and no other value for the application profile.

I think that adding a requirement about the proper combination of protocol and application profile could be useful, even with a view to a related check in the validator.

The allowed combination should be as follows:

Protocol	Application Profile
csw	discovery
wms	view
wmts	view
wfs	download
wcs	download
sos	download
atom	download

conformity indicator of network services

In the consolidated proposal presented by JRC, recommends to keep the service metadata as currently described in the Technical Guidance documents. due to the provision of conformity indicators.

This is not in line with the recommandation of 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)."

It is not necessary to use standalone service metadata or a capabilities element, to provide this information. It also contradicts with the description of the ApplicationProfile in the same consolidated proposal presented by JRC ;

"By using the above mentioned codelist values coming from the central INSPIRE Registry, it would imply that the described ResourceLocator URL would refer to an INSPIRE Spatial Data Service, fulfilling all the applicable Technical Guidelines requirements."
So by using a value of https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType, you indicate the service is conformant.

Part B - Remapping of Extended Capabilities - About temporal reference

My proposal:

• if the network service serves only one layer/feature type, then the date of publication of the corresponding data set (documented in the data set metadata) could be considered as the temporal reference of the service;
• if the network service serves more layers/feature types, then the temporal reference of the service could correspond to the earliest publication date among those ones documented in the corresponding data sets metadata;
• if the temporal reference of the corresponding data sets is documented through temporal extents, then the temporal extent of the network service could be composed with a start date corresponding to the earliest start date of the data sets and a end date corresponding with the most recent end date of the data sets.

Maybe this could imply an additional requirement in the Good Practice guidelines about the obligation of a date of publication.

TG View - Data-service linking simplification for WMS

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the WMS implementation in the TG View.

Addressed TG

Technical Guidance for the implementation of INSPIRE View Services

Location

Section 4.2.3. Get View Service Metadata operation.

Issue faced

Section 4.2.3. Get View Service Metadata operation should be updated to contain a third scenario, in which the View Service metadata elements are published in the WMS capabilities without using the ExtendedCapabilities part.

Proposed solution

1 – Add introductory text describing the third scenario in 4.2.3.3.1. View service metadata:

Question: should implementation requirements 6 and 7 be merged, and use a formulation such as:

The INSPIRE Metadata for the View Service shall be linked to in one of the following ways:

1. via an <inspire_common:MetadataURL> in an extended capabilities section;
2. the capabilities section shall contain the INSPIRE Metadata for the View Service in accordance with Table 3 and the schema at http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd;
3. the capabilities section shall contain the INSPIRE Metadata for the Download Service in accordance with Table x

2 – Update Implementation Requirement 4:

3 – Update Implementation Requirement 8:

4 – Update Implementation Requirement 9:

5 – Add Table x with the following contents: TODO (table with all the INSPIRE metadata elements, mapped to the WMS capabilities, from annex B).

Pull request

TODO

Additional information

Relevant legislation

Get View Service Metadata operation

Impact on IR

No impact.

Impact on INSPIRE validator

TODO

Linked issue

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/

"virtual datasets"

The "virtual datasets" mentioned in the discussion paper could be aggregated to dataset series with ONE md-set.

Erik

TG Download - Data-service linking simplification for Atom

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the Atom implementation in the TG Download.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

Section 5.1, Atom “Download Service Feed” containing an entry for a Pre-defined dataset. The main changes will occur in section 5.1.3 Download Service Feed: feed “link” element – service metadata, but other sections will have to be updated consequentially.

Issue faced

Section 5.1.3 Download Service Feed: feed “link” element – service metadata should be updated to contain a second option (also called scenario), in which the Download Service metadata elements are published only in the download service feed, not in a metadata record in a discovery service.

Proposed solution

1 – Update TG Requirement 6 from

(see also https://github.com/inspire-eu-validation/download-atom/blob/3.1/atom-pre-defined/download-service-feed-link-to-metadata-record.md).

to

The INSPIRE Metadata for the Download Service shall be linked to in one of the following ways:

1. The Download Service Feed shall contain an Atom link element that links to the metadata record for this Download Service. The value of the rel attribute of this element shall be describedby and the value of the type attribute shall be either application/xml or application/vnd.ogc.csw.GetRecordByIdResponse_xml;
2. The Download Service Feed shall contain the INSPIRE Metadata for the Download Service in accordance with Table x.

and add table x as present below:

Table x

INSPIRE Metadata element	Atom	Fallback
Resource Title (M)	/feed/title
Resource Abstract (M)	/feed/subtitle
Resource Type (M)	-	Is by default “service”
Resource Locator (C)	/feed/link[@rel="self"] in the top Atom feed	Resource Locator of the data set
Coupled Resource (C)	/feed/entry/link[@rel="describedby"] in the top Atom feed
Spatial Data Service Type (M)	-	gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource/gmd:applicationProfile in the ISO/TS 19139:2007 metadata record dataset
Keyword (M)	/feed/category; note that a keyword indicating the spatial data service category is required, see example below this table.
Geographic Bounding Box (M)	-	Geographic Bounding Box of the data set
Temporal Reference (M)	/feed/updated
Spatial Resolution (C)	Spatial Resolution of the data set
Conformity (M)	atom:category element	Using a atom:category element for each specification against which the service is conformant
Conditions for Access and Use (M)	-	identificationInfo[1]/*/resourceConstraints/*/accessConstraints in the ISO/TS 19139:2007 metadata record dataset
Limitations on Public Access (M)	/feed/rights in the top Atom feed
Responsible Organisation (M)	/feed/author in the top Atom feed
Metadata Point of Contact (M)	/feed/author in the top Atom feed
Metadata Date (M)	/feed/updated
Metadata Language (M)	gmd:MD_Metadata/gmd:language/gmd:LanguageCode in dataset metadata for main language, other supported language (if any) will be mapped to the xml:lang

Example for the spatial data service category:

<atom:category term="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/infoFeatureAccessService" scheme="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory"/>

2 – Remove the sentence below table 17, move table 17 to section 5.1.3 and give it title “Mapping of INSPIRE metadata elements to Atom for option 1”.

INSPIRE Metadata element	Atom	Note
Resource Title (M)	/feed/title	Will typically correspond with the Resource Title in the metadata record in the discovery service
Resource Abstract (M)	/feed/subtitle	Will typically correspond with the Resource Abstract in the metadata record in the discovery service
Resource Type (M)	-	See Resource Type in the metadata record in the discovery service
Resource Locator (C)	/feed/link[@rel="self"] in the top Atom feed
Coupled Resource (C)	/feed/entry/link[@rel="describedby"] in the top Atom feed
Spatial Data Service Type (M)	-	See Spatial Data Service Type in the metadata record in the discovery service
Keyword (M)	-	See Keyword in the metadata record in the discovery service
Geographic Bounding Box (M)	-	See Geographic Bounding Box in the metadata record in the discovery service
Temporal Reference (M)	-	See Temporal Reference in the metadata record in the discovery service
Spatial Resolution (C)	-	See Spatial Resolution in the metadata record in the discovery service
Conformity (M)	-	See Conformity in the metadata record in the discovery service
Conditions for Access and Use (M)	-	See Conditions For Access and Use in the metadata record in the discovery service
Limitations on Public Access (M)	/feed/rights in the top Atom feed	Will typically correspond with the Limitations on Public Access in the metadata record in the discovery service
Responsible Organisation (M)	/feed/author in the top Atom feed
Metadata Point of Contact (M)	-	See Metadata Point of Contact in the metadata record in the discovery service
Metadata Date (M)	/feed/updated
Metadata Language (M)	/feed/link[@rel="self"]/@hreflang

3 – Remove the following sentences, as their meaning is included in the table above.

• Typically this will correspond with the 'Resource Title' in the corresponding service metadata record. (section 5.1.1)
• Typically this will correspond with the 'Resource Abstract' in the corresponding service metadata record. (section 5.1.2)
• Typically this will correspond with the value of 'accessConstraints' in the corresponding service metadata record. (section 5.1.9)

Pull request

TODO (note: the TG download is not yet available as Asciidoc in https://github.com/INSPIRE-MIF/technical-guidelines/, see the conversion plan)

Additional information

Relevant legislation

Get Download Service Metadata operation

Impact on IR

No impact.

Impact on INSPIRE validator

This impacts test Download service feed: Provide link to metadata record for the download service.

Linked issue

N/A

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification

contributing to Evidence of implementation & support

Dear Team, We are interested in: reviewing the most recent set of recommendations herein for the service linking simplification in the context of our current SW/SaaS deployments; commenting on (if any) discrepancies of this approach towards the goal "proven to be implementable by de facto standard web applications" with our existing out-of-the-box SW/SaaS; and, contributing to the Evidence of Implementation and Support. We have established a demonstration hub for this purpose and have implemented several demonstration datasets following both the INSPIRE Alternative Encoding guidance, and early proposed approaches herein.

I've explored this repo and followed discussions. As there are several docs and ongoing threads, to make sure we are evaluating against the most current proposal, can someone provide a link in this thread to the proper resource/most current proposal?

Also, we would welcome opportunities to discuss further and participate in future meetings, as appropriate.

Best regards, Jill Saligoe-Simmel, Esri Product Manager

No requirements for <gmd:name> element

In the examples provided in the Annex A the <gmd:name> element is also used.

As the use of that element is already recommended in the INSPIRE MD TG, if no specific requirement is to be defined in the Simplification Good Practice document, I would avoid its use in the examples.

Duplicate requirements / reorganisation requirements classes

Requirement /req/coupled-resource-operateson-locator duplicates (although not exactly, see #38) requirement metadata/2.0/req/sds/coupled-resource from the TG metadata.

Requirement /req/coupled-resource-metadataurl-locator duplicates requirements 13 and 14 of the TG View.

I expected to find that requirement /req/coupled-resource-metadataurl-locator would duplicate requirements in the TG Download as well, but the mapping to wfs:MetadataURL is only present in an informative table, not in a requirement. This is probably something that should be dealt with with an update to the TG Download specification.

For Atom, a requirement regarding the implementation of the Coupled Resource is present, though:

As written in December via mail:

I think it is important

• to group the requirements into requirements classes according to what it is exactly they are setting a requirement for (“service metadata” is not specific enough in this case, what is it you would test using the validator, see screenshot below):
  • ISO/TS 19139:2007 dataset metadata record
  • OGC WFS service
  • OGC WMS service
  • Atom service
• not to repeat any requirements already present in other TGs, but instead
  • adding a dependency to that TG
  • or remove the requirements class if it does not actually define additional requirements

It seems that especially requirements class INSPIRE-Network-Service-Metadata-Coupled-Resource deserves a closer look.

Part B - Question tables in Annex B

Regarding Annex B: should it contain tables like tables 17 and 19 in the TG Download? These are basically tables that show how the metadata elements present in Table 2, Metadata for spatial data services, in the IR metadata are implemented (but see also #52).

A start for WFS (not complete!):

INSPIRE Metadata elements	WFS 2.0 without ExtendedCapabilities + ISO/TS 19139:2007 metadata record dataset
Resource Title (M)	ows:ServiceIdentification/ows:Title
Resource Abstract (M)	ows:ServiceIdentification/ows:Abstract
Resource Type (M)	discard: by default "service"
Resource Locator (C)	Resource Locator in the data set metadata (add path?)
Coupled Resource (C)	wfs:MetadataURL (per feature type)
Spatial Data Service Type (M)	gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource/gmd:applicationProfile
Keyword (M)	ows:Keywords/ows:Keyword
Geographic Bounding Box (M)	(bounding box of data set metadata record)
Temporal Reference (M)	#40
Spatial Resolution (C)
Conformity (M)	#39
Conditions for Access and Use (M)
Limitations on Public Access (M)
Responsible Organisation (M)
Metadata Point of Contact (M)	WFS_Capabilities/ows:ServiceProvider/ows:ProviderName and WFS_Capabilities/ows:ServiceProvider/ows:ServiceContact/ows:ContactInfo/ows:Address/ows:ElectronicMailAddress (#41)
Metadata Date (M)	#42
Metadata Language (M)

Similar tables would have to be added for WMS and Atom (and WMTS as well, I assume)?

ApplicationProfile use

The consolidated proposal is not clear in which cases the value view or download should be used.

In the proposal "By using the above mentioned codelist values coming from the central INSPIRE Registry, it would imply that you are fulfilling the new proposal on TG Requirement 1.8 (multiplicity 2..n) ..." and in the new proposal on TG Requirement 1.8 "In the metadata for each data set, resource locator elements are provided for at least one view and one download service (mandatory), pointing to an "INSPIRE Get Download/View Service Metadata" request.
Therefore, this proposal will affect the Requirement 1.8 of current Metadata TG (v2.0),"

Should we only use the values of this codelist when we are linking to the INSPIRE Get Download/View Service Metadata request? If this is the case the examples doesn't support this view.

If also the use of this values is allowed to a getMap (read endpoint) it is not possible to distinguish between Get View/Download Service Metadata (GetCapabilities) and Get Map / Get Spatial Data Set (GetMap/GetFeature).
If this distinction not is made it is not easy possible to filter the required getMetadata request of the view and download. The use the gmd:description element can solve this, but we have then still the national differences of implementation of the endponts.

From the point of view not to standardize too much it is most convenient to use only the values view and download in ApplicationProfile when the resourcelocator is pointing to the required "INSPIRE Get Download/View Service Metadata" request

Clarify what label to use for <gmd:protocol> element

The Requirement C for the <gmd:protocol> element recommends that the text value of the gmx:Anchor element should match the related codelist label.
The Requirement D requires that in case of the use of gco:CharacterString element the text value SHALL match the related codelist label.

As the ProtocolValue codelist published in the INSPIRE Registry refers to external controlled vocabularies (i.e. OGC Service Types register for all items except Atom), what above should be better specified by explaining that related codelist label means to use the label defined in the source vocabulary and not the label in the INSPIRE Registry.

Question changes TG Download regarding Atom

What would the concrete changes for the TG Download regarding Atom be?

For WFS and WMS, a third scenario will be added. For Atom, would the changes be

1. an update of 5.1.3 Download Service Feed: feed „link‟ element – service metadata
2. an update of the table below

?

protocol label

In the consolidated proposal presented by JRC, i see a deviation in the description of the protocol element. The URI provided in https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue should be used in gmx:Anchor xlink:href and the label can contain the national representation of that value, as discussed/ agreed earlier.

Missing requirements on the presence of a view service and download service

From clause 8.1:

When looking again the Good Practice, I noticed that this is actually not present in the form of requirements. The current requirements do not contain a sentence like “A Resource Locator to an INSPIRE View Service providing view access to the described data set or data set series SHALL be given.”.

In addition, I assume that it is still possible to provide other kinds of “online resources” using the /gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource element, apart from a view and download service, and that the requirements for providing gmd:protocol, gmd:applicationProfile do not apply there. So the requirements should allow for that and not suggest otherwise.

And a final remark: requirement /req/view-linkage and /req/download-linkage have dependencies. In OGC specifications, requirements don’t have dependencies on other requirements. Requirements classes can have dependencies on other requirements classes.

Therefore, would it be an option to do something like the following instead?

• Rephrase /req/view-linkage and /req/download-linkage, give them more subrequirements.
• Remove /req/resource-locator-url, /req/resource-locator-protocol and /req/resource-locator-application-profile.
• Keep /rec/resource-locator-url and /rec/resource-locator-application-profile (these will also apply to those other kinds of “online resources”, but that is in line with the general recommendation to use gmx:Anchor.

Requirement	/req/view-linkage	Note
A	A Resource Locator to an INSPIRE View Service providing view access to the described data set or data set series SHALL be given. It SHALL be encoded using the /gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource element.
B	The element gmd:URL SHALL point to the response of the Get View Service Metadata request of the View Service	Instead of /req/resource-locator-url.
C	The element gmd:protocol SHALL be present.	Instead of /req/resource-locator-protocol, A
D	If the element gmd:protocol is encoded using gmx:Anchor, the attribute gmx:Anchor/@xlink:href SHALL point to the URI of one of the values in https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue.	Instead of /req/resource-locator-protocol, B and C.
E	If the element gmd:protocol is encoded using gco:CharacterString, the text value of gco:CharacterString SHALL match the label of one of the values in https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue in the language of the metadata language.	Instead of /req/resource-locator-protocol, C
F	The element gmd:applicationProfile SHALL be present.	Instead of /req/resource-locator-application-profile, A
G	If the element gmd:applicationProfile is encoded using gmx:Anchor, the attribute gmx:Anchor/@xlink:href SHALL point to https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view.	Instead of /req/resource-locator-application-profile, B and C. The exact value can be specified by having this as a subrequirement.
H	If the element gmd:applicationProfile is encoded using gco:CharacterString, the text value of gco:CharacterString SHALL match the label of https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view in the language of the metadata language.	Instead of /req/resource-locator-application-profile, C.

Requirement	/req/download-linkage	Note
A	A Resource Locator to an INSPIRE Download Service providing download access to the described data set or data set series SHALL be given. It SHALL be encoded using the /gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource element.
B	The element gmd:URL SHALL point to the response of the Get Download Service Metadata request of the Download Service	Instead of /req/resource-locator-url.
C	The element gmd:protocol SHALL be present.	Instead of /req/resource-locator-protocol, A
D	If the element gmd:protocol is encoded using gmx:Anchor, the attribute gmx:Anchor/@xlink:href SHALL point to the URI of one of the values in https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue.	Instead of /req/resource-locator-protocol, B and C.
E	If the element gmd:protocol is encoded using gco:CharacterString, the text value of gco:CharacterString SHALL match the label of one of the values in https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue in the language of the metadata language.	Instead of /req/resource-locator-protocol, C
F	The element gmd:applicationProfile SHALL be present.	Instead of /req/resource-locator-application-profile, A
G	If the element gmd:applicationProfile is encoded using gmx:Anchor, the attribute gmx:Anchor/@xlink:href SHALL point to https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download.	Instead of /req/resource-locator-application-profile, B and C. The exact value can be specified by having this as a subrequirement.
H	If the element gmd:applicationProfile is encoded using gco:CharacterString, the text value of gco:CharacterString SHALL match the label of https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download in the language of the metadata language.	Instead of /req/resource-locator-application-profile, C.

Additional entries in terms and definitions

I think the following entries should be present in the terms and definitions:

• http://inspire.ec.europa.eu/glossary/ViewService
• http://inspire.ec.europa.eu/glossary/DownloadService
• http://inspire.ec.europa.eu/glossary/MetadataElement-CoupledResource
• http://inspire.ec.europa.eu/glossary/MetadataElement-MetadataLanguage
• http://inspire.ec.europa.eu/glossary/MetadataElement-ResourceLocator
• http://inspire.ec.europa.eu/glossary/MetadataElement-SpatialDataServiceType

Part B - Remapping of Extended Capabilities - About Supported languages

This issue is aimed at discussing proposals about the mapping of the <inspire_common:SupportedLanguages> element, which as per Annex B of the consolidated proposal is still pending to be agreed (TBD).

As an initial point of discussion, the mentioned Annex proposes to consider the metadataLanguage in the data set metadata.

Support to multilingualism is a key aspect in INSPIRE.

Please provide your input/proposals on this element in order to reach a consensus by the sub-group.

Referencing a specific layer/feature type in capabilities

I haven't seen this discussion in any of the threads, please correct me if i missed it.

In GeoNetwork (and adopted by some national profiles on iso19139) we have a convention to reference the layer/featuretype name (from service capabilities) in the gmd:name element of gmd:online. In that way being able to reference to the layer within the capabilities described by the current metadata record.

I am aware INSPIRE 'solves' this challenge by using ows:identifier (and/or ows:metadataUrl), but still the reference by name approach is quite common and adds an additional mechanism in case ows:identifier is not populated.

Let me list some related topics here for consideration:

• In https://metadata101.github.io/schemas/fgp/hnap/HNAP.html a suggestion is made to add the relevant layer as additional parameter to the capabilities url
• In the OGC API Records we're trying to capture this challenge as part of the standard, discussion is at opengeospatial/ogcapi-records#95. OGC API seems to move to a templated approach, e.g. https://example.com/wms?request=getMap&layer=forest&bbox={bounds}&crs={srs}&width={width}&height={height}

Discussion start

Dear all,

I think we should start our discussion with the very good discussion paper.

I have made some comments to the paper - feel free to comment the comments, but open a new issue per theme.

Best regards Erik

Part B - Remapping of Extended Capabilities - About Metadata Point of Contact

As some information about the network service will be moved to the data set metadata with the simplification approach, then it is reasonable to assume that the metadata point of contact for the service is the one provided in the data set metadata.

Distinguish between requirements and recommendations

The requirements C and D defined in the tables in the section 8.1 for gmd:protocol element and gmd:applicationProfile element use verbal forms (i.e. SHOULD and MAY) more typical of recommendations than requirements.

My proposal is to split the current requirements in two groups: Requirements (A and B) and Recommendations (C and D).

Mismatch between INSPIRE <gmd:protocol> label and OGC preferred label

In the proposed solution, the label required to be used for gmd:protocol element refers to the INSPIRE code list labels that use an expressive format for OGC services (e.g., "OGC Web Map Service"). The expressive labels do not match the OGC's preferred labels (e.g., "wms"). Additionally, the expressive labels for OGC services in the INSPIRE code list are linked to their associated OGC pages in which the OGC preferred label is clearly identified.

The likelihood is high that this will confuse end users as to which label to use. Additionally, requiring expressive labels precludes de facto standard web applications from populating this element value using the preferred label from an international standards organization. At worst, using the OGC preferred label will cause the INSPIRE metadata record to be rejected as invalid.

Suggestions to address this discrepancy, either:

1. In the INSPIRE code list registry, change the labels for the INSPIRE protocol values to match the OGC preferred labels, e.g., http://www.opengis.net/def/serviceType/ogc/wms expressed with the label “wms”, or
2. In the GP, for backwards/forwards compatibility of de facto standard web applications, allow the gmd:protocol element to use either the OGC preferred label or the INSPIRE code list label.

Finally, would there be any practical implications for future validation tests that are relaxed to be case-insensitive, e.g., WMS or wms?

thank you for your consideration

Wrong reference to the TG Requirement 1.8

In the latest proposal, we can read in the section 8.1:

In particular, TG Requirement 1.8 of INSPIRE MD TG expresses the obligation to provide online access, if available, to the described data set or data set series.

Furthermore, it suggests that at least two locators need to be expressed in the data set metadata: one for a View Service and one for a Download Service.

The current wording of the TG Requirement 1.8 doesn't include any suggestions about providing at least a locator for a View Service and another one for a Download Service.
This was instead the new proposal of the TG Requirement 1.8 included in the Discussion Paper.

Consequently the second sentence quoted above should be removed or reworded.

Part A

Hi,
Where can I find part A of this work?

Comment on final proposal - Dataset metadata change

JRC proposal:

#Data set metadata
The proposed approach for data set metadata is aligned with the Discussion Paper. Data sets are documented in metadata as currently described in the Technical Guidance documents, with minor modifications for the provision of data-service linkage. In the metadata for each data set, resource locator elements are provided for at least one view and one download service (mandatory), pointing to an "INSPIRE Get Download/View Service Metadata" request.

Therefore, this proposal will affect the Requirement 1.8 of current Metadata TG (v2.0), line:

The multiplicity of this element is 0..n.

by changing the multiplicity to 2...n.

Since the beginning we mentionned that the simplification approach would be on top of the existing one. The multiplicity should then not be changed for the current approach.
The Metadata TG should then say something like:
2..n when using simplification approach and 0..n otherwise.

Part B - Remapping of Extended Capabilities - About Keywords

(I could not find the Keyword issue so I open one here)
Currently the mapping for ATOM with Keywords says not mapped. However I think that atom:category could fit. Any objection ?

Normative references

INSPIRE MD TG - JRC is based on [ISO 19115] EN ISO 19115:2005, Geographic information – Metadata (ISO 19115:2003)
the reference to ISO 19115-2:2019 - ISO 19115-2:2019, Geographic information — Metadata — Part 2: Extensions for acquisition and processing seems not correct

simplification of service md

We should leave all standard md-fields within the service-getCap response mandatory und not suggest to remove them - why?
More info about the service is better than less ... - the main thing is, that's standard response and that's mandatory.

Erik

example WFS downloadable dataset

In the last example, the additional Resource Locator element is pointing to the data set itself. In the description of 8.1 it is indicated that in that case it should be avoid the use of the gmd:applicationProfile element, so please remove this element from the example.

Comments on the section 8.2

I think that the requirements in the section 8.2. are redundant as they are already defined in the INSPIRE MD TG and in INSPIRE NS - View / Download Service TG.
In addition, although service metadata is indicated as optional in the section 7.2, it is ultimately mandatory because:

• if Member State decides to follow the scenario 1 then a service metadata record is required to be referenced through the <inspire_common:MetadataURL> element within the INSPIRE ExtendedCapabilities section;
• if Member State decides to follow the scenario 2 then all the service metadata elements shall be documented in the ExtendedCapabilities section.

This because it was decided not to address the issue of removing the ExtendedCapabilities, that makes the simplification action incomplete in my opinion.

Part B - Remapping of Extended Capabilities - About conformity issue

This issue is aimed at summarizing the proposals about the mapping of the <inspire_common:Conformity> element starting from the Annex B in the consolidated proposal, in order to add further specific comments and to reach a consensus by the sub-group.

As pointed out in the Implementation Requirement 22 in INSPIRE NS - View Service TG, the INSPIRE Metadata Regulation requires that metadata shall include information on the degree of conformity with the implementing rules on interoperability of services. For this purpose, the <inspire_common:Conformity> element shall be added within an <inspire_vs:ExtendedCapabilities> (see Implementation Requirement 23 in INSPIRE NS - View Service TG) or an <inspire_dls:ExtendedCapabilities> (see TG Requirement 53 in INSPIRE NS - Download Service TG) element.
As the common opinion in the sub-group is that the extended capabilities should be removed, we need to find an element in the service metadata to use instead of the <inspire_common:Conformity> element, keeping the conformance to metadata Regulation.

Proposal from IT (me)

Having as reference the Regulation 1089/2010 (against which it is mandatory to declare the conformance based on Metadata TG), the proposal is adding a specific keyword encoded with the values coming from the code list "Degree of conformity" published in the INSPIRE metadata code list register.
With respect to other specifications (e.g. Regulation 976/2009), each service provider is free to add an extended capabilities section (that is kept as optional) including the <inspire_common:Conformity> element.
Here the examples about this proposal:

• For WMS, add a wms:Keyword element with a value coming from the code list mentioned above and the attribute vocabulary pointing to the code list URI within the wms:KeyworList group

...
<wms:KeywordList>
   <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity”>conformant</wms:Keyword>
...
</wms:KeywordList>

• For WFS, add a specific group ows:Keywords with a ows:Keyword element with a value coming from the code list mentioned above and a ows:Type element including the code list label and the attribute codeSpace pointing to the code list URI:

...
<ows:Keywords>
   <ows:Keyword>conformant</ows:Keyword>
   <ows:Type codeSpace="http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">Degree of conformity</ows:Type>
</ows:Keywords>
...

• For Atom, add a atom:category element including the term attribute with a value coming from the code list mentioned above and the scheme attribute pointing to the code list URI:

...
<atom:category term="conformant" scheme="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity"/>
...

Proposals from FR (@MarieLambois)

• adding a specific keyword encoded with the values coming from the Spatial data service type code list to declare the conformity (see the specific comment in the issue 12.
  Example:

...
   <wms:Keyword vocabulary="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType">view</wms:Keyword>
...

• Alternatively, adding a specific keyword to cite the Regulation applied for the conformity declaration (see the specific comment in the issue 13).
  Example:

...
<wms:KeywordList>
   <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/LevelOfConformity”>COMMISSION REGULATION (EC) No 976/2009</wms:Keyword>
...
</wms:KeywordList>

coupled ressources

The "coupled ressources" in the service-getCap (= MetadataURL) are extremely valuable - we should keep them in any way (especially when the service-md are removed)
If service-md are maintained, how to handle differences in the cr of the service-md and the MetadataURL of the service-getCap (e.g. in the validation or the data-service-linking)?

Erik

Requirement: <srv:operatesOn> element and Requirement: <wms:MetadataURL> and <wfs:MetadataURL> elements

In the requirement for scenario 2 is specified that the metadata is available in a Discovery Service catalog. I think this is also the case in the requirement for scenario1. Please articulate the requirements in the same way, whether to include both or not

Comments and proposals on the open issues

With reference to the consolidated proposal and the open issues pointed in the summary of the third meeting, please find below my comments and my proposals.

Service metadata

Keep the service metadata only for Spatial Data Services and for Network Services other than view and download. Concerning the need of the provision of conformity indicators see the proposal below.

Use of the gmd:function element

I would avoid the use of this element for the following reason:

• If the resource locator elements should point to an "INSPIRE Get Download/View Service Metadata" request as pointed in the section "Data set metadata", then it would be unnecessary;
• the value "download" for a Get Map request would be semantically inappropriate, as @MarieLambois also pointed out in her comment to the issue #10.

Resource locator

I think that the GetCapabilities request should be used as value of the linkage element, as pointed above.
Alternatively, another proposal for WMS could be as follows:

• if the network service provides view access only to one data set and the layer has a <Name> property, then the resource locator may be the GetMap request with that Name as the value of LAYERS argument, otherwise, if no <Name> property is included, the GetCapabilities request;
• if the network service provides view access to several data sets and each layer has a <Name> property, then:
  • either the resource locator may be the GetMap request with that Name corresponding to the data set described by the metadata record as the value of LAYERS argument
  • or the resource locator may be the GetCapabilities request with the gmd:name element in the metadata record encoded with the value of the layer property <Name>;
• if the network service provides view access to several data sets and no layer has a <Name> property, then the resource locator may be the GetCapabilities request.

A similar proposal could be defined for the other network services.

Conformity declaration

I disagree with the implicit conformity declaration as the spatial data service type is a mandatory element for the Metadata Regulation and consequently shall be documented regardless the conformity to be instead declared using other metadata elements.
If service metadata can be automatically generated from the service, my proposal is to move that declaration in the GetCapabilities document by adding a specific keyword encoded with the values coming from the code list "Degree of conformity" published in the INSPIRE metadata code list register. Here the examples about this proposal:

• For WMS, add a wms:Keyword element with a value coming from the code list mentioned above and the attribute vocabulary pointing to the code list URI within the wms:KeyworList group

...
<wms:KeywordList>
   <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity”>conformant</wms:Keyword>
...
</wms:KeywordList>

• For WFS, add a specific group ows:Keywords with a ows:Keyword element with a value coming from the code list mentioned above and a ows:Type element including the code list label and the attribute codeSpace pointing to the code list URI:

...
<ows:Keywords>
   <ows:Keyword>conformant</ows:Keyword>
   <ows:Type codeSpace="http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">Degree of conformity</ows:Type>
</ows:Keywords>
...

• For Atom, add a atom:category element including the term attribute with a value coming from the code list mentioned above and the scheme attribute pointing to the code list URI:

...
<atom:category term="conformant" scheme="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity"/>
...

To further simplify, we could consider only the value of the keyword without any pointing to the reference code list.

Protocol code list extension

I am also wondering whether, once agreed on the need for the extension, it is worth adding the codes related to other types of protocols such as REST API or OGC API Features.

Extended capabilities

I think that extended capabilities should be dismissed. Otherwise, if we keep both service metadata and extended capabilities, what would the simplification be?
The table below shows how the information included in the extended capabilities could retrieved alternatively.

Extended capabilities	Simplification	Service type
inspire_common:ResourceType	By default = service	WMS - WFS
inspire_common:ResourceLocator	Resource locator in the data set metadata	WMS - WFS
inspire_common:SpatialDataServiceType	Moved to the applicationProfile in the data set metadata	WMS - WFS
inspire_common:TemporalReference	Consider the temporalReference in the data set metadata?	WMS - WFS
inspire_common:Conformity	Declared through the wms:keyword element	WMS - WFS
inspire_common:MetadataPointOfContact	Consider the metadataPointOfContact in the data set metadata	WMS - WFS
inspire_common:MetadataDate	Consider the metadataDate in the data set metadata	WMS - WFS
inspire_common:SupportedLanguages	Consider the metadataLanguage in the data set metadata	WMS - WFS
inspire_dls:SpatialDataSetIdentifier/inspire_common:Code - inspire_dls:SpatialDataSetIdentifier/inspire_common:Namespace	Data set identifier in the data set metadata	WFS

Just for information, recently the GeoNetwork Italian plugin (i.e. the plugin aligned to the latest national metadata profile) for the version 3.10.x was released also including the management of the metadata elements for the simplification approach agreed under the 2019.2 action. I think that we should agree on a solution that takes into account existing initiatives and deviates as little as possible from current implementations.

Part B - Remapping of Extended Capabilities - About Unique Resource Identifier (inspire_dls:SpatialDataSetIdentifier)

From the IR metadata:

So the metadata element Unique resource identifier is not relevant for services.

This seems to be written wrongly in the TG Download and TG View, or am I missing anything here?

As for INSPIRE Spatial data set identifier, this means, as far as I can see, that that section can be removed completely. You could argue that inspire_dls:SpatialDataSetIdentifier is the mapping of “Coupled Resource”, but we have the Coupled Resource already via wfs:MetadataURL.

Labels expressed in the metadata language

The Requirements C and D for <gmd:protocol> element and for <gmd:applicationProfile> element recommend to use the codelist labels expressed in the metadata language.

As in case of <gmd:protocol> element the labels are acronyms in most cases (i.e. wms, csw, wfs, ...) the recommendation above doesn't make sense.

In case of <gmd:applicationProfile> element, the Regulation 1205/2008 in Part D3 also provides the language-neutral values for the Spatial Data Service types. Consequently the Requirements should allow for the use of either language-neutral values or the labels expressed in the metadata language.

Coupled resource implementation is not compliant

ISO requirement for the operatesOn element is the following:

Thus the link should point to a MD_DataIdentification XML element.
However in the current proposal the link will point to the MD_Metadata element.

Suggestion: Addition of #MD_DataIdentification at the end of the URL would make the proposal compliant with ISO.

endpoint versus accesspoint

We need a clear definition of accesspoint and endpoint.

• service-md: AP or EP
• service getCap: AP or EP
• getMap/getFeature: EP?
• AtomFeed: AP or EP
• datasetFeed: AP or EP
• DL-Link: EP?

Erik

harmonised versus as-is datasets

If we have only ONE md-set for the harmonised and the as-is "view" on ONE dataset, we need to distinguish these to "views" in the ressource locator - links. How to do that?
In the AppProfile, ProtocollValue, Description, ...?

Erik