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

[jsaligoe]

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

[jescriu]

Dear @jsaligoe,
Thank you for your input. We will discuss it in the meeting we have scheduled next Wednesday, and will provide you with feedback.

[MarieLambois]

Discussion from 2022-11-16 meeting:
Decision to change the label in the INSPIRE register once the issue opengeospatial/NamingAuthority#208 mentioned by @heidivanparys will be solved.

[heidivanparys]

I asked for an update in opengeospatial/NamingAuthority#208.

[heidivanparys]

We've received no reply from OGC. However, given the preferred labels at the links below, and given that there seem to be discrepancies at OGC's side, see opengeospatial/NamingAuthority#208, I suggest that we close this issue without without changing anything in the INSPIRE registry.

@jescriu Perhaps you want to take this up with OGC first during your coordination meetings? I will let you take the final decision whether to close or not.

• https://github.com/opengeospatial/NamingAuthority/blob/ec289ee1374ca3fae344d6aaefafb9cadb6dace8/definitions/conceptschemes/servicetype.ttl#L47
• https://github.com/opengeospatial/NamingAuthority/blob/ec289ee1374ca3fae344d6aaefafb9cadb6dace8/definitions/conceptschemes/servicetype.ttl#L68
• https://github.com/opengeospatial/NamingAuthority/blob/ec289ee1374ca3fae344d6aaefafb9cadb6dace8/definitions/conceptschemes/servicetype.ttl#L94
• https://github.com/opengeospatial/NamingAuthority/blob/ec289ee1374ca3fae344d6aaefafb9cadb6dace8/definitions/conceptschemes/servicetype.ttl#L132
• https://github.com/opengeospatial/NamingAuthority/blob/ec289ee1374ca3fae344d6aaefafb9cadb6dace8/definitions/conceptschemes/servicetype.ttl#L166

[fabiovinci]

Dear all,

you can find all the updates related to the integration of this good practice in this Discussion.

Regarding this issue, we decided, at the moment, to relax the check of the protocol labels and to consider valid also the OGC labels (even in capital letters). See the related note in the ATS.

The values that will be considered as valid are in the table below:

Any comment/suggestion is more than welcome.

[jsaligoe]

Thank you, @fabiovinci for this resolution.

[jescriu]

Today we will be asking OGC for an update on opengeospatial/NamingAuthority#208