search

INSPIRE-MIF / helpdesk-validator

Community discussion forum for INSPIRE validation issues
42 stars 23 forks source link

md common req C.21: Dataset Conformity Specifications #472

Closed alitka closed 3 years ago

alitka commented 3 years ago

proposal of improvement related to the (error) message (the test itself is correct!)

The metadata record set has [...] record(s) with errors for this assertion. XML document '[ ... ]': The metadata record contains a reference to a specification, but no dateType of 'creation', 'revision', or 'publication' is provided for it.

This (error) message is misleading or an accidental or inexperienced user could misinterprets this. The TG Requirement C.21 clearly states that for all specifications the date type (code) shall be point to the value "publication" of the ISO 19139 code list CI_DateTypeCode.

Therefore the (error) message should be change to e. g. The metadata record set has [...] record(s) with errors for this assertion. XML document '[ ... ]': The metadata record contains a reference to a specification, but the codeListValue or date type is not corret. The codeListValue or date type should be 'publication'.

additional "material"

iuriemaxim commented 3 years ago

@alitka But the user can provide also the "revision" date for that specification, isn't it? Quite many specifications were ammended by other specifications. So just providing the "publication" withouth "revision" could be misleading (i.e. refering to Commission Regulation 1089/2010 by indicating only the publication date from 2010, as it was ammended in 2011, 2013 and 2014). So the final sentence of the text could be <<At least the codeListValue "publication" should exist for the dateType element, but "revision" could be provided too in order to reflect the latest ammendments of the initial specification.>>

alitka commented 3 years ago

@iuriemaxim - I can follow your argumentation, but right now the test ist only checking the codeListValue "publication" (see ATS - Dataset Conformity Specifications):

Test method

This is related to the TG Requirement C.21:metadata/2.0/req/common/conformity-specification: tg_req_c 21

ghost commented 3 years ago

I agree with @alitka on this.

On the other hand I can also understand the point from @iuriemaxim.

Requirement for code list value to be publication is checked globally (every time date type code element is instanced), for example by keywords when metadata is referencing controlled vocabulary and has some of the values.

Let's assume this case: Metadata record is referencing non-INSPIRE controlled vocabulary (national metadata codelist from some registry), which is perfectly fine. If code list value is other than publication (for example revision) that means that test will fail. In my opinion this shouldn't be the case because non-INSPIRE vocabulary is used.

What is your opinion on this?

P.S. This case is not about dataset conformity specification but it is more feedback to https://github.com/inspire-eu-validation/community/issues/472#issuecomment-745650173 in different context.

iuriemaxim commented 3 years ago

@alitka I completly agree that according to TG the publication date of the Specification should be present. But this does not mean that the users are not able to provide the date of revision of the the specification. Even if the test is just checking the fact that date of the publication is present, this does not mean that the text that is provided to the users should tell them that they should provide the publication date only as this is misleading. Users can provide the date of revision and even they should be encouraged to do it.

If I am reffering to the fact that my dataset comply with Regulation 1089/2010 mentioning as publication date 2010-12-08, would it be correct if the dataset contains features that correspond to Annex III Data Theme, as the version of the regulation from 2010 is just providing rules for Annex I data themes?

I am understanding the rule as it is, but we should aknowledge that the information provided in the metadata should be also correct and logic, not just valid according to some rules that can be updated and which do not mention what the user is not alowed to provide.

PS: Looking at all the other temporal references in the Metadata TG, the requirments are to provide the revision date, not the publication date, so at least the text provided in the validator in case of an error should not indicate to the users that they cant provide the revision date of the specification even if the test is just looking at the date of publication.

iuriemaxim commented 3 years ago

In relation to the error provided in the validator, most probably it is not just enough to change the lines 485 to 487 from the code, because I think that they are related to other tests as well. Thats why @DeordD mentioned the vocabullary and there are other elements where date of creation, publication and revision can/should be provided. I did not looked into the code now, but just to mention that is not a good approach to change those lines of code unless clarifying that only this test is triggering this error based on the text from lines 485 to 487.

carlospzurita commented 3 years ago

Dear all,

We are marking this issue as "For discussion" for now, until we reach an agreement on how to handle this issue, and in the meantime we can collect more feedback.

carlospzurita commented 3 years ago

Dear @alitka

After discussing this issue, we have decided to change the error message to The metadata record contains a reference to a specification, but the codeListValue or date type is not corret. The codeListValue or date type should be 'publication'.. This way it reflects that the only value that is mandatory is publication.

Otherwise, the test is correctly failing for this specific metadata. Please check out the message available on the staging instance and let us know if everything is in order.

PeterParslow commented 3 years ago

This appears to be related: I am surprised to get this error when using the staging instance to test this record: https://osmetadata.astuntechnology.com/geonetwork/srv/api/records/G61ab9bc4-77b8-447c-8432-cdcd057d4cb7/formatters/xml?approved=true

Because the codeListValue is set to 'publication'

Is it because I have a second conformity statement, to my own specification, and for that one, I give the revision date?

alitka commented 3 years ago

Dear @carlospzurita , now the error message is correct and transparent for an accidental or inexperienced user, but the mentioned point from @PeterParslow is still relevant. For an additional country- or topic-specific specification entry the dateType 'creation' or 'revision' should be also permitted.

According to the above point, the test should be adjusted.

fabiovin commented 3 years ago

Dear @alitka, we decided to relax this test, see my comment here.

We will consider that Requirements C.20, C.21 and C.22 apply only to "INSPIRE specifications" and that all types of dates can be used.

carlospzurita commented 3 years ago

As no additional comments have been added on the discussion, and given that #479 has been solved, we are solving this as well