Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: How to ensure that same record/object will receive same FDP UUID #395

Open
jagerda opened this issue Feb 24, 2023 · 3 comments
Open

Q: How to ensure that same record/object will receive same FDP UUID #395

jagerda opened this issue Feb 24, 2023 · 3 comments

Comments

@jagerda
Copy link

jagerda commented Feb 24, 2023

@a-tassoni, @markwilkinson , @sdvr

Extension part
adding / updating data

Requirement / why we think this is important
Requirement F1: (Meta) data are assigned globally unique and persistent identifiers

FDP uses its own UUIDs for all of its objects (catalogues, etc). These are created when you use the web interface, or the FDP API. In our testing it seems that even if you provide your own UUID, FDP will overwrite it.

We need to ensure that when we uplift data to the FDP (regardless of our local data processing pipeline) that these UUIDs are somehow matched consistently – we assume that this has to be persistent matching for the data to be FAIR. In other words, if we have records with local IDs 1-10, these should always match to the same FDP UUIDs.

We know that when we add a new resource with POST to the FDP the response body returns the generated UUID (as part of the resource’s URI) and we can use this to do PUT afterwards to update resources and the URIs stay persistent from there on.
But in case we would need to setup a completely new FDP, FDP would create a complete new set of URIs because it would generate new UUIDs.

The Question
Is it possible to recreate the FDP content without genererating new URIs for all the objects in FDP?

@ifokkema
Copy link

I'm curious about this as well - I already have persistent identifiers for my data sets, and I don't see why I'll need to change my data model to store the FDP's autogenerated UUIDs so I can link my data sets to the FDP. I'd like to either provide the UUID or, otherwise, change it after creation to my own UUIDs.

@kburger
Copy link
Contributor

kburger commented Mar 20, 2023

The FDP specs allow for any way you prefer to generate the identifiers. Currently the reference implementation will generate unique identifiers for you. In case of a migration, I think the triplestore contents can be migrated as is and the identifiers will be consistent, but I'll check that one out and get back to you on this.

@markwilkinson
Copy link
Contributor

A solution to this would be for the REST interface of the FDP to accept the "Slug:" header, where I can tell it the identifier of the resource I want it to create. Does this work for FDP reference implementation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants