Support #3683

Correct implementation of codelists

Added by Michael Östling about 1 month ago. Updated 19 days ago.

Status:ClosedStart date:16 Sep 2019
Priority:HighDue date:
Assignee:Daniele Francioli% Done:

0%

Category:ETF Validator
Target version:-
Submitting Organisation:Lantmäteriet Knowledge-Base relevant?:No
Proactive:No Keyword #1:
Country:SE - Sweden Keyword #2:
Originating UI: Keyword #3:

Description

ETF-validation for Metadata TG 1.3

We some more rigid rules for encoding of code-lists.

These rules seems more strict than they have been previously.

Current ETF-validator requires codelist-element value to be set.

We think this is to strict. 

For example gmd:CI_DateTypeCode  can be encoded like

A

Element value has same value as codeListValue

<gmd:date>
         <gmd:CI_Date>
                    <gmd:date>
                        <gco:Date>2008-06-01</gco:Date>
                    </gmd:date>
                    <gmd:dateType>
                        <gmd:CI_DateTypeCode codeListValue="publication" codeList="https://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" >publication
                        </gmd:CI_DateTypeCode>
                    </gmd:dateType>
             </gmd:CI_Date>
/gmd:date>

or B
Element value in same value as Metadata language

<gmd:date>
         <gmd:CI_Date>
                    <gmd:date>
                        <gco:Date>2008-06-01</gco:Date>
                    </gmd:date>
                    <gmd:dateType>
                        <gmd:CI_DateTypeCode codeListValue="publication" codeList="https://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" >Publikation
                        </gmd:CI_DateTypeCode>
                    </gmd:dateType>
             </gmd:CI_Date>
/gmd:date>

or C

Element value is empty

<gmd:date>
         <gmd:CI_Date>
                    <gmd:date>
                        <gco:Date>2008-06-01</gco:Date>
                    </gmd:date>
                    <gmd:dateType>
                        <gmd:CI_DateTypeCode codeListValue="publication" codeList="https://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" />
                    </gmd:dateType>
             </gmd:CI_Date>
/gmd:date>

 

When reading ISO19139 and TG 2.0 of Inspire-metadata all of the above is valid.  It is only codeListValue that is mandatory
both CodeList and Element-value is optional

But ETF-validator do not accept C above. Isn't this to strict?

 

Regards
Michael

 

History

#1 Updated by Daniele Francioli about 1 month ago

  • Status changed from New to Feedback

Dear Michael,

since this issue is relevant to the INSPIRE Reference Validator, we kindly ask you to report it in the dedicated GitHub space: https://github.com/inspire-eu-validation/community

In particular, you can open a new issue from here: https://github.com/inspire-eu-validation/community/issues/new?template=problem.md

by following the steps suggested.

Thank you,

Daniele

#2 Updated by Daniele Francioli about 1 month ago

  • Assignee set to Daniele Francioli

#3 Updated by Michael Östling about 1 month ago

I have reported this issue on Github 14 days ago, But I see now real action on it besides Peter Parslows comment
https://github.com/inspire-eu-validation/community/issues/115

We would need some feedback on if the general agreement is that validator is correct implemented, which I do not think.
Is the Geoportal validator having the same rules in this area as Reference validator ?

Since the Linkage checker is suggesting to validate metadata in Reference validator in case of problems it s good to know where it differs.

 

 

 

#4 Updated by Angelo Quaglia about 1 month ago

Dear Michael,

please note that the baseline is: if a resource is valid for the ETF validator, then the INSPIRE Geoportal shall be able to extract information from it, unless of course, there is a bug in one of the two tools or both.

However, the INSPIRE Geoportal has always tried to extract as much information as possible and let as many resources through, even though not conformant.

For example, ISO 19139 records that fail the xml schema validation are processed and shown, unless a critical transformation error ensues.

Records missing the Resource Abstract are shown, and so on.

Please note also that there is no more a "Geoportal Validator". The INSPIRE Geoportal works as an "INSPIRE Client" attempting to extract information from INSPIRE Resources. Its evaluation messages are now informational only.

So, if a resouce is conformant or not, is not a concern for the INSPIRE Geoportal any more, unless, of course, it hinders its processing.

Best regards,
Angelo

#5 Updated by Marco Minghini 28 days ago

Dear Michael,

you can also find a reply to your issue in the INSPIRE Reference Validator helpdesk. Please note that the issue tracker for the INSPIRE Reference Validator is https://github.com/inspire-eu-validation/community/issues (you initially opened the issue in another repository that was not monitored).

Best regards,

Marco

#6 Updated by Daniele Francioli 19 days ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF