Design of Field Wrappers for Mobile Field Data Collection Peisheng Zhao
Sarah Nusser
Leslie Miller
Laboratory for Advanced Information Technology and Standard, George Mason University
Department of Statistics, Iowa State University
Department of Computer Science, Iowa State University
9801 Greenbelt Road Suit 316-317 Lanham, MD 20706 01-301-552-3829
Ames, IA 50011
Ames, IA 50011
[email protected]
[email protected]
[email protected]
Abstract
1. INTRODUCTION
In mobile field data collection, data gatherer requires to get geospatial information service to support in navigating to the right locations, describing context of observed object and providing thematic information for sampling or analysis. The framework how to get this information is subject to the variation in users with different levels of knowledge about information services, applications with different need of information, and limitations of field computing environments. In this paper, we present a new concept--field wrapper, which is an extension of wrapper concepts to the field data collection environments as a means of isolating the heterogeneity of field users, applications, and computing environments from infrastructure functions. The goal of our approach of field wrapper, which is as an important part of the mediator-based framework for collecting and using geospatial data in the field, is to enable any device with any user in the field to readily and easily interact with a larger computing infrastructure to search, retrieve, and get geospatial and other kinds of data. The key idea is to characterize the field environments to get an abstract field view. From this view, the system generates a field wrapper that facilitates query translation from user general request to the precise syntax statement accepted by mediator and result translation from native result to the specific result accepted by field user.
In computing systems, a wrapper is a component that acts as an interface between its caller and the wrapped component for the purpose of compatibility or interoperability. Usually it encapsulates the low level detail of wrapped component and provides more “general” interface enabling the caller to communicate with the wrapper in a more convenient form than would occur if directly interacting with the component without wrapper. Now the research efforts have mainly concentrated on using data wrapper in the mediator-based [4] system to deal with the problem of heterogeneous data caused by platform, structure and semantic.
Categories and Subject Descriptors H.4.m [Miscellaneous]
General Terms Management, Design, Languages
Keywords Mediator, Field, Wrapper, Heterogeneity, Mobile Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. GIS’02, November 8-9, 2002, Mclean, Virginia, USA. Copyright 2002 ACM 1-58113-591-2/02/0011…$5.00.
In mobile field data collection, data gatherer requires to get information services, especially geospatial information service, to support in navigating to the right locations, describing context of observed object and providing thematic information for sampling or analysis. The framework how to get this information is subject to the variation in users with different level of knowledge about information services, applications with different need of information, and limitations of field computing environments, such as bandwidth and reliability of communications links, size and capacity of field processing and storage technology. In this paper, we present a new concept--field wrapper, which is an extension of wrapper concepts to the field data collection environments as a means of isolating the heterogeneity of field users, applications, and computing environments from infrastructure functions. This research is motivated by the need to use and collect geospatial information in a potentially limited mobile computing environment and the problems that can arise in developing computing systems to accommodate this need. The goal of our approach of field wrapper, which is as an important part of the flexible and extensible framework for collecting and using geospatial data in the field, is to enable any device with any user in the field to readily and easily interact with a larger computing infrastructure to search, retrieve, and get gathered geospatial and other kinds of data. In what follows, we address the need of encapsulating heterogeneous field computing environments in the general framework for collecting and using geospatial data in the field. We then extend the concept of a wrapper to field wrapper, discuss the field wrapper model and describe the element of field view. Next we present its architecture, and provide a specific application
to mobile field data collection. Finally we conclude the paper and present some opportunities for future work.
2. EXTENSION OF WRAPPER CONCEPT TO FIELD ENVIRONMENTS With the development of Internet, the availability of information sources is literally exploding. To integrate these information from distributed heterogeneous systems, mediator-based approaches has been used, such as TSIMMIS[7], DISCO[2], MIX[3][5], Si3CO[8] and Information Manifold[1]. Especially MIX and Si3CO are extended for geospatial data. But the mediator-based system just concentrates on dealing with heterogeneous data. While in mobile field data collection, there is also a need to accommodate heterogeneous field environments. Given the rapid changes in technology, it is increasingly difficult for some agencies to make the large uniform purchases required to generate a homogeneous computing environment. Further, field staff need more flexible access to information resources (e.g., survey data, geospatial data, local GPS readings) to accomplish diverse task assignments (e.g., listing, locating, interviewing) in the same physical area. Therefore the field environments (including field user and her/his computing and application environment) vary in computing capability, network connection, display characteristics, peripheral devices, and so on. Moreover the field environment also has a large influence on the kind of data that can be handled in the field setting. In some settings, limited views or processing is required, while in others, a broader range of information formats and processing capabilities are possible. One way to address this heterogeneity is to expand the architecture of mediator-based system by developing a field wrapper that is used to implement additional flexibility in interactions between the field environment and a mediator-based system for accessing information resources.
The objective of field wrapper is to insulate the infrastructure from the problems caused by heterogeneous field environments. It encapsulates knowledge about user context that is passed on to the mediator to enable it to assemble information that addresses user needs from infrastructure components such as a dynamic warehouse, i.e. takes “relatively” general terms field user input and turns them into “precise” view. This allows new user applications and devices to be easily plugged into the infrastructure. In particular, field wrapper screens out the details of communication between the field worker, the application program and the field hardware. At the same time the field wrapper model gives us the opportunity to define operations that take characteristics of the field into consideration in a uniform way. In this paper, we explore this concept via a mobile field data collection testbed environment based on the National Resources Inventory (NRI) survey setting. There needs deal with various data sources: one, highly structured, is an object-relational database that contains PSU (Primary Sample Unit) information; two is partially structured information in the form of XML or html that encapsulates the information about ortho image, route and others. Data maybe is either vector or raster. While in field, user needs to make plan, locate sample point, navigate route and collect data by using various devices with GPS, such as Compaq IPAQ or 3Com Palm, Fujitsu Tablet, laptop and so on. The testbed framework is as figure1. Example 2.1 Suppose field user named Scott using a pocket PC IPAQ with wireless network connection is interested in making a plan to investigate land use in Story County. The parameters which should be noticed are the device name, network condition, purpose, and spatial location. Field user can send query Q: Get planning datum in Story County for a wireless-connecting IPAQ user.
3. DATA MODEL OF FIELD WRAPPER Before building field wrapper, it is necessary to understand the modes or manners of various field environments well, i.e. consider how to parameterize field environment to generate an abstract field view. In this paper we use Ontolingua[10], a language capable of translating between various ontology, to describe and reason about the field view.
User
User
Field Wrapper
Field Wrapper
Mediator Data Data Wrapper
Data Wrapper
Source Database
Source Web
Warehouse
Figure 1. The Framework of the NRI Testbed
The field view is a collection of classes. It serves as: 1. schema by which the user poses queries, 2. terms which are sent to the mediator for query, 3. domain-specific knowledge about real-world objects and their relationships in the field environments. In specifying the heterogeneity of field environment, three things including application, user and computing resources need to be clearly identified in the field view.
3.1 Application As figure 2, application includes a set of tasks, and while each task requires different types of information to support decision, such as spatial and non-spatial data.
Define-Class Application (?App) "Combining different kinds of data to support field worker to finish one certain task" :Def (And (set ?App) (forall ?task => (member ?task ?App))))
Define-Class Data_Attribute (?attribute) :Def (And (Has-One ?attribute Attribute.Name) (Has-One ?attribute Attribute.Type))
Define-Class Task (?task) "need some kinds of data to be supported" :Def (And (Has-One ?task Task.Name) (Has-Some?task Task.Data))
Define-Class Data_Format (?format) :Def (And (String ?format) (forall ?format (==>(member ?format (set of point line polygon image text)))))
Define-Class Data (?data) "including spatial and non-spatial data" :Def (And (Has-One ?data Data.Name) (Has-One ?data Data.Format) (Has-Some ?data Data.Attribute) (Has-One ?data Data.GeoContext)
Define-Class Data _GeoContext (?geoContext) :Def (And (Has-One ?geoContext GeoContext.SpatialFilter Define-Function Task.Data (?task):->?data :Def (And (Task ?task) (Data ?data))
Figure 2. Application in Field View The information is described by combining the following elements: 1. Data attribute, which is a text-based filter, such as theme, date, scale and others. 2. Data format, including vector, such as shp and coverage, and raster, such as grid and jpg. 3. GeoContext, which is a spatial-based filter compatible with OpenGIS feature filter specification [6], such as geographical coordinates, gazetteer and spatial relationship.
3.2 User In the mobile field data collection environment, field users get the information from distributed data source. But different users have different pre-defined access privileges to data sources and operations and different preferences for data source. Moreover sometimes users don’t need to know where the data come from at all. So we can classify data source into three categories based on user’s role as figure 3: 1. Specified data source, which provides proprietary datum prepared by the organizations of data collection. If users want to retrieval data in this kind of data source, they must been granted in advance. In general user name and password is used to indicate user’s pre-defined access privileges. 2. Preferred data source, which can be accessed publicly without permission. It is the first choice when users want to get public data. 3. Other data source, which is used when there is no data for user’s request in both specified data source and preferred data source. In this case where and how users can get this kind of data is decided by information infrastructure.
Define-Class User (?user) "User has pre-defined access privileges to specific data sources and preferences for some kinds of data source :Def (And (Has-One ?user User.Location) (Has-Some ?user User.DataSource)) Define-Class DataSource (?ds) :Def( And (Has-One ?ds DataSource.Name) (Has-One ?ds DaatSource.Description) (Has-Some ?ds DataSource.Data)) :Axiom-Def (Subclass-Partition DataSource (set of Specified Preferred Other)) Define-Class Specified (?sp) :Def( And (DataSource ?sp) (Has-One ?sp Specified.UserName) (Has-One ?sp Specified.Password))
Define-Class Preferred (?pre) :Def(And (DataSource ?pre) (Has-one ?pre Preferred.URL)) Define-Class Other (?other) :Def(And (DataSource ?other) (Has-one ?other Other.Theme)) Define-Relation User.Location (?user ?location) :Def (And (User ?user) (forall ?location (==> (member ?location (setof coordinate gazetteer))))) Define-Function User.DataSource (?user):->?ds :Def (And (User ?user) (DataSource ?ds)) Define-Function DataSource.Data (?ds):->?data :Def(And (DataSource ?ds) (Data ?data)
Figure 3. User in Field View
3.3 Computing Resource Define-Class Device (?device) "The characteristics of field computing resources" :Def (And (Has-One ?device Device.Name) (Has-One ?device Device.Width) (Has-One ?device Device.Height) (Has-One ?device Device.Color) (Has-One ?device DeviceNetwork) (Has-One ?device Device.Memory) (Has-Some ?device Device.dataFormat)) Define-Class Network (?network) :Def (And (Has-One ?network Network.type) (Has-One ?network Network.transRate))
Figure 4. Computing Resource in Field View Because of the limitations of field environment, the field computing resources have a large influence on the kind of data that can be handled in the field setting. In figure 5 the elements including “width”, “height”, and “color” indicate the display characteristics of handheld device, for example, the screen size of Compaq IPAQ is just 240 pixels in width and 320 pixels in height; the “transRate” element describes the network condition, usually in the field wireless communication, which is slow and unstable, is the most popular; the “maxDataSize” element means the computing capability.
4. QUERY TRANSLATION
In general field wrapper can be described as a function which translates field user query in general terms into more precise field view according to the encapsulated rules and knowledge. User query is a conjunctive query over field view and some buildin predicates. Example 4.1 The user query Q of example 2.1 can be described as following: Q ( dataCollection) ← userName(User, Scott), deviceName(Device, PAQ), type(Network, wireless), rate(Network, y) y Formally the knowledge can be represented as: A(O1,V1), … , A(On,Vn) ⇒ Q :< A = V1∩ Vn >, where A(O1,V1) ← A11 (O1,V1), …., A1n (O1,Vn), CQ A(On,Vn) ← An1 (On,V1), …., Ann (On,Vn), CQ
Where (1) Q is a new object as query input of mediator, (2) A11, …, A1n, …, An1, …, Ann are attributes on the classes in the field view, (3) A ∈∪1≤i≤n, 1≤i≤nAii , (4) others are the same as above description. Following shows some rules in field wrapper deviceName(Device, x), deviceType(Device, y) ⇒ Q :< displaySize = z >; gazetteer(SpatialContext, x) ⇒ Q :< spatial = x >; location(SpatialContext, x) ⇒ Q :< spatial = x >; dataList(User, z1) ← username(User, x1), password(User, y1), dataList(Application, z2) ← task(Application, x2), dataList(User, z1), dataList(Network, z2) ⇒ Q :< dataList = z >; dataType(Device, z1 ) ← deviceName(Device, x1) dataType (Network, z2) ← type(Network, x1), rate(Network, y1) dataType(Device, z1),dataType(Network, z2) ⇒ Q: 5. IMPLEMENTATION OF FIELD WRAPPER Figure 5 shows an overview of the field wrapper architecture as it is currently implemented in our testbed system. The controller component is responsible for invoking three major services. First, field wrapper models the contents of exact field environment as Abstract Field View (Ontolingua)
Field User General Request
Specific Result
Controller Field View Schema (XML Schema) Field View Instance (XML Document)
Field Wrapper
Parser
Translator Precise Request
Post Processor Native Result
Infrastructure
Figure 5. Field Wrapper Architecture field view instance in the form of XML, and then allows the parser to parse this instance into internal structures with validating it based on field view schema. Secondly, the field wrapper uses translator to translate user’s general request into a precise request according on the specific field view. This mechanism is important, because it provides a means by which user can get data without concerning about low level detail. The final service provided by field wrapper is post-processing, which transforms and packages the native result into the result that can be accepted by field user. Because of its ability to encode information in a way that is easy to read, process, and generate, XML is used in the testbed to describe field view schema and instances. The classes in field view are defined as nested elements, while attributes of classes are described as either elements or attributes of XML. Figure 6 is the description of field environment in example 2.1
it is Oracle spatial database, including NRI PSU, NRI point, NRI photograph, NRI attribute and soil maps NRI Database PSU_Boundary Polygon Shp PSU_ID varchar(2) PSU_Geom MDSYS.SDO_GEOMETRY ………. …….. Scott NRI Iowa Image Server hosted by ISU GIS facility Ortho Image Ortho_Image image jpg image image x0 double y0 double ………
http://baykal.gis.iastate.edu/client.cgi? ……….. PSU_Boundary.PSU_Geom PSU_Boundary.PSU_ID Ortho_Image.image Story_Road.Road_Geom Story_Road.Road_Name …….. 240 195 256 wireless 28800 Image.jpg 32000000 < dataType >vector.shp < dataType >Image.jpg
Figure 6. Field View Instance
6. CONCLUSIONS For encapsulating the heterogeneous environments of field data collection, in this paper, we have extended the wrapper concept to the area of field computing which is required to interact with a larger computing infrastructure to get information service. To describe and reason the content of knowledge for interacting with heterogeneous field environments, field view has been defined. Also we have described the field wrapper model and architecture for Battuta, an extensible framework and testbed for collecting and using geospatial data in the field. The key design features of field wrapper are extensibility and flexibility, which means field wrapper can accommodate almost any kind of field environment.
A prototype of field wrapper has been implemented. It can be run as a web service. The field application can communicate with it either by SOAP or by simple HTTP POST, all based on HTTP protocol. In the future, we will continue to refine the field view in order to more accurately represent the knowledge of field environment. We will also investigate the possibility of introducing KQML [9], which is an agent communication language between field wrapper and mediator. Moreover we will focus on the approach for automatically generating field wrapper.
7. REFERENCES [1] A.Levy, A.Rajaraman and J.Ordille. Querying Heterogeneous Information Sources Using Sources Descriptions, Proceedings of VLDB, 1996:251-262
[2] A.Tomasic, L.Raschid, P.Valduriez. Scaling Access to Heterogeneous Information Sources with DISCO, IEEE Transactions on Knowledge and Data Engineering, Vol.10, No.5, 1998:808-823
[3] C.Baru, A.Gupta, B.Ludaescher, R.Marciano, Y.Papakonstantinou, P.Velikhov. XML-Based Information Mediation with MIX, In Exhibitions Program of ACM SIGMOD 99.
[4] G.Wiederhold. Mediators in the Architecture of Future Systems, IEEE Computer, 25(3):38-49, 1992
[5] I.Zaslavsky, R.Marciano, A.Gupta, C.Baru. XML-based Spatial Data Mediation Infrastructure for Global Interoperability, 4th Global Spatial Data Infrastructure Conference , Cape Town, South Africa, 13-15 March, 2000
[6] OpenGIS. Web Feature Server Implementation Specification. http://www.opengis.org
[7] S. Chawathe, H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J. Ullman, and J. Widom: "The TSIMMIS Project: Integration of Heterogeneous Information Sources", In Proceedings of IPSJ Conference, pp. 7-18, Tokyo, Japan, October 1994.
[8] S.Shimada, H.Fukui. Geospatial Mediator Functions and Container-based Fast Transfer Interface in Si3CO TestBed, In Proc. Interoperating Geographic Information Systems, Second International Conference, INTEROP ’99, Andrej Vckovski, Kurt E.Brassel, Hans-Jörg Schek(Eds.), Zurich, Switzerland, March 10-12,1999, pp.265-276
[9] T. Finin, Y.Labrou, and J. Mayfield. KQML as an agent communication language. The Proceedings of the Third International Conference on Information and Knowledge Management (CIKM'94), ACM Press, November 1994.
[10] T.Gruber. Ontolingua: A Mechanism to Support Portable Ontologies, Strandford Knowledge Systems Laboratory. Tech Report KSL-91-66. November 1992
