Skip to content

Gateway API Services and Distributed Query Client

Jump to bottom
Andrea Cimmino Arriaga edited this page Jun 21, 2018 · 1 revision

In this page we present the two main components that implement the interoperability approach of VICINITY, the Gateway API Services and the Distributed Query Client. Following, we aim at providing an overview of how these components work separately, how they interact, and in which developing stage they are.

As specified in the architecture of the VICINITY project [3], the VICINITY Gateway API Services is one of the core components that conforms the VICINITY cloud. All functionalities provided by the Gateway API Services are only accessible through the Distributed Query Client, which is integrated in all the Gateway APIs of VICINITY. On the one hand, the Gateway API Services is in charge of providing a discovery interface to find, with no prior-knowledge, remote Gateway APIs that expose relevant data to answer a query. The discovered Gateway APIs must be within neighbourhood of the requester Gateway API, which is established through the VICINITY Neighbourhood Manager. On the other hand, the Gateway API Services provides Query Plans that are used to identify the relevant data to answer a given query, it also provides data of semantic resources allowing the Distributed Query Client enhancing the discovered data that is retrieved from other Gateway APIs (transforming their JSON data into RDF) and returning a set of query results. In order to understand how the Gateway API Services and the Distributed Query Client work, it is necessary to describe the main concepts to whose they refer to:

  • SPARQL Query: it is a query expressed in the SPARQL standard language [6], in which data is modelled as a graph.
  • Gateway API: it is a component of the P2P network that conforms to VICINITY. Namely the Gateway APIs expose data of IoT Infrastructures registered in VICINITY as JSON documents. It is paramour to remark that the JSON structures of the different Gateway APIs are in most of the cases different.
  • Ontologies and Semantic data: they refer to data modelled following the ontologies of VICINITY, namely core, wot, wot-map, and adp. Such data are located in the VICINITY component known as Semantic Repository.
  • Semantic Resources: they refer to the semantic data related to a Gateway API that can be either a wot:Thing or a wot:ThingDescription.
  • Thing Ecosystem Description: it is a document expressed in RDF [7], containing identifiers of wot:Things referencing Gateway APIs that expose relevant data to answer a query. Each of the Gateway APIs generally exposes data of devices, and physical or virtual objects, which are commonly referred as wot:Things. A set of wot:Things conforms an Thing Ecosystem Description.
  • Virtual Thing Ecosystem Description: it is a modified version of a thing Ecosystem Description. Thing Ecosystem Descriptions do not take privacy policies into account, therefore a requester node that receives a Thing Ecosystem Description may peek, but not access, addresses of other Gateway APIs outside its neighbourhood. The Virtual Thing Ecosystem Description is a version of the former document that fulfils the privacy policies of the requester Gateway API.

When a Gateway API provides a SPARQL query to its Distributed Query Client, the later component retrieves the TED form the Gateway API Services and produces the VTED containing only wot:Thing in the neighbourhood of the requester Gateway API. Then, for each wot:Things the address of a Gateway API is retrieved and accessed, gathering a set of JSON documents as result. Once all the data is gathered, the Distributed Query Client retrieves the wot:ThingDescriptions of each wot:Thing, with which transforms the JSON documents into RDF data. Finally, the Distributed Query Client retrieves a Query Plan from the Gateway API Services and applies it to prune the data that is not useful to answer the SPARQL query. As a result, the Distributed Query Client produces a set of query solutions that are the output to the Gateway API.

In conclusion, the main purpose of the VICINITY Gateway API Services and the Distributed Query Client is to provide Gateway APIs with a discovery and a querying functionality so they can find and consume data within the VICINITY cloud on-the-fly with no prior-knowledge following the VICINITY security and privacy protocols. There are several functionalities that need to be covered by the Gateway API Services as stated in D1.5 Technical requirements specification [5]:

  • Discovery Interface: receives a SPARQL query and produces a Thing Ecosystem Description containing identifiers of wot:Thing that are relevant to answer the query.
  • Query Plans interface: receives a SPARQL query and produces a Query Plan that is an RDF document describing which specific data is suitable to answer the query.
  • Semantic Resources interface: receives a resource identifier and returns its semantic RDF description.

The functionalities stated in D1.5 Technical requirements specification regarding the Distributed Query Client are (Figure 3):

  • Retrieve TEDs and generate VTEDs: receives a TED and a list of allowed neighbours to access, and produces a VTED containing only the allowed identifiers.
  • Retrieve Thing and Thing Descriptions from the Gateway API Services: consumes the Semantic Resources interface of the Gateway API Services.
  • Retrieve Gateway API addresses from Thing Descriptions: receives a wot:ThingDescription and returns the HTTP address of a specific Gateway API.
  • Retrieve JSON data from remote Gateway API addresses: receives an HTTP address of a Gateway API and retrieves the data exposed by it though the P2P network.
  • Virtualize RDF from a JSON document: receives a wot:ThingDescription and a JSON document, and translates the JSON document into RDF following the VICINITY ontology specifications; in other words, produces virtualised RDF.
  • Retrieve and consume Query Plans: receives a query and retrieves from the Gateway API Services a Query Plan; then, applies it to the virtualised RDF.
  • Generate query answers: manages the different query solutions generated and outputs them with the proper format.

Figure 3 Mode of operation of the GatewayAPI Services

Finally, both the Gateway API Services and the Distributed Query Client follow the secured communications protocol established in VICINITY by receiving and responding all the requests through the P2P network.

Clone this wiki locally