A Design Framework for Context-Aware Access

to Heterogeneous Resources?

Florian Daniel, Maristella Matera, Elisa Quintarelli, Letizia Tanca, and

Vittorio Zaccaria

Politecnico di Milano, Dipartimento di Elettronica, Informazione e Bioingegneria

{florian.daniel,maristella.matera,elisa.quintarelli,letizia.tanca,
vittorio.zaccaria}@polimi.it

Abstract. Current scenarios for app development are characterized by a

richness of heterogeneous resources that often overwhelm the final users,
especially in mobile app scenarios. It is therefore important to define
design methodologies that enable the dynamic filtering of pertinent re-
sources and the consequent tailoring of retrieved content. This paper
presents a design framework based on the specification of the possible
contexts deemed relevant to a given application domain and on their
mapping onto an integrated schema of the resources underlying the app.
The context and the integrated schema enable the instantiation at run-
time of templates of app pages in function of the context characterizing
the user’s current situation of use.

Keywords: Context-aware data access, Context Dimension Tree, CDT,

service selection, mashups, CAMUS

1 Introduction
In the last decades, the pervasive introduction of ICT technologies in our society
has changed the way people access information. Traditional data management
systems have left the place to sophisticated data integration systems that com-
bine and expose rich information extracted from all kinds of sources like Web
Data Service, Social Networks, Digital Libraries or Media Collections, and make
it available in the proper format to different media devices. Also savvy users have
changed their attitudes and behaviors to take advantage of the many opportu-
nities of being “digital” and “social,” starting from the initial need to choose
information to support their own tasks, to the identification of the necessary
budget, up to managing negotiations and other sophisticated operations. How-
ever, this does not come at a low price, as finding information that is most
suitable to their current situation of use often requires a lot of time and effort.
What is missing today is support for the fast development of integrated,
personalized, real-time assistants that help users by providing context-aware
?
This research has been partially supported by the IT2Rail project, funded by Euro-
pean Union’s Horizon 2020 research and innovation program under grant agreement
No: 636078, and by the the Italian project SHELL – CTN01 00128 111357
2 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

information and friendly guidance and by signaling events that may be of interest
in view of their tastes and current needs. It is therefore important to define design
methodologies that natively support the dynamic filtering of pertinent resources
and the consequent tailoring of the retrieved content. In this respect, the different
dimensions characterizing the context of use can guide the definition of queries
over the set of available heterogeneous resources.
Context awareness was born in the realm of ubiquitous computing, with the
objective of perceiving changes in the environment and reacting on this basis.
Various definitions of context have been proposed in the past: notably, Dey et al.
[15] characterize the context of a person in terms of time, location, identity, and
current activity; others identify further parameters, such as user role, current
task, device type, managing to cover different usage scenarios. More recently,
context has been understood to be strongly related to the application domain
and to individual use cases and, as such, to be treated by the designer of the
app as a first-class design concern.
To respond to the need for a development methodology with native sup-
port for context-awareness, this paper presents a design framework for the fast
development of apps that revolves around (i) the explicit specification of the
context dimensions deemed relevant in a given application domain and (ii) their
mapping onto an integrated schema of the available resources. We model context
dimensions using the Context Dimension Model (CDM) [4], which provides an
intuitive way to visually represent context information and, more specifically, the
conceptual relationships that exist among the properties of context in a given
scenario. The CDM comes in the form of Context Dimension Trees (CDTs), i.e.,
trees with nodes of three kinds: dimensions, concepts, and parameters.

Running Example. To illustrate our methodology, we make use of a tourism

scenario where an app that personalizes contents on the basis of his/her con-
texts (e.g., current location and time, possible disabilities, user’s preferences
about topics and means of transportation) enhances a travelers’ experience. The
app gathers contents about restaurants, hotels and itineraries from different re-
sources, Web APIs and datasets that may be public or made available by the
service provider who offers the app. We make a broad distinction between local
and remote data sources: local, proprietary data are, for instance, user profiles,
buying histories, or similar core assets of the application to be developed. We
assume our app stores data about affiliated hotels and discounts in a local table
(Hotel). As for remote sources, we assume the app leverages on two external
services for the calculation of itineraries (ItinSvc1 and ItinSvc2) and on one
service to search for restaurants (ResSvc). As there may be multiple providers
offering similar services, a service selection at runtime may be needed – again,
taking into account the user’s context.

Structure of paper. We next introduce the concepts and artifacts of the proposed
methodology, then we go into the details of the resource schema (Section 3) and
the Context Dimension Trees (Section 4). Next, we show how to interpret and
execute queries (Section 5) and discuss related work before closing the paper.
 Modeling Context-Aware Access to Heterogeneous Resources 3

R1 R2
D1
1 S1 S2
D2 2 S3
Local R3
D3
External
database
web services
Service registry
Data schema (descriptors)
3

Resource schema Query

4 Mapping

7
6 Query
Context rewriting
Dimension
Tree (CDT) CDT instance App views

Fig. 1. Overview of approach to the development of context-aware, mobile apps starting

from internal data sources, external services and a Context Dimension Tree.

2 Approach

In this paper we propose the use of the CDM in the development of context-
aware applications to achieve two goals: (i) the concise and human- and machine-
readable representation of all context dimensions and properties relevant to a
given development scenario and (ii) the simplification of the development of
context-aware application features. The approach turns the specification of all
the possible contexts of the considered scenario into a first-class development
artifact that not only serves a documentation purpose but also an operational
one. The context dimensions themselves can be aggregated into categories: in-
formation on the user (knowledge of habits, emotional state, physiological con-
ditions), user’s social environment (co-location of others, social interaction, cur-
rent tasks), physical environment (location, time, and physical conditions like
noise, light, pressure, air quality). Note that, while the dimensions of the latter
category can be automatically derived by appropriate sensors, the previous ones
may require to be inserted by the user or might be provided by default settings.
Figure 1 illustrates the resulting methodology and development steps. The
development process starts from the identification and description of the avail-
able resources, which can be both local data sources ¬, for example relational
data bases, or third-party Web services represented by their service descriptors
­. An integrated schema of the available data is then defined, so as to present
the developer with one abstract model of the data only. We call this schema
4 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

the resource schema ®, and we express it as a relational model. The resource

schema is generally defined manually, but it could be generated automatically
depending on the regularity of the schema of the selected resources. The resource
schema is accompanied with a CDT that captures all the execution contexts the
application may run in ¯. Each node of the CDT is mapped to the resource
schema (e.g., by means of views expressed in relational algebra).
The next step is the design of the queries that will feed the pages of the
final application, e.g., the pages in a mobile app that allow the user to interact
with the content °. The resource schema focuses on the integration of data,
independently of their use, and is thus context-agnostic. It is the CDT that
defines which of the elements in the resource schema are related to context in
the given application domain: for instance, the current position of a user is a
typical context property.
The queries expressed over the resource schema that do not make use of con-
text properties are thus context-agnostic too. Neglecting context properties in
this phase allows the developer to focus on the core functionality of the applica-
tion, deferring adaptation concerns. The queries are typically written manually;
without loss of generality, we express them in relational algebra.
At runtime, the CDT can be instantiated with concrete values coming from
the context sensors (sensing devices, user inputs, external sources) ±. That is,
the runtime environment of the application automatically updates the tree with
context information to characterize the usage scenario the user is currently in-
volved in. The availability of a CDT instance enables the derivation of context-
aware queries from the context-agnostic queries, by suitably enriching them with
context information ². This step can be performed fully automatically and is
based on conventional, view-based query rewriting techniques [13].
The simplification of the development process proposed for context-aware
applications therefore consists in (i) the use of a resource schema that hides
technological details and data provenance issues and (ii) the automatic rewriting
of context-agnostic queries into context-aware queries on behalf of the developer.
Both features alleviate the developer from tasks that are typically tedious and
time consuming. The following subsections describe the core ingredients of the
methodology in detail.

3 Resource Schema and Context-Agnostic Queries

As modern applications typically leverage on both local and remote data sources
(data bases and Web services), the initial activities in the development process
are the selection of the resources of interest and their technical description, speci-
fying the technical details that are needed to access them. Technically, local data
sources are usually accessed directly (without going though the Internet) and it
is necessary to specify (i) the endpoint of the data source (e.g., its IP address),
(ii) the port though which the source can be accessed, and (iii) the username and
password identifying the user that represents the application. To programmat-
ically access external Web services (e.g., SOAP/WSDL or RESTful services), it
 Modeling Context-Aware Access to Heterogeneous Resources 5

is necessary to specify: (i) the service endpoints (one or more URIs), (ii) the op-
erations offered by the service, (iii) the respective input parameters and output
data schemas and serializations (e.g., JSON or XML), and (iv) possible authenti-
cation details (e.g., usernames/passwords or developer keys). Each resource has
an own registry entry.
For the sake of brevity, we do not further detail these technicalities here; they
represent state-of-the-art development practice. What is relevant in our frame-
work is the specification of the access patterns that can be used to access the
services. Indeed, most services support different input parameters to access same
or similar data, which can be mandatory or oprional. We defer this specification
to after the modeling of the resource schema (Section 3.2).

3.1 Resource Schema Definition

Once the different resources are registered in the system, it is possible to derive
the resource schema of the available data so as to present the developer with a
unique schema of the data. The schema aims to represent the data provided by
the resources and their relationships in a way that accommodates the require-
ments posed by the specific application domain. For example, we can think of
the tables introduced in our running example as the result of a modeling activity
that produces a data schema representing all the resources selected for the given
application domain.
Considering the resources identified for our running example, a possible re-
source schema could look like the following one, where Restaurant represents
the data accessible through the service ResSvc, Hotel represent the data stored
in the local database HotelTab, and Itinerary represent the itineraries com-
puted by the two services ItinSvc1 and ItinSvc2:
Restaurant(name, address, phone, type, cuisine type, playground)
Hotel(name, address, category, childcare)
Itinerary(from, to, type, itinerary, price)
The identification of the previous relations depends on opportunistic choices
in the app design. For example, the attribute itinerary is not further specified,
as it is not necessary to further split and query itinerary descriptions. itinerary
could however contain a map image, a list of instructions, e.g., about how to go
from a hotel to a restaurant, or similar. The resource schema also makes only use
of logical addresses (city, street, number), instead of physical GPS coordinates.
In addition to these application-specific design choices, the resource schema
keeps track of the provenance of each attribute in the defined relations. This is
achieved using an additional table: Source(id, attribute, registry entry) that
tracks the necessary, minimal meta-data: for each attribute in the resource
schema, it contains a link to the registry entry that may provide data for the
attribute. A query for the attribute Itinerary.itinerary will thus return two
entries, i.e., ItinSvc1 and ItinSvc2. This meta-data will be used only at query
execution time and is not accessible to the developer, who instead is now able
6 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

to write her context-agnostic queries. For example, the following query

Q1 = Πname,address, σcousine type=$V AL Restaurant o

naddress=T o Intinerary
phone

corresponds to the view of the application that, at interaction time, allows the
user to choose a type of cuisine: the user choice will replace the parameter $V AL,
and then the app will show the restaurants matching the cuisine choice along
with the itineraries to reach them.
In Section 4.2, we show how to inject context into Q1 obtaining a context-
aware version of it.

3.2 Resource Mapping

Given the above resource schema, each access pattern to a resource can now be
expressed as a view over it. This equips the pure technical registry entry, that
tells how to interact with the service, with a semantical mapping of the service
to the resource schema; it will be this mapping to enable context-aware service
selection at runtime. For instance, the chosen restaurant search service can be
expressed as follows:
ResSvc ≡ Π name,address,phone, σ address=$optional ∧ Restaurant
type,cuisine,playground type=$optional ∧
playground=$optional ∧
cuisine type=$optional
In bold we highlight two keywords that are needed to express a service’s
access pattern: the values $mandatory and $optional tell, respectively, if an
attribute is a mandatory or optional input of the service. Both keywords are
automatically replaced at runtime by their respective values. Without proper
values for mandatory inputs, the service cannot be invoked; optional inputs may
be used to restrict the output data produced by the service.
In addition to mandatory and optional inputs, it is also possible to specify
constant values for some input parameters. Doing so binds the view representing
the access pattern to the given value, expressing that the service is able to provide
only data that complies with this restriction. If we take, for instance, two services
that provide itinerary information (e.g., one service about a city local transport
network and one about a national railway network), we may obtain the following
two access patterns:
ItinSvc1 ≡ Π f rom,to,type, σf rom=$mandatory ∧ Itinerary
itinerary,price to=$mandatory
∧type=$optional
ItinSvc2 ≡ Π f rom,to,type, σf rom=$mandatory ∧to=$mandatory Itinerary
itinerary,price ∧type=“train”
Service ItinSvc1 is the local service, while ItinSvc2 is the national rail-
way service. view explicitly binds the attribute type to the value "train" as
that service is able to provide only data about the train connections, while the
other service may provide data about all among trains, undergrounds, busses
and trams within its geographical area of competence (for simplicity, we do not
represent this limitation here).
 Modeling Context-Aware Access to Heterogeneous Resources 7

Analogously, the HotelTab table of the local database can be expressed

as follows (observe that, for consistency with the mapping of Web services, all
attributes are optional as relations do not have access patterns):
HotelTab ≡ Π name,address, σ name=$optional ∧address=$optional Hotel
category,childcare category=$optional ∧childcare=$optional

4 Context Dimension Tree and Context-Aware Queries

In this section we present the Context Dimension Model (CDM) [4] and the
automatic rewriting of context-agnostic queries into context-aware queries.

4.1 The CDM model and the CDT

The Context Dimension Model allows one to represent Context Dimension Trees
- CDTs as trees with nodes of three kinds: dimensions, concepts, and parameters.
An example of CDT for the touristic scenario of the running example is shown
in Figure 2. Dimension nodes, depicted in black, represent the different perspec-
tives describing context (e.g., user type and transportation), while concepts,
depicted as white nodes, are the admissible values of each dimension (e.g., the
concepts adult, young adult and family with children are values for the
user type dimension). The root is a special concept node representing the most
general context capturing all the available resources; its children are the main di-
mensions. Every dimension has only concept children, and each concept has only
dimension children; the latter are subdimensions, further specifying the concept
(e.g., r type specializes the restaurant concept). Dimensions and concepts can
be connected to attributes, that are parameters whose values can be dynamically
derived from the environment or provided by the users themselves at execution
time. A dimension can be connected to at most one attribute, used to replace
a huge number of concepts when it is impractical to list them all (e.g., a GPS
location). If this is the case, the dimension does not have any concept child; e.g.,
the current position dimension has as child the attribute curr pos. One or
more attributes can be added to concepts too, and are used to select specific
instances from the set of values represented by a concept node (e.g., the age
of an adult traveller). Attributes are graphically represented in Figure 2(a) by
double circles.
A context instance is a subtree of a CDT where the parameter nodes have
been replaced with concrete values; assuming w.l.o.g. that node labels are unique
in the CDT, a context instance can also be represented as a set of dimension=va-
lue pairs. For each dimension, typically a context instance contains at most
one child value (e.g., the user type dimension can assume at most one value in the
current context instance); when it is reasonable to allow the selection of multiple
values for a dimension, the edges toward its children are connected by an arc (e.g.,
the interest topic can assume multiple values). Figure 2(b) shows an instance:
a family with children, currently located in Viale Romagna in Milan, moves
8 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

user transportation
type
current interest_zone time disability
interest_topic position
young family adult d_type bus car train
cur_pos zone time_val
adult with
children
restaurant show
hotel
r_type s_type
user current
interest_topic transportation
type position
restaurant cur_pos
cinema theater concert Milan bus
pizzeria cafe pub family
with r_type Viale Romagna
(a) children
(b)
pub

Fig. 2. The CDT of our example (a) and a context instance (b)

Context Element Relational Algebra Expressions

user type = family with σplayground=“yes00 Restaurant
children
σchildcare=“yes00 Hotel
r type= pub σtype=“pub00 Restaurant
current position = Milan Viale σf rom=“M ilan V iale Romagna00 ∧to=$V alue Itinerary
Romagna σaddress=“M ilan V iale Romagna00 Restaurant
σaddress=“M ilan V iale Romagna00 Hotel
transportation = bus σtype=“bus00 Itinerary
Table 1. Relational Algebra Expressions associated with the context instance C

around by bus and prefers to eat at pubs. This instance can be equivalently repre-
sented as C = {user type = family with children, r type = pub, current
position = Milan Viale Romagna, time = now, transportation = bus}.

4.2 Query Rewriting

Following an approach similar to [4], we propose that the designer associates

each context element (i.e., dimension=value) of the CDT with one or more
relations of the resource schema, filtered on the basis of the value component of
the context element itself. For instance, Table 1 shows the expressions associated
with the context elements in C.
Suppose now that at run time, while in context C, the user is prompted
by the app with the view associated with the context-agnostic query Q1 from
Section 2, and selects the indian cuisine. Q1 will be automatically rewritten on
the basis of the context-aware expressions of Table 1 as in Figure 3, represented
as a standard syntax tree for relational algebra.
 Modeling Context-Aware Access to Heterogeneous Resources 9

Πname,address,phone

o
naddress=to

σP 2
σP 1

restaurant itinerary

Fig. 3. Query Q2 where P1 = cuisineT ype = “indian00 ∧ type = “pub00 ∧

playground = “yes00 ∧ address = “M ilan V iale Romagna00 and P2 = type = “bus00 ∧
f rom = “M ilan V iale Romagna00

Note how the context contributes to contextualizing each part of the agnos-
tic query by adding conditions related to the contextual information (e.g., the
user’s current position or the type of user) to the selection and join operations: in
Table 1, the expression σf rom=“M ilan V iale Romagna”∧to=$V alue Itinerary, asso-
ciated with the context element current position = Milan Viale Romagna,
contains a parameter referring to the destination of the itinerary, that takes now
the value specified by the join condition of the agnostic query Q1 .

5 Query Interpretation and Execution

In this section we describe the synthesis of a query execution plan from the
context aware query and the consequent selection of the related data and services;
in the last subsection we then give an account of the real execution flow of our
framework, as it has been made concrete in a research prototype [9].

5.1 Query Interpretation and Service Selection

The idea behind the query execution plan generation is as follows:

1. We produce a tree-like representation of the relational algebra query that is

extended with an explicit representation of the corresponding predicates.
2. We map a service to one or more query primitives in the original tree by
exploiting the structure of their access pattern represented as a tile pattern 1 .
3. We visit the mapped tree to produce a schedule of web services invocations
and database assesses.
1
A tile pattern is a tree template with one or more wildcards that can match any
subtree of the original query. Note that, in this view, data coming from lower nodes
is an “input” to a service, while the root of the node is the “output” of the service.
10 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

σ σ

∧ itinerary ∧ restaurant

(type) from to (cuisineType) (type) (playground) (address)

* * * * * * *
(a) (b)

Fig. 4. Itinerary service tile (ItinSvc1) and restaurant service tile (ResSvc).

For example, let us consider query Q2 of Figure 3. To see how this query
can be mapped to an actual query execution plan involving service request, we
consider the services described in Section 3.2. In general, every service will expose
a potential set of filtering predicates to be used when accessing it. To capture this
information, the tile pattern will cover not only the abstract relational algebra
operation associated with the service, but also the syntactic structure of valid
predicates. Here and in the rest of this section we extend with a double-line arrow
the representation of the associated logical predicate. For example, Figure 4(a)
shows the subtree pattern in the original query the ItinSvc1 service can answer
to (section 3.2). The pattern specifies that such a service can be selected when
part of the original query aims to select itineraries where:

– the from attribute is mandatory,

– the type attribute is optional,
– the to attribute is mandatory.

Figure 4(b) shows, similarly, the pattern associated with ResSvc. Itin-
Svc2’s pattern is not shown, as it’s restriction "type=train" is not compatible
with the query’s request for a bus ("type=bus").
We now can expand query Q2 by exposing the logical structure of its pred-
icates. We then note that the only registered access patterns that allow valid
matches are ResSvc and ItinSvc1 because ItinSvc2 cannot pattern match.
Figure 5 shows the result of the match operation; since we deal with a logically
correlated sub-query, we mark with a small circle each tile pattern leaf that cor-
responds to an attribute involved in a join condition appearing above it in the
tree.
After having identified the services by pattern matching, we schedule the
service invocation by traversing the tree in post-order and executing joins with
a nested join strategy. In particular, we use the convention that the left relation
is always the outer relation and exploit the commutativity of the join operator
to reorder the nodes in the tree and optimize the query execution. In particular,
we try to order nodes from left to right by ascending number of correlated
attributes. So, in this case, ResSvc is invoked first (by using, as parameters,
the values of the leafs that allowed the match), while ItinSvc1 is invoked for
dimensions using the Context Dimension Model
context (CDM) [4],
dimensions whichrelevant
deemed providesin an
a given application domain and (ii) their
intuitive way to visually represent context
mapping onto an integrated schema of the
information and, more specifically, the available resources. We model context
conceptual relationships that exist among the properties
dimensions using theof Context
context Dimension
in a given Model (CDM) [4], which provides an
scenario. The CDM comes in the form intuitive
of ContextwayDimension
to visuallyTrees (CDTs),
represent i.e., information and, more specifically, the
context
trees with nodes of three kinds: dimensions, concepts,
conceptual and parameters.
relationships that exist among the properties of context in a given
scenario. The CDM comes in the form of Context Dimension Trees (CDTs), i.e.,
Running Example. To illustrate our methodology, we make use of a tourism
trees with nodes of three kinds: dimensions, concepts, and parameters.
scenario where an app that personalizes contents on the basis of his/her con-
texts (e.g., current location and time,Running
possibleExample.
disabilities,
To user’s preferences
illustrate our methodology, we make use of a tourism
about topics and means of transportation) enhances a travelers’ experience.
scenario where an app that personalizes The contents on the basis of his/her con-
app gathers contents about restaurants, hotels
texts andcurrent
Modeling
(e.g., itineraries from di↵erent
Context-Aware
location and time, re-possible
Access to Heterogeneous Resources
disabilities, user’s preferences 11
sources, Web APIs and datasets that about may be public
topics andormeans
made ofavailable by the enhances a travelers’ experience. The
transportation)
service provider who o↵ers the app. We appmake a broad
gathers distinction
contents about between localhotels and itineraries from di↵erent re-
restaurants,
and remote data sources: local, proprietary data are,APIs
for instance, user profiles, ⇧MK2-//`2bb-T?QM2
sources, Web and datasets that may be public or made available by the
buying histories, or similar core assetsservice
of the provider
application to be developed. We
who o↵ers the app. We make a broad distinction between local
assume our app stores data about affiliated hotels and
and remote datadiscounts in a local
sources: local, table o
proprietary ndata
//`2bb4iQ
are, for instance, user profiles,
(Hotel). As for remote sources, we assume the app leverages
buying histories, or similar on core
two external
assets of the application to be developed. We
services for the calculation of itineraries (ItinSvc1
assume our app and ItinSvc2)
stores and on
data about one hotels and discounts in a local table
affiliated
service to search for restaurants (ResSvc). As there may be multiple providers
(Hotel). As for remote sources, we assume the app leverages on two external
o↵ering similar services, a service selection at runtime may be needed – again,
services for the calculation of itineraries (ItinSvc1 and ItinSvc2) and on one
taking into account the user’s context.
service to search for restaurants (ResSvc). As there may be multiple providers
o↵ering similar services, a service selection at runtime may be needed – again,
Structure of paper. We next introduce the concepts and artifacts of the proposed
^ `2bim`Mi
taking into account the user’s context. ^ BiBM2``v
methodology, then we go into the details of the resource schema (Section 3) and
the Context Dimension Trees (Section 4). Next, we show how to interpret and
Structure of paper. We next introduce the concepts and artifacts of the proposed
execute queries (Section 5) and discuss related work before closing the paper.
methodology, then we go into the details of the resource schema (Section 3) and
the Context Dimension Trees (Section 4). Next, we show how to interpret and
+mBbBM2hvT2 ivT2
execute THv;`QmM/
queries (Section 5) and //`2bb ivT2 before closing
discuss related work 7`QKthe paper. iQ

BM/BM Tm# v2b JBHM oBH2 _QK;M #mb JBHM oBH2 _QK;M

Fig. 5. Example context aware query where predicates have been expanded and services
have been verified to match (see annotation).

each tuple returned by ResSvc by using the “Address” attribute value as the
“to” parameter value.
As shown in other similar works on query execution plan generation (such as
[6]), one could extend this methodology to introduce more refined methods to
enlarge the space of solutions considered for tile pattern matching. For example,
we might have multiple valid services that could serve a specific query and then
either choose (i) to invoke them all and then merge their outputs or (ii) to apply
some ranking strategy and then select the best service.

5.2 Query Execution

The CAMUS (Context-Aware Mobile mashUpS) system, a first prototype which

is already available for demonstration [9], is based on the just described design
framework [11]. We here briefly illustrate the query execution flow implemented
in the prototype. For more details, the reader is referred to [9].
The API invoked by the mobile client to access the back-end functions is
compliant with the GraphQL API specification [1], which provides a flexible
way to specify the response format: different data formats can thus be required
from the same end point, depending on the context-aware queries to be processed
at runtime. The Client App then exploits React Native [2], a framework recently
introduced by Facebook to streamline the production of cross-platform mobile
apps. A typical request from the client app is composed of a JSON payload
that describes the context and a GraphQL request specifying the structure that
the incoming data should have in order to be rendered in the results page.
This structure depends on the query associated to the page of the app to be
processed. The request is thus processed through a number of steps, according
12 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

to the flow outlined in the previous sections. In particular, a Context Manager is

in charge of identifying the CDT instance, based on the JSON payload sent by
the client app, and expanding the context-agnostic query accordingly. A Query
Manager then interprets the context-aware query and selects the corresponding
services. Service-specific bridges are then used to invoke the services, according
to the access patterns defined in the resource schema and service descriptors.
A Response Aggregator composes the integrated result set according to some
selected integration strategies, like the ones illustrated above2 . Finally, a View
Builder in the app client re-renders the app page by hydrating the corresponding
React Native template.

6 Comparison with other Work

The literature reports different works on mobile app development (see for ex-
ample [16]) that consider context-awareness as a dimension to be programmed
ad-hoc for each application, while they do not provide reusable conceptual ab-
stractions and design frameworks. In [10] the authors follow a different approach
that promotes separation of concerns: they show how context-aware mobile apps
can be built by mashing-up components managing the app logic with context
components dedicated to capturing context events and activating related opera-
tions in the app. Although effective, this approach does not provide any abstrac-
tion to model the context. The designer is in charge of configuring the context
components (which basically manage location and time) by means of parameter
settings. Within our framework we instead assign a fundamental role to context
modeling, and exploit the resulting specification to derive the logic for selecting
services and dynamically build the integrated content of the final applications.
Some other approaches offer systematic methodologies and design environ-
ments where context is given a fundamental role. MoWA [5] is a framework based
on the notion of augmentation, which consists in adding some scripts on top of
context-agnostic pages so that at runtime context can be gathered and processed
to trigger page adaptations. In line with our approach, MoWA promotes separa-
tion of concerns and gives context a first-class role; however, it forces the designer
to add a number of scripts for each page to be adapted dynamically at runtime.
As we have shown in the previous sections, in our approach context-awareness is
achieved at the only cost of defining, during the initial design phases, an adequate
conceptual model capturing the most salient context dimensions. Designers are
not required to add scripts or additional software modules. Context-agnostic
queries are automatically expanded and instantiated to take into account the
context instance identified at runtime.
Further works focus on the retrieval of content from heterogeneous services.
The approach presented in [12] enables end users to graphically compose their
own applications directly on their mobile phone, mainly integrating the func-
tionality available on the device and those provided by pervasive and Internet
2
In previous works [7] we also experimented some union and merging strategies for
composing the result sets coming from heterogeneous sources
 Modeling Context-Aware Access to Heterogeneous Resources 13

services. This approach is very interesting, as the end users are empowered to
design by themselves how to access different resources. However, it does not
consider any mechanism to filter and/or recommend at runtime services that fit
the current context. MyService [14] instead provides expert designers with the
possibility to select pre-defined context-based rules on top of a service directory.
Based on the chosen rules, proper services are then selected at runtime depend-
ing on the gathered context, and the code of the final app invoking these services
is dynamically generated. This work is in line with our idea to filter services at
runtime on the basis of the identified context. However the adopted notion of
context is limited to the current location, while CDM is generic enough to cover
the specification of the dimensions that, in each given scenario, characterize the
various contexts of use. Moreover, in our approach the designers are not required
to care about which services have to be exploited at runtime. It is the system
that selects the services that best respond to the identified context instance.
Finally, some other works are characterized by the adoption of models to
guide the access to heterogeneous resources. One such work is described in [8].
The authors, using CDM to model the possible contexts, build a platform serving
the execution of a context-aware tourism app. The app flexibly collects non-
structured data from varying heterogeneous sources, and provides contextual
recommendations to the user. This work shows the feasibility of adopting CDM
to drive the context-aware selection of services to be invoked at runtime. With
respect to this work, in our paper we propose a full-fledged design methodology
clarifying how the services can be actually selected in an automatic manner.
In [3], the authors then present a Model-Driven Engineering (MDE) approach
where context meta-models and model-to-code transformations enable building
design frameworks where context models guide the automatic generation of code
for the final context-aware apps. The proposed techniques for model-to-code
transformations are interesting and are also in line with the goal of our research.
However, once meta-models are in place, context modeling for the generation
of a specific app requires the designer to define rules (i.e., OCL expressions)
specifying the context-aware behaviors to be shown at runtime. Our approach,
instead, does not need additional specifications on top of the context model;
strategies for service and content filtering are shaped up at runtime, depending
on the way the captured context guides the rewriting of context-agnostic queries.

7 Conclusions and Future Work

The contribution of this paper is the systematic definition of the design method-
ology underlying CAMUS (Context-Aware Mobile mashUpS) [9], a research
project that aims at the conception of high-level abstractions for lightweight
data and service integration in the development of context-aware mobile apps.
The paper specifically focuses on data preparation and retrieval tasks in the de-
velopment life cycle and shows how to enable the automatic rewriting of context-
agnostic queries into context-aware ones by explicitly modeling what is consid-
ered context in a given application scenario. The proposed methodology turns
14 F. Daniel, M. Matera, E. Quintarelli, L. Tanca and V. Zaccaria

context into a first-class design concern and provides the conceptual and techno-
logical foundation for principled context management, assisting the work of the
developer. We did not discuss how data display is managed at runtime, which is
the focus of our current research. In addition, our future work will focus on the
discovery of services from large repositories and on improving the visual design
environments for modeling context and designing resource integration.

References
1. GraphQL. Draft RFC Specification, Facebook, https://facebook.github.io/
graphql, 2015.
2. React Native. React Native official page, Facebook, https://facebook.github.
io/react-native, 2015.
3. A. Achilleos, K. Yang, and N. Georgalas. Context modelling and a context-aware
framework for pervasive service creation: A model-driven approach. Pervasive and
Mobile Computing, 6(2):281–296, 2010.
4. C. Bolchini, E. Quintarelli, and L. Tanca. Carve: Context-aware automatic view
definition over relational databases. Information Systems, 38(1):45–67, 2013.
5. G. A. Bosetti, S. Firmenich, S. E. Gordillo, and G. Rossi. An approach for building
mobile web applications through web augmentation. J. Web Eng., 16(1&2):75–102,
2017.
6. D. Braga, S. Ceri, F. Daniel, and D. Martinenghi. Optimization of multi-domain
queries on the web. PVLDB, 1(1):562–573, 2008.
7. C. Cappiello, M. Matera, and M. Picozzi. A UI-Centric Approach for the End-User
Development of Multi-device Mashups. TWEB, 9(3):11, 2015.
8. M. Casillo, F. Colace, M. D. Santo, S. Lemma, and M. Lombardi. A context-aware
mobile solution for assisting tourists in a smart environment. In HICSS 2017. AIS
Electronic Library (AISeL), 2017.
9. V. Cassani, S. Gianelli, M. Matera, R. Medana, E. Quintarelli, L. Tanca, and
V. Zaccaria. On the role of context in the design of mobile mashups. In RMC
2016, pages 108–128. Springer, 2016.
10. F. Daniel and M. Matera. Mashing up context-aware web applications: A
component-based development approach. In Proc. of Web Information Systems
Engineering - WISE 2008, volume 5175 of LNCS, pages 250–263. Springer, 2008.
11. F. Daniel and M. Matera. Mashups - Concepts, Models and Architectures. Data-
Centric Systems and Applications. Springer, 2014.
12. R. Francese, M. Risi, G. Tortora, and M. Tucci. Visual mobile computing for
mobile end-users. IEEE Trans. Mob. Comput., 15(4):1033–1046, 2016.
13. A. Y. Halevy. Answering queries using views: A survey. VLDB J., 10(4):270–294,
2001.
14. E. Lee and H.-J. Joo. Developing lightweight context-aware service mashup ap-
plications. In Advanced Communication Technology (ICACT), 2013 15th Interna-
tional Conference on, pages 1060–1064, Jan 2013.
15. D. Salber, A. K. Dey, and G. D. Abowd. The context toolkit: Aiding the devel-
opment of context-enabled applications. In Proceeding of the CHI ’99 Conference,
pages 434–441. ACM, 1999.
16. R. Schaller. Mobile tourist guides: Bridging the gap between automation and
users retaining control of their itineraries. In Proceedings of the 5th Information
Interaction in Context Symposium, IIiX ’14, pages 320–323, New York, NY, USA,
2014. ACM.