Consultation #2708

Feedback on draft Metadata TG v2.0 - structure & conformance classes 1 and 3 (metadata for discovery)

Added by Michael Lutz over 4 years ago. Updated over 4 years ago.

Status:ClosedStart date:29 Feb 2016
Priority:NormalDue date:14 Mar 2016
Assignee:Michael Lutz
Category:-

Description

Please find attached a draft (release candidate 1) for the Metadata TG version 2.0.

This draft includes the complete structure of the proposed version 2.0 of the TG document. In addition, chapters 2, 3 and 5 (covering conformance classes 1 and 3 for metadata for discovery) are ready for MIWP-8 review.

The text on yellow background contains drafting notes not intended to be left in the final version, but potentially useful for reviewers.

Please provide feedback on

  • the structure of the TG document and approach for wording TG requirements (based on requirements in the IR) by 7 March
  • conformance classes 1 and 3 by 14 March noon

using the attached commenting table (or directly as comments to this issue).

TG_for_INSPIRE_MD_2.0rc1_comments_XX.docx (22.3 KB) Michael Lutz, 29 Feb 2016 04:47 pm

TG_MD_20_draft_2016-02-29_for_MIWP-8_review.pdf (1.35 MB) Michael Lutz, 29 Feb 2016 04:47 pm

TG_for_INSPIRE_MD_2.0rc1_comments_CZ.DOCX (29.2 KB) Lenka Rejentova, 07 Mar 2016 02:41 pm

TG_for_INSPIRE_MD_2.0rc1_comments_MLS.docx (34.8 KB) Marie Lambois, 07 Mar 2016 03:19 pm

TG_for_INSPIRE_MD_2.0rc1_Comments_IGN_Geoslab.docx (26.8 KB) Javier Nogueras Iso, 08 Mar 2016 11:22 am

2016-03-08_TG_for_INSPIRE_MD_2.0rc1_comments_DE.docx (32.4 KB) Peter Kochmann, 08 Mar 2016 04:26 pm

TG_for_INSPIRE_MD_2.0rc1_comments_IdV.docx (42.5 KB) Ine de Visser, 10 Mar 2016 06:09 pm

TG_MD_20rc2_draft_without_annexes_2016-03-13.pdf (1.03 MB) Ilkka Rinne, 13 Mar 2016 07:27 pm

TG_for_INSPIRE_MD_2.0rc1_comments_IT.docx (28.7 KB) Antonio Rotundo, 14 Mar 2016 02:03 am

TG_for_INSPIRE_MD_2.0rc1_comments_AT.docx (26.9 KB) Christine Brendle, 14 Mar 2016 11:22 am

TG_for_INSPIRE_MD_2.0rc2_Without_annexes_comments_GN.docx (22.9 KB) Geraldine Nolf, 14 Mar 2016 03:27 pm

TG_for_INSPIRE_MD_2 0rc1_comments_UK.docx - Comments by James Reid (26.6 KB) Alex Ramage, 14 Mar 2016 03:31 pm

TG_for_INSPIRE_MD_2.0rc1_comments_JRC.docx (31.2 KB) Michael Lutz, 14 Mar 2016 08:20 pm

TG_for_INSPIRE_MD_2.0rc1_comments_PS.docx (30.9 KB) Pawel Soczewski, 15 Mar 2016 08:00 am

combined-comments_for_rc1.xlsx (45.4 KB) Ilkka Rinne, 15 Mar 2016 11:54 am

combined-comments_for_rc1_2016-03-23.xlsx (44.9 KB) Ilkka Rinne, 23 Mar 2016 09:45 am

History

#1 Updated by Michael Lutz over 4 years ago

  • Subject changed from Feedback on draft Metadata TG v2,0 - structure & conformance classes 1 and 3 (metadata for discovery) to Feedback on draft Metadata TG v2.0 - structure & conformance classes 1 and 3 (metadata for discovery)

Dear MIWP-8 experts and MIG-T representatives,

as announced last week, please provide feedback on

  • the structure of the TG document and approach for wording TG requirements (based on requirements in the IR) by 7 March
  • conformance classes 1 and 3 by 14 March noon

using the attached commenting table (or directly as comments to this issue).

Please also provide us a short comment in case you agree with the proposed structure and TG requirements approach - so that we know we are heading in the right direction.

#2 Updated by Alex Ramage over 4 years ago

One very quick comment on Page 7 the document should read Changes from Version 1.3 to 2.0 and not Changes from Version 3.1 to 2.0

 

Alex Ramage

#3 Updated by Ilkka Rinne over 4 years ago

Thanks Alex!

Alex Ramage wrote:

One very quick comment on Page 7 the document should read Changes from Version 1.3 to 2.0 and not Changes from Version 3.1 to 2.0   Alex Ramage

 

#4 Updated by Ilkka Rinne over 4 years ago

Hi all,

Just a reminder for providing the comments & feedback for the new TG MD document structure by next Monday 7th March.

Note that the proposed version 2.0 of document is completely restructured to reflect the ISO 19139 MD_Metadata element structure, and there are now separate Conformace Classes for datasets & services as well as for the additional interoperability requirements (SDS levels & MD for interoperability). If you have any ideas or suggestions about this on this now is a good time to discuss them.

As Michael wrote earlier, the deadline for detailed comments about the contents of the chapters 2, 3 and 5 is one week later on Monday 14th March at noon.

 

 

 

#5 Updated by Peter Kochmann over 4 years ago

It takes some time to get used to this new structure but I think it will work!

Having this chapter 2 with general requirements and recommendations suitable for all kind of metadata is a promising way to avoid too much things to be repeated at several points in the document.

The new wording of the requirements looks good to me and I approve the way to focus on the wording in IR (as we discussed in a smaller group before). That will ease to find the context und support the understanding.

I was a bit surprised to see the mapping changed to ISO 19139. But it makes sense to focus on that regardless the way how to come to this structure in XML. The detailled mapping in Annex B shows the particular elements of ISO 19115/19119 and the numbering of INSPIRE as well.

To have the numbering of INSPIRE still in it is important because we decided not to focus on an ISO numbering!

What I miss is a hint in chapters 2 and 3 to the detailled information in Annex B concerning the particular element. I guess that many readers will look for that information. A precise hint to the particular number in Annex B would be helpful.

#6 Updated by Ine de Visser over 4 years ago

I think its a clear structure!

Avoiding duplicates and also avoiding specific text for the  different resources by a metadata element.

The TG requirements more visible based on the IR requirements gives also more structure.

One point of concern, I got the impression that the domains/codelists  sometimes are mentioned in the TG requirement and somtimes with a footnote.

I share the point of Peter that i also missed the info that in annex B is more detailed information.

 

 

#7 Updated by Antonio Rotundo over 4 years ago

I think too that in general the new structure is clear and that it can work.

My only proposals are the following:

  1. I agree with Peter that a hint to the detailed info included in Annex B could be helpful. In the chapter 2, I’d even add an introduction section with a summary of the metadata elements required by INSPIRE Regulations for data sets and services (i.e. separate lists (or tables) of the metadata elements for data sets and services). I don’t know if Peter even meant that, but in any case I think that those lists/tables could be helpful as well.
  2. The structure of the chapters 3 and 4 seems be the same. If so, as the subject and the properties concerning the CC1 and the CC2 could be for most part overlapping and redundant, then the chapter 4 could become a paragraph of the chapter 3. Then, the chapter 3 will include two paragraphs: 3.1 concerning CC1 (baseline metadata) and 3.2 concerning CC2 (interoperability metadata). The title of the chapter 3 could be renamed with "INSPIRE data sets and data set series metadata conformance classes".
  3. For the same reason, the chapters 6, 7 and 8 could become the paragraphs of the chapter 5 (that will become the chapter 4 if the proposal referred to in the point 2) will be accepted). Then, the chapter 5 (the future chapter 4) will include 4 paragraphs: 5.1 concerning CC3 (SDS baseline metadata), 5.2 concerning CC4 (Invocable SDS metadata), 5.3 concerning CC5 (Interoperable SDS metadata) and 5.4 concerning CC6 (Harmonised SDS metadata). The title of the chapter 5 could be renamed with "INSPIRE Spatial Data Service metadata conformance classes".
  4. Alternatively to the previous proposals referred to points 2) and 3), the chapters 3, 4, 5, 6, 7 and 8 could be unified into a single chapter with a paragraph for every conformance class for dataset (baseline and interoperabily metadata) and services (baseline, invocable, interoperable, harmonised). Summing up, the chapter 3 could be renamed with "INSPIRE metadata conformance classes"; it will include the following paragraphs: 3.1 concerning CC1, 3.2 concerning CC2, 3.3 concerning CC3, 3.4 concerning CC4, 3.5 concerning CC5, 3.6 concerning CC6.

#8 Updated by Lenka Rejentova over 4 years ago

I think the structure of the document is good and clear with soma comments mentioned above.

I also attach a few technical comments to the capture 2 and 3.

#9 Updated by Marie Lambois over 4 years ago

Generally speaking the structure seems clear. I would agree with Peter suggestion to group the CC by their subject (dataset/services).

I have not checked annex B in details but there will be a necessary step to check that both stay coherent.

Some comments (review of chapter 2,3 and 5) are in the file attached.

 

#10 Updated by Peter Kochmann over 4 years ago

I'm already working on feedback on Annex B! It will be uploaded together with feedback on CC1 and CC3 the next days.

#11 Updated by Pawel Soczewski over 4 years ago

I think that new strukture is good and clear.

I'd add only examples of XML encoding in sections 2 - 8 for all metadata elements. It'll more clear for user than looking for a specific element in the full metadata record. Alternatively, examples may be added in Annex B.

In chapter 2.3.2 it would be good to add an explanation of how to use responspiblePartyRole.

In Annex B, part B.4 Coordinate Reference System - using of this element should be the same like part B.2 Coordinate Reference System. 

I'm also working on detailed comments to annex B.

 

 

 

#12 Updated by Ilkka Rinne over 4 years ago

Thanks for all the comments provided. I will create a synthesis of them today and post it in this issue

#13 Updated by Javier Nogueras Iso over 4 years ago

Please find attached some joint editorial and general comments on the technical guidelines documents from IGN Spain, Geoslab and University of Zaragoza at the document TG_for_INSPIRE_MD_2.0rc1_comments_IGN_Geoslab.docx. Overall we are worried in Spain about not taking into account ISO 19115-1 and ISO 19115-3 in this new version of the technical guidelines. I know that during the meeting in Rome (December 2015) this was discussed and the new versions of the standard were considered as an investigation problem. Still, we don't know if this will be a problem for the successful adoption of the new technical guidelines documents.

#15 Updated by Ine de Visser over 4 years ago

In the attachment my comments on chapter 2, 3 and 5

#16 Updated by Ilkka Rinne over 4 years ago

Good evening all,

Sorry for not being able to provide your with the promised comments synthesis yet. My overall impression is that the proposed structure was acceptable by the group, and I have now made some changes to it based on the comments. The biggest change is grouping the data set and service specific requirements together.

While adding more content to the list of terms, I checked the terms Conformance Class and Requirements Class from the OGC document dealing with specification structure (OGC 08-131r3): According to it the Conformance (test) Class is a collection of Conformance Tests, not Requirements, so I have now renamed the Conformance Classes to Requirements Classes throughout the document.

In the attached version of the document I have now also made all the straightforward fixes and corrections you provided in the comment tables. Your comments were detailed and very good, thanks a lot. After the deadline of Monday 14th March I will combine all the provided comments to one document and highlight the ones requiring further discussion and/or decisions from the MIWP-8 group, so that we can more easily go them through in Wednesday's comment resolving meeting.

Note that the attached version does not include any Annexes. I have not yet made any changes to them since the RC1 version, and I temporarily split them in separate documents, as managing the combined docuement started to be too much for the word processing software I have been using. Not to worry, I will merge the entire docuemnt back again before the final version.

#17 Updated by Antonio Rotundo over 4 years ago

Please find attached my comments. I previously checked what provided by the other WG members in order to avoid redundant comments.

#18 Updated by Christine Brendle over 4 years ago

Please find attached our comments. Already mentioned remarks by colleagues are marked in grey.

#19 Updated by Geraldine Nolf over 4 years ago

Hello,

I couldn't follow the working group anymore by a lack of time since the INSPIRE-conference 2015. Now I have read the new document.

- I am happy to tell the structure is more then ok. It is easy to follow this TG, linked with the IR and with ISO. Eventhough most remarks my colleagues mentioned are justified, so these should be solved. Good work everybody!

- Sometimes I am missing the reason why some elements are changed in implementation. Some extra explanation, because I was not able to follow the discussions in the MIG anymore, and then it is not always clear why the change is needed; or how it is changed. So I really think for some elements that are changed in the TG we really have to give more explanation, more examples, more reason why. Certainly when these changes in TG cause big changes in implementing data, metadata, services, ... Fe. The coupled resource. With more explanation and examples, the text will be self-explaning (logically follow). It will reduce the number of questions that will remain without explanation or examples by people who aren't members of this working group.

I hope I can participate the telco on Wednesday.

Geraldine

 

 

#20 Updated by Geraldine Nolf over 4 years ago

Geraldine Nolf schreef:

Hello, I couldn't follow the working group anymore by a lack of time since the INSPIRE-conference 2015. Now I have read the new document. - I am happy to tell the structure is more then ok. It is easy to follow this TG, linked with the IR and with ISO. Eventhough most remarks my colleagues mentioned are justified, so these should be solved. Good work everybody! - Sometimes I am missing the reason why some elements are changed in implementation. Some extra explanation, because I was not able to follow the discussions in the MIG anymore, and then it is not always clear why the change is needed; or how it is changed. So I really think for some elements that are changed in the TG we really have to give more explanation, more examples, more reason why. Certainly when these changes in TG cause big changes in implementing data, metadata, services, ... Fe. The coupled resource. With more explanation and examples, the text will be self-explaning (logically follow). It will reduce the number of questions that will remain without explanation or examples by people who aren't members of this working group. I hope I can participate the telco on Wednesday. Geraldine    

 

#21 Updated by Alex Ramage over 4 years ago

Please see the comments made on the TG for metadat.

I have found the structure easier to navigate.

Alex Ramage

 

PS Other comments may be forthcoming.

AR

#22 Updated by Christina Wasström over 4 years ago

Here is an input from my colleague who is our metadata expert:

"I agree with previous comments from (2708#change-7784)

The general structure of the report is good and comprehensible.

Although, I think there could be some more elaboration on the text explaining the context of various elements. Just to give less experienced readers a little bit more understanding of what the element actually contains.

Example:

2.11.3 Metadata Language

From TG_MD_IR it states:  “This is the language in which the metadata elements are expressed”

This description is not really exhausting the topic

An elaborated description on the full context on the matter should also include the language of text from “code lists” and “keywords” – not only “free text” fields.

This applies to many elements in the document. However, there is a balance to be found between IR and a “User Guide” –  I’ll leave that to others to decide."

#23 Updated by Michael Lutz over 4 years ago

Please find comments by Angelo Quaglia (JRC) attached.

#24 Updated by Pawel Soczewski over 4 years ago

Please find attached my comments, generaly to annex B.

#25 Updated by Ilkka Rinne over 4 years ago

Please find the combined comments for the RC1 version sent as comments to this issue, attached in an Excel spreadsheet. The total number of comments was 245. The comments have been sorted by the chapter/section to group comments regarding the same sections together.

I have already fixed some of them in the version currently under editing, these are indicated by green backgroud color. I have also added comments to some of the comments, these can be found in the column "Editor comments".

I think we have to find an efficient way to pick the ones needing most discussion/decision making in Wednesday's meeting, and find another way to resolve the rest, as there are quite many issues reported here, and we only have two hours meeting time.

 

#26 Updated by Antonio Rotundo over 4 years ago

Two additional comments that I directly provide here below, even if after the deadline.

  1. It is not clear why only 3 code lists are included in Annex C. If the criterion was to include only the extensions with respect to ISO 19115, then other code lists are missing (e.g. CRS lists (as remarked by Peter) or the resource locator functions code list). If the criterion was to include only those code lists that don't exist in the INSPIRE registry, then the code list "Spatial Data Service type" should be removed. If it's planned to include the code lists "LimitationsOnPublicAccess" and "ConditionsApplyingToAccessAndUse" in the INSPIRE registry, then Annex C could be removed keeping the reference to those code lists in the main text of the TG as well; alternatively, all the code lists referenced in the TG should be included (if so, see the issue https://ies-svn.jrc.ec.europa.eu/issues/2563).
  2. Altough the reference ISO Standards are 19115:2003 and TS 19139:2007, I think that a hint (in chapter 1?) to the new version of ISO Standards 19115-1 and 19115-3 and to the reasons on using the old Standards in the revised TG could be useful. About that, a comparison between INSPIRE metadata elements for discovery, the core requirements of ISO 19115:2003 and the metadata elements defined in ISO 19115-1:2014 was included in the GeoDCAT-AP specification (https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/geodcat-ap-v10).

#27 Updated by Ine de Visser over 4 years ago

@Ilkka,

You mentioned a meeting, wednesday on the comments. I am not aware of a meeting. is this a meeting for the working group? Where can I find the meeting date and time?

#28 Updated by Ilkka Rinne over 4 years ago

Ine de Visser wrote:

@Ilkka, You mentioned a meeting, wednesday on the comments. I am not aware of a meeting. is this a meeting for the working group? Where can I find the meeting date and time?

Whoops, it seems that invitation email from Michael Lutz sent on 26 Feb never reached you! I'll add a copy below:

From: Michael Lutz
Date: Fri, Feb 26, 2016 at 11:15 AM

Dear all,

the comment resolution telecon for the updated TG document will take place on 16 March 15:00-17:00 CET.

This means that we can only accept comments until 14 March noon - so that we can go through them and identify the ones that we need to discuss during the meeting.

Best regards,
Michael
 

#29 Updated by Ilkka Rinne over 4 years ago

Antonio Rotundo wrote:

Two additional comments that I directly provide here below, even if after the deadline. It is not clear why only 3 code lists are included in Annex C. If the criterion was to include only the extensions with respect to ISO 19115, then other code lists are missing (e.g. CRS lists (as remarked by Peter) or the resource locator functions code list). If the criterion was to include only those code lists that don't exist in the INSPIRE registry, then the code list "Spatial Data Service type" should be removed. If it's planned to include the code lists "LimitationsOnPublicAccess" and "ConditionsApplyingToAccessAndUse" in the INSPIRE registry, then Annex C could be removed keeping the reference to those code lists in the main text of the TG as well; alternatively, all the code lists referenced in the TG should be included (if so, see the issue https://ies-svn.jrc.ec.europa.eu/issues/2563). Altough the reference ISO Standards are 19115:2003 and TS 19139:2007, I think that a hint (in chapter 1?) to the new version of ISO Standards 19115-1 and 19115-3 and to the reasons on using the old Standards in the revised TG could be useful. About that, a comparison between INSPIRE metadata elements for discovery, the core requirements of ISO 19115:2003 and the metadata elements defined in ISO 19115-1:2014 was included in the GeoDCAT-AP specification (https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/geodcat-ap-v10).
 

The code lists in Annex C are given there because they are not (yet) available in the INSPIRE code list registry or in any other well-known, referenceable registry (that I know of). I would strongly recommend adding them to the INSPIRE codelist registry and remove the entire Annex, but for that I would need at east the URLs to point to.

#30 Updated by Peter Kochmann over 4 years ago

Lines 175 up to 188 concerning coupledResource (5.2.4,  4.1.2.4 in edited draft rc2) show that the discussion is still going on. We came clear in MIWP-8 group that there won't be the one and only solution. The latest draft of former structure (v_055, 2015-11-08) wasn't the end of this discussion! Martin Seiler again stressed the importance to allow the Unique Resource Identifier from 3.2.1 (in rc2 3.1.2.1 now) itself within operatesOn using xlink:href. We don't know by now why that proposal "vanished" though being sent in time.

We were very pleased to see the Finnish example using the same way! The green coloured side note was a good explanation of this conflict showing what has to happen in behind (resolving, i.e. redirecting the URI to a URL pointing to the metadata) in addition to recommendations 3.3 and 3.4.

The requirement 3.6 (old = new) is suitable for both ways and covers a URI and a GetRecordsById-Command as well! So there's no need to have any more restrictions like the one hidden in new recommendation 3.5 focussing on uuidref: We still propose to consider the URI for xlink:href as well. That would make the note #37 obsolete! 

In addition let's have an appropriate and equitable example for that like the old 3.3 containing the Finnish identifier!

 

Lastly a personal remark: I would be very happy to come to an end of this. It's very nerving to be bound to pedantically control every new draft concerning this issue and look for hidden (not to say secret) progress in one or the other direction! We all have to accept that there are different point of views that can't be proved to be wrong by the other party. So a consensus might be impossible, but a solution allowing both ways of implementation and both fulfilling the requirements given by INSPIRE must be accepted by all of us!

#31 Updated by Angelo Quaglia over 4 years ago

The URL used in the xlink:href attribute of each operatesOn element can be whatever one deems appropriate but:

  • the URL must return an xml document containing, at any level of nesting, at least one valid MD_DataIdentification element where the id attribute is set;
  • the URL must end with a fragment identifier whose value corresponds to the value of the id attribute mentioned in the previous point. Otherwise, the document returned must be a MD_DataIdentification element alone;

The fragment identfier allows clients to unambiguously identify, inside the file that is retrieved, be it a GetRecordByIdResponse, GetRecordsResponse, the plain gmd:MD_Metadata or any other xml document, the MD_DataIdentification element describing the coupled dataset.

Inside the identified MD_DataIdentification element, clients will find, at the position indicated in this Technical Guidance, all the Unique Resource Identifiers that identify the dataset, hence fully honouring the MD Regulation.

 

 

 

#32 Updated by Ilkka Rinne over 4 years ago

Please find an updated version of the comment resolution spreadsheet attached.

#33 Updated by Marc Leobet over 4 years ago

Dear colleagues,

 

Unfortunately I have few times now to read all your production. I just would like to support Peter's reaction. We fear here that the work could be even more complicated with the new TG instead to be simpler, as we need.

This is not only a personnal comment : there will be few future for a TG not adopted by consensus, and we would reach a consensus only by accpeting different way. I thought it was clear since the Maälmo meeting, in September.

Best regards

#34 Updated by Angelo Quaglia over 4 years ago

Dear Marc,

Indeed, standard specifications are the results of consensus.

Once a standard specification is adopted it has to be respected in full, thereby honouring the consensus.

Can you suggest an alternative implementation that is respectful of the adopted standards?

 

 

#35 Updated by Marc Leobet over 4 years ago

I believed we reached the balance between different implementations in Mälmo. Since months, I understand that this balance was dropped. I didn't understand why.

The European users were not in these standards committees (ISO...), that is the great difference with EU governance. If standards don't bring consensus in the European Union, may be it is because they are not adapted. We have no obligation to respect an ISO standard, even if we have together to continue to try to be at the same time respectful of Regulations, ISO 19115 AND  user's needs. That is why we are looking to other standards to offer a solution to non-specialists.

When we will have to go back to our stake-holders, we could defend the interest to adapt their implementation to reach an higher level of interoperability, but we will not be bind by non-consensual guidelines. Everyone knows that, the Peter's reaction gave just the opportunity to stress it again (thanks to him!).

 

 

 

 

 

 

#36 Updated by Michael Lutz over 4 years ago

  • Status changed from Work in progress to Closed

#37 Updated by Angelo Quaglia over 4 years ago

For the records, it must be mentioned that linking by reference of coupled resources is the approach that was chosen by the Metadata Drafting Team.

The representative for France was Nicolas Lesage who at the time was an ISO 19115 expert and ISO active member .

 

The following document summarises the consensus based process followed in developing the proposed INSPIRE implementing rules for metadata:

http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/metadata/IR_Metadata%20_process.pdf

 

The first version of the Metadata Technical Guidance document is available here:

http://inspire.ec.europa.eu/index.cfm/pageid/101/list/1

Also available in: Atom PDF