medrxivr: Accessing and searching medRxiv preprint data in R

[mcguinlu]

Submitting Author: Luke McGuinness (@mcguinlu)
Repository: https://github.com/mcguinlu/medrxivr
Version submitted: 0.0.2
Editor: @maurolepore
Reviewer 1: @tts
Reviewer 2: @njahn82
Archive: TBD
Version accepted: TBD

---

• Paste the full DESCRIPTION file inside a code block below:

Package: medrxivr
Title: Access MedRxiv Preprint Data
Version: 0.0.2
Authors@R: c(
    person("Luke", "McGuinness",
           role = c("aut", "cre"),
           email = "luke.mcguinness@bristol.ac.uk",
           comment = c(ORCID = "0000-0001-8730-9761")),
    person("Lena", "Schmidt",
           role = "aut",
           comment = c(ORCID = "0000-0003-0709-8226")))
Description: The medRxiv <https://www.medrxiv.org/> repository is a free online
    archive and distribution server for complete but unpublished manuscripts 
    (preprints) in the medical, clinical, and related health sciences. medrxivr
    provides programmatic access to both medRxiv API <https://api.biorxiv.org/>
    and a static snapshot of database, which is updated daily. Users can then 
    search for relevant records using regular expressions and Boolean logic, and
    can easily download the full-text PDFs of preprints matching their search 
    criteria. 
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Language: en-US
URL: https://github.com/mcguinlu/medrxivr
BugReports: https://github.com/mcguinlu/medrxivr/issues
Imports: 
    rvest,
    methods,
    dplyr,
    xml2,
    curl,
    jsonlite,
    httr,
    stringr,
    rlang
Suggests: 
    testthat (>= 2.1.0),
    knitr,
    rmarkdown,
    covr,
    kableExtra
VignetteBuilder: 
    knitr, 
    rmarkdown    
RoxygenNote: 7.1.0

Scope

• Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):

  • data retrieval
  • data extraction
  • data munging
  • data deposition
  • workflow automataion
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • field and lab reproducibility tools
  • database software bindings
  • geospatial data
  • text analysis

• Explain how and why the package falls under these categories (briefly, 1-2 sentences):
  medrxivr allows users to programmatically access data from medRxiv, a preprint respository for papers in medical, clinical, and related health sciences. The package also allows user to readily perform and document reproducible literature searches of the medRxiv database.

• Who is the target audience and what are scientific applications of this package?
  The primary target of this package is systematic reviewers (i.e. me!), who frequently wish both to use more complicated queries (e.g. regular expresssions/Boolean combinations) when searching medRxiv than the official site currrently allows for, and who also wish to be easily able to download the full text PDFs of records matching their search. medrxivr helps with both of these challenges. However, anyone who wishes to find and retrieve relevant medRxiv records in R, for example to explore the distribution of preprints by subject area, will find the package useful.

• Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?
  As far as I am aware, no other package allows users to access medRxiv data in R.

• If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.
  Issue: Presubmission inquiry: medrxivr #369
  Editor: @annakrystalli

Technical checks

Confirm each of the following by checking the box.

• I have read the guide for authors and rOpenSci packaging guide.

This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions, created with roxygen2.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, including reporting of test coverage using services such as Travis CI, Coveralls and/or CodeCov.

Publication options

• Do you intend for this package to go on CRAN?
• Do you intend for this package to go on Bioconductor?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Options

• The package has an obvious research application according to JOSS's definition.
  • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI: 10.5281/zenodo.3860024
  • (Do not submit your package separately to JOSS)

• Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

• The package is novel and will be of interest to the broad readership of the journal.
• The manuscript describing the package is no longer than 3000 words.
• You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see MEE's Policy on Publishing Code)
• (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no guarantee that your manuscript will be within MEE scope.)
• (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
• (Please do not submit your package separately to Methods in Ecology and Evolution)

Code of conduct

• I agree to abide by rOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Tagging my co-author @L-ENA for reference.

[maurolepore]

@mcguinlu and @L-ENA, thanks for your submission. I'll be the editor. As we move though the process I'll keep you posted. I welcome your questions any time.

[maurolepore]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

@mcguinlu, thanks again for your submission. The editor checks flagged a few issues that need your attention; see them below.

Let's discuss the first two items (ml1 and ml2) before I search for reviewers; these two items refer to a potential overlap with existing packages.

• (ml1) @mcguinlu, I see you discussed this issue with @sckott ((Potential) new data source: medrxivr ropensci-archive/fulltext#213 (comment)); but this was a while ago and the issue remains unresolved and open. As of today, what do you think is the best way to move forward?:

  a. Extend the package fulltext (https://github.com/ropensci/fulltext).
  b. Continue with this submission (please argue for the lack of overlap).
  c. Something else (please explain).

• (ml2) The file DESCRIPTION links to https://api.biorxiv.org/. @mcguinlu, is there an overlap with the package biorxivr (https://cran.r-project.org/web/packages/biorxivr/index.html)? Why not?

The remaining items are important but not as urgent as the first two.

• (ml3) Run spelling::spell_check_package(); then fix or update the list of valid words with spelling::update_wordlist().

> spelling::spell_check_package()
WORD              FOUND IN
api               mx_api_content.Rd:39,42
                  mx_api_doi.Rd:28,31
                  description:4
AppVeyor          README.md:14
                  README.Rmd:24
ation             building-complex-search-strategies.Rmd:110
biorxiv           description:4
capitalisation    building-complex-search-strategies.Rmd:125
... more lines

• (ml4) Run goodpractice::gp() to identify lines of code that tests don't touch.

> goodpractice::gp()
... more lines
── GP medrxivr ─────────────────────────────────────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code in
    general. 77% of code lines are covered by test cases.

    R/mx_crosscheck.R:50:NA
    R/mx_download.R:25:NA
    R/mx_download.R:27:NA
    R/mx_download.R:28:NA
    R/mx_download.R:30:NA
    ... and 51 more lines

• (ml5) Run covr::package_coverage() and try to test code in files with low % coverage.

> covr::package_coverage()
medrxivr Coverage: 77.60%
R/mx_download.R: 1.92%
R/mx_crosscheck.R: 96.15%
R/mx_search.R: 96.33%
R/mx_api.R: 100.00%
R/mx_info.R: 100.00%

• (ml6) You may run an automated code-styler to make it easier for reviewers to read your code (https://styler.r-lib.org/reference/style_pkg.html).

> styler::style_pkg()
Styling  12  files:
 R/medrxivr.R                     ✓ 
 R/mx_api.R                       ℹ 
 R/mx_crosscheck.R                ℹ 
 R/mx_download.R                  ℹ 
 R/mx_info.R                      ℹ 
 R/mx_search.R                    ℹ 
 tests/testthat.R                 ✓ 
 tests/testthat/test-api.R        ℹ 
 tests/testthat/test-crosscheck.R ✓ 
 tests/testthat/test-download.R   ℹ 
 tests/testthat/test-info.R       ✓ 
 tests/testthat/test-search.R     ℹ 
────────────────────────────────────────
Status	Count	Legend 
✓ 	4	File unchanged.
ℹ 	8	File changed.
x 	0	Styling threw an error.
────────────────────────────────────────
Please review the changes carefully!

---

Reviewers: @tts and @njahn82
Due date: 2020-07-01

[mcguinlu]

Hi @maurolepore

Thanks for your inital review of our package. I've gone through it and try to address each point below:

ml1: Overlap with fulltext
Personally, I think that fulltext and medrxivr should continue to be two seperate packages, but that there is the potential for intergration between the two (as occured with the aRxiv package). In all honesty, I completely forgot to reply to the issue on fulltext 🤦‍♂️- sorry @sckott! The reason I think they should be seperate is two fold:

• In the first instance, the two packages take fundamentally different approaches to searching. At present, the medrxivr workflow is to create a local copy of the whole medRxiv repository via the API (or maintained static snapshot), and then search it locally using the mx_search() function to find relevant articles [i.e. all data -> local search -> results]. In comparison, fulltext takes the same approach to search bioRxiv as the biorxivr package does (note: medRxiv and bioRxiv are very similar, so I am using fulltext's approach to bioRxiv for comparison here). They both paste the search (see this code line) on after the base URL (https://www.biorxiv.org/search) and scrape the resulting page(s), essentially mimicing what would happen if you performed a search on the site itself [i.e. remote search -> results]. The search functionality offered by this approach is dependent on what the site itself offers, and so therefore is not as comprehensive as that offered by medrxivr (e.g. you can't use regexes to define capitalisation/alternative spellings, or use the NEAR operator). In addition, using the search functionality of the site itself (i.e. by pasting the query onto the search/ path) has been shown to not be very reproducible/transparent, which is what originally motivated the development of medrxivr.

• Secondly, as far as I can tell (correct me if I am wrong @sckott), search strings for fulltext do not vary based on the database searched - for example, if you use ft_search() without specifying the source, it uses the same string to search every database. This would cause issues for anything beyond a simple search, as medrxivr allows for advanced search strings that would not be compatible with other data sources. Based on this, my argument is that medrxivr should be a standalone full package, and a simple restricted version of the medrxivr search could be implemented in fulltext, provided @sckott is happy to implement the medrxivr workflow [i.e. download data then search] within fulltext.

ml2: Overlap with biorxivr
Thanks for highlighting this. I did come across this package while developing medrxivr - however, the last work on this package took place 5 years ago, before introduction of the API which you refer to in your query. In addition, while the base URL of the API contains "bioRxiv" (e.g. https://api.biorxiv.org/), this is only because the same organisation (Cold Spring Harbour) is responsible for both repositories. The actually endpoint for the medRxiv API is https://api.biorxiv.org/details/medrxiv/[interval]/[cursor]/[format]. Finally, as mentioned above, biorxivr relies on the search functionality offered by the site (e.g. by pasting the query on after the search/ path) rather than performing the searches itself.

ml3: Spelling
I've added this as an issue (ropensci/medrxivr#4) and plan to address it soon.

ml4/ml5: Test coverage
In hindsight, I should have highlighted this as a potential sticking point in my inital submission. The single file which is dragging down the average coverage contains mx_download(), which takes the dataframe of records identified by the user as relevant and downloads a PDF for each one. In fact, this function has a test suite (see https://github.com/mcguinlu/medrxivr/blob/master/tests/testthat/test-download.R), but because it manipulates files and folders on a users machine, I have these tests set to skip_on_CRAN, which in turn means that covr doesn't pick them up. This is something I was hoping to get feedback on during the review process, as I am not sure if this is best practice or what a viable alternative would be?

ml6: styler
I've added this as an issue (ropensci/medrxivr#5) and plan to address it soon.

Hopefully this addresses your inital concerns, but please do let me know if anything is unclear, if my responses are insufficient, or if you need further details!

[maurolepore]

Thanks @mcguinlu! I think {medrxivr} merits to move to the next stage. I'll now start searching for reviewers.

ml1 and ml2

Here is my conclusion. I base it on your answers above, and on this quote from rOpenSci's
guidelines on overlap:

"An R package that replicates the functionality of an existing R package
may be considered for inclusion in the rOpenSci suite if it significantly
improves on alternatives in any repository (RO, CRAN, BioC) by being ...
better in usability and performance".

I considered the packages {medrxivr}, {fulltext} and {biorxivr}. I see an
overlap in what the packages aim to do but not in how they do
it. This would not justify the overlap in general; but in this case I think it does.

Compared to the other packages, {medrxivr} searches locally. This ensures the
results can be reproduced; and enables searching with regular expressions. The
different approach to searching also means that to integrate {medrxivr} into
the other packages seems challenging. This might be eventually possible,
but first {medrxivr} may need to mature independently.

ml3 to ml6

@mcguinlu, please let me know or check the boxes as you address these issues.

ml7

@mcguinlu, I see the positive aspects of the "local" approach to searching that {medrxivr} implements; but I understand that {medrxivr} downloads the entire database. I worry this may not scale up. Here are some questions I have; you may discuss them directly with the reviewers:

• How big is the database? How fast does it grow? And how long does it take to download it in a range of reasonable conditions? What happens in a range of extreme conditions?
• Is the process transparent and "polite" to the user?

Maybe you can avoid downloading the database and still provide flexible queries. For example, see how pkgsearch::advanced_search() does it -- apparently it uses elastic, which supports regular expressions, wildcards, fuzziness, and more). If you implement something similar you might get some guidance from @maelle; she is one of the two developers of pkgsearch::advanced_search().

[maurolepore]

@mcguinlu, please do this (from these guidelines):

add a rOpenSci review badge to their README, via rodev::use_review_badge(), rodev::use_review_badge(<issue_number>). Badge URL is https://badges.ropensci.org/<issue_id>_status.svg. Full link should be:

[![](https://badges.ropensci.org/<issue_id>_status.svg)](https://github.com/ropensci/software-review/issues/<issue_id>)

[maurolepore]

(ml8) @mcguinlu have you suggested any reviewer?

(The editor guidelines suggest you might but I fail to find them here or at #369.)