Orbital v0.2 release

Today, we released Orbital v0.2, about a month after our v0.1 release. As per the roadmap, Nick and Harry have made good progress on project activity data, user role management, dynamic datasets and, based on user feedback, we’ve added the ability to organise data into collections. You can read the high-level change log or trawl through the project tracker, if you feel inclined. Paul has also made some notes with screenshots on some of the new features.

You’ll notice that there are now APIs for loading data into Orbital’s MongoDB store and querying it, too. This is now in use on a daily basis, retrieving turbine data from Siemens, loading it into Orbital and then running queries on it. It’s very fast. I might add that updates to the data are being versioned, too, so a researcher can query data as it was stored in the past. There’s much more to be done to make Orbital a versatile platform for data analysis during the research process, but the groundwork is in place.

As we identified in our Implementation Plan, we see a workflow whereby data can be selected from a project workspace (e.g. a network drive), loaded into the dynamic datastore, analysed, and then eventually selected for archiving alongside published research papers.

A Minimum Viable Product for Research Data Management?

I’m at a meeting at the University of the West of England, focussing on RDM for post-92 universities. I briefly presented the Orbital project, focussing specifically on how we approached the first release of the Orbital software and how software development, and the learning that takes place in that process, is one way to learn about and understand the RDM domain. I am in no way advocating a technologically determined approach – far from it, as this is very much a user driven development project, as is evidenced in the use case I outline.

Development roadmap

The first release of Orbital (v0.1) was on May 16th 2012. Orbital is a research and development project that has initial funding until March 2013. Given that timeframe, what follows is a high-level roadmap of where we expect development to go over the next few months.

We plan to release a new, working version of Orbital around the beginning of each month, up to December 2012, when we hope to hit v1.0. We plan to have a further point release in February, based on user feedback and then give ourselves a month to tidy things up and wind down this phase of the project.

You can read our implementation plan, check out our responses to user feedback and watch our project tracker for more details. The code can be downloaded here and here. Be aware that the roadmap may change at any time, based on user requirements, illness and natural disaster.

v0.1 (May)

See announcement. Authentication, user profiles, projects, upload of flat file data, a license picker, private and public archives, publish to the web, stable identifiers, download of flat files, analytics, and a way to give feedback.

v0.2 (June)

Documentation (for both developers and users), activity data, working/dynamic datasets + APIs, app access (OAuth), bug fixes, responses to feedback.

v0.3 (July)

User workspaces, version control, data staging (workflow), data snapshots, tools for basic analysis of datasets.

v0.4 (August)

EPrints integration (SWORD2), integration with Lincoln’s Award Management System (Worktribe), APIs for discovery, full role/permissions management, documentation.

v0.5 (September)

Plugins for third-party tools (e.g. Matlab)

v0.6/0.7/1.0 (Oct/Nov/Dec)

Network drive for desktop workspaces, full documentation for RDM, DataCite, ORCID, DMPOnline integration, improve design/branding, federated access.

Happy Christmas!

A Minimum Viable Product: Orbital v0.1

This is a post about our first release of Orbital.

About a month ago, Dr. Tom Duckett, Reader in The Department of Computing and Informatics approached the Orbital project because he urgently wanted to publish around 20GB of data for Long-term mobile robot operations. That afternoon, we gave Tom and Feras Dayoub, his Research Assistant, space on one of our servers and they uploaded a bunch of HTML pages and the zipped up data. We minted a proxy URL for them and advised them on an appropriate data license to choose.   We also set up Google Analytics, so they could see what interest in his data there was.

Job done. For the time being.

What Tom really wanted was to be able to email a link to his data to a robotics mailing list and tell an international community of likeminded researchers and manufacturers that the data was available to use. He says that long-term datasets for mobile robots are quite rare in his community, so there was a good chance people would be interested in them. He also wanted to be able to demonstrate his work when writing an EU bid. There will be a follow up blog post about what impact this has had on Tom’s research.

That afternoon got us thinking: What is the minimal set of functions that a researcher like Tom requires of a Research Data Management tool?

Tom wanted access (sign in) to a server (hosting) where he could upload his data (storage) and describe it so that other people could understand and download it (publish) under an appropriate license. The URL pointing to the data should be persistent, even if the data itself is migrated from one system to another. The impact (analytics) of the data should also be measurable.

Tom’s chance intervention in our project made us focus on Orbital v0.1 as the ‘minimum viable product‘ for researchers who need to publish open data. We thought his requirements were a great opportunity to release something early and start getting direct user feedback on our product. We decided to set a release date for Orbital v0.1 a month ahead and aim to deliver everything that Tom asked of us in this first release.

A Minimum Viable Product has just those features that allow the product to be deployed, and no more.

Today, we released Orbital v0.1 and it does everything described above. It’s an alpha release, but we’ve been testing it like crazy, we also had Feras test it and we’ve been pushing code through Jenkins since the beginning of the project so we know it passes our QA checks and we think it’s stable enough for use. From this point forward, Orbital and the URIs it mints will persist, too.

From today, a researcher at the University of Lincoln can sign in to Orbital, create and describe a project, upload their data to the project, choose a license for the data and add a Google Analytics code to measure project analytics (we’re also tracking each button click to better understand how people use Orbital). The data is published at a id.lincoln.ac.uk URI, which will persist indefinitely. At this stage, until we’ve got an approved business case for scaling it up and out to all academics, we’ll be limiting uploads on a case-by-case basis. You can view and request what other features we develop for Orbital on UserVoice, or in more detail on our project tracker. We’ve also written a basic development roadmap.

For developers, here are the basic technical details. You might also want to trawl through our implementation plan and the collected blog posts at the bottom of the plan.

Orbital is written in PHP using the CodeIgniter development framework.  It’s split into two main pieces of functionality. Orbital Core (database and APIs) is currently hosted on a Linux box on Rackspace’s cloud. Orbital Manager (the User Interface) is likewise hosted on Rackspace. A user signs in to Orbital Manager via OAuth 2.0 using their university credentials. Orbital Manager is using Twitter’s Bootstrap framework. The project metadata is stored in a MySQL database. Files are uploaded to Rackspace’s cloud files storage using Andrew Valums’s AJAX Uploader. APIs are exposed using Phil Sturgeon’s CodeIgniter REST server.

Orbital is licensed under the GNU Affero GPL 3 license and you can download, fork it and create pull requests on Github:

Orbital Core

Orbital Manager

New contributors to Orbital will be ritually applauded each weekday morning 🙂 Thanks.