Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

...

  •  1.5) DataCite metadata

...

...

    •  1.5.2) Auto populate FundingReference with all relevant beamlines and proposal numbersand 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

...

...

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

...

  • .
  •  5.2 Future Requirement - users will be able to upload data for a data publication that doesn’t relate to an existing session (e.g. where data for the publication spans several visits, and auxiliary data doesn’t directly relate to any of them).