Describing models on the web using OGC standards

Environmental decision support systems normally require a data processing workflow based on models to explore alternatives. The typical workflow to handle environmental modelling involves several steps covering data discovery, access, pre-processing, model execution and validation, concluded by result visualization. These time consuming steps are usually setup for a particular scenario and set of input data. Scientists normally create their models in specific languages such as R or MATLAB. A challenge is understanding the data model of the scientists and getting the data into the model. In general, scientists are also not able to make their models available as web services. To make scientific models that fuse sensor data fit better into a service-oriented architecture, a software framework called Fusion4Decision was developed. The software framework provides a standard interface to processing algorithms, the so-called Fusors. The term Fusor refers to a general fusion or processing of input data, including through a model based computation. A common fusor is the spatiotemporal interpolation of measurement data. The Fusor is written in any software code that can be integrated into a Java environment, such as MATLAB, R, Python, and C variants. This framework based on Open Geospatial Consortium (OGC) standards can make scientific models available as a web service with standardized interfaces. The OGC services used in Fusion4Decision are: (a) Sensor Observation Service (SOS) to access sensor observations with queries filtering on the phenomenon (property) and the spatial and temporal domains of the observations, and (b) Sensor Planning Service (SPS) to parameterize and task (schedule and execute) assets such as sensors, sensor platforms (e.g. satellites), models or even persons (e.g. to conduct ex-situ measurements). The OGC information models Observation & Measurement Model (O&M) and Sensor Model Language (SensorML) also play a fundamental role. The main operations of the SPS are DescribeTasking (to get the tasking parameters), GetFeasibility (to ascertain if the asset can be tasked with the given parameters) and Submit (to actually execute the task). During the execution the operations GetStatus and Cancel are available. In Fusion4Decision we apply the SPS to models and the model result(s) become new observations for a SOS, i.e. the model is considered to be sensor and its meta-data is described in OGC SensorML. The SPS operations are functionally richer than those of the Web Processing Service (WPS) that is also often used to wrap processing modules as a web service. The formal description of the input and output arguments of the models in a language suitable both for scientists and client software is essential. The model description is encoded as a JSON object and consists of fields for the model name, a human readable descriptive text as well as formal descriptions of the inputs and outputs. The inputs and outputs allow for arrays of the basic variable types scalar, string, time, URL and file. Their description includes a) units of scalars, b) default, minimum and maximum values of scalars and optionally c) an annotation as a URI linking to an authoritative definition in an ontology. This covers the requirements of typical scientific models and also encourages the inclusion of comprehensive meta-data needed to convey full understanding of the model algorithm and its limitations. The JSON description of a model can be automatically translated into SensorML for use by the OGC services SOS and SPS. The increasing proliferation of sources of geospatial data on the web as well as models to process the data and derive new information underlines the need for a standardised framework to better link data, models and their results. Standards of the Open Geospatial Consortium can be used to integrate data access and models into web services, thus being a step towards the Model Web in which scientists and decision makers can work together effectively. The paper proposes a simple way of describing the input and output arguments of a model using JSON. This JSON description can be readily understood and generated by model providers and also translated into the sensor description language SensorML. The latter is the basis for applying the sensor concept in the OGC standards SOS and SPS to models (“model as a sensor”). This approach bridges the gap between scientists and IT specialists