2024-04-08 10:00 – 11:09
Main discussion: proposalID versus beamtimeID
RH focused on solution for avoiding confusion by “DESY naming”, sketching the problem of having different IDs when finding back data taken during a measurement time. This seems to be coming back again and again, several solutions have been discussed.
Conclusion: two possible solutions, see slide 6, go for both 1. + 2.:
1. Do change names in the frontend, such that under proposalID beamtime ID is displayed while in SciCat itself the field keeps the name given by the class.
2. At the same time ask the developers of SciCat for advise (for reasons of support and not forking) what they think of enhancing the data model, in particular the measurementPeriodListClass in a way that it corresponds to DESY beamtimes, adding ownership, accessRights.
Action item: Regina will draft together with Paul M and Frank S a DESY request to the developers on that.
Question of DOIs for a timeline.
Regina answered: By this year, possibly around summer – hopefully – we will be able to mint a DOI for a dataset, meaning producing a landing page with information of the datasets. One can have a preview from the PSI DOI landing page at https://doi.psi.ch/ and their detailed landing page per DOI by selecting on of the items. It does not yet include data access. No need to wait for migration of jobs functionality. First obstacle to overcome: How to efficiently store information of a worst case beamtime such that it’s managable.
Other: Use SCT for updates on SciCat developer’s meeting, see for detailed info notes by Max Novelli on our indico https://indico.desy.de/category/1079
Next SCG: on 26.04.2024 in hybrid mode, on site we will meet in 25b, room 235 and online via zoom (as announced end of March).
Participants
- Dmytro K
- Frank S
- Paul M
- Jan K
- Anton B
- Anjali A
- Lisa A
- Stefan D
- Jan G
- Martin G
- RH