Real-life Semantic Web Technology-based Information Sharing via Linked Data Concepts – The SPITFIRE Project
My last post was the first in a series of “spotlight posts” I am using to illuminate practical examples of Real-life Semantic Web Technology-based Information Sharing via Linked Data Concepts. All of these examples support my proposed Enhanced Linked Data Architecture and its current incarnation as the Enhanced Linkeddata Architecture for Persistent Sharing Environments (ELAPSE)™.
My second post in this series is focused on The SPITFIRE Project, which:
Uses open standards and state-of-the art protocols and is based on semantic web technologies (RDF) for meaningful data exchange, autonomous sensor correlation to learn about the environment, and software built around the Linked Data principles to be open for novel and unforeseen applications.”1
The SPITFIRE Project’s goal is to help the Internet of Things (IoT) become a reality. There are several obstacles on different levels that need to be overcome to meet this goal:
1. – Devices and Sensors (or “Things”) need to connect to the Internet and be able to offer services. To do so, they have to announce and describe these services in machine-understandable ways so that user-facing systems are able to find and utilize them.
2. – These “Things” have to learn about their physical surroundings so they can serve sensing or acting purposes without requiring explicit configuration or programming.
3. – Finally, it must be possible to include IoT devices in complex systems that combine local and remote data, from different sources, in novel and surprising ways.
The SPITFIRE Project’s SPITFIRE ontology is used topromote the semantic annotation of IoT sensors and devices to simplify:
(a) The integration of sensor data by data providers,
(b) The discovery of sensors, and
(c) The development of services and applications based on sensor data.
To ease the integration with other annotated data sources, SPITFIRE Projectfollows the recommended best-effort practice to reuse existing, popular ontologies/vocabularies as much as possible. The design of an ontology for SPITFIRE usage is composed of two main steps. First, existing vocabularies, taxonomies, and ontologies are reviewed and evaluated with respect to their usefulness to describe concepts required within the SPITFIRE Projectuse cases. Second, all concepts required in the uses cases, but without a suitable existing description, are identified and an ontology to describe these concepts is defined.
Initial SPITFIRE ontologyconcepts are from the domain of energy-saving in building automation and support for modeling any kind of activity/event that has been “sensed together.” The resulting SPITFIRE ontology aligns already existing vocabularies–including the World Wide Web Consortium (W3C) Semantic Sensor Network (SSN) ontology and social & provenance vocabularies, as well as The Internet Engineering Task Force (IETF®) Constrained RESTful Environments (CoRE) specs and especially the Constrained Application Protocol (CoAP) –to enable the semantic description of not only sensor measurements and sensor metadata but also of the context surrounding them, the detected activities, and energy efficiency concepts.
The SPITFIRE ontology is composed of modules with a focus on:
(a) energy saving in building automation (the SPITFIRE consolidated use case) thus allowing the developer to monitor and describe both the structure and the performance of sensor networks and their components; and,
(b) modeling any kind of activity/event that has been sensed together and enriched by descriptions of the surrounding environment. The SPITFIRE ontology enables a full and rich description of not only sensor data but also the sensed event, its structure, what triggered it, and its relation with other activities.
An alignment diagram of already existing ontologies from the social, sensor, and provenance domain, aimed at further modeling the context surrounding sensors is shown below:
Spitfire Ontology Social Provenance Diagram
For more details on the SPITFIRE ontology, go here.
A SlideShare presentation on the overall SPITFIRE Project is available here.
One key focus of the SPITFIRE Project was to bring its works and results together in a unified architecture and software suite. The main result is a unified SPITFIRE software suite: the SPITFIRE developer toolchain. This toolchain combines the smart service proxy (SSP), various Constrained Application Protocol (CoAP) extensions and implementations of SPITFIRE, semantic annotations, Service-Level Semantic Entities (SLSE), In-Network Semantic Entities (INSE), In-Network Query Processing (INQP), sleep scheduling, and cryptographic routines. Many of these components are available as modular WiseLib code. They can be used, as is, to quickly create SPITFIRE-enabled networks, or be easily adapted and re-assembled for custom applications.
More toolchain details and download links for these components are available here.
As with the Optique Project, the SPITFIRE Projectattempts to address a number of the concerns, identified in one of my previous posts, that are commonly associated with today’s RDF Stores and Linkeddata Framework solutions. The SPITFIRE Project ‘s strong and successful ontology-based directions have proven that both short and long-term benefits are achievable using Linked Data Concepts.
When focused on open source and open standards, the SPITFIRE Project does implement a number of the same components (the Enhanced parts) of my Enhanced Linkeddata Architecture for Persistent Sharing Environments (ELAPSE)™, including:
My next post will discuss a third practical example of Real-life Semantic Web Technology-based Information Sharing via Linked Data Concepts.
=david.l.woolfenden