ies-svn.jrc.ec. web viewcountries: at, ch, cz, de, dk, es, fr, it, nl, se, uk. date: 2016-05-24....

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.To be discussed with MIWP-8 / MIG-T whether to use (mnemonic) ids instead of numbers.

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

Proposed change is unclear.

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” will be updated accordingly.

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” will be updated accordingly.

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)

To be discussed with MIWP-8.

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

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.

Not accepted.This would be a huge task. The changes and their rationale have been documented by the MIWP-8 sub-group during the process.To be discussed with MIWP-8 / MIG-T.

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




Type of comment1


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.

Agreed to remove yellow text.To be discussed if we need introductory text to all sections.Ok

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.

To be discussed.To be clarified what the UML diagrams should represent? Should these be copied from ISO 19115/19139?If accepted, who could provide such a diagram?Please consider figure 1-19 (UML-diagrams) in ISO 19115:2014.

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 in principle.To be clarified with DK, where precisely tables would be helpful.Several places in the document there are reference to “Tables 1 and 2 of [Regulation 1205/2008], Part C” – it would be helpful if these tables where available in an annex to this TG MD. Several places in the document there are reference to “Tables 1 and 2 of [Regulation 1205/2008], Part C” – it would be helpful if these tables where available in an annex to this TG MD.

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

Numbering of requirements and recommendations to be discussed.Maybe we should give them unique (mnemonic) ids instead.

Provide unique ids sounds as a right approach. Now the identification is illogical:

Chapter 2: TG Requirement A.*, TG Recommendation A.*

Chapter 3: TG Requirement 1.*, TG





Type of comment1


Recommendation 1.*

Chapter 4: TG Requirement 3.*, TG Recommendation 3.*Chapter 4.2: TG Requirement 4.*

DK-5

All ed Some of the chapters prior to chapter 1 have headlines in clear text and no numbering. Why? – It would make the layout of the document more consistent if each chapter was assigned a number.

Add a number to each chapter. Accepted in principle. To be harmonised with other TGs.Ok

UK-1

All ed Editing required to ensure all text complete (no empty headers) and remove highlighted text sections

Complete text and check for odd formatting. Accepted.

UK-2

All ed Ensure that cross-references to other documents point to actual document fragments that provide meaning to the text.

Check all cross references and external dependencies in document are ‘live’ and resolvable.

Accepted.

UK-3

All ed Formatting - ensure consistency in capitalization, numbering and abbreviations used.

Ensure consistency in capitalization, numbering and abbreviations used.

Accepted.

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.

Is there a reason for including the multiplicity only

in some requirements?

DE Acknowle

dgements

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 Acknowle

dgements

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.

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

DE Reading

guidance

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.





Type of comment1


and

transition

period

ES Revision history

15th point ed Duplicate “and” Delete “and” Accepted.

ES Revision history

29th point ed “Has bee” Include “Has been” Accepted.

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.

To be discussed in conjunction with the DE

comment on section 3.1.2.

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

Proposed change is unclear. Clarify with DE.

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

Bring section on INSPIRE-specific constraints back as an annex?

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.

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.





Type of comment1


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

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.This should be 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.This should be harmonised with the terminology used in MIWP-5 / ARE3NA activity on the INSPIRE test infrastructure.Ok

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

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 should be used:‘spatial data set series’ means a collection of spatial data sets sharing the same product specification.Do we need to define “product specification”?Data product specification is according to ISO 19131:2007 defined as “detailed description of a dataset or dataset series together with additional information that will enable it to be created,





Type of comment1


supplied to and used by another party”

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

Accepted.

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. This should be taken from the SDS TG.

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 Fdescribing the discovery metadata for geographic resources in ISO 19115-1”

Accepted. Reword 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-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.

Unclear what the comment refers to. Check with DK and UK.We mean the sentence on page 17 starting “The above is not a requirement targeting metadata records as a subject...”. We think this text in yellow is a duplication of the text in the para prior one.

UK-5

2 Para 3 ed/te This para appears to repeat the previous one? Simplify text and remove repetition. Unclear what the comment refers to. Check with DK and UK.

CZ 2. ge Why are common requirements marked with “C”? We would recommend to mark them uniformly in order of occurrence.

To be discussed with MIWP-8 / MIG-T whether to use (mnemonic) ids instead of numbers.

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”

To be discussed with MIWP-8 why extensions are not allowed.





Type of comment1


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/

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.

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

To be discussed with JRC geoportal team / MIWP-

8 / MIG-T.

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?

To be discussed with JRC geoportal team / MIWP-8 / MIG-T.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.

To be discussed with MIWP-8 why extensions are not allowed.

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?

To be discussed with JRC geoportal team / MIWP-8 / MIG-T.

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

Comment not understood.

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

See “IR Requirement Annex II,, Section 1.5” of

Review this example Accepted with modifications. Providing CRSs as EPSG URIs is only a recommendation. But the examples could still be revised.


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/

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




Type of comment1


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.

Comment is not entirely clear.Discuss with MIWP-8 whether a recommendation can be added.

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. Not quite clear what section and requirement this comment refers to (TG req. C.17??). Clarify with DK.This comment refers to TG Requirement A.15 on page 31.Is there a possibility to remain backwards-compatible for this point?

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. Not quite clear what section and requirement this comment refers to (TG req. C.17??). Clarify with DK.This comment refers to TG Requirement A.17 on page 32.Is there a possibility to remain backwards-compatible for this point?

DK- 2.3.8 Para 1 ed/te We do not understand the following sentence: “Defining the geographic containing boundary of

Reformulate and clarify what is the intent with this 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


18 the described resource enables the users to discover interesting resources using their area or location of interest”.

sentence. Ok

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

Review the redaction Accepted. Reword 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.

Comment is not entirely clear.Discuss with MIWP-8 whether a recommendation can be added.

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

Accepted. Double-check.

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>

Revisit req. C.13 with MIWP-8.According to the schema, both options are valid.Maybe the wording of the requirement just needs to be made more clear.

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.

Does the new text not reflect the agreement reached in MIWP-8?





Type of comment1


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.Discuss whether/how to add the new proposed code lists to the INSPIRE registry.

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)

Proposal not clear. Discuss with MIWP-8 and/or request clarification from AT.

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.Disucss with MIWP-8.

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. Remove “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 interpreted...”

Delete “is” Accepted.

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 Why? Check with DE.

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. Not quite clear what section and requirement this comment refers to (TG req. C.21??). Clarify with DK.This comment refers to TG Requirement A.19 on page 36 – it says that “conformity with each INSPIRE Implementing Rule, specification document, its Requirements Class or similar part...” – so will that mean that a list of conformity





Type of comment1


evaluation to each mentioned document is provided as a list?A sentence could be added to clarify that the compliance with the relevant IRs is mandatory, but that also compliance with other specs (incl. specific conformance classes) can be provided.

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.

Not quite clear what section and requirement this comment refers to (TG req. C.22??). Clarify with DK.This comment refers to TG Requirement A.20 on page 37 “The title shall be given using the gmd:title/gco:CharacterString (...) the value of the title element shall match exactly the official title of the cited document in the language of the metadata.” This req. “shall match exactly” may be hard to live up to in practice (typos etc.).Discuss how to use e.g. Anchors here.

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.It was agreed in the comment resolution web-conference (https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_comment_resolution_meeting_2016-03-16) that Peter would make a proposal and that would be integrated in the draft.Review changes to the draft at the MIWP-8 meeting.

FR 3.1.2.1 TG Requirement 1.3

te There is no interest to forbid RS_Identifier. Please put a star in the xpath instead. Discuss with MIWP-8 whether this is acceptable.

NL 3.1.2.1 Recommendation 1.2

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

What is the proposed change?

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.OkWho could provide a rationale?

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.


https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_comment_resolution_meeting_2016-03-16






Type of comment1


Does rec 1.2 need to be more specific?

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.

To be discussed. The IRs explicitly refer to GEMET.

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.

Clarify with DK whether this refers to TG recommendation 1.5:

If the spatial resolution is an interval, both bounding values of the interval should be given, either as equivalent scale or resolution distance, should be given as two instances of the gmd:spatialResolution/gmd:MD_Resolution element.This comment refers TG Recommendation 1.4 on page 44. The above resolution has the copy of the text but it refers to Recommendation 1.5. That is not correct – it is 1.4.Who could provide an example?

UK-7


te An illustrative example of use might be helpful. Provide an example. Clarify with UK whether this refers to TG recommendation 1.5:

If the spatial resolution is an interval, both bounding values of the interval should be given, either as equivalent scale or resolution distance, should be given as two instances of the gmd:spatialResolution/gmd:MD_Resolution element.Who could provide an example?

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. Reword 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. Replace “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

Accepted.Who could draft an example?


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.

encoded.

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. Clarify with DK whether this refers to TG recommendation 1.8:

If a data provider has a procedure for the quality management of their spatial data set (series) then the appropriate ISO data quality elements and measures should be used to evaluate and report (in the metadata) the results in addition to the Lineage metadata element.

This comment refers to TG Recommendation 1.7 on page 51.

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

Agreed.See discussion in https://themes.jrc.ec.europa.eu/discussion/view/64808/what-crss-to-document-in-metadata-when-serving-a-dataset-through-a-wfsTo be discussed with MIWP-8 how to reflect this in the document.

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.

Good point. What to include for data sets with an indirect spatial reference?

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] Comment not clear.Correct to “zero to more”.

AT 3.2.2.1. ge Mandatory “Spatial Representation Type” may Give an example how to deal with this metadata Good point. The ISO code list also includes “textTable” as a value. Should we add this as a


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


cause difficulties for data themes with statistical data (population, human health).

element for data themes such as population and demography.

possible value?

DE 4.

Requirem

ents

Classes

for Spatial

Data

Services

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

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

To be discussed whether to use a reference to the Citation of the legal act here or a reference to the code list managed in the INSPIRE registry (or a combination of the two).

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


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.


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.


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

Create a new INSPIRE Attribute (ISO extension) with following name: inspireServiceType.This new Attribute has to be filled with the code list

This is a new suggestion (to my knowledge). To be discussed in MIWP-8.


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









Type of comment1


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.

from Part D3.In the existing attribute ServiceType, we can describe the service with the technical name, for example OGC:WMS

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).Ok

AT 4.1.2.4 ge Altough the uuidref element is optional it is very confusing to use an URL in an element that by the element name expects anuuid as reference value.

Remove the optional uuidref element. Discuss section 4.1.2.4 (including addition proposed by DE) in detail in the Comment resolution workshop.

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

Discuss section 4.1.2.4 (including addition proposed by DE) in detail in the Comment resolution workshop.

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.


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 nestedMD_DataIdentificationobject and do not enforce the ISO compliance.

Give a practical example with more than one MD_DataIdentification object in a document to






Type of comment1


make the application of the XPointer id clearer.

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


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.


NL 4.1.2.4. Requirement 3.6AndRequirement 1.2

te I can not find a reason (legal or technical) that the URI should pointing to the gmd:MD_DataIdentification element in the requirement;..The xlink:href attributeof 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


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 Discuss section 4.1.2.4 (including addition

proposed by DE) in detail in the Comment

resolution workshop.

DE 4.1.2.4.

Linking to

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

Discuss section 4.1.2.4 (including addition

proposed by DE) in detail in the Comment


http://paikkatiedot.fi/so/1002001

http://paikkatiedot.fi/so/1002001




Type of comment1


provided

data sets

using

coupled

resource

proposal has been promised resolution workshop.

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 (to be double-checked).

DE 4.2.2.

Data

quality info

section

TG

Requirement

4.2

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

cited as well

change wording: citing IR 1089/2010 is mandatory Unclear why this IR should be added for NS.

DE 4.2.2.

Data

quality info

section

Example 4.1 ge example for citing IR 1089/2010 is missing maintain example Unclear why this IR should be added for NS.

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

To be discussed how a code list can be used here instead of or in addition to the proposed solution.

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 conformance is declared against [Regulation 1089/2010]. Or [Regulation 1312/2014] is seen as a separate regulation and conformance is declared against it.

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

JRC to check with legal service / Publication Office, what the appropriate reference should be.

DE 4.3.3.1.

Conformit

y to

INSPIRE

Implement

ation

Rules

question in

yellow

ge 1312/2014 is an amendment to 1089/2010.

Refering to 1089/2010 is sufficient and includes

the SDS issues.

no additional declaration JRC to check with legal service / Publication

Office, what the appropriate reference should be.





Type of comment1


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.

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.

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.

To be discussed in detail at the MIWP-8 meeting. Also check in the comments on this section in the SDS TG.

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. (At most, we could add a short definition of what an ATS is).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.In the context of the MIWP-5 work and the implementation of the INSPIRE test framework, the following patterns for ATS and test ids has been discussed:

http://inspire.ec.europa.eu/id/ats/<ats-id>/<version>

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

To be discussed.

DE Annex C.2 8.1 ge there's no example for useConstraints; We had this build up example for useConstraints Accepted. Include example from v055.1 Type of comment: ge = general te = technical ed = editorial

page 18 of 20

http://inspire.ec.europa.eu/id/ats/%3Cats-id%3E/%3Cversion

http://inspire.ec.europa.eu/id/ats/%3Cats-id%3E/%3Cversion




Type of comment1


Conditions

applying to

access and

use

shown in a much clearer way in a former draft

(based on 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.

NL Annex C.4 Part B 1 Category

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

Change ininvocable 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.

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.

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

Remove the codelist Accepted.





Type of comment1


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

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. Check with NL which code lists are missing.

NL Annex D D4 Quality of Service criteria code

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.

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.

Discuss whether/how to add the new proposed code lists to 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.


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

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

ies-svn.jrc.ec. web viewcountries: at, ch, cz, de, dk, es, fr, it, nl, se, uk. date: 2016-05-24....

Documents