meeting minutes/notes

• Erweitern
  title 2021-03-04: Kick-off meeting
  # tour de table: AT, DE, DK, EL, ES, FR, LT, NL, PL, SE, SK + JRC # scope of work > introducing elaboration/submission of an INSPIRE good practice no replacement(!), provide an alternative # data and service linking current approach complicated/partly ambiguous, duplicate information low accessibility to dataset # technical challenges starting from proposal in discussion paper action 2019.2 recap (use of "protocol" + "applicationProfile")  another open question should be: how to handle different constraints (licences) between dataset and services? # organization of work march: collect proposals for technical approaches april/may: evaluate pro/con of proposals may/june: draft TG proposal may/june: set up of showcase of discovery service july: present result at 66th MIG-T-meeting november: submit good practice at 14th MIG meeting = new development on geoportal, outcome of this sub-group relevant/important = discuss with Geonetwork team on implementing this new dataset-service linking = https://github.com/ec-jrc/ = next meeting - beginning of april

06.04.2021 > 2nd meeting

# recap of the process, status of work

• consensus-based simplified approach for data and service linkages
• an alternative to the current approach, to be used in parallel (!)
• status = 3 proposals submitted (at github)

# proposals for approach

• NL > description-element as anchor (accessPoint) 1:1; endPoint plus protocol-element (reference to mediatype) for more than one service
• required: clear definition of the meaning of accessPoint and endPoint
  • GetCapabilities is an endpoint
  • link to GetCapabilities > obligatory, to GetMap/Feature > only additionally

  • Just a comment:  In Germany we use the gmd:protocol to describe the type of the service ( WMS / WFS / WCS / WPS / ATOM / FILE) and the gmd:applicationProfil to specify the media type.

• still an open discussion: harmonized vs. as-if datasets
  • on the agenda of the next MIG-T meeting (15.04.2021, 16.04.2021): as-is vs. harmonised datasets and how to express this in the dataset metadata

# discussion

If you use the gmd-description element to referenced an access- or endPoint, which iso-element are you use to specify e.g. the EPSG code (which is supported by the service)?

... the EPSG information can be 'left' to the service capabilities

Which URL should referenced in the extendedCapabilities of the service? Right now it's the link to service metadata.

In principle, the idea is that the extended capabilitie section disappears, and there will be no service metadata at all if we use this simplified approach.

Is there a possibility to link to service-md in the standard getCap section (without extension) - could be useful

How should we handle the fact, if a user create a service on different datasets (the basic idea of open data)?

If a service works base on more than one dataset, each dataset metadata point to the same service and from service capabilities is access to metadata of all datasets which the service base on.

No, if there are different providers, the service will not be referenced in the dataset.

You are right, but it is issue of organization of national infrastructure, providers should talk together :)

Good point, but I think a bit wider ... the approach of open data is, that every one can share and use the available data ...

= further discussion to all points on GitHub (creating an issue per topic, help to converge on the final approach)

# next steps

• until 16.04.2021: collect proposals for technical approaches
• until 30.04.2021: draft a proposal for a consolidated approach
• until 07.05.2021: collect comments on the consolidated approach (see GitHub-space)
• between 10.05.2021 and 12.05.2021: finalize the consolidated approache at the third meeting

= next meeting: 11.05.2021