Part B - Remapping of Extended Capabilities - About conformity issue

Question

Part B - Remapping of Extended Capabilities - About conformity issue

AntoRot opened this issue 3 years ago · 19 comments

This issue is aimed at summarizing the proposals about the mapping of the <inspire_common:Conformity> element starting from the Annex B in the consolidated proposal, in order to add further specific comments and to reach a consensus by the sub-group.

As pointed out in the Implementation Requirement 22 in INSPIRE NS - View Service TG, the INSPIRE Metadata Regulation requires that metadata shall include information on the degree of conformity with the implementing rules on interoperability of services. For this purpose, the <inspire_common:Conformity> element shall be added within an <inspire_vs:ExtendedCapabilities> (see Implementation Requirement 23 in INSPIRE NS - View Service TG) or an <inspire_dls:ExtendedCapabilities> (see TG Requirement 53 in INSPIRE NS - Download Service TG) element.
As the common opinion in the sub-group is that the extended capabilities should be removed, we need to find an element in the service metadata to use instead of the <inspire_common:Conformity> element, keeping the conformance to metadata Regulation.

Proposal from IT (me)

Having as reference the Regulation 1089/2010 (against which it is mandatory to declare the conformance based on Metadata TG), the proposal is adding a specific keyword encoded with the values coming from the code list "Degree of conformity" published in the INSPIRE metadata code list register.
With respect to other specifications (e.g. Regulation 976/2009), each service provider is free to add an extended capabilities section (that is kept as optional) including the <inspire_common:Conformity> element.
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"/>
...

Proposals from FR (@MarieLambois)

adding a specific keyword encoded with the values coming from the Spatial data service type code list to declare the conformity (see the specific comment in the issue 12.
Example:

...
   <wms:Keyword vocabulary="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType">view</wms:Keyword>
...

Alternatively, adding a specific keyword to cite the Regulation applied for the conformity declaration (see the specific comment in the issue 13).
Example:

...
<wms:KeywordList>
   <wms:Keyword vocabulary=”https://inspire.ec.europa.eu/metadata-codelist/LevelOfConformity”>COMMISSION REGULATION (EC) No 976/2009</wms:Keyword>
...
</wms:KeywordList>

Answer 1 · 2022-01-09T22:28:44.000Z

My final proposal is to use the keyword element in the GetCapabilities document encoded with the title of the specification against which the service is conformant.

Examples:

For WMS , add a wms:Keyword element within the wms:KeyworList group for each specification against the service is conformant

...
<wms:KeywordList>
   <wms:Keyword>COMMISSION REGULATION (EU) No 1089/2010</wms:Keyword>
  <wms:Keyword>COMMISSION REGULATION (EC) No 976/2009</wms:Keyword>
...
</wms:KeywordList>

Instead of the title, it would be better to use the related URI, as follows

...
<wms:KeywordList>
   <wms:Keyword>http://data.europa.eu/eli/reg/2010/1089</wms:Keyword>
  <wms:Keyword>http://data.europa.eu/eli/reg/2009/976</wms:Keyword>
...
</wms:KeywordList>

For WFS, add a specific group ows:Keywords with a ows:Keyword element for each specification against the service is conformant and a ows:Type element :

...
<ows:Keywords>
   <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
<ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
   <ows:Type>URI</ows:Type>
</ows:Keywords>
...

For Atom, add a atom:category element for each specification against which the service is conformant:

...
<atom:category term="http://data.europa.eu/eli/reg/2010/1089"/>
<atom:category term="http://data.europa.eu/eli/reg/2009/976"/>
...

If the Regulations 1089/2010 and 976/2009 will be added in the INSPIRE reference document register, then the vocabulary attribute could be added in the wms:Keyword element (in case of WMS) and the scheme attribute in the atom:category (in case of Atom) both pointing to the register URI.

To be noticed that in the INSPIRE NS - Download Service TG, in the table at page 67 there is a note for the inspire_common:Conformity element stating that the conformity refers to data specifications. See:

If so, there would be no need to declare the conformity of the service in the GetCapabilities document as the conformity of the dataset against data specifications is already declared in the dataset metadata.

Answer 2 · 2022-01-10T09:15:25.000Z

I agree with your finalproposal. Indeed vocabulary would help automated parsing , but if the characterstring is firmly fixed, the parsing is possible anyway.
The note in the table that you mention is confusing. I am not sur what was meant.

Answer 3 · 2022-01-25T13:00:33.000Z

I should use a vocabulary, to avoid problems with parsing if the document name is translated to the metadata language...

Answer 4 · 2022-01-25T21:03:24.000Z

Just adding input to the discussion in this comment, currently I don't have an opinion on which approach would be best.

My final proposal is to use the keyword element in the GetCapabilities document encoded with the title of the specification against which the service is conformant.

If no keyword with a specification is present, would degree of conformity then be "non-conformant" or "not evaluated"?

How about adding a keyword for the degree of conformity as well?

👍🏻 The metadata would clearly comply with the IR metadata, requiring that both specification and degree of conformity are stated
👎🏻 That would imply that only one conformity statement could be given for WMS, Atom and perhaps WFS (option 2, see below), as otherwise it would not be possible to determine which degree of conformity element goes together with which specification.

WMS example:

  <KeywordList>
    <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2009/976</Keyword>
    <Keyword vocabulary="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</Keyword>
  </KeywordList>

Atom example:

  <entry>
    <category scheme="http://data.europa.eu/eli" term="http://data.europa.eu/eli/reg/2009/976" />
    <category scheme="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity" term="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant" />
  </entry>

WFS example option 1:

      <ows:Keywords>
         <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
         <ows:Keyword>https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</ows:Keyword>
         <ows:Type codeSpace="https://inspire.ec.europa.eu/registry">conformity statement element</ows:Type>
      </ows:Keywords>
     <!-- multiple `<ows:Keywords>` like these could be added, allowing for multiple conformity statements -->

WFS example option 2:

      <ows:Keywords>
         <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
         <ows:Type codeSpace="http://data.europa.eu/eli">EU legal document</ows:Type>
         <!-- or codespace http://inspire.ec.europa.eu/document, if the legislation is reference from the INSPIRE reference document register -->
      </ows:Keywords>
      <ows:Keywords>
         <ows:Keyword>https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</ows:Keyword>
         <ows:Type codeSpace="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">degree of conformity</ows:Type>
      </ows:Keywords>
     <!--having multiple conformity statements is not possible, but the codeSpace can point to a subregister in the INSPIRE registry instead of to the registry itself -->

Regarding the text in ows:Type, its meaning is the same as MD_Identification.keywords.type from ISO 19115/ISO 19119 – see the table below from the OGC Web Services Common Specification – which is "Method used to group similar keywords" (ISO 19115:2003) or "subject matter used to group similar keywords" (ISO 19115-1:2014), and its domain value is a code list with some example values on this diagram from the ISO/TC 211 harmonized model.

So that text could in our case be e.g. "EU legal document", "EU legal document", "degree of conformity", see examples above. It should not be "URI". I noticed that the examples in http://schemas.opengis.net/wfs/2.0/examples/GetCapabilities/ use <ows:Type>String</ows:Type>, but that seems to be a mistake...

To be noticed that in the INSPIRE NS - Download Service TG, in the table at page 67 there is a note for the inspire_common:Conformity element stating that the conformity refers to data specifications. See:

This seems to contradict with the TG metadata:

In this specification the above Implementing Rule text is interpreted to mean that the conformity shall be declared at least to the following regulations depending on the described INSPIRE resource type:

Data sets and data set series shall declare conformity to [Regulation 1089/2010].

Network Services should declare conformity to [Regulation 976/2009].

Invocable Spatial Data Services (including interoperable and harmonised Spatial Data Services) shall declare conformity to [Regulation 1089/2010].

Answer 5 · 2022-01-26T00:16:01.000Z

My proposal implied that if no keyword with a specification is present, it does not matter whether it is "not-conformant" or "not evaluated" because for the purposes of INSPIRE monitoring the two options to be considered are conformant and "not-conformant".

About @heidivanparys proposal, I think that it could be OK for WFS (namely the option 2) as the ows:Keywords group has a multiplicity 0..* and consequently we can use for each specification a ows:Keywords group including a keyword for the specification and another one for the conformity degree as in the following example (revised with respect to that one provided by @heidivanparys):

<ows:Keywords>
  <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
  <ows:Keyword>http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</ows:Keyword>
</ows:Keywords>
<ows:Keywords>
  <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
  <ows:Keyword>http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/notEvaluated</ows:Keyword>
</ows:Keywords>

About the ows:Type element, I used "URI" as its value, based on the example <ows:Type>String</ows:Type> given in the OGC WFS specification, but @heidivanparys said

that seems to be a mistake...

I have no elements to say that value is a mistake. If so, I think that also "EU legal document", "EU legal document", "degree of conformity" could be a mistake (e.g. because those values don't come from the code list MD_KeywordTypeCode seen the mapping in the mentioned table D.5).

In any case as the ows:Type element is optional and doesn't provide any added value in my opinion, it can be omitted.

In case of WMS, as the wms:KeywordList element has a multiplicity 0..1, it's not possible to use an instance of that element for each specification and consequently in case of declaration of conformity to more specifications, we won't be sure what specification the conformity degree refers to.

Example:

  <KeywordList>
    <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2009/976</Keyword>
    <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2010/1089</Keyword>
   <Keyword vocabulary="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</Keyword>
   <Keyword vocabulary="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/notEvaluated</Keyword>
  </KeywordList>

Maybe an additional requirement about the respect of the sequence of the couple of keywords (i.e. a keyword referring to specification followed by a keyword referring to the conformity degree) could be useful.

A similar reasoning also applies to Atom.

Answer 6 · 2022-01-26T12:53:02.000Z

We (the SDI of Spain) like it better the way this is in the extended capabilities nowadays, but if the goal is to remove the extended Capabilities we agree on adding a specific keyword with the approach that @AntoRot gives in the examples of the last entry:

For WFS:

<ows:Keywords>
  <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
  <ows:Keyword>http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</ows:Keyword>
</ows:Keywords>
<ows:Keywords>
  <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
  <ows:Keyword>http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/notEvaluated</ows:Keyword>
</ows:Keywords>

For WMS , with the additional requirement regarding the sequence of the keywords.
I change it a little bit the sequence because I think it is more intuitive:

  <KeywordList>
    <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2009/976</Keyword>
    <Keyword vocabulary="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant</Keyword>
    <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2010/1089</Keyword>
    <Keyword vocabulary="https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity">https://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/notEvaluated</Keyword>
  </KeywordList>

Answer 7 · 2022-01-26T19:08:05.000Z

@LauraAlemany,

About the example on WMS, I intentionally put the keywords in a wrong order to let understand that it could be confusing without the proposed additional requirement.

The example you provided is that one with the correct sequence of keywords ;)

Answer 8 · 2022-01-28T11:05:34.000Z

Hello, I would like to add as @LauraAlemany says I think it is better to use the Extended Capabilities (Scenario 2) but we think it is a good discussion and we will keep participating in it.

I think that using keywords as auxiliary elements is not optimal. You can use keywords for everything also for including the conformity, but they are not mean for this.
In the dataset metadata, when it was planned to include the spatial scope and priority data, a first idea was to include them as keywords, but then it was analysed that it was better to include them with a controlled vocabulary.
The keywords describe the service as a whole entity and the purpose is to help catalogue searching. In short, the choice to include conformity in the keywords will lead to errors. For the same reason, the attribution or the point of contact is not included in the keywords and has its specific elements within the capabilities file.

For us the work for making the Extended Capabilities (in Scenario 2, without the metadata file) is more or less the same amount of work as completing the capabilities with the information outside the extended capabilities.

Answer 9 · 2022-02-24T11:42:59.000Z

Perhaps in the proposal below is an alternative that mitigates the above negative effects;

We make a new code list containing the INSPIRE specifications against which conformity must be specified, together with the degree of conformity. So each specification appears twice as value, once conforming and once not conforming..
This code list contains a URI and a label, so that it is easily readable by machine and by humans, so that it also provides meaningful information to users.

something like;
<KeywordList>
<Keyword vocabulary="https://inspire.ec.europa.eu/metadata-codelist/SpecificationDegreeOfConformity/2009/976-conformant">Conform INSPIRE network specification</Keyword>
</KeywordList>

I will try to make better examples

Answer 10 · 2022-02-24T19:03:34.000Z

In the examples in the previous comments, the ELI URIs have been used. These URIs (already available) uniquely identify the legislation.
But, as an INSPIRE reference document register already exists, we can alternately propose to add new items corresponding to the legal acts and guidelines we need.
That register is the appropriate location as its definition reads "This register provides unique identifiers for documents or parts of documents (e.g. chapters or tables) used in INSPIRE. These may include the INSPIRE legal acts, technical guidelines and other documents".

Answer 11 · 2022-02-25T08:02:31.000Z

I think it is unnecessary to mention the conformity level. We can just state that if the specification is mentioned it means it is compliant to this specification. So I think
<wms:KeywordList> <wms:Keyword>http://data.europa.eu/eli/reg/2010/1089</wms:Keyword> <wms:Keyword>http://data.europa.eu/eli/reg/2009/976</wms:Keyword> ... </wms:KeywordList>
or other options as listed by @heidivanparys for other kind of services is enougth. (and possibly refering also to the INSPIRE refernce document register for TGs as @AntoRot )
Nobody list in the metadata all the specification it is not compliant to that does not make sense. So I would say that it is by default set to true.

Answer 12 · 2022-02-25T08:36:53.000Z

This was my initial proposal (see comments #39 (comment) and #39 (comment)).
Consequently I agree with @MarieLambois.
But if the group will decide to also consider the degree of conformity, I think that this information should be documented separately from the specification as coming from two different vocabularies.

Answer 13 · 2022-02-25T12:00:58.000Z

As @abadppa0 said, keywords are initially foreseen for filtering resources, but since the declaration of conformity metadata element is mandatory i currently needed in the context of the M&R, I cannot see the issue in taking advantage of the keyword section in the Capabilities documents for making the declaration possible - Specially taking into account that this would only need an ad-hoc routine in the INSPIRE Geoportal in order to properly read this self-declaration. In principle, no more impact shall be expected.

NOTE 1: The possibility to avoid the use of the Extended Capabilities is not originated by the aim to reduce the effort on reporting the metadata elements, but allowing data providers choosing SW solutions in the market that might not be supporting the Extended Capabilities.

NOTE 2: Use of Extended Capabilities will remain possible. Data providers willing to continue using this option, should only use SW solutions supporting this feature.

My preference would be to follow the suggestion stated by @LauraAlemany, which in fact have been developed in a collaborative way between most of the participants in this thread.

Answer 14 · 2022-03-29T12:13:37.000Z

2022-02-25 Discussion:
Based on the discussion hold in the 2nd meeting for the 'Remapping of the extended capabilities', corresponding to Part B of the work of MIWP Sub-group on Action 2.3.2 'Simplification of Data and Service Linking', it was agreed to map this element to a specific keyword in the service Capabilities document or ATOM Feed document, based on this proposal - elaborated in collaboration of all members of sub-group on Action 2.3.2 attending the meeting, but further simplified (and user friendly), by considering the 'conformant' value as default when the keyword agreed for declaring a specific Regulation is present.
In other words, if an agreed reference to a specification is present as a keyword, this implies that the service is compliant to this specification, avoiding the need to add a second keyword stating the conformity value.

Proposed mapping and rationale

The conformity of the service to a specification is mapped to an specific keyword element, referencing an interoperable URI which represents this specification. This keyword shall be present in the service Capabilities document or ATOM Feed document in order to consider the value of the degree of conformity as conformant:

For WMS: wms:Keyword element for each specification against the service is conformant, included within an specific wms:KeyworList group.
For WFS: ows:Keyword element for each specification against the service is conformant, included within an specific ows:Keywords group including an ows:Type element of type URI.
For Atom: atom:category element for each specification against which the service is conformant.

If a specific keyword referencing the interoperable URI representing a specification is not present, the value of the degree of conformity of the service to this specification will NOT be considered conformant (i.e. non-conformant or not evaluated) - Therefore, differentiation between non-conformant and not evaluated will not be possible when using the simplified approach for data and service linking.

This approach is considered enough for the INSPIRE Geoportal to identify which services are conformant to an specific INSPIRE regulation (specification).

Detailed mapping description

In order to reference a specific INSPIRE regulation as specification to which a spatial data service may declare its conformity, its URL of publication in EUR-Lex shall be used as a common interoperable URI value:

Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services - URI: http://data.europa.eu/eli/reg/2009/976
Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services - URI: http://data.europa.eu/eli/reg/2010/1089

According to the mapping proposed and the mentioned interoperable URIs, the XML snippets below are proposed as examples to show the detailed mapping of the conformity element.

For WMS 1.3, the related XML schema snippet is:

    <KeywordList>
        <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2009/976</Keyword>
        <Keyword vocabulary="http://data.europa.eu/eli">http://data.europa.eu/eli/reg/2010/1089</Keyword>
    </KeywordList>

For WFS 2.0, using OWS 1.1 schemas, the related XML schema snippet is:

    <ows:Keywords>
        <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
        <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
        <ows:Type>URI</ows:Type>
    </ows:Keywords>

For an ATOM feed, the related XML snippet is:

    <entry>
        <category scheme="http://data.europa.eu/eli" term="http://data.europa.eu/eli/reg/2009/976"/>
        <category scheme="http://data.europa.eu/eli" term="http://data.europa.eu/eli/reg/2010/1089"/>
    </entry>

Changes to the current INSPIRE framework

TBD

Answer 15 · 2022-06-20T19:11:31.000Z

I just noticed one detail:

For WFS 2.0, using OWS 1.1 schemas, the related XML schema snippet is:

    <ows:Keywords>
        <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
        <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
        <ows:Type>URI</ows:Type>
    </ows:Keywords>

Earlier, we had an unresolved discussion on how to use ows:Type (starting here and see also this issue). I see two options:

Leave out ows:Type completely:

<ows:Keywords>
  <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
  <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
</ows:Keywords>

or ows:Type to match the Atom and WMS encoding of the keywords:

<ows:Keywords>
  <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword>
  <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword>
  <ows:Type codeSpace="http://data.europa.eu/eli">legislative document</ows:Type><!-- or another label than "legislative document" -->
</ows:Keywords>

Answer 16 · 2022-06-21T07:58:33.000Z

I agree with @heidivanparys last proposal since it could help finding where the conformant element keywords are automatically. I would suggest the following wording (rationale: what is in the keyword is in fact the identifier of the legislation)
<ows:Keywords> <ows:Keyword>http://data.europa.eu/eli/reg/2009/976</ows:Keyword> <ows:Keyword>http://data.europa.eu/eli/reg/2010/1089</ows:Keyword> <ows:Type codeSpace="http://data.europa.eu/eli">European Legislation Identifier (ELI)</ows:Type> </ows:Keywords>

Answer 17 · 2022-06-21T08:21:27.000Z

I agree too with @heidivanparys latest proposal and with @MarieLambois amendment.

Answer 18 · 2022-11-14T22:09:34.000Z

Dear @AntoRot,
It seems this issue could be closed. Could you check?

Answer 19 · 2022-11-15T13:53:29.000Z

Dear @jescriu,

Yes, the issue can be closed as the agreed findings have been included in the final proposal.