Skip to content

Ecosystem

AURORAL ecosystem can be described in one sentence as a network of nodes that are coordinated by a control plane.

Ecosystem

The decentralized network

The AURORAL network is composed by nodes that can interact among them. Each node belongs to an organisation and has two main purposes:

  • Data integration and standarization
  • Gateway into AURORAL (Discovery and data Sharing)

In the node detail section below we will dig in the inner side of the node.

The control plane

AURORAL platform uses a XMPP server and a web interface to configure the control plane. By creating relationships and data sharing agreements, the users of the platform are configurating the communication channels and the ACL rules that afterwards will be enforced by the nodes.

The web interface that allows to:

  • Configure visibility rules of the metadata (Who can discover me?)
  • Configure accessibility rules to the data (Who can access my data?)

The web interface, otherwise known as Neighbourhood Manager, is used also for creating the virtual entities of the nodes, which among other things, will hold the node credentials. In general, the Neighbourhood manager can be seen as the AURORAL 'social network', users can configure their accounts, see their assets and find other users with which they might want to collaborate.

The AURORAL Node in detail

The node is a client application that can be installed in most computers and servers (supporting AMD64, ARM64 and ARMv7 architectures). Download the Node here!

Node

As we can see in the picture, an AURORAL Node can communicate with the data assets or real world, by means of using an adapter, on the other hand, the Node is the gateway to communicate with other AURORAL Nodes and access configuration and authentication services from the Middleware.

Now, we will describe each part of the Node and their utility:

Agent

The AURORAL Agent coordinates the various tasks that the Node can do. Its main functionalities are:

  • Coordination of the AURORAL Node modules
  • Expose API to interact with the communication and semantic interoperability modules. Thus, acting as an abstraction layer of the rest of the Node components. The agent API will be known as the AURORAL OpenAPI.
  • Coordinate registration process between semantic modules and gateway.
  • Store credentials and other information relevant to the registered objects.
  • Process, validate against ACL rules, and redirect data requests to the adapter.

Gateway

The AURORAL Gateway shall provide the following functionality:

  • Act as communications module of the AURORAL Node
  • Relay consumption requests to AURORAL Node Agent
  • Expose API to allow resource consumption of remote items
  • Expose API for registration and discovery
  • Access Neighbourhood Manager to obtain updates and configuration rules
  • Access the ACL rules over DLT Network through the interface with the DLT Client, or alternatively, it is possible to choose using XMPP network.

WoT Directory

The WoT Thing Description Directory allows to discover Thing Descriptions (TD) from one AURORAL Node to another by point-to-point and discovery a set of Nodes that are discoverable to the former according to the AURORAL access control and privacy policies by point-to-cloud. The WoT Thing Description Directory provides the following functionalities and services:

  • Register TD objects in the directory.
  • Retrieve TD objects from the directory.
  • Update TD, modifying totally or partially and existing TD.
  • Remove a TD object from the directory.
  • Provides a publication/subscription mechanism allowing to follow the creation, updates and delete operations done over the TD.
  • Retrieve all the TD objects stored in a directory or a subset of TD.
  • Validate TD objects before registering.
  • Provide mechanism that enrich the validation already afforded.

To persist the triples the default storage is Jena-Fuseki.

ODRL Service

The ODRL Privacy Manager allows applying privacy policies over the TD registered in the WoT Thing Description Directory and check if the request is allowed to discover or access the resources associated to a privacy policy. Its main functionalities are:

  • Applying context privacy policies.
  • Applying content privacy policies.
  • Applying context compliance checking.
  • Applying content compliance checking.

This privacy policies allows to, for example, discover resources only if the requester is inside a certain location or discover resources only in certain moments of the day.

SHACL Validator

The SHACL Data Validator apply context and content data validation over the AURORAL Node. For that, the main functionalities are:

  • Ensures that all data across the Node is always aligned to the AURORAL ontology.
  • Apply some restriction over the data.
  • Perform CRUD operations over SHACL shapes.
  • Validate data express in RDF or another format stored in the Node.

Adapter

The adapter allows to perform operations or enrich the data stored in the AURORAL Node from the connected data sources. For that it should:

  • Apply context enrichment to the TD stored in the AURORAL Node.
  • Perform operations across the AURORAL Node.
  • Apply a semantic upgrade to the TD stored in the AURORAL Node.
  • Translate heterogeneous formats (i.e., JSON or CSV) to W3C standards (i.e., RDF or JSON-LD).

It is possible to run a Node without adapter, for this end, a service or application that wishes to use AURORAL can communicate directly with the AURORAL OpenAPI that is exposed by the Agent component.