Übersicht:
Favoritenliste:
Favoritenseiten
Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren. |
Erweitern | ||
---|---|---|
| ||
# tour de table: AT, DE, DK, EL, ES, FR, LT, NL, PL, SE, SK + JRC # scope of work > introducing
# data and service linking
# technical challenges
another open question should be: how to handle different constraints (licences) between dataset and services? # organization of work
= new development on geoportal, outcome of this sub-group relevant/important |
Erweitern | ||
---|---|---|
| ||
# recap of the process, status of work
# proposals for approach
# discussion If you use the gmd-description element to referenced reference an access- or endPoint, which iso-element are you use used 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 reference 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
= next meeting: |
> 3rd meeting
# round de table > new member (nomination from IT)
# proposal for the consolidated approach
# discussion
Did I understand you correctly, you still need the service metadata records to calculate the NSi4 indicators, right?
I thought there is created an option in the indicators to calculat calculate them without service metadata see the discription description of NS4;
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.
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.
Can we not agree that all services added with the INSPIRE value of SpatialDataServiceType are conformant?
Could the conformity field eventually be in the dataset metadata in the getResource for each service ?
But there are still requirements on layernames and stored queries, isn't it ?
What ist is the value of the servce service = compatible flag in the service md, if there is no extendedCap anymore?
Would it be possible to add a conformance report on view service and download service within the dataset-metadata ?
= new issue and futher further discussion on GitHub
# next steps
= next meeting