From OntologPSMW

Revision as of 16:20, 21 March 2015 by Garybc (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
[ ]

Beyond Semantic Sensor Network Ontologies     (1)

  • 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.     (1A)
    • It includes different operational, device related and quality of information attributes that are related to sensing devices.     (1B1)
    • describes the operational range, battery and power and environmental ranges that are specified for sensor devices.     (1B2)
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.)     (1C)

  • 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.”     (1D)
    • 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?"     (1D1)

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

  1. Stream Reasoning     (1H)
  2. Complex Event Processing     (1I)
  3. Stream Query Processing     (1J)
  4. Stream Compression     (1K)
  • A related point is that with the size and complexity of IoT an extensible, modular approaches may be useful, if not essential.     (1L)
    • A related idea is the practicality of Bridge ontologies as discussed by several groups.     (1L1)
    • 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?"     (1L2)
  • 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.     (1M)
  • 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.     (1N)
    • – Super/sub-class not always clear     (1N1)
    • – Semantic inconsistencies become clear such as feature representation/realthing     (1N2)
    • UML is frame based while RDF/Owl is open world     (1N3)
  • 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?     (1O)
  • One needs to understand that there are 2 fundamentally different approaches to interoperability:     (1P)
    • Centralized processing of spatially distributed and heterogeneous sensor data (Henson called it Semantics in the Cloud)     (1P1)
      • Send all sensor observations to the cloud for semantic annotation and processing     (1P1A)
      • Data collected in different settings by various kinds of sensors/things/persons     (1P1B)
      • Processed in an offline or semi-offline fashion     (1P1C)
      • Issues: describing the various sources correctly to allow semantic integration     (1P1D)
    • Local processing     (1P2)
  • Some key issues from Beyond SSNO     (1Q)
    • 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:     (1Q1)
  1. Integrating sensors & things with cloud computing     (1R)
  2. Configuring, deploying and using suitable IoT services     (1S)
  3. Auditing/assessing privacy of IoT apps in the cloud     (1T)
  4. Providing an ontological base for generating semantic annotations of open source internet-connected objects     (1U)
    1. A challenge would be to obtain open sensor information in a standard encoding that is understandable by users and their software     (1U1)
  5. Making sure that we have energy-efficient data harvesting     (1V)
  6. Supporting Publish/subscribe for continuous processing and sensor data filtering     (1W)
  7. Insuring mobility of sensors and QoS aspects in IoT     (1X)

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