Inspired by talks at the International Workshop on Science Gateways a few weeks ago, in particular keynotes by David De Roure on Social Machines and Michelle Barker on the evolution of Science Gateways, I started thinking about what would happen if we considered all computational and data software in the form of science gateways.
The definition of a science gateway has shifted a bit over time. In (Wilkins-Diehr et al 2008), it was defined as providing “access to high-end resources such as supercomputers and data archives through application-oriented interfaces designed by science community members.” And at that time gateways could involve more than just the web portals that they are most often seen as today: “science gateways typically operate through direct Web access or downloadable client programs.” Since then, the resources accessible via science gateways have increased beyond just HPC and data, and the interfaces have become more common. Today, a summary paper under review by FGCS (Michelle Barker at al., “The Global Impact of Science Gateways, Virtual Research Environments and Virtual Laboratories”) defines science gateways as providing “integrated access to research community resources including software, data, collaboration tools, workflows, instrumentation and high-performance computing, usually via Web and mobile applications.” In other words, science gateways provide easy integrated access to integrated community resources.
We might ask: When we wouldn’t want our resources to be available to others? And when wouldn’t we want the access to be easy? Could we teach people to develop software by always starting with the idea of a user community and what functionality they most want? Could all software be designed with a web page as the first user interface? How do we actually make things integrated?
All software would thus be public and accessible (and while this doesn’t solve the problem of discovery – how users find the software they want – it also doesn’t make it any worse than it is today.) This would be good for reproducibility (if we figure out how to document versions and keep old versions accessible.)
This reminds me a bit of the Network for Computational Nanotechnology Cyber Platform, (aka nanoHUB), where a large number of computational tools have been developed and are available to be used. These tools use one of two interfaces. The older interface is Rappture, where a developer describes the inputs and outputs of their tool in XML, and then fills in the methods of the tool within a structure generated based on those inputs and outputs. The newer interface is Jupyter’s dashboard, where a user creates a Jupyter notebook that contains their tool, then lays out the input and output cells, and hides the other cells. Of course, while each tool can have an integrated view of the underlying resources, integration of the tools themselves is still a challenge.
In other words, why shouldn’t we use the idea of a science gateway as a model for all software? Why shouldn’t all software be aimed at a community of users from the start? I don’t have all the answers, but some thoughts are:
- Maybe reuse and remixing would be harder? Or could we think of workflows of services?
- How do we design software to be integrated?
- Is this recreating web services?
- Some people will want to do more advanced things with the software, but having a simple interface doesn’t prevent them from digging into the code and developing or using another interface as well.
Acknowledgments: Thanks to Michelle Barker and Nancy Wilkins-Diehr for helpful comments on a draft of this post.