In this exploratory research we study the computational abilities of servers in the Linked Data network through agents that cooperatively evaluate tasks via delegation. We show the feasibility of developing lightweight systems of agents over the current Web infrastructure. We design a simple delegation language, develop a lightweight software (agent) to be installed over Web servers, and implement a study case over actual Web data to show the viability of the proposal.
3 This paper is a short report on the Master Thesis of the rst author. The spanish version is available at http://repositorio.uchile.cl/handle/2250/139150
We formulate the delegation mechanism and identify the main characteristics that may occur during the delegation in MAS in the environment of the Web. By way of motivation, consider an organized group of Web servers A, B, C, D, E and in each of them agents AgentA, AgentB, AgentC , AgentD and AgentE respectively installed. A possible scenario of interaction of these agents is that AgentA delegates a tasks to AgentB and AgentC , and both report the task performed to AgentE , who centralizes and processes the results received from them, to nally deliver the result to AgentD, who in turn can deliver the result to AgentA or alternatively notify by a messaging system to the original user who originated the task.
A prerequisite for the proper functioning of the scenario described would be
the existence of a software infrastructure of MAS so that agents can interact with
each other collaboratively. On the Web, a platform environment based entirely
on Web protocols allowing robust, secure and reliable interaction is required.
This platform should include at least the following capabilities: (
For allowing the agents to develop their capacities it is needed a high level of communication infrastructure between platforms. The Agent Communication Language (ACL) [12] communication language established by FIPA would be the most appropriate for it. On the other hand, an ideal platform for MAS would be JAVA Agent DEvelopment Framework because it has as characteristic a good communication infrastructure. However, although it supports HTTP protocol communications, is not completely oriented to the Web. For this reason, we develop and used platform called Agent Server [4], which is based entirely on the Web and developed with features of a REST API. Agent Server incorporates relevant information and functions for managing agents from the behavior and life cycle point of view. The architecture of this platform includes the Message Transport Protocol Module for reliable processing of messages, which uses the ACL and managed by the methods of the HTTP communication protocol. Likewise Agent Manager incorporates the module responsible for the management of the platform and agents.
The core of the MAS is the notion of action, which codes the basic capabilities of the system. In the following we introduce the miminal actions that agents should have to implement the delegation process: { Exec(Expr; M data) The agent that has this action implemented should have the ability to run a task. This action is composed of Expr that represents a particular expression (for example, an SPARQL expression, an SQL expression), and M data that is the metadata that is required for the implementation of the action (for example it can be either a constraint). { PutTo(Agents; R) The agent that has this action implemented has the ability to make and/or deliver a result obtained after performing an action Exec( ) to an agent that can be speci ed initially, or could be the one that initiated a task or a third party that is on a di erent platform but within the same domain. In this action, Agents represents the agent receiving the result and R represents the result obtained. { Join(Ri; :::; Rn) The agent that has this action implemented has the ability to unite the results received and integrate them into one. This actions parameters Ri; :::; Rn represent the results received.
The process of delegation requires agents that might specify arguments and communicate data in a structured manner. The parameters can be about the nature of information search, basic negotiation, or simply express tasks that the agent must perform. The degree of allocation of those parameters will re ect the degree of delegation. We use the notion of performatives de ned in the Speech Acts Theory presented by Austin [2]. In the ACL the performatives are denoted as Communicative Acts and is expressed as a query, recommendation or call. For our current model we only consider the performatives QUERY IF, REQUEST and INFORM. The choice of these is due to the simplicity of their implementation.
In order to de ne a formal semantics, we start from the Communicative Act S-Delegate(), described by Doherty et al. [5]. Their setting is oriented towards completely reactive agents, that is, agents with very simple reasoning capabilities and under the restrictions of the HTTP communication protocol. The following expression represents represents Communicative Act of the FIPA Architecture:
S-Delegate(AgentA; AgentB; performative( ; M data)): This means that the AgentA delegates the task to AgentB, using the FIPA performatives. This means that the following conditions must be ful lled: All agents have the same capabilities, that is, the same actions are implemented in all agents; All agents exhibit the list of actions implemented; The agents belonging to the same domain know of the existence of other agents and therefore know their location; At the same domain all agents have the necessary permissions to perform an action.
The actual behavior of MAS relies in a relevant manner in the specifation of the interaction protocol between participants to ensure interoperability and safety of participants. The protocol describes the interaction between AgentA and AgentB and is developed in the following two phases: Phase 1. The AgentA checks the list of actions that are implemented in AgentB. To do this, the performatives QUERY IF (to query the actions to develop) and INFORM (for the result of the query) are used; Phase 2. If the received result satis es the list of actions to be developed, AgentA plays the role of the delegator agent that delegates the task and AgentB plays the role of contractor agent. To do this, the performatives REQUEST and INFORM are used. By means of REQUEST the task is sent to the contractor agent AgentB, who is committed to execute the task. Once it nishes the execution, sends a conclusion message by means of INFORM to AgentA, in order that the delegator does not wait inde nitely.
In the literature there are di erent approaches to address the navigation on the Linked Open Data (LOD). Among them is the language NautiLOD [9, 11], a declarative language designed to specify navigation patterns in LOD. This language is based on regular expressions on predicates RDF intertwined with tests of the type ASK SPARQL queries issued on the RDF resources present at each node (server) this is implemented by SWPORTAL [10] and SWGET [8]. Both SWPORTAL and SWGET are currently implemented in a centralized form, depending to process a NautiLOD expression on a central node that makes the succesive requests to di erent Endpoints using only the GET method of the HTTP protocol.
In our case study we develop a fully distributed version using agents. For this, four servers have been con gured in the Microsoft Azure platform in which we replicated the SPARQL Endpoints dbpedia.org, freebase.org, geonames.org and yago.org respectively and agents A, B, C and D installed on each server. Each of these agents has implemented a NautiLOD Engine, which allows to process NautiLOD expressions and delegating tasks if it were necessary.
To illustrate, let us show how the following query, described in the literature [9] performs: \Starting from DBpedia, nd cities with fewer than 15000 persons, along with their aliases, in which musicians,currently living in Italy, were born".
This expression becomes an ASK query interlaced with a FILTER which allows evaluating triples that meet the pattern established. The agent expression takes the form ::putTo( AgentC , ::exec( EXP )) which will be interpreted by the players involved. The putTo( ) action indicates that the result will be delivered to AgentC after executing the exec( EXP ) action where EXP is the NautiLOD expresssion.
The execution of the NautiLOD expression uses delegation as follows: (
At rst sight it may seem this as a simple excercise or example. But it
development needs: (