We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Data.SemanticContextExt - FIWARE Forge Wiki

FIWARE.OpenSpecification.Data.SemanticContextExt

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Data.SemanticContextExt
Chapter Data/Context Management,
Catalogue-Link to Implementation [ <N/A>]
Owner ORANGE, Fano Ramparany


Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Copyright

Orange (FT), Telecom Italia (TI)

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

This enabler extends the functionalities of a publish/subscribe context broker, by making it possible to query the Context Broker through a SPARQL interface. SPARQL is the standard query language for the semantic web.

In the current implementation, this semantic extension has been brought to the CAP Context Broker through interfacing with the CML/CQL context modeling and querying languages. However, its architecture has been designed in such a way that it can extend other PubSub GE implementations. Future releases of the Semantic Extension will be able to interface with the FIWARE-NGI API.

The following subsections introduce the SPARQL syntax and other basic concepts involved in the enabler and introduce its design architecture.

Basic Concepts

SPARQL (SPARQL Protocol and RDF Query Language) is the query language and protocol for searching, modifying and creating RDF data. RDF (Resource Description Framework) is a modeling language developed and promoted by the W3C organisation to describe resources in the web (i.e. web site content, web services).

Using RDF and more generally semantic modeling languages ensures the interoperability between the providers and the consumers of such descriptions. In particular, this makes it possible for a machine to process automatically such description.

A comprehensive description and specification of the SPARQL language can be found here:

http://www.w3.org/2009/sparql/wiki/Main_Page

We simply give here a short introduction to the language, which should be enough for understanding the rest of this document.

SPARQL and SQL syntax have much in common, as you can see with the following simple query sample:

SELECT ?mob
WHERE
 { ?mob rdf:type ps:EmeiEntity }

Which aims at retrieving instances of the class "EmeiEntity".

As suggested by this example, a SPARQL query has two parts:

  • a "SELECT" block which specifies variables for which we seek a value. In this example there is only one variable "?mob". Variables have a name which always start with a "?" (like in the Prolog programming language)
  • A "WHERE" block which specifies a graph fragment containing the variables that could be matched against the RDF model. In this example the graph fragment is a single arc where the variable "?mob" is the subject, "rdf:type" is the predicate and "ps:EmeiEntity" is the object.

A graph fragment is specified as a set of arcs (RDF triples) where the two nodes and the link betwen the nodes can be variables (such as "?mob" in our example), or fully instantiated (such as "rdf:type" or "ps:EmeiEntity").

Main Interactions

  • The CML2RDFTranslator as been designed by composing a CML parser an object serializer and a template engine. The parser interprets a CML document as a structured object which is then serialized into a XML document which complies to the OWL/RDF XML encoding. This compliance is ensured by guiding the serialization along a template document which contains static OWL XML fragments and script programming instructions which traverse the structured object which the parser creates. Values returned by these instructions take the place of the instructions themselves in the template. The overall process is depicted in the following diagram:
  • The OWL document produced by the CML2RDFTranslator process is stored in a RDF database.
  • The SPARQL REST API makes it possible to query the RDF database.

Basic Design Principles

The Semantic Extension component interacts with the PubSub GE using the native CML/CQL protocol as depicted in the high level functional architecture diagram shown below.

Semantic Extension functional architecture

The component provides two main functions:

  • The CML2RDFTranslator
  • The SPARQL engine

The CML2RDFTranslator receives CML data from the Context Broker and convert it into a RDF document which complies to domain specific ontologies. For instance if the CML data contains geographical positioning information it will be converted into a RDF document that instantiates a Geospatial Ontology that standardizes the coordinate properties such as "longitude" and "latitude" and specifies the datatypes and units that the values of these properties should be expressed in and interpreted as. The resulting RDF document is stored temporarily in the RDF cache "Linked Context Data".

The "Context Ontologies" are organized in a modular way. For instance, they include "base ontologies" covering temporal, spatial, social and quality of information concepts, as well as "domain ontologies", such as smarthome, transportation ontologies or as in our examples the physical addressing ontology. For example, the concept "Entity" is defined in a domain ontology but is subsumed by the concept "Thing" which is defined in a base ontology. Likewise, timestamps are defined in the time ontology.

The PubSub semantic extension provides a REST API. It can be invoked by using the GET method with the unique and mandatory "query" parameter, which value should be a SPARQL query.

The Publish/Subscribe Semantic Extension - User and Programmer Guide provides more guidance on how to use this API.


Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications


Re-utilised Technologies/Specifications

This GE relies on the W3C specifications SPARQL, RDF and OWL.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Data refers to information that is produced, generated, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. Data in FIWARE has associated a data type and avalue. FIWARE will support a set of built-in basic data types similar to those existing in most programming languages. Values linked to basic data types supported in FIWARE are referred as basic data values. As an example, basic data values like ‘2’, ‘7’ or ‘365’ belong to the integer basic data type.
  • A data element refers to data whose value is defined as consisting of a sequence of one or more <name, type, value> triplets referred as data element attributes, where the type and value of each attribute is either mapped to a basic data type and a basic data value or mapped to the data type and value of another data element.
  • Context in FIWARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity (which in turn may map to a group of entities) in the FIWARE system to which the context element information refers. In addition, there may be some attributes as well as meta-data associated to attributes that we may define as mandatory for context elements as compared to data elements. Context elements are typically created containing the value of attributes characterizing a given entity at a given moment. As an example, a context element may contain values of some of the attributes “last measured temperature”, “square meters” and “wall color” associated to a room in a building. Note that there might be many different context elements referring to the same entity in a system, each containing the value of a different set of attributes. This allows that different applications handle different context elements for the same entity, each containing only those attributes of that entity relevant to the corresponding application. It will also allow representing updates on set of attributes linked to a given entity: each of these updates can actually take the form of a context element and contain only the value of those attributes that have changed.
  • An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. Events typically lead to creation of some data or context element describing or representing the events, thus allowing them to processed. As an example, a sensor device may be measuring the temperature and pressure of a given boiler, sending a context element every five minutes associated to that entity (the boiler) that includes the value of these to attributes (temperature and pressure). The creation and sending of the context element is an event, i.e., what has occurred. Since the data/context elements that are generated linked to an event are the way events get visible in a computing system, it is common to refer to these data/context elements simply as "events".
  • A data event refers to an event leading to creation of a data element.
  • A context event refers to an event leading to creation of a context element.
  • An event object is used to mean a programming entity that represents an event in a computing system [EPIA] like event-aware GEs. Event objects allow to perform operations on event, also known as event processing. Event objects are defined as a data element (or a context element) representing an event to which a number of standard event object properties (similar to a header) are associated internally. These standard event object properties support certain event processing functions.
Personal tools
Create a book