Environmental Information Systems and Services require exible discovery and chaining of distributed environmental services to support a large number of concurrent decision processes. The ability to cope with geo-spatial features of the environment and to process in real time huge and possibly noisy data streams are two critical factors in supporting such decision processes. Solution to separately cope with the two aspects are available. The geo-spatial aspect has been studied for decades in the Geographic Information System (GIS) community. Data Stream Management Systems (DSMS) are the result of a decade of investigation on data stream processing by the database community. However, seamless integrated usage of GIS and DSMS is still a di cult task. Recent developments of the Semantic Web community have been trying to overcome the barriers between these two technologies by proposing to extend the Semantic Web with both a Geo-Spatial and a Streaming dimension. In this paper, these two dimensions of Semantic Web are show-cased for environmental monitoring and management in oil and gas operations.
Remaining world leader in the oil and gas industry while achieving continuous
improvements in environmental performance is one of the objectives for the
years 2009-2011 listed by Norwegian Oil Industry Association (OLF)3[
larger amount of information that describe wells, templates, processing plants, and pipelines.
For instance, oil operation engineers base their decision processes on real time data acquired from sensors on oil rigs, both on the sea surface and on the seabed. A typical oil production platform is equipped with about 400.000 sensors for measuring environmental and technical parameters. Some of the questions they faces are: { Given an alarm on a well in progress to drown, how much time do I have given the historical behavior of that well? { Given this brand of turbine, what is the expected time to failure when the barring starts to vibrate as now detected? { How do I detect weather events from observation data? { Which sensors have observed a blizzard within a 100 mile radius of a given location.
Answering these questions requires to process an (almost) \continuous" ow of information { with the recent information being more relevant as it describes the current state of a dynamic system { against a rich background knowledge { with geospatial information playing a central role.
The Semantic Web can provide to the oil industry, and in general the Environmental Information Systems and Services research area, the standard technologies for data integration, but state-of-the-art semantic technologies can only partially support the need for intelligent systems in the oil industry.
In the rest of the paper, we brie y discuss (see Section 2 and 3) recent attempts to add to the Semantic Web the ability to continuously process data ows and to e ciently perform geospatial analysis. We exemplifying their usage for analyzing weather sensor data places all around the oil elds. In particular, in Section 4, we describe how we are developing a solution for chaining di erent processing units within the LarKC project4. Finally, in Section 5 we draw some conclusions. 2
Continuous processing of ows of information (namely data streams) has been
largely investigated in the database community [
On the contrary, continuous processing of data streams together with rich
background knowledge requires specialized reasoners, but work on semantic
technologies is still focusing on rather static data. In existing work on logical
reasoning, the knowledge base is always assumed to be static (or slowly evolving).
There is work on changing beliefs on the basis of new observations [
solutions proposed in this area are far too complex to be applicable to gigantic data streams of the kind illustrated in the oil production example above.
As argued in [
The foundation for complex reasoning over streams and background knowledge has been investigated since 2008 by introducing technologies for wrapping and querying streams in the RDF data format and by supporting simple forms of reasoning. In this paper, we focus on Continuous-SPARQL (shortly C-SPARQL) [5{8].
Listing 1.1 shows an example of C-SPARQL query that detects a blizzard: a severe storm condition lasting for 3 hours or more characterized by low temperatures, strong winds, and heavy snow.
Listing 1.1. Example of C-SPARQL which detects a blizzard
At line 4, the REGISTER clause is use to tell the C-SPARQL engine that it
should register a continuous query, i.e. a query that will continuously compute
answers to the query. In particular, we are registering a query that generates
as output an RDF stream (i.e., we use REGISTER STREAM). The COMPUTE EVERY
clause states the frequency of every new computation, in the example every 10
minutes. At line 9, the standard SPARQL clause FROM is used to load in the
default graph the location of all weather stations. At line 10, the C-SPARQL
speci c clause FROM STREAM de nes the RDF stream of weather observations. We
supposed that the observations are encoded in RDF using the Semantic Sensor
Web ontology [
As Listing 1.1 illustrates, C-SPARQL enables the encoding of the typical questions an oil operation engineer has to answer. This is possible, because C-SPARQL extends SPARQL with the notions of window and of continuous processing.
Two approaches alternative to C-SPARQL exist: Streaming SPARQL [
E
cient Geospatial Analysis
E cient geospatial analysis methods have been developed over the past half
century and most of them are available in Geographic Information Systems (GIS)
packages. However, the Semantic Web community has devoted very limited
attention to the spatial dimension of data. Available solutions (e.g., Virtuoso [
The main reason for such a limited support is the tendency to re-implement
geospatial analysis algorithm (e.g., R-tree indexes) in RDF repositories. This is
neither necessary, nor e cient. Since 2003, several solutions have been conceived
and implemented [16{20] addressing the growing need for RDF applications to
access the content of non-RDF, legacy databases without having to replicate the
whole database into RDF. They provide (in slightly di erent ways) declarative
languages to describe mappings between relational database schemata and
RDFS vocabularies (or more expressive ontological languages). Once the mapping is
ready, they can use it to rewrite SPARQL query in SQL. We refer interested
readers to [
In [
Listing 1.2 shows an example of SPARQL query that detects the platforms within oil- elds in which more than 10 blizzards were detected in the last month. 1 SELECT ? oilField ? platform 2 FROM 3 WHERE { 4 ? oilField ex : hasSurface ? oilFieldSurface . 5 ? platform ex : hasSurface ? platformSurface . 6 ? sensor grs : point ? sensorPosition ; 7 so : generatedObservation [a w: blizzard ] ; 8 so : samplingTime ? time . 9 FILTER ( g2r : contains (? oilFieldSurface , ? sensorPosition ) 10 && g2r : overlaps (? oilFieldSurface , ? platformSurface )) 11 FILTER (? time >= "2010 -10 -01 T00 :00:00 Z ^^ xsd : dateTime ") 12 FILTER (? time <= "2010 -09 -01 T00 :00:00 Z ^^ xsd : dateTime ") 13 } GROUP BY ? oilFieldSurface 14 HAVING ( COUNT (? sensor ) > 10)
Listing 1.2. Example of SPARQL query requiring geospatial analysis that G2R can e ciently answer using an underlying GIS.
The query in Listing 1.2 is a standard SPARQL 1.1 query that uses two of the extended value testing functions available in G2R: g2r:contains and g2r:overlaps. g2r:contains checks whether the sensor is contained in the area (in the general case a curved polygon) of the oil- eld. g2r:overlaps tests if the area of the oil platform overlaps the area of the oil- eld (in the general case both are a curved polygon).
G2R rewrites the query in Listing 1.2 in the equivalent SQL MM/Spatial query in Listing 1.3 using mappings of the kind declared in Listing 1.4. 1 SELECT o.ID , p.ID , 2 FROM platform AS p , oilFields AS o , sensors AS s 3 WHERE s. generatedObservation = " blizzard " AND 4 p. area . ST \ _Within (s. position ) = 1 AND 5 b. area . ST \ _Overlaps (o. area ) = 1 AND 6 s. samplingTime >= "2010 -09 -01 T00 :00:00 Z" AND 7 s. samplingTime <= "2010 -10 -01 T00 :00:00 Z" 8 GROUP BY o. ID 9 HAVING COUNT (s. generatedObservation ) > 10
Listing 1.3. A SQL MM/Spatial query equivalent to the SPARQL query in Listing 1.2 generated by g2r
In Listing 1.4, note that the extended value testing functions available in G2R, i.e., g2r:contains and g2r:overlaps, are rewritten in the respective SQL MM/Spatial functions ST Within() and ST Overlaps(). 1 map : area a g2r : SpatialPropertyBridge ; 2 d2rq : belongsToClassMap map : platform ; 3 d2rq : property ex : hasSurface ; 4 g2r : spatialColumn " area "; 5 d2rq : datatype g2r : Polygon .
Listing 1.4. A SQL MM/Spatial query equivalent to the SPARQL query in Listing 1.3 generated by g2r
Moreover, note that the mapping declared in Listing 1.4 allows G2R to map the property ex:hasSurface to the spatial column \area" of the GIS, which is a polygon. 4
C-SPARQL and G2R have not been integrated yet, but we are working on it in
the LarKC project. The main goal of LarKC [
Once the integration will be complete, we will be able to issue a C-SPARQL query that every 30 minutes determines the geographical area interest by a blizzard by combining the positions of the sensors that have been detecting a blizzard in the last 3 hours (i.e., the RDF stream resulting from the C-SPARQL query in Listing 1.1). To achieve this results (see Listing 1.5) the spatial function g2r:convexHull is called to compute the minimal convex polygon that contains all the sensor positions. 1 PREFIX so : <http :// knoesis . wright . edu / ssw / ont / sensor - observation . owl #> 2 PREFIX w: <http :// knoesis . wright . edu / ssw / ont / weather . owl #> 3 4 REGISTER STREAM BlizzardAreaDetection COMPUTE EVERY 30 m AS 5 CONSTRUCT { 6 [] a w: blizzard ; 7 ex : hasArea g2r : convexHull (? sensorPoint } . 8 } 9 FROM <http :// oilprod . org / weatherStations .rdf > 10 FROM STREAM <http :// oilprod . org / BlizzardDetection . trdf > [ RANGE 3h STEP 30 m] 11 WHERE { 12 ? sensor so : generatedObservation [a w: blizzard ] ; 13 grs : point ? sensorPosition . 14 }
Listing 1.5. Example of C-SPARQL that requires G2R to be e ciently evaluated
By further processing the results of this query, we can detect which oil platform could be potentially interested in the near future by a blizzard with the C-SPARQL query illustrated in Listing 1.6). This query uses the spatial function g2r:buffer to generate a bu er of 20 km around the convex hull previously computed and returns the oil platforms that are placed within this area. 5 LarKC datalayer is the powerful middleware behind http://factforge.net/, the rst successful attempt to assembly independent datasets published on the Semantic Web in a single consistent knowledge base. 1 PREFIX so : <http :// knoesis . wright . edu / ssw / ont / sensor - observation . owl #> 2 PREFIX w: <http :// knoesis . wright . edu / ssw / ont / weather . owl #> 3 4 REGISTER QUERY PlatformToAlertForPotentialBlizzard COMPUTE EVERY 30 m AS 5 SELECT ? platform 6 FROM <http :// oilprod . org / weatherStations .rdf > 7 FROM STREAM <http :// oilprod . org / BlizzardAreaDetection . trdf > [ RANGE 3h STEP 30 m] 8 WHERE { 9 ? blizzard a w: blizzard ; 10 ex : hasArea ? blizzardArea . 11 ? platform ex : hasSurface ? platformSurface . 12 FILTER ( g2r : overlaps ( g2r : buffer (? blizzardArea , "20"^^ g2r : km ) , ? platformSurface ))
Listing 1.6. Another example of C-SPARQL that requires G2R to be e ciently evaluated 5
In this paper we have illustrated the potential usage of C-SPARQL and G2R in the context of oil production. We have shown how to extend the Semantic Web standards, which already facilitate data integration, with the ability to cope with the geospatial features of the environment and to process in real time huge and possibly noisy sensor data streams. We have also reported on the ongoing work, within the LarKC project, in providing a pluggable platform for chaining various systems such as our C-SPARQL Engine and G2R Engine on top of a powerful data integration layer.
The path that leads to systems able to support in real-time the decision making processes of hundreds of concurrent users (e.g., the controllers on the platform and in the onshore control rooms) is still long. However, we trust that the partially implemented infrastructure, described in this paper, is a concrete step in the direction of developing exible Environmental Information Systems and Services.
The work described in this paper has been partially supported by the European project LarKC (FP7-215535). We also thank Titi Roman, Arne Je Berre and Einar Landre for the fruitful discussions that are at the basis of this paper.