Research Article OntoTrader : An Ontological Web Trading Agent …downloads.hindawi.com/journals/tswj/2014/560296.pdf · 2019-07-31 · approach [ , ]. ese traders have to operate

Research ArticleOntoTrader An Ontological Web Trading Agent Approach forEnvironmental Information Retrieval

Luis Iribarne Nicolaacutes Padilla Rosa Ayala Joseacute A Asensio and Javier Criado

Applied Computing Group Department of Informatics University of Almeria 04120 Almerıa Spain

Correspondence should be addressed to Luis Iribarne luisiribarneuales

Received 29 August 2013 Accepted 2 December 2013 Published 1 April 2014

Academic Editors J Shu and F Yu

Copyright copy 2014 Luis Iribarne et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

ModernWeb-based Information Systems (WIS) are becoming increasingly necessary to provide support for userswho are in differentplaces with different types of information by facilitating their access to the information decision making workgroups and soforth Design of these systems requires the use of standardized methods and techniques that enable a common vocabulary tobe defined to represent the underlying knowledge Thus mediation elements such as traders enrich the interoperability of webcomponents in open distributed systems These traders must operate with other third-party traders andor agents in the systemwhich must also use a common vocabulary for communication between them This paper presents the OntoTrader architecturean Ontological Web Trading agent based on the OMG ODP trading standard It also presents the ontology needed by some systemagents to communicate with the trading agent and the behavioral framework for the SOLERESOntoTrader agent an EnvironmentalManagement Information System (EMIS) This framework implements a ldquoQuery-SearchingRecovering-Responserdquo informationretrieval model using a trading service SPARQL notation and the JADE platform The paper also presents reflection delegationand federation mediation models and describes formalization an experimental testing environment in three scenarios and a toolwhich allows our proposal to be evaluated and validated

1 Introduction

In a more open world information systems must be flexibleand readily adaptable extendable accessible and operable bydifferent people or groups of people who are in differentplaces and have different types of information facilitatingaccess to information by decision-makers workgroups andso forth (convergent systems) This involves the use of rulesand standards for their construction and real-time operationinteraction and interconnection In this kind of systemssystem ldquoagentsrdquo (eg web components subsystems andhumans) working in the same ambient (computing space) oreven other third-party ldquoagentsrdquo interact System convergenceis possible through three basic parameters (a) autonomy andintelligence (software agents) (b) a common vocabulary forall convergent systems (ontologies) and (c) trading betweensubsystems necessary to enable coordinate translate andmaintain this common vocabulary (traders)Themost recentWeb Information Systems (WIS) have been developed underopen and distributed paradigms using rules and standards for

the construction and operation of real time interaction andinterconnection [1] WIS are intended for the new era ofinformation systems in web environments due not only tothe growing popularity of the web technology but also to theroles of web technology in modern information systemsThemajor features of web information systems areweb semanticsXML technologies web mining and querying and informa-tion extraction [2]

Environmental Management Information Systems (EMIS)[3] are a type of WIS Experimentation with WIS technolog-ical advances in fields like medicine biology and especiallyenvironment has allowed real convergent systems to developover time EMIS are social and technical systems with a vari-ety of final users and actors (ie politicians technicians andadministrators) who cooperate with each other and interactwith the system for decision making problems solving andso forth AnEMIS uses normally knowledge bases distributedin space and timeNot only is this information used by humanactors in the system but also coordinates web software (andautonomous) components requiring a common vocabulary

Hindawi Publishing Corporatione Scientific World JournalVolume 2014 Article ID 560296 25 pageshttpdxdoiorg1011552014560296

2 The Scientific World Journal

(eg ontologies) An example of web-based EMIS is theSOLERES system a spatiotemporal environmental manage-ment system based on neural networks agents and softwarecomponents [4]

An EMIS is an Information System supporting environ-mental management EMIS are a special case of GeographicInformation Systems (GIS) though the granularity of environ-mental information ismore specific (eg satellite and ecolog-ical information) Furthermore EMIS use a more advancedmore specific technology than geographic information sys-tems for instance we use neural networks multiagentssystems and cellular automata features

Two basic roles interact in WIS the Human and theComputer Due to the nature of these systems (open and dis-tributed) people organized in workgroups for decision mak-ing may be found in different places and be arranged bytheir profile (eg administrators politicians technicians andusers) This sort of interaction (Human-to-Human HH)requires unified protocol and communication policies for allparts of the system People and groups of people also interactthrough the system by using user interfaces (UI) which aregenerally well suited to their needs [5] This type of interac-tion (Human-to-Computer HC) also needs to establish com-munication protocols among users profiles groups and userinterface agents Finally these user interface agents act asmediators for people interacting with other system agentsThis interaction (Computer-to-Computer CC) requires com-munication protocol commonly known as choreography (ororchestration) All three of these types of interaction protocol(HH HC and CC) software have to know the knowledgesemantics that manages each part of the system (ie agents)

Mediators (commonly known as ldquotradersrdquo) enrich theinteroperability of web components working in a WISapproach [6 7] These traders have to operate with otherthird-party traders andor agents in the system which mustalso use a common vocabulary to allow communicationbetween themThe design of these components and the inter-action protocols (mentioned above) must use standardizedmethods and techniques that allow a common vocabularyrepresenting the underlying knowledge to be defined Onto-logies are used as a means to this goal [8]

On the other hand popularity of the WIS has led to anincreasing volume of information available in informationsystemsUsers depend on the web to meet their informationneeds through search engines portals digital libraries andother information retrieval systems [9 10] However infor-mation overload has led to a situation where users areswampedwith toomuch information and have to sift throughthe material in search of relevant content To address theseproblems a variety of techniques inherent in informationsearching drawing from the fields of information retrievalinformation filtering human-computer interaction and thestudy of information search behavior have been adopted intheWIS Information retrieval refers to techniques that assistusers in meeting their information needs [11]

ThemainWISinformation retrievalmechanism is the tra-ditionalQuery-SearchingRecovering-Response (QSRR)Thismechanism is based on the traditional clientserver modelOn one hand the term ldquoQueryrdquo refers to the whole process of

creating and formulating the clientrsquos questionThe term ldquoSea-rchingrdquo refers to the process of locating the repositories wherethe information is found and the term ldquoRecoveringrdquo refersto the process of locating identifying and selecting the datafrom the data sources (repositories data storage or databasesregardless of the model) Finally the term ldquoResponserdquo refersto the whole process of formulation preparation and cre-ation of the response by the server to the client The ldquoQuery-Searchingrdquo pair is a process that goes from the client to theserver The ldquoRecovering-Responserdquo pair goes from the serverto the client

UDDI (Universal Description Discovery and Integration)specification and WSDL (Web-Services Definition Language)for SOA (SOA httpwwwoasis-openorg) (ServiceOrientedArchitecture) are based on theseclientserver implementa-tions for web systems Nevertheless these techniques allowagents to respect a subscribepublishresponse model and aQSRR information retrieval approach for locating WSDLdocuments (ie XML specifications of web-services) andconnecting web services inWIS but not for different types ofinformation (non-WDSL information) Traders are anothersolution for open and distributed systems [12] that extendthe OMA (OMA httpwwwomgorg) (Object Manage-ment Architecture) ORB (Object-Request Broker) mechanismAlthough traders are traditionally used as middleware forobject interoperability they can easily be adapted for interop-erability of information and functionality In respect to thisthe use of functional ontologies in our work is a goodsolution for adapting traders to information retrieval inWISUser information retrieval is an emerging area and a promis-ing avenue for the design and implementation of a new gen-eration of information retrieval systems especially for newweb-based EMIS due to the particularity and complexity ofthe information and users (politicians technicians andadministrators) [13]

In a sense the SOLERES system (a spatiotemporal envi-ronmental management system based on neural networksagents and software components) our EMISmodel follows aWIS approach [14ndash17] In this paper we propose theOntolog-ical Web Trader (OntoTrader) as a mechanism for solving thecomplexity of information retrieval in the EMIS by means ofa trading model for WIS guided and managed by ontologiesThis kind of web service is a user-information search servicebased on a web QSRR model Therefore OntoTrader is anew information retrieval mechanism that implements a QSRR model and uses the SPARQL query language and theOWL ontology description language to operate This serviceis based on a user request action that identifies the agentsinvolved and their communication protocols In our systemthe ontologies are used in two different contexts (a) they rep-resent the application domain information itself and (b) theservices that some agents request from others during theirinteraction Although a trader agent has five interfaces (ieLookup Register Link Proxy and Admin) this paper dis-cusses only the behavioral and data ontology design featuresof the Lookup trader interface which is used for searchingand recovering user information in a QSRR model Allresearch work presented here is part of a complete designstrategy for Ontology-Driven Software Engineering (ODSE)that we are developing in SOLERES

The Scientific World Journal 3

The remainder of the paper is organized as followsSection 2 reviews some EMIS approaches and compares howontologies agents and trading features are used Section 3presents the SOLERES system as a running case studySection 4 defines OntoTrader a WIS information retrievalmechanism In this part we describe the Lookup interfaceontology and the metadata template that the trader man-ages (ie an OWL metadata repository of environmentalinformation) in OWL and formalize them in UML Section 5presentsOntoTrader formalization Sections 6 and 7 describesome implementation and experimental scenario details andsome evaluation and validation discussions respectively Weend with some conclusions and prospects for future work inSection 8

2 EMIS Technology

The progress of the new technologies in web-based informa-tion systems is obvious In a more open world informationsystems must be flexible and readily adapted extendableaccessible and operable by different people or groups of peo-ple (convergent systems) The convergence of these systemsmay appear over time with the business needs of the systemFor instance a decision-making system in medicine origi-nally made up of two subsystems may increase over time byconnecting to other systems in networks which requireprovide contentsservices to the system service as a wholeThe convergence of these systems is possible due to threebasic parameters (a) autonomy and intelligence (b) a com-mon vocabulary for all convergent systems and (c)mediationbetween subsystems necessary to enable coordinate trans-late and maintain this common vocabulary In the first para-meter software agent and multiagent system propertiesencapsulate traditional concepts of web components (or webservices) with repositories of knowledge-based rules thatwork autonomously (endowing it with a certain degree ofintelligence) These rules can be made and applied to agentgroups that work in the same communication and behaviorpatterns (choreography) Ontologies are a good mechanismfor establishing this common vocabulary necessary in con-vergent systems

Semantic web is a good example of this It standardizes thecriteria languages mechanisms methodologies and plat-forms in universal web data semantics Finally trading ser-vices are a good device for communication-coordination(interoperability) between WIS subsystems as for exampleUDDI andWSDL in SOA EMIS is an example of WIS devel-oped during recent years Experimentation with technologi-cal advances inWIS in fields likemedicine biology and espe-cially environment has allowed real convergent systems togradually emerge In the following sections we analyze somerelevant EMIS found in the literature and see how agentsontologies and trading services are applied ending with acase study the SOLERES system architecture as an exampleof an environmental information system developed by theApplied Computing Group (ACG) at the University of Alme-ria Spain [4]

21 Agent and Multiagent Systems in EMIS Software agentsare applied in different contexts in information systemsTheyare applied in four basic ways (their hybrids) in Web-basedEnvironmental Information Systems (our main line ofresearch)

(a) In information management agents can be used forsearching for information (such as a database) theycan filter results recall them organize or even auto-matically distribute them

(b) In control and supervision processes (monitoring) anagent canmonitor a particular element or activity andrespond to any event that may occur for examplein transport system modeling and control or inindustrial processes

(c) In cooperative work group applications (ComputerSupported Cooperative Work CSCW) where due totheir nature agents can support the information flownecessary for the activity and interaction of groupmembers

(d) As personal assistants an agent can only easily repre-sent a user if heshe knows hisher preferences before-hand and can act according to those preferences Forexample in electronic commerce applications thecommercial transactions require access to manyresources in real time and this task can be performedby one or more agents on behalf of the user

We used these four contexts to design and implementthe QSRR model for a web-based trading agent (Onto-Trader) Section 4 For an MAS design not only the proper-ties mentioned above must be borne in mind but also thechoice of a clear precise methodology and a developmentplatform There are currently over a hundred software pro-ducts for agent-based application design which are mainlyused in academic and commercial environments Someexamples are AdventNet Agent Toolkit Agent BuilderAgentTcl AgentTalk AgentTool AgentWare Cable Emor-phia FIPA-OS Grasshopper Impact JADE MAGE MASSMicrosoft Agent SiWalk Soar and so forth We usedJADE (JADE httpjadetilabcom) (Java Agent Develop-ment Framework) to implement the SOLERES multiagentsystembecause it simplifies the implementation ofmultiagentsystems through middleware and provides a tool-set as sup-port for depuration and implementation of open distributedand heterogeneous information systems

Agent-based environmental systems are grouped intoenvironmental information management assistance indecision-making for environmental problems and environ-mental system and process simulation Due to our specialinterest in EMIS designed with agent technology we exhau-stively reviewed the most important systems Table 1 shows asummary of the EMIS architectures studied We haveincluded the following relevant system metrics used in ourweb trading agent proposal including SOLERES in the tablefor comparison (a) use of trading mechanisms (b) use ofmodeling and designing ontologies and (c) use of some typeof user or interface agentWe also studied the technology andthemain application domainmetricsTheEMIS architectures


Table 1 A comparative view of some environmental management system architectures

System Trading Ontologies User agent Technology Application domainInfoSleuth No Yes Yes XMLRDF KQML and OKBC Water resourcesEDEN-IW No Yes Yes JADE DAML-OIL Water resourcesNZDIS No No Yes CORBAOQL MOF Environmental dataFSEP No No No JACK MeteorologyMAGIC No No Yes FIPA-ACL CORBA Water treatmentsDIAMON No No Yes JavaC++ FIPA-ACL Water treatmentsBUSTER Yes Yes No OIL FIPA-OS Geographical informationSOLERES Yes Yes Yes JADE OWL SPARQL and UML Ecology

studied were InfoSleuth [18] EDEN-IW [19] NZDIS [20]FSEP [21] MAGIC [22] DIAMOND [23] and BUSTER [24]

22 Ontology Applications in EMIS Ontologies were desi-gned to be used in applications that need tomanage informa-tion semantics In general ontologies not only describe spa-tial data for instance more easily understood by computersin encoded semantics but also integrate other EMIS data (iegeographical) from different sources and different ways ofreasoning

There are several languages available formodeling knowl-edge domains [25] in particular DAM-OIL [26] and OWL[27] Web Ontology Language (OWL) the most recent andwidely used language at present was designed to be used inapplications that need to test the content of the informationinstead of just representing it Such content can either be newor related to others An ontology can therefore use terms thatare included in other ontologies and change them creating anopen distributed system

In the literature ontologies have been used to representenvironmental knowledge In [28] the authors present anenvironmental decision-support system called OntoWEDSSfor wastewater management In this system an ontology isused to provide a common vocabulary for modeling thewastewater treatment and an explicit conceptualization thatdescribes data semantics Another example may be found in[29] an air quality monitoring system which uses an ontol-ogy to define messages and communications concisely andunambiguously In [30] the authors present Ecolingua anEngMath family ontology for representing quantitative eco-logical data These examples show the use of ontologies tobuild models that describe the entities in the given domainand characterize the relationships and constraints associatedwith them

In [31] the authors present an ontology for representinggeographic data and related functions To meet the need foran interoperable GIS in [27] the authors propose a Geo-ontology model design to integrate geographic informationWe have also explored an ontological application in the fieldof geographic information retrieval [32] A different useappears in [6] where an OWL extension has new primitivesfor modeling spatial location and spatial relationships with ageographic ontology

Extensions of existing ontologies have also appeared inthis knowledge domain In [33] the authors propose a

Importer Trader Exporter

4 invoke()

3 import()

2 query()

1 export()

Figure 1 Roles of the ODP trader (Adapted from ISO RM-ODP)

geographic ontology based on GeographicMarkup Language(GML) [34] and theOWL-S profile is extended to geographicprofiles Another case is an extension of the NASA SemanticWeb for Earth and Environmental Terminology (SWEET)ontologies that includes part of the hydrogeology domain[35]

23 Trading in Open Distributed Systems The ReferenceModel of OpenDistributed Processing (RM-ODP) is amodeljointly developed by the International Standard Organisation(ISO) and the International TelecommunicationUnion (ITU-T) This model defends the transparent use of servicesdistributed in platforms and heterogeneous networks anddynamic location of these servicesThe trading function is oneof the 24 functions of ISOITU-TODPmodel [12]This speci-ation was adopted by the Object Management Group (OMG)which called it CosTrading for the CORBA services tradingservice

From the viewpoint of object-oriented programming(OOP) a trading function (trader) is a software object whichserves as an intermediary between objects that provide cer-tain capacities (services) and objects that require dynamic useof these capacities From the ODP perspective those objectsproviding capacities to other objects are called exporters andthose requiring capacities from the system objects are calledimporters (Figure 1)

A trading object uses five interfaces to interact with clientobjects (importer and exporter) Register Lookup LinkProxy and AdminThe Lookup interface allows clients to askthe trader about the services stored in the trading serviceWith the Register interface clients can export services offered


in the trader The Link interface allows the trader to be con-nected to other traders (ie trading federation) This enablesthe system administrator to connect his trader with otherwell-known traders and propagate requests in a networkThetrader can also send the request to connected traders andlocate new offerswith the same searching conditions imposedon the target trader The Admin interface allows administra-tors to configure the trader (eg searching policies orderingpolicies and numbers of federated traders allowed) TheProxy interface is used to enable legacy system properties infederated trader systems

3 A Case Study The SOLERES System

This section presents the main SOLERES system architec-ture a spatiotemporal information system for environmentalmanagement (an example of EMIS)This system is supportedby the application integration and development (extension)of multidisciplinary studies in satellite imaging neural net-works cooperative systems based onmultiagent architecturesand intelligent agents and software systems with commercialcomponents The general idea of the system is a frameworkfor integrating the disciplines above for ldquoenvironmental infor-mationrdquo as the application domain specifically ecology andlandscape connectivityThe system has twomain subsystemsSOLERES-HCI and SOLERES-KRS Figure 2 shows the gen-eral system architecture

SOLERES-HCI is the framework specialized in human-computer interaction This level of the information system isdefined by means of the Computer Supported CooperativeWork (CSCW) paradigm and implemented using innovativeintelligent agent technology and multiagent architecturesThe system is designed to be used for cooperative envi-ronmental decision-making tasks by different people (sys-tems users) arranged in different organization models (iedepending on their hierarchy or profile)Theremay be politi-cians technicians or administrators among others whoneed to interact with each other and with the system

A user of the cooperative system has an intelligent agent(Interface agent in Figure 2) which operates two ways (a) bymanaging user interface presentation and interaction (UIagent) and (b) bymanaging the environmental queries (EMISagent) The UI agent mediates between the user and otherusers in the system (using other UI agents) The EMIS agentrefers to a virtual consultant or virtual supervisor who coop-erates with other agents within a previously established mul-tiagent architecture Both agents (ie UI and EMIS agents)follow protocol models for orchestration of the cooperativesystem cooperation among agents UI agents use HCI chore-ography (protocol) and EMIS agents use CSCW choreogra-phy

On the other hand SOLERES-KRS is used to manageenvironmental informationThe IMI agent is like a gatewaybetween the user interface and the rest of the modules and isresponsible for the management of user demands

Given the magnitude of the information available in theinformation system and that this information may be pro-vided by different sources at different times or even by

different people the environmental information (ie theknowledge) can be distributed consulted and geographicallylocated in different ambients (ie locations containersnodes or domains) called Environmental Process Units(EPU) Thus the system is formed by a cooperative group ofknowledge-based EPUs These groups operate separately byusing an intelligent agent to find better solutions (queries onecological maps)

We accomplished the distributed cooperation of theseEPUs by developing a web trading agent (OntoTrader) basedon the ODP trader specification [12] and extended to agentbehavior Our trading agent mediates between HCI requestsand EPU services EPUs manage two local repositories ofenvironmental information One of the repositories con-tains metadata on the information in the domain itself(ie basically information related to ecological classifica-tions and satellite images) called Environmental InformationMap (EIM) data or EIM documents This information isextracted from outside databases (External DB repositoryin Figure 2)TheEIMdocuments are specified by an ontologyin OWL [15 16] (ltltOWLrepositorygtgt) These EIM docu-ments are the first level of information in the KRS subsystem

The second repository contains metadata called envi-ronmental information metadata (EID) or EID documentsThese documents contain the most important EIM metadatathat could be used in an information retrieval service andfurthermore incorporate other new metadata necessary foragent management itself To a certain extent an EID docu-ment represents a ldquotemplaterdquowith the basicmetadata from theEIM document data The EID documents have also beenspecified by an ontology to accomplish open distributed sys-tem requirements EID documents represent the second levelof information in theKRS subsystem EachEPUkeeps its ownEID document (or sets of documents) locally and also regis-ters them with the OntoTrader (the web trading agent) Thisway the OntoTrader has an overall repository of all the EIDdocuments from all EPUs in an ambient and can thereby offeran information search service as described further below

The trading service implemented and the requirementsthat it must fulfill to be considered open and distributed aredescribed below Afterwards the structure and ontology usedby the software agent responsible for this service (the traderagent) are explained

4 Ontological Web Trading (OntoTrader)

Trading is a well-known concept for searching and locatingservices In a trader-based architecture a client componentthat requires a particular service can query a matchmakingagent (ie the trader) for references to available componentsthat provide the kind of service required We based our workon the traditional functionality of a trader but with adaptingit to knowledge-based agents instead of objects (or softwarecomponents) But first let us see the requirements a tradershould have

41 Requirements for Open Distributed (Web) TradingAlthough the trading services could be compared to web


SOLERES

SOLERES-HCI≪MAS≫

HCI system

≪Orchestration≫Choreography

≪Agent≫ ≪Agent≫

≪Agent≫

≪Agent≫ ≪Agent≫ ≪Agent≫

≪Agent≫

≪Agent≫

Interface UI

EMS

HCI

CSCWUses

Has Has

SOLERES-KRS

IMI

Ambient Web trading agent

EPU≪OWL repository≫

EID

≪OWL repository≫EIM

1

1

Trader≪Interface≫

Lookup

≪Interface≫Register

≪Interface≫Admin

≪Interface≫Link

≪Interface≫Proxy

Communication

Parser

≪OWL repository≫EID

1≪OWL repository≫

External DB

1 1

Uses

Uses

HasHas GroupScenario

1lowast

1lowast

1lowast

1lowast

1lowast

≪Protocol≫

≪Protocol≫

Figure 2 SOLERES architecture

search engines in reality web searches are more structuredIn a trading service the matching heuristics need to modelthe vocabulary the distance functions and the equivalenceclasses in a specific domain For cooperation among webtraders trading services using different strategies should beable to federate For example a repository-based federationstrategy makes it possible for different trading services toread and write in the same repository at the same time eachunaware of the presence of the others in the federation andthereby allowing the approach to be scalable On the otherhand the traditional ldquodirectrdquo federation strategy requires atrading service to communicate directly with the tradingservices with which it is federated Although this federation-based scheme is very safe and effective communicationoverloads increase with the number of federated tradingservices

Current information searching and selection (recovery)use ldquohardrdquomatchmaking operations which are too restrictive

and ldquosoftrdquo matching criteria are often necessary In tradingservices especially in independently extendable open sys-tems (eg the Internet) it must be decided whether ldquosoftrdquo orldquohardrdquo matching is required A trading service should thusallow users to be able to specify heuristic or metric functionsin the search particularly in cases where matches are ldquosoftrdquoFor instance the trading service could return results orderedby a search criterion or discard some search sequences in therepositories where they are carried out

Furthermore after processing a trading service shouldrespond to a user-query request (through a SOLERES-HCIinterface agent)with a resultThis result found after a request-response action can refer either to a list of results that meetthe restrictions imposed on the query or to a ldquofailurerdquo noticeif the search could not find a solution If a ldquofailurerdquo notice isreturned the trading service should also be able to demandthat the query request must necessarily be satisfied other-wise the query request is stored and the response is delayed


User

Internet

Discoveringrecovering

Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent

trader≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫

≪Agent≫≪Agent≫

≪Agent≫

(b) Web trading agent view

Figure 3 The web trading agent (b) uses the QSRR model (a)

This request-response behaviour is called store and forwardquery Finally a trading service should also allow queryrequests to be delegated to other (known) traders if theycannot be satisfied by the current trading service

Now that the demanded requirements of the trading ser-vice have been identified the service support structure can bedescribed

42 Web Trading Agent As outlined in Section 1 this sectiondescribes the internal structure of our trading agent and somedetails about its design and implementation It should beemphasized that the trader agent like all SOLERES systemagents was modeled designed and implemented based onrun-time management of the ontologies used The tradertherefore manages two kinds of ontologies data and func-tionality (or process) The first are related to the ecologicalinformation repositories which the trader can access Thesecond refers to trader functionality that is things which itcan do and demand from others In this case behaviour andinteraction protocols must be also defined These definitionsset the operating and interaction rules for agents governinghow the functions that the trader provides and demands towork (behaviour) are used and the order they are called up in(protocols or choreography) With this in mind certain dev-elopment details must be explained Since the work per-spective presented here is more focused on the searchingprocess and how the trader was designed based on theontologies the explanation concentrates only on the Lookup

interface (definition of the rest was similar to the followingexplanation)

Ontologies are written in the OWL notation and formal-ized as a metamodel using UML class diagrams We also usegraphs to show details of relationships between propertiesThroughout the explanation these notations are used to referto data or functionality ontology though all three notationsrepresent the same thing

As mentioned above the trading service takes part in thesearch for environmental information based on the QSRRmodel As shown in Figures 3(a) and 3(b) there are two basicsections in the model (a) the user or user groups who arerepresented by an agent interface (Figure 3(a)) and (b)the trading service which locates the metainformation(Figure 3(b)) Regarding which it should be recalled thatthe SOLERES system stores (as a whole) the environmentalinformation distributed in different OWL repositories ontwo levels Some contain environmental metadata (EIMrepositories) and other metadata from the first one (EIDrepositories) The trader manages an EID repository

The systemmakes use of ontologies Specifically it distin-guishes data ontologies which represent the information inthe domain on two levels and serviceprocess ontologieswhich represent the actions that can be performed in thesystem the information necessary to perform them and theresults of those actions In SOLERES the EIM and EID dataontologies as well as the Lookup Register Admin and Linkserviceprocess ontologies are described and they in turn arerelated to the mediation system interfaces


Classification

Geography Technician TimeLayer

Variable Band

1 1

1

Or

Satellite image

lowastlowastlowastlowastlowast

1lowast

1lowast

1lowast

1lowast

1lowast

lowast

Figure 4 Ontology of the EID metadata that traders use

Classification

Time

Technician

Classification is made by technician Technician makes classification

Classification ends timeTime is started by classification Time is ended by classification Classification starts time

Figure 5 Classification is temporal information carried out by technicians

Figure 4 shows a data ontology from an EID repositoryFor a better understanding we also show two figures with theontological relationships of the elements which describe theEID ontology (Figures 5 and 6) Let us recall that the applica-tion domain to be modeled is ecological information (a typeof environmental information) on cartographic maps andsatellite images Advanced algorithms based on neuronal net-works to find correlations between satellite and cartographicinformation were developed by the SOLERES work teamFor the calculation of this correlation prior treatment ofthe satellite images and maps is necessary (an image clas-sification Classification) A cartographic map stores itsinformation in layers (Layer) each of which is identified bya set of variables (Variable) For instance we are using car-tographic maps classified in 4 layers (climatology lithologygeomorphology and soils) with over a hundred variables(eg scrubland surface pasture land surface and averagerainfall)

Satellite images work almost the same way The informa-tion is also stored in layers but here they are called bandsAn example of satellite images are the LANDSAT imageswhich have 7 bands (but no variables are stored in this case)Finally both the cartographic and satellite classificationshave geographic information associated (Classification)which ismade at a given time (Time) by a technician or groupof technicians (Technician) As a complement and formal-ization for graphs and metamodel Table 2 shows the com-plete assertions of the eight ontology entities (the assertionsmay easily be interpreted from Figures 4 5 and 6)

The functionality of our web trading agent [14 36] isdivided into three clearly differentiated components

(see Figure 3) (a) a component that manages the agent-communication mechanism (Communication) (b) a parserthat codes and decodes the trading ontology-based messagesexchanged (Parser) and (c) trading itself (Trader) Thethird component is inspired by the traditional OMG tradingobject service specification concepts [12] (see Section 23)This specification indicates how offers and demands are to beimplemented among objects in a distributed environmentand proposes grouping all the different functionalities that atradermay includeAlthough the standard specifies five traderinterfaces (ie Lookup Register Admin Link and Proxy) itsspecification does not demand a trader to implement thesefive interfaces to work In fact we have only developedontologies for the Lookup Register Admin and Linkinterfaces but none has been implemented for the last oneyet The Lookup interface offers the search-information ina repository under certain query criteria The Registerinterface enables objects in this repository to be insertedmodified and deleted The Admin interface can modify themain parameters of the trader configuration and finallythe Link interface makes trading agent federation possible

As previously explained this paper focuses on identifyingand explaining how ontologies appear and intervene in theweb trading agent service Of the interfaces implemented weonly explain here how the Lookup interface works because ittakes part in the search which is the primary subject ofthis paper Several system agents depending on their func-tionality request these tasks (provided by the interfaces) fromthe trading agents For example a resource agent (belongingto a givenEPU) could request the trading agent of the ambientwhere both are located to register a new EID document by


Satellite_image

Band

Classification

Geography Layer

Variable

Satellite image is used by classification Classification uses satellite image

Band is shown by satellite image Satellite image shows band

Classification shows geographyGeography is shown by classification

Classification shows layerLayer is shown by classification

Layer has variable Variable is had by layer

Figure 6 Ontological relationships of a classification

Table 2 Formal EID ontology assertions

Number Entity Assertions

Number 1 Band (band id exactly 1) and (band is shown by satellite image min 0) and (band nameexactly 1)

Number 2 Classification

(classification id exactly 1) and ((classification shows layer min 1) or(classification uses satellite image min 1)) and (classification ends time exactly 1)and (classification is made by technician min 1) and (classification name exactly 1)and (classification shows geography exactly 1) and (classification starts timeexactly 1)

Number 3 Geography(geography id exactly 1) and (geography is shown by classification min 0) and(geography locality exactly 1) and (geography name exactly 1) and(geography town exactly 1)

4 Layer(layer id exactly 1) and (layer has variable min 1) and(layer is shown by classification exactly 1) and (layer name exactly 1) and(layer observations max 1)

Number 5 Satellite image (satellite image id exactly 1) and (satellite image is used by classification min 0)and (satellite image shows band min 1)

Number 6 Technician(technician id exactly 1) and (technician first name exactly 1) and(technician last name exactly 1) and (technician makes classification min 0) and(technician organization max 1)

Number 7 Time (time id exactly 1) and (time day exactly 1) and (time month exactly 1) and(time year exactly 1) and (time is started by classification min 0)

Number 8 Variable (variable id exactly 1) and (variable name exactly 1) and (variable is had by layerexactly 1)

using the Register interface Under these circumstanceshow is this request between agents expressed In SOLERESthis is done by specifying the service requests as ontologiesThe ontologies used to describe services are known as ldquopro-cess ontologiesrdquo and they are for three types of entities con-cepts actions and predicates

In our system an ontology has been created for each of thefour interfaces (services) implemented by the trading agentThe set of all ontologies used for these trading agent services iscalled the trading ontology Creation of specific ontologies forspecific services allows the agents to use only the ontologythat they need at any given time Figure 7 shows an example ofa service (ie interface) ontology expressed inUMLnotation

In this case the part of the ontology that defines the Lookupservice is specified This ontology is written in terms of con-cepts (domain entities) actions carried out in the domain(actions that affect concepts) and predicates (expressionsrelated to concepts) The only action in the Lookup serviceontology is query whichmakes the search for EIDdocumentsaccording to specified prerequisites The concepts identifiedin the ontology are

(i) QueryForm gives the information in the EID docu-ment necessary to make the query

(ii) PolicySeq represents the set of policies that specifyhow the search is to bemadeThese policiesmay affect


PolicySeq -id unsigned long-uri string

OfferSeq

Query

EmptyOfferSeqPolicyTypeMismatch

-ValuePolicy

-Value unsigned long -Value unsigned long

-id unsigned long-uri string-Type string-Source string-Target string

QueryForm-id unsigned long-uri string

OfferSeqmatch

UnknownQueryForm NotEmptyOfferSeq

-Returned_message stringMessage

QueryErrorInvalidPolicyValue DuplicatePolicyName

-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1

def search cardPolicy max search cardPolicy exact type matchPolicy

1lowast

lowast

Figure 7 UML Lookup ontology metamodel

the functionality of the trader during the executiontime

(iii) OfferSeq refers to the set of EID documents that meetthe query requirements It therefore represents theresult of the service requested

(iv) OfferSeqMach refers to the matchmaking processresult Results can be hard or soft solutions The firstone represents an exact solution (ie what the userexactly wants) and the second one refers to a partialsolution

43 OntoTrader Trading Models Let us now see how theontological web trading agent operates in the query processfollowing the QSRRmodel since the querymade by the user(or group of users) remains in the user interface until theresults are retrieved

This model is a trading-based version of the three-levelclientserver model It is comprised basically of a series ofobjects or processes ltITDgt each of which intervenes on adifferent level depending on the treatment of the query Theimplementation of these objects then corresponds to agentsLevel 1 (L

1) is like the client side Queries are generated and

dealt with by an interface object (I) Level 3 (L3) is the

server side System data (D) reside on this level In our case

these are the EIM repositories with the environmental infor-mation Level 2 (L

2) is the middleware that enables the

source information to be located This is the level where thetrader objects (T) operate In our case associated with thetrader (T) the EID repositories with the source environmen-tal information metadata (EIM) also reside there All threeobjects use the Lookup ontology (defined in Figure 7) to com-municate As the premise for their functioning an interfaceobject must be associated with a trader object However atrader object can also be associated with one or more outsidedata sources or resources in our case with the environmentalsource data (which reside in the EPU units as discussedabove) This ldquotrader-information sourcerdquo association arisesfrom the production of environmental information whereeach EPU has an associated trader in which a subset (meta-data) of environmental information generated in the EPU isregistered On the other hand each trader can be associatedwith one or more traders in federations

In this three-level architecture three different scenariosor trading models are possible Trading Reflection TradingDelegation and Trading Federation Figure 8 shows the threelevels (L

1 L2 and L

3) where the three basic objects (I T and

D) reside and the three trading models are permissible inOntoTrader as described below


I

D

T T

I

D

T T

I

D

T T

Scenario number 1(trading reflection model)

Scenario number 2(trading delegation model)

Scenario number 3(trading federation model)

L1

L2

L3

Figure 8 The three trading models of OntoTrader

(i) The Trading Reflection model is a model for directtrading on the trader The query may be solveddirectly by the trader The query is generated on theinterface and the information can be reached by themetadata that reside in the repository associated withthe trader In this case the model ltITgt pair inter-venes

(ii) The Trading Delegation model trades indirectly withthe traderThequery is partly resolved by the trader Aquery is generated on the interface level that goes onto the trading level (T) The trader locates the source(or sources) of the source data (D) in its repositoryinferring this information from its metadata reposi-tory Therefore the trader delegates the query to theoutside data source (D) In this case the object seriesintervening is ltITDgt

(iii) Finally the Trading Federation model is a case inwhich two or more traders are able to federate Asin the cases above the query remains preset on theinterface This query is passed on to the associatedtrader The trader can propagate the query to anotherfederated trader who locates the external data source(D) In this case the object series interveningis ltITTDgt

44 The Lookup Ontology in OntoTrader The Lookup onto-logy is used between system objects The trader uses theQuery action and the query form concept (see the Lookupontology Figure 7) The Query Form concept expresses thequery in a specific language whose properties among oth-ers are an id (a query identifier) and a uri (referenceto the file where the query is stored) In addition therecould be a set of query policies (Policy) through thePolicy Seq concept and each ldquopolicyrdquo is representedby means of a tuple (name value) For instance someof the tuples implemented are def search card Policyormax search card Policy indicating the number ofrecords to be located by default and the maximum number ofrecords to be located in the query respectively Possibleexceptions are (Lookup ontology Figure 7)

(i) UnknownQueryForm indicates that the query cannotbe answered because the file specified in the uri isnot accessible

(ii) PolicyTypeMismatch indicates that the type ofvalue specified is not appropriate for the policy

(iii) InvalidPolicyValue indicates that the policyvalue specified is not within the permissible valuerange for that policy

(iv) DuplicatePolicyName indicates that more thanone value for the same policy hve been specified inthe PolicySeq

(v) QueryError indicates that an error has occurredduring the query

If there is no exception and the query is successfully exe-cuted either the EmptyOfferSeq predicate is used when norecord is returned by the query or the NotEmptyOfferSeqpredicate when some record is returned This in turn usesthe OfferSeq concept to represent the set of records locatedin the query whose properties are the query ldquoidrdquo and the fileldquourirdquo where the records found are stored

5 Formalization of Ontological Web Trading

This section presents the formalization of ontological views ofthe query and response actions for the proposed web traderagent Both actions are described by means of theLookupontology (see Figure 7)We focus only on the formalization ofthe Lookup ontology because of its relationship with theQRRR process

Definition 1 (web trader) A web trader T is determined bytwo setsT= OG whereO is a set of two types of ontologies(data and functions)O= O

119889O119891 andG is a set of scheduling

and control agents where

(a) O119889is an OWL repository used by the trader

(b) O119891is a set of five ontologies O

119891= LEDKX

where L is the ontology of the Lookup interface L =

0 (mandatory)E is the ontology of the Register interfaceE = 0 (mandatory)D is the ontology of the Admin interfaceK is the ontology of the Link interface Xis the ontologyof the Proxy interface

In the framework of SOLERES system ontological dataO119889are related to ecological information repositories written

in OWL Ontological functions O119891refer to trader function-

ality There are at least two ontological functions (a) the


Lookup ontology (L) which models the query made to thetrader about information (templates) stored in the tradingservice and (b) the Register ontology (E) which models theexport (register) of OWL instances in the trader The threeremaining ontologies are not mandatory in a web trader TheLink ontology (D)models the interconnection of traders (ietrading federation) An Admin ontology (K) models thetrader configuration (eg searching policies ordering poli-cies and numbers of federated traders allowed) Finally aProxy ontology (X) models the legacy systems properties in afederated trader system

Definition 2 (Lookup ontology) The Lookup interface of aweb trader agent is defined as an ontology L = CAP

RR consisting of

(a) C a finite set of conceptsC = FYO O where

(i) F is a query form F = id uri type sourcetarget

(ii) Y is a policy sequence for instancedef search cardPolicy max search cardPolicyexact type matchPolicy

(iii) O is an offer sequence O = id uri(iv) O is an offer sequence matchM = id uri

(b) A an action A = Q where Q is an input queryaction

(c) P a finite set of predicatesP = M whereM is areturned message

(d) R a relation of request

(e) R a relation of response

A represents the set of possible actions (in the Lookupontology only a Query Q) whileF is a concept related to aQuery action which represents the query made

Predicates report any errors in the previous action(UnknownQueryForm PolicyTypeMismatch InvalidPolicy-Value DuplicatePolicyName and QueryError) or a successfulaction that is it has been performed satisfactorily (EmptyOf-ferSeq and NotEmptyOfferSeq)

Definition 3 (relation of request) Given a query form conceptF a policy sequence concept Y and a query action Q arelation of request is defined asR sube (F timesQ) cup (F timesQ timesY)

The purpose of the relation of request is to define therelationships that exist between concepts (setC) and actions(setA)

Definition 4 (relation of response) Given an input queryactionQ a returned message predicateM and an offer sequ-ence O a relation of request is defined as R a relation ofresponseR sube (Q timesM) cup (Q timesM times O) cup (Q timesM times O times O)

Finally there could be relationships between ldquoActionsrdquoand ldquoConceptsrdquo between ldquoPredicatesrdquo and ldquoActionsrdquo or evenbetween the pair ldquoPredicatesrdquo and ldquoConceptsrdquo

Definition 5 (ontology uses) Let us assume a given queryQ amessageM an offer sequenceO and an offer sequencematchO The uses of the ontology are defined in these three ways

(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902

(b) (119876 times 119872 times 119874) rarr 119872 =NotEmptyOfferSeq(c) (Q timesM times O times O) rarr 119872 =NotEmptyOfferSeq

6 Implementation andExperimental Scenarios

To evaluate the proposal a specific environment was devel-oped for experimentation which is available at the websitehttptkrsualesSKRS Several differentOntoTrader tradingservice functionality tests can be carried out in this envi-ronment Behind it the objects which comprise the Onto-Trader system have been implemented by agents using theJADE platform Three test cases one corresponding to eachof the three possible scenarios (reflection delegation andfederation) were prepared Below we explain some details ofOntoTrader implementation the framework of experimenta-tion and testing and the three case studies implemented

61 Implementation For design reasons the three basicOntoTrader model levels ltITDgt were implemented byagents The interface (I) was implemented by two agents theInterface Agent and the IMI Agent The trading level(T) was implemented by another two agents Query Agentand Trading Agent The data level (D) was implementedby a Resource Agent

The Interface Agent is the agent in charge of receiv-ing the queries from the user over the user interface transfer-ring them to the IMI Agent for management and returningthe result to the userThe IMI Agent acts like a hub betweenthe user interface and the rest of the modules and is respon-sible for managing user demands The Query Agents arein charge of solving the information queries demanded TheTrading Agents enable search and location of the informa-tion in the system and a filter based on the query parametersFinally the Resource Agents are responsible formanagingthe information bases

Figure 9 shows the multiagent architecture for theTrading-Based Knowledge Representation System designunder these premises As observed in the figure the infor-mation system may be distributed in different nodes each ofwhichmay be comprised of a series of agents according to theconfiguration desired As their basic configuration each nodemust have at least one set of interface agents (made up of oneor more agents) an IMI agent and a set of Query Agents (alsomade upof one ormore agents) Anodemay also contain zeroor more trading agents and resource agents but the system asawholemust have at least one agent of each type in some of itsnodes Let us further recall that the trading agents have anassociated repository (EID) which contains environmental


Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A

Lookup ont Lookup ont

Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont

agent agent agent agent1

agent 1

n

agent n

agent 1 agent n

agent 1 agent n agent 1 agent n

agent 1 agent n

agent 1 agent nQuery Query

Resource

Trading

Resource

Trading

1 nmiddot middot middot middot middot middot

middot middot middot






EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n

Figure 9 The general OntoTrader-based architecture

information metadata The resource agents also have associ-ated repositories with the original data sources containing theenvironmental information (EIM) The dashed lines in thedrawing represent the types of ontologies that intervene inagent communicationThere are three basic ontologies in oursystem Lookup Admin and Link In this paper we have onlydiscussed the Lookup ontology as an example of the processontologies The other two are outside the scope of this study

62 Test Scenarios Given the agent architecture a multitudeof scenarios could be suggested for processing a query madeby a user All the possible scenarios result in a combination ofthe threemain scenarios whichwe have identified and used toevaluate and validate the proposal

(a) Scenario number 1 (reflection)The user query can besolved directly by a trading agentwithout the action ofany of the resource agents

(b) Scenario number 2 (delegation) The user query can-not be solved directly by a trading agent and requiresthe action of one or more resource agents

(c) Scenario number 3 (federation) The user query canbe solved by a federated trading agent or other tradingagents withwithout the action of a resource agent

Figure 10 shows the three basic architectures definedwhere the number of agents that intervene in each scenariocan be seen The dashed lines show the order of the calls

between agentsThe diagram shows the QSRRmodel under-lying the OntoTrader model which was implemented as aprototype for testing and validating the web trader agentimplementation Keep this figure inmind during the descrip-tion of the three scenarios below

In general the sequence of the three models is very simi-lar as followsThe sequence beginswhen a userwrites a queryfrom the user interface The following section shows how aquery from the user interface is constructed Connected tothe interface is an interface agent which is in charge of trans-lating this query into the SPARQL query language The requ-ests that are sent between agents are constructed based onldquoQUERY-REFrdquo forms in which the query is embedded inSPARQL The results returned by the agents are constructedusing ldquoINFORM-REFrdquo forms We show some of these formsfurther below The interface agent transfers the query to theIMI agent which is in charge of deciding which query modelto follow (reflection delegation and federation) based on thetype of data in the queryThe IMI agent tells the Query Agentwhich path to take The tests for the three scenarios (threepaths) are shown below

621 Scenario Number 1 (Reflection) Figure 11 shows thesequence diagram for the reflection trading model This sce-nario takes place when there is a querywith the result that canbe directly found from the metadata stored in the tradingagentrsquos repository An example of a query in this scenariocould be ldquoFind the name of the soil science classification


Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2

Query 3Query 3 federation

8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C

BA IMI agentIMI agentIMI agent C

EID 005

EIM 003

EID 002

EIM 002

EID 001

Figure 10 The three main scenarios (reflection delegation and federation)

variables for the year 2008rdquo As mentioned we show furtherbelowhow a query is formed from the user interface (messagenumber 1 in Figure 10 and sequence number 3 in Figure 11)The interface agent translates this query into SPARQL(sequence number 2 in Figure 11) and generates a QUERY-REFmessage which it passes on to the IMI agent The messageform is as shown in Algorithm 1

A QUERY-REF form always has four basic clauses thesender clause (line number 2) where the name of the agentsending the message is given (in our case in the implemen-tation the interface agent is called WIAgent and it residesin the SOLERES-KRS workspace) the receiver clause(line number 4) where the name of the agent that receives themessage is given (in this case IMIAgent) and the contentclause which contains the content of the message Observehow the query is made in SPARQL in the message content(lines number 7 to number 20) Finally the languageclause is where the type of language used to write themessagecontent is given In this case it indicates that the content iswritten in SPARQL

When the IMI agent interprets the query it detects aquery that can be solved directly by the trader (reflectionmodel)The IMI analyzes the query sentence and the types ofmetadata in the trader repository to determine whether thequery can be solved directly by the trader If so it resends thisrequest to a Query Agent In the case of the example above

(Scenario 1) all the types of data in the query are available inthe trader The message to the Query Agent is as shown inAlgorithm 2 (message number 2 in Figure 10 sequence num-ber 5 in Figure 11)

Certain parts of the message have been omitted to reduceits length in this paperTheOWLontology is used towrite thecontent of this message (RDF notation lines number 2 tonumber 11) The argument in the content clause is a doc-ument in RDF Specifically the Lookup ontology is used forthis type of request between agents The message makes useof the ldquoconceptactionrdquo pair in the ontology to formulate thequery Specifically the concept QueryForm (lines number 2to number 11) where the query (generated in SPARQL) andthe action to be performed Query are specified (line num-ber 10) is used Observe how the concept and action weredefined in the ontology in Figure 7 The previous message(Algorithm 2) as in the language clause gives the type ofontology used (line number 12) The new ontology clausegives the path where the ontology is found

When theQueryAgent receives thismessage it infers thatthis query can be solved directly by the trading agent andgenerates a new QUERY-REF message similar to the onebefore again using the Lookup ontology (sequence number6) and sends it to the trading agent which launches thesparql query to its repository (sequence number 9) obtain-ing results These results are returned to the Query Agent


sd scenario 1

15 buildResultsMessage()

13 buildQueryOntology()


1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()

2 query2SPARQL(query)

User

EID OWLRepository TradingAgent QueryAgent IMIAgent InterfaceAgent

10 owl results

Figure 11 Sequence diagram for Scenario number 1 (reflection)

constructing an INFORM-REF form in this case as shown inAlgorithm 3 (message number 4 sequence number 12)

The ontology series ldquoconceptactionpredicaterdquo is used toconstruct this message The concept OfferSeq (lines num-ber 4 to number 24) in the Lookup ontology shows the resultsfound after processing the query The action Query (linenumber 26) and the predicate NotEmptyOfferSeq (linenumber 25) show that the query returns a result all of themin the Lookup ontology If the query should not return anyresult or if there were an error in the message constructedthe predicate EmptyOfferSeq or some predicates in theontology indicating error would be used instead of theconcept OfferSeq respectively

Then when the Query Agent receives the results from thetrading agent it transfers them directly to the IMI agentconstructing a new INFORM-REF form with the headingssender and receiver (message number 5 sequence num-ber 14) The IMI agent performs the same operation in

turn constructing its return form for the interface agent(message number 6 sequence number 16) which decodes themessage and shows the results on the user interface thusending the trading reflection sequence in Scenario number1

622 Scenario Number 2 (Delegation) Figure 12 shows thesequence diagram for thedelegation trading model In thisscenario the user query cannot be solved directly by a tradingagent and requires the action of one or more resource agentsto complete it A possible query that would enter in thisscenario could be ldquoFind the minimum value of variable X usedin information layer Yrdquo In this case the result cannot be founddirectly in the meta-metadata that the trading agent stores inits repository and the metadata in the resource agent must bequeried

Itmay be observed that the interface agent IMI agent andQueryAgent sequence are the same as for reflection (Scenario


sd scenario 2





18 query(sparql)

21 send(message6) 20 buildQueryOntology()

17 extractSPARQL(message5)16 send(message5)

1 makeQuery()

27 showResults()

10 query(sparql)


9 extractSPARQL(message3)

8 send(message3)

23 send(message7)

6 split(query)

14 extractResources(eid_results)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


EIM OWLRepository ResourceAgent

User


19 eim results

11 eid results

Figure 12 Sequence diagram for Scenario number 2 (delegation)

number 1) In this case the above query generates the text inSPARQL shown in Algorithm 4 which is transmitted onQUERY-REF forms (for the sake of simplicity only theSPARQL query is shown) (see Algorithm 4)

In this example the variable X remains on the user inter-face as variable ldquoE6rdquo and layer Y is given as ldquoEdaphic sectorsrdquoWhen the form gets to Query Agent (sequence number 5 inFigure 12) it infers that the type of query is by delegationandmakes a split (sequence number 6) to prepare a doublequery The first is the original query which continues itscourse to the trading agent (sequence number 8) After query-ing its associated EID repository the trading agent returnsa message (Algorithm 5) to the Query (sequence number 13in the sequence diagram of the Scenario 2 (see Figure 12))

Thismessage states that the trader has found variable ldquoE6rdquoin its repository in document ldquoEIM 0000000003rdquo coded asldquoVAR 0000000202rdquo Notice that ldquoEIM 0000000003rdquo is a

metadata (ie it resides in the traderrsquos EID repository) of anEIM resource found in a resource agent repositoryThis mes-sage is received by the Query Agent which generates a newmessage using the Lookup Ontology and applying a filter tothe original SPARQL query with the data found in the lastquery (previous message) Specifically the results are filteredfor those documents that contain the variable called ldquoVAR0000000202rdquo This message is sent to the resource agent so itcan complete the query by applying this filter The new mes-sage (with the filter) is as shown in Algorithm 6

Finally the sequence ends by returning the resultsbetween agents until arriving at the interface agent which isin charge of displaying the results on the user interface

623 Scenario Number 3 (Federation) As mentioned thefederation-based model arises when the system has beenconfigured for the trader to propagate the query to a second


10 owl results

16 owl results

sd scenario 3




19 process(message5)

18 send(message5)17 buildQueryOntology()

15 query(sparql)14 extractSPARQL()

12 buildQueryOntology()13 send(message4)

11 process(owl_results)

EID2 OWLRepositoryt2 TradingAgent

1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


UserEID1 OWLRepositoryt1 TradingAgent QueryAgent IMIAgent InterfaceAgent

Figure 13 Sequence diagram for Scenario number 3 (federation)

federated trader if the query could not be satisfied bythe first In this model several different combinations arepossible One situation is that the second trader can satisfythe query directly in what is known as a case of ldquoreflexivefederationrdquo that is a federation model on the first trader andin continuation reflection on the second Another situationappears when the second trader redirects the query to adata resource (resource agent) For this case a ldquodelegatedfederationrdquo appears that is federation on the first trader andthen delegation to the resource There could also be a case ofldquomultiple federationrdquo where the system has been configuredfor queries to be propagated among federated traders if theycannot be satisfied

Figure 13 shows the sequence diagram that follows thefederation-based trading model For the sake of simplifica-tion the diagram presents a case of ldquoreflexive federationrdquo

The functioning for the rest of the possible combinations issimilar

One possible query in this scenario could be the follow-ing ldquoFind the identifier of the classifications of city X in whichthere is information on variable V1 and variable V2rdquo Fromthe type of query the data may be found in the metadataof a trading repository For this example we assume thatVariable V1 is a metadatum in the repository of one traderand Variable 2 is in the repository of another

In the example of the query above the following sentenceis generated in SPARQL The sequence of the QUERY-REFcalls and their corresponding INFORM-REF among the sys-tem agents is similar to those explained in the scenarios above(see Algorithm 7)

63 Experimentation Environment As mentioned to evalu-ate the proposal a specific experimental prototype was


Figure 14 A part of the System Query window in the test environment

Figure 15 Trace of messages sent between agents after the query

developed for testing The three scenarios posed in thesection above can be put into practice at the test web-site httptkrsualesSKRS Figure 14 shows a portion ofthe window of this test scenarioThis website consists of threebasic sections the ldquoSystem Queryrdquo which contains a seriesof system capabilities with a basic list of preset queries theldquoComplex Queryrdquo section where any type of complex query

can be constructed and the ldquoGraphicrdquo section where theinformation repositories used can be displayed graphically asa tree

The preset queries section ldquoSystem Queryrdquo is divided inhalf vertically into two zones (Figure 14) On the left the userhas a list of capabilities that represent basic system queriesWhen one of them is selected a menu drops down with the


Figure 16 A portion of the Complex Query window in the test environment

TKRS definition

Agents Trading Ontologies

JADE platform ODP specification

Agent implementation Trading implementation Ontology implementation

TKRS implementation

Query interface Pellet

Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e

Figure 17 OntoTrader restrictions for TKRS validation

parameters that must be entered before it can be executed Inthe example in the figure the user wants to know the namesof the classification variables used in the information layerldquoClimate sectorsrdquo in the cities of ldquoGranada and Almeriardquo

After executing the query in the right-hand part of thewindow certain information appears which is organized inturn in other three sections On one hand the result of thequery is shown in XML format (ldquoResultrdquo tab) From this zoneit can be checked whether the result returned by the system iswell constructed by making use of a standard external (third-party) tool which does not belong to the system calledldquoPelletrdquo Another capability enables the query made to be

displayed in SPARQL In order to validate the implemen-tation we have included a third capability which makes itpossible to trace the messages exchanged by the different sys-tem agents The traces of the messages exchanged amongsystem agents after executing the query above are shown intheldquoTracerdquo tab (see Figure 15) These traces can be foldedup or dropped down to facilitate supervision and check-ing of the messages generated in the query sequence Thefigure shows the QUERY-REFmessage which was generatedand transmitted from the interface agent to the IMI agent It isalso possible to observe the SPARQL sentence generated inthis message


(01) (QUERY-REF(02) sender (agent-identifiername WIAgentSOLERES-KRS(03) addresses (sequence http))(04) receiver (set (agent-identifier(05) name IMIAgentSOLERES-KRS ))(06) content ldquoPREFIX eid httpacgualessolerestestsEIDOntologyowl(07) PREFIX rdf httpwwww3org19990222-rdf-syntax-ns(08) SELSCT DISTINCT EID VariableName

(09) WHERE

(10) EID EID eidEID eimId EID EID eimID(11) EID EID eidEID hasClassification EID Classification(12) EID Classification eidClassification hasLayer EID Layer(13) EID Layer eidLayer hasVariable EID Variable(14) EID Variable eidVariable name EID VariableName(15) EID Classification eidClassification hasTime EID Time(16) EID Time eidTime year eid timeyear(17) filter (eid TimeYear = 2008)(18)

(19) ORDER BY ASC(EID VariableName)(20) language SPARQL)

Algorithm 1

(01) (QUERY-REFsender receiver

(02) content ldquoltrdfRDFxmlnsrdf= ldquohttpwwww3org19990222-rdf-syntax-nsrdquo (03) ltowlOntology rdfabout=ldquohttpacgualessolerestestsLookupOntologyowlrdquogt(04)

(05) ltQueryForm rdfabout =ldquohttpacgualessolerestestsLookupOntologyowlQueryFormInstance10158401015840 gt(06) ltqueryString rdfdatatype=ldquohttpwwww3org2001XMLSchemastringrdquo gt(07) here the SPARQL sentence

(08) ltqueryStringgt(09) ltQueryFormgt(10) ltQuery rdfabout=ldquohttpacgualessolerestestsLookupOntologyowlQyeryInstancerdquo(11) ltrdfRDFgtrdquo(12) language ldquoLookupOntologyrdquo(13) ontology httpacgualessolerestestsLookupOntologyowl)

Algorithm 2

Any type of complex system query can be constructed inthe section ldquoComplex QueryrdquoThis section is also divided ver-tically into two parts (Figure 16) On the left the test repos-itory (on which the complex query will be executed) can beselected Any EIM or EID repository in the test environmentcan be selected or else the URLwhere the repository is foundcan be specified On the right the query can be constructedfrom the ldquoQueryrdquo tab by selecting the fields and criteria forthe query and specifying their values When constructing thequery the attributes to be selected can be incorporated ineither the SELECT or the WHERE part of the query All theproperties selected are incorporated in the SELECT part ofthe query When the option marked is related to theWHEREpart of the query and one of the attributes in the list on theleft has been selected the option to select one of theoperators for filtering the condition to be set appears on thequery interface When the operator has been selected it isadded to the tree on the right where the query is saved andthen the value to be checked must be entered for the

WHERE clause filter Additional insertionOf (AND) andor unionOf (OR) type conditions may also be added Oncethe query is executed the result of its execution appears onthe ldquoResultrdquo sheet as shown in XML

The section ldquoGraphicsrdquo of the website enables graphicaldisplay of the information repositories A basic repository ofthe systemmay be displayed or it is also possible to introducea URL where an external repository is located On the right-hand side of the window an ldquoappletrdquo draws its contentgraphicallyThis ldquoappletrdquo can also make searches for conceptsin the data ontology represented

7 Evaluation and ValidationFinal Considerations

For the validation of our environmental information systemthe starting point is establishing certain ldquocontractsrdquo or restric-tions to be evaluated in different areas of our framework


(01) (INFORM-REFsender receiver

(02) content ldquoltrdfRDFxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquo (03) ltowlOntologyrdfabout=ldquohttpacgualessolerestestsLookupOntologyowlrdquogt

(04) ltOfferSeq rdfabout=ldquohttpacgualessolerestestsLookupOntologyowlOfferSeqInstancerdquogt(05) ltresultString rdfdatatype=ldquohttpwwww3org2001XMLSchemastringrdquo gt(06) ltxml version = ldquo10 rdquo gt

(07) ltsparql xmlns=ldquohttpwwww3org2005sparql-resltsrdquo(08) ltheadgt ltvariable name=ldquoEID VariableNamerdquogt ltheadgt(09) ltresultsgt

(10) ltresultgt

(11) ltbinding name=ldquoEID VariableNamerdquo gt(12) ltliteral datatype=ldquohttpwwww3org2001XMLSchemastringrdquo gtC1ltliteralgt(13) ltbindinggt(14) ltresultgt(15) ltresultgt

(16) ltbinding name=ldquoEID VariableNamerdquo gt(17) ltliteral datatype= ldquohttpwwww3org2001XMLSchemastringrdquo gtC1L1ltliteralgt(18) ltbindinggt(19) ltresultgt(20)

(21) ltresultsgt(22) ltsparqlgt(23) ltresutStringgt(24) ltOfferSeqgt(25) ltNotEmptyOfferSeq rdfabout=ldquohttp LookupOntologyowlNotEmptyOfferSeqInstancerdquogt(26) ltQuery rdfabout=ldquohttpacgualessolerestestsLookupOntologyowlQueryInstancerdquogt(27) ltrdfRDFgtrdquo(28) language ldquoLookupOntologyrdquo(29) ontology httpacgualessolerestestsLookupOntologyowl)

Algorithm 3

(01) PREFIX eid lthttpacgualessolerestestsEIDOntologyowlgt(02) PREFIX rdf lthttpwwww3org19990222-rdf-syntax-nsgt(03) SELECT DISTINCT EID EID eimID EID VariableId

(04) WHERE

(05) EID EID eid EID eimId EID EID eimID(06) EID EID eid EID hasClassification EID Classification(07) EID Classification eid Classification hasLayer EID Layer(08) EID Layer eidLayer name EID LayerName(09) EID Layer eidLayer hasVariable EID Variable(10) EID Variable eidVariable id EID VariableId(11) EID VariableeidVariable name EID VariableName(12) FILTER (regex(EID LayerName ldquoEdaphic sectorsrdquo))(13) FILTER (regex(EID VariableName ldquoE6rdquo))(14) (15) ORDER BY ASC(EID EID eimID)

Algorithm 4

Figure 17 shows a summary of the steps in developing theTKRS (Trading-based Knowledge Representation System)The three main features of the TKRS are trading softwareagents and the ontologies

Each of these features has a series of restrictions thatmakeit possible for the system implemented to function as desired(validation) In the case of the trading function a trader wasdesigned and implemented following the standard RM-ODPspecification which enabled us to develop a trading system

with the functions we required properly The ODP tradingstandard was described in Section 23

Several different system objects (including the trader)were implemented as software agents using the JADE plat-form which enabled us to validate their behavior as well astheir proper functioning Furthermore JADE is an imple-mentation framework that complies with the FIPA (FIPAhttpwwwfipaorg) (Foundation for Intelligent PhysicalAgents) specification FIPA is an IEEE Computer Society


(01) (INFORM-REF sender receiver content rdquo (02) ltOfferSeq gt

(03) ltresultString rdfdatatype=ldquohttpwwww3org2001XMLSchemastring10158401015840 gt(04) ltxml version = ldquo10 rdquo gt

(05) ltsparql xmlns=ldquohttpwwww3org2005sparql-results10158401015840 gt(06) ltheadgt

(07) ltvariable name=ldquoEID EID eimIDrdquogt(08) ltvariable name=ldquoEID variableIdrdquogt(09) ltheadgt(10) ltresultsgt

(11) ltresultgt

(12) ltbinding name=ldquoEID EID eimIDrdquogt(13) ltliteral datatype=ldquohttpwwww3org2001XMLSchemastringrdquo gtEIM 0000000003ltliteralgt(15) ltbindinggt(16) ltbinding name=ldquoEID variableIdrdquo gt(17) ltliteral datatype=ldquohttpwwww3org2001XMLSchemastringrdquo gtVAR 0000000202ltliteralgt(18) ltbindinggt(19) ltresultgt(20) ltresultsgt(21) ltsparqlgt(22) ltresultStringgt(23) language ldquoLookupOntologyrdquo(24) ontology httpacgualessolerestestsLookupOntologyowl)

Algorithm 5

(01) (QUERY-REFsender receiver content rdquo (02) ltQueryForm rdfabout=ldquohttpacgualessolerestestsLookupOntologyowlQueryFormInstancerdquo gt(03) ltqueryString rdfdatatype=ldquohttpwwww3org2001XMLSchemastringrdquo gt(04) PREFIX eim lthttpacgualessolerestestsEIMOntologyowlgt(05) PREFIX rdf lthttpwwww3org19990222-rdf-syntax-nsgt(06) SELECT DISTINCT EIM VarMin

(07) WHERE

(08) EIM Var eimVariable id EIM VarId(09) EIM Var eimVariable name EIM VariableName(10) EIM Var eimVariable minimumValue EIM VarMin(11) FILTER (EIM VarId = ldquoVAR 0000000202rdquo)(12)

(13) ltqueryStringgt(14) ltQueryFormgt(15) ltQyery rdfabout=ldquohttpacgualessolerestestsLookupOntologyowlQueryInstancerdquogt(16)ltrdfRDFgtrdquo(17) language ldquoLookupOntologyrdquo(18) ontology http testsLookupOntologyowl)

Algorithm 6

Standards organization that promotes agent-based technol-ogy and the interoperability of its standards with other tech-nologies

Besides the trading and software agentsmentioned abovethe third key feature in the development of the TKRS is theontologies (see Section 4 for further details) Their design isassumed to be correct for two reasons (1) the process onto-logies were developed with the JADE specification for mess-ages exchanged by agents and under the trader ODP inter-face specification and (2) the data ontologies were foundfrom questionnaires filled out by the experts who made thedata classification in the framework of the national project

this research a part of [4] Based on this design premise itwas implemented using the Protege (Protege httpprotegestanfordedu) tool a standard ontologies tool andwith this tool we were able to verify that the implementationof the ontologies is correct

When the TKRS system had been implemented a seriesof ldquocontractsrdquo or restrictions were placed on data input andoutput (Figure 17) The restrictions on input enabled us toverify that the queries executed in the system are properlyconstructed queries that can be translated correctly intoSPARQL and can be correctly launched in TKRS Theserestrictions were made using a query interface which guided


(01) PREFIX rdf lthttp 0222-rdf-syntax-nsgt(02) SELECT DISTINCT EID ClassificationId

(03) WHERE

(04) EID EID eidEID eimId EID EID eimID(05) EID EID eidEID hasClassification EID Classification(06) EID ClassificationeidClassification id EID ClassificationId(07) EID Classification eidClassification hasGeography EID Geography(08) EID Geography eidGeography townsEID GeographyTown(09) EID Classification eidClassification hasLayer EID Layer(10) EID Layer eidLayer hasVariable EID Variable(11) EID Variable eidVariable name EID VariableName(12) EID Variable eidVariable id EID VariableId(13) FILTER (regex(EID GeographyTown ldquoGranada and Almeriardquo))(14) FILTER (regex(EID VariableName ldquoand Crdquo) || regex(EID VariableName ldquoand Erdquo))(15) (16) ORDER BY ASC(EID ClassificationId)

Algorithm 7

us in constructing executable system data queries Thiscan be checked on the website test environment speciallydeveloped for validating and evaluating the proposalhttptkrsualesSKRS

Finally once the results of the queries have been returnedby the TKRS another feature of the system is in charge ofchecking that the data obtained are correct This feature is anexternal check (Pellet) to which our data ontology and theSPARQL query made are sent as parameters obtaining as aresult the data that must be returned to the query It alsochecks the validity of the ontology warning if there is any typeof error in it TKRS implementation was checked with thesefive system features (marked in Figure 17 with a double box)and the functioning of the QSRR data recovery model pro-posed was validated

Furthermore several sample scenarios were developedwhere the different types of query that can be executed weretested In addition a tool with which several evaluation andvalidation tests predefined systemqueries generic queries onsystem documents display of the system document ontolo-gies and so forth can bemade was developed and is availableon the web The tool has a mechanism for agent messagetraceability and can check and validate their functioning andproper implementation The link to this tool is included inthe paper so anyone can make the pertinent validation andevaluation tests For the time being these information ret-rieval (IR) evaluation techniques only examine whetherinformation retrieval is done correctly and that the data arewhat was asked for

8 Conclusions and Future Work

Modern information systems are increasingly required toprovide support for users who are in different places and havedifferent types of data facilitating access to informationdecision-making workgroups and so forth DistributedInformation Systems (DIS) appear to provide the answerto these new requirements [37] Web-based Information

Systems (WIS) [2] for instance are developed under opendistributed paradigmsThis involves the use of rules and stan-dards for their construction and real time operation interac-tion and interconnection In this kind of system interactionsare between system ldquoagentsrdquo (eg web components subsys-tems and humans) working in the same ambient (computingspace) or even with other third-party ldquoagentsrdquo In both casesthe knowledge semantics for managing each part (ie soft-ware agent in our case) of the systemmust be formally defined[38]

EMIS a type ofWIS have been under development in thelast few years [3] The EMIS are social and technical systemswith a variety of final users and actors (ie politicians tech-nicians and administrators) who cooperate with each otherand interact with the system for decision making problemsolving and so forth Today web-based EMIS greatly facili-tate information search and retrieval favoring user cooper-ation and decision making Their design requires the use ofstandardized methods and techniques that provide a com-mon vocabulary to represent the knowledge in the systemanda capability for mediation to allow interaction (communi-cation negotiation coordination etc) of its componentsOntologies are able to provide that shared vocabulary andtrading systems can improve the interoperability of opendistributed system components

The present paper showed how traditional traders prop-erly extended to operate inWIS are a good solution for infor-mation retrieval An example of web-based EMIS is the SOL-ERES system a spatiotemporal environmental managementsystem based on neural networks agents and software com-ponents [4] In this paper we have reviewed the most impor-tant EMIS in the literature and have compared them espe-cially their agent trader and ontology features We have alsointroduced ontological web trading (OntoTrader) an exten-sion of the traditional OMG trading service to support onto-logical information retrieval issues on web-based EMIS Thepaper also presents three trading models for ldquoinformationretrievalrdquo trading reflection trading delegation and tradingfederation


We have also shown an OntoTrader model implemen-tation using software agent-based approaches This kind ofweb service is a search service based on a ldquoQuery-SearchingRecovering-Responserdquo web model using the SPARQL querylanguage and the OntoTrader ontology description languagefor information retrieval This service is based on a userrequest action that identifies the agents involved and theircommunication protocols Ontologies are used in two differ-ent contexts (a) to represent the application domain infor-mation itself (data ontology) and (b) the services that someagents request from others during their interaction (processontology) In this paper we have described the process anddata ontology design features of the Lookup trader interfaceAll research work presented in this paper was part ofthe complete Ontology-Driven Software Engineering (ODSE)design strategy we are now developing in SOLERES Imple-mentation details and a prototype ofOntoTrader are availableat httptkrsualesSKRS

Future work will focus on several open lines of researchOn one hand we are studying the possibility of grouping allontology management under a single agent (ontology agent)This agent would manage a database with all the ontologiesused in the system and would codedecode themThis wouldconsiderably simplify the implementation of other agents andwould providemore efficientmanagement Our work regard-ing the implementation of SOLERES-HCI (human-computerinteraction) is also ongoing This level of the EMIS isdefined by means of the Computer Supported CooperativeWork (CSCW) paradigm [39] and implemented by using aninnovative technology of intelligent agents and multiagentarchitectures Furthermore we continue working on thissubsystem which is described throughout the paper and weare studying how to decompose the user tasks into actionsthat will have to be performed by the SOLERES-KRS sub-system for retrieval of the information requested and theontology mapping problems involved

In literature review there are no approaches with enoughsimilarities to make an empirical comparison between ourprocesses and other existing algorithms However we intendto add some experimental comparisons with some isolatedparts of other works in order to highlight the advantages ofour proposal Finally we would like to study develop andincorporate new evaluation and validation techniques suchas measuring the precision of data returned to queriesresponse time in executing the query and usability

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

This work was funded by the EU ERDF and the SpanishMin-istry of Economy and Competitiveness (MINECO) underProject no TIN2010-15588 the Spanish Ministry of Educa-tion Culture and Sport (MECD) under a FPU Grant no(AP2010-3259) and the Andalusian Regional Government(Spain) under Project no P10-TIC-6114

References

[1] M Xiao-feng X Bao-wen L Qing et al ldquoA survey of Webinformation technology and applicationrdquo Wuhan UniversityJournal of Natural Sciences vol 11 no 1 pp 1ndash5 2006

[2] D Taniar and J RahayuWeb Information Systems IGI Global2004

[3] O El-Gayar and B Fritz ldquoEnvironmental Management Infor-mation Systems (EMIS) for sustainable development a concep-tual overviewrdquo Communications of the Association for Informa-tion Systems vol 17 no 1 p 34 2006

[4] ACGCEG ldquoSOLERES Project a spatio-temporal environmen-tal management information system based on neural-networksagents and software componentsrdquo Tech Rep Applied Comput-ing Group (ACG) University of Almeria Almeria Spain 2010httpwwwualesacgsoleres

[5] S Mukherjee and I V Ramakrishnan ldquoAutomated semanticanalysis of schematic datardquoWorld Wide Web vol 11 no 4 pp427ndash464 2008

[6] M Huang ldquoA New Method to formal description of spatialontologyrdquo Information Technology and Environmental SystemSciences vol 3 pp 417ndash421 2008

[7] OMG ldquoTrading object service specicationrdquo Tech Rep 2001httpwwwomgorg

[8] M Leida P Ceravolo E Damiani Z Cui and A GusminildquoSemantics-aware matching strategy (SAMS) for the OntologymeDiated Data Integration (ODDI)rdquo International Journal ofKnowledge Engineering and SoftData Paradigms vol 2 no 1 pp33ndash56 2010

[9] D Goh and S Foo Social Information Retrieval Systems Emerg-ing Technologies and Applications for Searching the Web Effec-tively Idea Group Reference 2007

[10] J Gama and M May ldquoUbiquitous knowledge discoveryrdquo Intel-ligent Data Analysis vol 15 no 1 pp 1ndash2 2011

[11] A Carrillo-Ramos J Gensel M Villanova-Oliver and H Mar-tin ldquoAdapted information retrieval in web information systemsusing PUMASrdquo in Agent-Oriented Information Systems III vol3529 of Lecture Notes in Computer Science p 243 2006

[12] I Trader ldquoISOIEC DIS 13235-1 IT-Open Distributed Pro-cessing-ODP Trading Function-Part 1 Specificationrdquo 1996

[13] C-H Chang M Kayed M R Girgis and K F Shaalan ldquoA sur-vey of Web information extraction systemsrdquo IEEE Transactionson Knowledge and Data Engineering vol 18 no 10 pp 1411ndash1428 2006

[14] J A Asensio L Iribarne N Padilla and R Ayala ldquoImple-menting trading agents for adaptable and evolutive UI-COTScomponents architecturesrdquo in Proceedings of the InternationalConference on e-Business (ICE-B rsquo08) pp 259ndash262 Porto Por-tugal July 2008

[15] L Iribarne N Padilla J A Asensio et al ldquoOpen-environmentalontology modelingrdquo IEEE Transactions on Systems Man andCybernetics A vol 41 no 4 pp 730ndash745 2011

[16] N Padilla L Iribarne J Asensio F Munoz and R AyalaldquoModelling an environmental knowledge-representation sys-temrdquo in Proceedings of the 1st World Summit on The KnowledgeSociety Emerging Technologies and Information Systems for theKnowledge Society pp 70ndash78 2008

[17] L Iribarne J Asensio N Padilla andRAyala ldquoSOLERES-HCImodelling a human-computer interaction framework for openEMSrdquo inThe Open Knowledge Society A Computer Science andInformation Systems Manifesto FirstWorld Summit on the


Knowledge SocietyWsks 2008 Athens Greece September 24ndash26 2008 Proceedings pp 320ndash327 Springer 2008

[18] InfoSleuth ldquoThe infosleuth agent systemrdquo Tech Rep 2005http wwwargreenhousecomInfoSleuth

[19] EDEN-IW ldquoEnvironmental data exchange network for inlandwaterrdquo Tech Rep 2001 httpwwwedeniworg

[20] NZDIS ldquoNew zealand distributed information systems projectrdquoTech Rep 2001 httpnzdisotagoacnz

[21] S DanceMGorman L Padgham andMWinikoff ldquoAn evolv-ing multi agent system for meteorological alertsrdquo in Proceedingsof the 2nd International Joint Conference on Autonomous Agentsand Multiagent Systems (AAMAS rsquo03) pp 966ndash967 ACM July2003

[22] H Worn T Langle and M Albert ldquoMulti-agent architecturefor monitoring and diagnosing complex systemsrdquo in Proceed-ings of the 4th International Workshop on Computer Scienceand Information Technologies (CSIT rsquo02) University of PatrasGreece 2002

[23] M Albert T Langle and H Woern ldquoDevelopment tool fordistributed monitoring and diagnosis systemsrdquo Tech RepDefense Technical Information Center 2002

[24] T Vogele S Hubner and G Schuster ldquoBustermdashan informationbroker for the semantic webrdquo KI-Kunstliche Intelligenz vol 3no 3 pp 31ndash34 2003

[25] J Albrecht B Derman and L Ramasubramanian ldquoGeo-onto-logy tools the missing linkrdquo Transactions in GIS vol 12 no 4pp 409ndash424 2008

[26] D LMcGuinness R Fikes JHendler and LA Stein ldquoDAML+OIL an ontology language for the Semantic Webrdquo IEEE Intelli-gent Systems vol 17 no 5 pp 72ndash80 2002

[27] Y An and B Zhao ldquoGeo ontology design and comparison ingeographic information integrationrdquo in Proceedings of the 4thInternational Conference on Fuzzy Systems and Knowledge Dis-covery (FSKD rsquo07) pp 608ndash612 August 2007

[28] L Ceccaroni U Cortes andM Sanchez-Marre ldquoOntoWEDSSaugmenting environmental decision-support systems withontologiesrdquo Environmental Modelling and Software vol 19 no9 pp 785ndash797 2004

[29] VDi Lecce C Pasquale andV Piuri ldquoAbasic ontology formultiagent system communication in an environmental monitoringsystemrdquo in Proceedings of the IEEE International Conference onComputational Intelligence for Measurement Systems and Appli-cations (CIMSA rsquo04) pp 45ndash50 July 2004

[30] V Brilhante ldquoAnontology for quantities in ecologyrdquo inAdvancesin Artificial Intelligence-SBIA 2004 vol 3171 of Lecture Notes inComputer Science pp 144ndash153 2004

[31] Q Zhan D Li and Z Shao ldquoAn architecture for ontology-basedgeographic information semanticGrid servicerdquo inGeoinformat-ics 2007 Geospatial Information Technology and Applicationsvol 6754 of Proceedings of the SPIE Nanjing China May 2007

[32] J Song Y Zhu and J Wang ldquoA study of semantic retrieval sys-tem based on geo-ontology with spatiotemporal characteristicrdquoin Proceedings of the of International Symposium on DistributedComputing and Applications to Business Engineering and Sci-ence (DCABES rsquo07) vol I-II pp 1029ndash1034 2007

[33] J Shen A Krishna S Yuan K Cai and Y Qin ldquoA pragmaticGIS-oriented ontology for location based servicesrdquo in Pro-ceedings of the 19th Australian Software Engineering Conference(ASWEC rsquo08) pp 562ndash569 March 2008

[34] GMLOCG ldquoGeography markup languagerdquo Tech Rep OpenGeospatial Consortium 2007 httpwwwopengeospatialorgstandardsgml

[35] A Tripathi and H A Babaie ldquoDeveloping a modular hydro-geology ontology by extending the SWEET upper-level ontolo-giesrdquo Computers and Geosciences vol 34 no 9 pp 1022ndash10332008

[36] L Iribarne J M Troya and A Vallecillo ldquoA trading service forCOTS componentsrdquo Computer Journal vol 47 no 3 pp 342ndash357 2004

[37] D Mishra and A Mishra ldquoA review of non-technical issuesin global software developmentrdquo International Journal of Com-puter Applications in Technology vol 40 no 3 pp 216ndash224 2011

[38] M Russ and J Jones ldquoKnowledge-based strategies and informa-tion system technologies preliminary findingsrdquo InternationalJournal of Knowledge and Learning vol 2 no 1 pp 154ndash1792006

[39] P C Pendharkar ldquoThe theory and experiments of designingcooperative intelligent systemsrdquo Decision Support Systems vol43 no 3 pp 1014ndash1030 2007

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014


Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in



(eg ontologies) An example of web-based EMIS is theSOLERES system a spatiotemporal environmental manage-ment system based on neural networks agents and softwarecomponents [4]

An EMIS is an Information System supporting environ-mental management EMIS are a special case of GeographicInformation Systems (GIS) though the granularity of environ-mental information ismore specific (eg satellite and ecolog-ical information) Furthermore EMIS use a more advancedmore specific technology than geographic information sys-tems for instance we use neural networks multiagentssystems and cellular automata features

Two basic roles interact in WIS the Human and theComputer Due to the nature of these systems (open and dis-tributed) people organized in workgroups for decision mak-ing may be found in different places and be arranged bytheir profile (eg administrators politicians technicians andusers) This sort of interaction (Human-to-Human HH)requires unified protocol and communication policies for allparts of the system People and groups of people also interactthrough the system by using user interfaces (UI) which aregenerally well suited to their needs [5] This type of interac-tion (Human-to-Computer HC) also needs to establish com-munication protocols among users profiles groups and userinterface agents Finally these user interface agents act asmediators for people interacting with other system agentsThis interaction (Computer-to-Computer CC) requires com-munication protocol commonly known as choreography (ororchestration) All three of these types of interaction protocol(HH HC and CC) software have to know the knowledgesemantics that manages each part of the system (ie agents)

Mediators (commonly known as ldquotradersrdquo) enrich theinteroperability of web components working in a WISapproach [6 7] These traders have to operate with otherthird-party traders andor agents in the system which mustalso use a common vocabulary to allow communicationbetween themThe design of these components and the inter-action protocols (mentioned above) must use standardizedmethods and techniques that allow a common vocabularyrepresenting the underlying knowledge to be defined Onto-logies are used as a means to this goal [8]

On the other hand popularity of the WIS has led to anincreasing volume of information available in informationsystemsUsers depend on the web to meet their informationneeds through search engines portals digital libraries andother information retrieval systems [9 10] However infor-mation overload has led to a situation where users areswampedwith toomuch information and have to sift throughthe material in search of relevant content To address theseproblems a variety of techniques inherent in informationsearching drawing from the fields of information retrievalinformation filtering human-computer interaction and thestudy of information search behavior have been adopted intheWIS Information retrieval refers to techniques that assistusers in meeting their information needs [11]

ThemainWISinformation retrievalmechanism is the tra-ditionalQuery-SearchingRecovering-Response (QSRR)Thismechanism is based on the traditional clientserver modelOn one hand the term ldquoQueryrdquo refers to the whole process of

creating and formulating the clientrsquos questionThe term ldquoSea-rchingrdquo refers to the process of locating the repositories wherethe information is found and the term ldquoRecoveringrdquo refersto the process of locating identifying and selecting the datafrom the data sources (repositories data storage or databasesregardless of the model) Finally the term ldquoResponserdquo refersto the whole process of formulation preparation and cre-ation of the response by the server to the client The ldquoQuery-Searchingrdquo pair is a process that goes from the client to theserver The ldquoRecovering-Responserdquo pair goes from the serverto the client

UDDI (Universal Description Discovery and Integration)specification and WSDL (Web-Services Definition Language)for SOA (SOA httpwwwoasis-openorg) (ServiceOrientedArchitecture) are based on theseclientserver implementa-tions for web systems Nevertheless these techniques allowagents to respect a subscribepublishresponse model and aQSRR information retrieval approach for locating WSDLdocuments (ie XML specifications of web-services) andconnecting web services inWIS but not for different types ofinformation (non-WDSL information) Traders are anothersolution for open and distributed systems [12] that extendthe OMA (OMA httpwwwomgorg) (Object Manage-ment Architecture) ORB (Object-Request Broker) mechanismAlthough traders are traditionally used as middleware forobject interoperability they can easily be adapted for interop-erability of information and functionality In respect to thisthe use of functional ontologies in our work is a goodsolution for adapting traders to information retrieval inWISUser information retrieval is an emerging area and a promis-ing avenue for the design and implementation of a new gen-eration of information retrieval systems especially for newweb-based EMIS due to the particularity and complexity ofthe information and users (politicians technicians andadministrators) [13]

In a sense the SOLERES system (a spatiotemporal envi-ronmental management system based on neural networksagents and software components) our EMISmodel follows aWIS approach [14ndash17] In this paper we propose theOntolog-ical Web Trader (OntoTrader) as a mechanism for solving thecomplexity of information retrieval in the EMIS by means ofa trading model for WIS guided and managed by ontologiesThis kind of web service is a user-information search servicebased on a web QSRR model Therefore OntoTrader is anew information retrieval mechanism that implements a QSRR model and uses the SPARQL query language and theOWL ontology description language to operate This serviceis based on a user request action that identifies the agentsinvolved and their communication protocols In our systemthe ontologies are used in two different contexts (a) they rep-resent the application domain information itself and (b) theservices that some agents request from others during theirinteraction Although a trader agent has five interfaces (ieLookup Register Link Proxy and Admin) this paper dis-cusses only the behavioral and data ontology design featuresof the Lookup trader interface which is used for searchingand recovering user information in a QSRR model Allresearch work presented here is part of a complete designstrategy for Ontology-Driven Software Engineering (ODSE)that we are developing in SOLERES



2 EMIS Technology




















4 invoke()

3 import()

2 query()

1 export()






















SOLERES


HCI system



≪Agent≫


≪Agent≫

≪Agent≫

Interface UI

EMS

HCI

CSCWUses

Has Has

SOLERES-KRS

IMI



EID


1

1


Lookup



≪Interface≫Link


Communication

Parser



External DB

1 1

Uses

Uses


1lowast

1lowast

1lowast

1lowast

1lowast

≪Protocol≫

≪Protocol≫







User

Internet


Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent


≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫


≪Agent≫











Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





2 EMIS Technology




















4 invoke()

3 import()

2 query()

1 export()






















SOLERES


HCI system



≪Agent≫


≪Agent≫

≪Agent≫

Interface UI

EMS

HCI

CSCWUses

Has Has

SOLERES-KRS

IMI



EID


1

1


Lookup



≪Interface≫Link


Communication

Parser



External DB

1 1

Uses

Uses


1lowast

1lowast

1lowast

1lowast

1lowast

≪Protocol≫

≪Protocol≫







User

Internet


Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent


≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫


≪Agent≫











Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in













4 invoke()

3 import()

2 query()

1 export()






















SOLERES


HCI system



≪Agent≫


≪Agent≫

≪Agent≫

Interface UI

EMS

HCI

CSCWUses

Has Has

SOLERES-KRS

IMI



EID


1

1


Lookup



≪Interface≫Link


Communication

Parser



External DB

1 1

Uses

Uses


1lowast

1lowast

1lowast

1lowast

1lowast

≪Protocol≫

≪Protocol≫







User

Internet


Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent


≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫


≪Agent≫











Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in



















SOLERES


HCI system



≪Agent≫


≪Agent≫

≪Agent≫

Interface UI

EMS

HCI

CSCWUses

Has Has

SOLERES-KRS

IMI



EID


1

1


Lookup



≪Interface≫Link


Communication

Parser



External DB

1 1

Uses

Uses


1lowast

1lowast

1lowast

1lowast

1lowast

≪Protocol≫

≪Protocol≫







User

Internet


Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent


≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫


≪Agent≫











Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




SOLERES


HCI system



≪Agent≫


≪Agent≫

≪Agent≫

Interface UI

EMS

HCI

CSCWUses

Has Has

SOLERES-KRS

IMI



EID


1

1


Lookup



≪Interface≫Link


Communication

Parser



External DB

1 1

Uses

Uses


1lowast

1lowast

1lowast

1lowast

1lowast

≪Protocol≫

≪Protocol≫







User

Internet


Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent


≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫


≪Agent≫











Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




User

Internet


Searchingfiltering

Information agent

Query Response

Organization

(a) QSRR model view

Web trading agent


≪Interface≫

≪Interface≫

≪Interface≫

≪Interface≫

Lookup

Register

Admin

Link

Proxy

Communication

Parser


1

Interface

CSCW user

≪Agent≫


≪Agent≫











Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Classification


Variable Band

1 1

1

Or

Satellite image


1lowast

1lowast

1lowast

1lowast

1lowast

lowast


Classification

Time

Technician










Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Satellite_image

Band

Classification

Geography Layer

Variable

























OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





OfferSeq

Query


-ValuePolicy




OfferSeqmatch




-Value boolean

1

1

1

1

1

01

1

1

1

1

1

01

1

1

1

1

1

1

1

1

1

1


1lowast

lowast














1 L2 and L




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




I

D

T T

I

D

T T

I

D

T T




L1

L2

L3



















119891= LEDKX









RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in






RR consisting of
















(a) (119876 times 119872) rarr 119872 = 119880119899119896119899119900119908119899119876119906119890119903119910119865119900119903119898

or 119875119900119897119894119888119910119879119910119901119890119872119894119904119898119886119905119888ℎ or 119868119899V119886119897119894119889119875119900119897119894119888119910119881119886119897119906119890or 119863119906119901119897119894119888119886119905119890119875119900119897119894119888119910119873119886119898119890 or 119876119906119890119903119910119864119903119903119900119903

or 119864119898119901119905119910119874119891119891119890119903119878119890119902








Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Interface

Query

IMI agent

Interface

Query

Lookup ont

HCI

KRS

Node A


Admin ont

Link ont

Look

upon

t

Admin ont

Link ont

Look

upon

t

Look

upon

tLo

okup

ont

Interface

Resource

IMI agent

Interface

Trading

Resource

Lookup ont

HCI

KRS


Admin ontLink ont

Look

upon

t

Admin ontLink ont

Look

upon

t

Look

upon

tLo

okup

ont

Node B

Trading

Lookup Ont


agent 1

n

agent n

agent 1 agent n


agent 1 agent n


Resource

Trading

Resource

Trading








EIM 1

EID 1

EIM 1

EID 1

EIM nEIM n

EID nEID n












Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Interface

Trader

Query

Resource

Interface

Trading

Query

Interface

Trader

Resource

1 6

2

3

4

5

1

2

3 4

5

6

7

8

Query

1

2

3

4

5

7

7

6

9

10

Node A

HCI HCI HCI

KRSKRSKRS

Node B Node C

Query 1Query 2


8

BA agentagentagent

Aagent

Aagent

Bagent

Bagent

Bagent

C

agent C

agent C

agent C


EID 005

EIM 003

EID 002

EIM 002

EID 001









sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




sd scenario 1




1 makeQuery()

18 showResults()

9 query(sparql)

12 send(message4)


8 extractSPARQL()

7 send(mesaage3)

14 send(message5)

5 send(message2)

16 send(message6)


3 send(message1)

17 showResults()


User


10 owl results









sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




sd scenario 2





18 query(sparql)



1 makeQuery()

27 showResults()

10 query(sparql)



8 send(message3)

23 send(message7)

6 split(query)


5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()



User


19 eim results

11 eid results









10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




10 owl results

16 owl results

sd scenario 3










1 makeQuery()

27 showResults()

9 query(sparql)


8 extractSPARQL()

7 send(message3)

23 send(message7)

5 send(message2)

25 send(message8)


3 send(message1)

26 showResults()


















TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in











TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





TKRS definition




TKRS implementation


Inputs Outputs

Agent design

Trading design

Ontology design

Query Query results

Prot eg e







(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





(09) WHERE



Algorithm 1





Algorithm 2











(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in








(10) ltresultgt




Algorithm 3


(04) WHERE


Algorithm 4










(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in








(11) ltresultgt


Algorithm 5


(07) WHERE



Algorithm 6







(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





(03) WHERE


Algorithm 7















Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in









Acknowledgments


References

















































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in


































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in










Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in



Documents

Research Article OntoTrader : An Ontological Web Trading Agent …downloads.hindawi.com/journals/tswj/2014/560296.pdf · 2019-07-31 · approach [ , ]. ese traders have to operate