You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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?
@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?
The text was updated successfully, but these errors were encountered: