• No comments on the agenda

• JRC to draft minutes from sub-group meeting #5 20 Jun 2018 

General comments

• JRC to update the TG document based on the discussions in the meeting. 29 Jun 2018 

• Minor editorial changes will be accepted.
• A separate section (as currently proposed in section 6.7) should be included in the TG and discuss the preferred approach according to the MD TG v2.0. In all other requirements, a generic term (e.g. spatial data set identifier) should be used.
• Section 6.6. should state clearly the requirements of the IR and how each of them is mapped in the TG. Options 1 and 2 mainly refer to the requirement to provide service metadata as part of the response to a Get Download Service Metadata request. The other parameters still have to be provided as well.
• The table in section 6.6. should cover all 4 parts of the the Get Download Service Metadata response required in the IR. It could be split following the example provided in this Google spreadsheet.
• Any changes in the mapping in the table should consider the impact on existing implementations, which should be kept to a minimum.
• We should collect examples of how MS implementations have mapped their metadata to the relevant (extended) capability elements.
  • All members to provide some annotated examples of capability documents illustrating their national mappings 27 Jul 2018 

Table 19

• Coupled Resource
  
  • For consistency with the MD TG v2.0 (and option 1), the Coupled ResourceMD element should be provided in the same way as described in the MD TG v2.0, i.e. by reference, providing a "URI pointing to the gmd:MD_DataIdentification element of the metadata record of the provided the data set or data set series."
  • However, mapping the Coupled Resource MD element to the spatial data set identifier would actually be closer to the requirement in the IR ("this metadata element identifies, where relevant, the target spatial data set(s)

    of the service through their unique resource identifiers (URI)").

  • Ideally, the link (or spatial data set id) should be provided only once per data set, but this would probably require a specific element (to be added to the Extended Capabilities). Alternatively, wfs:FeatureTypeList/wfs:FeatureType/wfs:MetadataURL could be used for this, even if this means providing the link/id redundantly for each feature type.

• Keyword
  • Only ows:ServiceIdentification/ows:Keywords/ows:Keyword should be used.
• Conformity
  • see https://github.com/inspire-eu-validation/download-service/issues/86
  • For consistency with the MD TG v2.0 (and option 1), the recommendation from MD TG v2.0 should be repeated here.
• Metadata Language
  • This MD element should be mapped to inspire_common:ResponseLanguage since it refers to the language in which the metadata is provided.
• Languages parameter
  • This parameter should be provided through the inspire_common:ResponseLanguage and inspire_common:SupportedLanguages elements in the extended capabilities
• Spatial Data Sets Metadata parameters
  • The IR requirement to provide "the INSPIRE metadata elements of the available Spatial Data Sets" in the Get Download Service Metadata response should be mapped through a link to the relevant MD record, e.g. through the wfs:FeatureTypeList/wfs:FeatureType/wfs:MetadataURL (redundantly for each feature type).
  • This may create a clash with the proposed mapping of the Coupled Resource MD element (since this link should point to the gmd:MD_DataIdentification element and not to the whole MD record)

Spatial Data Set identifier

• There is no explicit requirement to provide the spatial data set identifier directly in the Get Download Service Metadata response, but this id is needed by clients in order to execute the Get/Describe Spatial Data Set operations.
• A recommendation should be added how to provide the id directly in the Capabilities.

Requirement 52 ("A separate WFS endpoint shall be provided for each INSPIRE dataset thus providing one dataset per GetCapabilities response.")

• It was unclear why requirement 52 has been introduced - JRC to check. 29 Jun 2018 

• If possible, the requirement should be changed into a recommendation, and the reason should be explained.