Skip to content
This repository has been archived by the owner on Sep 9, 2022. It is now read-only.

(Potential) new data source: medrxivr #213

Closed
mcguinlu opened this issue Mar 2, 2020 · 2 comments
Closed

(Potential) new data source: medrxivr #213

mcguinlu opened this issue Mar 2, 2020 · 2 comments

Comments

@mcguinlu
Copy link

mcguinlu commented Mar 2, 2020

Hello!

Following a presubmission enquiry to rOpenSci, I wanted to get in touch with you to make you aware of medrixvr, a new package I have been working on to help users search a daily snapshot of the medRxiv preprint repository using regular expressions and Boolean logic, and then download the full text PDFs of relevant records. It seems like medrixvr could be a useful additional data source in the fulltext package, based on the existing inclusion of the biorxivr package - would you be interested in incorporating it in the future?

If it is of interest, @annakrystalli also reccommend checking to see if there is anything I should be considering at this point (i.e. before submission to the rOpenSci peer review process) to ensure compatability of medrxivr with fulltext?

Thanks in advance!

@sckott
Copy link
Contributor

sckott commented Mar 3, 2020

thanks for the questions.

would you be interested in incorporating it in the future?

possibly, probably. i can't say for sure because e.g,. with biorxivr i did use that package in fulltext at one piont, but since have removed it and implemented biorxiv search within fulltext itself. reasons for not using a package here include if the package does not work reliably, or the interface for me to hook into it in fullltext is too difficult to work with.

most likely ways to tie your pkg in here would be for the functions ft_search (search for articles) and ft_get (download full text articles)

in terms of what you could consider:

  • ft_search: if there's any pagination that can be done by the user in your search functionality I'd need to be able to let fulltext users control those parameters.
  • ideally you'd allow users to pass in curl options for any http requests - and then here in fulltext I can let users pass curl options down to your package
  • ft_get: for downloading files, i'd prefer a http package, e.g, crul rather than using download.file, that way http request errors have proper error handling

@maelle
Copy link
Contributor

maelle commented Sep 9, 2022

This repository is about to be archived.
If you develop a related package, it might be in scope for https://ropensci.org/software-review/

@maelle maelle closed this as completed Sep 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants