science-collective / scoping-review Goto Github PK
View Code? Open in Web Editor NEWA scoping review of open collaboration within scientific research
A scoping review of open collaboration within scientific research
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/pubmed-search.R
And have as its own section in the paper or something?
There's a lot of irrelevant stuff with covid, but some is very relevant....
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/medrxiv-search.R
This is a great resource! https://openalex.org/ Has an API, connects many many sources (interestingly, not ones like Scopus, bioRxiv, or medRxiv, the same ones we were struggling with). Might be easier to switch to those? Or another time maybe 😛
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/biorxiv-search.R
Would be nice to start using something like this to indicate our contributions: https://credit.niso.org/
Based on our discussion during the meeting.
This is a databank for useful resources on how to conduct scoping reviews. Please add here as we go along.
This is based on the initial links provided by Hannah and additional searches.
Key papers describing scoping reviews:
Arksey & O'Malley 2005: https://www.tandfonline.com/doi/abs/10.1080/1364557032000119616
Levac, Colquhoun & OBrien 2010: https://implementationscience.biomedcentral.com/articles/10.1186/1748-5908-5-69
Seminar from Cochrane:
https://training.cochrane.org/resource/scoping-reviews-what-they-are-and-how-you-can-do-them
Guidelines for conducting scoping reviews
Joanna Briggs Institute: https://jbi-global-wiki.refined.site/space/MANUAL/3283910770/Chapter+11%3A+Scoping+reviews
Guidelines for reporting scoping reviews:
PRISMA checklist: http://www.prisma-statement.org/Extensions/ScopingReviews
PRISMA description paper: https://www.acpjournals.org/doi/10.7326/M18-0850
Scoping review of scoping reviews
Tricco et al. 2016: https://bmcmedresmethodol.biomedcentral.com/articles/10.1186/s12874-016-0116-4
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/zenodo-search.R
To automate exclusions at the title level
Hi all,
Since last month I have been unable to run pubmed-search.R. For some reason, make_df_from_pubmed() function generates an empty dataframe. Last month I figured out that this is solved when the encoding is not specified in batch_pubmed_download() function. It is possible that this is just an issue with how my computer handles these issues, but please check it out just in case.
My current function looks like this:
pubmed_search <-
batch_pubmed_download(
pubmed_query_string = search_terms$pubmed,
dest_file_prefix = "open_collab_"
)
E.g. some articles that talk about openness etc don't actually follow one of the basic principles of openness... that being accessible to read.
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/arxiv-search.R
This is a huge topic and hence we want to break it down into smaller more manageable chunks.
Suggestions for subtopics (science-collective/admin#5 (comment)) are:
For each of these topic we could have outline a general process of how we want to work with these topics.
A suggestion could be:
This would give us time to dive into each subtopic and build this initiative brick-by-brick.
Moved from protocol:
Research question:
Searches:
Data sources:
Screening:
Data synthesis:
Resources:
ACTION POINTS:
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/figshare-search.R
Here are the first minutes for the scoping-review Discord chat held on 21-02-2022. I love doing minutes, since it helps me understanding what has been done and what should I do next. As @lwjohnst86 suggested, there is no need to have these for every Discord chat, since they are mostly informal, but I believe that today's chat had some nice things I would like to come back to.
After I joined here are some of the highlights:
@danielibsen suggested whether we should look for examples of best practices on open science and @lwjohnst86 commented that that could be a second project, following this one.
We discussed the objectives @lwjohnst86 wrote. From this I realized there are two sections: the introduction and the scoping-review itself. In the introduction we should discuss about the definition of science and maybe we should open an issue.
Shall we only include open science publications? We discussed about how hypocritical not doing so might be. @hchats pointed out that if we use it as filtering criteria, it is going to be reported in the methods and for me that is making a strong statement or a "declaration of intentions".
@hchats also commented about doing a pre-survey on what topics should we focus on in the scoping-review.
We still need to think about the best way of doing the reference list.
I was wondering what the best way of collaborating and knowing what to do in a non-hierarchical structure is. We discussed about it and I will add some ideas on some workflows in this issue: #3.
I think that sums it up! Please add in the comments anything I might missed, misheard or if you want to discuss something about it!
@hchats and @MarioGuCBMR please review the protocol at https://github.com/science-collective/scoping-review/blob/main/doc/protocol.Rmd
Everyone else please add your institutions to the metadata at the top.
Linked to ideas here: science-collective/admin#5
Specifically comments:
What I've gotten from the discussion so far is to:
I have been doing some tests with R libraries such as easyPubMed or rscopus. It would be interesting to have a folder where we could put our code so that people can glance it over and help. What are your thoughts on the best way of doing this?
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/scopus-search.R
In data/review/fulltext/pdfs/
.
Maybe when we go through the papers we select we can decide if this is necessary.
I'm trying to run the Scopus code but I can't get the API key to work and I've created several. Neither the rscopus
package website has much information on this, nor does Elsevier's website. I'm close to considering we exclude any database that requires a substantial amount of work to access.
Thoughts?
Prof Bouter suggested that we contact the key people at the following organizations:
Prof Bouter suggested the following articles as a starting point:
Hi all,
I have been trying to reproduce the code for arxiv and medrxiv, but an error occurs when the query is done. The problem lies when using the function search_terms from search-terms.R.
As you know the function returns the search terms according to the "engine" you introduce as input. Right now the arxiv and medrxiv code load this as:
query = search_terms$medrxiv #this seems like search_terms was a dataframe with the searching terms once, but now it is a function and, of course, the code fails.
To solve this issue we just need to properly call the function:
query = search_terms("medrxiv") #this solves the issue!!
If you give the thumbs up I will change the code accordingly!!
As discussed in our meeting, I'll fetch the abstracts for us to review after the title screening, and do the same thing as we did for the titles.
Not the most important thing, but after going through the output of pubmed-search.R, I have noticed that with the current query we get lots of noise from medical and technological papers. Here are some examples:
"Oxygen vacancies in open-hollow microcapsule enable accelerated kinetics for stable Li-S battery."
"Predicting major complications in patients undergoing laparoscopic and open hysterectomy for benign indications."
Clearly, the word open is used for many more topics than we were expecting. Those two seem like an exception, but the amount of noise is actually quite big and, though unavoidable to some extent, there might be some ways of mitigating it. If you think it is necessary, we can use this issue to highlight terms that are found more than once and that can be used in query.
For instance, I have seen more than twice the following terms:
"open fracture"
"open-label"
Since we want to follow a "one output = one repository" format. Doesn't have to be done right now though.
Whatever task we work on, we should follow scoping review guidelines (e.g. #10). Everything is at this point in rough draft stage, but we should be working as much as possible to fill out the doc/review.md
and doc/protocol.md
file (and other supporting documents).
doc/protocol.md
and more detailed in the Methods of the doc/papers.md
and in the CONTRIBUTING.md
documentdoc/protocol.md
)(Inspired from manual)
doc/paper.md
)(More will be added here as we go on).
Following the TODO added by @hchats in the protocol, maybe we should add books. A maximum of 4 books should be added after reaching a common consensus among the collaborators.
In this issue I suggest that we discuss of the best strategies to look for books (if they differ to those used for other type of data) so that they can be added in the protocol accordingly.
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/wos-search.R
Write functions that will extract from the source and download to the repository. To finish this issue, we don't need to download and save the data from the source, we only need the code.
Code should be placed in: R/embase-search.R
Note: This checklist was generated with the script
R/extract-prisma-scr-checklist.R
.
The checklist can also be found atdoc/instructions/prisma-scr-checklist.md
.
Title:
Abstract:
Introduction:
Methods:
Results:
Discussion:
Funding:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.