Advertisement

Towards an Internet of Agents model based on Linked Open Data approach

  • Pablo Pico-Valencia
  • Juan A. Holgado-TerrizaEmail author
  • J. A. Senso
Article

Abstract

The Internet of Agents (IoA) is a current approach to the Future Internet that has arisen as an alternative to mitigate the limitations of the Internet of Things (IoT) concerning autonomy, reasoning and social capabilities. The aim of this paper is to present a novel architectural model governed by semantic contracts, published as linked data which describe the main aspects regarding the IoA domain, such as context, social circles, services ecosystems, IoT resources, and real-time restrictions. This proposal introduces some mechanisms such as (i) Linked Open Agents (LOAs) as the main unit of process for coordinating and managing IoT-objects, (ii) Linked Agent Contracts (LACs) as contractual semantic descriptions of entities of IoA ecosystems, (iii) an ontology named IoA-OWL that covers the current main aspects related to the IoA, (iv) a Reference Architecture for the IoA approach driven by LOAs and LACs, and (v) a mechanism for agent-discovery based on semantic descriptors. Both the model and its mechanisms are integrated, in order to improve the semantic interoperability and intelligence in heterogeneous IoT networks controlled by Multi-Agent Systems. Finally, a case study is proposed for a scenario of Ambient Intelligence as a working example of the novel architectural model. In addition, a qualitative and quantitative evaluation is then performed to analyze the applicability, performance, functionality of our proposal. A better performance was obtained for the agent discovery process with our architecture in contrast to JADE Yellow Pages and the Java implementation of the Universal Description, Discovery, and Integration.

Keywords

Linked Open Data Internet of Agents Internet of Things Linked Open Agent Contract Ontology 

Abbreviations

AAA

Authentication, Authorization and Accounting

ACL

Agent Communication Language

AmI

Ambient Intelligence

BDI

Belief, Desire, Intention

DbC

Design by Contract

DOHA

Dynamic Open Home-Automation

DPWS

Devices Profile for Web Services

FIPA

Foundation for Intelligent Physical Agents

IoA

Internet of Agents

IoS

Internet of Services

IoT

Internet of Things

IRI

Internationalized Resource Identifier

JADE

Java Agent Development Framework

JSON

JavaScript Object Notation

JSON-LD

JavaScript Object Notation for Linked Data

jUDDI

Java implementation of the Universal Description, Discovery, and Integration

LAC

Linked Agent Contract

LOA

Linked Open Agent

LOD

Linked Open Data

MAS

Multi-Agent System

OWL

Web Ontology Language

REST

Representational State Transfer

RDF

Resource Description Framework

SOA

Service-Oriented Architecture

SOAP

Simple Object Access Protocol

SPARQL

SPARQL Protocol and RDF Query Language

URI

Uniform Resource Identifier

UUID

Universally Unique Identifier

WAC

Workflow for Agent Contract

XML

Extensible Markup Language

1 Introduction

Nowadays, it is common to see people interacting in their daily lives via smart devices. The Internet has been positioned as the prominent medium of communication employed for data exchange to date. Consequently, the concept of Future Internet [43] has originated, along with related concepts such as the Internet of Things (IoT) [48], Internet of Services (IoS) [82], Internet of People (IoP) [64], and Internet of Agents (IoA) [93].

The IoT is an emerging paradigm in which everything and everyone in the real and physical world is interconnected through the Internet, forming a worldwide dynamic network of objects [13, 57, 89]. Commonly, these objects are composed of sensors and actuators and support Machine-to-Machine (M2M) communication, which enables both human–device and device–device interfaces to exchange information [48]. Hence, objects are enabled to perform low-human intervention communication processes that facilitate the execution of automation processes [13].

Trends regarding the IoT require objects to be capable of behaving in a smart and autonomous way. However, currently, the majority of marketed objects do not support a mechanism that allows a behavior with these features to be dynamically defined and consequently, there is a line of research addressed at achieving this issue through the integration of IoT and agent technologies [67]. This new approach is called IoA [93]. The main goal pursued by this emerging approach is oriented towards mitigating the deficiencies related to reasoning and social capabilities in IoT scenarios through the use of software agents [74]. As result, IoT-objects are converted into “smart objects” which are capable to operate autonomously, proactively and reactively as dynamic scenarios demand [87].

The achievement of the goal addressed by the IoA implies that heterogeneous Multi-Agent Systems (MASs) must be interconnected in order to reach the semantic interoperability among objects that are connected to heterogeneous IoT networks. The semantic interoperability in the agent domain essentially lies in agents that operate in MASs must be able to interact and communicate with other agents which run in a different MAS. Nonetheless, this is a concern that agent technologies still have to confront because, despite the efforts made to attain global interoperability between agents in terms of communication languages such as the FIPA Agent Content Language (ACL) [24], there are frameworks in which agents cannot interact among them even if they use the same technology [37].

The complexity of improving semantic interoperability in MASs essentially lies in the agent discovery process, which is almost impossible to perform in a global ecosystem as required by the IoA, due to the fact that most agent applications have been developed following different guidelines. To be more specific, some concerns presented in some agent-based applications are related to the following limitations: (i) use of heterogeneous vocabulary to describe agents that hinders its discovery by third parties, (ii) use of specific ontologies to describe concepts that in most cases are not standardized, (iii) use of a non-standard agent communication language which makes inter-agent communication unfeasible, and (iv) discovering processes performed with limited data of catalogs which provides not so accurate results [17, 24, 71]. Based on these limitations, and considering the scope of the Semantic Web to retrieve information based on its meaning and not just the syntax, we have proposed a semantic compact model to describe IoA entities based on semantic contracts.

The main contributions of this paper to the literature of the agent field can be summarized as follows:
  • A compact and extensible ontological model—called IoA-OWL—is proposed based on a full ontology built in Ontology Web Language (OWL), being the most widely employed standard for sharing semantic data on the Web. This model defines the main vocabulary regarding the IoA, such as context-aware data, social circle, services ecosystem, agent architecture and its artifacts, IoT-objects and their resources, and non-functional information of the agent. In this way, agents associated to the IoT are similarly described.

  • A semantic contract model understandable by both humans and machines called Linked Open Contract (LAC) is defined. This contract model is represented following the format employed for the publication of Linked Open Data (LOD). This enables to agents of heterogeneous ecosystems can be described by reusing distributed descriptors previously published as open data.

  • The definition of a new autonomous, smart, active entity called Linked Open Agent (LOA) is formulated, which thanks to semantic descriptors stored in a LAC and a specialized workflow of control is able to reason over IoT-objects in an intelligent way by interacting with agents of different ecosystems.

  • A reference architecture for developing IoA ecosystems is proposed based on the Linked Open Agent concept proposed in this paper. In addition, a fully implementation of an IoA ecosystem conform to the proposed reference architecture demonstrates the technical feasibility to create collaborative smart scenarios of IoT governed by agents such as smart communities for neighbors.

  • Finally, a qualitative and quantitative evaluation is performed over our implementation of IoA ecosystem in order to analyze the applicability, performance and functionality of our proposal. Precisely, the agent discovery process based on reasoning semantic descriptors as we proposed, provides the possibility to achieve a wide agent recovery that meets the requests with a good performance, and high accuracy.

This paper is organized as follows. In Sect. 2, we present the main studies in which ontologies for describing main issues regarding the IoT and agents have been proposed. In Sect. 3 the main aspects regarding IoA ecosystems are introduced. Section 4 describes both the core and components of the IoA-OWL model through formal tuples. In Sect. 5, we formalize the concepts associated with LOA entities such as unit of semantic description (LACs), workflow of control, mechanism of collaboration and a reference architecture for IoA. Additionally, in Sect. 6, a study case applied in the Ambient Intelligence (AmI) area is presented and the performance of the proposal is evaluated and compared with the discovery process of both Java implementation of the Universal Description Discovery and Integration (jUDDI) [85] and Yellow Pages of Java Agent Development Framework (JADE) [8]. Finally, in Sect. 7 our conclusions and future studies are outlined.

2 Background

Although several agent tools such as methodologies, languages, frameworks, and ontologies have been proposed [84], as Yu et al. assert “very few practical MASs have been deployed after such a long period of intensive research and development”. Therefore, in order to achieve higher popularity and standardization, the Agent Oriented Software Engineering must adopt new emerging paradigms [93]. A suitable example is the good practices adopted by both Service Oriented Architecture (SOA) and Semantic Web by introducing service contracts and semantic descriptors. This section presents an overview of the main ontologies specialized in the description of agents and aspects related to the IoT.

2.1 IoA, related preliminary ontologies

Recent developments in the field of IoT have led to a renewed interest in agent-oriented technologies [2, 30, 45, 55, 65, 68, 91]. However, with regards to the IoA domain, few papers directly refer to this approach. On the one hand, Yu et al. [93] assert that the IoA is an evolution of the agent paradigm in order to include the participation of end-users to change the configuration of agent features at runtime. On the other hand, in Pico-Valencia et al. [74], the IoA is seen as a smart agent interaction, defined in an upper level that governs the IoT resources, that includes not only the agent structure and its agent artifacts but also important additional aspects such as its context execution, social nature, real-time restrictions, service ecosystem, and a mechanism for planning tasks. Against this background, ontologies regarding agent technology, IoT concepts, and aspects related to context-aware systems are key to accurately describing the main aspects handled by the IoA.

In Table 1 the most 16 relevant online ontologies related to the IoA are summarized. The availability of these models was checked by employing specialized tools of the Web Semantic such as Linked Data Portal (http://linkeddata.org/) and Swoogle (http://swoogle.umbc.edu/2006/). As the column 4 shows, five of these models are ontologies published as Linked Open Vocabularies (1–5), while the remaining are specific ontologies (6–16) that cover individual concerns of the IoT or agents.
Table 1

Main online ontology models for describing most relevant issues of Internet of Agents

#

Semantic models

Format

Type

Avai.

Reus.

Docu.

C

O-P

D-P

1

FOAF [16]

RDF

Vocabulary

Y

Y

++

Y

Y

Y

2

VCard [42]

RDF

Vocabulary

Y

Y

++

Y

Y

Y

3

Computer [79]

OWL

Vocabulary

Y

Y

++

Y

Y

Y

4

Dublin Core [25]

RDF

Vocabulary

Y

Y

++

Y

Y

Y

5

M3-lite [39]

OWL

Vocabulary

Y

Y

++

Y

Y

Y

6

Time [23]

OWL

Ontology

Y

Y

++

Y

Y

Y

7

Cobra [20]

RDF

Ontology

Y

Y

++

Y

Y

Y

8

CoDAMoS [22]

OWL

Ontology

Y

N

+/\(-\)

Y

N

N

9

COforAmI [76]

Theoretical

Ontology

N

N

++

Y

Y

Y

10

INRIA SNA [27]

RDF

Ontology

Y

Y

++

Y

Y

Y

11

AgentOWL [52]

Theoretical

Ontology

N

N

++

Y

Y

Y

12

SOUPA [21]

Theoretical

Ontology

N

N

\(-\) \(-\)

Y

N

N

13

OntforAMobile [77]

Theoretical

Ontology

N

N

\(-\) \(-\)

Y

Y

Y

14

BDI-workflow [59]

Theoretical

Ontology

N

N

+/\(-\)

Y

Y

N

15

OWL-S [61]

OWL

Ontology

Y

Y

++

Y

Y

Y

16

GOforIoT [40]

Theoretical

Ontology

N

N

+/\(-\)

Y

Y

N

C reusing of classes; O-P reusing of object-properties; D-P reusing of data-properties

In column 3 of Table 1, the format of the model employed to store each semantic model is defined. Ten of these models have been expressed and published in OWL and RDF (Resource Description Framework) formats, while the six remaining were only proposals explained in scientific publications. Both OWL and RDF formats are widely used markup languages for publishing and sharing data on the web using ontologies. In addition, the column 5 labeled as Avai. shows that not all models listed were available online. Indeed, six of the sixteen models were not available. However, the conceptual ontologies could be analyzed by including required classes, object-properties and data-properties already devised by other groups. The column six labeled as Reus. shows which models were imported in the proposed ontology (Y), and which models were not directly employed (N). The seventh column labeled as Docu. shows if each semantic model has complete (++), partial (+/−) or limited (\(-\)\(-\)) documentation. Finally, last three columns show if our proposal reused some of the classes (C), object-properties (O-P) and data-properties (D-P) of each semantic model.

Next, each semantic model included in Table 1 is briefly described together with the main vocabulary integrated within our proposed ontological model.
  • FOAF [16], Friend Of A Friend is a vocabulary to link people and information using the Web by employing social networks of human collaboration, friendship and association. Some properties employed were name and topic_interest.

  • VCard [42], is a vocabulary comprised of useful terms to describe people and organizations. Latitude, longitude, and country-name were some of the properties that were reused.

  • Computer [79], is a vocabulary that allows personal computers, laptops and netbooks to be described. The main properties employed were battery type, processor model, and memory.

  • Dublin Core [25], is a specialized vocabulary for describing resources in the Web Semantic. Creator, date and title were some of the reused properties.

  • M3-lite [39], is a taxonomy designed to enable semantical annotations for heterogeneous IoT-objects. It also includes a well-defined classification of devices based on sensors and actuators over different domains.

  • Time [23], is an ontology that provides a vocabulary for describing temporal properties of resources. Properties such as time zone and unit type were reused.

  • Cobra [20], is a location ontology that details the spatial and temporal properties of physical objects. The main properties reused were: locatedIn, locatedFar, awayfrom, locatedNearBy, inRegion and notLocatedIn.

  • CoDAMoS [22], Context-Driven Adaptation of Mobile Services is an ontology for solving challenges in the AmI area, where personal devices are considered an extension of each user’s environment, running mobile services adapted to the user and his/her context. Some important classes integrated by this model were the following: profile, service, and platform.

  • COforAmI [76], Context Ontology for Ambient Intelligence is an extension of the CoDAMos ontology for creating context-aware computing applications. Some of the general classes employed by this model were the following: service, platform and environment.

  • INRIA SNA [27], is an ontology that includes the concepts and centrality measurements associated with the Social Network Analysis (SNA) [19], such as degree, betweenness, closeness, relationship and path. These were all integrated in the proposed ontology.

  • AgentOWL [52], is an ontology that presents a model that enables the modeling of agent environment (collaborators), agent context (resource, event) and its results (answer agent) for JADE platforms [8].

  • SOUPA [21], is a standard ontology for ubiquitous and pervasive applications that describes deliberative agents based on belief, desire and intention. The main reused classes were the following: belief, desire and intention.

  • OntforAMobile [77], Ontology for Mobile Agents is an ontology focused on modeling the agent mobility. Some relevant classes reused were the following: host, location, visit, and migration constraints.

  • BDI-workflow [59], is an ontology compatible with BDI agents for describing the binding process of semantic web services according to workflows. Concepts like goal, belief, plan, workflow were reused.

  • OWL-S [61], Web Ontology Language for Services is an ontology for managing semantic services by using a profile, a process model and a grounding. Properties associated with the profile and model were reused by the proposed model.

  • GOforIoT [40], General Ontology for IoT is a global ontology for IoT that employs a high-level abstraction to describe the technical functionalities of hardware devices. Sensor, actuator and unit of measurement were some of the concepts reused by our ontology.

3 Modeling the IoA

The IoA approach integrates both software agents and IoT technologies in order to improve the level of autonomy and intelligence in generic IoT environments that generally operate under certain predefined rules. Some related works such as the proposals of Mzahm et al. [65, 67], Fortino et al. [30, 31], Nieves et al. [68], Leong et al. [55], Al-Sakran et al. [2], Kaminski et al. [45] and Xu et al. [91] have modeled this integration, but they do not cover all the important aspects that allow the goal pursued by the IoA approach to be achieved. In order to define these aspects, this section analyzed the scope of the main proposals related to the integration of agents and IoT.

3.1 Main aspects

The IoT enables things or devices anytime in any context, anywhere, any service and any business and any network [1, 5, 33, 73]. In order to achieve this goal, the scientific community has raised and worked on improving aspects such as identification, sensing, communication, computing, service and semantic [1, 5, 48]. In addition, some challenges such as interoperability and standardization, naming and identity management, privacy and security, mobility and reliability have been raised and they are under improvement. But the fulfillment of the objective pursued by the IoT has not been fully addressed. Hence, as Mzahm et al. [67] assert, many devices still have limitations to perform communication processes and action tasks at an inter-network level. Thus, the Agent of Thing concept and consequently the IoA paradigm arise as an alternative to add autonomy, interoperability and intelligence to IoT-objects and networks.

In order to achieve the sufficient autonomy, provide interoperability on different types of IoT-objects and be able to act proactively in an intelligent way, agents require to have a detailed knowledge of the properties that characterize the agent model, the context where they are executed, the type of IoT-objects on which they can access or the entities or resources with which they can collaborate, among others. We have conducted a literature review process to identify the main agent-based models of IoT-objects proposed to date and the aspects they modeled to perform control tasks. As result of this study, we organized those around six aspects (profile of agent, context-aware data, social-context, service ecosystem, agent artifacts and IoT resources) into a single model. Fifteen models were considered in this study and their employed descriptors were deeply analyzed. The results are detailed in Table 2.
Table 2

Use of the aspects profile, context, social, service, model and thing by the main models of agent based IoT-objects

#

Model

Profile

Context

Social

Service

Model

Thing

1

Agent of Things [66]

N

Y

N

N

N

Y

2

IoT-a [18]

N

Y

Y

Y

N

N

3

Smart object [30]

N

Y

Y

Y

N

N

4

Knol et al. [49]

N

N

N

N

N

Y

5

Manate et al. [60]

N

Y

N

Y

N

Y

6

Sol [7]

Y

Y

N

Y

Y

N

7

NFC-agent [58]

N

Y

Y

N

N

N

8

AIoT device [46]

N

Y

Y

Y

N

Y

9

Rest agent [55]

N

Y

N

N

N

N

10

MAF [10]

N

N

Y

N

N

N

11

Rest agent [56]

N

Y

Y

Y

N

Y

12

HTML5 agent [44]

N

N

N

Y

N

N

13

AgentJS [12]

N

N

Y

Y

N

N

14

PherCon [36]

N

Y

Y

Y

N

N

15

DLDA agent [26]

Y

Y

N

N

N

N

The content of the Table 2 show which aspects have been used by the main models of agents for IoT. The analysis of the fifteen models under study confirmed that using descriptors related to the six proposed aspects (Profile, Context, Social, Service, Model and Thing) helps in the execution of decision making processes in IoT (e.g., contextual data has been used to execute actions according to the location of the IoT-objects, resource data of the IoT-objects such as the battery level has been used to monitor the state of these objects). However, none of the models included in Table 2 cover all six aspects in an integrated manner. This is because each model has been designed for very specific objectives (mostly context-aware systems).

It is clear to see that the aspects related to the contextual, social and service are the mostly employed aspects to describe agents based on IoT-object systems. We also emphasize that the fourth aspect, Thing, used by this kind of systems is related to the description of IoT-objects. Finally, the least significant aspects are those related to the profile and model of the agents. However, these last aspects have been considered as potentially relevant by this proposal because, on the one hand, the metadata of the agent profile holds relevant information to define the social circle of an agent and, on the other hand, the metadata stored by the model aspect saves useful information regarding the internal structure of the agent (e.g., behaviors and their trigger times) from which the agent can be automatically generated.

Based on the good practices adopted by the agent-based IoT models analyzed in Table 2, we consider that as more descriptors are used to describe IoT (organized in specific aspects), more data inputs are provided to agents enabling them to make more accurate decisions in IoA ecosystems.

3.1.1 Profile of agent

Adding non-functional information is useful to describe the features and capabilities of agents. From this information agents can be discovered on MASs [7]. Therefore, we believe that it is a remarkable information that must also be included to describe the IoA. In order to cover this concern, the modeling of an AgentProfile has been needed.

Following some IoT challenges regarding trust, security, reliability and semantic interoperability [5, 34, 63], the AgentProfile must describe the following information: (i) identification, state and requests that the agent has successfully completed, (ii) credentials of agent for establishing secure communications accomplishing the Authentication, Authorization and Accounting (AAA) protocol [70] in a transparent way so that agents can define their identity when a communication process starts, (iii) a set of rules which indicate how to create secure agents, (iv) a set of input parameters that allow the agent to operate in a controlled way in the platform where it lives, and (v) a set of real-time restrictions that allow to know the quality of service offered by agents when providing data to their counterparts.

3.1.2 Context-aware information

Managing context data is very important in the IoT and, consequently, in the IoA. In order to introduce contextual information to agents and their managed IoT-objects, we have considered mandatory to model the context aspect. This aspect we have called AgentContext is useful because the agent discovery process can be executed more accurate and agents can adapt themselves based on their contextual conditions. Taking into account the challenges, such as sensing, semantic, and intelligence [5, 34, 35], the AgentContext must manage the following issues: (i) geolocation information from which an agent can act based on its own geographic position and the geolocation of objects that the agent controls, (ii) location information of the objects managed by each agent which allows the agent to execute actions based on the objects position with respect to other objects or referential entities, (iii) information associated with the time zone where the agent and objects are installed to execute temporary actions programmed by the user, and (iv) information regarding the technological platform where the agents live. These information allow any entity (e.g., agent, IoT-object, user) to send requests for information or sensing/control actions more accurately.

3.1.3 Social-context information

The social networking has led to the emergence of a new approach called the Social Internet of Things. This approach has been proposed in order to enable agents to manage their own collaborative networks, similar to human social networks [6, 57, 89]. Based on this assumption, we have found it useful to model a new aspect we called AgentSocial. Properties associated with this aspect will make it possible in IoA ecosystems to model social networks based on the relationships that arise from the interconnection of devices controlled by agents. Thus, the process of discovering agents can be modeled based on the social power of agents.

The information linked to this aspect is summarized as follows: (i) topics of interest related to the agent’s goal, (ii) data and units of measurement that the agent is interested in receiving or providing to potential counterpart agents that are part of the global social network of IoA, (iii) list of agent counterparts or partners that collaborate with the modeled agent to achieve the goal of control over the object it manages, and (iv) a set of measures of centrality associated with agents that allow us to know the power of each agent in the global IoA social network in which it collaborates.

3.1.4 Service ecosystem information

The AgentService aspect covers functional aspects of the IoT such as computation, service management and service composition [1, 5, 57, 89] in order for IoA to keep SOA [28] support.

In general terms, we consider that this aspect should allow the modeling of agent actions based on the following web services models that are most widespread today: (i) SOAP (Simple Object Access Protocol) [28] web services deployed mostly by SOA applications for the development of business processes, (ii) RESTful (Representational State Transfer) [86] web services deployed in REST applications, objects and specialized IoT frameworks, (iii), and DPWS (Device Profile for Web Service) [92] web services typically deployed on devices such as printers, sensors, among others. Furthermore, we suggest covering other models of web services specific to Pervasive Computing and IoT, not as popular as the three previous ones, such as (iv) DOHA (Dynamic Open Home-Automation) [80] web services. This service model manages data acquisition and fusion based on a service composition model in every IoT-device according to its computing capacity.

3.1.5 Agent artifacts information

Because the functionality of the agents is determined by the artifacts that it integrates—independent of the model it employs (e.g., reactive, deliberative or hybrid), we have considered it relevant to describe elements that constitute the agent’s architecture. For this purpose, we have integrated an additional aspect called AgentModel. The metadata that this aspect includes are dependent on the architecture of the modeled agent. However, we have focused on the reactive model because the agents created under this model support better interactions in ecosystems where a high number of agents interact.

In the specific case of reactive agents, these agents should have responsiveness to detected stimuli in the environment where they operates [81]. The following elements should be described: (i) behaviors as a set of actions (e.g., web service invocations for accessing IoT-objects, communication operations with other counterpart agents) associated with a reactive agent that is executed when an event occurs in its environment, (ii) temporal parameters which determines the frequency of the behavior execution or its maximum deadline, and (iii) workflows as mechanisms that address the control actions of the agent itself.

3.1.6 IoT resources information

Finally, considering that each IoT-object has an agent linked to it, we have considered necessary to describe the resources that each IoT-object has associated to it. Hence we have included properties in a new aspect called AgentSmartThing. In general terms, it is recommended to prepare the information of the following resources: (i) technical aspects of the network in which the IoT-object is connected, such as host, port, logical name of the object, among others, (ii) list of functionalities/operations supported by the IoT-object, as well as the data and units of measurement provided by the object itself, (iii) computational resources associated with objects such as: compatible communication interfaces, battery level, memory capacity, bandwidth and processing, among others, and (iv) context information where the IoT-object is installed similarly to the agent contextual information.

4 A semantic model for IoA

A compact ontology for the IoA paradigm has not been still developed to date, as we analyzed previously. The IoA does not only require the management of non-functional aspects associated with agents but also communication mechanisms and agent artifacts as most papers propose. On top of these concerns, it is also necessary to design the appropriate mechanisms to provide to machines and users the ability to easily discover and collaborate with other partner agents in heterogeneous IoT networks. Thus, both machines and users can benefit from optimizing their control tasks. This section presents an overview of a full ontology proposed by Pico-Valencia et al. [74]—compatible with the main aspects regarding the IoA detailed in Sect. 3.1—aimed at describing agents which have the capacity to discover the most suitable counterpart agents for performing tasks over the IoT ecosystem. This discovery process is driven by a semantic reasoner and a set of semantic descriptors or labels described according the IoA-OWL ontology. This means, therefore, that the ontological model to be described below is the key to integrate the semantic search of resources in IoT ecosystems.

4.1 Upper ontology for IoA

The IoA-OWL [74] is an ontological model for describing IoA ecosystems. This model integrates six ontological components from which it is possible to save enough information in order to execute semantic reasoning processes that recover accurate resources in IoT networks managed by agents. Thus, these agents can be able to act autonomously and socially over different dynamic IoT ecosystems as well as MASs. Formally, this model is represented by a six-tuples as shown in (1), where \(P_{a}\) is the AgentProfile, \(P_{c}\) the AgentContext, \(P_{s}\) the AgentSocial, \(P_{m}\) the AgentModel, \(P_{v}\) the AgentService and \(P_{t}\) the AgentSmartThing component. All of them detailed in Section 3.
$$\begin{aligned} O_{IoA} <P_{a}, P_{c}, P_{s}, P_{m}, P_{v}, P_{t} > \end{aligned}$$
(1)
The implementation of each component has been achieved through an OWL sub-ontology. Using these uncoupled ontological pieces, it is feasible to extend our proposal model according to future necessities such as agent mobility or the agent normative model, among others. Next, Fig. 1 shows the detailed model at the implementation level. The diagram shown is the ontological graph generated by the ontology editor Protegè (https://protege.stanford.edu/). The six components were included through the use of six object-properties. The presents property and its corresponding inverse-property isPresentedBy integrate the AgentProfile. The acts property and its inverse property isActingIn allow the integration of the AgentContext component. Similarly, the leans and isLeanedBy properties enable us to describe the information concerning the AgentSocial component.
Fig. 1

IoA-OWL upper ontology and ontological components

The AgentModel was linked through the supports property and its inverse property isSupportedBy. Next, AgentService was integrated into the ontological model through the offers and isOfferedBy properties. Finally, the AgentSmartThing component was integrated with the manages property and its inverse property isManagedBy. These jointly coupled components constitute the IoA-OWL ontology from which the IoT-objects and their linked agent are semantically described in order to be easily discovered by their partners.

We have made great efforts to identify the most appropriate ontologies regarding IoT and software agents to be reused in our proposal. It is not the intention of this paper to start over and create a complete ontology, but to identify the most relevant classes, data-properties and object-properties in order to compose a new model capable to support the most common aspects handled by the IoA domain. Once this has been clarified, next, a specification of each component was formalized by using tuples.

4.2 Agent profile component

The AgentProfile describes non-functional properties of the agent. Formally, and in a mandatory way, an AgentProfile is represented by eight-tuples, as (2) details.
$$\begin{aligned} Pa_{i} <pid_i, pn_i, pd_i, [optionalElements], pB_i, pO_i, pC_i, pP_i, pRT_i> \end{aligned}$$
(2)
The first three elements are data-properties which describe the basic agent aspects: identifier (\(pid_i\)), name (\(pn_i\)) and description (\(pd_i\)). However, it is possible to include optional data-properties such as status (\(ps_i\)), version (\(pv_i\)), date of submission (\(pds_i\)), date of publishing (\(pdp_i\)), requests (\(pr_i\)) and accomplished requests (\(par_i\)) if required. On the other hand, the four remaining elements constitute object-properties which link the agent to other entities. This properties are described as follows:
  • The createdFrom property determines the Building-Model (\(pB_i\)) used to create the agent. A building model is a set of rules that show details about the creation of agents and which are helpful for validating each agent before publication.

  • The hasOwner property allows the Owner (\(pO_i\)) of the agent to be described. An owner is the creator or provider of the agent, and he/she is described by an identifier, name, website and phone.

  • The hasCertificate property binds the Digital Certificate (\(pC_i\)) with the agent. A certificate saves information regarding the credentials of the agent, which enables secure communication processes and trust to third-parties.

  • The hasParameter property allows specifying the temporal Parameters (\(pP_i\)) that the agent uses to execute both the task of controlling IoT resources and the task of discovering services in the IoA ecosystem.

  • The hasRestriction property links to the Real-Time Constraints (\(pRT_I\)) that the agent satisfies for the achievement of its goal. Each real-time constraint is described by a real-time parameter, and operator and a numerical value expressed in milliseconds.

This sub-ontology was defined by reusing FOAF terms. Nevertheless, \(pB_i\), \(pO_i\) and \(pC_i\) were introduced by using new vocabulary. The information saved in this component allows external agents to identify the most relevant agents for use in a specific domain based on the metadata of non-functional agent aspects. For instance, to determine if there are agents for the measurement of a specific condition.

4.3 Agent context component

The AgentContext characterizes the current situation regarding the real physical environment where the agent runs [94]. On this background, the context is formally represented by seven-tuples mandatories as shown in (3).
$$\begin{aligned} Pc_{i} <cid_i, cn_i, cd_i, cL_i, cT_i, cN_i, cP_i, [optionalElements]> \end{aligned}$$
(3)
The first three elements are data-properties and the remaining ones are object-properties. Data-properties such as identifier (\(cid_i\)), name (\(cn_i\)) and description (\(cd_i\)) describe a brief piece of information about a specific agent context. On the other hand, the remaining five elements allow four entities regarding context-aware systems and one additional entity related to agent context can be linked. All of them were introduced by using the isDescribedBy property:
  • Location (\(cL_i\)) context was defined by reusing the Cobra 4.0 ontology in order to include spatial properties such as locatedIn, locatedFarAwayFrom, nextTo, insideOf, outsideOf, locatedNearBy and behind.

  • To define Time (\(cT_i\)) context data-properties supported by Time and VCard ontologies such as time zone, unit time and local time were reused.

  • The Computational-Node (\(cN_i\)) context is the habitat where agents live. This context is formed by a personal computer or smart device, which was semantically described by using the Computer and m3-lite ontology.

  • Agent-Platform (\(cP_i\)) is described by using own data-properties such as identifier, name, description, host and port of the agent-platform.

  • Finally, the Geolocation (\(cG_i\)) context was defined by using terms of the VCard ontology. Thus, the description of geographical data such as country, locality, latitude and longitude was possible. It is important to emphasize that this element is optional because not all devices support geolocation by themselves.

The information saved by this sub-ontology gives agents and IoT-objects contextual data that the reasoner of the agent can employ to act coherently in dynamic environments where the real world-context is crucial to understanding the situation in which a functionality is provided [3]. Hence, agents in IoA have knowledge about the current environment and the changes that occur in order to manage the IoT resources consistently. For example, a task in which this information is relevant could be the acquisition of the meteorological prediction of the zone where the sensors of an IoT network are installed.

4.4 Agent service component

This component was designed taking into account the integration of heterogeneous services as agent actions [72, 75]. Therefore, the actions executed by the agent encapsulate a set of web services—SOAP, RESTful, DPWS, DOHA—logically organized to achieve a specific goal of the agent. Each service is formally represented by five-tuples as (4) shows.
$$\begin{aligned} Pv_{i} <su_i, sPr_i, sIP_i, sOP_i, sO_i> \end{aligned}$$
(4)
The unique data-property of this component is the contract Uniform Resource Identifier (URI) (\(su_i\)) which defines the URI of the document that describes the web service which offers the functionality required by the modeled agent. Remaining elements are object-properties and they are introduced as follows:
  • The non-functional information about the service included as a Service Profile of OWL-S ontology [61] (\(sPr_i\)) was bound by means of the present property.

  • A set of Input Parameters (\(sIP_i\)) required by the WS for performing their operations were introduced by using the hasParameter property.

  • An Output Parameter (\(sOP_i\)) for depicting the result of the WS was included by also employing the hasParameter property.

  • Finally, an Operation (\(sO_i\)) was introduced by means of the hasOperation property. Based on this operation, the service returns a specific value.

We have extended the OWL-S model [61] because it is standardized and compatible with SOAP, DPWS and DOHA WSs. The extension of the ontological model basically consisted in the addition of descriptors to support the resources managed by RESTful services. Thereby, we provide to the IoA approach the capability of applying the IoS approach to compose complex processes from a suite of heterogeneous micro-services [88] implemented as web services. This was implemented through an API that handles uniformly the four types of services used in this proposal [75]. Thus, for example, an agent may combine a REST service to obtain the weather forecast with a DPWS service to control the air conditioning system based on predictive data.

4.5 Agent model component

This component is introduced to describe the architecture of both reactive and deliberative agents. The Model of the agent allows the agent creator to describe structural software artifacts that agents employ to define their structure. In this paper we have only considered reactive agents.

A JADE agent is an autonomous reactive entity whose functionality is modeled by using behaviors. A behavior is a computational unit that automatically triggers when an event occurs in order to solve a specific task [9]. Formally, a reactive agent can be represented by two-tuples as (5) defines.
$$\begin{aligned} Pmr_{i} <rP_i, rBehav_i> \end{aligned}$$
(5)
The hasParameter object-property allows us to describe the arguments (\(rP_i\)) required by the agent to execute its tasks. In addition, the Behaviors (\(rBehav_i\)) that coordinate the conduct of the agent are described through the hasBehavior object-property. This type of behaviors are oriented to control the object managed by the agent.

\(rBehav_i\) are software units that form part of the JADE agent structure. They are introduced at design time in order to give the agent specific functions. This type of behavior is represented by four-tuples \(rBeahv_{i} <n_i, d_i, P_i, W_i>\). The first two data-properties describe basic information, such as name (\(n_i\)) and description of the agent’s behavior. The two remaining elements are object-properties, which allow us to link arguments (\(P_i\)), and the workflow (\(W_i\)) defined by the behavior. It is not the intention of this paper to describe a language to compose workflows. A workflow can include specific control actions, invocations of operations executed over the IoT-objects through web services and even requests made to partner agents. Formally, a workflow is composed by two elements \(W_i<wn_i, wsect_i>\), where \(wn_i\) is the logical name of the workflow and \(wsect_i\) is the URI of the document where the description of the workflow is stored.

4.6 Agent smart-thing component

This component gives us essential information about IoT-objects and their resources. These will enable IoT-objects to become smart-things, this is, that IoT-objects are controlled by agents, and consequently they can act proactively and intelligently. These own agents can use the information associated with these IoT-objects to establish control over them. Formally, this component is represented by seven-tuples, as (6) details.
$$\begin{aligned} Pt_{i} <tlog_i, tnet_i, tF_i, tG_i, tL_i, tT_i, tR_i> \end{aligned}$$
(6)
The first two properties are of data-properties type: logical name (\(tlog_i\)) and host (\(tnet_i\)) of the IoT-object. The third element is an object property, Functionalities (\(tF_i\)) or operations, which specify data and units of measurement generated by IoT-objects. These ones are data that an agent obtains invoking web services and that is able to share with external entities (e.g., agents). Remaining properties are also object-properties which integrate information regarding Geolocation (\(tG_i\)), Location (\(tL_i\)) and Time (\(tT_i\)) context of the IoT-object, similarly to the context component of the agent described in Sect. 4.3. The contextual data associated with the IoT-object is additional to the managed by the AgentContext component. The first one allows knowing where the IoT-object is operating while the second one gives information to know where the agent runs. The last property, offered, allows us to describe the resources of the IoT (\(tR_i\)) such as computational resources. As an example, these metadata are useful if it is necessary to monitor the location of a mobile sensor and its battery level from which the system manager can act to prevent the object from stopping its operation.

4.7 Agent social component

AgentSocial is a component integrated to enable collaboration in the IoA domain through social entity and social circles established among the agents of IoA ecosystems. This component allows modeling the social circle of an agent guided by the topics of interest of the agent and the units of measurement required to execute the corresponding actions. The search process is supported by the SNA theory. Formally, this component is represented by six-tuples, as (7) details.
$$\begin{aligned} Ps_{i} <soc_i, soUMr_i, soUMp_i, soT_i, soSN_i, soR_i> \end{aligned}$$
(7)
The first property is a data-property called collaborative degree (\(soc_i\)). This property specifies if the agent is a collaborative unit or not. Only collaborative agents build a social circle. The remaining elements included in this component are object-properties which are described below:
  • The topic_interest property specifies the particular topics of interest (\(soT_i\)) that the agent has. Each topic of interest is described following the schema composed of field, discipline, sub-discipline and topic.

  • Units of measurement in which the agent is interested in receiving (\(soUMr_i\)) to accomplish its goal and those that it can provide (\(soUMp_i\)) among its partners.

  • \(soSN_i\) details in which social networks the agent cooperates. A \(soSN_{i}\) is represented by eight-tuples \(soSN_{i} < nn_i, nM_i, nSSE_i, nI_i, nO_i, nD_i, nB_i, nC_i>\), where the Social Network (SN) name (\(nn_i\)) is an attribute expressed by means of data-property, while the remaining are object-properties. Each SN is represented with an adjacency matrix (\(nM_i\)) of N order where N is the total of agent counterpart in the social network. Furthermore, a set of a minimum of three agents (\(nSSE_i\)) is required to create a SN. Finally, the five most-used centrality measurements, InDegree (\(nI_i\)), OutDegree (\(nO_i\)), Degree (\(nD_i\)), Betweeness (\(nB_i\)), and Closeness (\(nC_i\)) [19, 47] were introduced to the social network. These centrality measurements are employed to identify the prominent nodes in a social graph [90].

  • \(soR_i\) joins the relationships (\(soR_i\)) that an agent saves with external known agents in a SN. A Relationship is formally represented by using a triad \(rR_{i} <rn_i, rTo_i, rFrom_i>\), where the relationship name (\(rn_i\)) is data introduced through a data-property. Otherwise, the source (\(rFrom_i\)) and destination (\(rTo_i\)) of the relationship were introduced through object-properties.

Some of these properties were integrated by this sub-ontology were reused from the SNA ontology [27]. With this information collaborative agents can discover external partners. From these recovered partners the social circle and collaborative tasks are performed by the agent. An example of the use of this information is a collaborative agent that searches for partners with higher social power who are interested in comfort control actions in smart homes. Thus, the agent avoids searching in large catalogs of agents and turns to its partners only. However, the agent is also required to keep its social circle updated at regular time intervals. This aspect will depend on how dynamic the IoA ecosystem where the agent operates is.

5 Towards the IoA

The IoA is a new approach that is gaining popularity because the IoT has limitations in reasoning, autonomy and intelligence. Therefore, in the IoA domain it is necessary to rely on special agents which support the main aspects of this approach detailed in Sect. 3.1. Based on this assertion and taking into account that the current Web is tending towards the publication of data as LOD [11, 41], we propose a new concept called Linked Open Agent (LOAs) as the unit of process for IoA. In this section, LOAs, their architectural model and associated artifacts, and their handled elements are introduced and formalized.

5.1 Linked open agents (LOAs)

A LOA is defined as an autonomous software entity described by employing LOD that has associated a semantic contract called Linked Open Agents (LAC), a control workflow, and specialized behaviors that allow controlling one or more IoT-objects independently or collaboratively. On a generic basis, a LOA handles a set of semantic descriptors associated with the main issues of the IoA, such as AgentProfile, AgentContext, AgentService, AgentModel, AgentSmartThing and AgentSocial. This information stored in an integrated fashion enables them to execute discovery processes based on common descriptors closely related to IoT applications. Consequently, the probability of retrieval of specialized agent counterparts increases in comparison to platforms where certain descriptors are used in a decoupled way. The suitable management of these descriptors is important for agents running in IoA ecosystems to acquire improved and additional capabilities that generic agent models do not currently offer. These new features acquired by LOA entities are described as follows:
  • Autonomous This feature enables LOAs to act based on the modeled knowledge stored by using contracts and to agents become capable to behave with the minimum human intervention.

  • Sociable and collaborative This property gives LOAs the capability of communicating with other social LOAs, which reside on the IoA ecosystem, in order to request or provide collaboration in a proactive way. Although LOAs rely on the reactive model to define behaviors that allow them to act on the messages they receive and execute their workflow according to a scheduler, these agents also incorporate certain proactive behaviors. These proactive behaviors are carried out by the LOA themselves to take advantage of new counterpart agents published in the IoA ecosystem to (i) recover from failures of IoT-objects and external agents, (ii) optimize the processing time of their WAC, and (iii) update their social circle. In all cases, LOAs are proactively adapted.

  • Semantic This feature enables LOAs to be described semantically. Thereby, agents in the IoA have the capability of discovering others based on the semantic information stored in their contracts.

  • Open Reusing existing LOAs requires agents to publish their descriptions as open data by adopting Creative Commons (CC) Licenses [50]. Thus, the developers of IoA applications can reuse descriptors integrated to LACs that were previously published.

  • Context-aware The contextual information combined with descriptors belonging to other semantic components allow the execution of more exact and consistent control actions.

  • Smart The consistency of actions implemented by LOAs depends in part on how contract data is used. In this sense, the agents acquire an advanced level of intelligence because they perform processes based on semantic reasoning.

  • SOA-supporting The use of web services for modeling agent actions enables LOAs to execute complex tasks without becoming too heavy software entities.

  • Adaptable Dynamic environments imply constant changes. LOAs adapt their behavior according to the information contained in their LAC and workflow. Both elements are updated with the information of the environment where the agent is running.

  • Standard-based LOAs are compatible with the ACL standard language and their contracts are standard-compliant with web-based data exchange such as JavaScript Object Notation for Linked Data (JSON-LD) [83] in order to maintain functional interoperability.

  • Testable For security reasons it is required that LOAs can be audited. Aspects such as credentials and collaboration networks in which each agent participates can be easily verified thanks to the information stored in its contract.

5.1.1 LOA architecture

In IoA it is possible to integrate collaborative and non-collaborative LOAs. The decision of the type of agent to be modelled depends in general terms on the control restrictions of the IoT-object and the level of privacy of the data handled by the LOA. Below, main features of the collaborative and non-collaborative LOAs are described:
  • A non-collaborative LOA is an agent capable of controlling its linked IoT-object autonomously; that is, using its own resources without the need for third party interaction. This type of LOAs are justified when the information they handle is a private property and cannot be shared. In addition, a non-collaborative LOA is useful when active entities capable of controlling multiple, passively operating IoT-objects with a certain level of intelligence are required

  • A collaborative LOA is defined as an agent with the ability to control its linked IoT-object and takes advantage of specialized data provided by LOAs counterparts, which are discovered through the execution of reasoning processes that use the metadata described by the LOAs that are part of the global IoA ecosystem. These types of agents are flexible entities that are able to adapt their behavior according to the resources that they can discover in their environment. It is important to note that when a collaborative LOA is created, its information becomes public for the IoA ecosystem. However, it is possible to restrict which specific data can be shared publicly by agents in order to avoid privacy issues (e.g., indiscriminate access to confidential data).

Conceptually, a LOA is defined by the description of two main entities: (i) a contract (LAC) and (ii) a workflow. Additionally, a LOA requires three components to execute properly: (i) a set of agent tasks that handle the execution of the agent, (ii) a REST interface to establish communication with the external world (e.g., access to IoT-objects), and finally (iii) an agent execution environment (e.g., JADE) where the agent is executed. These components and their interaction are illustrated in Fig. 2.
Fig. 2

Architecture of a Linked Open Agent

Firstly, the Linked Agent Contract (LAC) is the basic unit of semantic description of the LOA to describe the properties and capabilities of this agent as well as the characteristics of the agents with which LOA is collaborated based on the six components of the IoA-OWL ontology. This contract can be updated regularly in order to reflect the status of the LOA. Secondly, the workflow is the control unit of the LOA that defines the agent’s behavior. It contains a description of the sequence of actions that the agent must execute to accomplish its goals. Thirdly, the agent tasks are responsible to maintain updated the status of the LOA and assist the execution of the agent workflow. It involves the following tasks:
  • Agent Discovery Task This task is in charge of executing the discovery process for collaborative LOAs. As a result, a LOA can know other counterpart LOA candidates with which the agent can collaborate.

  • Workflow Execution Task It guides the execution of the workflow following a programming model based on a synchronized pooled loop. The reactive nature of the agent depends on the frequency of the execution of this task and the sequence of actions that the workflow contains.

  • Asynchronous Agent Response Task It intercepts and processes any FIPA message whose recipient is the own LOA. This task waits possible requests from FIPA-ACL messages, executes the corresponding request asynchronously without blocking the sender, and then sends a response to the agent sender.

Other important tasks that are not included in the list of task are related to the security in the access and data transmission using authentication mechanisms and secure channels, and the privacy determining the information available to agent ecosystem. However, in this paper, we are focused especially in the functional aspects, leaving the security and privacy issues outside the scope of this study.

Fourthly, the REST interface enables LOA to communicate with the external world (e.g., LOAs, agents that support the standard ACL and IoT-objects) using the well-known REST service web. Finally, the agent execution environment is important since it establishes how the agent model is activated (reactive, or deliberative), and manages the execution of agent behavior, the agent’s life cycle and the capability to establish communication using FIPA-ACL.

5.2 Linked agent contracts (LACs)

Software contracts have normally been employed to formalize social relationships and establish the negotiation and conflict resolution process in the agent domain [4, 15, 32]. However, we have put forward the redefinition of this unit oriented towards a semantic context. In this context, we propose the use of a software contract as a compact unit of description oriented towards depicting agent entities in a standard way [29, 38]. Thus, agents in the IoA domain can have enough information regarding the ecosystem in which they are operating and consequently they could perform semantic discovery processes based on the meaning of things. From results recovered by the discovery process, agents can take autonomous and smart decisions [53].

Once the use of the contract in the field of agent-oriented technologies has been specified, we propose the use of the Linked Agent Contract (LAC) as the basic unit of semantic description for the IoA. A LAC is a dynamic open linked document that stores an instance of the IoA-OWL ontology in order to give semantic information of both agent and its linked IoT-object. An LAC follows the formalization of the IoA-OWL ontology detailed by the six tuples defined in (1). Therefore, the contractual document is decomposed into seven documents—six of them to store the metadata of each one of the elements that constitute the IoA-OWL ontology and the remaining one to organize the URIs that link the previous six linked documents. Each one of these six documents are contractual sections whereas the document of integration of these sections is called a general contract.

The full contract follows the specifications of a linked open document. This means that a LAC accomplishes the four principles of LOD: (i) the use of URIs as names for things, (ii) the use of https URI scheme, (iii) the use of standards and (iv) the inclusion of links to external URIs [11]. As LOD is an emerging approach to the Web, we consider that it is important to the IoA must reuse any secure resource that have already been defined by the IoA domain in order to extend the approach in a universal way. In addition, LACs were also developed accomplishing the best practices of JSON-LD [83], which is currently a standard for expressing linked data as JSON format. Among these principles the following are highlighted: (i) publishing data using JSON, (ii) using well-known identifiers for describing data, (iii) caching JSON-LD contexts, (iv) identifying objects with a unique id, (v) linking entities using URIs, and (vi) using typed terms for external references. The application of these principles ensures interoperability among contracts and also provides the following benefits:
  • Easy-lightweight format readable as long by humans and machines. This allows both users and agents to know what and how a specific agent works. For users, they can understand the metadata that describes the behavior of agents. For machines, they can process contract files faster than other formats for the description of resources on the Web such as XML.

  • Description of agents compatible with the guidelines of LOD. The adoption of JSON-LD as a format for the persistent storage of agent contracts greatly facilitates the dynamic semantic enrichment process (assignment of values to descriptors that define an ontological component) of any entity related to the IoA. Agents of IoA are described by reusing same vocabulary and open linked data. Consequently, the reuse of data available on the Web is maximized.

  • Compatibility with Semantic Web data format. The use of the JSON-LD format does not only include benefits with respect to the reuse of linked data available on the global Web. From this format it is possible that the information will be represented in RDF triplets—format that allows interoperability between applications that exchange information on the Semantic Web. This is an absolute strength because reasoning processes are performed based on the descriptors stored within the contract of the agent.

  • Automatic agent generation. From the semantic descriptors stored in the contracts agents can be generated automatically, saving programming efforts. In this sense, the Design by Contracts (DbC) [62, 69] approach takes hold at IoA. This would save time in the development of systems and, in addition, applications could be built by users with no technical knowledge related to agent technologies—aspect that Yu et al. considers it a major challenge to be addressed in future agent-based applications [93].

5.2.1 General LAC

LACs are automatically generated by a specialized tool developed as part of this work. This tool, called IoA-Building Model, builds contracts following the syntax of the JSON-LD tool. In Listing 1, the general LAC is composed by three basic parts as follows:
  • Contract context Lines 2–13 include the context of the linked document, in which the prefixes used as abbreviations in the body of the contract are defined. This considerably simplifies the writing of the document and makes it easier for users to understand it if they need to work directly with its content. Furthermore, the context also defined the default @language to describe each of the components of the contract. We defined the English language to describe JSON-LD attributes that compose the LAC. However, it is possible to describe each resource described into the contract adopting other natural languages.

  • Contract identification This part includes two specific IRIs (Internationalized Resource Identifiers) to define the identifier (@id) of the contract and the type (@type) of entity (lines 14–15). The identifier employed a Universally Unique Identifier (UUID) generated by the CouchDB (http://couchdb.apache.org/) database engine that is unique for each contract. From this UUID, contracts are accessible through URIs.

  • Contractual sections links The general LAC finally includes six nodes that define the corresponding IRIs to link directly to the sections of the general contract. Lines 15–18 link to the agent profile section, lines 23–26 binds to the agent context section and so on.

5.2.2 LAC sections

The six contractual sections that form part of the previously detailed general contract links adopt the same syntax and scheme. However, instead of linking to the contractual sections as the general contract does, a contractual section is connected to the linked data that describes each component integrated by the ontology IoA-OWL accordingly. To illustrate this, in Listing 2 we present a snippet of the LOA profile section.

The context part of the AgentProfile section is shown in lines 2–10, section identifiers are defined in lines 11, 12 and finally, the descriptors of the sections are introduced in lines 13–29. Specifically, lines 18–21 show a link to the agent provider through its corresponding identifier. From this identifier, it is possible to access all the provider’s complementary information such as his/her name, contact, among others, if required. This means that a LAC reuses descriptors and only stores the basic information from which is possible to link to the datasets that must be accessed to obtain more detailed data of the entities included in the contracts. Likewise, lines (22–28) refer to a real-time parameter called execution-time. This is a parameter previously stored in a public dataset of IoA and which includes additional details of the parameter entity such as its description and unit of time. Remaining sections of a LAC are similarly described but linking the suitable datasets.

5.3 LOA wokflows

The workflow concept was introduced in the formalization of component AgentModel (Sect. 4.5) and it represents an important entity that models the behavior of the LOA. Although this concept may differ among developers, we identified the workflow as the description of a sequence of actions that an agent must execute to achieve its goals. As Listing 3 shows, it can include specific control actions, operation invocations to IoT-objects or requests to other partner agents.

The workflow structures the actions organized in a set of control blocks. Each control block specifies the control actions according to If-This and Then-That patterns. The snippet of a workflow, shown in Listing 3, describes the content of a control block consisting in a structure If-This (lines 5–15) and Then-That (lines 16–32) . This structure allows setting a rule that must guarantee the LOA; that is, if condition is satisfied, then an action is applied. Conditions and actions can be specified in base of entities (e.g., agent or IoT-object) using the channel unit in order to express, for instance, a sensor data reading or an actuator control action. Indeed, the channel describes metadata of objects is located outside the LOA context, but it is accessible from the LOA. For example, in the illustrated channel (lines 18–22), the information of the channel is complete; that is, HVAC is managed by an IoT-object called ext_central_hvac_c2 accessible at https://yy.smarthome.com. However, a channel could have some incomplete information as occurs in channel (lineas 9–11). In this case we have information about the required data (temperature) but not how it is achieved. Then, remaining information regarding the agent can be unknown initially. Those unknown metadata such as agent name, host and port of the agent platform can be obtained during the agent discovery process, or directly from the LAC in the case of IoT-object is managed by the LOA itself.

5.4 Reference architecture for the IoA

The model shown in Fig. 3 is our proposal of a Reference Model for IoA. This is a 5-layered architecture formed by: an IoT layer, an IoT-communication layer, an IoS layer, an IoA layer and a semantic layer at the highest abstraction level. This model has been created following a philosophy where each IoT-object has a LOA associated to increase the intelligence and interoperability level in IoT. This associated agent runs on the server where the MAS has been deployed.
Fig. 3

Proposed reference architecture for Internet of Agents

At the lowest abstraction level of the architecture, the IoT Layer or Sensor/Actuator Layer [57] was included. This mainly manages the sensors and actuators of smart-things connected to a physical IoT infrastructure [66]. It is important to highlight that connected devices must be compatible with wired or wireless communication interfaces of the IoT in order to their linked agent can establish communication processes and consequently, the agent may execute the suitable control actions where the specific object is involved.

The IoT-Communication Layer establishes communication between IoT-objects and the next-up layer IoS Layer by means of wireless communication such as ZigBee, WIFI, WiMax, 3G and 4G cellular, among others [34, 57]. Both IoT and IoT-Communication Layers have been employed in IoT Reference Architectures. Subsequently, the proposal has only integrated them to cover the hardware and communication issues of IoT—we have not worked at this level, and therefore it is possible that this issue can be resolved by using any currently-existing IoT middleware such as UbiSOAP, Ubiware and OpenHAB, among others [78].

Web services are undoubtedly the most important computational resources that agents can invoke to directly control IoT-objects, access data acquired from sensors or to perform business processes if required. Therefore, the IoS Layer incorporates mechanisms for consuming heterogeneous WSs belonging to different services-ecosystems including its own. The implementation of WSs by each smart-thing are usually hosted in the cloud or deployed in the object’s own architecture. Even so, this layer implements a mechanism that allows heterogeneous microservices to be invoked by employing a uniform invoking-mechanism. To cover this specific issue, we propose using an Application Programming Interface (API) oriented to invoke heterogeneous web services in order to compose workflows from SOAP, RESTful, DPWS, and DOHA services invocations [54, 75].

The next layer is the IoA Layer which encompasses a set of LOAs. Each LOA must have a LAC to describe the properties of the LOA and a workflow to define the LOA behavior. Both, LAC and workflow are locally published in an agent execution environment. This infrastructure may store the information of several LOAs at the same time. In addition, this layer allows LOAs can also store and update its LAC as global data in order to enable agents to execute reasoning processes for discovering eventual partner agents.

In regards to the selection of the software tool to develop agents, it is recommended to employ the most widespread agent frameworks based on validated theoretical bases (e.g., Jack, JADE, Jadex and Jason, among others) in order to have compatibility with already-developed applications [51]. Thus, we recommend the selection of JADE [8] for reactive agents and Jadex [14] for deliberative agents, because their theoretical bases have been validated by the scientific community. However, the use of these tools does not represent a restriction. The sole condition is that agents can communicate using the standard FIPA ACL.

Finally, the Semantic Layer is responsible to manage the coexistence of semantic knowledge and open linked data, in order to execute semantic reasoning requested by LOAs from the IoA Layer in a compact format. This layer includes two repositories. The first one is the Centralized-Repository of LACs to enable semantic reasoning on IoA. On the other hand, the second repository, IoA-OWL and Datasets Repository, stores the IoA-OWL ontology and the specific datasets of the IoA approach (e.g., parameters, owners, certificated) that can be reused to facilitate the semantic enrichment of LOA entities.

5.5 LOA building process

The process for building LOAs is driven by the IoA-Building Tool. The creation of a LOA requires the preparation of the agent platform to be used as habitat before to the deployment of the LOA instances. Subsequently, the creation of LOAs is technically feasible by following the steps illustrated in the UML Sequence Diagram in Fig. 4.
Fig. 4

UML sequence diagram to create a LOA

The LOA creation process requires the participation of the developer/user in a preliminary stage. His/her main task is to collect the data associated to the semantic descriptors that define the instance of the modeled LOA using a GUI interface. Once the descriptors have been specified, the basic architectural elements to build LOA are created.

The first stage of the LOA creation process is the identification of the LOA. A UUID is requested to the IoA Central Infrastructure in order to generate the local LAC, which it will be stored in the agent platform.

In the next stage, the LAC is generated taking into account the semantic descriptors provided by user. The LAC is validated by checking that the descriptors linking to the IoA datasets are well formed, and it is completed assigning default technical descriptions with default values

Both description documents, LAC and workflow, should be synchronized before creating the LOA that holds them. In fact, the workflow may have incomplete data on its channels in relation to IoT-objects. This data are fulfilled with metadata of the LAC from the component AgentSmartthing. An example of a channel of a workflow that can be completed with these metadata is illustrated in lines 31–37 of Listing 3. Likewise, data of interest in the LAC AgentSocial section are updated from the information of data of interest available in the workflow channels.

At the end, the set of collaborating agent tasks of a LOA is configured selecting the control time (execution of the Workflow Execution Task), and discovery time (execution of the Agent Discovery Task) and, then, is scheduled. Afterwards, a task for the agent to communicate with external entities (Agent Asynchronous Response Task) is added. Once all stages have been completed, the LOA is added to its corresponding platform and it is activated to fulfill its goals.

5.6 LOA discovery

LAC metadata stored at global (centralized) scale enables LOAs to be discoverable by external entities of the IoA ecosystem. The format used for the storage of this metadata may vary according to the technological resources available. However, it is mandatory that the LAC metadata keep compatibility with formats used by LOD software such as SPARQL, D2RQ, and Virtuoso. Two alternative formats that could be used are JSON-LD and RDF triplets formats. The first one corresponds to the JSON format for publishing Linked Data (Listing 2), while the second one corresponds to a widely spread format around the Semantic Web whose scheme is formed from three elements \(T_i <subject_i, predicate_i, object_i>\). To illustrate the use of the latter format, in Listing 4, we present the equivalent content of Listing 2 in RDF triplet format.

The agent name, state, description and provider defined in lines 15, 16, 17 and 20 of Listing 2 are equivalent to triplets 2, 3, 4 and 5 of Listing 4, respectively. The total of triplets generated from a LAC instance depends on the number of descriptor-values introduced by the developer/user during the semantic enrichment process of a LOA. This number of triplets does not hold constant because new descriptor values can be added or updated after the creation of the LAC. For example, some descriptors of the AgentSocial component such as data of interest of the agent and the list of its counterparts are dynamically introduced because they depend on the agent’s environment.
The publication of the LAC in triplets format empowers LOAs. Then, they can execute tasks to achieve collaborative goals. A collaborative goal is a target achieved by a finite set of participants (e.g., IoT-objects, agents) in which each of them perform simpler tasks that together they may solve a complex task. When a LOA is assigned a collaborative task, it must identify the set of tasks that it can perform with its own resources and it must also identify which tasks are beyond its scope. In the latter case, the LOA must explore the IoA ecosystem in a proactive way according to a scheduling in order to identify the agent counterparts that support it for achieving the target. This process of exploration also called discovery process—addressed by the Algorithm 1—is executed by the agent through the Agent Discovery Task. Because of the application of the Agent Discovery Task, the agent’s own LAC and workflow are updated. Thus, the LOA maintains a current status with respect to the IoA ecosystem.

In general terms, Algorithm 1 requires only one input argument. This argument is the name of the LOA (\(\alpha \)) that launches the discovery process. The return value is a list of partner agents (\(\rho \)) that match the current requirements of agent \(\alpha \). To create this list, agent \(\alpha \) executes a set of operations based on the content of its LAC (\(\phi \)) and its workflow (\(\omega \)). Therefore, before starting the process of exploring the IoA ecosystem, the agent \(\alpha \) should make sure that its workflow still requires to update some channels (line 2); otherwise, it does not take any action. In this way, agent \(\alpha \) can verify whether its workflow is already complete or not. An example of complete and incomplete channels are illustrated in lines 20–26 and 7–14 of Listing 3 respectively.

Then, in the second stage the core of the discovery process on the IoA ecosystem is executed based on a semantic discovery (line 6). The semantic discovery applies a reasoning engine on a strategic list of semantic descriptors as input arguments. These semantic descriptors can be selected from any of the six LAC sections of agent \(\alpha \). Depending on the reasoning operator (e.g., similar to, contextual, social power, quality of service) established as discovery criteria, a set of agents are recovered that fully satisfied the request. For example, if agent \(\alpha \) needs to recover partners by means of the data of interest and IoT-object context, we should select a combination of semantic descriptors from the AgentProfile and AgentSocial and AgentContext sections which include magnitude, unit of measurement, real-time constraints, and location. The formalization of these descriptors was described in Sect. 4 and their use will depend on the agent’s purpose and application.

Once the agents are retrieved from semantic discovery, a selection process of agent counterparts is performed in the third stage in order to discard the worst LOAs retrieved (line 8). To carry out this process it is necessary to specify the selection operator to be applied on the list of agents created from the execution of the reasoning task. Some examples of selection operators could be better response times, higher social power, among others. The application of a specific operator also depends on the agent’s restrictions and nature of the modeled system.

Finally, using the metadata of each of the agents that overcame the applied selection process, the algorithm should update both the LAC and workflow of agent \(\alpha \); that is, it updates the metadata of the channels of its workflow (line 11) and the social circle of agent \(\alpha \) (line 12). At the end, agent \(\alpha \) will increment the counter of successful discovery (line 15).

6 Deploying the IoA: a case study

As an illustrative case study, we have defined as scenario a community of neighbors that we called \(S_{ioa}<SmartCommunity>\). A community consists of a group of inhabitants who live by certain norms in apartments of different buildings in which they share at the same time common interests. In order to delimit the proposed scenario, and to be more specific, we have considered a set of three communities \(C=\{c_1, c_2, c_3\}\). Each community consists of an individual building. In addition, each of these buildings have been distributed on three floors each (e.g., an apartment on each floor). Therefore, the scenario (S) consists of 9 floors, \(F=\{\{c_1f_1, c_1f_2, c_1f_3\}, \{c_2f_1, c_2f_2, c_2f_3\}, \{c_3f_1, c_3f_2, c_3f_3\}\}\). Each community has installed several individual IoT-objects in their homes and only one of them has an agent-based system which control automatically several IoT-objects. The installed IoT-objects are specialized for giving comfort regarding temperature and illumination. The interaction between users and IoT is carried out by different mobile applications provided by manufacturers of IoT-objects. For instance, the neighbors of the community 1 and 3 can individually control in this way each IoT-objects of their apartments, while the community 2 has a MAS that controls automatically the apartments of the community. To simplify the system we have considered that all IoT-objects can be accessible by openHAB (a specialized framework for the development of smart homes based on IoT, https://www.openhab.org/), while MAS is managed by JADE agents. The diagram of the described scenario, as well as the IoT-objects that were installed at both inside (e.g., ext_tempe_c2_f3) and outside (e.g., ext_tempe_c2_1) on each apartment of each community are illustrated in Fig. 5.
Fig. 5

General diagram of the proposed scenario (smart community) modeled as IoT

6.1 IoA infrastructure deployment

The development of an IoA system following the proposed Reference Architecture (Fig. 3) involves the deployment of a centralized infrastructure that implements the Semantic Layer called IoA Central Infrastructure. This infrastructure is responsible as well for receiving, processing and response to all requests from the distributed platforms of agents (IoA Layer) that are part of the IoA ecosystem. To do this, the following 5 basic tasks are carried out: (i) persistence of the IoA-OWL ontology, (ii) generation of IUIDs or unique identifiers for LOAs and their LAC, (iii) storing the supplementary IoA datasets on the IoA-OWL ontology & Dataset Repository, (iv) generation and storing of semantic descriptors in RDF triplets format on the Centralized-Repository of LACs RDF, and finally, (v) executing the semantic reasoning processes on IoA ecosystem. All these tasks were developed using RESTful services in order to facilitate requests from managed agent platforms on the IoA Layer. The implementation of services required by the IoA Central Infrastructure to make operational the above tasks were the following: Java JDK v1.8 to create and execute IoA’s RESTful services, Glassfish server v4.1.1 to deploy the IoA’s RESTful services (https://javaee.github.io/glassfish/), CouchDB v1.6.1 to manage UUIDs and IoA datasets, Virtuoso v7.x to perform semantic reasoning processes (https://www.openlinksw.com/), and Apache Jena v3.0 (https://jena.apache.org/) oriented to process RDF graphs and semantic queries.

On the other hand, at distributed agent platform level (IoA Layer), each platform created is not only in charge of creating the required LOA instances and maintaining the integrity of the agents’ habitat; it must also interact with the Central Infrastructure of IoA when it requires the execution of processes of discovery of counterpart agents. To do this, each agent platform must offer tasks focused on the following aspects: (i) execution of workflow, (ii) semantic enrichment of LOAs, (iii) automatic generation of LACs, (v) automatic LOA generation, (vi) management of agent behaviors, (vii) IoA Central Infrastructure request management, and finally (viii) FIPA-ACL communication using a REST interface. For the implementation of these tasks the following tools were employed: JADE v4.3.2 to handle generic reactive agents, JSON-LD tool v1.0 to process JSON-LD documents, OpenHAB v2.x to communicate with IoT-objects and finally, Java to run generic agents and the IoA-Building Tool.

6.2 Systematic process

In order to provide the main guidelines that a developer must follow to model an IoA ecosystem, a summary of the steps addressed by the systematic process is shown next. The first procedure aims to delimit the control goals of the IoA scenario at infrastructure level. To do this, the next steps were carried out: (I-1) definition of both IoA scenario and IoA networks, (I-2) definition of the general and specific control goals of the IoA scenario, (I-3) selection the IoT-objects and mapping them to LOAs, and (I-4) deployment of the distributed platform IoA for each IoT network to support the creation of LOA entities. On the other hand, the second procedure is carried out at the LOA level. Thus, for each selected IoT-object it is necessary to define the suitable LOAs and their logic of control. To do this, next steps were accomplished: (O-1) modeling the workflow of the LOA, (O-2) semantic enrichment of the LAC, and finally (O-3) creation of the LOA features.

6.3 Modeling the smart community scenario

In the proposed model \(S_{ioa} <SmartCommunity>\) we identified 3 networks of \(IoT=\{iot_{c_1}, iot_{c_2}, iot_{c_3}\}\). From these networks were modeled 3 networks of \(IoA=\{ioa_{c_1}, ioa_{c_2}, ioa_{c_3}\}\), each one to manage the resources of each community. These elements were defined following the step (I-1) of the guidelines previously detailed. Step (I-2) required the definition of the scope and purpose of the modeled system. The overall goal of the system is to provide an intelligent collaborative comfort to the families of the involved communities, taking advantage of the technological resources that each community has deployed. The spectrum of the comfort applied in our case was delimited only on thermal and lighting comfort. After the completion of Step I-3 and based on Fig. 5, a list of IoT-objects was defined. All these IoT-objects were implemented and accessed via the interfaces provided by the OpenHAB framework.

Based on the technical aspects of each of the IoT-objects illustrated in Fig. 5, especially the functionalities supported by each object and its own sensors, the control workflow associated with each object was then created as indicated in step (O-1). Workflow includes the control logic for LOAs can execute control actions on the object. Then, in step (O-2), the semantic enrichment of the LAC of each LOA included in Fig. 5 was performed using the IoA-Building Tool. This tool provides a simple graphic user-interface to input the value of the LAC descriptors. Figure 6 visualizes some of these descriptors used in the case study. The descriptors of LACs are organized by components including a letter (A-L) which corresponds to the specific associated agent (e.g., the collaborative degree of AgentSocial for A is 1, Granada is the locality where all objects are installed).
Fig. 6

Organization of the main descriptors used to semantically enrich the LOAs of the modeled scenario

Then, by means of the IoA-Building Tool, the generation process of the local LAC and the LOA instance were automatically executed with little or no human intervention. Consequently, the step (O-3) was successfully completed. After this, each LOA has its own LAC and workflow and can execute the corresponding control task at an individual or collaborative level, depending on the case. A general outline of the created IoA ecosystem is illustrated in Fig. 7.
Fig. 7

General diagram of the proposed scenario (smart community) modeled as IoA

Figure 7 shows the global ecosystem of IoA for the case study. The modeling scenario required the organization of all loT-objects distributed on 3 IoA networks. All these networks together constituted the global ecosystem of IoA. It is important to note that the system incorporated both non-collaborative LOAs (loa_hvac_c1_f3 and loa_light_c3_f1) and collaborative LOAs (remaining ones). In the first case, the LOAs did not require interaction with other LOAs of the IoA ecosystem. These agents were completely autonomous and executed their goals using only their own IoT resources. However, in the second one (collaborative LOAs), they are responsible for achieving the available counterparts on the IoA ecosystem addressed by a process of discovery and selection of counterparts in order to conform collaborations with other agents according to their goals.

In order to describe more specifically the behavior of each agent of the IoA ecosystem shown in Fig. 6, we have detailed the main activities or tasks executed by each LOA. Since this ecosystem included a set of 13 LOAs distributed over three networks (\(ioa\_net1\), \(ioa\_net2\) y \(ioa\_net3\) ), we grouped the agents according to their degree of collaboration and the nature of IoT-object linked to each agent. Next, a brief description is formulated for every type of agent.
  • Non-collaborative LOAs In this case, the IoA ecosystem included two such agents, \(loa\_hvac\_c1\_f3\) and \(loa\_light\_c3\_f1\). Both non-collaborative LOAs were introduced in the IoA ecosystem in order to contrast the specific behavior of these autonomous LOAs with respect to the collaborative ones.
    • \(loa\_hvac\_c1\_f3\) It is responsible for managing an HVAC object using its own integrated temperature sensor only in the floor 3 of the community 1. The LOA was able to control the turning on and off of the HVAC depending of the ambient and set-point temperatures by means of a specific rule in the WAC. The set-point temperature may be fixed or changed following a programmed rule defined in the WAC.

    • \(loa\_light\_c3\_f1\) In this case, LOA managed an IoT-object with a light-bulb that had integrated a sensor to measure the illumination level in the floor 1 of the community 3. According to the ambient lighting level measured outside the building, the LOA could apply a WAC rule for turning the light on and off respectively.

  • Collaborative LOAs In contrast to non-collaborative LOAs, collaborative LOAs were mostly part of the IoA ecosystem. Next, some of them are described:
    • Light-bulb LOAs The light-bulb LOAs, \(loa\_light\_c2\_f1\), \(loa\_light\_c2\_f3\) and \(loa\_light\_c3\_f3\), were responsible to turn the linked IoT-objects, light-bulbs, on and off on the floors where they were installed. The decision was made automatically based on the illumination level values recovered that this LOA was recovered from other counterpart agents because in this case these bulbs did not integrate any sensor in contrast to \(loa\_light\_c3\_c3\_f1\). The rules to be followed by light-bulb LOAs are described in the associated WAC. In this case, the single LOA, \(loa\_ext_\_illumination\_c3\), was discovered and selected by \(loa\_light\_c2\_f1\) and \(loa\_light\_c2\_f3\) LOAs for requesting the lighting level periodically making the decision if the associated light-bulb should turn on or off. Likewise, \(loa\_light\_c3\_f3\) discovered and selected the \(loa\_illumination\_c3\_f1\),

    • Shutters LOAs In this case, shutters LOAs, \(loa\_shutters\_c2\_f3\) and \(loa\_shutters\_c3\_f1\), had linked as an IoT-object that control the shutters of the floor 3 of the community 2 and the shutters of the floor 1 of the community 3, respectively. Based on the rules described on the WAC, shutters LOA can decide if the shutters should be opening or closing depending on the temperature and illumination levels achieved from other counterpart LOAs. Both shutters LOAs retrieved the illumination levels from the illumination LOA, \(loa\_ext_illumination\_c3\) which provide ambient illumination values external to the building. \(loa\_shutters\_c3\_f1\) also retrieved the inside illumination level from agent \(loa\_illumination\_c3\_f1\). On the other hand, the temperature levels could be achieved from one of the temperature LOAs available in the IoA ecosystem which provides the ambient temperature outside the building. In this case, \(loa\_ext\_temperature\_c2\) was selected instead of \(loa\_ext\_temperature\_c1\).

    • Illumination LOAs These LOAs, \(loa\_ext_illumination\_c3\) and \(loa\_ illumination\_c3\_f1\), had defined a WAC that provided the illumination-level data of the linked illumination IoT-object to other LOAs. In this specific case, this single LOA only returned illumination values of its linked IoT-object to any requests carried out by other LOAs, Light-bulb and Shutters LOAs.

    • Temperature LOAs Temperature LOAs, \(loa\_ext\_temperature\_c1\) and \(loa\_ext\_temperature\_c2\), had an associated WAC with a rule focused only on accurate readings of the ambient temperature values. The agent \(loa\_ext\_temperature\_c1\) obtained the temperature value from the linked temperature object \(ext\_temperature\_c1\). On the other hand, the agent \(loa\_ext\_temperature\_c2\) achieved the temperature value from an external JADE agent. This JADE agent is external to the IoA ecosystem and provided the fused temperature after accessing to the temperature objects \(ext\_tempe\_c2\_1\) and \(ext\_tempe\_c2\_2\).

    • HVAC LOAs These LOAs, \(loa\_hvac\_c1\_f2\) and \(loa\_ext\_central\_hvac\_c2\), are in charge of controlling the HVAC system in the floor 2 of the community 1 and the HVAC of all floors of the community 2. According to the associated WAC, a HVAC LOA can turn HVAC system on and off depending on the ambient and set-point temperatures that had to be recovered from other LOAs after a discovery process. The \(loa\_hvac\_c1\_f2\) found the \(loa\_ext_temperature\_c1\), while \(loa\_ext\_central\_hvac\_c2\) selected the counterparty \(loa\_ext\_temperature\_c2\).

In general, an IoT scenario can be scaled towards an IoA ecosystem with the agent model proposed in this paper. In this case the IoT scenario for the three communities (Fig. 5) composed of a set of individual IoT-objects and an external MAS could be integrated into a global IoA ecosystem (Fig. 7) providing an overall benefit to three communities. In general, these benefits empowered communities to share all their resources as well as the potential collaborations between parties in order to perform tasks proactively. Hence, the system was able to take advantage of the useful IoT resources that were installed in generic IoT networks which were not available or were not easily identified by third party use.

Some of the most relevant benefits are summarized as follows: (i) the IoT-objects installed in a specific community can be used to control nearby communities that they do not have specific IoT-objects (e.g., light-bulbs of the community 2 were switched on and off taking into account the level of external lighting provided by a sensor belonging to community 3), (ii) reuse of existing and operating systems that partially control certain IoT-objects can be reused and extended to other communities that require them (e.g., shutters of the floors in community 3 took advantage of the temperature value provided by the JADE agent running in the community 2 MAS), (iii) protection of specific IoT-objects in order to avoid the access by anyone through non-collaborative LOAs (e.g., the HVAC in the floor 3 of the community 1 and the light bulb in the floor 1 of the community 3 are not visible in any case within the IoA ecosystem) and (iv) an accurate control of IoT-objects is possible to be performed through the use of related magnitudes that contribute to improve their behavior (e.g., shutters were controlled from the illumination level and the temperature of the environment).

6.4 Experimental evaluation

Three IoA platforms, ioa_net1, ioa_net2 and ioa_net3, were implemented to evaluate the case study. These platforms were implemented on different nodes with different computing characteristics. Node 1 corresponds to a 2.5 GHz Intel Core i7 computer, 16 GB RAM and Linux operating system. Node 2 was an Intel Core i7 computer with 3.1 GHz, 16 GB RAM and MAC OS operating system. Likewise, node 3 was implemented on a Core i5 computer with 4 GHz, 16 RAM and Linux operating system. The IoA Building Tool was executed in each of the three nodes. The IoA Central Infrastructure was implemented on node 1. However, this infrastructure could have been implemented anywhere, although it is preferably to deploy on an independent node

6.4.1 Evaluation of the model functionality

We conducted an experiment oriented to realize a qualitative evaluation of a set of criteria in order to analyze the level of functionality, scalability, adaptability, interoperability, usability and reliability of the implemented scenario (smart communities). The acceptance criterion was based on checking the fulfillment of each 22 aspects included in the evaluation questionnaire listed in Table 3. The results obtained showed us that the proposed model is technically feasible to be implementable. A summary of this evaluation is detailed below:
Table 3

Mains aspects evaluated in the implemented IoA system in terms of F = functionality, S = scalability, A = adaptability, I = interoperability, U = usability, r = reliability

Type

Aspect evaluated

Result

F

Do agents achieve their goal (collaborative, non-collaborative)?

Y

F

Do agents execute their tasks (control, discovery, communication)?

Y

F

Do LOAs manage their LAC consistently?

Y

F

Do LOAs manage their workflow consistently?

Y

F

Are LOAs able to request the storage of their LAC in triplet format?

Y

F

Are LOAs able to execute discovery of agent counterparts?

Y

S

Do agent platforms support the incorporation of new LOAs?

Y

S

Do agent platforms support the termination of LOAs?

Y

S

Do agent platforms support the addition new agent technologies?

L

S

Do LOAs support the addition new IoT technologies?

L

A

Are non-collaborative agents capable of becoming collaborative?

Y

A

Are the agents able of adapting to changes in their workflow?

Y

A

Are the agents capable of adapting to changes in their environment?

Y

I

Do LOAs support communication with non-LOA agents that support FIPA-ALC?

N

I

Do LOAs support communication with external agents?

Y

I

Do LOAs support communication with external IoT-objects?

Y

U

What level of difficulty is required to semantically enrich a LAC?

M

U

What level of difficulty is required to create a LAC?

E

U

What level of difficulty is required to create a LOA?

E

U

What level of difficulty is required to create agent platform?

E

R

Are agents able to recover from failures caused by their partners?

Y

R

Are agents able to recover from failures caused by their linked IoT-objects?

Y

Y = yes, N = no, L = limited, difficulty level = {E = easy, M = normal, H = hard}

With regard to functionality (F), the application successfully covered all them. The modeled LOAs in IoA ecosystem worked in a coordinated way to achieve the collaborative and non-collaborative goals proposed by each agent. In addition, the three IoA platforms created to satisfy the functional constraints of the implemented scenario interacted properly each other and services deployed at the IoA Central Infrastructure.

Concerning scalability (S), implemented LOAs did not experience any anomalous behavior. IoA’s platforms allowed the addition of new LOAs at runtime and the termination of these if required. The fact that a counterpart changes its availability status did not imply a fatal error for any LOA.

In terms of adaptation (A) of the system, LOAs were not only adapted to use the data provided by new agents, but also to self-adapt when their counterparts have a lack of sufficient data for supporting them. From this premise, it is evident that LOAs entities are operationally reliable (R) since they could recover from changes of their previously formed social circle and IoT-objects managed by themselves.

Regarding interoperability (I), the modeled LOAs were able to communicate with IoT-objects and generic JADE agents that adopted the FIPA standard through REST interfaces. There was no control over IoT-objects that do not have a REST communication interface, nor with external agents that adopt a different communication model than FIPA ACL.

Finally, in terms of usability (U) of the application, IoA-Building Tool is quite simple to use as it is preventing the user from having to perform complex technical tasks. However, to improve the semantic enrichment time in which the user participates, it is possible to improve the interface to include more user-friendly graphical components.

In summary, the implemented application achieved satisfactorily the proposed functional requirements while maintaining an acceptable level of reliability; as well as the adaptation and recovery from possible failure of counterpart agents at runtime. Each of the agents that were part of the IoA ecosystem behaved in accordance with the outline of IoA illustrated in Fig. 7. The aspects evaluated over the smart communities system demonstrate us the technical feasibility of the theoretical model of IoA ecosystem proposed in this paper with the current tools of agents, web and semantic technologies.

6.4.2 Evaluation of the LOA performance

Based on the characteristics of the computers explained above, an evaluation of the performance was carried out. Due to differences in computing capabilities, we performed all tests on a single machine, node 1, in order to achieve more consistent results of the LOA execution.

The first quantitative experimentation focused on measuring the total time (\(T_{LOAtotal}\)) required to process a LOA and its elements. This was determined for collaborative LOAs applying the following equation:
$$\begin{aligned} T_{LOAtotal} = T_{LACgeneration} + T_{TRIPLETSgeneration} + T_{LOAgeneration} \end{aligned}$$
(8)
where \(T_{LACgeneration}\) corresponds to the time required for the generation of the local LAC, \(T_{TRIPLETSgeneration}\) is the time required for the creation of the triplets and their corresponding publication in the global IoA ecosystem, and finally, \(T_{LOAgeneration}\) is the time required to generate the LOA entity and its corresponding inclusion on the IoA platform. For the case of non-collaborative LOAs the time is calculated similarly and is done with the same equation (8), but discarding \(T_{TRIPLETSgeneration}\) because they do not perform reasoning processes.

In order to show the time required to generate and implement a LOA and its elements, an instance of the modeled scenario was selected. The selected entity was called loa_light_c2_f1 and shown in Fig. 7. The interface provided by the IoA-Building Tool was used to carry out the semantic enrichment process of the LOA loa_light_c2_f1 entity, which was made up of 58 descriptors. Next, the times \(T_{LACgeneration}\), \(T_{TRIPLETSgeneration}\) and \(T_{LOAgeneration}\) were measured and from these results, \(T_{LOAtotal}\) required to generate light_c2_f1was calculated. In order to obtain more realistic times, this experiment was executed during 100 iterations for the calculation of the mean. Consequently, in each iteration a new LOA is added to the agent execution environment of the node 1 until we have 100 LOAs. Furthermore, the first iteration was discarded, since Java requires initially more time to load the Java virtual machine and the memory required by the application.

In addition to the experiment described above, an experiment based on a LOA equivalent of light_c2_c2_f1 agent was also designed. This new instance integrated twice as many descriptors (58*2) in order to analyze the time requirements concerning the number of descriptors of a LOA. The results of both experiments obtained for \(T_{LACgeneration}\), \(T_{TRIPLETSgeneration}\) and \(T_{LOAgeneration}\), are shown respectively in Fig. 8a–c. It also details the time \(T_{LOAtotal}\) required to create the two modeled LOAs instances.
Fig. 8

Times required for processing a Linked Agent Contracts, b triplets, c Linked Open Agents (LOAs) and d a complete LOA entity

The results of Fig. 8a, c show, on the one hand, that the time required for the creation of both the LAC and LOA is not dependent on the quantity of descriptors integrated by loa_light_c2_f1. Indeed, we obtained not significant fluctuations around the mean time without any remarkable trend. The mean time required for LAC generation and storage was 11.81 ms for the LOA with 58 descriptors and 10.05 ms for the LOA with 116 descriptors, respectively, with a 5 percent difference. Regarding the time required to generate the agent and add it to its corresponding IoA platform, the obtained mean time was 18.04 ms and 16.69 ms for the LOA entity with 58 and 116 descriptors, respectively, with a similar behavior in the time of each iteration with only a difference of 1% in this case.

The time required to generate the RDF triplets of a LAC, shown in Fig. 8b, seems to indicate a direct proportional dependence of \(T_{LOAgeneration}\) on the quantity of specified descriptors. For the case of 58 descriptors, the mean time required was 505.48 ms; while to generate the triplets of the LAC of 116 descriptors was 748.57 ms, with a difference of 32%. Obviously, this difference also affected on the total time required to create the complete LOA (agent, contract and triplets). We obtained a mean time of 599.57 ms when the LOA instance was composed of 58 descriptors and 841.45 ms for the case of 116 descriptors. The small variations observed on the LOA creation time among iterations (especially with respect to \(T_{TRIPLETSgeneration}\) ) reveals that scalability is maintained when new LOAs are added. Increasing LAC descriptors could have some impact in the creation of LOAs (for the creation of triplets in central repository) and the subsequent reasoning process with triplets in the agent discovery, but it is limited since the difference in times is not too high.

6.4.3 Evaluation of the performance and accuracy of the agent discovery task

Collaborative LOAs must execute regularly the agent discovery task in order to find possible collaborating agents as part of their scheduling. This task performs a matching process based on descriptors with the aim of recovering counterparts that help in the fulfillment of the LOAs’ goals. The matching process included in the discovery task is generally based on the syntax of the descriptors (data provided), such as the JADE [8] Yellow Pages and the UDDI service catalogues used in SOA [28]. However, this matching process can also be performed based on the semantics of the descriptors as in the case of this proposal.

For experimental purposes, three scenarios were prepared, consisting of 13 (Fig. 7 scenario), 100 and 10,000 agents, in which the process of discovery of counterparts based on descriptors was carried out. These three scenarios correspond to (i) the Yellow Pages used by JADE to register the services associated with agents, (ii) the catalog of jUDDI web services that an agent can access to retrieve services that can assist the execution of its tasks (an agent and service analogy was suggested to carry out the discovery process), and (iii) the repository of LACs stored in RDF triplets format. The matching process associated with the agent discovery task was applied to the three specified technologies, and to be equitable, two basic descriptors were registered, such as: the name and type of data provided by the agents or services, as appropriate. In the case of JADE, the agents were centralized in one platform and each agent registered the data provided under the use of services in their yellow pages. In the case of jUDDI, it was not agents but web services that were registered. Thus, the agent who executed the search process had the mission of discovering services instead of agents. These services were grouped into 3 different business models. Finally, in the case of LACs represented in triplet format, they were stored in an RDF network managed by the Virtuoso server.

Similarly to the previous experimentation process, the agent discovery process applied to the three previously specified technologies was executed during 100 iterations and matching based on 1 descriptor (data provided). The results obtained for the selected agent loa_shutter_c2_f3, without considering the first iteration for the reasons previously described, are shown in Fig. 9a (JADE), b (jUDDI), c (LACs repository). Firstly, regarding the discovery with JADE Yellow Pages (Fig. 9a), there was an increase in time depending on the number of agents included in the platform. In the case of the ecosystem formed by 13 agents, the mean time required to complete the discovery process was 12.13 ms considering an ecosystem with 13 agents, 19.46 ms with 100 agents, and 25.64 ms with 1000 agents, respectively. Although the mean time was increasing with the number of agents recovered by the discovery process, the mean time per agent was much lower; then, the scalability is guaranteed with JADE technology. Furthermore, Fig. 9a shows also that the time to discover agents was decreasing when the number of iteration was increasing.
Fig. 9

Times required for processing the discovery process on a JADE’s yellow pages, b jUDDI, c LACs repository and d comparison between methods

Secondly, the discovery executed on jUDDI (Fig. 9b) exposed much higher mean time requirements than the previous mechanism, i.e. 633.05 ms for the 13-agent ecosystem, 995.85 ms for the 100-agent ecosystem, and 25,777.76 ms for the 1000-agent ecosystem. In this case, the mean time was increasing accordingly to the number of agents recovered.

Thirdly, an equivalent discovery process was executed on the repository of LACs stored in triplets format. The results (Fig. 9c) also show a dependence on the number of agents in the IoA ecosystem. However, these times are relatively less. For example, in the case of the ecosystem formed by 13 agents, 5.73 ms were required, which is equivalent to an increase of 3.20% and 81.84% with respect to the same scenario consisting of 100 and 1000 agents. Despite this increase, as shown in Fig. 9, the process is more efficient when compared to the two previous methods; i.e. an increase of 71.01% over the JADE Yellow Pages and 99.87% over the ecosystem of 1000 agent instances.

Results obtained previously showed a better performance of the proposed discovery mechanism with respect to JADE Yellow Pages and jUDDI service catalogue. In order to demonstrate that the benefits of the proposal lie not only in performance, but also in the precision of the recovered partners, a third experiment was designed. This experiment consisted of evaluating the proposed discovery algorithm using a variable set of both semantic descriptors and descriptor-values on the same ecosystem of IoA employed in the previous experiment with 100 LOAs. From these tests on, we evaluate Algorithm 1 in terms of the precision and accuracy of the recovered agents in IoA.

The IoA ecosystem studied included the 13 LOAs illustrated in Fig. 5 and 87 additional LOAs that were strategically generated in order to introduce both false positive (\(F^+\)) and true positive (\(T^+\)) agents that could hinder the process of discovery of agents. A \(F^+\) is an agent recovered but not fully satisfied the request and a \(T^+\) is an agent recovered that fully satisfies the request.

In Table 4 the values of the precision (P) and the accuracy (ACC) obtained by executing the reasoning process on the JADE Yellow Pages, jUDDI and the IoA Central Infrastructure using 1, 2 and 6 descriptors are shown. P in this context is the fraction of retrieved agents that are relevant to the reasoning task and ACC is the degree to which the result of a discovery conforms to the correct values. For calculating the value of P and ACC, next equations were used, respectively: \(P = T'^+ / (T'^+ + F'^+)\) and \(ACC = (\Sigma T'^+ + \Sigma T'^- ) / (Total Population)\).
Table 4

Precision and accuracy of the discovery process

Mechanism

D

V

S

C

\(F^{+}\)

\(F'^{+}\)

\(T^{+}\)

\(T'^{+}\)

P

\(T^{-}\)

ACC

JADE

1

2

Y

100

6

6

20

14

14/20 \(\simeq \) 0.70

60

0.74

jUDDI

1

2

Y

100

6

6

20

14

14/20 \(\simeq \) 0.70

60

0.74

IoA

1

2

Y

100

6

5

20

15

15/20 \(\simeq \) 0.75

60

0.75

JADE

2

4

N

*

*

*

*

*

*

*

*

jUDDI

2

4

N

*

*

*

*

*

*

*

*

IoA

2

4

Y

100

6

3

20

15

15/17 \(\simeq \) 0.88

63

0.77

JADE

6

9

N

*

*

*

*

*

*

*

*

jUDDI

6

9

N

*

*

*

*

*

*

*

*

IoA

6

9

Y

100

6

1

20

15

15/16 \(\simeq \) 0.94

63

0.79

D = descriptors; V = values; S = descriptor support; C = agents deployed within the IoA ecosystem; \(F^{+}\) = false positives introduced; \(F'^{+}\) = false positives recovered; \(T^{+}\) = true positives introduced; \(T'^{+}\) = true positives recovered; P = precision; \(T^{-}\) = true negatives; ACC = accuracy

*Mechanism couldn’t handle descriptors used in the experiment

The results detailed in Table 4 show an increase in the accuracy and precision of the data recovered by the discovery algorithm, executed in this specific case by the agent loa_shutter_shutter_c2_f3 over JADE, jUDDI and IoA. In the explanation of the tests performed, we refer to loa_shutter_c2_f3 as the studied agent.

In the first case, the discovery mechanism used a single descriptor (magnitude of interest) and two descriptor-values (temperature and illumination). These values allowed the discovery algorithm for JADE and jUDDI to recover a total of 14 true positive agents (\(T^+\)) and 6 false positive agents (\(F^+\)). Hence, the data recovered was obtained with an accuracy of 70% and 74%, respectively. It is important to note that 6 false positive agents were recovered. These agents provided the magnitudes required by the studied agent but were in a different context than that requested by the agent. In addition, 14 of the 20 existing true positive agents were recovered. On the other hand, in the case of the discovery process applied over IoA, the semantic knowledge had incorporated a rule of equality (sameAs) between illumination and light values, and based on it the agent that had described the proportional magnitude using light was recovered. This could not be done by the discovery mechanisms of the two other technologies. With these new restrictions, the false positive agents \(F^+\) were reduced by 1 from 6 to 5. This allowed to reach a level of precision and accuracy in the discovery of agents of 75% for both cases. This was equivalent to a 5% improvement in accuracy and 1% improvement in accuracy over the discovery applied to JADE and jUDDI.

In the second case, the executed discovery mechanism added a new descriptor (context of localization insideOf) together with 2 additional values (community_c1, community_c2 and the previous two). With these new descriptors, the number of false positive agents \(F^+\) was reduced from 6 to 3. Consequently, an accuracy level of 83% and an accuracy of 77% was achieved. This represented an increase of 13% and 2% in both measures. It is important to note that 2 more false positive agents \(F^+\) were recovered. The remaining 3 false positive agents \(F^+\) were found inside the houses and corresponded to the required context.

Finally, in the latter case, the discovery algorithm was able to discriminate between two additional agents because two new descriptors were specified. These descriptors were the maximum execution time required by the agent to execute the requested task and the bandwidth of the object was 54 Mbit/s or 11 Mbit/s. Therefore, the accuracy of the algorithm with respect to the recovered agents was 94%. This corresponds to an increase of 18% and 5% over the use of 1 and 2 descriptors respectively. Also, the accuracy trend shows an increase of 79%.

The above analysis allows us to assert that the proposed discovery model increases its level of precision as additional descriptors are included. This is basically due to the fact that, as in cases 2 and 3, the algorithm discriminates agents that do not comply with the restrictions that the agent requires to carry out control tasks on the IoT ecosystem. On the other hand, although the number of descriptors used to perform a discovery process may be a condition for true positive agents \(T^+\) to be discriminated against, as shown in case 1, a semantic reasoning allows the number of true negative agents \(T^-\) to be reduced and the probability of discovering true positive agents \(T^+\) to be increased. However, the semantic model is required to include the appropriate rules (e.g., equality, transitive, inverse) in order for the reasoning engine to operate more coherently.

7 Conclusions and further works

7.1 Conclusions

This paper has established the main conceptual bases and aspects related to the Internet of Agents (IoA) approach. In order to provide a high level of interoperability within the Internet of Things, by integrating software agents, we have proposed a novel mechanism based, on the one hand, on using Linked Open Agent (LOA) as the unit process for the IoA and, on the other hand, the employment of Linked Agent Contracts (LACs) to describe LOAs semantically and publish them as Linked Open Data (LOD). We suggest these mechanisms in order to improve the level of semantic interoperability in the agent domain and, consequently, in IoT networks which are governed by agents. The use of open data to describe agent components breaks the boundaries of agent and IoT platforms because users, developers and other agents can reuse semantic descriptors belonging to already defined components. In addition, the discovery process of agents and services can be performed at a global level, and not only in a specific agent-platform as is commonly done.

Currently, data are trending towards open data, and Web technologies related to agents and IoT are addressed towards the Web Semantic. Therefore, in the IoA approach new models, methods, and mechanisms are necessary to support the new emerging technological advances of information systems. In order to contribute to the integration process of agents and IoT, we propose a novel model useful for increasing the semantic interoperability and intelligence in smart-IoT-objects and networks, at different levels:
  • At the semantic-architectural level, we have proposed a novel semantic architectural model driven by dynamic contracts for describing specialized agents that have enough information to operate at both IoT levels, intra-platform and inter-platform (Fig. 3). Furthermore, the proposed model is oriented towards devices because we propose an agent model for devices by contributing to improving the concept Agent of Thing proposed by Mzahm [67] in terms of a formal semantic description. Moreover, the model is also compatible with the Internet of Service (IoS) approach, which gives the added bonus of interoperability because agents and IoT-objects can reuse microservices belonging to heterogeneous ecosystems of services.

  • At the semantic-description agent level we have redefined the contract concept LACs (Listing 1) in the agent domain in order to describe and publish information as open data at a global level. In this way, it is possible to normalize the concepts employed by developers of IoA applications and to achieve a high level of semantic interoperability. In addition, the language employed to describe contracts is readable by both humans and machines, which allows users to define their agent contracts based on the current and future requirements presented in IoA ecosystems. In the case of machines the computational performance required to create LACs is low as Fig. 8a shows.

  • At the semantic-formal vocabulary level, our proposal contributes to providing a compact model for describing semantically rich entities such as LOAs by using ontologies and open data. The development of the IoA-OWL ontology (Fig. 1) is an important contribution because the majority of the agents and IoT semantic models only cover a very specific issue, and many of them are not available for use or reuse. Therefore, in order to continue with the standardization steps in the agent semantic domain and to begin normalization in the IoA paradigm, we have developed an extensible ontology for describing LOAs. The semantic descriptors were introduced by employing six ontological components: AgentProfile, AgentContext, AgentSocial, AgentService, AgentModel and AgentSmartThing. In this way, the agents are capable of knowing information about real-time restrictions, context, social circles, IoT resources, agent components and non-functional issues which can be employed by reasoners in order to take autonomous decisions at the global level more accurately than current mechanism as Fig. 9-d shows. However, the semantic model can be extended to include other components according to the new issues required to be modeled in IoA (e.g., normative).

  • At implementation level, the proposed model demonstrated its efficiency in carrying out semantic discovery processes of counterpart agents with a level of precision more accurately than current discovery mechanisms such as the JADE yellow pages and the web services catalog used in SOA as shown in Fig. 7d. In addition, regarding the functionality of the LOAs, they are able to identify the best counterpart agents according to a selection operator that adapts to the needs and constraints of the modeled system. Thus, they are able to achieve their goals individually or in a collaborative way. In addition, thanks to the use of workflow, that can control IoT-objects by means of web service invocations and can expose the need to have support of the recovered counterpart agents, a LOA is easily adaptable at runtime automatically. The easy creation of LOAs and their workflows is a simple task for the user and therefore constitutes an alternative to cover the challenge that Yu et al. [93] specified with regard to the inclusion of mechanisms for the creation and adaptation of agents at the level of non-specialist users in the agent domain.

As we have previously asserted, our proposed model is basically oriented towards improving semantic interoperability in the IoA domain. However, the model that we present has some limitations which can be summarized in terms of the following concerns:
  • The model requires the use of a service layer to execute tasks required by both IoT-objects and agents in general. Nonetheless, this limitation could become a strength because SOA and web services is a current trend that is increasingly being employed in the development of Web, mobile and ubiquitous applications. Additionally, it can ease the development of workflows to control IoT-objects that agents can employ to model their behavior because WSs are software artifacts with loosely coupled properties that encapsulate part of the systems complexity.

  • There is a dependence of the model on JADE framework because the AgentModel component integrated in the IoA-OWL ontology includes specific vocabulary to describe behaviors such as is supported by JADE. However, to add compatibility with other existing frameworks, it is possible to extend the AgentModel ontology to support new vocabulary that allows the description of new components adopted by the specific agent implementation framework.

  • Semantic components such as ontologies and datasets employed to describe entities in the IoA domain can be published in distributed environments, but clients must access in a concurrent way and therefore this can present concerns when many clients need to data access at the same time. However, the REST interface of web services can reduce its impact, because the idempotence property guarantees that multiple requests can be managed at the same time without changing or otherwise affecting the data provided by the web services.

  • Agents adopting the proposed model can be executed on distributed agent platforms. In these platforms each agent also stores its respective LAC and WAC. However, the semantic reasoning process requested by the agents from these distributed platforms is carried out on a centralized infrastructure (IoA-Central Infrastructure). The RDF triplets (replica of distributed LACs) are also stored in this infrastructure. This means that if IoA-Central Infrastructure is not available, the agents who need to complete their WAC cannot do until the infrastructure is available again. However, this limitation can be overcome by creating replicas of the IoA-Central Infrastructure or by creating a federation mechanism for this type of infrastructure.

  • The proposed model is oriented towards developing small and large IoA applications. However, it is possible that modeling a basic application can be a limitation because the model requires efforts to describe every component managed by agents that compose the IoA application, such as non-functional properties, context, service ecosystem, agent artifacts, social circles and IoT resources handled by objects connected to IoT networks. However, the time required for agent development is relatively minimal due to the fact that the creation process is fully automatic.

7.2 Future works

Regarding future work, we are developing a structured method which takes into account the concepts and mechanisms introduced in this work in order to provide the guidelines that developers of IoA applications must follow to build smart IoT networks based on agents by adopting the Linked Open Data approach. Related to this future work, another additional required study is the development of a CASE tool that allows us to model IoA applications based on the concepts introduced in the proposed model and which is addressed by the method also proposed.

On the other hand, in order to add compatibility with additional existing agent frameworks, as a future study, the ontological model IoA-OWL can be extended to support vocabulary employed by new frameworks and languages such as Jack, Jason, AgentBuilder, among others, if required. Finally, another significant contribution in the IoA domain and specifically in this proposal is the inclusion of agents-IFTTT with supporting of different levels of intelligence that can be personalized by users in order that IoA applications can adapt their behavior based on the new requirements of end-users in a personalized way, and not in a general way as currently occurs.

Notes

Acknowledgements

This study was funded by the Ecuadorian Ministry of Higher Education, Science, Technology and Innovation (SENESCYT) through the Program of Ph.D. for university professors. In addition, the authors thank the Center for Research in Information and Communication Technologies of the University of Granada (CITIC-UGR). Finally, the authors would also like to thank the referee for a careful reading of the paper and some valuable suggestions.

References

  1. 1.
    Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., & Ayyash, M. (2015). Internet of things: A survey on enabling technologies, protocols, and applications. IEEE Communications Surveys and Tutorials, 17(4), 2347–2376.CrossRefGoogle Scholar
  2. 2.
    Al-Sakran, H. O. (2015). Intelligent traffic information system based on integration of internet of things and agent technology. International Journal of Advanced Computer Science and Applications (IJACSA), 6(2), 37–43.Google Scholar
  3. 3.
    Alegre, U., Augusto, J. C., & Clark, T. (2016). Engineering context-aware systems and applications: A survey. Journal of Systems and Software, 117, 55–83.CrossRefGoogle Scholar
  4. 4.
    Andrade, F., Novais, P., Machado, J., & Neves, J. (2007). Intelligent contracting: Software agents, corporate bodies and virtual organizations. In L. M. Camarinha-Matos, H. Afsarmanesh, P. Novais, & C. Analide (Eds.), Establishing the foundation of collaborative networks. PRO-VE 2007. IFIPThe International Federation for Information Processing (pp. 217–224). New York: Springer.Google Scholar
  5. 5.
    Atzori, L., Iera, A., & Morabito, G. (2010). The Internet of Things: A survey. Computer Networks, 54(15), 2787–2805.CrossRefzbMATHGoogle Scholar
  6. 6.
    Atzori, L., Iera, A., & Morabito, G. (2011). SIoT: Giving a social structure to the internet of things. IEEE Communication Letters, 15(11), 1193–1195.CrossRefGoogle Scholar
  7. 7.
    Ayala, I., Amor, M., & Fuentes, L. (2015). The Sol agent platform: Enabling group communication and interoperability of self-configuring agents in the Internet of Things. Journal of Ambient Intelligence and Smart Environments, 7, 243–269.Google Scholar
  8. 8.
    Bellifemine, F., Caire, G., Poggi, A., & Rimassa, G. (2008). JADE: A software framework for developing multi-agent applications. Lessons learned. Information and Software Technology, 50, 10–21.CrossRefGoogle Scholar
  9. 9.
    Bergenti, F., Iotti, E., & Poggi, A. (2015). Outline of a formalization of JADE multi-agent systems. Intelligenza Artificiale, 9(2), 149–161.  https://doi.org/10.3233/IA-150085.CrossRefGoogle Scholar
  10. 10.
    Bhaskaran, N., Shekhar, J., & Wilfred, G. (2013). Mobile Agent Frame (MAF) based Internet of Things (IoT) system for allowing diverse heterogeneous devices to coexist, has MAF that is running on every device that can host static and mobile agents and receive mobile programs and messages. Patent IN201200674-I2.Google Scholar
  11. 11.
    Bizer, C., Heath, T., & Berners-Lee, T. (2009). Linked data: The story so far. International Journal on Semantic Web and Information Systems, 5(3), 1–22.  https://doi.org/10.4018/jswis.2009081901.CrossRefGoogle Scholar
  12. 12.
    Bosse, S. (2016). Mobile Multi-agent systems for the Internet-of-Things and clouds using the JavaScript agent machine platform and machine learning as a service. In 2016 IEEE 4th international conference on future internet of things and cloud (FiCloud) (pp. 244–253).Google Scholar
  13. 13.
    Borgia, E. (2014). The Internet of Things vision: Key features, applications and open issues. Computer Communications, 54, 1–31.CrossRefGoogle Scholar
  14. 14.
    Braubach, L., Pokahr, A., & Lamersdorf, W. (2004). Jadex: A short overview. https://vsis-www.informatik.uni-hamburg.de/getDoc.php/publications/212/jadex_node.pdf. Accessed November 14, 2016.
  15. 15.
    Brazier, F., Oskamp, A., Schellekens, M., & Wijngaards, N. (2003). Can agents close contracts? https://pdfs.semanticscholar.org/bcf0/da4a0eabb55c8d5a4f865df6740d56ab0a19.pdf. Accessed December 14, 2016.
  16. 16.
    Brickley, D., & Miller, L. (2014). FOAF vocabulary specification 0.99. http://xmlns.com/foaf/spec/. Accessed December 14, 2016.
  17. 17.
    Cabri, G., Domnori, E., & Orlandini, D. (2011). Implementing agent interoperability between language-heterogeneous platforms. In 20th IEEE international workshops on enabling technologies (pp. 29–34). Infrastructure for Collaborative Enterprises (WETICE).Google Scholar
  18. 18.
    Carlier, F., & Renault, V. (2016). IoT-a, Embedded agents for smart internet of things. Application on a display wall. In IEEE/WIC/ACM international conference on Web Intelligence Workshops (WIW) (pp. 80–83).Google Scholar
  19. 19.
    Chelmis, C., & Prasanna, V. K. (2011). Social networking analysis: A state of the art and the effect of semantics. In IEEE third international conference on social computing (SocialCom) (pp. 531–536).Google Scholar
  20. 20.
    Chen, H. (2004). Context broker architecture: An intelligent broker for context-aware systems in smart spaces. http://daml.umbc.edu/ontologies/cobra/0.4/location. Accessed December 14, 2016.
  21. 21.
    Chenand, H., Finin, T., & Joshi, A. (2005). The SOUPA ontology for pervasive computing. In V. Tamma, S. Cranefield, T. W. Finin, & S. Willmott (Eds.), Ontologies for agents: Theory and experiences. Whitestein series in software agent technologies (pp. 233–258). Basel: Birkhäuser.Google Scholar
  22. 22.
    CoDAMoS Project. (2003). Context-driven adaptation of mobile services. https://distrinet.cs.kuleuven.be/projects/CoDAMoS/ontology/context.owl. Accessed December 14, 2016.
  23. 23.
    Cox, S., & Little, C. (2016). Time ontology in OWL. https://www.w3.org/2016/time. Accessed December 14, 2016.
  24. 24.
    Cucurull, J., Martı, R., Navarro-Arribas, G., Robles, S., & Borrell, J. (2009). Full mobile agent interoperability in an IEEE-FIPA context. Journal of Systems and Software, 82(12), 1927–1940.CrossRefGoogle Scholar
  25. 25.
    Dublin-Core-Metadata-Inititative. (2012). DCMI metadata terms. http://dublincore.org/documents/dcmi-terms/. Accessed December 14, 2016.
  26. 26.
    Elkhodr, M., Shahrestani, S., & Cheung, H. (2013). A contextual-adaptive location disclosure agent for general devices in the internet of things. In 2013 IEEE 38th conference on local computer networks workshops (pp. 848–855).Google Scholar
  27. 27.
    Ereteo, G., Gandon, F., & Buffa, M. (2008). INRIA’s IRC ontology as RDF vocabulary. http://ns.inria.fr/semsna/2008/10/13/voc.html. Accessed December 14, 2016.
  28. 28.
    Erl, T. (2008). SOA principles of service design. New York: Prentice Hall.Google Scholar
  29. 29.
    Erl, T., Karmarkar, A., Walmsley, P., Haas, H., Yalcinalp, L. U., Liu, K., et al. (2009). Web service contract design and versioning for SOA. New York: Prentice Hall.Google Scholar
  30. 30.
    Fortino, G. (2016). Agents meet the IoT: Toward ecosystems of networked smart objects. IEEE Systems, Man, and Cybernetics Magazine, 2(2), 43–47.CrossRefGoogle Scholar
  31. 31.
    Fortino, G., Guerrieri, A., & Russo, W. (2012). Agent-oriented smart objects development. In Proceedings of the 2012 IEEE 16th international conference on computer supported cooperative work in design (CSCWD) (pp. 907–912).Google Scholar
  32. 32.
    Garcia, E., Giret, A., & Botti, V. (2011). Regulated open multi-agent systems based on Contracts. In J. Pokorny, V. Repa, K. Richta, W. Wojtkowski, H. Linger, C. Barry, et al. (Eds.), Information systems development (pp. 243–255). New York: Springer.CrossRefGoogle Scholar
  33. 33.
    Gazis, V., Goertz, M., Huber, M., Leonardi, A., Mathioudakis, K., Wiesmaier, A., et al. (2015). Short paper: IoT: Challenges, projects, architectures. In 18th international conference on intelligence in next generation networks (pp. 145–147).Google Scholar
  34. 34.
    Gazis, V., Görtz, M., Huber, M., Leonardi, A., Mathioudakis, K., Wiesmaier, A., et al. (2015). A survey of technologies for the internet of things. In International wireless communications and mobile computing conference (IWCMC) (pp. 1090–1095).Google Scholar
  35. 35.
    Gil, D., Ferrández, A., Mora-Mora, H., & Peral, J. (2016). Internet of Things: A review of surveys based on context aware intelligent services. Sensors, 16(7), 1069.  https://doi.org/10.3390/s16071069.CrossRefGoogle Scholar
  36. 36.
    Godfrey, W. W., Jha, S. S., & Nair, S. B. (2013). On a mobile agent framework for an internet of things. In 2013 international conference on communication systems and network technologies (CSNT) (pp. 345–350).Google Scholar
  37. 37.
    Grimstrup, A., Gray, R., Kotz, D., Breedy, M., Carvalho, M., Cowin, T., et al. (2002). Toward interoperability of mobile-agent systems. In N. Suri (Ed.), Mobile agents. MA 2002. Lecture notes in computer science (Vol. 2535, pp. 106–120). Berlin, Heidelberg: Springer.Google Scholar
  38. 38.
    Grosof, B. N., & Poon, T. C. (2004). SweetDeal: Representing agent contracts with exceptions using XML rules, ontologies, and process descriptions. International Journal of Electronic Commerce, 8(4), 340–349.  https://doi.org/10.1080/10864415.2004.11044305.CrossRefGoogle Scholar
  39. 39.
    Gyrard, A., Tarek, E., Agarwal, R., Gomez, D, & Sánchez, L. (2016). The machine-to-machine measurement (M3) lite ontology (m3lite). http://lov.okfn.org/dataset/lov/vocabs/m3lite. Accessed December 14, 2016.
  40. 40.
    Hachem, S., Teixeira, T., & Issarny, V. (2011). Ontologies for the internet of things. In Proceedings of the 8th middleware doctoral symposium (pp. 1–6).  https://doi.org/10.1145/2093190.2093193.
  41. 41.
    Heath, T., & Bizer, C. (2011). Linked data: Evolving the web into a global data space (1st ed.). San Rafael: Morgan & Claypool.Google Scholar
  42. 42.
    Iannella, R., & McKinney, J. (2014). vCard ontology: For describing people and organizations. https://www.w3.org/TR/vcard-rdf/. Accessed December 14, 2016.
  43. 43.
    Issarny, V., Georgantas, N., Hachem, S., Zarras, A., Vassiliadist, P., Autili, M., et al. (2011). Service-oriented middleware for the Future Internet: State of the art and research directions. Journal of Internet Services and Applications, 2(1), 23–45.CrossRefGoogle Scholar
  44. 44.
    Jarvenpaa, L., Lintinen, M., Mattila, A.-L., Mikkonen, T., Systa, K., & Voutilainen, J.-P. (2013). Mobile agents for the internet of things System Theory. In 2013 17th international conference on control and computing (ICSTCC) (pp. 763–767).Google Scholar
  45. 45.
    Kaminski, N. J., Murphy, M., & Marchetti, N. (2016). Agent-based modeling of an IoT network. In 2016 IEEE international symposium on systems engineering (ISSE) (pp. 1–7).Google Scholar
  46. 46.
    Kato, T., Takahashi, H., & Kinoshita, T. (2017). Multiagent-based autonomic and resilient service provisioning architecture for the Internet of Things. International Journal of Computer Science and Network Security, 17(6), 36–58.Google Scholar
  47. 47.
    Katsaros, D., Dimokas, N., & Tassiulas, L. (2010). Social network analysis concepts in the design of wireless ad hoc network protocols. IEEE Network, 24(6), 23–29.CrossRefGoogle Scholar
  48. 48.
    Khan, R., Khan, S. U., Zaheer, R., & Khan, S. (2012). Future internet: The internet of things architecture, proof possible applications and key challenges. In 10th international conference on frontiers of information technology (pp. 257–260).  https://doi.org/10.1109/FIT.2012.53.
  49. 49.
    Knol, M., van Voorst, K., Telgen, D., van der Paauw, R., van den Berg, M., Puik, E., et al. (2016). Internet of smart things, a study on embedding agents and information as a service. ICAART Proceedings, 1, 102–109.Google Scholar
  50. 50.
    Korn, N., & Oppenheim, C. (2011). Licensing open data: A practical guide, higher education funding council for England. http://discovery.ac.uk/files/pdf/Licensing_Open_Data_A_Practical_Guide.pdf. Accessed February 21, 2017.
  51. 51.
    Kravari, K., & Bassiliades, N. (2015). A survey of agent platforms. Journal of Artificial Societies and Social Simulation.  https://doi.org/10.18564/jasss.2661.
  52. 52.
    Laclavik, M., Balogh, Z., Babik, M., & Hluchy, L. (2006). AgentOWL: Semantic knowledge model and agent architecture. Computing and Informatics, 25(5), 421–439.zbMATHGoogle Scholar
  53. 53.
    Laufer, C., & Schwabe, D. (2007). Semantic contract support for E-business processes. In Web congress, Latin American (pp. 67–75). http://doi.ieeecomputersociety.org/10.1109/.
  54. 54.
    Lee, J., Lee, S.-J., & Wang, P.-F. (2015). A framework for composing SOAP, non-SOAP and non-web services. IEEE Transactions on Services Computing, 8(2), 240–250.CrossRefGoogle Scholar
  55. 55.
    Leong, P., & Lu, L. (2014). Multiagent web for the Internet of Things. In 2014 international conference on information science and applications (ICISA) (pp. 1–4).Google Scholar
  56. 56.
    Leppänen, T., Riekki, J., Liu, M., Harjula, E., & Ojala, T. (2014). Mobile agents-based smart objects for the internet of things. In G. Fortino & P. Trunfio (Eds.), Internet of things based on smart objects. Internet of things (technology, communications and computing) (pp. 29–48). Cham: Springer.Google Scholar
  57. 57.
    Li, S., Da Xu, L., & Zhao, S. (2015). The Internet of Things: A survey. Information Systems Frontiers, 17, 243–259.CrossRefGoogle Scholar
  58. 58.
    Lin, C.-H., Ho, P.-H., & Lin, H.-C. (2014). Framework for NFC-based intelligent agents: a context-awareness enabler for social internet of things. International Journal of Distributed Sensor Networks, 10, 978951.CrossRefGoogle Scholar
  59. 59.
    Liu, C.-H., & Chen, J.-Y. (2012). Using ontology-based BDI agent to dynamically customize workflow and bind semantic web service. Journal of Software, 7(4), 884–894.Google Scholar
  60. 60.
    Manate, B., Fortis, T.-F., & Negru, V. (2014) Infrastructure management support in a multi-agent architecture for Internet of Things. In 2014 European modelling symposium (EMS) (pp. 372–377).Google Scholar
  61. 61.
    Martin, D., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., et al. (2004). OWL-S: Semantic markup for web services. https://www.w3.org/Submission/OWL-S/. Accessed December 14, 2016.
  62. 62.
    Meyer, B. (1992). Applying “design by contracts”. Computer, 25(10), 40–51.CrossRefGoogle Scholar
  63. 63.
    Miorandi, D., Sicari, S., De Pellegrini, F., & Chlamtac, I. (2012). Internet of Things: Vision, applications and research challenges ad hoc networks. Ad Hoc Networks, 10(7), 1497–1516.CrossRefGoogle Scholar
  64. 64.
    Miranda, J., Mäkitalo, N., Garcia-Alonso, J., Berrocal, J., Mikkonen, T., Canal, C., et al. (2015). From the Internet of Things to the internet of people. IEEE Internet Computing, 19(2), 40–47.CrossRefGoogle Scholar
  65. 65.
    Mzahm, A. M., Ahmad, M. S., Tang, A. Y., & Ahmad, A. (2016). Towards a design model for things in agents of things. In Proceedings of the international conference on internet of things and cloud computing (pp. 1–41).Google Scholar
  66. 66.
    Mzahm, A. M., Ahmad, M. S., & Tang, A. Y. (2014). Computing hardware analysis for agents of things (AoT). In Proceedings of the 6th international conference on information technology and multimedia (pp. 223–228).Google Scholar
  67. 67.
    Mzahm, A. M., Ahmad, M. S., & Tang A. Y. C. (2013). Agents of Things (AoT): An intelligent operational concept of the Internet of Things (IoT). In 13th international conference on intelligent systems design and applications (ISDA13) (pp. 159–164).Google Scholar
  68. 68.
    Nieves, J. C., Andrade, D., & Guerrero, E. (2017). MAIoT-an IoT architecture with reasoning and dialogue capability. In E. Sucar, O. Mayora, & E. Munoz de Cote (Eds.), Applications for future internet. Lecture notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering (pp. 109–113). Cham: Springer.Google Scholar
  69. 69.
    Ozkaya, M., & Kloukinas, C. (2013). Towards design-by-contract based software architecture design. In 2013 IEEE 12th international conference on intelligent software methodologies, tools and techniques (SoMeT) (pp. 157–164).Google Scholar
  70. 70.
    Pack, S., Baek, S., Kwon, T., & Choi, Y. (2008). Authentication, authorization, and accounting (AAA) framework in network mobility (NEMO) environments. In Handbook of research on wireless security (pp. 395–411).  https://doi.org/10.4018/978-1-59904-899-4.ch025.
  71. 71.
    Pai, F.-P., Hsu, I.-C., & Chung, Y.-C. (2016). Semantic web technology for agent interoperability: A proposed infrastructure. Applied Intelligence, 44(1), 1–16.CrossRefGoogle Scholar
  72. 72.
    Paz, J., Castillo, A., & González, R. (2014). An evaluation of integration technologies to expose agent actions as web services. In Z. Wen & T. Li (Eds.), Practical applications of intelligent systems. Advances in intelligent systems and computing (pp. 259–270). Berlin, Heidelberg: Springer.Google Scholar
  73. 73.
    Perera, C., Zaslavsky, A., Christen, P., & Georgakopoulos, D. (2014). Context aware computing for the Internet of Things: A survey. IEEE Communications Surveys and Tutorials, 16(1), 414–454.CrossRefGoogle Scholar
  74. 74.
    Pico-Valencia, P., & Holgado-Terriza J. A. (2016). Semantic agent contracts for internet of agents. In IEEE/WIC/ACM international conference on Web Intelligence Workshops (WIW) (pp. 76–79).Google Scholar
  75. 75.
    Pico-Valencia, P. A., & Holgado-Terriza, J. A. (2016). An agent middleware for supporting ecosystems of heterogeneous web services. Procedia Computer Science, 94, 121–128.CrossRefGoogle Scholar
  76. 76.
    Preuveneers, D., Van den Bergh, J., Wagelaar, D., Georges, A., Rigole, P., Clerckx, T., et al. (2004). Towards an extensible context ontology for ambient intelligence. In P. Markopoulos, B. Eggen, E. Aarts, & J. L. Crowley (Eds.), Ambient intelligence. EUSAI 2004. Lecture notes in computer science (pp. 148–159). Berlin, Heidelberg: Springer.Google Scholar
  77. 77.
    Price, R., Krishnaswamy, S., Loke, S. W., & Chhetri, M. B. (2004). Towards an ontology for agent mobility. In S. Wang, K. Tanaka, S. Zhou, T. W. Ling, J. Guan, D. Yang, et al. (Eds.), Conceptual modeling for advanced application domains. ER 2004. Lecture notes in computer science (pp. 484–495). Berlin, Heidelberg; Springer.Google Scholar
  78. 78.
    Razzaque, M. A., Milojevic-Jevric, M., Palade, A., & Clarke, S. (2016). Middleware for internet of things: A survey. IEEE Internet of Things Journal, 3(1), 70–95.CrossRefGoogle Scholar
  79. 79.
    Rodriguez-Castro, B., Torok, L., & Hepp, M. (2016) Computer vocabulary language reference. http://www.ebusiness-unibw.org/ontologies/opdm/computer.html. Accessed December 14, 2016.
  80. 80.
    Rodriguez-Valenzuela, S., Holgado-Terriza, J. A., Gutierrez-Guerrero, J. M., & Muros-Cobos, J. (2014). Distributed service-based approach for sensor data fusion in IoT environments. Sensors, 14(10), 19200–19228.CrossRefGoogle Scholar
  81. 81.
    Russel, S., & Norvig, P. (2003). Artificial intelligence: A modern approach. New York: Prentice Hall.Google Scholar
  82. 82.
    Soriano, J., Heitz, C., Hutter, H. P., Fernández, R., Hierro, J. J., & Vogel, J., et al. (2013). Internet of services. In E. Bertin, N. Crespi, & T. Magedanz (Eds.), Evolution of telecommunication services. Lecture notes in computer science (pp. 283–325). Berlin, Heidelberg: Springer.Google Scholar
  83. 83.
    Sporny, M., Longley, D., Kellogg, G., Lanthaler, M., & Lindström N. (2017). JSON-LD 1.1 A JSON-based serialization for linked data. http://json-ld.org/spec/latest/json-ld/. Accessed January 23, 2017.
  84. 84.
    Sturm, A., & Shehory, O. (2014). Agent-oriented software engineering. Reflections on architectures, methodologies, languages, and frameworks. Berlin: Springer.Google Scholar
  85. 85.
    The Apache Software Foundation. (2014). jUDDI Project: An open source implementation of OASIS’s UDDI v3 specification. https://juddi.apache.org/. Accessed December 20, 2017.
  86. 86.
    Thomas, R., & Taylor, R. (2000). Architectural styles and the design of network-based software architectures. https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Accessed December 14, 2016.
  87. 87.
    Tran, H. T., Baraki, H., & Geihs, K. (2015). An approach towards a service co-evolution in the Internet of Things. In R. Giaffreda, R. Vieriu, E. Pasher, G. Bendersky, A. Jara, J. Rodrigues, et al. (Eds.), Internet of Things. User-centric IoT. IoT360 2014. Lecture notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering (pp. 273–280). Cham: Springer.Google Scholar
  88. 88.
    Vresk, T., & Cavrak, I. (2016). Architecture of an interoperable IoT platform based on microservices. In 39th international convention on information and communication technology, electronics and microelectronics (MIPRO) (pp. 1196–1201).Google Scholar
  89. 89.
    Whitmore, A., Agarwal, A., & Da Xu, L. (2015). The Internet of Things: A survey of topics and trends. Information Systems Frontiers, 17, 261–274.CrossRefGoogle Scholar
  90. 90.
    Xia, F., Liu, L., Li, J., Ma, J., & Vasilakos, A. V. (2015). Socially aware networking: A survey. IEEE Systems Journal, 9(3), 904–921.CrossRefGoogle Scholar
  91. 91.
    Xu, X., Bessis, N., & Cao, J. (2013). An autonomic agent trust model for IoT systems. Procedia Computer Science, 21, 107–113.CrossRefGoogle Scholar
  92. 92.
    Xu, D., Fang, B., & Li, H. (2016). An abstract communication service interface of DPWS on embedded device. In 2016 Chinese control and decision conference (CCDC) (pp. 4695–4699).Google Scholar
  93. 93.
    Yu, H., Shen, Z., & Leung, C. (2013). From Internet of Things to Internet of Agents. In 2013 IEEE international conference on green computing and communications and IEEE Internet of Things and IEEE cyber, physical and social computing (pp. 1054–1057).Google Scholar
  94. 94.
    Yurur, O., Liu, C. H., Sheng, Z., Leung, V. C., Moreno, W., & Leung, K. K. (2014). Context-awareness for mobile sensing: A survey and future directions. IEEE Communications Surveys and Tutorials, 18(1), 68–93.CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media, LLC, part of Springer Nature 2018

Authors and Affiliations

  1. 1.Pontifical Catholic University of EcuadorEsmeraldasEcuador
  2. 2.University of GranadaGranadaSpain
  3. 3.University of GranadaGranadaSpain

Personalised recommendations