A Semantic Solution for Data Integration in Mixed Sensor Networks

Transcription

1 A Semantic Solution for Data Integration in Mixed s Ismail Khalil Ibrahim, Reinhard Kronsteiner, Gabriele Kotsis Teleccoperation Department, Johannes Kepler University Linz, Altenberger Str. 69, A-4040 Linz, Austria Tel.: Fax: {ismail; reinhard; gk}@tk.uni-linz.ac.at Abstract The number of sensors deployed for a myriad of applications is expected to increase dramatically in the coming few years. This is spurred by advances in wireless communications and the growing interest in wireless sensor networks. This growth will not only simplify the access to information sources but also will motivate the creation of numerous new ones. Paradoxically, this growth will make the task of getting meaningful information obtained from disparate sensor nodes not a trivial one. On the one hand, traffic overheads and the increased probabilities of hardware failures make it very difficult to maintain an always-on, ubiquitous service. On the other hand, the heterogeneity of the sensor nodes makes finding, extracting, and aggregating data at the processing elements and sink nodes much harder. These two issues (in addition to distribution, dynamicity, accuracy, and reliability issues) impose the need for a more efficient and reliable techniques for information integration of data collected from sensor nodes. In this paper, we first address the issues related to data integration in wireless sensor networks with respect to heterogeneity, dynamicity, and distribution at both the technology and application levels. Second, we present and discuss a query processing algorithm which make use of the semantic knowledge about sensor networks expressed in the form of integrity constraints to reduce network traffic overheads, improve scalability and extensibility of wireless networks and increase the stability and reliability of networks against hardware and software failures. Third, we discuss a scenario of what we believe a uniform interface to data collected from sensor nodes that will map sensor specific data to the global information source based on a context exported by the data integration system Keywords: sensor networks, agents, data integration 2. Introduction The vision of a smart environment [33] [34] where hundreds of thousands of ad hoc tiny sensor nodes spread over a geographical area and collaborate with each other to establish a sensing network is spurred by advances in hardware and wireless network technologies. A sensor network can provide access to information anytime, anywhere by collecting, processing, analyzing and disseminating data. Thus, the network actively participates in creating the smart environment. This is because of their reliability, accuracy, flexibility, cost effectiveness and ease of deployment [33]. Challenges in hardware design, communication protocols and applications design face sensor network technology to make it a reality. In addition to the frequent changes in networks topology, the use of a broadcast communication paradigm instead of point-to-point communication, power limitations, prone to failures, no global identification, dense deployment in terms of collision and congestions, to mention a few [34]. Other challenges include: Reachability: how to find, extract, aggregate information [21] Dynamic environmental conditions require the system to adapt over time to changing connectivity and system stimuli. Ad hoc deployment requires that the system identifies and copes with the resulting distribution and connectivity of nodes Heterogeneity: how data is captured, processed and managed. Heterogeneity of the software and hardware Autonomy: content and format of data are determined by the network owning the data not by the user The architecture illustrated in Figure 1 constitutes the blueprint for a sensor network that shows how sensors cooperate among themselves and how they disseminate and aggregate data [29]. A sensor network consists of a large number of sensor nodes (S). Individual sensor nodes are connected to other nodes in their vicinity through a wireless network, and

2 use a multi-hop routing protocol to communicate with nodes that are spatially distant. nodes also have limited computation and storage capabilities: a node has a general purpose CPU to perform computation and a small amount of storage space to save program code and data. We distinguish a group of nodes called clusters. Each cluster is managed by a cluster head (CH). Every cluster head is responsible of a group of child nodes in the cluster. When cluster heads receive queries from the aggregate nodes, they send the queries to the child nodes to get results and, in return, send back results to the aggregate nodes (AN). Child nodes communicate locally (i.e., within a cluster) with their counterparts or their cluster heads. Children in a cluster cannot communicate with cluster heads from other clusters whereas cluster heads can only communicate among themselves. AN CH 1 S1 S2 S3 AN Ch n Sn Aggregation Node Cluster Head pushed into the sensor network (e.g. aggregating records, or eliminating irrelevant records). In-network processing can reduce energy consumption and reduce bandwidth usage by replacing more expensive communication operations with relatively cheaper computation operations, extending the lifetime of the sensor network significantly [38]. For example, the ratio of energy spent in sending one bit versus executing one instruction ranges from 220 to 2900 in different architectures [30]. Different applications usually have different requirements [38] from accuracy, energy consumption, to delay. For example a sensor network deployed in a traffic control may only have a short lifetime but a high degree of dynamics compared to a habitat-monitoring network where power is the main concern. The reminder of the paper is organized as follows: in the next section we introduce a motivational scenario to show the importance of data integration in mixed sensor networks and to highlight the differences and commonalities between data aggregation and data integration systems. In section 3 we review different approaches to data integration and their relevance to sensor networks. In section 4 we present an algorithm for data integration in mixed sensor networks. Finally, we conclude with some remarks that make data integration in sensor networks different from other application domains. 3. Motivational Scenario Fig 1 Architecture The purpose of the research from which this paper stemmed is to develop a query layer for mixed wireless sensor networks where queries are expressed in a declarative way and the users pose queries without need to know how results are generated, processed and returned to the user. Sophisticated query processing and optimization techniques free the user from the need to locate relevant sensors, processing sensor data, and getting the results. The solution takes into account the very limited resources in wireless sensor networks especially those related to energy and bandwidth [38]. Data transmission back to a central node for offline storage, querying and data analysis is very expensive for sensor networks of no trivial size since communication using the wireless medium consumes a lot of energy. Since sensor nodes have the ability to perform local computations. Parts of the computation can be moved from the clients and Consider a road traffic information system where various sensors are used to manage traffic as efficient as possible. Those sensors are needed to measure the number of passing cars (to collect the tolls and inform about traffic jams) and the weather conditions (to trigger speed limits). Querying those sensors allows accurate reaction of the traffic control organization on the actual situation on the roads and long term strategic plans about traffic development. Nowadays most cars are also equipped with various sensors. A car knows about its speed (tachometer) and depending on its equipment on the actual location, distance to the next car, destination of the actual trip and the actual weather conditions. Actually the sensor network of the traffic control organization is not linked/networked with the sensor capabilities of individual cars (that can also be seen as a single sensor network) and also the sensor capabilities of a particular car can t communicate with other cars. Linking the sensors of both (cars and roads) into a collaborative mixed sensor network would bring a more complete view of the actual traffic situation and allow more efficient and higher quality decisions for both participants. According to [3] we distinguish queries on a mixed sensor network between historical queries, long running queries and snapshot queries. For efficient decision

3 support we need all three types of queries to achieve the maximum use of the available information. Historical queries allow statistical browsing over historical data for strategic planning. For the traffic control organization consider a construction site is necessary on a particular highway section. Knowing about the average traffic congestion for each moth in the last three years, the least disturbing time for a construction site can be identified via the minimum of upcoming traffic in a comparable period. For a motorist historic information about average speed helps to derive arrival at his/her destination and fuel consumption can help to decide for the next necessary stop on his/her trip. Long running queries are suited for permanent monitoring of particular parameters. The results of permanent monitoring can lead to accurate counter steering actions. In situations where the traffic control organization knows that the traffic congestion exceeds a particular limit (whenever the amount of cars passing a highway section exceeds 100 cars for example) automatically configuring speed limits (limit the maximum speed to 80 instead of 100 km/h) can avoid a traffic jam. The permanent monitoring of the cars sensors can inform the motorist of potential errors in the vehicle and therefore act immediately avoiding dangerous situations. E.g. if the fuel consumption exceeds a specific limit for a longer time (with no relation to the actual speed of the car) there could be a malfunction in the engine. Snapshot queries deliver an actual view on the situation of an environment. Those queries satisfy the demand of actual information in situations with special triggers to best support ad-hoc decisions. E.g. in an emergency case it is necessary to know which highway entry in a specific section has actually the lowest traffic congestions. The tachometer is a trivial example for a snapshot query that help the motorist for adjusted traveling. It delivers actual information about the situation without taking the history into account and triggering any events out of exceeded limits. 4. Information Mediation and Integration Strategies The goal of a data integration system is to provide a uniform interface to a multitude of data sources [4][8][19][22]. As an example, consider the task of providing information about the roads congested at a specific period of time due to heavy rainfall. Let us assume that we have two sensor networks, one provides us with traffic information (like location, cars per minute, and average speed) and another network which provides us with information about the weather like location, temperature and rainfall. Suppose we want to find which roads are congested (average speed is less than 50 km per hour) due to heavy rainfall. None of these sensor networks in isolation can answer this query. However, by combining data from multiple networks, we can answer queries like this one and even more complex ones. To answer our query, we would first send a query q 1 to Traffic to retrieve the Locations where the average speed is less than 50km per hour and then send another query q 2 to the Weather to retrieve locations where the rainfall is HEAVY. Finally, we join the results of the queries q 1 and q 2 to get the answer to our query. The query and how to obtain the results is depicted in Figure 2. SELECT road FROM Weather, Traffic WHERE AvgSpeed < 50 AND Rainfall = heavy Select road FROM Traffic WHERE AvGSpeed <50 Fig 2 Query Example SELECT road FROM Weather WHERE Rainfall = heavy The data integration problem can be stated as follows: Given a set of data sources schemas, provide a convenient interface to the data that efficiently gives the user correct, complete answers to her queries. The schema of data sources consists of the collections and relations in an actual or virtual data sets while the query is an expression indicating the data desired in term of the schema. Providing a query interface to the data has significant advantages in cost, scalability, and user acceptance over merging the sources into a monolithic whole. The interface can be layered on top of the sources, requiring no changes whatsoever to those systems. It is unnecessary to move the data or reorganize mission critical systems. Applications already using the data need not be changed. As sources are added and deleted, they can be incorporated into a query interface with minimal effort. In contrast, constructing a monolithic data store may not even be feasible due to the size and speed limitations of modern digital storage devices and transaction processing software. The grand challenge of data integration is to balance the expressiveness of languages for relating individual schemas and information needs of users, against the need for efficient algorithms. The most important advantage of a data integration system is that it enables users to focus on specifying what they want, rather than thinking about how to obtain the answers. As a result, it frees the users from the

4 tedious tasks of finding the relevant data sources, interacting with each source in isolation using a particular interface and then combining data from multiple sources. The main characteristic distinguishing data integration systems from distributed and parallel database systems is that the data sources underlying the system are autonomous. In particular, a data integration system provides access to pre existing sources that were created independently. Unlike multi-database-systems (see [24]) a data integration system must deal with the large and constantly changing set of data sources. These characteristics raise the need for richer mechanisms for describing the data and hence the opportunity to apply techniques from knowledge representation. In particular, a data integration system requires a flexible mechanism for describing contents of sources that may have overlapping contents, whose contents are described by complex constraints and sources that may be incomplete or only partially complete Data Aggregation Aggregation [25][34] refers to delivering data from distributed source sensor nodes to a central node for computation. The huge number of sensing nodes densely deployed in a small area may congest the network with data. To avoid this, some sensors such as the cluster heads can be used to aggregate data, do some computations (e.g., average, summation, highest, etc.,) and then broadcast the summarized information. These aggregate nodes can cache, process, filter the data to more meaningful information and resent it to the sink nodes. Aggregation in this way is useful for (a) increasing the circle of knowledge, (b) increasing level of accuracy and (c) data redundancy to compensate for sensor nodes failing [34]. A sensor node has one or more sensors attached that are connected to the physical world (examples are temperature sensors, light sensors, etc.). Thus each sensor is a separate data source that generates records with several fields such as the id and location of the sensor that generated the reading, a time stamp, the sensor type, and the value of the reading. Records of the same sensor type from different nodes have the same schema, and collectively form a distributed table. The sensor network can thus be considered a large distributed database system consisting of multiple tables of different types of sensors [39]. We believe that declarative queries are the preferred way of interacting with a sensor network. Most Aggregate queries derive their form from SQL [26]are of the form: SELECT {attributes} FROM {Senordata S} WHERE {predicate} GROUP BY {attributes} HAVING {predicate} Where the SELECT clause specifies attributes and aggregates from sensor records, the FROM clause specifies the distributed relation of sensor type, the WHERE clause filters sensor records by a predicate, the GROUP BY clause classifies sensor records into different partitions according to some attributes, and the HAVING clause eliminates groups by a predicate. Since most aggregate queries are event oriented, It is possible to extend the query template with additional clauses like DURATION and EVERY to support long running queries and periodic queries which specifies the lifetime of a query and the rate at which the query is applied respectively. It is also possible to have join queries by specifying several relations in the FROM clause [39]. A query plan for simple aggregate queries (queries without GROUP BY and HAVING clauses) can be divided into two components: a communication component where records from a set of distributed sensor nodes need to be delivered to a central aggregation node for aggregation and a computation component where the aggregate node computes the aggregate. Since power is the main design constraint when devising query-processing strategies for sensor networks, it is important to synchronize the communication and computation components of the query plans such that the number of messages exchanged can be reduced. This can be achieved [14] either by (a) direct delivery where each sensor node sends a data packet and it is the responsibility of the multi-hop ad-hoc protocol to deliver the packet to the aggregate node. Computation is only done at the aggregate node after all records are received or (b) packet merging where several records are merged and sent once since it is proven in wireless technology that sending smaller packets is more expensive than sending one large packet or (c) partial aggregation where intermediate nodes are used to compute partial results that contain sufficient statistics to compute the final result Data Integration In the research community, two approaches to building data integration systems [37] are based on the following two-step process: 1) Accept a query, determine the appropriate set of information sources to answer the query, and generate the appropriate sub queries or commands for each information source. 2) Obtain results from the information sources, perform appropriate translation, filtering, and merging of the information and return the final answer to the user or application. This process is refereed to as a virtual or on-demand approach (Figure 3) to data integration, since information

5 is extracted from the sources only when queries are posed. (This process also may be referred to as a mediated approach, since the module that decomposes queries and combines results often is the mediator.) Application Mediator Fig 3 Virtual Approach to data integration Source Description The second alternative is the materialization or inadvance approach (Figure 4) to data integration. In this approach: 3) Information from each source that may be of interest is extracted in advance, translated and filtered as appropriate, merged with relevant information from other sources and stored in a (logically) centralized repository. 4) When a query is posed, the query is evaluated directly at the repository without accessing the original information sources. This approach is referred to as data warehousing since the repository serves as a warehouse storing the data of interest. Application Data extraction Data warehouse Fig 4 Materialisation Approach to data integration A virtual approach to integration is appropriate for information that changes rapidly, for clients with unpredictable needs and for queries that operate over vast amounts of data from very large numbers of information sources (for example, the sensor networks). However, the virtual approach may incur inefficiency and delay in query processing, especially when queries are issued multiple times, when information sources are slow, expensive or periodically unavailable, and when significant processing is required for the translation, filtering, and merging steps. In cases where information sources do not permit ad hoc queries, the virtual approach is simply not feasible. In the warehousing approach, the integrated information is available for immediate querying and analysis by clients. Thus, the warehousing approach is appropriate for: (a) clients requiring specific predictable portions of the available information; (b) clients requiring high query performance but not necessarily over the most recent state of the information; (c) environments in which native applications at the information sources require high performance (large multi-source queries are executed at the warehouse instead) (d) clients wanting access to private copies of the information so that it can be modified, annotated, summarized, etc. and (e) clients wanting to save information that is not maintained at the sources (such as historical information). 5. Data Integration in Mixed s Several systems have been built with the goal of answering queries using a multitude of data sources (a.k.a. data integration systems). Many of the problems encountered in building these systems are similar to those addressed in building sensor networks. Data integration systems have, in addition, to deal with the large and evolving number of data sources, little metadata about the characteristics of the sources, and the larger degree of source autonomy. The purpose of a data integration system in wireless sensor networks is to provide a uniform query interface to a multitude of autonomous heterogeneous data sources. The sources may all belong to a single network or may be distributed over a wide geographic area. Furthermore, the sources may have different computing or communication capabilities. The goal of a data integration system is to free the user from having to find the data sources relevant to a query, interact with each source in isolation, and manually combine data from the different sources. Instead, a data integration system exposes a mediated schema on which users pose queries. A mediated schema is a set of virtual relations in the sense that they are not actually stored anywhere. The mediated schema is designed manually for a particular data integration application. To be able to answer queries, the system must first reformulate a user query into a query that refers directly to the schemas in the sources. In order to perform the reformulation step, the

6 data integration system requires a set of source descriptions. A description of a data source specifies the contents of the source, the attributes that can be found in the source, constraints on the contents of the source, completeness and reliability of the source, and the query processing capabilities of the source. A prototypical architecture of a data integration system is shown in Figure 5. Query in the union of global and local schemas Distributed query execution plan Query in the exported local schema Query in local schema Query in global schema Query reformulation Query Query execution plan Fig 5 Prototypical Architecture Query in local schema This architecture is based on the mediation architecture, shown in Figure 3 [22] and lists the major components of a data integration system. In response to a user query, the query-reformulator uses the applicable source descriptions to rewrite the original query over the schema into a high-level procedural plan for accessing the sources, known as logical plans. The reformulation algorithm used depends on the expressive power of the source descriptions and query languages. The logical plan contains queries to the relevant sources ordering constraints between those queries and data flow from the output of some source queries to the inputs of others. The optimizer is responsible for choosing an encoding of the logical plan as a lower level physical plan, using a variant of relational algebra. A relational algebra expression is a tree, whose internal nodes are database operators such as join, union, set difference, selection and projection and whose leaves are sources. Since numerous relational algebra expressions can be semantically equivalent to a logical plan, but vary enormously in their computational cost, optimization involves choosing a low cost encoding. The executor interprets and executes the physical plan. It communicates with the sources through wrappers or data extraction subroutines and does the local database operations called for the physical plan. The other components of a sensor network data integration system include an offline wrapper generator and modules for learning statistics and caching data. Each module does optional work that replaces a human activity or improves performance. A wrapper generator constructs a procedure to extract data from the source. It uses machine-learning techniques to identify syntactic patterns in the text given a few example text pages. One of the main differences between a data integration system and a traditional database system is that users pose queries in terms of a mediated schema. The data however, is stored in the data sources and organized under local schemas. Hence, in order for the data integration system to answer queries there must be some description of the relationship between the source relations and the mediated schema. The query processor of the integration system must be able to reformulate a query posed on the mediated schema into a query against the source schemas. Given the local schemas exported by the wrappers at the various sources and the global schema designed to give a uniform common reference to all users and applications, there are two approaches to the design of an integration solution [12]. The first approach, called Global As View (GAV), follows the traditional strategy developed for federated databases [32]. The global view is constructed by several layers of views on the relations exported by sources. Queries are expressed in terms of the global view and are evaluated in the conventional way. GAV is the approach of [13] or GESTALT [31], for instance. The second approach, called Local As View (LAV) considers that the relations exported by the sources are materialized views defined on virtual relations in the global schema. Queries are still expressed in terms of the global schema. In order to evaluate a query, a rewriting in terms of the component schemas needs to be found: this process is called Answering Queries Using Views (AQUV). LAV is the approach of the Information Manifold [20] and Infomaster [9]. The GAV and the LAV approaches can be qualitatively or quantitatively compared in terms of their adequacy (a) to model a particular integration situation, (b) to cope with autonomy of the sources (sources changing their exported schemas, joining or leaving the network) and their ability (c) to answer queries. The main arguments against the GAV approaches are that (a) it may not be able to model integration situations where sources are missing to build a complete world view; (b) it may stop to offer a complete global view as some sources become unavailable or services are disrupted [2]. In favor of GAV, it can be argued that most practical applications will require sufficiently simple global schemas (unions) to avoid such difficulties

7 and that there might be enough economic incentives in participating in the network to convince the sources managers to play the game. The strength of GAV is that if the modeling is successful, (c) all queries on the global schema are guaranteed to be answered and a complete answer can be constructed. The LAV approach, conversely, is designed to cope with a dynamic, possibly incomplete set of sources. The counterpart of this flexibility is that all queries may not be answered or only an incomplete answer can be found. It can be argued in favor of LAV that in large information infrastructures such as WWW, complete answers are rarely expected or needed by the users: better some answers than no answers Semantic Data Integration The idea of what is meant by semantic can be explained by using the similarity in programming languages. The syntax of the language specifies how the statements are formed out of basic textual elements. However, the syntax does not associate any meaning with the statements. A specification of how programming language statements act under all possible conditions, what the statements mean in terms of their effect, is known as the semantics of the language. The semantic modeling implies that in the ER approach we are getting into the topic of what data items really mean in order to model their behavior in terms of database structures such as relational tables. An important consequence of the local autonomy and heterogeneity of multi-database-systems is that semantically similar pieces of information may have very different names and different data structures in different local databases, based on user specifications and terminology preferences, and that providing transparent access to information from multiple databases is possible only if there is an intimate understanding of the local application, local data structures, and the semantics or meaning of data in each local system. Local applications are constructed by different users with varying levels of contextual domain knowledge. The contextual difference introduces subjective issues, which necessitates the need to tap into work done in the fields of artificial intelligence, knowledge representation, information systems, and linguistics as these areas have addressed semantics and their representation 5.2. Theoretical Background: Subsumption, Containment, and Equivalence The theoretical foundation relevant to this line of work can be found in the notion of subsumption [6] and the various forms of equivalence and containment for logic programs ([27], Chap. 16,17). A literal P subsumes a literal P [6] if there exists a substitution of the variables in P such that (P ) is identical to P. A clause Q subsumes a clause Q if there exists a substitution so that (Q) is a subclause of Q. I.e. if each literal in (Q) is identical to a literal in Q. A very similar notion was introduced by database researchers [35] and is known as containment mapping. Subsumption, or containment mapping are the syntactical counterpart of various semantic notions of containment and equivalence ([27],Chap. 16). From a database point of view, a conjunctive query q is contained in a conjunctive query q if q produce a subset of the set of results produced by q for every database, q q. They are equivalent, q q if they produce the same set of results. Decidability and complexity results are scattered in the logic programming and database literature. As far as this paper is concerned, the main results are discussed in [19]. [1] also gather comprehensive set of basic results with proofs Semantic Query Transformation We use the following example throughout this section to illustrate how semantic knowledge about sensor network can help answering queries that are undecideable otherwise. The example is adapted from [10][11]. Example: Suppose we have the following relations in the mediated schema traffic(location, Cars) detour(location, Rain) weather(cars, Rain, Detour) describing traffic information for a specific location where a detour is needed in case of some level of rainfall and/or in case the number of cars passing some point exceeds the maximum number that may result in traffic jam. A location is only identified by the maximum number of cars and the Rainfall levels. Also, in a given rainfall conditions and traffic level, a detour is specified. Therefore, we have three functional dependencies: traffic: Location Cars detour: Location Detour weather: Cars, Rain Detour Using LAV we model each data source as follows: v 1 (L,C,R) traffic(l,c), detour(l,r) v 2 (L,D) traffic(l,c), detour(l,r), weather(l,r,d) v 1 tells us the maximum number of cars passing and rain levels that may cause a traffic jam and therefore a detour is needed and v 2 stores the location of the roads and the suggested detours. Assume a user wants to know where is the next detour when the maximum number of cars passing is 100 and the rainfall is heavy:

8 q(d) weather(100,heavy,d) The following plan would answer the query: Answer(D) v 1 (L,100,HEAVY), v 2 (L,D) The query plan finds some location where the number of cars passing is 100 cars per minute and the rainfall is heavy using v 1 and then finds the next detour v 2. This plan is correct only because a detour is only specified when the number of cars passing exceeds the maximum number and the rainfall is heavy. In fact, if these dependencies would not hold, there would be no way of answering this query using the sources. It is also important to note that view v 1 is needed in the query plan even though the predicates in v 1, cars and rainfall, don t appear in the query q at all. Without functional dependencies, only views that contain predicates appearing in the user query need to be considered [23]. Definition (Functional Dependencies): An instance of a relation p satisfies the functional dependency A 1,,A n B if for every two tuples t and u in p with t.a i = u.a i for i=1,, n, also t.b = u.b. We will abbreviate a set of attributes A 1,,A n by A. When the relations satisfy a set of functional dependencies, we refine our notion of containment to relative containment: Query Q is contained in query Q relative to, denoted Q Q, if for each database D satisfying the functional dependencies in, Q (D) Q(D). In the following we are going to give a construction of query plans that is guaranteed to be maximally contained in the given queries, even in the presence of functional dependencies. The key to the construction is a set of inverse rules, whose purpose is to recover tuples of the virtual relations from the source relations. In the following definition we use a set of function symbols; for every source relation v with variables X 1,,X n in the body but not in the head of the source description, we have a function symbol f v,i. These function symbols can later be removed from the query plan [8]. Definition (I-Rules): Let v be a source description v( X ) P 1 ( X 1 ),K,P n ( X n ) Then for j=1,,n P j ( X j ') v( X ) is an inverse rule of v. We modify X j to obtain the tuple X j ' as follows: if X is a constant or a variable in X, then X is unchanged in X j '. Otherwise, X is one of the variables Xi appearing in the body of v but not in X and X is replaced by f X v,1 ( ) in X j '. We denote the set of inverse rules of the views in V relative to by V 1. Continuing with our example, the inverse rules for v 1 and v 2 are: r 1 : traffic(l,c) v 1 (L,C,R). r 2 : detour(l,r) v 1 (L,C,R). r 3 : traffic(l,f 1 (L,D)) v 2 (L,D). r 4 : detour(l,f 2 (L,D)) v 2 (L,D). r 5 : weather(f 1 (L,D),f 2 (L,D),D) v 2 (L,D). For example, rule r 5 extracts from v 2 that next detour for every location L in a specific area. Suppose that v 1 stores the information that for location= A3, the maximum number of cars should not exceed 100 cars per minute and the rainfall should be less than heavy in order not to have a traffic jam and v 2 stores the information that for location= A3 the next detour is Steyer. The inverse rules derive the following facts: traffic <A3,100> (with r 1 ) <A3,f 1 (A3,Steyer)> (r 3 ) detour <A3,HEAVY> (r 2 ) <A3,f 2 (A3,Steyer)> (r 4 ) weather <f 1 (A3,Steyer),f 2 (A3,Steyer),Steyer> (r 5 ) The inverse rules do not take into account the presence of the functional dependencies. For example, because of the functional dependency in relation traffic, Location Cars, it is possible to conclude that the function term f 1 (A3,Steyer) must actually be the same as the constant 100. We model this inference by introducing a new binary relation e. The intended meaning of e is that e(c 1,c 2 ) holds if and only if c 1 and c 2 must be equal under the given functional dependencies. Hence, the extension of e includes the extension of = (for every X, e(x,x)) and the tuples that can be derived by the following chase rules ( ea,a' ( ) is a shorthand for e(a 1,A 1 ),,e(a n,a n )). Definition (E-Rules) Let A B be a functional dependency satisfied by a virtual relation p. Let C be the attributes of p that are not in A,B. The E- rule corresponding to A B, denoted E( A B ), is the rule eb,b' ( ) p( A,B,C ), p( A,B',C' ), e( A,A' ) We denote by E( ) the set of E-rules corresponding to the functional dependencies in. In our example, the E-rules are e(c,c ) traffic(l,c), traffic(l,c ), e(l,l ). e(r,r ) detour(l,r), detour(l,r ), e(l,l ) e(d,d ) weather(c,r,d), weather(c,r,d ), e(c,c ), e(r,r ) The E-rules allow us to derive the following facts in relation e: <f 1 (A3,Steyer),100> <f 2 (A3,Steyer),HEAVY>

9 The extension of e is reflexive by construction and is symmetric because of the symmetry in the E-rules. To guarantee that e is an equivalence relation, it is still needed to enforce transitivity of e. The following rule, denoted by T, is sufficient for guaranteeing transitivity of relation e: e(x,y) e(x,z), e(z,y) The final step in the construction is to rewrite the query q in a way that it can use the equivalences derived in relation e. We define the query q by modifying q iteratively as follows. If c is a constant in one of the sub goals of q, we replace it by a new variable Z and add the sub goal e(z,c). If X is a variable in the head of q, we replace X in the body of q by a new variable X and add the sub goal e(x,x). If a variable Y that is not in the head of q appears in two sub goals of q, we replace one of its occurrences by Y and add the sub goal e(y,y). We continue until we cannot apply this rule anymore. Our example query would be rewritten to q (D) weather(c,r,d ), e(c,100), e(r,heavy), e(d,d) 5.4. Algorithm and Implementation After the generation of the sets of integrity constraints used for join-introduction (I-Rule) and join elimination (E-Rule), respectively, the algorithm can be summarizes as follows: Input: Q: query I-Rule: set of integrity constraints E-Rule: set of integrity constrains I := 0 Output: Q: transformed query For each R I-Rule For each such that (Body( R)) Body (Q) I := I Head(o( R)) End for End for For each L I with predicate P For each R in E-Rule(P) If such that (Body(R))= L Than remove any literal Matching Head( (R))from Body (Q) Unless this would remove a distinguished variable or leave a variable bound End for End for If Body (Q) = 0 then Q :=I The implementation of this algorithm in Prolog can be done in two different ways. Views, queries and constraints can be represented by group expressions, in which case some special notation is used to represent the variables in the query and unification, subsumption or variance need to be written from scratch. Alternatively, the variables, terms and constraints can be represented by variables terms and constraints in Prolog. In this case, Prolog Unification as well as the built-in or library predicates for (term-)subsumption and variance can be used. Term decomposition using =../2 or variables/2 can not be avoided (e.g. find the distinguished variables). The later implementation is not necessarily simpler as it hides some important aspects of the implementation and runs the risk fort he programmer to inappropriate unified terms. The rules and procedures for join-introduction and join elimination resembles the constraint handing rules. It is possible indeed to use an approach similar to the one we advocated in [10],in order to implement the above described algorithm. 6. Related Work Research o data management in sensor networks has been a field of a large body of research and many papers have been published. The most relevant research is that about wireless routing [5][17][18], power awareness [7][29][15], ubiquitous computing [28], distributed databases [1][35][39] and adaptive query processing [25][3]. All routing protocols are general in purpose and don t consider the specific application workloads. We believe that these protocols can be augmented with the algorithm similar to the one we are proposing in section 3. While the work on query processing in distributed database systems seems to be the solution to this application workloads, still there are major differences between sensor networks and traditional distributed database systems. Different projects have been implemented with the goal of answering queries in wireless sensor networks. Some follow the data warehousing approach like ALERT flood detection system [36], while others follow the virtual approach like Cornel University COUGAR device database system [38] and the DataSpace Project at Rutgers University [16]. The work we presented in this paper can be considered as a generic in-network approach for collecting, aggregating and disseminating data from mixed sensor networks using algorithms that have proven to work well in the context of data base systems. 7. Conclusion In this paper, we have discussed some aspects of the relationship between answering queries in mixed wireless sensor networks and the semantic knowledge about these sensor networks with respect to data integration strategies. We have presented a

10 transformation of an answer queries problem into a semantic query transformation problem. We have described the semantic query transformation algorithm which answers queries using the views. The algorithm is similar to the one of [10] and it is summed and complete for Project-Select-Join. We illustrated that the algorithm can also apply to some situations where existing integrity constraints on the local schemas are taken into account. We have not discussed the general strategy for using such constraints, nor the completeness of the algorithm in this case. The purpose of the project from which this research stems is to build a complete mediation network for wireless sensor networks. Our objective is to integrate seamlessly the process of answering queries with the little semantic knowledge about the wireless sensor network as a basis for an effective and efficient integration strategy. A prototype system is currently being developed. The wrappers and the runtime component of the mediator are being implemented in Java. The query rewriter and optimizer components of the mediator are being prototyped with ECLiPSe logic programming platform. 8. References [1] S. Abiteboul, R. Hull and V. Vianu, Foundation of Database. Addison Wesley [2] P. Bonnet, Pris en Compte des Sources de Données Indisponibles Dans Les Systémes De Médiation. PhD thesis, Université de Savoie, [3] P. Bonnet, J. Gehrke and P. Seshardi, Querying the Physical World, IEEE Personal Communications, Oct 2000, [4] S. Bressan and I. Khalil Ibrahim, Semantic Query Transformation for the Integration of Autonomous Information Sources, Proc. INAP 99, Tokyo [5] J. Broch, D.A. Maltz, D.B. Johnson, Y.C. Hu and J. Jetcheva, A Performance comparison of multi-hop and wireless ad-hoc network routing protocols, ACM SIGMOBILE MOBICOM 1998, ACM [6] C. Chang and R. Lee, Symbolic Logic and Mechanical Theorem Proving, Academic Press [7] J.H. Chang and L. Tassiulas, Energy conserving routing in wireless ad-hoc networks, Proc. INFOCOM 2000, IEEE 2000, [8] O. Duschka and M. Genesereth, Answering Recursive Queries using Views, Proc. ACM SIGACT-SIGMOD-SIGART PODS [9] O. Duschka and A. Levy, Recursive Plans for Information Gathering, Proc. 15 Int. Joint Conf. On Artificial Intelligence [10] O. Duschka, Query Planning and Optimization in Information Integration, PhD thesis, Stanford University, [11] O. Duschka,M. Genesereth and A. Levy, Recursive query plans for data integration, J.o. Logic Programming, Special Issue on Logic Based Heterogeneous Information Systems, Vol. 43, No. 1, 2000, [12] M. Friedman, A. Levy and T. Millstein, Navigational Plans for Data Integration, Proc. National Conference on Artificial Intelligence, [13] H. Gracia-Molina, Y. Papakonstantinou, D. Quass, A. Rajaraman, Y. Sagiv, J. Ullman and J. Widom, The TSIMMIS Project: Integration of Heterogeneous Information Sources, J.o. Intelligent Information Systems, Vo. 8, No. 2, 1997, [14] J. Gray, S. Chaudhuri, A. Bosworth, A. Layman, D. Reichart, M. Venkatrao, F. Pellow and H. Pirahesh, Data cube: A relational aggregation operator generalizing group-by cross-tab and sub-totals, Data Mining and Knowledge Discovery, Vol. 1, No. 1, 1997, [15] W.R. Heinzelman, J. Kulik and H. Balakrishnan, Adaptive protocols for information dissemination in wireless sensor networks, MOBICOM 1999, ACM 1999, [16] T. Imielinski and S. Goes, DataSpace querying and monitoring deeply networked collections in physical space, IEEE Personal Communications Magazine, Special Issue on ing the physical world, Oct [17] P. Johansson, T. Larsson, N. Hedman, B. Mielczarek and M. Degermark, Scenario based performance analysis of routing protocols for mobile ad-hoc networks, MOBICOM 1999, ACM 1999, [18] D.B. Johnson and D.A. Maltz, Dynamic source routing in ad-hoc wireless networks, In: Imielinski, Korth (eds.), Mobile Computing, Vol. 353, Kluwer [19] Khalil Ibrahim, Semantic Query Transformation for the Intelligent Integration of Information Sources, Ph.D., dissertation, Gadjah Mada University, Yogyakarta, [20] T. Kirk, A. Levy, Y. Sagiv and D. Srivastava, The Information Manifold, Proc. AAAI Spring Symposium on Information Gathering in Distributed Heterogeneous Environments, 1995.

11 [21] R. Kronsteiner in I. Khalil Ibrahim (eds.): Radiomatics: J.o. Communications Engineering Vol.1 May 2004, IDTS 2004, pages [22] Levy, Logic-based Techniques in Data Integration, In: J. Minker, Logic Based Artificial Intelligence, Kluwer Publisher [23] Levy, A.O. Mendelzon, Y. Sagiv and D. Srivastava, answering Queries using Views, Proc. ACM SIGACT-SIGMOD-SIGART PODS [24] W. Litwin and A. Abdellatif, Multidatabase Interoperability, IEEE Computer, Vol. 19, No. 12, 1986, [25] S. Madden, R. Szewczyk, M.J. Franklin and D. Culler, Supporting Aggregate Queries Over Ad- Hoc Wireless s, Workshop on Mobile Computing and Systems Applications, [26] S. Madden, M.J. Franklin, J.M. Hellerstein and W. Hong, Tag: A tiny aggregation service for ad-hoc sensor networks, OSDI [27] J. Minker, Foundation of Deductive Databases and Logic Programming, Morgan Kaufmann, [28] T.Pfeifer, Computer Communications, Special Issue on Ubiquitous Computing, Elsevier [29] G.J. Pottie and W.J. Kaiser, embedding the Internet: Wireless integrated network sensors, Communications of ACM, Vol. 42, No. 5, 2002, 51. [30] V. Raghunathan, C. Schurgers, S. Park and M.B. Srivastava, Energy aware wireless microsensor networks, IEEE Signal Processing Magazine, Vol. 19, No. 2, 2002, [31] R. Ramakirshnan and A. Silberschatz, Scalable Integration of Data Collection on the Web, Technical Report University of Wisconsin- Madison, [32] Sheth and J. Larson, Federated Database Systems for Managing Distributed Heterogeneous and Autonomous database, ACM Computing Surveys, Vol. 22, No. 3, 1990, [33] S. Tilak, N. Abu-Ghazaleh and W. Heinzelman, A Taxonomy of Wireless Micro- Nework Models, ACM Mobile Computing and Communications Rview, Vol.6, No. 2, [34] M. Tubaishat and S. Madria, s: An Overview, IEEE Potentials. Vo. 22. No. 2, [35] J. Ullman, Principles of Database and Knowledgebase Systems, Computer Science Press, [36] Urban Drainage and Flood Control Districs, ALERT System: Rela Time Flood Detection & Current Weather Conditions, [37] J. Widom, Research Problems in Data Warehousing, Proc. CIKM [38] Y. Yao and J. Gehrke, The Cougar Approach to In- Query Processing in s, SIGMOD Record, Vol. 3, Nr. 3, Sep [39] Y. Yao and J. Gehrke, Query Processing for s, Proc. CIDR 2003.