Handling DateTypeCode for Thesaurus citation - Keyword Originating CV

[MichaelOstling]

When validating dataset metadata I see that reference validator requires codelist value to be included both as a element-value and a attribute.

<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode"
 codeListValue="publication">publication</gmd:CI_DateTypeCode> 

instead of just referencing the codeListValue

<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication"/>

But when checking the requirements it seems that it should be enough to only add a attribute
https://github.com/inspire-eu-validation/metadata/blob/2.0/common/keyword-originating-cv.md
This requirement is for TG 2.0. Its not as clear for TG 1.3 (as far as I can find information)

The requirement on having the codelist values also as element-values (either as identical value or Describing text) seems to be different element for element. Eg Hierarchical level do not require the value to be stored as a element value.
Can someone give some clarification on how the coding should be done ?

[PeterParslow]

Clause 2.1 of TG 2.0 says (of TG Requirement C.3)
"Both the value of the codeList attribute (a URL that references a code list definition within a register or a code list catalogue) and the textual content of the ISO 19139 element are purely informative. The codeList value may e.g. point to the code list dictionary in the ISO 19139 repository at http://standards.iso.org/iso/19139/resources/codelist/, and if a text is provided, it may contain the translation of the code list value in the language of the metadata."

Presumably, where the 'textual content' is not required/encouraged, the team took the view that this is a term that does not get translated. As a native English speaker, I'm not well placed to judge whether they made the right call in all cases. But I suspect they had in mind these statements in ISO 19139:2006:

"The Name column of the CodeList tables in ISO 19115, Annex B, contains a value that all software will
use to recognize the unique concept or option defined in a row of a CodeList table. As the result, this
value is not a proper name in any language even English."

"The content of the element is either the name of the codelist value in the given code space or the name corresponding to the codelist value in the default language of the metadata when the codeSpace attribute is not present." (but then ignoring the codeSpace attribute)

I cannot find any requirement for having the element values, only this note & a number of examples. Perhaps the reference validator is being over zealous here?

(TG1.3 discussed use of the textual content in a comment & examples, specific to 2.2.7 Resource language

[josemasensio]

Dear @MichaelOstling,

Thank you for your message. We moved this issue from the metadata repository to community.
Please, could you follow our contribution guidelines in order to help us to locate easier the issue?

Best regards.

[MarcoMinghini]

Dear @MichaelOstling,
a similar discussion has been addressed some months ago (with the help of the sub-group 2017.4) in this issue.

In substance, for both MD TG 1.3 and 2.0, the Validator checks (also) that the content of the <CI_DateTypeCode> element is non empty.

However, since I understand that your issue refers to the validation of MD TG 1.3, please note that (as recently discussed in issues #114 and #106) you are encouraged to switch to MD TG 2.0, whose implementation deadline is December 2019.

[MichaelOstling]

In substance, for both MD TG 1.3 and 2.0, the Validator checks (also) that the content of the <CI_DateTypeCode> element is non empty.

But isn't this to strict implementation? In validator I understand it is currently implemented like this. Will you remove this stricter rule?

However, since I understand that your issue refers to the validation of MD TG 1.3, please note that (as recently discussed in issues #114 and #106) you are encouraged to switch to MD TG 2.0, whose implementation deadline is December 2019.

We have already implemented TG 2.0 But when tried to publish to Inspire Geoportal earlier this year we found out that Inspire Geoportal did not yet support TG2.0!!! Even though that should have been working already since December 2016 ! So we have had huge struggle to transform our metadata TG 2.0 back to TG 1.3 to be able to Publish to Inspire Geoportal

`

[MarcoMinghini]

But isn't this to strict implementation? In validator I understand it is currently implemented like this. Will you remove this stricter rule?

Since this has been already discussed and agreed, we will keep this implementation.

We have already implemented TG 2.0 But when tried to publish to Inspire Geoportal earlier this year we found out that Inspire Geoportal did not yet support TG2.0!!! Even though that should have been working already since December 2016 ! So we have had huge struggle to transform our metadata TG 2.0 back to TG 1.3 to be able to Publish to Inspire Geoportal.

Can you please send us an example of MD TG 2.0 which validates in the INSPIRE Validator, but is not supported in the Geoportal? Thank you.

[MichaelOstling]

I think this is really problematic. The TG 2.0 writes
Both the value of the codeList attribute (a URL that references a code list definition within a register or a code list catalogue) and the textual content of the ISO 19139 element are purely informative. The codeList value may e.g. point to the code list dictionary in the ISO 19139 repository at
http://standards.iso.org/iso/19139/resources/codelist/, and if a text is provided, it may contain the translation of the code list value in the language of the metadata.

We are trying to follow the TG and from what we can read there we don't see that the element itself should have a value..
If additional rules are added that is not obvious in TG the TG must be updated. Having a Reference validator that have other rules than whats specified in TG will be very hard to work with. Inspire is already quite complex to handle. Why do we put requirements on elements that is not important for interoperability. Also related to previous comments on "A.11 Codelists in the MD TG v. 1.3". This section recommends two way of expressing codelists. But it does not require any of them. Also the requirement of datetype code Publication. That is also shown in a example and is not a requirement in TG. We don't understand why that value is required.

---

The information we have got from MIG-t is that the Inspire Geoportal do not yet support publishing of Metadata according to TG 2.0. The information we have got on last MIG-t is that is not supported at all. Is that information not correct so that Inspire Geoportal already supports TG 2.0? If so then there are some severe missunderstanding.

[MarcoMinghini]

Dear @MichaelOstling,

after an internal discussion, we decided to relax the test applied by the Validator by removing the check that the content of the <CI_DateTypeCode> element is not empty. The reason is that, although ISO/TS 19139:2007 (in section 8.5.5.1 Building blocks of the CodeList encoding) clearly refers to the 'content of the element', this is not formulated as a requirement.

Therefore, we will change the ETS to relax the test made by the Validator, but we will still mention the presence of the non-empty free text as a recommendation in the ATS (see the NOTE added here).

---

Regarding the Geoportal support for MD TG 2.0, there might have been a misunderstanding in the communication. We confirm that we have not yet fully implemented the change to MD TG 2.0, which means that very few elements (those present in MD TG 2.0 but not in TG 1.3) are lost, but all the other elements are regularly available. We are working to provide full support for MD TG 2.0 (more details will be shared in the upcoming MIG-T).

[danielnavarrogeo]

Dear @MichaelOstling

You can try the last modifications in the staging instance:
http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/

Please let us know if the issue is already solved.

Regards

[josemasensio]

After some internal tests, we checked that everything is working fine, so we will mark as solved this issue.

Best regards.