From an eLife developer

Inside eLife
  • Views 124
  • Annotations

By Graham Nott, eLife Developer

I was invited to write my inaugural blog post. "Describe your experience working as a developer with eLife". It is a privilege to be part of the team at eLife. I'm taking this opportunity to mix in some commentary along with details about the eLife API.

January of this year, I was contracted to provide some technical assistance in launching eLife's first website. Ostensibly I was to configure CRM software, but as with any new venture additional needs arise: to help evaluate hosting technology, domain name configurations, email redirects, fix small things, and test to make sure nothing blows up. There was lots of effort spent on making good decisions and getting the details right.

Months later the project I really wanted came along: an eLife API prototype. The initial project requirements were very basic: some target use cases, XML input, Python language parser, and to use Fluidinfo. There was just enough for me to produce a rough scope and timeline, and despite all the unknowns, I was looking forward to the challenge.

I had never heard of Fluidinfo, so I will not be surprised if you haven't either. Essentially, it makes the read-write web possible. Anyone can write data to the same place eLife data is stored. It has the potential to make data social, or at the very least collaborative. If you only want to consume read-only data, you can use it for that alone. Fluidinfo lays the foundation for additional tools, and for anyone to discover and use eLife data in interesting ways.

Years ago I read this (paraphrased): An ideal database administrator (DBA) is not one who restricts access, but one who grants privileges so a user can get their work done. The concept of granting privilege taking precedence over controlling access has stuck with me ever since, and it applies to more than just databases. Providing access to tools, documentation and training empowers users. You can be a data steward without controlling it.

Sharing is the default at eLife. It's a refreshing change from my previous experience developing in closed environments to hear that eLife is embracing a read-write environment, and is also planning to release open source software. The API is populated with data right now, and the code that parses XML and publishes the data will be released very soon. It's still early days, but it *seems* to be working.

If you're not already aware, code is shared at eLife's Github:

API documentation and more can be found at:

I'm new to the scientific publishing realm, and there is a vast amount of domain specific knowledge to read up on. NLM? DOI? Ingelfinger? Coming from outside gives me a different perspective. I think my role is to build things based on the good ideas handed to me. It includes to simplify complexity, expand limits, evaluate alternative choices, test things, report back findings, or implement a solution. These are the things that make me want to get up in the morning and go to work.

When used effectively, technology should lower barriers of entry and promote interaction and contribution. You can be assured that everyone at eLife is putting in untold hours perfecting the final product so it is most useful and effective.

For you, the reader, it may be something else that excites you about eLife: submitting your own research, reading published articles, uncovering trends in the metrics, leveraging disruptive technology, or participating in a community. Hopefully by creating additional tools, citation formats, and publishing endpoints, eLife will allow you to more easily access the content and data.