=Paper=
{{Paper
|id=Vol-136/paper-7
|storemode=property
|title=Towards a Context-Aware Relational Model
|pdfUrl=https://ceur-ws.org/Vol-136/190.pdf
|volume=Vol-136
}}
==Towards a Context-Aware Relational Model==
https://ceur-ws.org/Vol-136/190.pdf
Towards a Context-Aware Relational Model
Yannis Roussos? Yannis Stavrakas∗ Vassia Pavlaki??
Department of Electrical and Computer Engineering,
National Technical University of Athens (NTUA)
Athens, Greece
{iroussos,ys}@dblab.ntua.gr vpavlaki@mail.ntua.gr
Abstract. In traditional databases and information systems the num-
ber of users is more or less known and their background is to a great ex-
tent homogeneous. In distributed and heterogeneous environments how-
ever such as the Web, users do not apply the same conventions when
interpreting data due to different backgrounds, knowledge or culture. In-
terpreting and managing data according to the context is a topic not
explored in its full potential in these new environments. In this work we
present the Context Relational model (CR model), a model that extends
the relational model to argue also about context. The interesting part of
this approach is that context is treated as first-class citizen at the level
of database models and query languages. This is due to the fact that an
attribute may not exist under some contexts or that the attribute may
have different values under different contexts. Apart from the model de-
scription this work presents also a set of basic operations which extend
relational algebra so as to take context into account.
1 Introduction
Information today is accessed and used in a global environment, where assump-
tions about data become less evident. Users with different backgrounds or view-
points may interpret the same data in a different way. Moreover, the interpreta-
tion and suitability of data may depend on unpredictably changing conditions,
like for example the current position of the user or the media he is using (lap-
top, mobile, PDA). To avoid such ambiguous situations the information provider
needs to specify the context under which information becomes relevant. Con-
versely, information users can specify their own current context when requesting
for data in order to denote the part that is relevant to their specific situation.
For instance imagine a product whose specification changes according to the
country it is being exported. Or a Web page that is to be displayed on devices
?
Work supported in part by DELOS Network of Excellence on Digital Libraries, IST
programme of the EC FP6, no G038-507618, and by PYTHAGORAS EPEAEK II
programme, EU and Greek Ministry of Education, co-funded by the European Social
Fund (75%) and National Resources (25%)
??
Work supported by HERAKLEITOS EPEAEK programme, EU and Greek Ministry
of Education, co-funded by the European Social Fund (75%) and National Resources
(25%)
with different capabilities, like mobile phones, PDAs, and personal computers.
Another example is a report that must be represented at various degrees of detail
and in various languages. In those situations, context can be used as a viewpoint
mechanism that takes into account implicit background knowledge.
In previous work [SG02,Sta03] we argued that the management of context
should take place at the level of database systems in a uniform way and that
consequently context should be treated as a first-class citizen in data models
and query languages. In particular, relational databases (R-DBs) can no longer
be seen as isolated data sources, where users are familiar with the implied as-
sumptions necessary for interpreting the data they retrieve. Today R-DBs are
widely used in Web applications for dynamically constructing Web pages that
are globally available. They are also used as back-ends in systems where con-
text information is constantly provided by sensors. It is therefore interesting to
examine how the notion of context can be incorporated in a R-DBMS.
In [Sta03], it has been shown that direct incorporation of context in database
management systems would have the following positive results: a) management
of data according to the interpretation frame, b) ability to pose cross-world
queries that have no counterpart in context-unaware systems, c) personalization
in a flexible and uniform manner and d) direct support for managing data and
schema histories.
In this work we study the problem of incorporating context in the relational
database model, which has a strong formal background, and propose a novel
infrastructure. We present the Context Relational model (CR model) that can
be viewed as an extended relational model able to argue about context as well.
The proposed model is able to accommodate information entities that manifest
different facets, whose contents can vary in structure and value. Each facet of
such a multi-faceted information entity is associated with a context, stating
the conditions under which this facet holds. We then discuss some operations
through example queries that demonstrate the potential of this model.
The rest of the paper is organized as follows. Section 1.1 presents related
work. In Section 2 the notion of context is revised. In Section 3.1 we give a mo-
tivating example to facilitate the understanding of our model. In Section 3.2 we
discuss the technical challenges of our work and the advantages of our framework.
In Section 3.3 we describe in detail the CR model. Section 4 presents the basic
operations of an extended algebra that incorporates context through example
queries. In Section 5 we state the differences of the CR model relatively to the
relational model. Finally Section 6 discusses possible future research directions.
1.1 Related Work
The notion of context was originally introduced in Frege’s proposal of a princi-
ple of contextuality [Fre84]. Since then, context has been called to account for
a variety of problems in different areas. Context has been used in diverse ar-
eas of computer science as a tool for reasoning with viewpoints and background
beliefs, and as an abstraction mechanism for dealing with complexity, hetero-
geneity, and partial knowledge. A formal framework for reasoning upon a subset
of a global knowledge base can be found in [GG01], which is extended in Local
Relational Model [SGMB03,BGK+ 02] to allow for inconsistent databases and to
support semantic interoperability in the absence of a global schema. Examples
of how context can be used for partitioning an information base into manageable
fragments of related objects can be found in [MMP95,TACS98].
In Web information systems context is often defined by giving values to a
number of user-defined variables called dimensions or characteristics. By assign-
ing values to such variables, users can constraint the information that is relevant
to them by explicitly specifying the way they interpret data. In [Bro98,Yil97],
Intensional HTML is introduced to address the problem of constructing and
maintaining Web sites that must exist in many versions, for example depending
on the language, user expertise, subscription level, screen resolution.
In multidimensional semistructured data [Sta03,SG02] similar principles are
applied to represent semistructured information entities that assume different
facets, with varying content (value and/or structure), under different contexts.
This approach sees context as a set of constraints, which are combined through
context operations to specify environments under which information obtains an
unambiguous meaning. Such an environment is called a world, while constraints
are expressed by assigning values to dimension variables. The work in [SGDZ04]
shows how context can be used to represent and query valid time of data and
histories of semistructured databases.
This perception of context has also been used in OMSwe, a Web-publishing
platform described in [NP03b,NP03a]. OMSwe is based on an Object DBMS,
which has been extended to support a flexible, domain-independent model for
information delivery where context plays a pivotal role.
New mobile-aware applications are more effective and adaptive to user in-
formation needs without consuming too much of a users attention, by taking
advantage of the dynamic environmental characteristics, such as the user’s loca-
tion, time, people nearby, etc. A detailed survey about exploiting context-aware
computing in mobile environments is presented in [CK00]. In [DVV03], the au-
thors propose a context-aware service discovery, describing a context-based index
to support efficient retrieval of Web services whereas in [VVV+ 03] a platform
is presented for sharing context dependent data and services for mobile sources,
called MobiShare.
2 Preliminaries
In our approach, a world represents an environment under which data obtain a
substance. The set of parameters used to specify the world are called dimensions.
A context specifier is a syntactic construct used to qualify pieces of data and
specify sets of worlds (or contexts) under which these pieces hold. In this way,
it is possible to have at the same time variants of the same information entity,
each holding under a different set of worlds, or equally under a different context.
The variants of an information entity are called facets of the entity and they
may differ in value and/or structure.
Definition 1. Let D be a nonempty set of dimension names and for each d ∈ D,
let Vd be the domain of d, with V d 6= ∅. A world w with respect to D is a set
of pairs (d, v), where d ∈ D and v ∈ Vd , such that for every d ∈ D exactly one
(d, v) belongs to w.
In the model we present in Section 3, sets of worlds are represented by context
specifiers, which can be seen as constraints on dimension values.
Example 1. Some context specifiers might be the following:
(a) [device=PC]
(b) [device=PDA, payment in {credit card, cash}]
In Example 1, context specifier (a) represents the worlds for which the di-
mension device has the value PC, while (b) represents the worlds for which
device is PDA and payment is either credit card or cash. It is not necessary
for a context specifier to contain values for every dimension in D. Omitting a
dimension implies that its value may range over the whole dimension domain.
The context specifier [] is a universal context and represents the set of all
possible worlds, while the context specifier [-] is an empty context and represents
the empty set of worlds. In [SG02,Sta03] operations on context specifiers are
defined and it is presented how a context specifier can be transformed to the set
of worlds it represents with respect to a set of dimensions D. In the case where
two context specifiers represent disjoint sets of worlds the context specifiers are
called mutually exclusive.
3 A Context Relational Model
In this section we start with an example used throughout this paper and we
continue with stating some of the challenges we had to face. Then we present
in detail a Context Relational Model (CR model) for the representation and
manipulation of information under different worlds.
3.1 Motivating Example
Example 2. Consider a Web site about digital cameras. The information pro-
vided for each camera includes the brand name, the model of the camera, a
picture, the size in megapixels and the price. Customers connect to this Web
site using a variety of devices ranging over desktop computer (PC), PDA and
cell phone. Moreover, they can select the method of payment between Credit
Card and Cash.
The data about a digital camera returned to customers depends on the brows-
ing device and payment method. That is, a customer using a PDA receives a
picture of lower resolution than when using a PC. When using a cell phone
no picture exists and only textual information is provided. Moreover, the price
of a digital camera varies according to the payment method. Evidently, digital
camera is an information entity whose contents and structure in this particular
example vary according to the browsing device and the method of payment.
In database terms there is a main relation dcamera, with attributes: Brand,
Model, MPix, Photo, Price (see Table 1b). Customer requests are expressed
as queries and the data returned correspond to the evaluation of the queries
over this relation. The context of the example relation is expressed through the
following dimensions: device ranging over {PC, PDA, CELL}, payment ranging over
{Credit Card, Cash}.
The schema of relation dcamera and the data for a particular entity may
differ between different worlds. This is due to the fact that an attribute may
not exist in some worlds and that the same attribute may have different values
under different worlds. Table 1a presents all the possible worlds, while Table 1b
presents the worlds under which each attribute is defined.
Attributes Worlds
World Device Payment
Brand defined in every world
w1 PC Credit Card
Model defined in every world
w2 PDA Credit Card
MPix defined in every world
w3 CELL Credit Card
Photo defined only for worlds with
w4 PC Cash
browsing device in {PC,PDA}
w5 PDA Cash
Price defined in every world
w6 CELL Cash
but its values may change
Table 1. (a) On the left, all the possible worlds for Example 2 are presented and
(b) on the right, the worlds under which each attribute is defined are presented
3.2 Technical challenges and comparison with related work
The relational model does not treat context and entities as first class citizens. As
a result, the definition and manipulation of information that exists in multiple
worlds is done at application level. This has a series of disadvantages:
1. Redundancy, as the logic and the different basic operations must be reim-
plemented in each application.
2. Implementations that are strictly connected to specific design decisions and
the nature of each application.
3. Maintenance overhead.
There are two other approaches for dealing with context. In the first ap-
proach context is managed by the application logic at a separate level from
data management leading to an inflexible and hard to maintain architecture,
whereas ad-hoc solutions must be developed from scratch for every new case.
In the second approach, context is managed in a mediator, at an intermediate
layer between the data source(s) and the application(s). In this approach the
mediator contains context metadata that are ”linked” to the information parts
they annotate at the sources. Queries are addressed to the mediator, which uses
context metadata to navigate to the relevant data.
Handling context at the level of information sources (ie. database systems)
has the following advantages:
1. Comprehensive data design: context and its relation to data are taken into
account at the stage of schema design. This introduces an additional com-
plexity to schema design, however the incorporation of context conditions
into the DB schema enables also the consistency checking of insertions and
updates of context-dependent data.
2. Wider spectrum of queries: data models and query languages that directly
incorporate context can be more expressive, leading to new sorts of queries
(cross-world queries [Sta03]), like ”show the pictures of cameras that are
more expensive when paying in cash than when paying using credit card”,
or data management queries like ”under which contexts there is no picture”.
3. Efficient access: by pushing context management at the level of informa-
tion sources, the database systems have complete control and can use their
context-aware schema information as well as potentially especially designed
access methods to improve efficiency.
3.3 Model Description
In the previous section we argued that context should be incorporated in data-
base engines. In this next section we present in detail the proposed CR model.
The basic notion of our model is the multi-facet entity. A multi-facet entity is
an information entity which assumes different facets as defined under different
worlds. In the remaining of the paper, when we write entity we mean a multi-
facet entity. A facet fi,j is the variant of an entity ei defined under a specific
world wj . A set of entities are grouped to form a context relation.
For a context-relation R, a number of attributes are defined in each world.
The sets of attributes defined for R in two different worlds can (i) be the same,
(ii) have a common subset or (iii) have no common attributes at all. Moreover,
the same attribute Ai of a single entity can have different values in different
worlds. We refer to the value of an attribute Ai in world wj as Ai {wj }.
Brand Model MPix Photo Price
w6
w5
w4
w3
... w1
w2
Entity
Attribute World
Fig. 1. The Context Relation for the digital camera example
In Figure 1 we present the context-relation dcamera of Example 2. In order
to show the basic parts of our model, we highlight the entity e4 , the attribute
Photo and the world w2 .
Entities belonging to context-relation dcamera have values for the six worlds
of Table 1a. As stated in Table 1b, attribute Photo is not defined for worlds w3
and w6 (device = CELL PHONE), it stores a high resolution photo for worlds
w1 and w4 (device = PC) and a low resolution one for worlds w2 and w5
(device = PDA). Also the value of attribute Price depends on the payment
dimension. For example, entity e4 has Price{w1 } = 154 and Price{w4 } = 142.
A context-relation can be viewed as a cube. Each entity of the relation is
an horizontal slice spanning across all the worlds. Each entity slice has |a| ∗ |w|
cells, where |a| is the total number of attributes of the entity and |w| is the total
number of worlds in the system. A cell {i,j} in this slice represents the attribute
Ai {wj }. In Figure 1, we highlight entity e4 , which is a two-dimensional 5*6
horizontal slice, as context-relation dcamera has five attributes and is defined for
six worlds. Attribute Model is the second attribute of context-relation dcamera
and { Cell Phone ,Credit Card} is the third world, so cell {2,3} represents
attribute Model{w3 } for entity e4.
An attribute is a two-dimensional |e| ∗ |w| vertical slice, where |e| is the total
number of entities in the context dependent relation. A cell {i,j} in the slice
corresponding to attribute Ak represents the value of Ak for entity ei in world
wj . Proportionally, a world is a two-dimensional |e| ∗ |a| vertical slice. Each facet
of an entity ei is represented by the intersection of the slice entity for ei and the
world slice for the corresponding world.
Modeling entities and attributes as two-dimensional slices allows us to exhibit
these relations and interpret queries over different worlds in a more meaningful
way. For example, in Figure 1, we highlight attribute Photo. The response to a
query that asks for the photos of entity e4 is represented by the intersection of
the vertical attribute slice for attribute Photo and the horizontal entity slice for
e4 . The response to a query that asks for all the photos in world w2 is represented
by the intersection of the two vertical slices for attribute Photo and world w2 .
Finally, the intersection of the three slices corresponds to the value of attribute
Photo for entity e4 in world w2 .
4 Operations
In this section we present the basic operations (projection, selection, cartesian
product, join and set operations) of the relational algebra extended to incorporate
context. To distinguish them from the classical operations, we use the term
context in front of them, as for instance context-project. We keep the relational
symbols, e.g. π for context-project.
Context–Project
Given an input context-relation, the objective is to output only the attributes
specified in the condition of the context-project operator. The result is a new
context-relation that has only the vertical slices that correspond to the pro-
jected attributes. The resulting context relation will still include slices for all
possible worlds, however will only contain actual values for the projected part
(highlighted cells in figures of this section).
Brand Model MPix Photo Price Brand Model MPix Photo Price
w6 w6
w5 w5
w4 w4
w3 w3
... w1
w2 ... w1
w2
(a) (b)
Fig. 2. a)Context-Project for attributes Model, MPix and Price in all worlds,
b)Context-Project for attributes Model and MPix in world w1 and for Price in worlds
{w2 ,w4 }
For example, in Figure 2(a) we see the result of projecting attributes Model,
MPix and Price:
πM odel[ ], M P ix[ ], P rice[ ] dcamera
Note that a context specifier follows each attribute. Specifying the context
of the projected attributes is crucial when we are interested in the values of
attributes only for some worlds. For each attribute, the context specifier denotes
the set of worlds that will be projected.
Figure 2(b) illustrates the following query, which projects attributes Model
and MPix for world w1 and attribute Price for worlds w2 and w4 :
πM odel[Device=P C,P ayment=CreditCard],M P ix[Device=P C,P ayment=CreditCard],
P rice[Device=P DA,P ayment in {CreditCard,Cash}] dcamera
World Project
This operation retains only those facets of entities that hold under specified
worlds. For example, for a customer using a PC the relevant worlds are w1 and
w4 . We use the letter κ to represent the world-project operator:
κ[w1 ,w4 ] dcamera
Entity Context–Select
The entity context-select operation uses context in order to express conditions
that involve attribute values under different worlds. The following queries il-
lustrate this point. Note that we use the symbol σ entity to denote the entity
context-selection. Figure 3(a) highlights digital cameras created by Kodak, with
more than three megapixels.
entity
σ(BRAN D[ ]=0 Kodak0 AN D M P ix[ ]>3) dcamera
Brand Model MPix Photo Price Brand Model MPix Photo Price
w6 w6
w5 w5
w4 w4
w3 w3
... w1
w2 ... w1
w2
(a) (b)
Fig. 3. (a) Entity Context–Select, (b) Facet Context–Select
A simpler case where selection criteria is restricted to the values in specific
worlds is illustrated by the following example query, which selects only entities
where the price is less than 250 when the customer is paying in cash:
entity
σ(BRAN D[ ]=0 Kodak0 AN D P rice[Device=P C,P ayment=Cash] < 250) dcamera
Notice that an attribute may appear more than once in the same condition
with different context specifier. The following query is a cross-world query that
compares the values of the same attribute in different worlds, asking for cameras
that have lower price if the customer pays in cash than using a credit card:
entity
σ(P rice[Device=P C,P ayment=Cash] < P rice[Device=P C,P ayment=CreditCard]) dcamera
In the previous queries each attribute in the select condition is evaluated in
the set of worlds indicated by the respective context specifier. In case there is no
context specifier for an attribute, we evaluate the condition to true if there exists
at least one world where the condition holds. For instance, the following query
requests for entities where at least one facet has Price less than 250 Euros:
entity
σ(BRAN D[ ] = Kodak AN D P rice < 250) dcamera
Facet Context–Select
Users should be able to pose queries that involve selection of facets or, in other
words, to select parts of an entity. This can be done using the facet context–select
operator, denoted σ f acet . The σ f acet operator selects only the facets of an entity
that satisfy the condition, instead of the whole entity as the σ entity operator.
In Figure 3(b) we present the result of selecting facets with Price less than
500 euros. Note that the select facet operation is a basic operation in our algebra
as it cannot be constructed by any combination of the other operations.
Context Cartesian Product
In a way similar to the relational model, context cartesian product creates new
context-relations from existing ones. For the needs of our example Figure 4(a)
presents a new context-relation named accessories. The attributes defined for
accessories are the accessory name, the model of the corresponding digital
camera that the accessory fits in, a description of the accessory and its price.
Attribute model serves as a foreign key to the dcamera context-relation.
Name Model Desc Price Brand ... Price Name Model ... Price
...
w6 w6
w5 w5
w4 w4
w3 w3
... w1
w2
... w1
w2
(a) (b)
Fig. 4. a) context-relation accessories, b) Cartesian project
The cartesian product of context-relations dcamera and accessories is pre-
sented in Figure 4(b). The attributes of the resulting context-relation are the
attributes of dcamera and accessories. Entities of the new relation are con-
structed by combining each entity of dcamera with all the entities of accessories.
Context-Join
A context-join is defined as the composition of the context cartesian product and
the entity context-select operations, as in the relational model. As an example,
consider a query that asks for Kodak digital cameras with cheap 200mm lens
(e.g. where accessories.P rice < 0.2 ∗ dcamera.P rice). Apart from the context-
join, which adds no new complexities in our algebra, there is a need for a more
restrictive join operation, named context natural join. This operation is necessary
for selecting entities where (dcamera.Model = accessories.Model) for all worlds.
Set operations
Set operations like union, intersection, difference and division are defined only
for context-relations that are union compatible. In order for two context relations
to be union compatible, they must have exactly the same attributes defined under
each world. The semantics is the same as in set theory, but with entities as the
basic set elements.
Illustrating example
The following example brings together many of the operations presented in this
section. Consider a customer who uses a PC and wants to buy a Kodak cam-
era costing less than 400 Euros. He/she also wants to buy accessories for this
camera, so for all selected cameras he/she then requests to see all available ac-
cessories. Finally, he/she asks the price using cash for camera and credit card
for accessories. In database terms he/she requests dcamera.Price for cash and
accessories.Price for credit card:
Ctx-Rel1 ← context cartesian product(dcamera, accessories)
entity
Ctx-Rel2 ← σ(dc.M odel[ ] = ac.M odel[ ] AN D BRAN D[ ]=0 Kodak0 AN D dc.P rice[Device=P C,
P ayment=Cash]<400) Ctx-Rel1
Result ← πdcamera.M odel[Device=P C,P ayment=Cash], dcamera.P rice[Device=P C,P ayment=Cash],
accessories.N ame[Device=P C,P ayment=CreditCard], accessories.P rice[Device=P C,
P ayment=CreditCard] Ctx-Rel2
5 CR vs Relational model
In this section we discuss the differences of the CR model relatively to the relational
model. Although relational model can be in principle used to represent context depen-
dent information, context as such cannot be handled in database level but through the
use of application logic. In the CR model context is treated as a first class citizen added
at the level of databases, enabling a uniform approach to context and the definition of
context aware structures and operations.
In the CR model, a world slice wi is a classical relation as in the relational model.
The tuples of this relation would correspond to the facets of the entities for this world.
One can argue that instead of a context-relation that is defined in k worlds we could
have a set of k relations (as defined in the relational model). Another approach would
be to create a single denormalized relation with as many attributes as the sum of the
number of attributes defined in each world.
The main inconvenience of the relational model is that there is no way to define
the relation between the same attribute under different worlds. Regardless of whether
a context-relation is defined by k different relations or a single denormalized relation,
the fact that two attributes represent the same attribute of an information entity under
different worlds cannot be modelled.
If we decompose a context-relation to a series of relations, the link between facets
that consist a single information entity is lost. This link is used in the CR model to for-
mulate cross-world queries. Similarly, in the case of a single denormalized relation there
is no way to specify the attributes that belong to a specific world and ask intra-world
or cross-world queries. Moreover, maintaining a large number of relations (normalized
approach) or relations with hundreds of attributes (denormalized approach) adds a
great deal of complexity in the process of designing or altering the schema representing
a context aware database.
6 Conclusions and future work
In this work we studied the incorporation of context into relational database systems
and we presented the CR model that can argue about context as well. Our primarily aim
was to allow the management of context to take place at the level of database systems.
The proposed framework should also model heterogenous environments where users
may receive different responses for the same query depending on the context. This is
a consequence of our view of the model, where an attribute may not exist in some
worlds or the same attribute may have different values under different worlds. The
challenging part of this work consisted on how to extend the classical operations of
relational algebra to include context and enable users to pose cross world queries. As
future work we plan to:
- Extend the relational calculus and algebra to incorporate context.
- Propose a context-aware query language for the CR model.
- Demonstrate possible uses of our approach through example applications. In previous
work, context has been used to represent time [SGDZ04]. In this case it could be possible
to use the CR model for representing and querying histories of data. Moreover, in
[GSK+ 01] the authors have shown how context can be used to achieve personalization
in a uniform way at the database level.
- Design efficient access methods to take context into account.
References
[BGK+ 02] P. Bernstein, F. Giunchiglia, A. Kementsietsidis, J. Mylopoulos, L. Serafini,
and I. Zaihrayeu. Data management for peer-to-peer computing: A vision.
In WebDB, 2002.
[Bro98] G. Brown. Ihtml 2: Design and implementation. In Proceedings of the 11th
International Symposium on Languages for Intensional Programming, 1998.
[CK00] G. Chen and D. Kotz. A survey of context-aware mobile computing research.
Technical Report TR2000-381, Dartmouth College Computer Science, 2000.
[DVV03] C. Doulkeridis, E. Valavanis, and M. Vazirgiannis. Towards a context-aware
service directory. In Proceedings of the 4th VLDB Workshop on Technologies
for E-services (TES’03), 2003.
[Fre84] G. Frege. Die grundlagen der arithmetik. Koebner, Breslau, 1884.
[GG01] Ch. Ghidini and F. Giunchiglia. Local model semantics, or contextual rea-
soning = locality + compatibility. Artificial Intelligence, 127:221–259, 2001.
[GSK+ 01] M. Gergatsoulis, Y. Stavrakas, D. Karteris, A. Mouzaki, and D. Sterpis. A
web-based system for handling multidimensional information through mxml.
In ADBIS, 2001.
[MMP95] J. Mylopoulos and R. Motschnig-Pitrik. Partitioning information bases with
contexts. In CoopIS, 1995.
[NP03a] M. C. Norrie and A. Palinginis. Empowering databases for context-
dependent information delivery. In CAiSE’03 Workshop on Ubiquitous Mo-
bile Information and Col-laboration Systems (UMICS’03), 2003.
[NP03b] M. C. Norrie and A. Palinginis. From state to structure: an xml web pub-
lishing frame-work. In CAiSE’03, 2003.
[SG02] Y. Stavrakas and M. Gergatsoulis. Multidimensional semistructured data:
representing context-dependent information on the web. In CAiSE02, 2002.
[SGDZ04] Y. Stavrakas, M. Gergatsoulis, Ch. Doulkeridis, and V. Zafeiris. Represent-
ing and querying histories of semistructured databases using multidimen-
sional oem. Information Systems, 29:461–482, 2004.
[SGMB03] L. Serafini, F. Giunchiglia, F. Mylopoulos, and P. Bernstein. Local rela-
tional model: A logical formalization of database coordination. In CON-
TEXT, 2003.
[Sta03] Y. Stavrakas. Multidimensional semistructured data: representing and
querying context-dependent multifacet information on the web. PhD the-
sis, National Technical University of Athens, 2003.
[TACS98] M. Theodorakis, A. Analyti, P. Constantopoulos, and N. Spyratos. Context
in information bases. In CoopIS, 1998.
[VVV+ 03] E. Valavanis, C. Ververidis, M. Vazirgiannis, G. Polyzos, and K. Nor-
vag. Mobishare: Sharing context-dependent data and services from mobile
sources. In Proceedings of the IEEE/WIC International Conference on Web
Intelligence, 2003.
[Yil97] T. Yildirim. Intensional html. Master’s thesis, Department of Computer
Science, Univerity of Victoria, 1997.