=Paper=
{{Paper
|id=Vol-1401/paper-07
|storemode=property
|title=Short Paper: Weather Station Data Publication at IRSTEA: An Implementation Report
|pdfUrl=https://ceur-ws.org/Vol-1401/paper-07.pdf
|volume=Vol-1401
|dblpUrl=https://dblp.org/rec/conf/semweb/RousseyBACSBC14
}}
==Short Paper: Weather Station Data Publication at IRSTEA: An Implementation Report==
https://ceur-ws.org/Vol-1401/paper-07.pdf
Weather Station Data Publication at Irstea: an
Implementation Report
Catherine Roussey1 , Stephan Bernard1 , Géraldine André1 , Oscar Corcho2 , Gil
De Sousa1 , Daniel Boffety1 , and Jean-Pierre Chanet1
1
Irstea, UR TSCF Technologies et systèmes d’information pour les agrosystèmes,
9 avenue Blaise Pascal - CS 20085 Aubiére, F-63178, France
{firstname.lastname}@irstea.fr
2
Ontology Engineering Group, Universidad Politécnica de Madrid, Spain
ocorcho@fi.upm.es
Abstract. We describe how we are publishing RDF data about one of
the meteorological stations that Irstea owns in its experimental farm at
Montoldre. Our objective is to revisit previous work done by other re-
searchers on the publication of meteorological Linked Data, and provide
some recommendations and best practices based on our experience.
Keywords: SSN, meteorological data
1 Introduction
Several works in the state of the art address the publication of meteorological
data as Linked Data, using the Semantic Sensor Network (SSN) ontology [8] pro-
posed by the W3C Incubator Group on Semantic Sensor Networks. The work
presented in this paper aims to confirm whether the steps taken by these previ-
ous works on publishing meteorological data can be easily reused for a similar
purpose and to detect any potential difficulties in the usage of the SSN Ontology,
rather than presenting new innovations on the application of the SSN Ontology
in this domain.
We have chosen to publish data from the Vantage Pro 2 weather station in
use at our experimental farm located in Montoldre (France)3 . We have followed
the usual steps in Linked Data publication, as discussed in [1], paying special
attention to the reuse of existing general and domain ontologies applicable to
this type of data publication.
This paper is organized as follows: first, we describe our weather station
and its data; next we study some works on weather data publication based on
SSN. Then we briefly present the network of ontologies that we have reused. In
Section 5, we describe how we have populated the selected ontology network, and
Section 6 describes the workflow followed in this process. Finally we conclude by
presenting an analysis of our work and perspectives.
3
http://www.irstea.fr/la-recherche/themes-de-recherche/motive/
station-de-montoldre
2 Montoldre’s Weather Station Description and Data
Sources
Irstea has a research and experimentation site located at Montoldre, where dif-
ferent types of experiments are run. This site has its own weather station, a
Vantage Pro 24 from Davis Instruments5 . The station has the following compo-
nents: a clock, two temperature sensors (indoor and outdoor), an atmospheric
pressure sensor, two air humidity sensors (indoor and outdoor), a wind vane, an
anemometer, a rain gauge to measure water precipitation and speed, and a solar
radiation sensor.
The external sensors communicate wirelessly with a console located inside a
building, which (in addition to the sensors it contains) allows calculating other
variables (wind chill, dew point, etc.), as well as weather forecasts. By connecting
the console to a computer it is possible to store the values measured and put
them online on a Web server6 . The storage of measures is automatically done
in the station according to the user parameters (intervals of time, units, etc.).
These data can be extracted to generate a CSV (comma-separated values) file
containing the following information:
Temp Hi Low Out Wind Wind
Date Time Out Temp Temp Hum Speed Dir
01/01/13 0:30 6.2 6.7 6.0 73 1.6 WSW
01/01/13 1:00 7.1 7.1 6.1 68 3.2 WSW
01/01/13 1:30 7.5 7.5 7.0 67 3.2 WSW
01/01/13 2:00 7.8 7.8 7.5 67 4.8 WSW
01/01/13 2:30 7.7 7.8 7.7 70 4.8 WSW
01/01/13 3:00 7.2 7.7 7.2 75 3.2 SW
For the purpose of data publication, we have generated CSV files for the
period between 2010 and 2013 with the following measures: outdoor temperature,
external atmospheric pressure, relative humidity of outside air, wind direction,
wind speed, precipitation quantity, water precipitation rate, and solar radiation.
3 State of the Art
The SSN ontology [8] can be used as the basis for the publication of weather
station data. This ontology must be linked with other ontologies to form an
ontology network, including the following ones:
– Ontologies to describe the different type of sensors.
– Ontologies to describe weather phenomena and their measurable properties.
– Ontologies to describe units of measurement.
4
http://www.davis-meteo.com/Vantage-Pro2.php
5
http://davisnet.com/
6
http://meteo.clermont.cemagref.fr/ - service accessible only inside Irstea
– Ontologies to describe geographical places and their location.
– Ontologies to describe temporal entities.
Table 1 lists some of the datasets that use SSN for publishing meteorolog-
ical data as Linked Data. The first column indicates the name of the dataset.
The column “Environmental ontology” presents the ontology used to describe
the Feature Of Interests and their associated properties. The column “Spatial
ontology” indicates the ontology used to describe the localisation information.
The column “time ontology” indicates the ontology used to describe time infor-
mation, if any. The last column shows more ontologies used in the dataset.
dataset environmental spatial time other
name ontology ontology ontology ontologies
AEMET AEMET WGS84 W3C Time
Geobuddies
Swiss Experiment SWEET WGS84 QUDT
ACORN-SAT WGS84 UK Intervals DUL
Data Cube
SMEAR SWEET Geoname DUL Data Cube
WGS84 Situation Theory
Table 1. Projects where SSN has been used to publish meteorological data
AEMET (Agencia Estatal de Meteorologı́a) is the Spanish public agency in
charge of collecting and publishing weather data. The workflow used to publish
this dataset as Linked Data is described in [9]. It is important to note here that
this work was done in parallel to the development of the SSN Ontology, and for
this reason some of the design decisions taken for the publication of these data
sources are not totally compliant with the current SSN Ontology. This dataset
uses the ontologies: AEMET7 , WGS848 , Geobuddies9 and W3C Time10 .
The Swiss Experiment Linked Data publication effort reported in [10] pro-
poses the use of the SSN ontology to combine and publish several meteorological
data streams provided by heterogeneous sensor networks. Thus this work com-
bines several ontologies to build the common schema that will be used to query
sensor data and metadata. SWEET11 , WGS84 and QUDT12 are reused in this
project.
The Australian Bureau of Meteorology published an homogenised daily tem-
perature dataset called ACORN-SAT. In [12], the authors describe how this
7
http://aemet.linkeddata.es/models_en.html
8
http://www.w3.org/2003/01/geo/
9
http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/ontologies/
83-geobuddies-ontologies
10
http://www.w3.org/TR/owl-time
11
http://sweet.jpl.nasa.gov/
12
http://www.qudt.org/
dataset was published on the Linked Data using two main ontologies: SSN and
RDF Data Cube13 . UK Intervals14 and DUL15 are also used.
The Finnish Station for Measuring Ecosystem Atmosphere Relations (SMEAR)
is a large scale sensor network which measures environmental phenomena like
weather or atmospheric gases. The works presented in [13] propose a software
framework able to interpret sensor data at different level of details. The global ar-
chitecture is composed of hierarchical layers : measurement, observation, deriva-
tion and situation. Each layer reads the data from previous one and increases
data complexity in order to enhance its interpretation. The observation layer is
based on the SSN ontology.
To conclude, table 1 shows that all meteorological datasets use different net-
works of ontologies. Thus SSN is generic and does not prevent to build hetero-
geneous schema for meteorological data publication.
4 An Ontology Network for Weather Station Data
Publication
In this section we describe the ontologies that we have reused for the publication
of our weather station data. We describe briefly these ontologies and the main
parts that we have used from them, if any.
4.1 The W3C Semantic Sensor Network (SSN) Ontology
The “Semantic Sensor Network” (SSN) ontology [8] is a generic ontology created
by the W3C Semantic Sensor Network Incubator Group. This ontology contains
different modules. Given our interest on the publication of sensor data and on
describing the sensors used to produce such data, we have focused on the classes
and properties defined in the following modules: Skeleton, Data, Platform Site,
Device and System. More specifically, the classes that we have reused from this
ontology are:
– ssn : Observation to describe the measurement context,
– ssn : F eatureOf Interest to specify the observed phenomena,
– ssn : SensingDevice to describe the sensors,
– ssn : P latf orm to describe where the sensors are installed,
– ssn : System to describe a system composed of several sensors such as, for
example, our weather station.
We have also used the main properties associated to these classes: ssn : observedP roperty,
ssn : observedBy, ssn : hasSubsystem, ssn : f eatureOf Interest, etc.
13
http://purl.org/linked-data/cube
14
http://reference.data.gov.uk/def/intervals
15
http://www.loa-cnr.it/ontologies.DOL.owl
4.2 The AWS Ontology for Meteorological Sensors
The “Ontology for Meteorological Sensors” [6] (AWS) extends the SSN ontology
by extending its class ssn : SensingDevice. It is focused on the description of
different models of sensors that can be used to measure weather phenomena,
and hence is also of interest for our purposes.
More specifically, we have mostly reused the following classes:
– aws : AtmosphericP ressureSensor for the atmospheric pressure sensor,
– aws : CapacitiveT hinF ilmP olymer specialisation of aws : HumiditySensor
for the hygrometer,
– aws : P yranometer specialisation of aws : RadiationSensor for the solar
radiation sensor,
– aws : T hermistor specialisation of aws : T emperatureSensor for the ther-
mometer,
– aws : T ippingBucketRainGaugeT brgW ithoutCorrection specialisation of
P recipitationSensor for the pluviometer; this sensor is able to produce two
separate measurements: the quantity of rain and the speed of the precipita-
tion,
– aws : W indV ane specialisation of aws : W indSensor for the weather vane,
– aws : CupAnemometer specialisation of aws : W indSensor for the anemome-
ter,
Furthermore, some of these classes contain restrictions indicating which type
of ssn : P roperty they are able to measure. For example, the class aws :
P yranometer is defined by P yranometer v ∃observes.EnergyF lux. This has
been also useful for our purpose. Note that sometimes the documentation of the
weather station is not complete enough in order to select the appropriate sensor
model in AWS hierarchy. This is the case of the atmospheric pressure sensor. We
were not able to select one of those sensors. Thus we do not try to specialise this
sensor. We have noticed that AWS proposes lots of sensor models. In our case
AWS provides all the sensor descriptions we need for our purpose. Note that
AWS does not import any ontology but it defines and reuses several prefixes like
dim of the QU ontology.
4.3 Climate and Forecast (CF) features Ontology
The “Climate and Forecast features” ontology [2] (aka cf − f eature) is a trans-
lation of the “Climate and Forecast (CF) standard names vocabulary”16 main-
tained by the “Program for Climate Model Diagnosis and Intercomparison”17 .
This ontology was used to produce one of the use cases of the W3C SSN ontology.
The ontology cf − f eature proposes elements to describe climate measure-
ments and weather phenomena. It consists of two modules. The module “cf-
feature” is used to define environmental observed phenomena (rain, wind, etc.).
It thus contains classes that specialise the ssn : F eatureOf Interest class. We
have used the following individuals and classes from this ontology:
16
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/
17
http://cf-pcmdi.llnl.gov/
– cf − f eature : air instance of cf − f eature : M edium,
– cf −f eature : ground level soil instance of cf −f eature : Surf aceM edium,
– cf − f eature : rainf all instance of cf − f eature : P recipitation,
– cf − f eature : wind instance of cf − f eature : W ind.
The module “dim” is used to define measurable properties (speed, volume,
etc.). It contains classes that should specialise the ssn : P roperty class18 . Note
that this module uses the prefix dim of the QU ontology. All the individuals
of this module are defined with the prefix cf − property. We have reused the
following individuals:
– cf − property : air temperature instance of dim : T emperature,
– cf − property : air pressure instance of dim : StressOrP ressure,
– cf − property : relative humidity instance of dim : Dimensionless,
– cf − property : wind f rom direction instance of dim : Angle,
– cf − property : wind speed instance of dim : V elocityOrSpeed,
– cf − property : rainf all amount instance of dim : Surf aceDensity,
– cf − property : rainf all rate instance of dim : V elocityOrSpeed,
– cf −property : downward heat f lux at ground leveli ns oil instance of dim :
EnergyF lux.
Some of these individuals are linked to individuals of the module “cf-feature”.
For example, cf − property : air pressure is linked to cf − f eature : air by the
property ssn : isP ropertyOf . However, this is not the case for all individuals
(for example, cf − property : relative humidity is not linked to any instance
of ssn : F eatureOf Interest). Hence we had to provide some of these links, as
shown in the Table 2.
In general, this ontology still needs to be better documented. We have diffi-
culty to make the distinction between cf − f eature ontology and cf − property
one, these two ontologies having very similar schema. Thus for clarity pur-
pose maybe only one ontology should be defined. Moreover, sometimes it is
difficult to choose between two individuals. This is, for example, the case, for
cf − f eature : air, which is an instance of cf − f eature : M edium, and cf −
f eature : atmosphere air, which is an instance of cf −f eature : LayerM edium.
As this ontology also imports many other ontologies, it is sometimes difficult to
know the origin of some of the elements that it defines, in order to make decisions
about their usage or reuse.
4.4 The Library for Quantity Kinds and Units (QU)
The “Library for Quantity Kinds and Units” (QU) ontology [4] has been also
created by a W3C working group. The cf − f eature ontology, discussed in the
previous section, imports directly the QU ontology. Indeed, the cf − f eature on-
tology reuses the modules “dim” and “unit” of the QU ontology. The AWS
18
All these classes are defined as subClassOf qu : QuantityKind. They are not defined
directly has subClassOf ssn : P roperty
ontology does not import QU but reuses its prefixes like dim. The module
“dim” of the QU ontology defines classes that are useful to categorise physi-
cal quantities, such as dim : Angle, dim : Distance, dim : Dimensionless, etc.
The module “unit” defines classes that are useful to categorise measurement
units, and also provides instances of those classes, so as to identify units such as
unit : hectopascal, unit : percent, etc. Therefore, we have reused this ontology19
for the representation of our units of measurement, as we will discuss later.
4.5 The ISA Location Core Vocabulary (LOCN) and GeoSPARQL
Currently, several ontologies exist for the publication of spatial data. Each of
which has a different origin and different purposes. This makes it sometimes
difficult to determine which are the best options to follow when aiming at repre-
senting geospatial information, such as the one associated to a weather station.
The WGS84 vocabulary is the oldest and most commonly used vocabulary
to indicate the spatial coordinates of any geographical feature. All the previous
work on publishing meteorological dataset use it. We decide not to use it be-
cause all these datasets do not contain the location property that link a spatial
thing to the point which is its geometrical representation. We think that a clear
distinction should be made between the spatial object and one of its possible
geometrical representations.
We decide to use the “GeoSPARQL” vocabulary [5]. GeoSPARQL is the
result of a standardization process at the Open Geospatial Consortium (OGC),
which was initially focused on querying geographical data. It has also proposed
the model to use for describing geometries of spatial objects (through the object
property hasGeometry, and the use of GML or WKT strings). GeoSPARQL
extends the WGS84 vocabulary and proposes different types of geometries like:
point, polygon, multipolygon, etc. It also allows defining topological relationships
between geometric elements.
The “ISA Core Location” vocabulary [3] (LOCN) was released in November
2013, and has recently been given a W3C-owned namespace, although it was
initially generated outside the consortium. This lightweight ontology is focused
on the description of places and their address, providing a set of three classes and
several properties for their description. Notably, aspects related to the geometry
description of places are still in an “unstable” state, and hence they may change
in the future. This is the ontology that we have used for specifying the address
of the experimental farm.
4.6 The W3C Time Ontology
The W3C Time ontology [7][11] enables the description of time instants (in-
stances of the class time : Instant) and intervals (instances of the class time :
Interval). Hence it may be useful when we need to describe the timestamps or
the time intervals associated to the measurements made by the weather station.
19
prefixed qu-rec20 http://purl.oclc.org/NET/ssnx/qu/qu-rec20
We have used the classes time : Interval and time : Instant, and the associated
properties time : month, time : hour, etc.
5 Design and Population of the Ontology Network for
Weather Station Data
Based on the ontology network described in the previous section, we are now
able to create a dataset containing all the individuals describing measurements
of our weather station. Now we explain the decisions taken in order to create
resource URIs (Section 5.1) and we provide examples of how we publish different
types of data according to our ontology network (Section 5.2).
5.1 Resource URIs for our Weather Station Data
URIs have been designed with several principles in mind, such as simplicity, sta-
bility and manageability. We have followed common guidelines for their effective
uses, following in many cases the recommendations already applied in [9]. This
section presents the main URI design decisions and conventions used, and Table
3 provides a summary of the main types of URIs that we generate.
The base URI is http://ontology.irstea.fr/weather/, prefixed as irstea.
Hence all individuals follow the URI scheme http://ontology.irstea.fr/
weather/resource. For example, the URI to identify the experimental research
site of Montoldre is: http://ontology.irstea.fr/weather/resource/location#
irsteaClermontMontoldre.
Specially relevant is the template used for generating identifiers for the ob-
servations (that is, instances of the class ssn : Observation). In this case, we
had initially considered moving from the URI template that had been used
for the AEMET Linked Data generation (where cool but rather long URIs
were generated as a consequence of including in the observation the identifiers
of the timestamp, sensor and property that was measured) into more simple
URIs generated as an MD5 hash code from the string proposed in Table 3.
For instance, the MD5 hash code for that observation would be something like
eea6c7338102cb8866c8ad563bb85faf. After discussing with our domain experts,
they did not find it so troublesome to have long URIs with a descriptive identi-
fier, since they considered that this is a rather normal way to name files in many
file systems for many scientific domains. Hence we kept them as cool URIs.
5.2 Excerpts of our Ontology-based Weather Station Data
In the following subsections we provide examples of how we generate some of
our RDF data according to the selected ontologies. We think that these excerpts
of the global ontology instances will be useful for others trying to generate and
publish RDF data from a similar domain. It is also a good example of the use
of SSN with other ontologies.
Describing the Weather Station. In this section we provide a general overview
of how we describe the main context of where our weather station is located. Be-
sides the SSN Ontology (our weather station is an instance of the ssn : System
and ssn : P latf orm classes) we use two others vocabulary: the GeoSPARQL
vocabulary in order to relate the weather station to its geometry, and the ISA
Core Location Vocabulary (LOCN) for the description of the address where the
Montoldre experimental farm is located. Note that the geosparql : Geometry
instance uses the geosparql : asW KT property, with a WKT string to specify
the corresponding geographical point. Note that the LOCN vocabulary propose
to use the dcterms : Location class to identify spatial objects.
To combine the LOCN vocabulary with the GeoSPARQL one, we add an in-
stantiation link from the dcterm : Location instance to the geosparql : SpatialObject
class.
Figure 1 provides a graphical summary of our model and individuals.
Fig. 1. Description of our weather station at Montoldre
Describing the Sensors deployed in the Weather Station. We have also
focused on describing each of the sensors that are assembled in our weather
station. Figure 2 provides a graphical overview of one of these sensors, more
specifically the anemometer.
This anemometer is identified by a URI that finishes with W indGauge 01. It
is an instance of the class aws : CupAnemometer, which is a subclass of aws :
W indSensor, in order to specify clearly the type of sensor that the anemometer
represents. This anemometer is a subsystem of the weather station, expressed
with the property ssn : hasSubsystem between the weather station and the
sensor. Finally, we specify that the sensor observes the individual cf − property :
wind speed.
An important aspect to note here is to be able to connect the individuals of
cf −f eature ontology to the class ssn : P roperty. The definition of ssn : Sensor
states that a sensor observes only instance of ssn : P roperty. Thus a reasoner
will deduce automatically that the individual cf − property : wind speed is
an instance of ssn : P roperty. Even if the class qu : QuantityKind is not
defined as a subclass of ssn : P roperty, we can deduce that, in the case of
our description of sensors, any instance of qu : QuantityKind will also be an
instance of ssn : P roperty. This inference is represented in figure 2 by a dash
arrow.
Fig. 2. Description of the wind gauge installed in our weather station
Describing the Observations. Observations allow describing the context of a
measurement done by a sensor, and their description lies at the core of the SSN
Skeleton module, and it is one of the most well documented patterns to follow.
Figure 3 represents an observation done by the anemometer, described previ-
ously, on the wind speed at a given point in time. We can see here that we use the
properties ssn : observedP roperty, ssn : f eatureOf Interest, ssn : observedBy
and ssn : observationResult to relate our specific observation with its corre-
sponding observed property, feature or phenomenon, sensor used to obtain the
measurement, and result of the measurement, respectively. As for the result of
the observation, it is important to note that this is a pattern that is not so
well documented and hence there are multiple ways to represent the observation
values, together with their corresponding units. For example, the QU ontology
proposes the properties qu : numericalV alue and qu : unit. As shown in Figure
3 we prefer to use the properties already contained in ssn:
– the property ssn : hasV alue to relate the result with the corresponding
ssn : ObservationV alue,
– the property DU L : hasDataV alue to express the actual value,
– the property DU L : isClassif iedBy to express the unit of the measurement.
Fig. 3. Description of an observation of wind speed
Describing the Time Instants or Intervals associated to the Obser-
vations. This is also a pattern that is not well documented in the existing
SSN Ontology documentation, and hence many options are available for the
generation of the corresponding data. An observation can be related to a time
instant or describe the result of an aggregation of values (average, sum, maxi-
mum, minimum, etc.) over a time interval. The relationship of the observation
with the corresponding time instant or time interval is done with the property
ssn : observationResultT ime, and the terms that are needed to specify time
instants and intervals are provided in the W3C Time Ontology.
Figure 4 presents an example where the observation is related to a time
instant (for instance, in the case of a temperature measurement). In this case,
the range of the property ssn : observationResultT ime is an instance of the
class time : Instant which is connected to the corresponding xsd : dateT ime
value according to the ISO 8601 format via the property time : inXsdDateT ime.
Besides, we provide in our examples additional properties defined by the W3C
Time Ontology, such as time : year, time : month, time : day, time : hour, and
time : minute, so as to allow creating GROUP BY queries more easily, which
Fig. 4. Description of an observation related to a time instant
can be used for aggregation purposes by data consumers when accessing our
SPARQL endpoint.
Fig. 5. Description of an observation related to a time interval
Figure 5 presents an example where the observation is related to a time
interval (for instance, in the case of rainfall amount). In this case, we follow a
similar pattern, but the value of the property ssn : observationResultT ime is
instead an instance of the class time : Interval, and we also use the properties
time : hasDurationDescription and time : hasEnd to specify the duration of
the interval and its end, besides the beginning of the interval.
Table 4 contains a summary of the type of timestamp that we have associated
to each type of measurement that our weather station sensors perform.
6 Implementation of the Data Transformation Process
Now we describe briefly the process followed for the generation of the RDF data
according to the design principles described in the previous section. All the data
that we have generated are available at our SPARQL endpoint20 .
As explained in the Introduction, data measured by the weather station sen-
sors are stored in CSV files. These measurements are performed every half or
quarter an hour. Figure 6 shows the main data processing flow that we apply.
Fig. 6. Data Processing Flow for the Generation of RDF Data from the Weather
Station Measurements
Pre-processing and date-related operations. A first pre-processing step is
done using shell functions, which allows easy and quick conversions and substi-
tutions, such as deleting line headers, detection and removal of ill-formed lines,
and the substitution of initial tab characters by a semicolon, better accepted by
the next tools in the pipeline (e.g., the csvfix tool). Moreover, we used standard
Unix tools, for the following purposes:
– to convert dates as they were stored in the CSV file into the ISO 8601 format,
– to calculate the time interval between two timestamps,
– to convert the wind direction in degree.
The last pre-processing step is to group data by month, as a pragmatic way
of processing batches of data and allowing an easier load into our Fuseki server.
CSV to RDF Transformations. The conversion of CSV data to RDF Turtle
is made using the csvfix 21 toolbox for CSV file, which allows converting CSV
data to other formats using template files.
20
http://ontology.irstea.fr/weather/query/
21
https://code.google.com/p/csvfix/
We have created some RDF Turtle format template files which are used in
this process22 . Finally, the data are sent to the server using s-update, which is
part of SOH (SPARQL over HTTP) from the Jena framework23 .
7 Conclusions, Perspectives and Recommendations
As discussed in the Introduction, our intention with this work lied mainly at
providing an implementation report about the usage of a set of ontologies that
have been so far associated to the generation and publication of Linked Data
from weather stations. This work tries to reflect which parts of the existing doc-
umented examples need to be refined or extended, and which parts are already
well described and reproducible for a weather station.
We hope that our examples and code can provide further information to
people that will be involved in a similar processing pipelines. Besides that, we
have the following recommendations for the following versions of this set of
ontologies:
– In general, we think that we still need a better documentation for many of
these ontologies, in order to facilitate their use. This covers both document-
ing some of the classes and properties that are defined in these ontologies
and providing more examples of usage. This does not say that the current
documentation is bad at all. However, the documentation is still sometimes
difficult to understand by people who are not specialists in ontologies. It
would be interesting to associate it with concrete examples showing good
practices in publication of data collected by sensors, such as what we try
to do in this paper, or what is available in many other papers as well as in
the W3C SSN Incubator Group implementation report. The lack of docu-
mentation is also a limitation of the cf − f eature ontology, as discussed in
this paper, what makes it sometimes difficult to take decisions about which
instances of properties to use for a specific type of measurement.
– There is still too much heterogeneity in ontologies that can be used to express
geospatial information (W3C WGS84, GeoSPARQL, the ISA Core Location
Vocabulary, etc.). This forces us to spend a lot of time deciding which on-
tologies to use for describing each type of geospatial information (locations,
spatial points, polygons, etc.), and in some cases many alternatives exist,
what may make some applications and SPARQL queries to work for some
SPARQL endpoints and fail in others.
– The cf − f eature and cf − property ontologies should be merged in one
ontology in order to clarify their usage.
– The pattern to use for the specification of time instants and intervals as-
sociated to observations has to be unified as well with clear guidelines,
something that is not done because of the lack of a range for the ssn :
22
These template files and the processing pipeline code will be published on http:
//ontology.irstea.fr
23
http://jena.apache.org/documentation/serving\_data/soh.html
observationResultT ime property. We have seen examples in other datasets
where the observation time is provided directly as an xsd:dateTime, whereas
in our case we have preferred using the W3C Time Ontology so as to al-
low easier SPARQL queries when aiming at doing aggregations through the
GROUP BY operator available in SPARQL.
In the coming months we will do similar processes to other weather stations
owned by Irstea in other sites in France, so that they can be used by other
researchers outside our institution in their research. We will also work with the
association of quality indicators to data measured by the weather station or
calculated by different processes over the initial data that have been captured.
References
1. Best practices for publishing linked data. http://www.w3.org/TR/ld-bp/. Ac-
cessed: 2014-07-08.
2. Climate and forecast (cf) features. http://www.w3.org/2005/Incubator/ssn/
ssnx/cf/cf-feature. Accessed: 2014-06-30.
3. Isa programme location core vocabulary. http://www.w3.org/ns/locn#. Accessed:
2014-06-30.
4. Library for quantity kinds and units: schema, based on qudv model omg sysml(tm),
version 1.2. http://www.w3.org/2005/Incubator/ssn/ssnx/qu/qu. Accessed:
2014-06-30.
5. Ogc geosparql - a geographic query language for rdf data. http://www.
opengeospatial.org/standards/geosparql. Accessed: 2014-06-30.
6. Ontology for meteorological sensors. http://www.w3.org/2005/Incubator/ssn/
ssnx/meteo/aws. Accessed: 2014-06-30.
7. Owl code of the time ontology. http://www.w3.org/2006/time. Accessed: 2014-
06-30.
8. Semantic sensor network xg final report. http://www.w3.org/2005/Incubator/
ssn/XGR-ssn-20110628/. Accessed: 2014-06-30.
9. G Atemezing, O Corcho, D Garijo, J Mora, Poveda-Villalon M., P Rozas, D Vila-
Suero, and B Villazon-Terrazas. Transforming meteorological data into linked
data. Semantic Web journal, Special Issue on Linked Dataset descriptions, 2012.
IOS Press, ISSN: 1570-0844, 07 2012.
10. J-P Calbimonte, H Jeung, O Corcho, and K Aberer. Semantic sensor data search in
a large-scale federated sensor network. In K Taylor, A Ayyagari, and D De Roure,
editors, SSN, volume 839 of CEUR Workshop Proceedings, pages 23–38. CEUR-
WS.org, 2011.
11. Jerry R. Hobbs and Feng Pan. Time ontology in owl. W3C Working Draft, 09
2006.
12. L. Lefort, J. Bobruk, A. Haller, K. Taylor, and A. Woolf. A linked sensor data
cube for a 100 year homogenised daily temperature dataset. In In 5th International
Workshop on Semantic Sensor Networks (SSN-2012), CEUR-Proceedings, 2012.
13. M. Stocker, Baranizadeh E., H Portin, M. Komppula, M. Rönkkö, A. Hamed,
A. Virtanen, K. Lehtinen, A. Laaksonen, and M. Kolehmainen. Representing sit-
uational knowledge acquired from sensor data for atmospheric phenomena. Envi-
ronmental Modelling and Software, 58:27–47, 2014.
measurement feature of interest property
instance of cf − f eature instance of cf − property
outdoor temperature air air temperature
atmospheric pressure air air pressure
humidity air relative humidity
wind direction wind wind from direction
wind speed wind wind speed
quantity of precipitation rainfall rainfall amount
speed of precipitation rainfall rainfall rate
solar radiation ground level soil downward heat flux
at ground level in soil
Table 2. Weather measurement properties
Object Resource class local ID pattern
Station ssn : System hlocation Nameih station type i hnumber IDi
Windwane ssn : Sensor hstation IDi hsensor typei hnumber IDi
Instant time : Instant hdateiThtimeihtime zonei (ISO 8601 format)
Interval time : Interval Phperiodihuniti hdateiThtimeihtime zonei
Observation ssn : Observation at htimestampi of hsensori on hpropertyi
Examples
URI station irstea:resource/system#lesPalaquinsVp2_01
URI windwane irstea:resource/sensor#lesPalaquinsVp2_01_WindVane_01
URI instant irstea:resource/instant#2013-01-23T13:30+0100
URI interval irstea:resource/interval#P30M_2013-01-23T13:30+0100
URI observation irstea:resource/observation#at_2012-06-19T15:45+0200_
of_lesPalaquinsVp2_01_Thermometer_01_on_AirTemperature
Table 3. URI generation templates for resources
Measured property timestamp
exterior temperature instant
atmospheric pressure instant
air humidity instant
wind direction interval
wind speed interval
rainfall amount interval
rainfall speed interval
solar radiation interval
Table 4. Types of timestamps associated to the measured properties of our weather
station