GitHub - page >  INSPIRE-MIF / gp-data-service-linking-simplification

tasks

  • proposal for technical approach


meeting minutes/notes

  • # 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")

    (Frage) 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

  • # 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 (, ): as-is vs. harmonised datasets and how to express this in the dataset metadata

    # discussion

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

    (Haken) ... the EPSG information can be 'left' to the service capabilities

    (Frage) Which URL should reference in the extendedCapabilities of the service? Right now it's the link to service metadata.

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

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

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

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

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

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

    (Info) 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 : collect proposals for technical approaches
    • until : draft a proposal for a consolidated approach
    • until : collect comments on the consolidated approach (see GitHub-space)
    • between  and : finalize the consolidated approach at the third meeting

    = next meeting:

> 3rd meeting

# round de table > new member (nomination from IT)

# proposal for the consolidated approach

  • additional proposal by IT
  • still keep the service metadata > necessary for the inspire monitoring (calculation of the indicator)

# discussion

(Frage) Did I understand you correctly, you still need the service metadata records to calculate the NSi4 indicators, right?

(Info) I thought there is created an option in the indicators to calculate them without service metadata see the description of NS4;

(Haken)  For this indicator only discovery, view, download and transformation network services will be taken into account. The identification of the type of network services will be done based on the "spatial data service type" metadata element when service metadata is provided, based on the definition of the service access points if these service access points are defined in data set metadata and based on the registered service endpoints for discovery network services. The conformity with Regulation (EU) No 976/2009 should be expressed in the "Conformity" metadata element. The Commission will provide a code list with possible conformity statements in the INSPIRE Register.

(Info) Having the service metadata only for the indicator is too much work for no benefit, there is no way I can explain that to the data producer. We need to find another option. Maybe the description field as an Anchor.

(Info) Can we not agree that all services added with the INSPIRE value of SpatialDataServiceType are conformant?

(Info) Could the conformity field eventually be in the dataset metadata in the getResource for each service ?

(Info) But there are still requirements on layernames and stored queries, isn't it ?

(Frage) What is the value of the service = compatible flag in the service md, if there is no extendedCap anymore?

(Info) Would it be possible to add a conformance report on view service and download service within the dataset-metadata ?

= new issue and further discussion on GitHub

  • conformity-statement is need > extend capabilities? no real good mapping between the elements in the TG
  • keep the service metadata records for SDS, but find a solution for NS
  • declare the conformity over the inspire-codelist (true = use the codelist, false = use another codelist) → needed a really good documentation !
  • reasoning for not extending the ProtocolValue → Add some new items in the Protocol Value register #17
  • reduce the duplicates between capabilities and service metadata → extended capabilities not available in the standard (optional)

# next steps

  • NL: make a showcase, is also a discovery service needed or only metadata
  • continued discussion on GitHub (within the week - approach the consolidated approach) + showcase implementation too

= next meeting