INSPIRE link in Element 37 Spatial data service type

[PeterParslow]

Guidance section:

Link should perhaps be to the "new" web versions of the INSPIRE TG rather than the older PDF version, e.g. https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139 or https://github.com/INSPIRE-MIF/technical-guidelines/blob/2022.2/metadata/metadata-iso19139/metadata-iso19139.adoc rather than https://inspire.ec.europa.eu/documents/inspire-metadata-implementing-rules-technical-guidelines-based-en-iso-19115-and-en-iso-1

Encoding:

The INSPIRE TG now gives an example using codeSpace to indicate the controlled list:

<gco:localname codespace="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType">view</gco:localname>

This is because ISO 19139 implements LocalName using gml:CodeType, so it is not possible to use gmx:Anchor as you could with a gco:CharacterString.

Note: the example in the INSPIRE Guidance is incorrect, it should be "LocalName" as shown in TG Requirement 3.5 just above; see INSPIRE-MIF/technical-guidelines#71

[PeterParslow]

Not just an example, it's TG Requirement 3.5 which was already in the 2016 & 2017 TGs

[nmtoken]

https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139 seems better as through the Document URL link it gives access to the three variants/formats of the documentation

AsciiDoc
HTML
PDF

[nmtoken]

The schematron rule MI-37a (Spatial Data Service Type) checks for content at path srv:serviceType/*[1] for 'view', 'download' etc. so strictly would allow either gco:LocalName or gco:ScopedName (neither gco:CharacterString or gmx:Anchor are allowed here by the schema).

Should the rule be tightened to check content at srv:serviceType/gco:LocalName or should a new rule be added to check that srv:serviceType/gco:LocalName exists.

[PeterParslow]

"localname" capitalisation fix now applied at INSPIRE MIF: https://github.com/INSPIRE-MIF/technical-guidelines/tree/2023.1

[PeterParslow]

Remaining action:

• change encoding guidelines to include codeSpace
• check whether "tightening" the schema is/was to bring it in line with Schematron, or would also be a (breaking) change to the Schematron. Is it breaking anyway (and therefore this bit would need to be in a next release)?

Needs further discussion: could be split into a non-breaking & breaking part.

Colm: encoding here could be added to MEDIN in a future iteration