Migration to v4 of RSS, OpenSearch and INSPIRE OpenSearch

[pvgenuchten]

These 3 topics are quite related and each of them still lacking in v4. Suggestion is to use the moment to align these functionalities. Currently the documentation about these topics is quite limited, so it is a bit unclear what is the expected behaviour of each of them. This issue tries to collect some user scenario's and suggestion for implementation.

Use scenario's

RSS

• User can subscribe to a metadata record, by copying the rss url of a metadata record to a rss reader. Most feed readers support both RSS and Atom format, so this can potentially be deprecated in favor of Atom.
• Some (like esri geoportal) use rss endpoint to run a query against the catalogue and return a set of records, this functionality looks quite similar to OpenSearch as below.

OpenSearch

The main page of the application (example.com/index.html) should have a reference to the opensearch endpoint

<link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="OpenSearch">

A user can type the domain name, then space and use the opensearch functionality to query the catalogue from the browser bar. Search result opens in Angular application (or oapi-records)

OGC OpenSearch

OGC introduced a space-time extension to OpenSearch facilitating the earth observation domain. AFAIK GeoNetwork currently does not support that extension. It could be interesting to add support for it.

INSPIRE OpenSearch

Similar as above, however this introduces an opensearch endpoint for each download service to query for datasets within that download service. INSPIRE also adds some implementation specific elements to the Atom document, not sure if it would break the default Opensearch service if added. Also some new methods are introduced to link to related resources (describe dataset, download dataset). These methods should be migrated to API.

INSPIRE OpenSearch local vs remote

In remote mode, GeoNetwork loads atom feeds from remote location, indexes them and returns the remote feed when requested. In local mode feed responses are generated from metadata content. Another option to support is a hybrid mode, use the remote feed if available, else create a feed response based on metadata content. Local mode seems deactivated in 3.10

Plugin/micro service vs integration in core

A choice should be made to embed the INSPIRE OpenSearch into the core product or to introduce it as a separate plugin / micro service. The functionality is only relevant to a subset of the users and due to its dedicated url structure it is relatively easy to seperate it to a separate micro service. The micro service could potentially still use some query functions from the core library.

On the other hand it would make sense to reuse the canonical url of a record, enforcing the relevant output encoding. For example the url of a record in atom would be /oapi/collections/srv/items/{uuid}?f=atom

[fxprunayre]

+1 for moving all this to a dedicated search micro-service - OAI-PMH is also a candidate to preserve.
With OGC-API Record POC, we demonstrated that we can have a standalone service next to a v4. See https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records

[fxprunayre]

RSS service and OpenSearch description can be deployed next to GeoNetwork 4.0.3 using OGC API Records service (see geonetwork/geonetwork-microservices#29)

[landryb]

i'll be interested into testing this, but maybe a dumb question, can one run one of those microservices without having to be converted to the docker dogma ? eg do we get some buildable code deployable the old way, within jetty or tomcat ?

[fxprunayre]

eg do we get some buildable code deployable the old way, within jetty or tomcat ?

Spring boot allows to build a number of packages types - see https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records#start-as-standalone-service JAR/WAR/Docker. And we are learning, so be kind and don't hesitate to suggest improvements !

Note that this work is a first draft currently on test at Ifremer. RSS will probably not change much. More work ongoing on (Geo)DCAT(-AP) profiles mapping and the OGC API Records spec is also still a draft for now.

[landryb]

thanks, that's what i wanted to see - i know that the RSS feature is used in our geOrchestra instance to display latest catalog records on our drupal portal, so having it at least working like it was in 3.8 will be a requirement for geOrchestra to upgrade to latest 4.0, so we'll make sure to get that covered/tested.

[landryb]

right, tried building from the repo but it requires a recent maven and java so i'll leave it there for now - i've just noticed that the paths in README.md are wrong in https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records - they all refer to modules/services/ogc-api-records/service while it seems service doesnt exist, i guess code was moved around.

[fxprunayre]

while it seems service doesnt exist, i guess code was moved around.

Fixed. Indeed was refactored by @josegar74 in last sprint.
and indeed, the repo is using Java 11.

i know that the RSS feature is used in our geOrchestra instance to display latest catalog records on our drupal portal,

Same at ifremer. We are also experimenting new ways of interacting with third party apps using web components in https://github.com/geonetwork/geonetwork-ui eg. https://geonetwork.github.io/geonetwork-ui/master/demo/eea/results-list.html