A whistlestop tour of our project to build a helper app that enables researchers to build a submittable data paper using a dataset uploaded to an institutional repository

2. “Carrot” for data deposit
 “Submit data paper” button on repository
 Researcher gets
– Another publication/citation opportunity
– (Data preserved)
 Publisher gets
– More data paper submissions
– Better quality (metadata already curated by the repo)
– Link referrals from data repositories
 Repositories get
– More data deposits
– Better metadata
 Funders get
– More re-use
– More impact

3. Phase 1 – Feasibility Study
 RDA Publisher Workflow Analysis
– Straw Man spec for Helper app/API
 Questionnaire for Repositories and Publishers
– Confirm requirements
– Gauge interest in proposal
 Overwhelmingly positive feedback
– Offers of collaboration

4. Schematic
Researcher
Helper
App
Data
Repo
Partial
Package
(SWORD+)
Complete
Package
(SWORD+)
Publisher
Data
Paper
Data Deposit
Submit
Refs
(Zotero)
Etc.
(Upload)
Docs
(O360/
G-Docs)
Feedback
DOI+Metadata

5. Phase 2 – Proof of Concept
 Detailed API Spec (SWORD2/DataCite)
 Protoype helper app “Data Paper Companion”
– Fedora Repository/Hydra
– Sword Client/ServerRuby Gems
 Community building
– F1000 Research, Elsevier(Data in Brief and Mendeley), ORCID,
RDA/THOR
– Many more collaboration offers than we could handle
●
Figshare, OJS, Dryad, Nature...
– Presentations/outreach
 Join up with “Streamlining Deposit”

6. Phase 3 – The Business Case
 We started to look for indications of the time this app
would save scholars to quantify the possible benefits...
 We were expecting to measure efficiency gains of
maybe tens of minutes per submission or a bit more...
 What we found rather exceeded our expectations!
 And explains why everyone was so keen...

7. #submissionsystems

8. #datamanagement

9. Phase 3 - Consolidation
 Demonstrate real paper(s) published using the workflow
 Join forces with Streamlining Deposit team
– UX expertise
– Align metadata requirements
– Expect repo-led and publication-led workflows to co-exist
– Need to “close the loop”
 Sustainability
– Steering Committee to initiate governance structures
– API Spec as a formal publication
●
Code as a reference implementation/test harness
●
Include generalised version of Streamlining workflow
– THOR project – identifier ecosystem for research entities
– Jisc shared services
– ORCID
– Cloud hosting: Azure (Microsoft Research), AWS

10. Phase 3 - Expansion
 Expanding reach/integration
– More outreach activities
– Updated SWORD modules for EPrints, Dspace, OSP
– Work with structured repositories such as EBI, NCBI etc. (domain/data specific)
– Take up other publisher offers: Nature, OUP
– Datasets in ORCID
– Journal Policy Registry as a reference source
 Roadmap (not development) for additional use cases
– Multiple datasets
– Other people's data
– Embargoed data (DataShield?)
– Automated publication
– Not just data papers
– REF/Impact friendliness

11. Resourcing
 PI & Project Manager - Lucie Burgess/Neil Jefferies (Bodleian), Fiona Murphy (MMC Ltd)
– Community engagement
– Overall co-ordination
 Lead Developer - Anusha Ranganathan (Digital Nest)
– Some hands on development
– “Cloud ready” build process for helper app
– Primarily co-ordination/support of partner technical efforts
 UX Specialist – Stephann Makri (City)
– Streamline/optimise Data Paper Companion experience
 Technical Author (tbd)
– Formal API specification document
– Developer guidelines
 Partners (F1000Research, Nature, OUP, Elsevier, Figshare, OJS, Microsoft Research etc.)
– Outreach, technical partners, Steering Committee, governance