=Paper=
{{Paper
|id=Vol-533/paper-4
|storemode=property
|title=Modelling autonomic dataspaces using answer sets
|pdfUrl=https://ceur-ws.org/Vol-533/06_LANMR09_03.pdf
|volume=Vol-533
|dblpUrl=https://dblp.org/rec/conf/lanmr/Montiel-MorenoZV09
}}
==Modelling autonomic dataspaces using answer sets==
https://ceur-ws.org/Vol-533/06_LANMR09_03.pdf
Modelling autonomic dataspaces using answer
sets
Gabriela Montiel-Moreno1 and José Luis Zechinelli-Martini1 and Genoveva
Vargas-Solar2
1
Research Center of Information and Automation Technologies
Universidad de las Américas, Puebla,
Sta. Catarina Mártir s/n, 72820, San Andrés Cholula, México
2
French National Council of Scientific Research
Laboratory of Informatics of Grenoble
681 rue de la Passerelle, BP 72, Saint Martin d’Hères, France
Abstract. This paper presents an approach for managing an autonomic
dataspace, able to automatically define views adapted for fulfilling the
requirements of a set of users, and adjust them as the dataspace evolves.
An autonomic dataspace deals with incomplete knowledge to manage
itself because of the heterogeneity and the lack of metadata related to
the resources it integrates. Our approach exploits the expressiveness of
stable models and the K action language for expressing the dataspace
management functions This paper proposes a model for specifying an
autonomic dataspace using answer set programming. Answer set pro-
gramming (ASP) is a type of declarative logic programming particularly
useful in knowledge-intensive applications [1, 7, 8]. It is based on the sta-
ble semantics (answer sets), which allows negation as failure and applies
the ideas of auto-epistemic logic to distinguish between what is true and
what is believed.
1 Introduction
The increase in the production and spread of data and applications around the
Web introduces new challenges related to their management and exploitation.
Users continuously produce and exploit resources in different formats defined
according to the models used by their producers and their applications, and may
provide different computing and search capabilities. Moreover, certain resources
may be characterized with description of their structure and content.
Users around the Web exploit a certain set of resources and develop new
knowledge. For example, consider the personal information managed by Alice,
consisting of images, documents, web pages, applications, etc. Suppose Alice
wants to write the state of art of her dissertation on Dataspaces management.
Therefore, Alice must explore and analyse every resource stored in the servers
she accesses in order to define the bibliography she needs. This task is long
and complex because resources may not provide metadata, or may be described
under a different vocabulary than the one used by Alice.
61
The notion of dataspace arises as a possible solution to this requirement by
defining a dynamic virtual environment publishing, accessing, and managing a
set of heterogeneous and distributed resources (data or services) shared by dif-
ferent communities of users [6, 9]. A dataspace is fed when users publish new
resources, and when new information is generated as a result of the exploitation
of resources. Dataspaces have an associated platform (DSSP) that provides ser-
vices for managing heterogeneous resources having different models and querying
than in a coordinated and controlled way [6, 9].
However, the dynamicity and autonomy of the components of a dataspace
causes the participants to continually analyse the dataspace in order to verify
the availability and the subscription of new resources potentially useful to their
activities. To illustrate this situation, reconsider the consider that Alice has
already defined her bibliography after analysing her dataspace. Suppose that
her advisor uploads a new document relevant to Alice after this process. In
order to incorporate this resource, Alice must analyse after certain period of
time if new resources have been published and if any is relevant to her state
of art. This task is hard and difficult to achieve if we consider the continuous
evolution of her dataspace. Additionally, if Alice modifies her requirement she
must query again the dataspace to retrieve the pertinent information.
These reasons motivate us to build a dataspace that must adapt itself res-
pect to its evolution, by automatically defining and executing strategies that
optimize its behaviour. An autonomic dataspace auto-manages itself by defining
automatically views and adjusting them as the dataspace evolves. To achieve
this, a dataspace must provide a set of services satisfying the following auto-
nomic properties [10, 11]:
– Auto-configuration. The DSSP configures its components automatically
according to its evolution. This configuration must respect a set of policies
describing the correct behaviour of a dataspace for ensuring its consistency.
– Auto-optimization. An autonomic dataspace analyses continuously the
behaviour of its components to make decisions about the execution of ope-
rations and to optimize the access and exploitation of its resources.
– Auto-healing. The DSSP automatically detects failed resources and imple-
ments recovery strategies avoiding the interruption of its services.
– Auto-protection. A DSSP detects, identifies and protects itself automa-
tically from attacks. It avoids access to resources prohibited according to
access control constraints.
1.1 Related works
A DSSP can deal with incomplete knowledge about resources for answering
queries. [14, 13] propose the definition of a global logic view of information
contained in the dataspace through the definition of relevant objects and asso-
ciations between these objects. [13] defines and enriches approximate meta-data
and semantic relations between resources as the dataspace evolves, as queries are
executed and as users qualify them over time. [14] maintains a set of schemas
62
modelling resources respect to a specific domain and store them in information
repositories organized by topic.
Our approach towards an autonomic dataspace is done by extending the
DSSP management platform with a set of services:
1. A resource indexation structure [3, 13, 14, 20] that organizes resources accor-
ding to the terms used in their annotations and defines mappings between
those terms.
2. An autonomic view manager that automatically triggers actions to configure
views respect to the presence of events over the resources and the partici-
pants.
1.2 Contribution and organization of the paper
We specify the main components of this dataspace and describe our approach
towards the auto-configuration of views exploiting the expressiveness of stable
model semantics [8]. Stable model semantics is used for modelling the knowledge
of the dataspace and the K action language [5] is used for representing the actions
and events related to the auto-management strategies in the dataspace.
The remainder of the paper is organized as follows. Section 2 and 3 describes
our model to characterize a dataspace, views over dataspaces and their ope-
rations using language Answer Set Prolog [1] and the K action language [17].
Section 4 specifies the auto-configuration functions for a dataspace. Section 5
presents our current implementation. Finally, Section 6 concludes this paper
and describes our future work.
2 Modelling an autonomic dataspace
In our approach, an autonomic dataspace is represented as a tuple dataspace
(Participants, Resources, Events) where Resources represents a set of re-
sources subscribed into the dataspace, Participants characterizes the set of
participants publishing or exploiting resources in the dataspace, and Events
represent a set of events characterizing the evolution of the dataspaces compo-
nents along time.
We model the components of the dataspace (resources, participants) as pre-
dicates in Answer Set Prolog language [1]. Events are modeled as fluents in the
K action language [5]. Fluents express a property of an object in a world and
form part of the Resource of states of the world. Fluents keep their truth values
during time unless they are explicitly affected by an action.
2.1 Participants
Participants defined by the predicate participant(ParticipantName) repre-
sent individuals providing or consuming a set of resources to generate new in-
formation or execute a particular activity. Participants in a dataspace can be
63
organized into communities.
Community represents a group of participants sharing similar interests about
certain knowledge domains. Communities are formally defined with the predicate
community(Community) where Community represents the name of the commu-
nity. The members of a certain community are specified using a set of predicates
belongsTo(ParticipantName, Community).
(2.1) ← community(Community),
!count {Participant : belongsTo(Participant, Community)}< 1.
(2.2) ← participant(Participant),
!count {Community : belongsTo(Participant, Community)}< 1.
A community must have at least one participant (2.1) and every participant
must belong to at least one community (2.2). According to the communities
he/she belongs, a participant has access to a certain sub-space of resources over
which he/she can execute queries or operations.
Every community has at least one associated vocabulary used for specifying
queries over the dataspace. This association is formally defined with the predi-
cate hasVocabulary(Community, Vocabulary).
Vocabulary represents a set of terms belonging to a specific knowledge do-
main, e.g. Computer Science. They are formally defined as a set of predicates
vocabulary(Vocabulary, Domain, Term), where Vocabulary represents the
identifier of the specific vocabulary, Domain its knowledge domain, and Term a
specific term belonging to the vocabulary. Communities must have at least one
associated vocabulary (2.3).
(2.3) ← community(CommunityName),
!count {Vocabulary : hasVocabulary(Community, Vocabulary)} < 1.
Participants in the dataspace exploit their resources according to a set of
requirements expressed using terms of the vocabularies. This association is for-
mally defined using a fluent hasRequirement(ParticipantName, Requirement)
where ParticipantName represents the name of the participant defining the re-
quirement RequirementID.
Requirement is represented as a set of fluents requirement(Requirement,
Term), where each predicate states that a Term describes a specific requirement
Requirement used for defining a query on the dataspace.
2.2 Resource
Resources in a dataspace can represent a data source, an application or a Web
service subscribed into the dataspace. Resources are defined using the predi-
cate resource(ResourceName, URI, Type) which is characterized with a name
64
ResourceName, an universal resource identifier (URI) specifying the way the re-
source can be accessed, and a Type, e.g. document, image, or application.
According to its type, a resource has associated meta-data describing its
structure. For instance, a document resource can be described with the at-
tributes: title, description, words number, related topics and format (pdf, word,
latex, plain text) using a predicate document(Resource, Title, Description,
TotalWords, Topic). Additionally, a resource may provide data related to its
producer, the operations it provides, and its content.
Producer represent participants providing a resource specified using the predi-
cate hasProducer(Resource, Producer), where Producer represents the name
of the participant providing the Resource.
(2.4) ← hasProducer(Resource, Producer),
not resource(Resource, URI, Type).
uri(URI), format(Type).
(2.5) ← hasProducer(Resource, Producer),
not participant(Producer).
The association between a resource and a producer cannot exist if a resource
is not defined (2.4). The association between a resource and a producer cannot
exist if the producer is not defined as a participant (2.5).
Operation According to its type, a resource may provide a set of operations over
its data. An operation is modelled with the predicate operation(OperationName,
Type). Every operation in the dataspace must be associated to at least one re-
source within the dataspace using the predicate hasOperation(ResourceName,
OperationName).
Additionally, an operation can be defined by a set of input and output pa-
rameters. Input and Output parameters are modelled through predicates of
the form parameter(ParameterName, DataType), where a ParameterName ex-
presses the name of the parameter and DataType represents the abstraction
of basic data types, i.e. boolean, real, integer, string, or double. An opera-
tion is associated to its input and output parameters using a set of predicates:
hasInput/Output(Operation, Parameter, Order), where Order specifies the
position of the parameter within the operation.
Annotations represent the description of a resource using a set of terms from
a specific vocabulary domain, i.e. Computer Science. Annotations are expressed
as a set of predicates annotation(Annotation, Term) stating that a term Term
from a specific vocabulary describes a specific Annotation.
An annotation can not be defined by a specific positive or negative literal (2.6)
and it cannot be expressed using two terms TermA and TermB that contradict
themselves, i.e. good and bad (2.5).
65
(2.6) ← annotation(AnnotationID, Term),
not annotation(AnnotationID, Term), term(Term).
(2.7) ← annotation(AnnotationID, TermA),
annotation(AnnotationID, TermB),
contradicts(TermA, TermB).
A resource can have several annotations defined under different vocabularies
and they can be inconsistent between each other. The association of an annota-
tion with a specific resource is represented using the predicate hasAnnotation
(Resource, Author, Annotation).
(2.8) ← hasAnnotation(Resource, Author, Annotation),
not resource(ResourceName, URI, Type).
uri(URI), format(Type).
(2.9) ← hasAnnotation(Resource, Author, Annotation),
not annotation(AnnotationID, Term), term(Term).
An annotation can be only associated to resources that have been previously
defined in the dataspace (2.8). Resources can be associated to a certain annota-
tion if and only if it has been previously defined and it is composed by at least
one term (2.9).
2.3 Events
Events in the dataspace represent changes over the dataspace at a given in-
stant. Events are modelled as fluents in K action language [5] of the form
evenName(Timestamp, Producer, Delta), where Timestamp represents the ti-
me in which the event was produced [19]. Additionally, an events is characterized
specifying its producer and additional information described by a set Delta, e.g.
the terms added and deleted from an annotation when it has been updated. We
classify the events of the dataspace with respect to the entity over which they
are produced: resource and participant.
2.4 Resources index
The resource index of an autonomic dataspace is composed of three layers: (i)
physical that organizes resources into physical storage, (ii) logical that classifies
the resources according to the terms used in their annotations, and (iii) external
composed by a set of terms and relations between terms. The index is out of the
scope of this paper. Interested readers can refer to [12].
3 View
Resources in a dataspace can be organized into sub-spaces named views. A view
represents a set of resources satisfying a participant’s requirement [16]. Views
66
allow to have different perspectives from resources in the dataspace. As a view
changes automatically in response to the events of the dataspace,it is modelled as
fluents characterized with an integer identifier viewID. The fluent view(ViewID,
Term, Resource) states that a view with an identifier ViewID uses a resource
Resource under the semantic defined by Term.
A view has two main parts: a semantic, and an extension. The semantic
represents the content of the view expressed through a set of terms belonging to
multiple vocabularies. Every term in the semantic of the view must be mapped
(equivalence, generalization, etc.) to at least one term in the requirement of the
view.
The extension represents the set of resources relevant to the problem dealt
within the view. A resource is relevant to the view if it is indexed by a subset of
terms (or related terms) from the requirements associated to the view. A specific
resource Resource using the term Term can be a component of the view if and
only if the resource has an annotation described by this term, and the term is
related to the view’s requirements.
Because of the heterogeneity of resources in a dataspace, it can be possible
that a resource provides an incorrect annotation of its content, or it does not
provide any annotation at all. Views may not be complete with respect to the
requirements of a participant, because resources can have imprecise or incorrect
associated annotations.
A view must be associated to at least one requirement defined by a participant
in certain period of time through the fluent respondsTo(View, Requirement).
The requirement and the view must be previously defined. The association bet-
ween a participant and a specific view is modelled with the fluent hasView
(Participant, Requirement, View). This association can be defined if and
only if the participant is connected in the dataspace and the participant has
been previously associated to the view’s requirement.
3.1 Operation on views
Inspired in relational algebra and set theory, we propose a family of operations
over views. Because operations produce effects over the current state of views,
we model them as actions in the K action language [5].
3.2 Resource insertion/removal - insertR/deleteR(Resource, View).
These operations update a View by adding (or removing) a Resource and its
associations with terms related to the requirements of the view.
Requirements: (i) The view must have been previously defined, and (ii) the
resource to be inserted (or removed) must be defined in the dataspace.
insertR/deleteR(Resource, View)
requires view(View, ViewTerm, ViewResource), (i)
resource(Resource, URI, Type). (ii)
67
Execution conditions: The resource to be inserted (or removed) has been previ-
ously defined and indexed using at least one term related to the view’s require-
ments.
executable insertR/deleteR(Resource, View)
if respondsTo(View, ReqID),
requirement(ReqID, ReqTerm),
isIndexed(Resource, IndexTerm),
mapping(IndexTerm, ReqTerm).
Effects: A View is updated by adding (or negating) a set of fluents view(View,
IndexTerm, Resource). This fluent states that the Resource indexed with
IndexTerm forms part of the view and satisfies the view’s requirements expressed
with ReqTerm.
caused view(View, IndexTerm, Resource)/
-view(View, IndexTerm, Resource)
if isIndexed(Resource, IndexTerm),
responds(View, ReqID),
requirement(ReqID, ReqTerm),
mapping(IndexTerm, ReqTerm)
after insertR/deleteR(Resource, View).
3.3 Vocabulary insertion/removal - insertV/deleteV(Vocabulary,
View).
This operation updates a View by adding (or removing) the terms of a Vocabulary
and their indexed resources as elements of the view.
Requirements: (i) The view must have been previously defined, and (ii) the
vocabulary to be inserted must have been defined and composed by at least one
term.
insertV/deleteV(Vocabulary, View)
requires view(View, Term, Resource), (i)
vocabulary(Vocabulary, Domain, VocTerm). (ii)
Execution conditions: There exists at least one term in the vocabulary that is
related to one from the view’s requirements.
executable insertV/deleteV(Vocabulary, View)
if responds(View, ReqID),
requirement(ReqID, ReqTerm),
vocabulary(Vocabulary, Domain, VocTerm),
mapping(VocTerm, ReqTerm).
68
Effects: The View is updated by adding (or negating) a set of fluents view(View,
IndexTerm, Resource). This fluent states that the Resource indexed with
VocTerm belonging to the Vocabulary to be inserted forms part of the view
and satisfies the view’s requirements expressed with ReqTerm.
caused view(View, VocTerm, Resource)/
-view(View, VocTerm, Resource)
if responds(View, ReqID),
requirement(ReqID, ReqTerm),
vocabulary(Vocabulary, Domain, VocTerm),
mapping(VocTerm, ReqTerm),
resource(Resource, URI, Type),
isIndexed(Resource, VocTerm)
after insertV/deleteV(Vocabulary, View).
3.4 View Projection - filter(Vocabulary, ViewA, ViewB).
This operation produces a new view composed of all the elements from a view
(terms and associated resources) that are related to at least one term of the
vocabulary.
Requirements: (i) The view ViewA must have been previously defined, (ii) the
vocabulary must have been defined and composed by at least one term, and the
view ViewB must not have been defined.
filter(Vocabulary, ViewA, ViewB)
requires view(ViewA, TermA, ResourceA), (i)
vocabulary(Vocabulary, Domain, ViewTerm), (ii)
not view(ViewB, TermB, ResourceB). (iii)
Execution conditions: There exists a VocTerm in the vocabulary that is related
to a TermA in views A’s requirements.
executable filter(Vocabulary, ViewA, ViewB)
if respondsTo(ViewA, ReqA),
requirement(ReqA, TermA),
vocabulary(Vocabulary, Domain, VocTerm),
mapping(VocTerm, TermA).
Effects: A ViewB is created by defining a set of fluents of the form view(ViewB,
TermA, ResourceA). This fluent states that the ResourceA described with TermA
is related to a VocTerm of the vocabulary. View B’s requirement is composed by
all VocTerm of the vocabulary related to at least one term of view A’s require-
ment.
69
caused view(ViewB, TermA, ResourceA)
if view(ViewA, TermA, ResourceA),
vocabulary(Vocabulary, VocTerm),
mapping(VocTerm, TermA)
after filter(Vocabulary, ViewA, ViewB).
3.5 Union - union(ViewA, ViewB, ViewC).
Produces a new ViewC including all the elements from ViewA and ViewB.
Requirements: (i) The views ViewA and ViewB must have been previously de-
fined, and (iii) the view ViewC must not have been defined.
union(ViewA, ViewB, ViewC)
requires view(ViewA, TermA, ResourceA), (i)
view(ViewB, TermB, ResourceB),
not view(ViewC, TermC, ResourceC). (ii)
Execution conditions: This operation has no execution conditions.
Effects: A ViewC is created by defining a set of fluents of the form view(ViewC,
Term, Resource) where Resource is an element of ViewA or ViewB described
with Term. View C’s requirement is composed by all TermA and TermB from the
requirements of views A and B respectively.
caused view(ViewC, Term, Resource)
if view(ViewA, Term, Resource)
after union(ViewA, ViewB, ViewC).
caused view(ViewC, Term, Resource)
if view(ViewB, Term, Resource)
after union(ViewA, ViewB, ViewC).
3.6 Intersection - intersection(ViewA, ViewB, ViewC).
Produces a new ViewC including all elements from ViewA that are related to at
least one element of the ViewB and vice versa.
Requirements: (i) The views ViewA and ViewB must have been previously de-
fined, and (iii) the view ViewC must not have been defined.
intersection(ViewA, ViewB, ViewC)
requires view(ViewA, TermA, ResourceA), (i)
view(ViewB, TermB, ResourceB),
not view(ViewC, TermC, ResourceC). (ii)
70
Execution conditions: There exists a ReqATerm in view A’s requirements that is
related to a ReqBTerm in views B’s requirements.
executable intersection(ViewA, ViewB, ViewC)
if respondsTo(ViewA, ReqA),
requirement(ReqA, ReqATerm),
respondsTo(ViewB, ReqB),
requirement(ReqB, ReqBTerm),
mapping(ReqATerm, ReqBTerm).
Effects: A ViewC is created by defining a set of fluents of the form view(ViewC,
Term, Resource) where Resource is an element of ViewA and ViewB described
with Term. View C’s requirement is composed by all TermA from the requirements
of view A related to at least one term in view B’s requirements and vice versa.
caused view(ViewC, TermA, ResourceA),
view(ViewC, TermB, ResourceB)
if view(ViewA, TermA, ResourceA),
view(ViewB, TermB, ResourceB),
mapping(TermA, TermB)
after intersection(ViewA, ViewB, ViewC).
3.7 Difference - difference(ViewA, ViewB, ViewC).
Produces a new ViewC including all the elements from ViewA that are not related
to any element in the ViewB.
Requirements: (i) The views ViewA and ViewB must have been previously de-
fined, and (iii) the view ViewC must not have been defined.
difference(ViewA, ViewB, ViewC)
requires view(ViewA, TermA, ResourceA), (i)
view(ViewB, TermB, ResourceB),
not view(ViewC, TermC, ResourceC). (ii)
Execution conditions: There exists a ReqATerm in view A’s requirements that is
not related to any term in view B’s requirements.
executable difference(ViewA, ViewB, ViewC)
if respondsTo(ViewA, ReqA),
requirement(ReqA, ReqATerm),
not inR(ReqATerm, ViewB),
not view(ViewC, TermC, ResourceC).
71
Effects: A ViewC is created by defining a set of fluents of the form view(ViewC,
Term, Resource) where Resource is an element of ViewA and not of ViewB
and is described with Term. View C’s requirement is composed by all TermA
from the requirements of view A that are not related to any term in view B’s
requirements.
caused view(ViewC, TermA, ResourceA)
if view(ViewA, TermA, ResourceA),
not in(TermA, ViewB)
after difference(ViewA, ViewB, ViewC).
4 Auto-configuration of views
The auto-configuration of views involves the creation and execution of view
management plans over views respect to the presence of events. Through this
autonomic configuration is possible to automatically define new views when a
participant specifies new requirements, update views when resources are sub-
scribed or removed, and delete views when they are no longer required.
An autonomic view manager executes the auto-configuration task and is
composed of three main components: a monitor, an evaluator, and an executer
[10, 11, 16]. The monitor observes continuously the evolution of the dataspace
looking up the presence of events over the resources or the requirements specified
by the participants. When a new event is detected, it is notified to the evalua-
tor. The evaluator identifies the views that are potentially affected by the event
and the strategy that is associated to the event. With these data, the evaluator
determines the actions that have to be executed over the views and generates
a view management plan. This plan contains all the information about the ac-
tions that have to be executed and their order. Finally, this plan is sent to the
executer, who is in charge to execute the operations over the views and validate
the coherence of the new state of the dataspace.
The auto-configuration of views is achieved through the definition of a set
of management strategies respect to the presence of events over resources and
views. Our auto-configuration strategies are organized in three categories:
4.1 Auto-definition
This category refers to all the strategies related to the definition of views within
the dataspace when an event of RequirementAdded is detected. In this case, the
autonomic view manager must detect the participant producing this event and
the requirement that has been inserted. The management platform must define
a new view based on previous defined views or by executing a search using the
index.
72
4.2 Auto-update
The main objective of this category of strategies is to automatically update the
set of views respect to the presence of events produced over the resources and the
participant like: resource subscription, annotation insertion, update or removal,
resource removal and update of the requirements from a participant.
For doing so, it is necessary that the management platform identifies all the
views v1 , . . . , vn that are partially or totally described by the terms contained in
the annotation of the resource involved in the event or the modified requirements.
4.3 Auto-removal
This category refers to the strategies related to the elimination of views within
the dataspace when an event of RequirementDeleted is detected. In this case,
the management platform must detect the participant producing this event and
the requirement that has been removed. Using the requirement identifier, the
management platform must identify the view associated to the requirement and
delete the view from the dataspace. In case another participant is consuming the
view, the management platform should delete only the association between the
participant and the view.
5 Implementation issues
In order to validate our approach we implemented an autonomic view manager
oriented to personal dataspaces. A personal dataspace integrates heterogeneous
and distributed resources produced by an individual to be exploited by her/him
and her co-workers [18].
We implemented a background knowledge base containing the components
and structure of Alices personal dataspace using the datalog programming sys-
tem DLV [4]. Events, views, operations and strategies were implemented as a
planning program in DLV-K planning system [17].
The strategies defined over the auto-configuration of views were modelled as
a set of Event-Condition-Action rules in the planning program. By expressing
the strategies as Event-Condition-Action rules, we could exploit the capabilities
of planning programming to determine the sequence of actions and the state of
the dataspace under the presence of events in a period of time.
We have currently validated the correct execution of strategies related to the
auto-update and auto-removal in the autonomic and requirement-based personal
dataspace, as well as the operations over views. We are currently implementing
the auto-definition strategies in DLV-K and defining an approximation algorithm
to optimize the definition of views based on predefined views under the JAVA
platform version 1.5.0.
73
6 Conclusions
This paper presented our characterization of an autonomic and requirement-
based dataspace using answer sets programming. An autonomic and requirement-
based dataspace is a system that auto-manages itself according to the evolu-
tion of its resources and participants. Thanks to an autonomic dataspace, users
can integrate heterogeneous resources (data and applications) and exploit them
through the definition of views representing sub-spaces of resources adapted res-
pect to their requirements [16].
Our approach exploits the expressiveness of stable models semantics [8] to
model incomplete knowledge within its components and the K action language
[5] to represent the actions and events related to the auto-management strategies
in the dataspace. The action logic-based language K is used for modelling ope-
rations over views as actions and representing the view management strategies
as sequences of actions triggered given a set of events [1, 5].
Currently, we have implemented a first version of the management plat-
form in the area of personal management. This version was implemented us-
ing DLV-K [17], an extension of DLV datalog programming system for planning
based on answer sets. Future work relies on the definition of strategies for the
auto-optimization, auto-protection and auto-repair in the dataspace. Also, it is
necessary to develop strategies to fulfil the autonomic properties to the index
structures so they are automatically configured respect to the evolution of the
environment.
Once we complete these implementations, we will validate the performance
of our system with a highly dynamic environment having multiple predefined
views . Through these experiments we will be able to determine the efficiency of
our solution and the cost related to achieving autonomy in such a variable and
increasing environment.
References
1. Chitta Baral. Knowledge Representation, Reasoning, and Declarative Problem
Solving, chapter Reasoning about actions and planning in AnsProlog, pages 1–
30. Cambridge University Press, New York, NY, USA, 2003.
2. Gennaro Bruno. “ADEMS” a knowledge-based service for intelligent mediator con-
figuration. PhD thesis, Institut National Polytechnique de Grenoble, 2006.
3. Xin Dong and Alon Halevy. Indexing dataspaces. In 2007 ACM SIGMOD in-
ternational conference on Management of data (SIGMOD ’07), pages 43–54, New
York, NY, USA, 2007. ACM Press.
4. Robert Bihlmeyer, Wolfgang Faber, Giuseppe Ielpa, Vincenzino Lio, and Gerald
Pfeifer. DLV User Manual. The DLV Project, April 2009.
5. Thomas Eiter, Wolfgang Faber, Nicola Leone, Gerald Pfeifer, and Axel Polleres.
Planning under incomplete knowledge. In Computational Logic, volume 1861 of
Lecture Notes in Computer Science, pages 807–821, New York, NY, USA, 2000.
Springer Verlag.
74
6. Michael J. Franklin, Alon Y. Halevy, and David Maier. From databases to datas-
paces: a new abstraction for information management. ACM SIGMOD Records,
34(4):27–33, 2005.
7. Michael Gelfond. Handbook of Knowledge Representation, chapter Answer Sets.
8. Michael Gelfond and Vladimir Lifschitz. The stable model semantics for logic
programming. In Proceedings of the 5th International Conference on Logic Pro-
gramming (LPAR 1988), pages 1070–1080, 1988.
9. Alon Halevy, Michael Franklin, and David Maier. Principles of dataspace systems.
In Proceedings of the 25th ACM SIGMOD-SIGACT-SIGART symposium on Prin-
ciples of database systems (PODS ’06), pages 1–9, New York, NY, USA, 2006.
ACM Press.
10. Paul Horn. Autonomic computing: Ibm’s perspective on the state of information
technology. Technical report, IBM Corporation, Riverton, NJ, USA, 2001.
11. Markus C. Huebscher and Julie A. McCann. A survey of autonomic computing -
degrees, models, and applications. ACM Computing Surveys (CSUR), 40(3):1–28,
2008.
12. Carlos-Manuel López-Enrı́quez, Genoveva Vargas-Solar, José-Luis Zechinelli-
Martini, and Ofelia Cervantes. Indexing dataspaces: dealing with content and
storage space. RCS, September 2009.
13. Shawn R. Jeffery, Michael J. Franklin, and Alon Y. Halevy. Pay-as-you-go user
feedback for dataspace systems. In Proceedings of the 2008 ACM SIGMOD inter-
national conference on Management of data (SIGMOD ’08), pages 847–860, New
York, NY, USA, 2008. ACM Press.
14. Jayant Madhavan, Shirley Cohen, Xin Luna Dong, Alon Y. Halevy, Shawn R. Jef-
fery, David Ko, and Cong Yu. Web-scale data integration: You can afford to pay
as you go. In CIDR, pages 342–350, 2007.
15. Gabriela Montiel-Moreno, José-Luis Zechinelli-Martini, and Genoveva Vargas-
Solar. Sisels: a mediation system for giving access to biology resources. Journal
Research in Computing Science Special Issue: Electronics and Biomedical Engi-
neering, Computer Science and Informatics, 35, 2008.
16. Mohammad Reza Nami and Mohsen Sharifi. A survey of autonomic computing
systems. In Proceedings of the Intelligent Information Processing, volume 228,
pages 101–110, New York, NY, USA, 2007. Springer Verlag.
17. Axel Polleres. The dlvk system for planning with incomplete knowledge. Mas-
ter’s thesis, Institut fr Informationssysteme, Technische Universitt Wien, Vienna,
Austria, February 2001.
18. Marcos A. Vaz Salles, Jens P. Dittrich, Shant K. Karakashian, Olivier R. Girard,
and Lukas Blunschi. itrails: Pay-as-you-go information integration in dataspaces.
In Proceedings of the 33rd international conference on Very large data bases (VLDB
’07), pages 663–674. VLDB Endowment, 2007.
19. Genoveva Vargas-Solar and Christine Collet. Adees: An adaptable and extensi-
ble event based infrastructure. In 13th International Conference on Database and
Expert Systems Applications (DEXA 2002), volume 2453 of Lecture Notes in Com-
puter Science, pages 423–432, New York, NY, USA, 2002. Springer.
20. Cathrin Weiss, Panagiotis Karras, and Abraham Bernstein. Hexastore: sextuple
indexing for semantic web data management. Proceedings of the VLDB Endow-
ment, 1(2):1008–1019, 2008.
75