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 researchers on the publication of meteorological Linked Data, and provide some recommendations and best practices based on our experience.
Several works in the state of the art address the publication of meteorological
data as Linked Data, using the Semantic Sensor Network (SSN) ontology [
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 [
This paper is organized as follows: rst, we describe our weather station and its data; next we study some works on weather data publication based on SSN. Then we brie y 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 work ow 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
Montoldre's Weather Station Description and Data Sources Irstea has a research and experimentation site located at Montoldre, where different types of experiments are run. This site has its own weather station, a Vantage Pro 24 from Davis Instruments5. The station has the following components: 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) le containing the following information:
For the purpose of data publication, we have generated CSV les 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
The SSN ontology [
Geobuddies WGS84 WGS84 time ontology W3C Time other ontologies dataset name AEMET SMEAR Swiss Experiment SWEET ACORN-SAT { Ontologies to describe geographical places and their location. { Ontologies to describe temporal entities.
AEMET (Agencia Estatal de Meteorolog a) is the Spanish public agency in
charge of collecting and publishing weather data. The work ow used to publish
this dataset as Linked Data is described in [
The Swiss Experiment Linked Data publication e ort reported in [
The Australian Bureau of Meteorology published an homogenised daily
temperature dataset called ACORN-SAT. In [
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 [
To conclude, table 1 shows that all meteorological datasets use di erent networks of ontologies. Thus SSN is generic and does not prevent to build heterogeneous 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 brie y these ontologies and the main parts that we have used from them, if any. 4.1
The \Semantic Sensor Network" (SSN) ontology [
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 \Ontology for Meteorological Sensors" [
More speci cally, 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 thermometer, { 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 precipitation, { aws : W indV ane specialisation of aws : W indSensor for the weather vane, { aws : CupAnemometer specialisation of aws : W indSensor for the anemometer,
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 de ned by P yranometer v 9observes: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 de nes and reuses several pre xes like dim of the QU ontology. 4.3
The \Climate and Forecast features" ontology [
The ontology cf f eature proposes elements to describe climate measurements and weather phenomena. It consists of two modules. The module \cffeature" is used to de ne 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 de ne measurable properties (speed, volume, etc.). It contains classes that should specialise the ssn : P roperty class18. Note that this module uses the pre x dim of the QU ontology. All the individuals of this module are de ned with the pre x 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 levelinsoil 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 di culty to make the distinction between cf f eature ontology and cf property one, these two ontologies having very similar schema. Thus for clarity purpose maybe only one ontology should be de ned. Moreover, sometimes it is di cult 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 di cult to know the origin of some of the elements that it de nes, in order to make decisions about their usage or reuse. 4.4
The \Library for Quantity Kinds and Units" (QU) ontology [
The ISA Location Core Vocabulary (LOCN) and GeoSPARQL Currently, several ontologies exist for the publication of spatial data. Each of which has a di erent origin and di erent purposes. This makes it sometimes di cult to determine which are the best options to follow when aiming at representing 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 because 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 [
The \ISA Core Location" vocabulary [
The W3C Time ontology [
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 di erent types of data according to our ontology network (Section 5.2). 5.1
URIs have been designed with several principles in mind, such as simplicity,
stability and manageability. We have followed common guidelines for their e ective
uses, following in many cases the recommendations already applied in [
The base URI is http://ontology.irstea.fr/weather/, pre xed 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 identi ers for the observations (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 identi ers 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 nd it so troublesome to have long URIs with a descriptive identier, since they considered that this is a rather normal way to name les in many le systems for many scienti c 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. Besides 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 instantiation link from the dcterm : Location instance to the geosparql : SpatialObject class.
Figure 1 provides a graphical summary of our model and individuals. 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 speci cally the anemometer.
This anemometer is identi ed by a URI that nishes 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 de nition 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 de ned 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 gure 2 by a dash arrow. 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 previously, 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 speci c observation with its corresponding 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. Describing the Time Instants or Intervals associated to the Observations. 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, maximum, 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 de ned 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 can be used for aggregation purposes by data consumers when accessing our SPARQL endpoint.
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.
Implementation of the Data Transformation Process Now we describe brie y 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 sensors are stored in CSV les. These measurements are performed every half or quarter an hour. Figure 6 shows the main data processing ow that we apply. Pre-processing and date-related operations. A rst pre-processing step is done using shell functions, which allows easy and quick conversions and substitutions, 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 csv x tool). Moreover, we used standard Unix tools, for the following purposes: { to convert dates as they were stored in the CSV le 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 csv x 21 toolbox for CSV le, which allows converting CSV data to other formats using template les. 20 http://ontology.irstea.fr/weather/query/ 21 https://code.google.com/p/csvfix/
We have created some RDF Turtle format template les 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 re ect which parts of the existing documented examples need to be re ned 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 documenting some of the classes and properties that are de ned 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 di cult 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 documentation is also a limitation of the cf f eature ontology, as discussed in this paper, what makes it sometimes di cult to take decisions about which instances of properties to use for a speci c 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 ontologies 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 speci cation of time instants and intervals associated to observations has to be uni ed as well with clear guidelines, something that is not done because of the lack of a range for the ssn : 22 These template les 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 allow 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 di erent processes over the initial data that have been captured. property 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