Beyond Semantic Sensor Network Ontologies

• Sensors are most closely in touch with the outside world and are thus are a big part of IoT since they provide an observational basis for data about things of interest. The Semantic Sensor Network Ontology (SSNO) is an ontology for describing networked sensors and its output.

• • It includes different operational, device related and quality of information attributes that are related to sensing devices.
  • describes the operational range, battery and power and environmental ranges that are specified for sensor devices.

Sensors and networks continue to merge which leads to  making Connected Things “Smarter”. Some of the support for smart networking may include event-driven message passing & responsive processing based on sensed & identified event and “software sensor agents” managing the sensors can represent the original content in a logical/digital form that can be broadcast through a networked system.  Increasingly these sensor agents can be expected to work smarter as[[1]] cooperative agents in network. 

The number, volume and variety of sensor data, including via data streams, results in Big Data challenges (e.g. heterogeneity challenging integration, interpolation & summarization, filtering, compression, etc.)

• Many Big Data issues are immediately applicable to sensor networks, including things such as explosion of standards & reliance on metadata vocabularies such as the idea of things within IoT like services, users, networks, concentrators/aggregators and devices called “resources.”
  • In the face of these challenges we ask: "do even light-weight sensor ontologies scale and what is realistic for ontological commitments for big heterogeneous data?"

• Ontology reuse issues are not unique to IoT but there are some good ontologies such as SSN and PROV that provide some starting points for representing sensors, sensor also networks, observations, etc.
  • There is some Semantic Web enablement work by OGC (see talk by Ingo [[2]] Simonis http://ontolog.cim3.net/file/work/OntologySummit2015/2015-03-05_OntologySummit2015_Beyond-Semantic-Sensor-Network-Ontologies-2/Track-B_OntologySummit2015_IngoSimonis_2015-03-05.pdf) and NIST (see talk by Jeff Voas) initiatives to standardize the view on sensor networks and to move to formalism like JSON-LD.
  • There is also work to "Keep sensor data moving

" & provide ontology-based access to data streams by using CQL-like extensions for RDF stream queries as discussed by Jean-Paul Calbimonte (LSIR EPFL)

• • • RDF Store + Stream processor systems are called RSPs [[3]]
    • CQELS-QL is a declarative query language built from SPARQL 1.1 grammar. As C-SPARQL allows it extends SPARQL with operators to query stream.
    • Issues within the RSP community include:

1. Stream Reasoning
2. Complex Event Processing
3. Stream Query Processing
4. Stream Compression

• A related point is that with the size and complexity of IoT an extensible, modular approaches may be useful, if not essential.
  • A related idea is the practicality of Bridge ontologies as discussed by several groups.
  • Approaches for developing small, focused ontologies customized to the available sensors and sensor data might be necessary, but a research questions is, "do they scale?"

• Also discussed by several groups is the questions of whether the priority work and opportunity is for ontologies to be used to annotate IoT data, or to more fully represent & model it in order to analyse/understand it.
• Much IoT work is modeled in formalisms like UML and as shown by OGC's SWE Direct mapping from UML/O&M to OWL/O&M there are issues with mapping classes to concepts. E.g.
  • – Super/sub-class not always clear
  • – Semantic inconsistencies become clear such as feature representation/realthing
  • UML is frame based while RDF/Owl is open world
• for all of these we can ask what tools are needed to support the development of modular ontologies and methods are needed to develop schemas?

• One needs to understand that there are 2 fundamentally different approaches to interoperability:
  • Centralized processing of spatially distributed and heterogeneous sensor data (Henson called it Semantics in the Cloud)
    • Send all sensor observations to the cloud for semantic annotation and processing
    • Data collected in different settings by various kinds of sensors/things/persons
    • Processed in an offline or semi-offline fashion
    • Issues: describing the various sources correctly to allow semantic integration
  • Local processing
    • "Semantics at the Edge" or locally intelligent (geo-)sensor networks
    • Distributed processing: In-place computing
    • Issues:
      • use ontologies to smartly aggregate, filter, process, access, and respond to sensor data
      • Downscale semantic representation and reasoning for local processing.

• Some key issues from Beyond SSNO
  • How do we handle going beyond SSN with an Open Source Cloud solution for the Internet of Things (OpenIoT)? Challenges include sensor annotation, sensor mobility & efficient data harvesting and data quality:

1. Integrating sensors & things with cloud computing
2. Configuring, deploying and using suitable IoT services
3. Auditing/assessing privacy of IoT apps in the cloud
4. Providing an ontological base for generating semantic annotations of open source internet-connected objects
   1. A challenge would be to obtain open sensor information in a standard encoding that is understandable by users and their software
5. Making sure that we have energy-efficient data harvesting
6. Supporting Publish/subscribe for continuous processing and sensor data filtering
7. Insuring mobility of sensors and QoS aspects in IoT

• • The need to formalize Situation has obvious overlap with extending SSN to more adequately modeling sensing and observation situations