commentson web viewadd a hint that currently gmx ... md_keywords element should be ... if one...

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.12.1 - 2.8 interoperability data, chapter 3.23.1 - 3.8 SDS chapter 4.14.1 and 4.2 network services chapter 4.25.1 - 5.5 invocable SDSchapter 4.36.1 - 6.5 interoperable SDS chapter 4.47.1 - 7.3 harmonised SDS chapter 4.5

Proposed Change

3.1.1 – 3.1.12 data, chapter 3.13.2.1 – 3.2.8 interoperability data, chapter 3.24.1.1 – 4.1.8 SDS chapter 4.14.2.1 and 4.2.2 network services chapter 4.24.3.1 – 4.3.5 invocable SDS chapter 4.34.4.1 – 4.4.5 interoperable SDS chapter 4.44.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 http://inspire.ec.europa.eu 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

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.

1 Type of comment: ge = general te = technical ed = editorial page 1 of 22

http://inspire.ec.europa.eu/




Type of comment1


documents

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”.





Type of comment1


In addition to the numbering, the document now also uses mnemonic ids (that can be used to create URIs in the http://inspire.ec.europa.eu 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 by whom this 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.4 Linking 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 ge The section 1.2 INSPIRE specific constraints m is Consider making a complete description of the Not accepted.






Type of comment1


history page 10

removed. This makes it difficult to see what is an ISO requirement and INSPIRE IR Metadata requirement

differences between ISO and INSPIRE requirements and not only for ISO core elements in Annex B

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


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


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


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.



DK-10


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







Type of comment1


conformity” the term “Executable test suite” is used. This situation must be avoided.

DK-11


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


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 Fdescribing the discovery metadata for geographic resources” by “into the normative Annex Fdescribing 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 is a proof of concept that has been developed to test these guidelines. It is not intended to be an operational tool,..."

"The validator is a proof of concept that has been developed to test these guidelines. It is not intended to be an operational tool,...";

this statement refers to the old version of this document

Accepted.

DK- 2 Para 3 ed/te We find it hard to distinguish between what is Either delete this paragraph or make the Accepted.





Type of comment1


14 written in this paragraph and the prior one. distinction more clear. 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: NOTE These 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: NOTE These 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 http://inspire.ec.europa.eu 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 http://schemas.opengis.net/iso/19139/20060504/

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


http://schemas.opengis.net/iso/19139/20060504/srv/





Type of comment1


srv/). We are aware of the GML 3.2.0 / 3.2.1 problem in the metadata application schemas as discussed e.g. in https://github.com/inspire-eu-validation/ats-metadata/issues/95.

We support the suggested solution and highly recommend that JRC should host updated schemas for the SRV namespace and an adopted ISO AP schema.

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. 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.The consideration of the new version of ISO 19115 has been out of scope for this update of the TG.

IT 2.1 Page 27 Te Not allowing extensions in the version 2.0 of TG will mean that amounts of data compliant with those extensions (defined in conformance to the rules given in ISO 19115) won’t be considered in the INSPIRE context.

Revise the decision of not allowing extensions, referring to the specific rules given in ISO 19115, Annex C and in ISO TS 19139, Annex A.3.

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.

Uk-6 2.1 TG Req. C.1 te XSD locations should be less ambiguous A clear INSPIRE registry owned location for definitive schemas could be established?


DE 2.1.

Metadata

structure

and

encoding

TG

Requirement

C.1

te listed schemas do not fulfil some requirements given in this document where gmx:Anchor is mandatory

provide a reference to a schema that includes the gmx: namespace or downgrade to a recommendation


ES 2.2 Example C.1 ge According the requirement has to be met starting from 23 November 2012 for data sets that were created or extensively restructured after 15 May 2007 and starting from 23 November 2017 for all other data sets, the EPSG has to be introduced with identifiers (EPSG URIs).

Review this example Accepted.The example now uses keywords rather than reference systems.


https://github.com/inspire-eu-validation/ats-metadata/issues/95

https://github.com/inspire-eu-validation/ats-metadata/issues/95

http://schemas.opengis.net/iso/19139/20060504/srv/




Type of comment1


See “IR Requirement Annex II,, Section 1.5” of Data specification. Example: http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.1.pdf

In this example, the Information about Reference System Information is included with EPSG not with URI. This is confuse

ES 2.3.1 Requirement C.4

ge In the text says: Only the code values for the official languages of the European Union shall be used.What happen with “regional Languages”?Is not possible to include in this elemente?

Explain it Not accepted. It is explained in the IR requirement, which states that the metadata language “is limited to the official languages of the Community expressed in conformity with ISO 639-2”.

CZ 2.3.2. TG Req. C5 te Element Country, should be a mandatory element. When the element is not specified, it causes problems in completing.

We would appreciated to supplement a recommendation identifying how to fill in the element, e.g. a reference to code list, URIs, etc.

Not accepted.The comment is not clear.

DK-16

2.3.6 TG Req A.15 te Requirement A.15 introduces a gmx:Anchor link in otherConstraints pointing to a value of a code list. The element otherConstraints is free text and as a result of requirement A.15, its seems that metadata compliant with previous versions of the Technical Guidelines must be updated. The new gmx:Anchor element may not directly be supported when existing metadata is updated in the existing editors and it may be necessary for the metadata responsible people to edit the XML directly.

Please reconsider the content of this requirement. (Assuming that the comment refers to C.17)Not accepted. The new version indeed in not backwards-compatible. However, the proposed change is deemed to be an important improvement over the previous version.Some of these changes can be automated.Because of the non-backwards compatibility, the transition period is proposed to be 3 years.

DK-17

2.3.7 TG Req A.17 te Requirement A.17 introduces a gmx:Anchor link in otherConstraints pointing to a value of a code list. The element otherConstraints is free text and as a result of requirement A.17, it seems that metadata compliant with previous versions of the Technical Guidelines must be updated. The new gmx:Anchor element may not directly be supported when existing metadata is updated in the existing editors and it may be necessary for the metadata responsible people to edit the XML directly.

Please reconsider the content of this requirement. (Assuming that the comment refers to C.19)Not accepted. The new version indeed in not backwards-compatible. However, the proposed change is deemed to be an important improvement over the previous version.Some of these changes can be automated.Because of the non-backwards compatibility, the transition period is proposed to be 3 years.

DK-18

2.3.8 Para 1 ed/te We do not understand the following sentence: “Defining the geographic containing boundary of the described resource enables the users to discover interesting resources using their area or

Reformulate and clarify what is the intent with this sentence.

Accepted.


http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.1.pdf

http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.1.pdf




Type of comment1


location of interest”.

ES 2.4.2 1st paragraph ge Drafting error (¿?) “The elements the abstract for the resource...”

Review the redaction Accepted. Reworded to “The element for the resource abstract is described …”

CZ 2.4.3. TG Req. C.9 te Element Country, should be a mandatory element. When the element is not specified, it causes problems in completing.

We would appreciated to supplement a recommendation identifying how to fill in the element, e.g. a reference to code list.

Not accepted.The comment is not clear.

CZ 2.4.3. TG Req. C.9 te XPath is not complete, the Responsible party is in identificationInfo element.

We would recommend to add the “identificationInfo[1]/*/” into the XPath for clarity

Not accepted. This is in line with the other requirements in the document that describe elements rather than full XPath expressions. Xpath can be derived from the example in section 2.3.3.

AT 2.4.4 ge Example of temporal extent is missing Accepted.

ES 2.4.4 Requirement C.11 and C.12

ge According the regulation 1205/2008, date of last revision “ There shall not be more than one date of last revisión”, that is multiplicity (0-1) and the date of creation “There shall not be more than one date of creation that is multiplicity (0-1)However in the guidelines, it is included these dates like mandatory in the Requirement C.11 and C.12.

Review these Requirements Accepted – the wording could be ambiguous. Use the wording of the IRs.

ES 2.4.4 Example C.6 ge In the example is included the term “revision” in French however, in this section is not described that the value of date can be included in different languages.

Include a note about the possibility to include the value of date in different languages.

Not accepted. The rest of the example is in English. Change example text to “revision”.

NL 2.4.4 Requirement C.13

te In the Netherlands another XML notation of temporal extent is required

Use <gml:TimePeriod gml:id="temporal-extent-1" xmlns:gml="http://www.opengis.net/gml"> <gml:begin> <gml:TimeInstant gml:id="start_temporal-extent-1"> <gml:timePosition>2009-11-27</gml:timePosition> </gml:TimeInstant> </gml:begin> <gml:end> <gml:TimeInstant gml:id="end_temporal-extent-1"> <gml:timePosition>2009-11-27</gml:timePosition> </gml:TimeInstant> </gml:end> </gml:TimePeriod>

Not accepted.Although, according to the schema, both options are valid, only a very small minority of INSPIRE metadata records uses the proposed alternative encoding.

ES 2.4.6 5th paragraf ge Drafting error (¿?) “…The make the references to the allowed reasons...”

Review the text. Accepted. The text should read: “To make the …”

FR 2.4.6 te Why not using useLimitation anymore? I see the opportunity to have Anchors but not of this change of field.

Please document reason for changes. When changes have no added-value for interoperability please allow no-change options.

Not accepted.The Correction of TG Metadata concerning the use of another element instead of useLimitation for





Type of comment1


"Condtions applying to access and use" was one of the essential issues to build up this task and is documented in the Terms of Reference (bullet A). As pointed out before the element useLimitation aims at "fitness for use" and is designated to show limitations concerning the content ("What is it not suitable for?") and not legal restrictions on access or use ("Who is not allowed to use it and what has to be respected?").See also detailed discussion of MIWP-8 at https://ies-svn.jrc.ec.europa.eu/issues/2212.

AT 2.4.6. ge Footnote 25: http://inspire.ec.europa.eu/registry/metadata-codelist/LimitationsOnPublicAccess

Link does not exist yet. Links in general need to be proofed.

Accepted. The values in Annex D have been added to the INSPIRE registry and the URL has been corrected to http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess

AT 2.4.7 Example C.9 ge Enhancement of the Example C.9: a condition of the codelist (http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse) in combination with a free text element with a textual description of conditions (for instance detailed information about licensing)

Not accepted.Proposal not clear.

AT 2.4.7 Example C.8Example C.9

ge Is the codeListValue="otherConstraints" correct?(codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode")

Should mean "otherRestriction" (?) Accepted.It should read “otherRestrictions”.

CZ 2.4.8. ge According to the GeoDCAT and Semantic Web initiatives the spatial extent presented only by the geographical bounding box is not sufficient.

We would appreciated to add a recommendation to present the spatial extent by the code/URI of spatial units (from official European registry if available) besides the bounding box.

Not accepted.Such a recommendation is out of scope for these TGs.

ES 2.5 List of 3rd paragraf

ge Drafting error? “Invocable Spatial Data Services (including interoperable and harmonised Spatial Data Services) and shall declare.”

Review the text Accepted. Removed “and”.

ES 2.5.1 Conformity ge In this section is not included to declare conformity to Regulation 1205/2008 but the metadata element are regulated according this Regulation

Include declare conformity to Regulation 1205/2008

Not accepted. The MD element conformity describes the conformity of data sets, spatial data services and network services, not of the metadata itself.

ES 2.5.1 3rd paragraph ge Mistake…Implementing Rule text is is Delete “is” Accepted.


https://ies-svn.jrc.ec.europa.eu/issues/2212




Type of comment1


interpreted...”

DE 2.5.1.

Conformit

y

list of three

bullets

ge For Network services the IR 1089/2010 has to be cited as well

change wording Not accepted. (The following interpretation is still legally checked by DG ENV).

The MD IRs require that the conformity element be used where there is a requirement in Article 5(2)(a) and Article 11(2)(d) of Directive 2007/2/EC relating to the conformity (i.e. only for data sets).

Since the required multiplicity is 1..* for both data sets/series and services, services also need to include at least one conformity statement, but it does not have to be related to Regulation 1089/2010.

This also makes sense, since NS do not need to comply with Regulation 1089/2010; thus, if a conformity statement was required, it would by default have to be "not evaluated".

DK-20

2.5.1 TG Req A.19 ed/te We are not sure if the intention of TG Requirement A.19 is a long list of results of conformity evaluations.

Consider clarification. Accepted (refers to TG Requirement C.21).The requirement has been reworded to: The degree of conformity of the described resource with an INSPIRE Implementing Rule, specification document, its Requirements Class or similar part, shall be given using a gmd:DQ_ConformanceResult element under gmd:report/gmd:DQ_DomainConsistency/gmd:result. For each conformity statement (i.e. for each specification), a separate gmd:DQ_ConformanceResult element shall be used.

DK-21

2.5.1 TG Req A.20 ge/te Titles of documents in metadata may contain typos and misspellings. Perhaps optional use of code lists containing the relevant documents could help the metadata responsible people.

Consider possible ways of helping the metadata responsible people to cite titles correctly.

Accepted. Recommendations to use Anchors with references to the ELIs (European Legal Identifiers), e.g. http://eur-lex.europa.eu/eli/reg/2010/1089/oj,have been added.

DE 3.1.2.

Identificati

on info

section

TG

Recommenda

tion 1.1

ge Recommendation is not covering both alternatives for data service coupling and is obsolete for the way still to be added

see E-Mail from Wed, 20 Apr 2016, where addition regarding data service coupling based on our proposal has been promised

Accepted.

FR 3.1.2.1 TG te There is no interest to forbid RS_Identifier. Please put a star in the xpath instead. Unresolved.


http://eur-lex.europa.eu/eli/reg/2010/1089/oj




Type of comment1


Requirement 1.3

This has been the most controversial issue discussed in the MIWP-8 sub-group.An open issue in the document outlines the arguments for and against keeping the requirement strict.

NL 3.1.2.1 Recommendation 1.2

te "For other types of URIs, a resolving service should be provided implementing similar functionality."How does the user now where the resolving service is available?

Not accepted.The proposed change is unclear.

DK-22

3.1.2.1 TG Recommendation 1.2

te In order to really understand the need for this recommendation we need a description of the need.

Provide somewhere in text a rationale for this recommendation.

Accepted.But still TBD.

CZ 3.1.2.1. Recom. 1.2 te There is not fully described how the URI should link to the resource – metadata description in HTML/resource itself/machine readable document

We would recommend to specify the recommended behaviour of the target – some semantic web practises ?

Not accepted.The proposed change is not specific enough.

CZ 3.1.2.2. TG Req. 1.4 te Since the INSPIRE themes are part of the INSPIRE Registry, we would recommend to use this Registry as a reference.

Remove the GEMET form the Thesaurus citation and use INSPIRE Registry (http://inspire.ec.europa.eu/theme) instead of GEMET. Also thesaurus citation might be omitted when Anchor – URI mechanism is used.

Accepted in principle.The IRs explicitly refer to GEMET. Example C.7 already shows how to use Anchors pointing to the INSPIRE theme register for the GEMET theme keywords.

ES 3.1.2.3 Example 1.3 ge The example belongs to chapter 3.1.2.2 Change the example Accepted.

DK-23


te We strongly support this recommendation. However, an example describing how it can be used would fruitful.

Provide somewhere in text an example where this recommendation is used.

Accepted.

UK-7


te An illustrative example of use might be helpful. Provide an example. Accepted.

ES 3.1.2.4 Example 1.6 ge Drafting error in the description of the example (¿?) “it's the name if the Finnish language in Finnish”

Review the description of the example Accepted. Reworded to: ““it is the name of the Finnish language in Finnish”

ES 3.1.4.1 TG Requirement 1.10 (1st paragraph)

ge There is an error describing the scope (¿?). It shall say “dataset” and/or “series”. “There shall be exactly one gmd:dataQualityInfo/gmd:DQ_DataQuality element scoped to the entire described service.”

Delete “service” Accepted. Replaced “service” by “data set or data set series”.

SE 3.1.4.2 XML example te It would be informative to indicate how conformity to different requirement classes should be encoded, and not only to publish documents. In

Clarify how conformity against requirement classes or conformance classes should be encoded.

Accepted.A recommendation and an example have been


http://inspire.ec.europa.eu/theme




Type of comment1


data specifications examples are given using href and URI of the conformance class instead of using CI_Citation. Reading this document it seems that using CI_Citation is the only possibility.

added.

NL 3.1.4.3 TG Recommendation 1.8

te Does this mean that lineage is conditional and not mandatory?

No. It clearly states at the end of the recommendation that the DQ measures should be used “in addition to the Lineage metadata element”.

DK-25


te The way we see it, the first part of this recommendation is an extension of what I written in INSPIRE metadata regulation.

Reconsider the content of this recommendation. Not accepted. It is the nature of recommendations that they go beyond what is required by the IRs.

ES 3.2.1.1 TG Requirement 2.2

ge Drafting error? “The gmd:codeSpace element shall not be be used in this case.”

Mistake in the sentence. Delete “be” Accepted.

SE 3.2.1.1 te, ge What is the coordinate reference system describing is it the valid system for distribution or is it the CRS for managing dataset at each data provider?Why was this element included in the metadata for interoperability?

Our opinion is that the metadata element should describe the CRS used to produce and manage datasets at each provider; in this case the list with valid CRS must be extended. CRS used for distribution is provided in the capabilities document of the services.Annex D5 should only be used to indicate the default CRS for the services

Accepted. A recommendation has been added according to the discussion in https://themes.jrc.ec.europa.eu/discussion/view/64808/what-crss-to-document-in-metadata-when-serving-a-dataset-through-a-wfs.

AT 3.2.1.1. ge Mandatory “Coordinate Reference System” may cause difficulties for data themes with statistical data (population, human health).

Give an example how to deal with this metadata element for data themes such as population and demography.

Unresolved. This is marked as an open issue for discussion.

ES 3.2.1.2 3rd paragraph ge Drafting error? “The multiplicity of this element is zero more”.

Review because the multiplicity is the [0.1] Accepted.

AT 3.2.2.1. ge Mandatory “Spatial Representation Type” may cause difficulties for data themes with statistical data (population, human health).

Give an example how to deal with this metadata element for data themes such as population and demography.

Accepted. The ISO code list also includes “textTable” as a value, which is added as an additional possible value.

DE 4.

Requirem

ents

Classes

for Spatial

Data

(all) ge Version 3.2 of [TG SDS] will include requirements concerning Metadata as well. Both documents shall be consistent.

Ensure consistency between [TG SDS], version 3.2 and [TG MD], version 2.0 and consider including metadata requirements in [TG MD] only, i.e. remove metadata requirements from [TG SDS].

Accepted.In the proposed version 4.0 of the SDS TG the MD requirements have been removed and a pointer to the MD TGs is included.


https://themes.jrc.ec.europa.eu/discussion/view/64808/what-crss-to-document-in-metadata-when-serving-a-dataset-through-a-wfs






Type of comment1


Services

ES 4.1.2.2 Recommendation 3.2

ge In the text says that “ gmd:theaurusName element of the enclosing gmd:MD_Keywords element should be added and it should contain the citation to the [Regulation 1205/2008], Part D 4 and its publication date according to section 2.4.5.” but there is a thesaurus to include “Classification of spatial data services” (http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/SpatialDataServiceCategory.en.rdf)

Change the redaction of this Recommendation to include the correct name of thesaurus

Accepted with modification.The authoritative source is the list in the Regulation, but the recommendation and example have been changed to use an Anchor element with a reference to the code list value in the INSPIRE registry.

ES 4.1.2.2. Example 3.2 ge The element “gmd: title” include the name of a Regulation, but it is not a title of thesaurus

Change the content of element “gmd: title” by “Classification of spatial data services” according tohttp://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/SpatialDataServiceCategory.en.rdf

Accepted with modification.The authoritative source is the list in the Regulation, but the recommendation and example have been changed to use an Anchor element with a reference to the code list value in the INSPIRE registry.

CZ 4.1.2.2. Example 3.2 te Reference to a citation of Classification of Spatial Data Services should not take the form of CharacterString but URI when the INSPIRE registry exists.

We recommend to use URI instead of CharacterString where the INSPIRE Registry exists.

Accepted.The recommendation and example have been changed to use an Anchor element with a reference to the code list value in the INSPIRE registry.

CZ 4.1.2.2. Example 3.2 te Part D4 of Regulation 1208/2005 is not a thesaurus, therefore it should not have a citation.

We recommend to remove the citation from the example.

Not accepted.The authoritative source is the list in the Regulation

CH 4.1.2.3 TG Requirement 3.5

te The value domain of this metadata element is defined in Part D3. With these conditions, it is not possible to give a good and precise description of the service. Example: in the case of a viewing service, we have to write view, in state of OGC:WMS or OGC:WMTS. With View, we don’t know whether it is a WMS or a WMTS.

Create a new INSPIRE Attribute (ISO extension) with following name: inspireServiceType.This new Attribute has to be filled with the code list from Part D3. In the existing attribute ServiceType, we can describe the service with the technical name, for example OGC:WMS

Unresolved.This is highlighted as an open issue.

DK-28

4.1.2.3 Para 2 te The content of this note is a problem. If one compares with what is written in the INSPIRE Directive then the word “invoke” is clearly used a couple of times.

There is a need for clarification of what is written in the Directive and in the regulations. These must be harmonised and then implemented in these guidelines.

Accepted. This should refer to the explanation in the SDS TG on how invoke services should be implemented (by providing additional SDS MD through the discovery service).

AT 4.1.2.4 ge Altough the uuidref element is optional it is very Remove the optional uuidref element. Accepted.


http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/SpatialDataServiceCategory.en.rdf









Type of comment1


confusing to use an URL in an element that by the element name expects anuuid as reference value.

Recommendation 3.5 is removed.

ES 4.1.2.4 Requirement 3.6

ge Coupled resource shall be implemented by reference, but it is not included that the reference should be made with the operation “GetRecordByID” of the CSW service. Why is not mandatory to include this operation to access to metadata record?

If it is mandatory include this operation then include it

Not accepted. The reference does not need to be to a CSW GetRecordByID request.

AT 4.1.2.4 Example 3.4 ge,ed Better explanation for the example would be great.

The current example uses a GetRecordById CSW operation that is not part of the INSPIRE Discovery Service TG. The id used in this example clearly hints to a file_identifier-like id of an ISO MD record, since there is no namespace.

The last sentence in the description (“An optional uuidref attribute is used …”) seems not to be complete.

Use as example either a GetRecords Discovery Service operation with a filter on a unique resource identifier, with an URI as id or the proposed solution from chapter 3.1.2.1 with an URL as unique resource identifier that resolves to aMD_Metadata document with an anchor to the MD_DataIdentification object.

Accepted. The example now uses a GetRecords request.Note however, that any URI could be used (also a GetRecordById request).

AT 4.1.2.4 te The proposed introduction to reference the MD_DataIdentification object via XPointer is a solution to respect the ISO standard, but results in a big implementation effort, since every metadata dataset has to be updated to introduce the anchor id.

Only allow one MD_DataIdentificationobject per MD_Metadata document and demand a reference to the remote MD_Metadataobject instead of the nested MD_DataIdentification object and do not enforce the ISO compliance.

Give a practical example with more than one MD_DataIdentification object in a document to make the application of the XPointer id clearer.

Accepted with modifications.Different options and examples for implementing the reference to the MD_DataIdentification element are included.

CH 4.1.2.4 TG Requirement 3.6

te If there is a spatial data service (for example a OGC:WMS) using more than one data set, then there is a problem:When using the element srv:operatesOn for linking the metadata of the spatial data service and the metadata of the target data set, it’s not possible to specifiy which is the target layerName (for OGC:WMS) in the spatial data service.

In state of the element srv:operatesOn, the element srv:coupledResource should be used. In this case, the element gco:ScopedName could be used to describe the target layerName in the spatial data service

Not accepted. The link from the service to the layer names are not required by the MD Regulation.This link can be established through the service capabillties.

FR 4.1.2.4. TG Recommandation 3.5

te If http://paikkatiedot.fi/so/1002001 points to the metadata you would not need any alternative href so no uuidref would be required.

Please consider this option that would be far cleaner as http://paikkatiedot.fi/so/1002001 is not a uuid at all.

Accepted. The example has been revised.


http://paikkatiedot.fi/so/1002001

http://paikkatiedot.fi/so/1002001




Type of comment1


NL 4.1.2.4. Requirement 3.6AndRequirement 1.2

te I cannot find a reason (legal or technical) that the URI should pointing to the gmd:MD_DataIdentification element in the requirement;..The xlink:href attribute of each of the srv:operatesOn elements shall contain a URI pointing tothe gmd:MD_DataIdentification element of the metadata record of theprovided the data set or data set series….This makes it unnecessary complex and difficult in maintenance. Requirement 1.2 is used to prevent more (theoretically ?) gmd:IdentificationInfo INSPIRE properties.If requirement 1.2 can be made more explicit by allowing not only the first, but only one gmd:IdentificationInfo, are all potential problems solved

Change requirement 3.6 ;The URI should pointing to the metadata record of the datasetChange also requirement 1.2 ; only one gmd:IdentificationInfo is allowed

Accepted with modifications. The link to MD_DataIdentification is required by ISO.

DE 4.1.2.4.

Linking to

provided

data sets

using

coupled

resource

TG

Recommenda

tion 3.5

ge recommendation is obsolete when documenting the two alternative ways

remove Accepted. Recommendation 3.5 has been removed.

DE 4.1.2.4.

Linking to

provided

data sets

using

coupled

resource

whole section te/ge alternative for data service coupling based on URI is missing

see E-Mail from Wed, 20 Apr 2016, where addition regarding data service coupling based on our proposal has been promised

Accepted. The section 4.1.2.4 has been revised accordingly.

ES 4.2.1 Requirement 4.1

ge Mistake in the definition of the element Change “The multiplicity of the gmd:report/gmd:DQ_DomainConsistency/gmd:result/gmd:DQ_ConformanceResult” by “srv:serviceType/gco:LocalName”

Accepted

DE 4.2.2.

Data

TG

Requirement

ge For Network services the IR 1089/2010 has to be cited as well

change wording: citing IR 1089/2010 is mandatory Not accepted.

The MD IRs require that “the requirements





Type of comment1


quality info

section

4.2 referred to in Article 5(2)(a) and Article 11(2)(d) of Directive 2007/2/EC relating to the conformity, and the degree of conformity, with implementing rules adopted under Article 7(1) of Directive 2007/2/EC shall be addressed by the following metadata elements” Conformity.Specification and Conformity.Degree.

The Directive says in Article 5(2):

2. Metadata shall include information on the following:(a) the conformity of spatial data sets with the implementing rules provided for in Article 7(1);…

and in Article 11(2):

2. For the purposes of the services referred to in point (a) of paragraph 1, as a minimum the following combination of search criteria shall be implemented:(…)(d) degree of conformity with the implementing rules provided for in Article 7(1);

Thus, from the Directive, there is only an obligation to specify the conformity with Regulation 1089/2010 for data sets, and not for spatial data services (incl. network services).

However, since the required multiplicity is 1..* for both data sets/series and services, services also need to include at least one conformity statement, but it does not have to be related to Regulation 1089/2010.


DE 4.2.2.

Data

quality info

section

Example 4.1 ge example for citing IR 1089/2010 is missing maintain example Not accepted.

The MD IRs require that “the requirements referred to in Article 5(2)(a) and Article 11(2)(d) of Directive 2007/2/EC relating to the conformity, and the degree of conformity, with implementing rules





Type of comment1


adopted under Article 7(1) of Directive 2007/2/EC shall be addressed by the following metadata elements” Conformity.Specification and Conformity.Degree.

The Directive says in Article 5(2):

2. Metadata shall include information on the following:(a) the conformity of spatial data sets with the implementing rules provided for in Article 7(1);…

and in Article 11(2):

2. For the purposes of the services referred to in point (a) of paragraph 1, as a minimum the following combination of search criteria shall be implemented:(…)(d) degree of conformity with the implementing rules provided for in Article 7(1);

Thus, from the Directive, there is only an obligation to specify the conformity with Regulation 1089/2010 for data sets, and not for spatial data services (incl. network services).

However, since the required multiplicity is 1..* for both data sets/series and services, services also need to include at least one conformity statement, but it does not have to be related to Regulation 1089/2010.


AT 4.2.2.1. te Conformity declaration Conformity declaration against the regulation should be in a codelist/ registry

Accepted.Two options exist for implementation. This is highlighted as an open issue in section 2.5.1.

NL 4.3.3.1. te Open question: The only part of [Regulation 1089/2010] concerning services is the amendment [Regulation 1312/2014]. Conformance can declared in two ways; [Regulation 1312/2014] is seen as part of [Regulation 1089/2010] and the

Or conformance is declared against [Regulation 1089/2010] or conformance is declared against [Regulation 1312/2014] not both.

Accepted.

The EU Publications Office has advised the following:





Type of comment1


conformance is declared against [Regulation 1089/2010]. Or [Regulation 1312/2014] is seen as a separate regulation and conformance is declared against it.

The usual way of referral is the following (using an example):

Council Directive of 27 July 1976 on the approximation of the laws of the Member States relating to alcoholometers and alcohol hydrometers (76/765/EEC) (OJ L 262, 27.9.1976, p. 143), as subsequently amended.

Such formulation means that you refer to a legal instrument together with all its subsequent amendments.

In case for a specific reason you want to list all the amending acts concerned you could use the following formulation:Council Directive of 27 July 1976 on the approximation of the laws of the Member States relating to alcoholometers and alcohol hydrometers (76/765/EEC) (OJ L 262, 27.9.1976, p. 143), as amended by (and then you list the amending acts).

Therefore, conformity shall be declared only to Regulation 1089/2010 (as subsequently amended).

DE 4.3.3.1.

Conformit

y to

INSPIRE

Implement

ation

Rules

question in

yellow

ge 1312/2014 is an amendment to 1089/2010. Referring to 1089/2010 is sufficient and includes the SDS issues.

no additional declaration Accepted. Conformity shall be declared only to Regulation 1089/2010 (as subsequently amended).

NL 4.4.3.1 te The valuedomain of the criteria are as described in the [Regulation1312/2014], availability, performance and capacity. In the example and table is this not conform the regulation

Change the value of nameOfMeasure in the example and table conform the regulation.

Accepted.

NL 4.4.3.1 te The valuedomain of the criteria are as described in the [Regulation1312/2014], availability, performance and capacity. In the example and table is this not conform the regulation

add a codelist for this valuedomain Accepted.





Type of comment1


NL 4.4.3.1 te Not correct to point here to a codelistgmd:DQ_ConceptualConsistency/gmd:measureIdentification/gmd:MD_Identifier/gmd:code shall be angmx:Anchor element referring to code list value for the criteria…That should be done in element nameOfMeasure

The identifier should refer to a identifier of a description/specification, of the measurement as specified in the table in TG SDS v3.2rc2 in a register

Accepted with modifications. The Anchor with the reference to the code list value in the INSPIRE registry is used for the nameOfMeasure element. To avoid duplication of information, the measureIdentification element is no longer used.

NL 4.5.1.1 TG Requirement 7.1

te The class SV_OperationMetadata with elements operationName, DCP and connectPoint are mandatory in ISO 19119; option 1 is not valid. The metadata record contains always at least one srv:containsOperations/srv:SV_OperationMetadata element.

Option 1 should use the element connectPoint with the same URL as resource locator being an access point.The operationName is a free text field, so a specified text something like “operation description” can be used to point out that the operations are described in the connectPoint access point.

Accepted. Requirement 7.1 has been updated accordingly.

CZ Annex A ATS ge Where should these tests be performed, JRC validator or validation at MS’s side.

Add information for whom are designed these tests.

Not accepted.The abstract test suite defines tests at an abstract level. These can then be implemented by whoever wishes to do so.

UK-9

Annex A te None of the URLS in the ATS actually resolve e.g. http://inspire.ec.europa.eu/specification/RC/TG-Metadata/2.0/dataset-interoperability does not resolve

Remove or check all URL resolves Accepted in principle.At the time of writing, the test cases for these Conformance Classes were not yet published. The repository for the Conformance Classes will be made available at http://inspire.ec.europa.eu/id/ats/metadata/2.0

DE Annex C.2 1.4 Resource

locator

ge Example for Resource locator for datasets is misleading: a link to a capabilities document of a corresponding service might be allowed, but is more sufficient for services itself

change example to e.g. a link to a web site with further product information

Accepted. A second example pointing to a web site for a data set has been added.

DE Annex C.2 8.1

Conditions

applying to

access and

use

ge there's no example for useConstraints; We had this shown in a much clearer way in a former draft (based on v055)

build up example for useConstraints Accepted. Include example from v055.

ES C.2,C.3,C.4,C.5

ge The table include in the Annex C.2, C.3, C.4, C.5 and C.6 for the description of each element should be included in each element, not all included in an Annex. In the last version of the document, the table is included in each section not all together

Review for included the information that is not repeated in its section of document, like in the actual version of document.

This table make that the document will be a very long document.

Not accepted.


http://inspire.ec.europa.eu/id/ats/metadata/2.0




Type of comment1


NL Annex C.4 Part B 1 Category

te The domain values are not correct, also the one used in the example

Change in invocable http://inspire.ec.europa.eu/RequirementsClass/TG-Metadata/2.0/SDS-invocableinteroperable http://inspire.ec.europa.eu/RequirementsClass/TG-Metadata/2.0/SDS-interoperableharmonised http://inspire.ec.europa.eu/RequirementsClass/TG-Metadata/2.0/SDS-harmonised

Accepted.

NL Annex C.4 Part D 1. function

te The domain is not correct The gmd:linkage/gmd:description child element gmd:CI_OnlineResourceshall contain a gmx:Anchor element pointing to the value "accessPoint" ofthe code list OnLineDescriptionCode in the INSPIRE Registry55.

Accepted.

NL Annex C.5 Part B 4.2 Measurement

te The domain and example is not correct Replace with http://inspire.ec.europa.eu/registry/metadata-codelist/QualityOfServiceCriteriaCode/minimumAvailability…

Accepted.The correct code list URI is http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/availability

SE C7 Comments row in many tables, i.e. Spatial representation information

ge Reference to a non-existing (?) document regarding theme specific metadata is given.

Include the document as an Annex or provide a formal citation.

Accepted. The information from the document have been included in the TG document.

IT Annex D D.3 ed/ge The codelist “Spatial Data Service type” is given in IR and is already included in the INSPIRE registry (http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType). It should be treated similarly to the codelist “Spatial Data Service category”, given in IR and included in INSPIRE registry but not in the Annex D.

Remove the codelist Accepted.

NL Annex D te Not all codelists are provided here. I miss the codelists on

Check if all new codelists are provided here and add if missing.

Comment not complete. All relevant code lists are included in Annex D.

NL Annex D D4 Quality of Service criteria

te Codelist should be replaced with a measurement register

Describe the measurements in a measurements register and provide the identifier to refer to.

Not accepted.This code list reflects the values included in the SDS amendment to Regulation 1089/2010.


http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType

http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType

http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/availability

http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode/availability




Type of comment1


code

NL Annex D D4 Quality of Service criteria code

te This values are not conform the regulation. A codelist with the criteria values, conform the regulation should be added

Add a codelist conform the regulation Accepted. See above.

ES Annexes ge Links to inspire registry and specifications at inspire.ec.europa.eu are not working

Include the Link correctWait until registry and specifications are implemented and check them again.

Accepted.The code lists are now available in the INSPIRE registry.

UK-13

Annexes

E &F

All ge I'm presuming someone has double checked each of the mappings independently? (I don't see any obvious errors but I've not had a chance to individually go through each mapping)

Double check that the mappings in Annex E & F are correct.

Accepted.


commentson web viewadd a hint that currently gmx ... md_keywords element should be ... if one...

Documents