## 4 Formalization of the Integration Approach
### Generating Value-Added Information  
Now, as the foundations are available, we focus our attention on the transitions from the raw data (innermost layers in Figure 2, see Section 2.3), to any added value, _i.e._, processed information (outer layers the diagrams). These constructs are application dependent; the forest fire example serves for illustrations. We introduce constructs that represent the results of a transition (the next outer layer in the diagram), and formalizations of the systems, which perform the actual transition between two layers, such as the creation of hotspots. In analogy to the observations data types above, the former can be seen as ADTs, which provide unique entry points to each layer, such as hotspots and forest fires. They encapsulate the manifold possibilities in which a single instance might have been produced. As a first example, we create a type for capturing hotspots as a specific kind of value-added information. Each hotspot represents a set of observations results, which can again be encapsulated by a single data type:  
\[\textbf{type}\;\text{Hotspot}=\text{ObservationResult}\]  
Notably, as we use the type construct, hotspots can be handled just as any other observation result. We use the same mechanism to distinguish forest fires:  
\[\textbf{type}\;\text{ForestFire}=\text{Hotspot}\]  
Having the types for representing measurement results available, we are now able to specify systems implementing one or more processing step, _i.e._, the transition from inner to outer layers. For example, the CONAVI analyzer takes a VGI sensor as input and performs two steps, the identification of hotspots (e.g., Tweets mentioning burnt areas or on-going fires) and the categorization into forest fire information (e.g., the likelihood that the hotspot is actually about a forest fire, see also Section 2.1, Figure 1):  
\[\textbf{data}\;\text{CONAVIanalyser}\;\{\text{caInput}\;::\;\text{VGISensor, caHotspotResult:: Hotspot,}\] \[\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\; \;\  
* _Agents_: agentive physical objects, including those that can carry out observations, _i.e._ that serve as sensors, and tell about the results;
* _Stimuli_: enabling agents to perceive qualities, _i.e._, properties of some entity; and
* _Observations_: Given an available stimulus, the process of an agent generating an observation result through perception. Again following [43], DUL and SSN concepts can be formalized in Haskell as follows. The entity, which is able to observe its surroundings is called agent. As the most important behaviors, an agent can tell what it has observed:  
**class** AGENTS agent **where**  
tell :: agent \(\rightarrow\) ObservationResult  
Stimuli are emitted by an entity, related to a specific quality that this entity inherits. These can then be perceived by some agent. The result of this perception is a change in the agent's internal state, which holds a quale (to be modeled further down):  
**class** STIMULI quality entity agent **where**  
perceive :: quality entity \(\rightarrow\) agent \(\rightarrow\) agent  
Now, if there is a stimulus, the agent may perform an observation, in which the quale is mapped onto a communicable expression, which will be an observation result, as we show later:  
**class** STIMULI quality entity agent \(\Rightarrow\) OBSERVATIONS quality entity agent **where**  
observe :: quality entity \(\rightarrow\) agent \(\rightarrow\) agent  
Having this reference frame available, we can specify the common observation behavior of the previously introduced data types by instantiation. For reasons of brevity, we introduce only one full example (the VGI sensor) below and only indicate the instantiations of the other data types. A VGI sensor is an agent that can tell the full list of recorded VGI items, _i.e._, messages with position and clock time.