European Commission logo
INSPIRE Community Forum

Geonetwork gmx/gmd:ci_DateType validation issues

Dries Luts
By Dries Luts Replies (4)

Hi all,

Some questions about saving INSPIRE compliant metadata in Geonetwork.

So we are using Geonetwork 3.6.0 to create, save and for some metadata also publish INSPIRE metadata.

However while we are able to create metadata that gets fully through the ETF validator by exporting the metadata from the geonetwork and editing the XML, when the matadata is saved in geonetwork, Geonetwerk seems to change parts of the xml. These changes then results in the validator showing the metadata as failed. Hopefully somebody else has already experienced these issues and knows to solve them. After asking the validator team on Github it seems likely to me that we may have missed some essential configuration steps for our geonetwork installation?

In Geonetwork I have added the GEMET - INSPIRE themes thesaurus using Re3gistry.
When I then try to validate the exported xml-metadata file, I each time get a fail for the dataset keyword test. It points out that the gmd:CI_DateTypeCode is empty. When I inspect the xml I find that gmd:CI_DateTypeCode is filled in with codeListValue "publication" but publication is not actually filled in between an opening and closing tag. If I manually change this in the xml, provide the publication value with a closing tag, when I upload it back into the geonetwork, automatically the closing tag and publication value are removed.

Any way I can prevent geonetwork from doing this?

(The xml used and the validator report can be found on github:

The second problem I can't figure out is how to prevent geonetwork from using gmx:anchor for its internal reference to the thesaurus. Using gmx:anchor results in a schema validations error, both in Geonetwork and the validator. I have tried to use the options in Geonetwork to try to force it to use gco:characterstring instead of gmx:anchor, but for some reason it keeps changing back to gmx. Any suggestions/experiences on this topic would be very usefull.


  • Dries Luts

    Yes Holger, they seem to be related (but the actual validation errors are different). Anyway I will follow up both threads in the hopes that one results in a solution and then cross-post the working solution.

  • Lars Erik STORGAARD

    By Lars Erik STORGAARD

    I have had same problem with the ETF Validator and it is been reported. Check this issue: (with status "Ready for testing")

  • Dries Luts

    Hi Lars,

    Thanks for pointing me to that issue. Unfortunatly it seems that the ETF Validator-team has decided that the issue is a "won't change". I think we have to look for a solution to the Geonetwork team? Anyway I find both issue's frustrating because for the second one it is something extra being added by Geonetwork and the first issue is about something that is missing but isn't, it just not in the metadata in the exact way it is expected by the validator.

    By the way, I have the impression that the language for the codelist titles mentioned in the above issue also hasn't yet reached the production environment?