Traditional modelling and data analysis techniques involve installing software, collecting data from a variety of sources, preprocessing the data, and evaluating models on a local machine. With everything owned and operated locally, the process becomes very expensive and time consuming. Interoperability — the ability of diverse systems to exchange and use information — is one of several factors limiting the application of models. Without interoperability, communication be- tween multiple models and data stores is challenging and often extremely limited. Terminology to describe common properties may vary between other modellers, researchers, and policy mak- ers. These users also face restrictions on model access and availability. Increasing the availability of, and interoperability between, models and resources can help to improve modelling and data analysis in various domains (Zhao et al., 2012).
The Model Web is a generic concept envisioned to enhance model interoperability, ultimately providing better access to and interaction between models (Nativi et al., 2012). Consisting of a system of interoperable components, the Model Web utilises Web services to provide machines and users with access to models and data stores (Geller and Turner, 2007), and places no restric- tions on the size and quantity of these components. Detailed modelling scenarios often depend on contributions from multiple disciplines. For example, predicting the effects of climate change on wheat yields may involve models from many domains, including climate, edaphology and eco- nomics. As a result, since its original definition for the purpose of ecological forecasting, the Model Web concept has been proposed across various domains.
The idea of interoperable models and data stores is nothing new, and there are many frame- works available for model integration (Bastin et al., 2013). However, interoperability has in the past only been achieved within small groups of services, often from the same organisation. The Model Web seeks to remove these boundaries, and has the advantage over other frameworks of
utilising the existing Web infrastructure, allowing models and data to be shared across the globe, and integrating components from a variety of sources.
SOA is a methodology for providing software applications as interoperable services (Papa- zoglou, 2003). A SOA consists of reusable software components, each representing a modular block of well-defined functionality. By combining several components in a SOA, complex func- tions and workflows can be constructed. This can serve as the basis for distributed computing and an interoperable framework of collaborating applications. The Model Web can be considered as a SOA, with each model, or simulator, built as a software component. It may be desirable to de- compose a complex model into several smaller pieces of functionality, providing that the smaller pieces form useful and reusable components. A data store is also built as a software component, and communicates with the model by passing data in a standard format.
While Web services are not a requirement for SOA, they are commonly how such architec- tures are implemented, and therefore fundamental to building the Model Web. Exposing a model on the Web presents many opportunities for sharing, reuse, and workflow composition. Imple- mentation is platform and language agnostic, and updating a model only requires the installation on the service to be changed, as clients are only communicating with this single instance. The interoperability provided by the Web can allow us to build generic tools. If model’s inputs and outputs conform to a set of data types, it may be possible to use any software that supports those data types, and neither the developer of the model or software need write specific code to interact with an individual model. A layer of abstraction is provided by service interfaces, allowing clients to specify input data and execute service operations without specialised knowledge of the under- lying implementation. One of the major challenges faced in the construction of the Model Web is reaching a consensus on Web service communication protocols and data encoding. Available protocols and data encoding standards are discussed in Section 2.4.
Although still a relatively new concept, Model Web components have been developed by various parties. eHabitat, a model for assessing the relative importance of protected areas in Africa (Dubois et al., 2011), is one example of a Model Web component. The implementation of eHabitat as a Model Web component is designed to extend participation of the scientific com- munity, and create usage opportunities in scenarios not originally considered when developing the model. For example, if the output from a climate change model is used as input data, eHabitat essentially becomes a service for assessing the impact of climate change in protected areas.
When executing complex workflows involving several components, all of which are sources of uncertainty, the final output must provide information on the quality of the result, a matter which is increasingly important where intermediate results may be inaccessible (Skøien et al., 2011). Although uncertainty propagation support for the eHabitat component was implemented by Skøien et al. (2011), there are few examples demonstrating propagation in a workflow — from uncertain inputs, through several components, to representation in an uncertain output.
Full utilisation of the Model Web — widespread integration of independent, multidisciplinary models — is yet to develop. As discussed in Section 2.2, tools for performing SA on a model or building an emulators are currently restricted by software package or platform, and can require much pre-processing to transfer data between model and tool. The interoperability provided by the Model Web presents an opportunity to create Web-based tools which, as a result of standard interfaces and data formats, are compatible with an unlimited amount of models. The development and use of such tools is an unexplored area.