A new version of rentrez, our package for the NCBI’s EUtils API, is making it’s way around the CRAN mirrors. This release represents a substantial improvement to rentrez, including a new vignette that documents the whole package.

This posts describes some of the new things in rentrez, and gives us a chance to thank some of the people that have contributed to this package’s development.

🔗

Thanks

Thanks to everyone who has filed and issue or written us an email about rentrez, your contributions have been an important part of the package’s development. In particular, we welcome Han Guangchun as a new contributor to rentrez and thank Matthew O’Meara for posting an issue that brought the by_id mode for entrez_link (discussed below) to our attention.

• CRAN
• rentrez
• packages
• NCBI

We’re happy to announce the launch of a CRAN-style repository for rOpenSci at http://packages.ropensci.org

This repository contains the latest nightly builds from the master branch of all rOpenSci packages currently on GitHub. This allows users to install development versions of our software without specialized functions such as install_github(), allows dependencies not hosted on CRAN to still be resolved automatically, and permits the use of update.packages().

🔗

Using the repository

To use, simply add packages.ropensci.org to your existing list of R repos, such as:

• drat
• CRAN
• packages

Despite the hype around “big data”, a more immediate problem facing many scientific analyses is that large-scale databases must be assembled from a collection of small independent and heterogeneous fragments – the outputs of many and isolated scientific studies conducted around the globe.

Collecting and compiling these fragments is challenging at both political and technical levels. The political challenge is to manage the carrots and sticks needed to promote sharing of data within the scientific community. The politics of data sharing have been the primary focus for debate over the last 5 years, but now that many journals and funding agencies are requiring data to be archived at the time of publication, the availability of these data fragments is increasing. But little progress has been made on the technical challenge: how can you combine a collection of independent fragments, each with its own peculiarities, into a single quality database?

• reproducible research
• archiving
• open science

There are many different databases. The most familiar are row-column SQL databases like MySQL, SQLite, or PostgreSQL. Another type of database is the key-value store, which as a concept is very simple: you save a value specified by a key, and you can retrieve a value by its key. One more type is the document database, which instead of storing rows and columns, stores blobs of text or even binary files. The key-value and document types fall under the NoSQL umbrella. As there are mature R clients for many SQL databases, and dplyr is a great generic interface to SQL backends (see dplyr vignettes for an intro), we won’t delve into SQL clients here....

• databases
• key value
• sql
• nosql

There are two things that make R such a wonderful programming environment - the vast number of packages to access, process and interpret data, and the enthusiastic individuals and subcommunities (of which rOpenSci is a great example). One, of course, flows from the other: R programmers write R packages to provide language users with more features, which makes everyone’s jobs easier and (hopefully!) attracts more users and more contributions.

But what if you have an idea, or a need, but not the time or confidence to write a package for it? I can’t speak for this blog’s readers, but I’ve been writing R for about two years and it took a good long while before I felt comfortable contributing upstream to CRAN. Or, what if you do have the time, and do have the confidence, but want to spend that time well, on things that you know other people will find useful, and don’t know what that is?

• GitHub