Hi,

We noticed that the Priority datasets are visible in the INSPIRE Geoportal only if the

<gco:Date> is set to 2018-04-04

<gmd:CI_DateTypeCode>​ is set to publication

as can be seen bellow:

However the INSPIRE priority data set codelist (http://inspire.ec.europa.eu/metadata-codelist/PriorityDataset/PriorityDataset.ro.atom)

<updated>2018-03-26T10:54:57.968+02:00</updated>

Dear Iurie,

there has indeed be some confusion about the correct date and date type to be used.

The correct date and date type is the one specified in the Implementation Guidance for Priority Datasets at https://ies-svn.jrc.ec.europa.eu/projects/2016-5/wiki/Implementation:

3. Add the citation information for the used controlled vocabluary. For the citation, the following information shall be used:

• URI of the Code list: http://inspire.ec.europa.eu/metadata-codelist/PriorityDataset (only for encoding 1)
• Date type: publication
• Date: 2018-04-04
• Title of the vocabulary: INSPIRE priority data set

We require the use of "publication" as the date type to refer to the date when the new major version (v2.0) was officially published. There may be some minor updates or bug fixes in the coming weeks, but we will not change the date of publication for each of these minor updates.

The date included in the Atom format of the registry is a "system time" for the date of the last update in the registry. This date will change when data in the registry changes, so it is a "date of last update/revision". We are aware that this may be confusing, so we are discussing the possibility to add an explicit date of publication in a future release of the registry software.

Hope this clarifies the issue.

Best regards,
Michael

Hi Michael,

Many thanks for the information provided. We noticed what we need to add in the metadata to pass the validation, even if some clarifications were needed as can be seen here https://ies-svn.jrc.ec.europa.eu/issues/3220

It is good that you are discussing the possibility to add an explicit date of publication in a future release of the registry software and please take into consideration that for data providers is important to have a mechanism to know when something was changed in the Registry in order to allow a certain period of time to change the datasets, services or the metadata according to the new changes in the Registry.

Currently such mechanisms do not exist and a dataset that is valid at a certain date will not be valid the next day after the values in the registry were changed. The registry is not indicating an update date that can be supplied trough a feed and monitored by the data provider.

Therefore, if minor or major changes occur but the date is not changed and provided to indicate an revision, the data provider can’t be aware by the fact that the Registry was changed (i.e: some values were superseded or some values were added).

In this context it is almost impossible for a data provider to maintain a dataset and its corresponding network services and metadata valid over time. Similarly, as the EC/JRC is monitoring all services through the INSPIRE Geoportal, the data providers need to be able to monitor the changes that occurs in the Registry in order to be able to change the data sets, services or metadata.

Currently there is no such mechanism in place.

Even more, it should be taken into consideration that a certain period of transition should exist if changes in the Registry occurs. If a certain value is changed, then it should not become invalid the next day, because the next day the dataset/service/metadata will became invalid as well. Values in the Registry should have lifeCycleInfo and a certain value even if it is superseded by another one, then it should still be valid for a certain period of time to allow data providers the necessary time to revise the dataset/service/metadata..

As regards the dateType ”publication” instead of ”revision”, I do not think it is correct unless the version of the vocabulary is indicated somewhere in the metadata, that currently is not indicated.

Based on your info I understand that the version 1 of the ”INSPIRE priority data set” vocabulary had the following information:

• URI of the Code list: http://inspire.ec.europa.eu/metadata-codelist/PriorityDataset
• Date type: publication
• Date: 2017-11-16
• Title of the vocabulary: INSPIRE priority data set

While the version 2 of the ”Inspire priority data set” vocabulary has this information

• URI of the Code list: http://inspire.ec.europa.eu/metadata-codelist/PriorityDataset
• Date type: publication
• Date: 2018-04-04
• Title of the vocabulary: INSPIRE priority data set

Because nothing indicates in the metadata that first vocabulary is version 1 and second one is version 2, the information is not understandable nor by humans, nor by machines.

Both humans and machines understand that the INSPIRE priority data set vocabulary has two publications dates. If date type should remain ”publication” as sugested, than the version of the vocabulary should appear somewhere to diferenciate between resources  (i.e.: in the title ”INSPIRE priority dataset v.2.0”, but I do not think it is advisable).

In any case, for data providers is important to have a mechanism (i.e.: RSS feed) to know when a certain vocabulary is updated. If a major change of the vocabulary is considered to be a ”publication” of a new version of the vocabulary, while minor changes are considered ”revisions” of the same vocabulary version, then this information should be clear and the version of the vocabulary should be exposed and used (i.e.: version 2.12). However I think that the best is to use the date as being the version, but in this case the date type is ”revision”, and not ”publication”.

What do you think?

Can someone clarify in the context of a vocabulary what means date of creation, date of publication and date of last revision?

If looking at http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode%22

the terms are explained as following:

Creation - date identifies when the resource was brought into existence

Publication - date identifies when the resource was issued

Revision - date identifies when the resource was examined or re-examined and improved or amended

I understand that there is only one resource with the title INSPIRE priority data set and this resource was firstly created at a certain date, but it became available to public only it was published in the Registry at a certain publication date. Then this resource was updated at a certain revision date. The same resource can be revised as many times, but is still a revision of the same resource. In order to have another publication date, it should be another resource created and then published.

So in order to have two publication dates there should be two separate resources. Two separate resources can be obtained either if the titles of the thesaurs differs, like for example:

<gco:CharacterString>INSPIRE priority data set version 1</gco:CharacterString>

<gco:CharacterString>INSPIRE priority data set version 2</gco:CharacterString>

or if for the <gmd:CI_Citation> it is added an element to differentiate between the two resources by indicating the version, as for example the element  <gmd:edition>. See http://www.datypic.com/sc/niem21/e-gmd_CI_Citation.html

Best regards,

Iurie Maxim

http://essensys.ro

I don't know if my question(s) should be asked here or somewhere else on the forum...

In conclusion there is still lots of confusion about the tagging of the priority data set in the metadata.

(I know the keyword is different in both examples but my question is mainly about the format)

Is it enough to use the character string encoding: as mentioned above

<gmd:descriptiveKeywords>
       <gmd:MD_Keywords>
             <gmd:keyword>
                          <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/PriorityDataset/Agglomerations-dir-2002-49">Agglomeration (Noise Directive)</gmx:Anchor>
             </gmd:keyword>
     <gmd:thesaurusName>
            <gmd:CI_Citation>
                  <gmd:title>
                       <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/PriorityDataset">INSPIRE priority data set</gmx:Anchor>
                 </gmd:title>
                 <gmd:date>
                         <gmd:CI_Date>
                               <gmd:date>
                                     <gco:Date>2017-11-16</gco:Date>
                             </gmd:date>
                          <gmd:dateType>
                                     <gmd:CI_DateTypeCode                   codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode>
                        </gmd:dateType>
                   </gmd:CI_Date>
                </gmd:date>
            </gmd:CI_Citation>
        </gmd:thesaurusName>
     </gmd:MD_Keywords>
</gmd:descriptiveKeywords>

Dear Katia,

the ‘Implementation guidance and support” for priority data sets specify that " there are two supported options for the encoding of priority dataset keyword(s) and the used controlled vocabulary: 

• Option 1: Using the gmx:Anchor element
• Option 2: Using the gco:CharacterString element "

therefore you can choose either the first or the second one, since they both are valid.

Kindly note that:

• in the encoding examples provided in the guidance, the thesaurus date is set to “2018-04-04” both for Option 1 and Option 2;
• as reported by Iurie (see above): "Priority datasets are visible as such in the INSPIRE Geoportal only if the

<gco:Date> is set to '2018-04-04'

<gmd:CI_DateTypeCode>is set to 'publication'.

Regarding your second question i.e. why some data sets available in the Geoportal are not visible in the Thematic Viewer, I would like to point out that the Thematic Viewer shows only those data sets for which the INSPIRE Geoportal was able to find a Download Service.

Therefore first thing is to check (clicking on the relevant INSPIRE metadata link in the Geoportal) whether those metadata you are not able to find in the Thematic Viewer report any “DOWNLOAD_MATCHING_DATA_IS_AVAILABLE” missing aspect in the "INSPIRE Resources Linkage Aspects (Documentation)" section.

If so, that’s likely the reason why they are not visible.

Conversely, should the “DOWNLOAD_MATCHING_DATA_IS_AVAILABLE” be verified, yours is a question for the INSPIRE Geoportal Helpdesk or the Thematic Viewer team.

Should this latter be the case, and you find out something remarkable for the users of Thematic clusters, would you please feedback here?

Thank you

Stefania