Comments and proposals on the open issues

Question

Comments and proposals on the open issues

AntoRot opened this issue 4 years ago · 10 comments

With reference to the consolidated proposal and the open issues pointed in the summary of the third meeting, please find below my comments and my proposals.

Service metadata

Keep the service metadata only for Spatial Data Services and for Network Services other than view and download. Concerning the need of the provision of conformity indicators see the proposal below.

Use of the `gmd:function` element

I would avoid the use of this element for the following reason:

If the resource locator elements should point to an "INSPIRE Get Download/View Service Metadata" request as pointed in the section "Data set metadata", then it would be unnecessary;
the value "download" for a Get Map request would be semantically inappropriate, as @MarieLambois also pointed out in her comment to the issue #10.

Resource locator

I think that the GetCapabilities request should be used as value of the linkage element, as pointed above.
Alternatively, another proposal for WMS could be as follows:

if the network service provides view access only to one data set and the layer has a <Name> property, then the resource locator may be the GetMap request with that Name as the value of LAYERS argument, otherwise, if no <Name> property is included, the GetCapabilities request;
if the network service provides view access to several data sets and each layer has a <Name> property, then:
- either the resource locator may be the GetMap request with that Name corresponding to the data set described by the metadata record as the value of LAYERS argument
- or the resource locator may be the GetCapabilities request with the gmd:name element in the metadata record encoded with the value of the layer property <Name>;
if the network service provides view access to several data sets and no layer has a <Name> property, then the resource locator may be the GetCapabilities request.

A similar proposal could be defined for the other network services.

Conformity declaration

I disagree with the implicit conformity declaration as the spatial data service type is a mandatory element for the Metadata Regulation and consequently shall be documented regardless the conformity to be instead declared using other metadata elements.
If service metadata can be automatically generated from the service, my proposal is to move that declaration in the GetCapabilities document by adding a specific keyword encoded with the values coming from the code list "Degree of conformity" published in the INSPIRE metadata code list register. Here the examples about this proposal:

For WMS, add a wms:Keyword element with a value coming from the code list mentioned above and the attribute vocabulary pointing to the code list URI within the wms:KeyworList group

...
<wms:KeywordList>
   <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity”>conformant</wms:Keyword>
...
</wms:KeywordList>

For WFS, add a specific group ows:Keywords with a ows:Keyword element with a value coming from the code list mentioned above and a ows:Type element including the code list label and the attribute codeSpace pointing to the code list URI:

...
<ows:Keywords>
   <ows:Keyword>conformant</ows:Keyword>
   <ows:Type codeSpace="http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">Degree of conformity</ows:Type>
</ows:Keywords>
...

For Atom, add a atom:category element including the term attribute with a value coming from the code list mentioned above and the scheme attribute pointing to the code list URI:

...
<atom:category term="conformant" scheme="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity"/>
...

To further simplify, we could consider only the value of the keyword without any pointing to the reference code list.

Protocol code list extension

I am also wondering whether, once agreed on the need for the extension, it is worth adding the codes related to other types of protocols such as REST API or OGC API Features.

Extended capabilities

I think that extended capabilities should be dismissed. Otherwise, if we keep both service metadata and extended capabilities, what would the simplification be?
The table below shows how the information included in the extended capabilities could retrieved alternatively.

Extended capabilities	Simplification	Service type
inspire_common:ResourceType	By default = service	WMS - WFS
inspire_common:ResourceLocator	Resource locator in the data set metadata	WMS - WFS
inspire_common:SpatialDataServiceType	Moved to the applicationProfile in the data set metadata	WMS - WFS
inspire_common:TemporalReference	Consider the temporalReference in the data set metadata?	WMS - WFS
inspire_common:Conformity	Declared through the wms:keyword element	WMS - WFS
inspire_common:MetadataPointOfContact	Consider the metadataPointOfContact in the data set metadata	WMS - WFS
inspire_common:MetadataDate	Consider the metadataDate in the data set metadata	WMS - WFS
inspire_common:SupportedLanguages	Consider the metadataLanguage in the data set metadata	WMS - WFS
inspire_dls:SpatialDataSetIdentifier/inspire_common:Code - inspire_dls:SpatialDataSetIdentifier/inspire_common:Namespace	Data set identifier in the data set metadata	WFS

Just for information, recently the GeoNetwork Italian plugin (i.e. the plugin aligned to the latest national metadata profile) for the version 3.10.x was released also including the management of the metadata elements for the simplification approach agreed under the 2019.2 action. I think that we should agree on a solution that takes into account existing initiatives and deviates as little as possible from current implementations.

Answer 1 · 2021-07-09T11:25:39.000Z

@AntoRot thank you for providing your opinions.
In fact, quite a lot, so I will do my best to quote and give my opinion on each of them.

Service metadata

I agree, if the service metadata cannot be automatically generated, or proven to be difficult to create/maintain for those services. As you mentioned, at least we should guarantee the reachability of those services that are not covered by a dataset metadata and by this simplification approach, once in place.

Use of the gmd:function element

Regarding the use of this element, it was driven by a pure technical point of view. The ResouceLocator section, as now, accepts multiplicity 0...n. I proposed this in order to enforce the distinction among a potentially infinite number of other ResourceLocators (eg. it will immediately find the WFS GetCapabilities URL via a appProfile:download+protocol:ogc+function:information triplet). Think if the LinkageChecker founds multiple ResourceLocator with a applicationProfile:download: it will be forced to test them all. Otherwise, we should put a TG Requirement where the applicationProfile:download and applicationProfile:view will appear only once for that dataset MD.
Regarding the values itself, you can find my reply to @MarieLambois here

Resource Locator

I think it's a good idea, and I feel it probably matches the content of the issue #14 posted by @pvgenuchten . Maybe I would suggest you to copy&paste the above content right there, as dedicated discussion.

Conformity declaration

I reviewed my point of view on this, and I partially agree with you. The implicit declaration is a convoluted and risky approach, so it's a no-go! It would also complicate the assessment of a service conformity, expecially during the M&R task.
Regarding your proposal of using ***:keywords instead of the current inspire_common:Conformity inside the ExtendedCapabilities: you are missing the possibility of multiple conformity declarations. We already know some country's services that have this kind of scenario. How can the service owner be able to declare the degree of conformities both to a national regulation and to the INSPIRE regulation 976/2009?

Protocol code list extension

We already shared our points of view here: #8

Extended capabilities

Very interesting proposal, but I think we cannot remove entirely the ExtendedCapabilities. I would rather keep some mandatory fields (ie. see above my point on the Conformity) and deprecate some other as recommended fields (ie. ResourceType, TemporalReference). But, let's move this away from here, into a dedicated discussion!

Answer 2 · 2021-07-13T10:50:26.000Z

Dear @dartasensi

Please find below my comments to some of your opinions in order to further contribute to the discussion.

Use of the gmd:function element
Regarding the use of this element, it was driven by a pure technical point of view. The ResouceLocator section, as now, accepts multiplicity 0...n. I proposed this in order to enforce the distinction among a potentially infinite number of other ResourceLocators

Given that discarding the use of function for this purpose as in the latest revision of the consolidated proposal is the preferred option, I think that an alternative proposal (that could overcome the semantic issues) could be to use the gmd:description element to distinguish between Get View/Download Service Metadata (GetCapabilities) and Get Map / Get Spatial Data Set (GetMap/GetFeature). For the former the gmd:description element should be encoded with the value "accessPoint" of the code list OnLineDescriptionCode in the INSPIRE Registry, whereas for the latter it should be encoded with the value "endPoint" of that code list.

As pointed out in the consolidated proposal, the only requirement for that metadata element is TG Requirement 5.2 that only affects the invocable services. Consequently, no requirement exists for that metadata element in case of Network Services.

In this way, as per your example, appProfile:download+protocol:ogc+description:accessPoint triplet would let to easily identify the WFS GetCapabilities.

Resource Locator
I think it's a good idea, and I feel it probably matches the content of the issue #14 posted by @pvgenuchten . Maybe I would suggest you to copy&paste the above content right there, as dedicated discussion.

I copied&pasted the proposal as comment to that issue.

Conformity declaration
Regarding your proposal of using ***:keywords instead of the current inspire_common:Conformity inside the ExtendedCapabilities: you are missing the possibility of multiple conformity declarations. We already know some country's services that have this kind of scenario. How can the service owner be able to declare the degree of conformities both to a national regulation and to the INSPIRE regulation 976/2009?

As the conformity of network services is checked against the INSPIRE regulation 976/2009 in M&R, my proposal refers to that Regulation.

About this, I see an inconsistency between the EC Decision about the M&R and the metadata TG. In the metadata TG the conformity to Regulation 976/2009 is indeed only a recommendation whereas in the M&R the conformity of NS is measured just against that Regulation. I suppose this is one of the reason, e.g., for the low values of the indicators of the NS conformity for Italy. But this issue is out of the scope for this subgroup.

The declaration of the conformity to national regulation and/or other specifications and CC is only a recommendation and not a requirement. For this reason, I think that the ExtendedCapabilities section could be optional and to be used by those countries/service providers that want to document additional conformity details.

Extended capabilities
Very interesting proposal, but I think we cannot remove entirely the ExtendedCapabilities.

I'm aware that the objectives of the work of this subgroup should be (i) to remove the need for extensions of the OGC base standard for view and download services and (ii) no longer to document those services in stand-alone (ISO 19119) service metadata records, as pointed in the Discussion Paper defined and discussed under the 2019.2 action.

For this reason, I think again that the ExtendedCapabilities should be dismissed or, as proposed above, kept as an optional section to be used if the service provider wants to add further details.

Answer 3 · 2021-07-15T15:44:02.000Z

I agree with @AntoRot use the gmd:description element to distinguish between Get View/Download Service Metadata (GetCapabilities) and Get Map / Get Spatial Data Set (GetMap/GetFeature). for the interpretation of what endpoint / accesspoint se the discussion in #7

If this distinction not is made and also the function element not used, it is not possible to filter the required getMetadata request of the view and download. The use of the function element have his issues, se #10

Alternative can be that the resource locator elements should only point to an "INSPIRE Get Download/View Service Metadata" request , then it would be unnecessary, but from point of usage, the reference to the endpoints are valuable. NL discussion on this point is the value of the protocol element for the endpoints, we are using the mediatypes codlist.

Answer 4 · 2021-07-15T15:46:25.000Z

I agree alsowith @AntoRot that thatExtendedCapabilities should be dismissed or, as proposed above, kept as an optional section to be used if the service provider wants to add further details.

Answer 5 · 2021-09-16T13:00:31.000Z

Hello,

As I said in #9, I think we cannot remove entirely the ExtendedCapabilities.

I agree with @dartasensi. I would deprecate some recommended fields (ie. ResourceType, TemporalReference and so on) and rather keep the following elements:

<inspire_common:Conformity> I think is important to specify which Regulation the service applies. I think saying only that is Conformant in a keyword doesn't mean anything.

...
<wms:KeywordList>
   <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity”>conformant</wms:Keyword>
...
</wms:KeywordList>

In the case that we decide to keep the Conformity in a Keyword I think it is important to specify the Regulation.

<inspire_common:SupportedLanguage> In my opinion this element is very useful to know in which languages you can see the GetCapabilitites. It is something about the service itself, so I dont think it is a good idea to write that in the dataset metadata file.

Here, there is an example:
https://www.ign.es/wms-inspire/pnoa-ma?request=GetCapabilities&service=WMS

<inspire_vs:ExtendedCapabilities>
...
<inspire_common:DefaultLanguage>
<inspire_common:Language>spa</inspire_common:Language>
</inspire_common:DefaultLanguage>
<inspire_common:SupportedLanguage>
<inspire_common:Language>eng</inspire_common:Language>
</inspire_common:SupportedLanguage>
</inspire_common:SupportedLanguages>
<inspire_common:ResponseLanguage>
<inspire_common:Language>spa</inspire_common:Language>
</inspire_common:ResponseLanguage>
</inspire_vs:ExtendedCapabilities>

Answer 6 · 2021-10-12T14:37:31.000Z

For the conformity part it could be more precise such as:
<wms:KeywordList> <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/LevelOfConformity”>COMMISSION REGULATION (EC) No 976/2009</wms:Keyword> ... </wms:KeywordList>

For the language I see 2 options:
1 - You only use the extended capabilities if you support several languages
2 - Could also use keywords:
<wms:KeywordList> <wms:Keyword vocabulary=”http://www.loc.gov/standards/iso639-2/”>eng</wms:Keyword> ... </wms:KeywordList>

Answer 7 · 2021-10-12T15:56:04.000Z

Dear all,

thank you for your effort in providing feedback on this specific topic, but as presented at the last MIG-T, our idea is to consider "out of scope" of the current work the proposal to remove the ExtendedCapabilities.

We think it requires extra work and a lot of changes in the relevant IRs and TGs, therefore it would be better to deal with it in a dedicated action.

Answer 8 · 2021-10-12T17:02:21.000Z

Dear @fabiovin,

our idea is to consider "out of scope" of the current work the proposal to remove the ExtendedCapabilities.

this is a surprise, because it wasn't shared and agreed in this sub-group. Indeed it is one of the main and basic point in the Discussion Paper and this new decision contradicts the conclusions and recommendations from the 52nd MIG-T meeting included in the Discussion Paper itself.

I took a look to the summaries of the sub-group meetings and JRC declared what follows:

JRC confirmed that both points (removing of the service metadata and extended capabilities) are the main idea of the simplification in order to remove duplication and the need for software extensions, among others.

JRC commented on extended capabilities:

possible conflict between extended capabilities and ISO elements,

almost zero client support for extended capabilities,

a possible solution could be an optional/conditional requirement class, i.e. the extended capabilities could be used only under specific conditions.

I'm wondering what and where is the simplification if we reduce it only in removing service metadata (just view and download, by the way). It would be enough to revise requirements and recommendations about some metadata elements (protocol, applicationProfile, ...), but I wouldn't name it simplification.

Regards,
Antonio

Answer 9 · 2021-10-14T09:41:02.000Z

Hello,

We agree on the proposal of @MarieLambois and use the keywords instead of using the <inspire_vs:ExtendedCapabilities>.

Regards,
Laura

Answer 10 · 2022-10-03T21:17:22.000Z

The issues were discussed, some proposals accepted and now it can be closed.