IMAT: INTELLIGENT MOBILE AGENT

1st Houssein Dhayne 2nd Rima Kilany Chamoun 3rd Rami Abou Sabha
ESIB ESIB ESIB
Saint-Joseph University Saint-Joseph University Saint-Joseph University
Beirut, Lebanon Beirut, Lebanon Beirut, Lebanon
[email protected] [email protected] [email protected]

Abstract—With the evolution from a web of documents to a we need. Unfortunately, the project was discontinued. Making
web of data, it is important we change the way we search for effective use of RDF data published online (such as RDF
data among the huge amounts made available through social DBLP, DBpedia, FOAF profiles), through visual web-based
media, IoT devices, mobile devices, etc. A user should be able
to express what he is searching for, in natural language or and collaborative way. Tasks like joining and transforming
even through voice recognition, and be able to get the result fragmented or incomplete Data, dealing with different iden-
he is seeking for, even if his search involves data of different tifiers (URIs) used for the same entities, aligning ontologies,
nature and format: web pages, RSS feeds, RDF triples, web etc. can be executed without any custom programming.
services calls, sensors data, etc. Another fact to consider is that At the level of search engines, swoogle [3], Sindice [4],
Internet access is mainly done nowadays via mobile devices. In
this paper, we propose a framework to answer those challenges Falcons [5] and Omnity1 are semantically enabled search
by enabling the user to make a search from a Google-like simple engines that collect, index, and analyze Semantic Web docu-
interface, and thus create from his search keywords, an intelligent ments to provide search and querying mechanisms. As for the
personalized mashup, without needing any programming skills, Redlink Plugin2 , it aims to add semantic capabilities to Apache
and yet integrating calls to REST web services, RSS feeds, RDF Solr3 , by extracting named entities and facts during Solr
triples or any other data available on the web. In order to
achieve this goal, we designed an ontology that can hold the indexing. Furthermore, Google started using Hummingbird
description of any web resource, and implemented an automated search algorithm since August 30, 2013. At the heart of
service composition engine that takes advantage of this ontology. the Hummingbird algorithm lies the all-important concept of
The engine has two main execution phases: The startup phase, semantics, or meaning [6].
implemented for performance improvement, which scans the At the level of web services description, service annotations
semantically defined resources in order to create a HashMap
linking each output to one or more chains of potential matching are an essential element that enables tasks such as service
services. Matching services are services having an output linked discovery, composition and mediation [7]. The approaches for
by an inferred similarity to another service input. The processing semantically annotating services are OWL-S [8], WSMO [9],
phase, where a query analyzer inspects the ontology, and checks SAWSDL [10], and WSMO-Lite [11] for WSDL services, and
with Dbpedia and WordNet, in order to decompose the user MicroWSMO [12], and SA-REST [13] for RESTful services.
request into input and output parameters. A type-based score
model is used to decide which chain among the available chains Verborgh et al [14] presents a more complete survey of
to execute. The usefulness of our approach, was validated by semantic description of REST APIs and classifies the various
developing a mobile client application which was used to test the approaches.
implemented engine. Swagger4 , recently named as OpenAPI, is an open spec-
Index Terms—Internet resources; REST Web Services; Ontol- ification for describing REST APIs. The Swagger document
ogy & Semantic web; Services integration
specifies the list of resources that are available in the REST
API and the operations that can be called on those resources.
I. I NTRODUCTION JSON and YAML formats are also used to describe RESTful
Do you imagine yourself searching on the internet for an web services. All these formats are human and machine-
apartment to rent in Moscow, during the world cup, having a readable [15], but lack semantic annotation.
certain rental price within your budget, as well as having a With iMAT, the user can get access to whatever informa-
nearby park and mall, etc. How many searches you should tion he needs, without searching for it on the Internet, and
execute, how many pages you should read and analyze in combining numerous data to obtain the result. A semantic
order to finally combine the information about the location, mashup is built under the hood, in order to process the search
price, nearby commodities, etc. Mashups are among the most query and execute it. It encapsulates the search keywords
convenient ways to integrate heterogeneous resources and in with a semantic layer that allows to express the query in a
order to produce new, complex and enhanced functionali- high-level and abstract way, in order to select unambiguously
ties [1]. In fact, yahoo pipes [2] were created exactly for this 1 https://www.omnity.io/
purpose, mainly integrate RSS feeds, and many other elements 2 http://dev.redlink.io/plugins/solr/
from the web in order to generate a personalized mashup 3 http://lucene.apache.org/solr/

that can be executed any time to obtain the search results 4 http://swagger.io/
Fig. 1: iMAT ontology classes and defined services individu-
als. (b) iMAT object proper-
(a) isEquivalnt Object Property.
ties.

the corresponding Web APIs to call, and enable reasoning Fig. 2: The properties of the ontology
while composing them together. The SMART platform [16]
we implemented in a previous work, shares the same purpose
of the iMAT platform, but did not target mobile users, nor it file (Web Application Description Language). This file has a
tried to profit from external knowledge datasets as it is the fixed format: each service is composed of resources and each
case of iMAT, and as we will see all along this paper which resource can have different method calls.
is organized as follows: Section 2 details the ontology we Similarly to the information held in the WADL, we con-
defined for describing as a start, REST Web services. Section sidered that each service is composed of resources and each
3 details the internals of the iMAT platform. In Section 4 we resource can have different method calls, since a resource can
describe the mobile application simple search interface. Finally be invoked with different combinations of inputs (some of
conclusions and future work are given in Section 5. them are required and others optional).
We gave each parameter a label which is determined from
II. IMAT S EMANTIC R EST W EB S ERVICE D ESCRIPTION the WADL definition file in order to be used for the web
In this section, we begin by describing the logic behind the service invocation. Besides, a type provides the kind of data
semantic description we gave to a REST web service, and then (e.g. text, number, date,) that can be accepted by the parameter.
we detail all the classes and properties we needed to define The concept of the type provided will be suitable for matching
in order to complete this description. We used the Protégé the Input and Output parameter mechanism.
5.0.05 Ontology editor to accomplish this task, and named Furthermore, each parameter is associated with a noun that
our owl ontology file web ressources.owl, since the ultimate describes it in order to infer relations, as explained in the
goal of our work is to be able to integrate any web resource by previous section, via the ”isEquivalent” objectProperty (see
providing a semantic description that enables this integration. Fig. 2a).
Each service along with its resources, methods and pa- 1) iMAT Ontology classes:
rameters are represented by distinct classes in the ontology.
The boundary between these services is the input and output • Service: represents any RESTful web service.
parameters since information need to travel from the outputs • Resource: a resource associated to a REST service.
of one service to the inputs of another when they are mashed • MethodCall: Method invoked for a certain resource
up. In our model, we wanted to give each input and output (could be a POST, GET or any http verb).
an equivalent meaning related to the parameter name or to • Parameter: Root class of all parameters.
the information it represents. In order to deduce and infer • InputParam: A sub-class of ”Parameter” representing a
the connection between these parameters, a class Noun rep- service input.
resenting parameter nouns is defined. Relations (synonyms, • OutputParam: A sub-class of ”Parameter” representing a
sub-types) between the differently stored nouns and therefore service output.
between the parameters is done by querying the database of • Noun: Used to tag and describe parameters.
WordNet which enables us to associate nouns together via the 2) iMAT Ontology Object Properties: The ontology Object
objectProperty ”isRelatedTo” which has two sub-properties: Properties we defined are shown in Fig. 2b and detailed here
hasSynonym to describe synonym relations and isTypeOf to below:
define hypernyms. • hasInput: A property that associates a ”MethodCall” to
A. The ontology structure its inputs.
• hasOutput: A property that associates a ”MethodCall” to
The root of the ontology is the ”Thing class” from which
its outputs.
are derived all the classes used to describe our services (see
• hasMethodCall: Links a resource to its different methods.
Fig. 1). Each of our services is initially described by a WADL6
• hasResource: Links a service to its different resources.
5 https://protege.stanford.edu/ • isEquivalent: Used to describe a certain parameter with
6 https://www.w3.org/Submission/wadl/ the appropriate noun.
 • isInputTo: Inverse of ”hasInput”, it associates an ”Input-
Param” with its method.
• isOutputTo: Inverse of ”hasOutput”, it associates an ”Out-
putParam” with its method.
• isPartOfResource: Inverse of ”hasMethodCall”, it asso-
ciates a ”MethodCall” with its resource.
• isPartOfService: Inverse of ”hasResource”, it associates
a ”Resource” with its service.
• isRelated: The root property that associates nouns. Two
nouns are considered related if they are a synonyms or
one noun is a Hypernym of another noun.
• hasSynonym: Sub-property of ”isRelatedTo”. It tells if
two nouns are synonyms. It is transitive and reflexive. Fig. 3: iMAT architecture.
• isTypeOf: Sub-property of ”isRelatedTo”. Noun A is
”Type Of” noun B, if A is a hyponym of B or alternatively
B is a hypernym of A. It is transitive but not reflexive. iMAT architecture have been validated by the implementation
of a mobile application prototype we called ”MobileiMAT”
3) iMAT Ontology Datatype Properties: The only datatype
(cf. Section 4) which is the front-end part the user interacts
property used is called ”Label”. It is a string that labels
with.
parameters according to their names in the REST Web service
WADL description file, and used for the service invocation In order to process user’s requests, the service execution
in order to pass in the parameters. For example, the weather- engine tasks are mainly: analyzing the text request, finding
Longitude InputParam, was given the Label ”lng”. Therefore, the adequate services to execute, querying and mashing up
according to the relations between nouns used to describe those services in order to return the needed information to the
parameters of services we can determine which parameters are user. Fig. 3 shows the architecture of the platform.
compatible with each other and that the information obtained B. Core module algorithm
can be communicated between them.
4) iMAT Ontology service individuals: iMAT ontology The ”service execution engine” is also decomposed in two
defines 7 REST Web services (see Fig. 1) that are fully main modules (see Fig. 4):
described in the ”web ressources.owl”, by their corresponding • Ontology Chain Builder: which searches the Ontology
individuals. New web services could be added to the ontology to build a Hashmap that maps each output parameter
in order to enlarge the possibilities of user’s queries. to one or more chains of potential matching services.
When building the model for the ontology, it is important to Matching services are services having an output that
make sure that the services we include are decoupled as much matches another service input based on an inferred sim-
as possible in a way that the different combinations between ilarity relation.
them can cover many different cases. It is also recommended • Semantic Request Analyzer: which identifies the inputs
that these services be numerous, diverse and simple (direct and outputs parameters from the user query. A type-based
inputs and outputs).

III. T HE IMAT P LATFORME

A. IMAT Architecture
At a high level, iMAT defines an ontology of services, and
an execution engine that interacts with DBPedia, WordNet
and the ontology in order to discover and execute the REST
web services that the user needs to call. At the infrastructure
level, iMAT is mainly divided into two packages: the core
engine and the mobile app. The core engine contains all the
generic classes that could be used by any external applications
in order to interact with our ontology: all the classes that wrap
up the definition of a Service, its parameters, as well as the
classes that contain the service execution engine interacting
with the defined ontology. It also contains the main REST
service, wrapped up in a front-end servlet that takes as input a
phrase or expression and returns, in a JSON format, the results
gathered from different REST services described and saved in
the ontology. The choices we made at all the levels of the Fig. 4: Architectural design of the proposed algorithm.
 1) Ontology Analyzer (Module 1- Submodule 1): Querying
ontology is often time-consuming. Therefore, this submod-
ule prepares data in a manner that assists in the building
of M ap < O, C > by creating a broker map M ap <
O, M Hchy >, which facilitates matching between input and
output based on the ontology file. The entry of this submodule
(see procedure 1) is the ontology loaded from our owl file
”web resources.owl”. The result is a Hashmap denoted by
M ap < O, M Hchy >, which maps the output parameter Oi
as a key and its corresponding set of MatchingHierarchy as a
value (see Fig. 6). A MatchingHierarchy class is denoted by
M Hchyi < O, Mi , Im , M OU Tk > where:

Fig. 5: Hierarchy tree of a Chain. Procedure 1 Submodule Ontology Analyzer

Input: web resources.owl
Output: Map<OUT ,MHchy>
initialize an ontology model model
score model decides which chain is chosen among those initialize Hashmap M ap
defined in the previous step, in order to be executed. initialize List<MatchingHierarchy> M Hchyi
for Oi in OU T do
This decomposition facilitates the replacement of any of Mi ← getAllM ethodsHaveOutput(Oi )
for Mj in Mi do
these modules, as long as it operates using the same inter- INj ← getAllInputF orM ethod(Mj ) // INj be the set of
module APIs. input parameters of Mij
for Ik in INj do
M OU Tk = getAllM atching(Ik ) // using submodule-2
M Hchyi .add(Mj , INj , M OU Tk )
C. Ontology Chain Builder (Module 1) end
end
The goal of the engine is to find the most specific output // put Oi as a key and MHchyi as a value in the Map
M ap.put(Oi , M Hchyi )
parameter relevant to the user request. Therefore this module end
intends to produce a HashMap7 M ap < O, C > that maps the return M ap
output parameters OU T to: an adequate list of chains and to
the required list of input parameters as indicated in Fig. 7. In • O ={O0 , ..., On } and IN={I0 ,...,Im } is the set of output
order to improve the performance of the algorithm, this M ap and input parameters that are declared in the ontology,
is created once at the startup of the application by exploring respectively.
the ontology, and is searched each time a new user’s query is • Mi ={ Mij | Mij is a method of a service with an output
executed. parameter Oi }
Chain (Definition):The chain presented in Fig. 5 is defined
as a hierarchy-tree of nodes. These nodes represent services
defined by the ontology. The Node class N is represented
by four properties N = (M, INm , IVm , LN ) where: (i)
Method M represents the standard HTTP GET of the service
to invoke8 . (ii) INm is a set of input-parameter of M . (iii)
IVm is the Input-Value of INm that will be filled either from
the user’s entry or by the result of the next matching node
(service). (iv) LinkT oN ode LN represents a relation between
two matching nodes, where the direction between nodes N1
and N2 indicates that one output of N2 establishes one input
of N1 .
Matching(Definition): the Matching is an operation of cor-
respondence between input/output parameters based on an
efficient semantic reasoning. The correspondence between
input/output is performed according to the relation (synonym
or typeof) between nouns themselves as well as the relation (is
equivalent to) between each input/output parameter and nouns.
The Ontology Chain Builder module is decomposed into
three submodules (see Fig. 4):
Fig. 6: HashM ap M ap < O, M Hchy > represents the
7 https://docs.oracle.com/javase/9/docs/api/java/util/HashMap.html output parameter as a key and its corresponding list of
8 Additional http verb will be supported in future implementation. M atchingHierarchy objects as a value.
 • Im = {Ij | Ij is an input parameter of a service having
a method Mi }
• M OU Tk ={Oki | Oki ∈ OU T ∧ Oki = matching(Ij ) |
Ij ∈ Im }. The matching procedure will be defined
hereafter (Module 1 - Submodule 2).
2) Input Output Matching (Module 1- Submodule 2):
The purpose of this submodule is to search the ontology
for output parameters (OutP aram) that match an input pa-
rameter (inputP aram) of different services. Thus, we build
a SPARQL query (Listing 1) which retrieves the required
information from the ontology. The text [inputparam] in the
listing represents the name of the target input parameter.
SELECT DISTINCT ?OutParam
WHERE{
?OutParam rdf:type mat:OutputParam. Fig. 7: Iteration represent the generate of Chains Cij for the
?OutParam mat:isEquivalent ?outNoun.
{?outNoun mat:isTypeOf* ?noun}
output Oi = Day Weather.
UNION
{?outNoun (mat:hasSynonym)* ?noun}.
?noun (mat:hasSynonym)* ?inNoun . idea: (i)The iteration begins by creating the first chain that
?inParam mat:isEquivalent ?inNoun . contains one node, which consists of a service and their direct
?inParam rdfs:Individual* mat:[inputparam]
} inputs from M Hchyij . For Example: the first Chain Ci1
of the service Day-Weather has one Node that consists of
Listing 1: SPARQL query to extract matching output param- dayWeather get-method with three inputs: longitude, latitude
eter and weekday (Fig. 7 iteration1). (ii) In the second iteration, the
procedure builds the second node of the chain by applying the
3) Services Connectors (Module 1- Submodule 3): User’s
Combination formula on the inputs of dayWeather service
request, in general, is a set of terms, representing the needed
and replacing each input with the service of its matching
result (output) related to the provided information (input).
output using M ap < O, M Hchy >. For Example: the
Generating the M ap < O, C > will bind each output declared
longitude input parameter of DayWeather is matched to a
in the ontology to the required inputs needed to execute a
longitude output parameter. Using M ap < O, M Hchy >,
specific chain. This submodule uses M ap < O, M Hchy >
we can find that this longitude output parameter is achieved
produced in submodule-1 to generate the M ap < O, C >.
by GeoLocation service that has one input parameter of type
Procedure 2 implements this submodule by iterating aver
City; thus, the new chain Ci2 will consist of two nodes:
all Oi in M ap < O, M Hchy > and calling a recursive
DayWeather and GeoLocation with three inputs: City, Latitude
procedure recursiveGenerateN ewChain that uses the ob-
and Weekday) (see Fig. 7 iteration2), and so forth.
ject M Hchyij to generate a set of chains Ci denoted by
Ci = {Ci1 , Ci2 , ..., Cij }. Each Cij contains a hierarchy-tree of Procedure 3 Recursive technique to generate new chain C
Node besides to the required inputs RIij = {Ii1 , Ii2 , ..., Iij } Input: M ap < OM Hchy > M apOM Hchy, M Hchyij ,Cij
(see Fig. 7) Output: Cij
Mij ← M Hchyij .getM ethod
for all combination Oi in M apOM Hchy do
Procedure 2 Services Connectors if this combination was not used before to create a chain then
Input: M ap < O, M Hchy > M apOM Hchy chain.add(create a new chain from this combination)
Output: M ap < O, C > M apChain else
initialize an ontology model model for M OU Tk in M Hchyij .getOutP arams(inP aram) // output
initialize M apChain that matches the inParam of the combination
for Oi in M apOM Hchy do do
Let Ci a list of Chain for newLevelM Hchyij in
for M Hchyij in M apOM Hchy.getM Hchyi of Oi do M apOM Hchy.getHierarchys(M OU Tk ) do
do recursiveGenerateN ewChain(
recursiveGenerateN ewChain(M Hchyij , Cij ) // see newLevelM Hchyij , chain)
procedure 3 end
Ci .add(Cij ) end
while Cij not empty; end
end end
MapChain.put(Oi,Ci) return chain
end
return M apChain
At the end of this submodule, M ap < O, C > is ready to
be used in the next module.
The role of the procedure recursiveGenerateN ewChain
(procedure 3) is to generate a hierarchy-tree of Node (denoted D. Semantic Request Analyzer (Module 2)
by N) by relying on the input and output matching stored This module performs the analysis of queries expressed in
in M Hchyij . Fig. 7 presents an example which clarifies the natural language. The query submitted by the user is analysed
to obtain a set of terms, for instance: If user needs information TABLE I: Example scenario for scoring new york weather on
about ”new york weather on Friday”, it is important to under- Friday
stand that he/she is looking for the ’weather’ as an output, Term Type Ty Score Sc
and ’New York’ and ’Friday’ as urban area and weekday New not found
Place Of Business 4479
respectively as inputs. Without this identification of terms, we Seat 5428
cannot effectively identify and execute the most suitable chain Establishment 5991
for the user request. Therefore, this module is divided into Center 6454
New York City 20943
three Submodules : Town 23658
1) Parsing and Annotating (Module 2- Submodule 1): Area 50625
There are several pre-processing activities necessary to choose Municipality 89581
Urban Area 89689
properly the suitable services to execute. It includes: text New York Weather not found
parsing, filtering, tokenizing, annotating, and scoring. The fol- Genre 6380
Weather
lowing activities describe the module supported functionalities. Topical Concept 6837
Weather On not found
Request Parsing: we analyze the user’s request by using an
Weather On Friday not found
ensemble of representation models based upon iMat ontology On Friday not found
(semantic rest web service description), DBpedia (ontological Days Of The Week 9
features), and WordNet (Linguistics features). DBpedia has Days 506
Friday
Time Unit 655
a number of definitions that are grouped into one, two or Measure 16967
three words long. For this reason, the user’s input should be
tokenized to generate the unigrams, bigrams, and trigrams
terms. Various filters from Lucene9 are chosen to process is tokenized into three terms: ”Berlin”, ”Berlin Wall”, and
the provided text, such as removing chars according to the ”Wall”, where each term is found in DBpedia. Only longest N-
given regular expression pattern, whitespace tokenizer, word grams ”Berlin Wall” is taken. On the other side, Sc is deemed
delimiter filter, stop-word filter, and shingle filter (token n- to be the number (score) of DBpedia entities that refer to type
grams) etc. T yi (see table I). The score will be later used for selecting the
Terms Enrichment and Annotating: The extracted terms most suitable chain in the case of multiple matching chains
represent a simple text without any other information. Thus, for the user’s request (Module 2- Submodule 2).
these terms have to be enriched in order to select the appro- Third step: Matching the chosen terms that do not have
priate services to execute. Therefore, three steps are applied a type in DBpedia, by using WorldNet10 in order to extract
as follows: their types. WordNet divides lexicons into five categories as
First step: Identifying the formatting terms like date, nouns, verbs, adjectives, adverbs, and function words. In our
longitude-latitude, mail, and URL in order to propose them approach, only nouns are used for type extraction. To extract
as inputs as well as annotating them directly with their types. the types of a term there are three steps: (i) getting all synsets
For example, information ”33.8938, 35.5018”, 01/10/2016, (synonyms) of the term, (ii)searching the hypernyms (is-a) for
and [email protected] are identified as Coordinate, Date, and each synonym, which represents types, (iii) querying DBpedia
Email respectively, etc. Thus, these terms are considered as to fetch the number (scores) of DBpedia entities that refer to
inputs and ignored in the next enrichment steps. each hypernym (type). The hypernyms and their scores are
SELECT ?type (COUNT(?subType) as ?score) added to the set TySc.
WHERE { Finally, the term, that have a type in DBpedia and is not
?subType rdf:type ?type.
{SELECT ?type in WordNet, is considered as an input. Each one of the other
WHERE { terms is checked using WordNet to see if it is an instance. If
Dbr:[term] rdf:type ?type. } it is an instance, it will be considered as an input. Otherwise,
}
} GROUP BY ?type ?score it will be considered as an output (see table II).
The result achieved by these three steps is a HashMap
Listing 2: SPARQL query to fetch the types of terms denoted by M apT =< T, T ySc >, that maps each term to a
list of types and scores TySc. Moreover, according to table II
Second step: Querying dbpedia.org, using SPARQL query,
the terms of the user request are decomposed in two sets:
for the search terms. Listing 2 describes the query that
IT = {IT1 , ..., ITi } terms considered as input.
returns a set of T ySc of pairs: < type, score > T ySc =
OT = {OT1 , ..., OTi } terms considered as output.
{[T y1 , Sc1 ], ..., [T yn , Scn ]}. T y represents the types in DB-
pedia for one term of the user request. Indeed, if multiple
consecutive terms of the user request have types in DBpedia, 2) Score-Based Chain identification (Module 2- Submod-
and these terms share the same word, then only longest ule2): The objective of this Submodule is to identify the most
N-grams term will be taken. For example; ”Berlin Wall” suitable chain from M ap < O, C > that takes IT as input

9 https://lucene.apache.org/ 10 https://wordnet.princeton.edu/
TABLE II: Classification of terms by input and output cate-
gories
formated Has types Has types instance
Term Result
term in DBp in WN in WN
not not not
T-1 Yes Input
checked checked checked
not
T-2 No Yes No Input
checked
T-3 No Yes Yes Yes Input
T-4 No Yes Yes No Output
T-5 No No Yes Yes Input
T-6 No No Yes No Output
not
T-7 No No No Ignored
checked
Fig. 8: Example scenario to execute the chosen chain.

and return OT as output, therefore, we apply the following

deemed to replace ITj and OTj . Therefore, we perform
steps:
the following actions (procedure 4); for each OP i: (1) find
First, replace each ITi and OTj by elements from the
all chains Ci that can achieve the output OP i according
IN and OU T parameters from ontology, respectively, taking
to the M ap < O, C >. (2) Choose the appropriate chain
into account the following rule: ITi could be replaced by an
Cij by comparing its Required Input RIij with the IN P .
element Ii , if Ii is ’equivalent’ to a noun that is a sub-type,
Our assumption behind type scoring is that; if multi-result
type or synonym of T yi (T yi is a set of concepts of ITi
chains are found for the input terms IT , then the types that
identified from M apT < T, T ySc >). A SPARQL query is
have less score will be taken. We will use a simple example
applied to find the ’equivalent’ parameter from the ontology
to illustrate the assumption. Consider the input term ”Fri-
(listing 3). A Similar query is used for retrieving the output
day” that has many types with different scores in DBpedia:
Oi .
{(Days Of The Week,9), (Day,506), (Time Unit,655)}. Let us
SELECT DISTINCT ?InParam suppose that the iMat ontology defines two services: service-x
WHERE{
?Ii rdf:type mat:InputParam . has an input parameter equivalent to ”Days Of The Week”
?Ii mat:isEquivalent ?noun. and service-y has an input parameter equivalent to ”Day”.
{ ?noun mat:isTypeOf* mat:[Tyi] .} According to our assumption, the type that has a smaller score,
UNION { mat:[Tyi] mat:isTypeOf* ?noun .}
UNION{?noun mat:hasSynonym* mat:[Tyi] .} has the higher relevance for its sub type. This would mean
} that the service-x that has the input parameter equivalent to
”Days Of The Week” (with score 9) is more suitable to the
Listing 3: SPARQL query to retrieve the inputs-param that are
term ”Friday” than service-y which has an input parameter
equivalent to the type of input-term
equivalent to ”Date” (with score 506).
3) Chain execution (Module 2- Submodule 3): The result
Procedure 4 Retrieves the more suitable chain to the list of of the previous submodule is a chain Ci of consecutive
inputs services(nodes) to be mashed-up and executed.The following
Input: M ap < O, C > M apChains, IN P ,OU T P steps are applied:
Output: List < Chain > chainList
for OU T Pi in OU T P do • The terms of the IT are used as node inputs.
Ci ← M apChains.getChains(OU T Pi ) • The chain Ci is executed starting from the last node.
initialize List < Chain > tempChainList
for Cij , RIij in Ci do • The result (output) of each node execution is used as an
// INP must contain elements equivalent to all input parameter of its previous service (node). Then, the
elemnts in RIij
if RIij is equivalent to IN P then process continues executing to the previous node and so
tempChainList.add(Cij ) // add chain to the on.
tempChainList
end • When we cannot get a previous node, the final result is
end returned to the user.
if tempChainList contain more than one chain that are suitable to an output
OU T Pi then Fig. 8 illustrates how the inputs terms are put in their place,
determine the chain that has the minimum sum of score
add this chain to the chainList // it is a list perhaps consequently, and how the chain is executed.
there are several services return the users
request E. Implementation Technologies
end
end The iMAT framework was implemented using javaEE
return chainList
7 11 platform, the semantic web development tool Jena12
and Lucene API for keywords filtering. The application
Next, let OU T P = {OP0 , ..., OPi } and IN P =
{IP0 , ..., IPi } be the sets of output and input parameters, 11 http://www.oracle.com/technetwork/java/javaee/

respectively, returned from the previous query (listing 3) and 12 https://jena.apache.org/

 that can be linked together through inferencing. The benefit
of solutions such as iMAT, is that they draw a way to enter
the realms of the smart web, where information can be easily
obtained with little to no effort and where users can profit
from the scattered resources on the internet which will form
a seemingly single simply accessible resource for the user.
Future Work will concentrate mainly on:
• enriching the ontology with more Web APIs to cover ad-
ditional subjects (such as food, or any trending subjects).
• supporting different types of web resources such as RSS
feeds, IoT data, RDFa documents, etc.
• creating the GUI in order to support and simplify the task
of adding any type of web resource to the ontology.
Fig. 9: ScreenShots of the MobileiMat application R EFERENCES
[1] D. Benslimane, S. Dustdar, and A. Sheth, “Services mashups: The new
13 generation of web applications,” IEEE Internet Computing, vol. 12,
is deployed in Wildfly application server. Source code no. 5, 2008.
and iMat ontology are publicly available at the URL: [2] M. Pruett, Yahoo! pipes. O’Reilly, 2007.
https://github.com/housseindh/iMat [3] L. Ding, T. Finin, A. Joshi, R. Pan, R. S. Cost, Y. Peng, P. Reddivari,
V. Doshi, and J. Sachs, “Swoogle: a search and metadata engine for
the semantic web,” in Proceedings of the thirteenth ACM international
IV. M OBILE A PPLICATION conference on Information and knowledge management. ACM, 2004,
In order to validate the usefulness of the iMAT framework, pp. 652–659.
[4] E. Oren, R. Delbru, M. Catasta, R. Cyganiak, H. Stenzhorn, and
we implemented a mobile application for 2 reasons: First, G. Tummarello, “Sindice. com: a document-oriented lookup index for
most of the Internet surfing is done nowadays -according to open linked data,” International Journal of Metadata, Semantics and
the most recent statistics- via smartphones. Second, a mobile Ontologies, vol. 3, no. 1, pp. 37–52, 2008.
[5] G. Cheng, W. Ge, and Y. Qu, “Falcons: searching and browsing
application can make benefit of the sensors installed within entities on the semantic web,” in Proceedings of the 17th international
the smartphone such as the accelerometer, digital compass, conference on World Wide Web. ACM, 2008, pp. 1101–1102.
gyroscope, Global Positioning System (GPS), the microphone, [6] D. Sullivan, “Faq: All about the new google hummingbird algorithm,”
Retrieved March, vol. 13, p. 2015, 2013.
and the camera [17] in order to enhance the user experience. [7] D. Roman, J. Kopeckỳ, T. Vitvar, J. Domingue, and D. Fensel, “Wsmo-
Taking the GPS as an example, the information returned by lite and hrests: Lightweight semantic annotations for web services and
various RESTful API is dependent on the location of the restful apis,” Web Semantics: Science, Services and Agents on the World
Wide Web, vol. 31, pp. 39–58, 2015.
request, therefore we designed our mobile application in a way [8] D. Martin, M. Paolucci, S. McIlraith, M. Burstein, D. McDermott,
to enrich each user’s request with its current location before D. McGuinness, B. Parsia, T. Payne, M. Sabou, M. Solanki et al.,
sending the request to the server. Another design constraint “Bringing semantics to web services: The owl-s approach,” in In-
ternational Workshop on Semantic Web Services and Web Process
we respected, was to make the GUI as simple as possible with Composition. Springer, 2004, pp. 26–42.
only one TextBox where the user types his search request (see [9] J. De Bruijn, D. Fensel, M. Kerrigan, U. Keller, H. Lausen, and
Fig. 9). J. Scicluna, “The web service modeling ontology,” Modeling Semantic
Web Services: The Web Service Modeling Language, pp. 23–28, 2008.
[10] H. Lausen and J. Farrell, “Semantic annotations for wsdl and xml
V. C ONCLUSION A ND F UTURE W ORK schema,” W3C recommendation, W3C, vol. 69, 2007.
In this paper, we proposed an intelligent, powerful way [11] T. Vitvar, J. Kopeckỳ, M. Zaremba, and D. Fensel, “Wsmo-lite:
Lightweight semantic descriptions for services on the web.” in ECOWS,
to search for information on the web, and we described the vol. 7, 2007, pp. 77–86.
Intelligent Mobile Agent (iMat) framework that we imple- [12] M. Maleshkova, C. Pedrinaci, and J. Domingue, “Supporting the creation
mented to reach this purpose. The usefulness of the framework of semantic restful service descriptions,” 2009.
[13] A. P. Sheth, K. Gomadam, and J. Lathem, “Sa-rest: Semantically
was validated by the implementation of a Mobile Client interoperable and easier-to-use services and mashups,” IEEE Internet
Application, which helped us test the most important features Computing, vol. 11, no. 6, 2007.
of iMAT. In fact, we showed that simple search keywords can [14] R. Verborgh, A. Harth, M. Maleshkova, S. Stadtmüller, T. Steiner,
M. Taheriyan, and R. Van de Walle, “Survey of semantic description
be mapped to semantically described web resources (REST of rest apis,” in REST: Advanced Research Topics and Practical Appli-
Web services in our case) and mashed up by one service cations. Springer, 2014, pp. 69–89.
in order to return the most suitable answer to the user. The [15] F. A. Musyaffa, L. Halilaj, R. Siebes, F. Orlandi, and S. Auer, “Mini-
mally invasive semantification of light weight service descriptions,” in
concept we used in iMAT for describing REST web services Web Services (ICWS), 2016 IEEE International Conference on. IEEE,
can be further applied to include any type of resources on 2016, pp. 672–677.
the web. This can be easily seen and reflected in the way [16] R. Kilany, M. Chamoun, “Smart: Semantically mashup rest web ser-
vices,” arXiv preprint arXiv:1311.3078, 2013.
we constructed our ontology by unifying the interface or the [17] N. D. Lane, E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, and A. T.
frontier between these resources in simple words or nouns Campbell, “A survey of mobile phone sensing,” IEEE Communications
magazine, vol. 48, no. 9, 2010.
13 http://wildfly.org/