Question use of metadata fileIdentifier in geoportal as identifier for linking

[wboersma]

Dear Geoportal Helpdesk,

In the Netherlands we have an INSPIRE register for all Dutch INSPIRE datasets (see https://inspireaanmerking.nl/aanmerkingsregister). In the register we link via the metadata fileIdentifier to the dataset in the national portal.

We would also like to link to the EU INSPIRE geoportal and also via the metadata fileIdentifier. In the current Geoportal a resource id is used, but this is not the metadata fileIdentifier but a different identifier.
Is it possible that in the new Geoportal (based on Geonetwork) we can link from our register to the EU geoportal based on metadata fileIdentifier?

Best regards, Wideke

[dartasensi]

Dear @wboersma

thank you for your comment.
We, as JRC INSPIRE team, had an internal discussion about your question.

The current geoportal indeed uses dedicated fileIdentifiers for records including a member state prefix.
The feature was designed to allow multiple MS to have an identical file identifier for a record while solving this id collision.
For the new edition of the geoportal we want to learn from your needs regarding this aspect.

In this scope, we want to ask you: what is the expected behavior in (the unlikely) case that 2 member states (or from 1 member state, within a single harvest run) provide records with identical file identifier?

• The harvest process skips the second arriving fileIdentifier with a warning that this fileIdentifier is already taken?
• The harvest process creates a unique fileIdentifier for the second arriving record with a warning that this fileIdentifier was already taken?
• The geoportal returns 2 (or more) records for the GetRecordById operation

Or do you have alternative suggestions for this challenge?

JRC INSPIRE team

[wboersma]

Dear @dartasensi,

Thanks for your reply. We have discussed your question.

In geonetwork, which most MS use, it is not possible to have the same file identifier. Also according to the CSW standard this is probably not allowed (but we have not checked this in the standard). The member states offer 1 discovery service per member state (with exceptions) (usually from GN). So we don't easily see a problem at member state level.

Theoretically, the problem can arise when different MS discovery services come together in the EU portal. We are actually curious whether the same file identifiers of different MS also occur in practice. That way you also know how big the problem is that may need to be solved. So do you know how many times this occurs?

A possible solution is indeed a member state prefix, the Country code, and then the file identifier.

For instance the Dutch dataset 'Wijk- en Buurtkaart 2020 versie 1' with file identifier: f1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3.
In the Geoportal the file identifier is then: NLf1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3.
In the Dutch geoportal we can find the dataset easily (through the file identifier without NL):
https://nationaalgeoregister.nl/geonetwork/srv/dut/catalog.search#/metadata/f1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3

It would be nice, we also could find in so easily in the geoportal (file identifier with NL):
https://inspire-geoportal.ec.europa.eu/download_details.html?view=downloadDetails&resourceId=%NLf1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3%2Fservices%2F1%2FPullResults%2F481-500%2Fdatasets%2F14&expandedSection=metadata

Would this be a possible solution. Please keep the original file identifier as base in the geoportal.

Best regards, Wideke

[ghost]

Interesting discussion here!

I had similar problem to return individual metadata record which is existent in our catalogue with unique fileIdentifier encoded as UUID as suggested in "Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007".

Although I didn't want to return HTML representation of the metadata record in INSPIRE-Geoportal as @wboersma.

My goal is to address CSW 2.0.2 interface from INSPIRE (https://inspire-geoportal.ec.europa.eu/GeoportalProxyWebServices/resources/OGCCSW202) using GetRecordByID operation.

But, the same problem occurred like described from @wboersma - setting "as it is" fileIdentifier from our catalogue as value for Id parameter in GetRecordByID request results in empty response because internal IDs are used to uniquely identify records in INSPIRE metadata catalogue as described from @dartasensi.

Also these dynamical internal fileIdentifiers can't be returned with GetRecordByID operation. More details here.

example of INSPIRE fileIdentifier:
/INSPIRE-4fed3eb0-06fa-11ea-8480-525400695e9c_20210629-164602/services/1/PullResults/88901-88920/datasets/5_ID_8ae5ca56-9f36-f95a-5b61-7a42a8fd5f70

My workaround described here #8 didn't work because complex queries aren't supported from INSPIRE CSW 2.0.2 implementation!

To summarize:
Individual metadata records can't generally be addressed in INSPIRE environment using these endpoints:

• XML representation via CSW 2.0.2 interface with GetRecordByID operation
• XML or HTML representation via INSPIRE Geoportal interface
• XML or HTML representation via INSPIRE Ressource Browser from external applications

@dartasensi Should we discuss here generic solution for getting HTML and/or XML representation generically using INSPIRE endpoints from external applications? Your questions here apply for all three endpoints?

[ghost]

A possible solution is indeed a member state prefix, the Country code, and then the file identifier.

For instance the Dutch dataset 'Wijk- en Buurtkaart 2020 versie 1' with file identifier: f1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3.
In the Geoportal the file identifier is then: NLf1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3.
In the Dutch geoportal we can find the dataset easily (through the file identifier without NL):
https://nationaalgeoregister.nl/geonetwork/srv/dut/catalog.search#/metadata/f1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3

It would be nice, we also could find in so easily in the geoportal (file identifier with NL):
https://inspire-geoportal.ec.europa.eu/download_details.html?view=downloadDetails&resourceId=%NLf1859b4d-93be-4fc8-9e91-0ecc2fa0f3b3%2Fservices%2F1%2FPullResults%2F481-500%2Fdatasets%2F14&expandedSection=metadata

Would this be a possible solution. Please keep the original file identifier as base in the geoportal.

Best regards, Wideke

@wboersma Do you know if ressourceID (see URL above) is persistent or it is changed (could be changed) every time during the harvesting process? If resourceId is not persistent than your solution probably will not work after next harvesting process...

[jrc-inspire]

Dear Community,

As reported in the last 75 MIG-T meeting, the rollout of the revamped INSPIRE Geoportal based on GeoNetwork is approaching.

As part of this rollout the Classic Geoportal harvesting console was dismissed on Thursday 20 July - From that date onwards all harvesting processes shall be performed using the revamped GeoNetwork console.

This discussion may potentially be continued taking into account the migration of the INSPIRE Geoportal to a GeoNetwork-based architecture, were the rules applied in this software (and not those from the Classic Geoportal) will apply.

[fabiovinci]

Dear all,

the issue was solved by the new Geoportal, since the metadata are now accessible through a link containing the file identifier (e.g. https://inspire-geoportal.ec.europa.eu/geonetwork/srv/api/records/391de539-ea1a-44dd-9b00-43feb66e64d2/formatters/xml?approved=true).

It worked until yesterday, but now it doesn’t work.
I hope it will be fixed soon.

[jescriu]

Dear @fabiovinci and colleagues,
We are investigating this issue and will keep you posted.

[jescriu]

Dear community,

The issue has been identified and a new version of the INSPIRE Geoportal frontend will be published in the next days.
We will keep you posted on the status of this fix.

In the meantime, and illustrating it with the metadata example provided by @fabiovinci here, you can temporarily access to the XML visualisation of the metadata by using the following URL pattern:

https://inspire-geoportal.ec.europa.eu/srv/api/records/391de539-ea1a-44dd-9b00-43feb66e64d2/formatters/xml?approved=true

[jescriu]

Dear community,
The fix is already implemented in the INSPIRE Geoportal.