Collaborations for OSrPRE API intergration

[dasaderi]

• [ ] ResearchGate (ongoing conversation) - so far all they have done is link to OSrPRE in their Resource page of the COVID-19 effort they just launched;

• [ ] Observable notebook (Mt Sinai). They have ~100 reviews as docx files (with the DOI in the name) on Dropbox and they would like to upload these reviews to the PREreview site. They also want to be able to pull these reviews into the Observable notebook from our site after (using the DOI - which seems like this is possible).

• [ ] covidpreprints.com (ongoing conversation) - covidpreprints.org: They said they want to look at how we could incorporate our API into the preprints on their timeline and asked for ideas on how to implement that. The code for their site can be found on github 

• [ ] SemanticScholar (Daniela needs to reach out)

• [ ] bioRxiv/medRxiv (we had our meeting with Ted and Richard - see #116 for follow-up)

[sajacy]

I took a look at the Mt Sinai reviews on their Github. It seems they're trying to standardize on a Markdown format (that's great!).

A couple ideas / questions:

• It's easy enough to create some scripts to scrape and parse these Markdown files, but the format is quite different than the review questions + free-text that currently exists on OSrPRE. Would you want to adopt some of the sections? How about the tags/keywords? There are some sections like "Main Findings" which seem to range between 1 paragraph to a couple pages of content, and would be problematic to properly render from multiple reviewers.

• As more reviews are completed, it would make sense to get notified. We could create a Terraform or similar CICD-style task to import Markdown files via Github webhooks?

• The folks using Observable can already hit the API to get a feed of what shows up on the OSrPRE home page. I can setup an example Observable snippet.

  • The covidpreprints.com folks are copying the Mt Sinai reviews. We can help them avoid that work by also giving them a feed driven by our API. It would also be some Gist or code snippet. It would be straight HTML+JS, but I don't know how R works, so they'd have to do the integration themselves (hopefully just a copy-paste).

thoughts? cc: @georgiamoon

[dasaderi]

@sajacy Thank you so much for your work and suggestions. We just got an email from the group at Mt. Sinai saying, as you mentioned, that they have the reviews are being publicly posted to GitHub as Markdowns on this repo: https://github.com/ismms-himc/covid-19_sinai_reviews.

Also, they are pulling the reviews from this repo into the Observable notebook using the GitHub API: https://observablehq.com/@ismms-himc/covid-19-sars-cov-2-preprints-from-medrxiv-and-biorxiv.

They suggest to directly upload the reviews to PREreview directly from GitHub.

Similarly to the point you raised, Outbreak Science Rapid PREreview has a format with a structured questionnaire with two optional editing boxes. https://prereview.org, platform we would like to eventually merge, has the space for longer reviews of the type they have here.

I see the following possible course of action here:

1. We direct the reviews to https://prereview.org. PROS: that’s what the site is for, longer reviews. CONS: they will be buried in that ugly website which no many people are paying attention to and it’s not a COVID-19 specific material.

2. We add a larger optional editing box to the rapid reviews and ask the authors of those reviews to fill out the form at the top before we can post them there. PROS: That way we get the rapid reviews and the longer ones all in one place. CONS: it’s more work and it kind defeats the design of hosting rapid reviews (even though I personally think in this case we need as much conversation as we can get).

Tagging can also help make the content discoverable. Right now the user on OSrPRE has to tag the reviews with the "2019-nCOV" tag. But perhaps there is a way to search for keywords in the title of the preprint and abstract to automatically tag these preprints/reviews/requests? - refers to issue #83.

[georgiamoon]

@sajacy I've been debating a few ideas here, because the longterm goal that we need to map out is to merge the code bases supporting PREreview and rapid-prereview together.

The idea that I've been discussing with @rudietuesdays @dwins and @dasaderi is to introduce a "type" or "template" to the attributes for a PREreview, and then allow for a choice of template:

• rapid form
• long review
• rapid form + long review

where a long review can have some formatting (e.g. the Mt. Sinai format or similar to the template options on prereview.org)

Then I think we want to help document/enable how the Mt.Sinai folks could post to OSrPRE using the API, where their templated long review would get posted as a prereview with the "long" review template, if that makes sense?

We'd also need to expose "long" reviews in the interface on OSrPRE, which based on a conversation @dasaderi and @majohansson and I had tonight I think could look like a list reviews below the rapid review synthesis if that makes sense, and then open to a view of the one longer review.

If we can sort this out, we can also merge over prereview from preview.org and actually move towards merging the platforms faster.

[dasaderi]

Update on possible API standards that would allow for integration with preprint servers:

• Way to query if the review(s) has been requested by the author and if the review(s) has been moderated. Preprint servers want to know that to eventually display the reviews on their sites but only those for which the authors have driven the request AND that have been moderated. This could be done by matching ORCID iDs for example but there are potential issues with this such as that not every author of a preprint has orcid ids. It could be a name matching and/or ORCID iD, but potential to be gamed. Potentially request for review happens on preprint server at time of submission and we get that "secure" query to display on OSrPRE.

• If reviews not "author-driven" then preprint servers may still want to link to reviews on our site but they would not necessarily agree to displaying that content.

[dasaderi]

We heard back from bioRxiv. Richard said " If you can supply a feed of the articles we can add trackback links to them from bioRxiv." Can we already do this with the current API? @rudietuesdays @jheretic

[georgiamoon]

Related to https://github.com/PREreview/prereview-standup/issues/111