Markus Stocker bio photo

Markus Stocker

Between information technology and environmental science with a flair for economics, the clarinet, and the world of soups and salads.

Email Twitter Google+ LinkedIn Github

Following the short intro on RDF, as well as on RDFS and OWL, this post is a walk-through the extraction of metadata about sensing devices used in net ecosystem exchange (NEE) research from various (PDF) documents, and the representation of such metadata using the Semantic Sensor Network (SSN) and GeoSPARQL ontologies.

SSN describes sensors, and observations made by sensors, and GeoSPARQL describes space, terms such as feature and geometry.

The sensing devices of interest here are those used by Shurpali et al. [1] for research aimed at understanding “the impact of reed canary grass […] cultivation on the carbon dioxide (CO2) balance of an organic soil.” The devices are pretty standard for eddy covariance measurement.

Let’s get started.


According to Shurpali et al., the eddy covariance system consists of a 3D sonic anemometer and an open path infrared CO2/H2O analyzer. The model of the sonic anemometer is CSAT3, manufactured by Campbell Scientific. The model of the open path infrared analyzer is LI-7500, manufactured by LI-COR. Shurpali et al. note that the sensing devices “are mounted on a tower at a height of 3.7 m above the ground and aligned at an angle of 225°.” The tower is located at the Linnansuo cutover peatland site with coordinates 62°30’N, 30°30’E. Measurement started in late March of 2004, and is ongoing (personal communication). Sampling frequency is 10 Hz.

There is quite a bit of information here, and we can find more.

Wikipedia tells us that the CSAT3 sonic anemometer is a type of anemometer. An anemometer is “a device used for measuring wind speed” and a sonic anemometer uses ultrasonic sound waves to do so. The LI-7500 sensing device is, specifically, a infrared gas analyzer.

Campbell Scientific provides information about CSAT3, including a (PDF) instruction manual. From the manual we learn, for instance, that the CSAT3 operating temperature is -30 to +50°C. Similarly, LI-COR also provides information about LI-7500, including a (PDF) instruction manual. Its operating temperature is -25 to +50°C.


The SSN ontology defines the class ssn:SensingDevice as a sub class of ssn:Sensor as well as of ssn:Device. The Campbell Scientific sonic anemometer and the LI-COR infrared gas analyzer are very specific types of sensing devices. Thus, we first create a small hierarchy of sensing device types. It states that anemometers and infrared gas analyzers are sensing devices and that sonic anemometers are specialized anemometers.

Anemometer rdfs:subClassOf ssn:SensingDevice
InfraredGasAnalyzer rdfs:subClassOf ssn:SensingDevice
SonicAnemometer rdfs:subClassOf Anemometer

Furthermore, we can specify that the Campbell Scientific CSAT3 is a type of SonicAnemometer and the LI-COR LI-7500 is a type of InfraredGasAnalyzer.

CampbellScientific_CSAT3 rdfs:subClassOf SonicAnemometer
LI-COR_LI-7500 rdfs:subClassOf InfraredGasAnalyzer

So far we have only a hierarchy of sensing device types of interest here. At the Linnansuo cutover peatland site, Shurpali et al. have two concrete instances of the modelled sensing device types. Let’s state something about what we know about them using the newly introduced terms. First, we name them and state their type.

 theLinnansuoLI-7500 rdf:type LI-COR_LI-7500
 theLinnansuoCSAT3 rdf:type CampbellScientific_CSAT3

The first line simply states that the LI-7500 deployed at Linnansuo is a LI-7500 manufactured by LI-COR. Actually, it doesn’t—I have read into the statement much more than a computer could, because the strings mean to me more than they mean to a computer, which only understands that the resource labelled theLinnansuoLI-7500 is an instance of the class labelled LI-COR_LI-7500. However, from the statements above a computer also understands that the resource labelled theLinnansuoLI-7500 is an instance of the classes labelled InfraredGasAnalyzer and ssn:SensingDevice. If you ask a system for all (known) instances of ssn:SensingDevice it would thus answer theLinnansuoLI-7500 (and, of course, theLinnansuoCSAT3).

According to Shurpali et al. the sensing devices are mounted on a tower. The tower acts as a platform for the devices and SSN provides a class for platforms. Thus, let’s name the tower at Linnansuo and state that it is a platform and also state that the two sensing devices are on the tower at Linnansuo.

theLinnansuoTower rdf:type ssn:Platform
theLinnansuoLI-7500 ssn:onPlatform theLinnansuoTower
theLinnansuoCSAT3 ssn:onPlatform theLinnansuoTower

The platform not only has a location but its location is accurately determined, namely 62°30’N, 30°30’E.

theLinnansuoTower dul:hasLocation theTowerLocation
theTowerLocation rdf:type dul:PhysicalPlace
theTowerLocation rdf:type geo:Feature
theTowerLocation geo:hasGeometry theLocationGeometry
theLocationGeometry rdf:type sf:Point
theLocationGeometry geo:asWKT "POINT (62.5 30.5)"^^geo:wktLiteral

The lines state that there exists a physical place named theTowerLocation. It is the location of the Linnansuo tower and a physical place. Physical place is a physical object and is defined by the DUL ontology, which SSN builds on. For the purpose here, we consider the class of physical objects to be equivalent to the class of physical entities, which in GML are features. Thus, the tower location is also a GeoSPARQL feature and features can have a geometric aspect, in this case a point for the location coordinates.

We also know that an anemometer measures wind speed and the LI-7500 measures carbon dioxide and water concetration in a volume of air. The SSN ontology supports stating the relation between a sensing device and what it observes. It is properties that are observed by sensing devices.

theLinnansuoLI-7500 ssn:observes moleFractionCO2
theLinnansuoLI-7500 ssn:observes moleFractionH2O
theLinnansuoCSAT3 ssn:observes windSpeed
moleFractionCO2 rdf:type ssn:Property
moleFractionH2O rdf:type ssn:Property
windSpeed rdf:type ssn:Property

The SWEET ontology provides further modelling support for properties, in particular also mole fraction and wind speed.

From the LI-COR manual, we know that the LI-7500 has a temperature operating range -25 to +50°C. We can model such charateristics using the SSN ontology.

theLinnansuoLI-7500 ssn:hasOperatingRange theLI-7500TempOperatingRange
theLI-7500TempOperatingRange rdf:type ssn:OperatingRange
theLI-7500TempOperatingRange dul:hasRegion aTempRegion
aTempRegion rdf:type dul:Region
aTempRegion dul:hasRegionDataValue "-25 +50°C"

We can go on with specifying what we know about the sensing devices and extracting further information from more sources. But for the purpose here the examples should be sufficient to give you an idea for how information about sensing devices can be extracted from various documents and represented using RDF and OWL technologies.

Having done this, we can do a few cool things we could not do well, or not at all, on the original heterogeneous set of documents. For instance, we can use SPARQL to query this data. We may ask for the defined sensing devices and query their observed properties. With a bit of spatial reasoning, and given a spatial region delimited by a polygon, a query may return the sensing devices at Linnansuo if the tower location is inside the polygon. The ontology we created for our sensing devices can be tested for logical consistency using a reasoner.


You may argue that this is by far too expensive and technical to be done manually, and is thus impractical. True. In fact, I think machines should be doing it for us automatically. For instance, it may be possible for LI-COR to implement such technologies and metadata directly into the hardware. Sensing devices can increasingly be interrogated over Internet protocols, a feature used for instance to retrieve data from a device. A Web server on the device could provide metadata similar to that described in this post, automatically upon request. Some metadata can be defined by the manufactured and other metadata, such as the tower location, could be specified by the user in device configuration. A user—or, more interestingly, software—could then retrieve the RDF data via HTTP at a certain address, say

where is the (hypothetical) IP address of the sensing device and /data/meta/ssn is the request for metadata encoded conformat to the SSN ontology. The result of such a query could be as shown below. While not meant for humans to read, computers can do interesting things with such RDF data, which they cannot do if the data is only available in documents, such as manuals.

Imagine the administrator of a large sensor network if she could issue a (federated) query to interrogate the network about its sensors and their characteristics. Add or remove a sensing device and the same query could give a different answer. The sensing devices describe themselves. Metadata can automatically be shared. Observation data made by the sensing devices can be automatically enriched with metadata.

<?xml version="1.0"?>

  <!ENTITY owl "" >
  <!ENTITY xsd "" >
  <!ENTITY ssn "" >
  <!ENTITY geosparql "" >
  <!ENTITY rdfs "" >
  <!ENTITY DUL "" >
  <!ENTITY rdf "" >

<rdf:RDF xmlns=""
  <owl:Ontology rdf:about="">
    <owl:imports rdf:resource=""/>
    <owl:imports rdf:resource=""/>
    <owl:imports rdf:resource=""/>

  <owl:Class rdf:about="">
    <rdfs:label xml:lang="en">Infrared gas analyzer</rdfs:label>
    <rdfs:subClassOf rdf:resource="&ssn;SensingDevice"/>

  <owl:Class rdf:about="">
    <rdfs:label xml:lang="en">LI-COR LI-7500</rdfs:label>
    <rdfs:subClassOf rdf:resource=""/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource=""/>
    <ssn:observes rdf:resource=""/>
    <ssn:observes rdf:resource=""/>
    <ssn:hasOperatingRange rdf:resource=""/>
    <ssn:onPlatform rdf:resource=""/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource="&ssn;Property"/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource="&ssn;Property"/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource="&ssn;OperatingRange"/>
    <DUL:hasRegion rdf:resource=""/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource="&DUL;Region"/>
    <DUL:hasRegionDataValue rdf:datatype="&xsd;string">-25 +50°C</DUL:hasRegionDataValue>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource="&ssn;Platform"/>
    <DUL:hasLocation rdf:resource=""/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource="&DUL;PhysicalPlace"/>
    <rdf:type rdf:resource="&geosparql;Feature"/>
    <geosparql:hasGeometry rdf:resource=""/>

  <owl:NamedIndividual rdf:about="">
    <rdf:type rdf:resource=""/>
    <geosparql:asWKT rdf:datatype="&geosparql;wktLiteral">POINT (62.5 30.5)</geosparql:asWKT>


[1] Shurpali, Narasinha J. and Hyvönen, Niina P. and Huttunen, Jari T. and Clement, Robert J. and Reichstein, Markus and Nykänen, Hannu and Biasi, Christina and Martikainen, Pertti J. (2009). Cultivation of a perennial grass for bioenergy on a boreal organic soil – carbon sink or source? GCB Bioenergy, 1(1):35-50, Blackwell Publishing Ltd. doi:10.1111/j.1757-1707.2009.01003.x

This post is part of a series. Previous posts discussed RDF, RDFS and OWL. The next one is about the representation of sensor data using the SSN ontology.