discovery service INSPIRE compliance

[grigoriouelena]

Geonetwork's initial capabilites response is formed based on a template located here: web\geonetwork\xml\csw\capabilities.xml The administrator can edit this file in order to include the required by the INSPIRE Discovery Service IR elements.

Geonetwork 3.12.x capabilities configuration can be done using a metadata record (https://github.com/geonetwork/core-geonetwork/blob/3.12.x/web/src/main/webapp/xml/csw/capabilities.xml). The administrator can select the relevant metadata record here:

I have edited the capabilities.xml to include all inspire elements.

When no metadata file is selected (see picture above) geonetwork uses the edited capabilites.xml file to form the response, but the title, abstract, relevant authority, fees etc elements remain with no value.

When the relevant metadata file is selected, geonetwork seems to ignore the edited capabilities.xml file, and forms the response with no inspire extended capabilites elements.

Does it use some other capabilites template?

[grigoriouelena]

Reported also in geonetwork github project here https://github.com/geonetwork/core-geonetwork/issues/6053

[grigoriouelena]

After a response we got in the geonetwork github space, the problem is solved.

Geonetwork adds the inspire extended capabilities section when the GEMET INSPIRE themes keywords are present in the discovery service metadata. Those keywords were not added at first because they are not mandatory for the services.

As more dataset will be added in the catalog, the corresponding INSPIRE theme keywords will be added in the discovery service metadata.

In order for this functionality of geonetwork to work properly, I had to make the following edits in the metadata file:

• changed the metadata language so I could provide all the metadata elements in english. the greek language is there also as alternative language
• added a temporal extent section in the discovery service metadata, because the extended capabilities section was looking for this information in the metadata, and in case of absense, the xml schema seamed to be wrong.
• the reference to the interoperability regulation in the metadata conformity section was changed to comply with the relevant value of the extended capabilities, since the validator compares this value with an enumeration.

After the above changes, the discovery metadata record and the capabilities response both pass the validation tests.