Template for comments / Countries: AT, CH, CZ, DE, DK, ES, FR, IT, NL, SE, UK / Date: 2016-05-24 / Document: TG for Metadata v2.0rc2 / Project: MIWP-8
MS / Chapter/ Section
(e.g. 3.1) / Paragraph/Figure/Table/
(e.g. Table 1) / Type of comment1 / Comments / Proposed change / Resolution
NL / ed/ge / alignment of the requirement numbers and the chapters;
1.1 - 1.12 data, chapter 3.1
2.1 - 2.8 interoperability data, chapter 3.2
3.1 - 3.8 SDS chapter 4.1
4.1 and 4.2 network services chapter 4.2
5.1 - 5.5 invocable SDSchapter 4.3
6.1 - 6.5 interoperable SDS chapter 4.4
7.1 - 7.3 harmonised SDS chapter 4.5 / Proposed Change
3.1.1 – 3.1.12 data, chapter 3.1
3.2.1 – 3.2.8 interoperability data, chapter 3.2
4.1.1 – 4.1.8 SDS chapter 4.1
4.2.1 and 4.2.2 network services chapter 4.2
4.3.1 – 4.3.5 invocable SDS chapter 4.3
4.4.1 – 4.4.5 interoperable SDS chapter 4.4
4.5.1 – 4.5.3 harmonised SDS chapter 4.5 / Not accepted.
The numbers refer to the conformance classes. If the document is renumbered, the requirement numbers would need to change.
In addition to the numbering, the document now also uses mnemonic ids (that can be used to create URIs in the namespace) to identify requirements.
SE / ge / The reference from the sections to the tables in the Annex C is unclear / Add reference from the sections to the tables in the Annex C / Not accepted.
Annex C is simply a summary of the mapping. The main text of the document is meant to be self-explanatory (without references to the mapping).
CZ / ge / The description of operation how the gradual transition to the new TG version is missing. / We recommend to describe the process during the 3 year transitional period. E.g. whether the JRC validator will validate according to both versions of TG (1.3 and 2.0). / Accepted.
The section “Reading guidance and transition period” has been updated accordingly. The start date of the 3-year transitional period still needs to be set.
CZ / ge / Add information about JRC validator. / Add information whether the JRC validator is binding, when the validation according to the TGv2.0 will operate. / Accepted.
The section “Reading guidance and transition period” has been updated accordingly. The start date of the 3-year transitional period still needs to be set.
CZ / ge / Use of Anchor element is not symmetric thru the whole document / We recommend to use Anchor element (URI) in all examples and places where INSPIRE registry or other URI could be used (keywords) / Not accepted.
The use of gmx:Anchor is already promoted in more places than in the current TGs. No specific element is proposed in the comment.
CZ / ge / The invoke services could contain large amount of various services/metadata records. It would be helpful if there will be some metadata element for sorting these records. / We would recommend to integrate the sorting of metadata according to their coverage (EU/national/local). / Not accepted.
The comment and proposed change unclear. The proposed change seems to refer to a functionality of the discovery service, not a requirement for metadata.
ES / ge / At the end of April, “ISO/DTS 19115-3 Geographic information - Metadata - Part 3: XML schema implementation for fundamental concepts “ has been sent to ISO for its publication.
According with the calendar the next month of June the document could be published. Then this guidelines must be review and adapted to this documents / Not accepted.
The consideration of the new version of ISO 19115 has been out of scope for this update of the TG. The new standard is not binding, and it will probably not be widely implemented within the next few years.
FR / ge / There are quite a lot of changes in this version but reasons for these changes are not documented. / Please document reason for changes and their added value. / Accepted in principle.
The rationale for the changes made is already specified in the ToR of the MIWP-8 sub-group. A reference to the ToR and a short summary of the issues addressed in this version is given in the section “Foreward to this version”.
DK-1 / All / ge / There is a little too many places in the document marked with yellow, indicating questions to be answered, items to be handled or text to be inserted. E.g. Revision history, chapter 1.2.1, 1.2.2, 1.5, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 4.1.2.1 and 4.3.2.
Beside there are several chapters which are empty i.e. no text only headline. E.g. 4.3.1, 4.3.3, 4.3.4, 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.5.1, 4.5.2, 4.5.3 and 4.5.4.
With these remarks in mind we do not think that the document is ready for MIG-P for endorsement. / Insert the missing text, answer the questions and in general solve the issues marked in yellow. / Accepted with modifications.
All yellow text has been removed. Since this is technical document, we don’t see a need to have an introductory sentence for each section.
DK-2 / All / ge / A way to make the document easier to read and understand we suggest including UML-models in the document do demonstrate the relationship among the various elements and classes. The UML-diagram could be included in an annex. / Include UML diagram in the document, according to the comment. / Not accepted.
Adding numerous UML diagrams from ISO 19115:2003 would be quite a big change to the document very late in the process, and this has never been discussed with the MIWP-8 sub-group.
Also, strictly speaking, the reference standard for these TGs is now ISO 19139, not ISO 19115, so the diagrams might actually be confusing to readers rather than helpful.
DK-3 / All / ge / At several places in the document there are references to important tables from other documents. It would make the understanding of the text easier for the reader if these tables where available somewhere in the document (e.g. in an annex). / Include the referenced tables in an annex. / Accepted.
Overview tables of the INSPIRE metadata elements are already included in Annex C: INSPIRE metadata element catalog (informative).
DK-4 / All / ge / Why use different type of writing when it comes to requirement. In some chapters a capital letter is used and then a number whereas in other cases the capital letter is substituted with a number. E.g. TG Requirement A.8 (chapter 2.3.3) and TG Requirement 3.7 (chapter 4.1.3.1). The same goes for recommendation. / Harmonise the use of letters and numbers in the requirements and recommendations. As an alternative write the reasons for the different way of writing in chapter “Technical Guideline Requirements and Recommendations notation”. / Not accepted.
In general, requirements are prefixed with the numbers of the conformance classes they belong to. Common requirements are not part of a specific conformance class. That’s why they are pre-fixed with C. This is now explained in the chapter “Technical Guideline Requirements and Recommendations notation”.
In addition to the numbering, the document now also uses mnemonic ids (that can be used to create URIs in the namespace) to identify requirements.
DE / (all) / TG Requirements / ge / The INSPIRE multiplicity shall be described consistently in all Requirements as listed in Annex C: INSPIRE metadata element catalog. / INSPIRE multiplicity shall be added in Requirement where missing. / Accepted.
Still TBD.
DE / Acknowledgements / list of members of MIWP-8 / ge / list is incomplete / add: James Reid (UK), Ine de Visser (NL), Marc Leobet (FR), Marie Lambois (FR), Eliane Roos (FR), Peter Kochmann (DE) / Accepted.
DE / Acknowledgements / Contact information / ge / contact person Massimo Craglia seems to be outdated / Check and change accordingly. / Accepted.
ES / Foreword to this versions / 4th paragraph / ed / Error in the citation of ISO 19115: “ISO 19115/19115” / Change ““ISO 19115/19115” by ““ISO 19115” / Accepted in principle.
Changed to “ISO 19115/19119”.
DE / Reading guidance and transition period / list of annexes / ed / Annexes A and D are not mentioned / add bullet points for Annexes A and D / Not accepted.
Here only the annexes are listed that should help the readers in locating the specific elements and technical requirements in this version of the document.
DE / Reading guidance and transition period / last paragraph / ge / "...a transitional period of 3 years has been defined..." / please add information bywhomthis period was defined / Accepted in principle.
This should ultimately up to MIG-P to decide.
DE / Revision history / 20th bullet point / ge / "A new TG Recommendation 3.4 considering using id attributes of the referred MD_DataIdentification elements and URI fragment identifiers for referring to them in the Coupled resource elements has been added." / please clarify that this applies for one of the two alternatives for data service coupling only / Accepted in principle.
Since the recommendation 3.4 has been removed during the update of section 4.1.2.4Linking to provided data sets using coupled resource, this bullet point is also removed.
DE / Revision history / 42th bullet point / ge / "Referring to the new INSPIRE code lists for the reason of the Limitations on public access as well as Conditions applying to access and use ("no conditions" or "unknown") is now mandatory using the gmx:Anchor element." / while we support the use of gmx:Anchor elements we'd like to point out that currently this can't be validated with schemas given in section 1.2 / The issues was discussed at the MIWP-8 comment resolution workshop.
The JRC has raised the issue with the OGC. If the OGC is unable or unwilling to host a version of the AP-ISO xml schema that fixes the known problems with the OGC/ISO xml schemas, the JRC can host these.
SE / Revision history page 10 / ge / The section 1.2 INSPIRE specific constraints m is removed. This makes it difficult to see what is an ISO requirement and INSPIRE IR Metadata requirement / Consider making a complete description of the differences between ISO and INSPIRE requirements and not only for ISO core elements in Annex B / Not accepted.
This is beyond the scope of this document.
ES / Normative references / ge / Check the date of the standards. E. g. 19115:2005 (¿?), 19108:2005 (¿?), etc. / Change “ISO 19115:2005” by “ISO 19115:2003”. Review the other standars / Accepted in principle.
For ISO standards that have also been adopted as EN by CEN, the relevant CEN reference and adoption date are given, with the ISO number and adoption date in parentheses.
ES / Normative references / ge / Missing document citation “ISO 15836 (Dublin Core)” See “1.1. Introduction” 3rd paragraph. / Review and include “ISO 15836 (Dublin Core)” / Accepted.
DE / Other references / ge / INSPIRE data specifications are not listed though a lot of information is taken from there (e.g. theme-specific metadata) / add TG DS ... / Accepted.
DE / Other references / ge / "[TG SDS] Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked, version 3.1" / deprecated version 3.1 should no longer be referenced here, please reference version 3.2 instead / Accepted. The final version will be 4.0.
DK-6 / Terms and abbreviations / ge / If one is looking for a specific term it would ease the finding of the given term if the terms where sorted alphabetically. / Sort the term in alphabetic order. / Accepted.
UK-4 / Terms and abbreviations / Para 4 and 7 / ge/te / It would assist readers if the terms “Requirement class” and “Conformance (test) class” were better defined as they are currently confusing / Better define terms / Accepted in principle.
The definitions have been harmonised with the terminology used in MIWP-5 / ARE3NA activity on the INSPIRE test infrastructure.
DK-8 / Terms and abbreviations / Para 4 and 5 / te / The terms “Requirement class” and “Conformity subject” are defined circular. I.e. in the definition of “Requirement class” the term “Conformity subject” are used and at the same time in the definition of “Conformity subject” the term “Requirement class” is used. This situation must be avoided. / Reconsider the definitions of the two terms in order to avoid circular definitions. / Accepted in principle.
The definitions have been harmonised with the terminology used in MIWP-5 / ARE3NA activity on the INSPIRE test infrastructure.
DK-9 / Terms and abbreviations / Para 4 and 7 / te / The terms “Requirement class” and “Conformance (test) class” are defined circular. I.e. in the definition of “Requirement class” the term “Conformance (test) class” are used and at the same time in the definition of “Conformance (test) class” the term “Requirement class” is used. This situation must be avoided. / Reconsider the definitions of the two terms in order to avoid circular definitions. / Accepted in principle.
The definitions have been harmonised with the terminology used in MIWP-5 / ARE3NA activity on the INSPIRE test infrastructure.
DK-10 / Terms and abbreviations / Para 10 and 11 / te / The terms “Executable test suite” and “Statement of conformity” are defined circular. I.e. in the definition of “Executable test suite” the term “Statement of conformity” are used and at the same time in the definition of “Statement of conformity” the term “Executable test suite” is used. This situation must be avoided. / Reconsider the definitions of the two terms in order to avoid circular definitions. / Accepted in principle.
The definitions have been harmonised with the terminology used in MIWP-5 / ARE3NA activity on the INSPIRE test infrastructure.
DK-11 / Terms and abbreviations / Para 12 / te / It is not the same definition for ”Data set” that is used here as in the referred standard and the INSPIRE Directive. / Harmonize the term at least with the INSPIRE Directive. / Accepted.
DK-12 / Terms and abbreviations / Para 13 / te / The definition of “Data set series” use the terms “resources” and “product specification”. However, these terms are not described further and their interpretation is left to the reader. / Include definitions of “resource” and “product specification”. / Accepted in principle.
The definition from regulation 1205/2008 is used:
‘spatial data set series’ means a collection of spatial data sets sharing the same product specification.
ES / 1.1 / 4th paragraph / ge / IT is not included reference to ISO 19157 when enumerate the standards of metadata / Change “the standards [ISO 19115], [ISO 19119], [ISO 19139]” by “the standards [ISO 19115], [ISO 19119], [ISO 19139], [ISO 19157]” / Not accepted.
[ISO 19157] is listed under “Other References”. It is not listed under normative references because it is only referred as an inspiration for the ISO 19139 encoding of the INSPIRE metadata elements Topological consistency and Data quality. The ISO 19157:2013 standard should be used together with a newer version of ISO metadata standard for geographic information, [ISO 19115-1].
SE / 1.1.2 / Figure 2 / ge / Clarify the definition of Other SDS. Other SDS is not mentioned in the text / Please clarify the difference between the different categories / Accepted.
Section 1.1.2 has been replaced by the corresponding section in [TG SDS, version 4.0rc3]
ES / 1.2 / 3rd paragraph 1st point / ge / Missing Standard citation (Annex F from which document?) / Change “into the normative Annex F
describing the discovery metadata for geographic resources” by “into the normative Annex F
describing the discovery metadata for geographic resources in ISO 19115-1” / Accepted.
Reworded to “into the normative Annex F (of ISO 19115-1) describing the discovery metadata for geographic resources”.
DE / 1.2. XML Encoding of ISO metadata / first paragraph / te / "To provide an XML encoding also for the INSPIRE service metadata, XML Schemas implementing the [ISO 19119] model have been published by the OGC" / add a hint that currently gmx: namespace is not included in the referenced schema and hence e.g. gmx:Anchor elements are not valid / Accepted.
DE / 1.3. INSPIRE Validator Service / second paragraph in Note / ge / "The validator isa proof of concept that has been developed to test these guidelines. It isnot intended to be an operational tool,..." / "The validator isa proof of concept that has been developed to test these guidelines. It isnot intended to be an operational tool,...";
this statement refers to the old version of this document / Accepted.
DK-14 / 2 / Para 3 / ed/te / We find it hard to distinguish between what is written in this paragraph and the prior one. / Either delete this paragraph or make the distinction more clear. / Accepted.
In the MIWP-8 comment resolution workshop it was decided to remove the 2 paragraphs about extensions/profiles, so that they can also be used.
Possible issues with the XPaths used in the document are addressed by the following note:
NOTEThese guidelines extensively use XPath expressions in the requirements and recommendations. If profiles conformant to [ISO 19139] are being used to encode INSPIRE metadata records, these XPath expressions may need to be adapted to match the profile.
UK-5 / 2 / Para 3 / ed/te / This para appears to repeat the previous one? / Simplify text and remove repetition. / Accepted.
In the MIWP-8 comment resolution workshop it was decided to remove the 2 paragraphs about extensions/profiles, so that they can also be used.
Possible issues with the XPaths used in the document are addressed by the following note:
NOTEThese guidelines extensively use XPath expressions in the requirements and recommendations. If profiles conformant to [ISO 19139] are being used to encode INSPIRE metadata records, these XPath expressions may need to be adapted to match the profile.
CZ / 2. / ge / Why are common requirements marked with “C”? / We would recommend to mark them uniformly in order of occurrence. / Not accepted.
In general, requirements are prefixed with the numbers of the conformance classes they belong to. Common requirements are not part of a specific conformance class. That’s why they are pre-fixed with C.
In addition to the numbering, the document now also uses mnemonic ids (that can be used to create URIs in the namespace) to identify requirements.
ES / 2.1 / 1st paragraph / ge / Drafting error (¿?) “…using the only the original...” / Change “Technical Guidelines requires using the only the original, unmodified [ISO 19139] “ by “Technical Guidelines requires using ISO 19139” / Accepted.
In the MIWP-8 comment resolution workshop it was decided to remove the 2 paragraphs about extensions/profiles, so that they can also be used.
DE / 2.1 / TG Requirement / ge / There is a strong need to validate service metadata that uses GML 3.2.1 elements instead of GML 3.2.0 elements (as used in We are aware of the GML 3.2.0 / 3.2.1 problem in the metadata application schemas as discussed e.g. in
We support the suggested solution and highly recommend that JRC should host updated schemas for the SRV namespace and an adopted ISO AP schema. / Provide and host a valid Schema XSD for Service Metadata using GML 3.2.1 (e.g. the ones generated by IGN). Refer to the Schemas in the Requirement A.1 / The issues was discussed at the MIWP-8 comment resolution workshop.
The JRC has raised the issue with the OGC. If the OGC is unable or unwilling to host a version of the AP-ISO xml schema that fixes the known problems with the OGC/ISO xml schemas, the JRC can host these.
CZ / 2.1 / TG Req. C.1 / te / Referring to two possible XSD should lead to validation problems (2006 has some errors, 2007 has not include service description), different gml versions etc / We would recommend to create INSPIRE repository with one mandatory scheme where the errors would be corrected. What about using new ISO 19115 standards? / The issues was discussed at the MIWP-8 comment resolution workshop.