Describing OGC API Features in ISO geo-metadata

[akuegeler]

We are looking into a way to identify OGC API Features in geo-metadata (ISO19139), because we would like to improve the geo-harvesting process for the European Dataportal data.europa.eu. As there are different ways of describing OGC API Features endpoints in metadata, we are interested in the following:

1. How do you describe resources delivered via OGC API Features (dataset or service metadata, serviceType ...)?
   Examples would be great!
   2.) Are there any efforts to harmonise the way OGC API Features are described in ISO geo-metadata (or GeoDCAT-AP) in your county or on a European level?
   Your input is very much appreciated!

[hallinpihlatie]

Here's an example:
https://www.paikkatietohakemisto.fi/geonetwork/srv/api/records/943dac39-fd79-4d5a-9f0b-3462177d349c/formatters/xml?approved=true

• service metadata
• serviceType = download
• keyword= infoFeatureAccessService referring to https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/infoFeatureAccessService

That is the same description as for a WFS service has been used.

If there is a need to describe OGC API Features in a different way than WFS services one should agree on how. One could perhaps add a new code to this code list https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory. As far as I know, there hasn't been a discussion so far.

[akuegeler]

Thank you, Lena!
Unfortunately the serviceType "download" isn't specific in what kind of download service we are describing (WFS, ATOM, or OAF).
We are looking for a way to identify the specific type of service. Of course this is not new or specific to OGC API Features.
In Germany there is a convention [1] to add this information to serviceTypeVersion, e.g.:

<srv:serviceType>
<gco:LocalName codeSpace="http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType">download</gco:LocalName>
</srv:serviceType>
<srv:serviceTypeVersion>
<gco:CharacterString>OGC:WFS 2.0</gco:CharacterString>
</srv:serviceTypeVersion>

We were wondering whether other member states have similar (or different) conventions to address this question

[1] https://www.gdi-de.org/download/AK_Metadaten_Konventionen_zu_Metadaten.pdf (in German only)

[fabiovinci]

Dear @akuegeler,

I suppose you are referring to "Dataset" metadata, since for "Service" metadata the geo-harvester (if I remember well) converts all the links available in the Resource Locator element(s) into "Distribution" element(s) of the GeoDCAT metadata.

Looking at the INSPIRE Good Practice for the OGC API-Features and the related OGC Specification it seems that one of the mandatory paths in the URL is "/collections", which follows the base URL of the service, considered as the landing page.

This check could help to identify OGC API Features services, even if there could be corner cases:

• URLs not related to the OGC service can contain the text "/collections"
• The link of the landing page is provided for OGC API Features services (even if in this case adding the path "/collections" the URL should work)
• A different link is used (i.e. different from the <landing page> and/or <landing page>/collections)) if a redirect service is configured.

Hope this can help you.

[akuegeler]

Thank you, Fabio!
We are looking at metadata for both datasets and services.
Checking the URLs for "/collections" should indeed work in the cases that this is used as an CI_OnlineResource. Unfortunately this doesn't need to be the case...which is why we are hoping that someone is working on a convention on how to best approach this.

[fabiovinci]

You are right, the Resource Locator element is "conditional" (it shall be given if online access to the service is available), so it may not be present in the metadata.
But, for service metadata, the idea is to identify the service as OGC API Features even if no related links (and then distributions) are available?

[akuegeler]

No, I would not see any value in identifying a service as OGC API Features if no related links (and then distributions) are available.
For a harvesting portal identifying a service type should be straightforward or we should not attempt it at all.
To me it seems like many data providers use the API landing page as the CI_OnlineResource and not a URL to an individual feature collection.
We are hoping that there would already be some efforts underway to find a good way on how to describe OGC API Features in ISO geo-metadata.
In my opinion the focus should be on the data set metadata (because of the INSPIRE good practice Data-Service Linking Simplification. However the concept of describing services still seems very much a part of INSPIRE and personally I still like using filters for service types in geoportals or find myself adding a service type to a search because I am used to it.
Thank you for your input!

[fabiovinci]

No, I would not see any value in identifying a service as OGC API Features if no related links (and then distributions) are available.

I agree with you. I had asked the question just to understand if you were looking at other metadata elements than those expected within the "<gmd:CI_OnlineResource>" element to locate the type of service.

In my opinion the focus should be on the data set metadata

I fully agree with you. Indeed in the INSPIRE Geoportal the service metadata are "only" visible inside the dataset metadata view (if the Geoportal is able to establish a link between the dataset and the related service(s)).

The "Data Service Linking Simplification Good Practice" facilitates linking the dataset and the related services requiring the provision of at least two Resource Locator elements (one for the View and one for the Download service).
The Good practice also mandates the element gmd:protocol which shall contain one of the values in https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue codelist.
This codelist was recently updated with a new item for OGC API-Features (see related issue), but the related value is still not visible in the INSPIRE Registry due to an issue with the cache.

To me it seems like many data providers use the API landing page as the CI_OnlineResource and not a URL to an individual feature collection.

Indeed, it is not so simple to map the IR requirements to the OGC-API Features standard (as it was for WMS/WFS). See Annex B: Mapping the requirements from the IRs to the OGC-API Features standard (and extensions).

So, the service metadata (capabilities) document, commonly used as a link in the Resource metadata element for WMS/WFS, corresponds to a series of requests for the OGC API Features:

For these reasons, the landing page should be the most appropriate link to use in the Resource Locator metadata element.

I still like using filters for service types in geoportals
Agree, it is useful.

[hallinpihlatie]

Here's a link to a dataset metadata related to the service metadata link provided earlier
https://www.paikkatietohakemisto.fi/geonetwork/srv/api/records/f6f81412-297e-45f9-ace3-bf3b1bb52a9f/formatters/xml?approved=true

Now:
gmd:onLine
gmd:CI_OnlineResource
gmd:linkage
gmd:URLhttps://geo.stat.fi/inspire/ogc/api/pf/</gmd:URL>
</gmd:linkage>
gmd:protocol
gco:CharacterStringOGC:WFS</gco:CharacterString>
</gmd:protocol>
</gmd:CI_OnlineResource>
</gmd:onLine>

Could the solution just be to add the protocol "OGC API Features" to the list of protocols to be used?

[fabiovinci]

Dear @hallinpihlatie,

the change proposal for the addition of the "OGC API-Features" value was already endorsed by the MIG/MIG-T.
The value should soon be visible in the related codelist: https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue.

[akuegeler]

Thank you, @fabiovinci for the in depth explanation!
So in @hallinpihlatie's example would you just use OGC API-Features instead of OGC:WFS now or is it necessary to reference the codelist (and thus wait until OGC API-Features has been added to the codelist)?

[fabiovinci]

The value can already be used.
As indicated by the "Data Service Linking Simplification Good Practice" it is recommended the use of the gmx:Anchor encoding, but also the <gco:CharacterString> can be used.
The following are examples of the different encodings:

<gmd:protocol>
    <gmx:Anchor xlink:href="http://www.opengis.net/def/docs/17-069r3">OGC API-Features</gmx:Anchor>
</gmd:protocol>

<gmd:protocol>
    <gco:CharacterString>OGC API-Features</gco:CharacterString>
</gmd:protocol>

Please note that the MD TG does not foresee the use of the <gmd:protocol> element, so this is not currently tested by the Reference Validator.
A new ATS/ETS for the "Data Service Linking Simplification Good Practice" will be developed in the coming months, and a new dedicated Conformance Class will be available in Reference Validator.
This will allow for testing Good Practice requirements and thus the correct encoding of the <gmd:protocol> element.

[akuegeler]

Thank you, Fabio, that was very helpful!

[hallinpihlatie]

Thanks for raising this @akuegeler and for answering Fabio, very helpful for me as well.

[armin11]

Hello together,

we have actually more than 700 different OGC API-Features endpoints available:
https://vocabulary.geoportal.rlp.de/geonetwork/srv/ger/catalog.search#/search?resultType=details&sortBy=relevance&any=OGC%20API%20Features&fast=index&_content_type=json&from=1&to=20
They are generated by our WFS-proxy dynamically. The metadata records are also generated OTF since 2019.

srv service info:

<srv:serviceType>
    <gco:LocalName>download</gco:LocalName>
</srv:serviceType>
<srv:serviceTypeVersion>
    <gco:CharacterString>ogcapifeatures</gco:CharacterString>
</srv:serviceTypeVersion>

srv contains operation:

<srv:containsOperations>
    <srv:SV_OperationMetadata>
        <srv:operationName>
            <gco:CharacterString>getApiDescription</gco:CharacterString>
        </srv:operationName>
        <srv:DCP>
            <srv:DCPList codeList="./resources/codelist/gmxCodelists.xml#DCPList" codeListValue="WebServices"/>
        </srv:DCP>
        <srv:connectPoint>
            <gmd:CI_OnlineResource>
                <gmd:linkage>
                    <gmd:URL>https://www.geoportal.rlp.de/spatial-objects/575</gmd:URL>
               </gmd:linkage>
           </gmd:CI_OnlineResource>
        </srv:connectPoint>
    </srv:SV_OperationMetadata>
</srv:containsOperations>

gmd transfer options:

<gmd:transferOptions>
    <gmd:MD_DigitalTransferOptions>
        <gmd:onLine>
            <gmd:CI_OnlineResource>
                <gmd:linkage>
                    <gmd:URL>
https://www.geoportal.rlp.de/spatial-objects/575/collections/ms:vbs_fliessgewaesser_entwicklung
                   </gmd:URL>
               </gmd:linkage>
               <gmd:protocol>
                   <gco:CharacterString>OGC:API:Features</gco:CharacterString>
               </gmd:protocol>
               <gmd:name>
                   <gco:CharacterString>ms:vbs_fliessgewaesser_entwicklung</gco:CharacterString>
               </gmd:name>
               <gmd:description>
                  <gco:CharacterString>VBS Fließgewässer Entwicklung</gco:CharacterString>
              </gmd:description>
          </gmd:CI_OnlineResource>
      </gmd:onLine>
    </gmd:MD_DigitalTransferOptions>
</gmd:transferOptions>

We would be pleased, if there will be a consistent European way of encoding this information somewhen ;-)

Best regards,
Armin

[Dnoack49]

Dear all,

our implementation for describing OGC API-Feature endpoints in metadata is similar to the approach suggested by @armin11 .

Major differences are:

• serviceTypeVersion is OGC API – Features (as notation on OGC-site)
• containsOperations: API-Specification
• transferOptions: using landing page

These are visualised below:

srv service info:

We chose OGC API - Features as it is the notation from the OGC website.

srv contains operation:

API Specification is the technical term for such an interface description. One could also specifiy it as "OpenAPI Specification", then it would even be clearer and correspond to the official documentation:

• https://swagger.io/docs/specification/about/
• https://de.wikipedia.org/wiki/OpenAPI

gmd transfer options:

Indeed, thanks for raising this question, we'd also appreciate a harmonised metadata description.