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.ArchitectureDescription.Data.SemanticContextExt R3 - FIWARE Forge Wiki

FIWARE.ArchitectureDescription.Data.SemanticContextExt R3

From FIWARE Forge Wiki

Jump to: navigation, search
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



Orange (FT), Telecom Italia (TI)

Legal Notice

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


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:


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:

 { ?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.

Personal tools
Create a book