Requirements

User-defined DOIs

• 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.

• DataGateway should provide the ability to let PIs add or remove users associated with a DataPublication before it is created.

• Landing page created. Anyone can access data through landing page.

• Version control: no changes allowed to data or metadata once minted, but a new version can be created. One DOI to point to latest version. Ensure suitable metadata supplied so that search engines discover only latest version.

• DataCite metadata:

  • Populate all recommended metadata.

  • Auto populate FundingReference with all relevant beamlines and proposal numbers and allow additional funding metadata.

  • Select experimental technique(s) under Subject, based on PaNET terms (future update – TBC) and allow free-text in addition.

  • Apply standard Diamond licence (currently CC-BY-4.0).

  • Initial phase to have limited metadata (as above); future development phases to include tools to provide enhanced metadata.

• View complete metadata record before minting. Reproduce in landing page? [TBC].

• Complete or partial data download option.

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

Automatic minting of DOIs for visits

• Identify visits that are ready to be be opened (excluding BAGs and commercial) – Diamond.

• Email PI once visit is over to update team or say DOI not to be created (exceptional circumstances) – Diamond.

• Automatically mint DOI 2 days after visit ends for eligible visits

o    After this point the experimental team will be fixed as a permanent record of the experiment.

• DataGateway should allow the PI for a visit to open the visit data to everyone after agreeing to terms and conditions.

o   No user selection of data: all visit data and metadata other than ‘hidden’ data will be open.

• DataCite metadata: similar to user-selected case but title, description (abstract), contributors taken from experimental team.

• Include local contact and beamline(s)

• All DataCite metadata on landing page.

• Landing page gives data access to team. After being made open, access is open to everyone.

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.

Data Download:

• 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].

• DataGateway should allow access to data by investigation team.

• Allow PI to manage restricted data access by adding people who are not in the team or removing access to anyone (except themselves) – Diamond.

• Support current download and restaging options plus future object store, DAaaS access etc.

Hiding data:

• Hidden data is data files, sets and visit that are not made open, even if the set or visit they belong to is opened.

• Hidden data will be accessible in DataGateway to registered users with data access rights to the related visit.

• User uploaded auxiliary data should be hidden automatically in the short term.

• 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.

• Possible to make hidden data unhidden in the future – requires policy change.

Data upload:

• 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’.