Summary

At the moment OpenMI only supports exchange of quantitative data, which is not sufficient for certain environmental domains. Using OpenMI in these domains, or in projects that try to integrate such domains with others, is by consequence difficult. Support for other types of data, in particular qualitative data is needed.

Qualitative is in essence non numerical data (i.e. text, audio, video, categorical), in contrast to quantitative data (i.e. interval and ratio). Ordinal data (i.e. enums) can be considered to be somewhere in between. The previous examples of qualitative data (land use, crop types) can indeed be easily (to some extent) catched as enums (although useful implementation would have some problems; e.g. who defines the enum and how is it shared between models). Other examples (i.e. data as free form text) do not fit into this solution.

In the agro-environmental domain models are used (e.g. CAPRI, CLUE, EfiScen, Integrator) that for example forecast future land use based on scenarios of policy options. Or that generate rotations (sequences of crops farmers will plant) based on input parameters like soil conditions, technological development, weather conditions, etc. Also social and landscape indicators are used and processed that are very difficult to "quantify". For example a peron expressing her/his opinion about a possible future landscape.

How to address in Version 1

The proposed solution (as implemented in Alterra's internal OpenMI Java version) is to add a super interface for Data, with IQuality and IQuantity as specialisations. A Quality consists of a number of categories, which can be ordered or not. The definition of the categories and the proper use of them is a responsibility of the models (modeller) not of the OpenMI.

How to address in Version 2

The meta-information about the data (this includes the definition of the categories for qualities, but also of units for quantities) could be stored in an ontology or some other type of glossary making it more flexible to work with and easier for models to use the same definitions. Also IQuality can be improved to support more types of qualitative information.

  • No labels

3 Comments

  1. Unknown User (don)

    Ontology-based definition can be a bit too heavy for OpenMI. Qualitive data can be easily implemented using the following approach:

    interface IQuantity
{
   ...
   Type ValueType { get; } // note that it returns System.Type.
   ...
}

public enum LandUse { Soil, Grass, Forest };

public class LandUseQuantity : IQuantity
{
   Type ValueType { get { return typeof(LandUse); } }
}

public class QualitiveValueTypeTests 
{
   void GetLandUseTypeValueFromExchangeItem()
   {
      IComponent c1 = ...;

      LandUse defaultLandUseType = (LandUse)c1.Output["default land use"].Value;
   }

   void GetAllLandUseTypesFromLandUseQuantity()
   {
      LandUseQuantity landUseQuantity = new LandUseQuantity();

      Array landUse = Enum.GetValues(landUseQuantity.ValueType);
      Assert.AreEqual(landUse.GetValue(0).ToString(), "Soil");
      Assert.AreEqual(landUse.GetValue(1).ToString(), "Grass");
      Assert.AreEqual(landUse.GetValue(2).ToString(), "Forest");
   }

   void GetSoiltypeGridValues()
   {
      IComponent gis = ...;

      IExchangeItem soilTypeGridExchangeItem = gis.Output["soil type grid"];

      // check if ValueType of exchange item is grid coverage-like (element, land use type)
      Assert.AreEqual(soilTypeGridExchangeItem.ValueType, typeof(IDictionary<IElement, LandUseType>));

      IDictionary<IElement, LandUse> gridValues = (IDictionary<IElement, LandUse>)soilTypeGridExchangeItem.Value;

      LandUse element1LandUseType = gridValues[element1];
   }
}

  2. Rob Knapen

    I have updated the summary, the previous examples for qualitative information were perhaps too limited. Using enumerations (ordinal data) as replacement for qualitative data is at best a work-around (IMHO) and will not always work.

    As an example, for a scenario study a model could predict how the landscape will look like in the future and render it in 3D. A person could then be asked for an opinion, and enter it as free form text (qualitative information). This would need to be stored and exchanged to different models that analyses the text (entered by multiple persons also for other possible landscapes) and calculates some kind of (qualitative or quantitative) indicator for each landscape.

    1. Unknown User (don)

      Enumerations should be sufficient to store only singular categorial values.

      I agree that it is not enough to store other types of data. For more complicated data types (structures) we can use some ideas explained on 5. Extend types of information exchanged via OpenMI from time-dependent to more general.

Disclaimer