Open geofranzi opened 2 years ago
sventhiel
commented
2 years ago What means "internal" and "external"? Based on some discussions, I think this requirement is about adding a DOI to a dataset that was assigned manually at DataCite and not through the bexis2 system. -> yes but also adding several DOIs to one dataset
May the DOIs should move to a separate table anyway. Because all of them are stored in the "publications" table.
geofranzi
commented
2 years ago What means "internal" and "external"? Based on some discussions, I think this requirement is about adding a DOI to a dataset that was assigned manually at DataCite and not through the bexis2 system.
yes but also adding several DOIs to one dataset
sventhiel
commented
11 months ago Hej, sorry for the late response...
Anyway, would that imply several DOIs related to one dataset version? Should each minted DOI be inside future dataset versions, with the hint to the specific version? Should there be an option to reference DOIs for the data and other types of resources (e.g. publications) within the metadata as well? Will DOIs be listed within the metadata at all or are we going to use the existing concept of "links" for DOIs?
sventhiel
commented
11 months ago @aostrow and @Anahita-Kazem:
Please go through the list mentioned at "Settings" within this issue. In general, by using the mapping facility provided by David, it would be easy to add new properties to the transformation (from BEXIS2 -> DataCite).
aostrow
commented
9 months ago BE needed fields (adapted from a mail)
| datacite nodes | source | number of entries | input values |
|---|---|---|---|
| identifier | doi workflow | one | doi |
| creators | metadata | multiple | name (given name, family name), orcid, affiliation/ror |
| contributor with specific role (data collector) | metadata | multiple | name (given name, family name), role, orcid, affiliation/ror |
| contributor with specific role (PI) | metadata | multiple | name (given name, family name), role, orcid, affiliation/ror |
| contributor with specific role (contact person) | metadata | one | name (given name, family name), email(?), role, orcid, affiliation/ror |
| contributor with specific role (curator) | instance | multiple | fixed list per instance: name (given name, family name), role, orcid, affiliation/ror |
| title | metadata | one | title |
| publisher | instance | one | fixed name |
| publication year | database table | one | date |
| resource type (resourceTypeGeneral) | instance | one | need to get from somewhere from B2? We may have e.g. dataset, sample, … |
| subject (keywords) | metadata | multiple | keywords |
| date issued | doi workflow | one | doi date |
| date created | metadata | one | metadata creation date |
| version | metadata | one | version (+1) |
| rights | metadata | one | license |
| description (abstract) | metadata | one | abstract |
| description (methods) | metadata | multiple | all in methods without keywords, specific formatting rules needed |
| funding references | metadata | multiple | funder name, funder identifier |
sventhiel
commented
8 months ago @Anahita-Kazem, do you see a "general" match or some further/other fields you would need?
Names (Authors/Creators/Owners/...)
At the moment, the system grabs the information from the metadata or a referenced party from within the metadata field. There is a huge drawback with this approach, because if the party is mentioned, it overwrites the XML value (regardless if the XML value would be more informative).
Management of DOIs
At the moment, the system keeps track of DOIs that were issued through the system - only. But quite often, data managers will issue a DOI directly at the DOI provider. That is the reason why there is the requirement to introduce existing DOIs into the system afterwards.
Furthermore, it would be good to visualize the "model" of such a DOI, so that certain people (e.g. data curators) can cross-check the values BEFORE the model is send to DataCite - or even afterwards to correct an issued DOI through the system.
Settings
Right now, the DOI functionalities support the different instances with "required" properties only. This is the smallest set of properties to be transferred to DataCite. But reach project/instance meet different requirements and set of properties as well. That's why there is a need to extend the existing model and make it more configurable.
Citations
Similar to DOIs, there is a high demand to get proper citation strings for datasets/publication from within the system. Much properties are highly related to DOI property issues (e.g. get proper names of authors/owners/creators/...).