Data2paper: Giving Researchers Credit for Their Data
Round 1
Reviewer 1 Report
I consider this paper relevant and of high interest as contribution to Open Data uptake. Indeed, better infrastructures and services are needed in order to spread the Open Data practices. Overall, I enjoyed reading the paper and appreciated very much the project's results.
As for the research, I consider the paper would have been much stronger if a user-test would have been conducted in order to validate the app design through human-computer interaction lens.
The empirical base in this paper is the history of the project as process of software development, as well as the coherence between detected user-needs and the final app design. Moreover, the code adopted is openly shared through the Github.
My only suggestion to the authors is to refer the limitations of this study in the conclusions, namely, the lack of empirical data supporting the app (which can constitute a further phase in this study). The authors could also elaborate on the cycles of user-testing, including diversification of disciplinary fields (to which extent is the app usable for all disciplines).
These are issues relating the user experience, beyond the technological development (apps are developed to cover users' needs, in this case, the researchers' need of dealing with faster ways to publish their data, hence embracing an Open Data perspective).
Author Response
Testing with a select community is something we are working on, I will update the paper to mention this.
Reviewer 2 Report
In general, the approach sounds quit interesting but – as by you already mentioned – there are some assumptions that influence the successful implementation of the workflow generally. As a prerequisite, the data repository must support DataCite DOIs, metadata and ORCID for being connectable to Data2Paper. Furthermore, the initial research indicated the use of only a few submission management platforms that are supported by Data2Paper. In practice, many publishers / data journals use their own workflow. This fact reduces the broad integration of data journals in the helper app or at least increase the time and effort of integration. Maybe, the individual integration of the original repository with the journal submission workflow could be made with the same effort. You should explain the advantages of using the helper app in contrast to an individual solution in more detail or to a simple portal integrating all data journal suppliers with their information about submission process and conditions.
You state that the “app makes the process of associating and publishing data with a detailed description easier”. In my opinion, the basis for that would be to match existing metadata from the repository to the metadata needed in the data journal. Unfortunately, the mapping / matching process is not mentioned in the article. For me, this seems necessary regarding the possibility to judge the project and the achievement of objectives. The authors should adjust the contents accordingly.
Overall, the article should provide more substance, which means more details about the interrelation between the stakeholders that constitute the workflow. Which advantages does the use of Data2Paper in the current state have for these stakeholders?
Author Response
The prior research referenced in the paper (The RDA Publsihign Workflows Working Group) had already demonstrated that metadata mappings between DataCite and journals was sufficiently strong to make the app viable.
Journal worksflows have tended to be more vvariable than expected, but data focussed journals tend to be newer and more amenabe to automation.
I will note these points in the paper.
Reviewer 3 Report
This is a very timely article describing a much needed app/development project to address the need for better integrated data paper publishing with existing metadata sources. It describes the compelling need and how the app creates new efficiencies.
Author Response
Thanks!
