Requirements

Key

• Only tick checkbox once everyone agrees requirement met by current implementation

• Not started

• Requires further clarification

• Blocked externally

• In progress

• Met by WIP implementation (pending demo, final approval etc.)

1) User-defined DOIs

• 1.1) DataGateway should provide the ability for a PI in an investigation (so an ICAT users with role of PI) to create DataPublications (and associated DOIs) for a set of investigations, datasets and/or datafiles.
• 1.2) DataGateway should provide the ability to let PIs add or remove users associated with a DataPublication before it is created.
• 1.3) Landing page created.
• 1.3.1) Anyone can access data through landing page. Would need anon authentication to be enabled for Diamond. Tracked by https://github.com/ral-facilities/icat-doi-minter-api/issues/45
• 1.4) Version control: See /wiki/spaces/DDSDOI/pages/220856389 , tracked by https://github.com/ral-facilities/icat-doi-minter-api/issues/46
• 1.4.1) No changes allowed to data or metadata once minted, but a new version can be created.
• 1.4.2) One DOI to point to latest version.
• 1.4.3) Ensure suitable metadata supplied so that search engines discover only latest version.
• 1.5) DataCite metadata: See DataCite Metadata Schema Properties , tracked by https://github.com/ral-facilities/icat-doi-minter-api/issues/47
• 1.5.1) Populate all recommended metadata.
• 1.5.2) Auto populate FundingReference with all relevant beamlines and proposal numbers and allow additional funding metadata.
• 1.5.3) Select experimental technique(s) under Subject, based on PaNET terms (future update – TBC) and allow free-text in addition.
• 1.5.4) Apply standard Diamond licence (currently CC-BY-4.0).
• 1.5.5) Initial phase to have limited metadata (as above); future development phases to include tools to provide enhanced metadata.
• 1.5.6) View complete metadata record before minting. Reproduce in landing page? [TBC].
• 1.6) Complete or partial data download option.

• Minting DOI will make data open and accessible to anyone.

2) Automatic minting of DOIs for visits

• 2.1) Identify visits that are ready to be be opened (excluding BAGs and commercial) – Diamond.
• 2.2) Email PI once visit is over to update team or say DOI not to be created (exceptional circumstances) – Diamond.
• 2.3) Automatically mint DOI 2 days after visit ends for eligible visits
• 2.3.1) After this point the experimental team will be fixed as a permanent record of the experiment.
• 2.4) DataGateway should allow the PI for a visit to open the visit data to everyone after agreeing to terms and conditions. Tracked by https://github.com/ral-facilities/icat-doi-minter-api/issues/48
• 2.4.1) No user selection of data: all visit data and metadata other than ‘hidden’ data will be open.
• 2.5) DataCite metadata: similar to user-selected case but title, description (abstract), contributors taken from experimental team.
• 2.6) Include local contact and beamline(s)
• 2.7) All DataCite metadata on landing page.
• 2.8) Landing page gives data access to team.
• 2.8.1) After being made open, access is open to everyone. See 1.3.1).

Making Visit Data Open:

After visit DOI has been minted:

• PI to be able to make all non-hidden visit data open. No user selection.

• All non-hidden data and metadata will then be open to anyone.

3) Data Download:

• 3.1) DataGateway should allow anonymous users to download open data. [Diamond is considering a requirement to have a orcid for data download, but this is pending final data policy consultation feedback. Wellcome are specifically interested in tracking data citations, which could have implications for DataCite metadata and data downloads]. See 1.3.1).
• 3.2) DataGateway should allow access to data by investigation team.
• 3.3) Allow PI to manage restricted data access by adding people who are not in the team or removing access to anyone (except themselves) – Diamond.
• 3.4) Support current download and restaging options plus future object store, DAaaS access etc.

4) Hiding data:

• 4.1) Hidden data is data files, sets and visit that are not made open, even if the set or visit they belong to is opened.
• 4.2) Hidden data will be accessible in DataGateway to registered users with data access rights to the related visit.
• 4.3) User uploaded auxiliary data should be hidden automatically in the short term.
• 4.4) Other data from session DOIs and user created publications can only be hidden by email request to Diamond, neither case is editable by users after publication.
• 4.5) Possible to make hidden data unhidden in the future – requires policy change.

5) Data upload:

• 5.1) Users will have the ability to upload data to the archive, relating to a specific session, at any stage (e.g. auxiliary/processed data). User-uploaded data will be covered by the same restrictions described under ‘hiding data’.