Location:Application of XML in Location Based Service

Abstract
Extensible Markup Language (XML) is a new trend in the Geographical Information System. XML has a long history in terms of providing reliable data management strategy. It was primarily designed to take benefit of Standard Generalized Markup Language (SGML) by removing all the complicated definition parts, only focusing on how the data should be described in a simpler way. In GIS, XML was used in fulfilling different organization needs in terms of data sharing, data definition, transportation and others. The Open Location Services (OpenLS), one of the standards introduced by Open Geospatial Consortium (OGC) uses the efficiency of XML throughout its specification. The Abstract Data Type (ADT) of OpenLS were defined and designed as application schemas that are encoded in XML for Location Services (XLS). XML was also used in Mobile Location Protocol (MLP) which was used by Open Mobile Alliance (OMA) for transmitting location positioning request and response from the Mobile Positioning Center . As the needs for integration and interoperability among different systems arise, XML usage has been broaden from solving syntactic problems to overcoming poor semantic description in the processing of spatial data throughout Location Based Services (LBS). This article briefly describe the importance of XML based standards in order to achieve interoperability and demonstrate the basic Web Service framework for LBS using generalization technique. Other than going into the details of the web service standards used in describing service metadata and information transfer, this article explain the basic of Semantic Web technology and its implementation for integrating system with different domains.

INTRODUCTION
Interoperability is the ability of a system, or components of a system, to provide information portability and inter-application cooperative process control [1] Two kinds of interoperability can be distinguished. For a program, data interoperability means the ability to utilize a range of data formats. For a data set, program interoperability means that it can be used by different types of programs [1]. An interoperable database refers to the data level interoperability. It can be used by different types of programs and applications. With interoperable databases users can request and integrate data easily no matter whether the databases are stored locally or remotely. The interoperability of data from heterogeneous sources is extremely important in the context of LBS applications, because there exist large amounts of spatial data of different geographical formats and there are increased demands for re-use of these existing spatial data. There are two approaches to data interoperability—database integration and standardization. Database integration is the most sophisticated approach. A very first basic approach is to provide users with a global catalogue of accessible information sources, where each source is described by associated metadata, including representation mode, scale, last update date, and data quality level and others. Current database integration has evident drawbacks related to lack of scalability, consistency and duplication. The second approach to interoperability is through standardization. The definition of standard data modeling and manipulation features provide a reference point, which facilitates data exchange among heterogeneous systems. The creation of a new standard data exchange format, Geography Markup Language (GML) represents another important step taken by the geospatial community towards data interoperability. The GML is an XML grammar written in XML Schema for the modeling, transport, and storage of geographic information including both the spatial and non-spatial properties of geographic feature. It is developed as Data Exchange Standards Interface by OGC to achieve data interoperability and reduce costly geographic data conversions between different systems. In the OGC spirit, interoperability is achieved by means of common specifications that programs and data must follow. OGC takes a new spatial interoperability approach, which is not based on a common format, but based on open and common software interfaces. The interface specification largely eliminates the need for data format standards and costly batch data conversion. With the development of the World Wide Web Consortium’s (W3C) XML (Extensible Markup Language), the creation of Geography Markup Language Implementation Specification by OGC represents a significant step in the development of interoperable architectures for the use of spatial information between different applications.

1 BENEFIT OF OGC STANDARD
Firstly, an OGC based specification data can be easily shared and reused. They have no proprietary data models and database structures. Because of the proprietary software design, databases created by current commercial GIS software are difficult to be shared. To share data among such databases, many data conversion processes are necessary. Since XML are text format, they can be easily integrated with other format data across varieties of platforms. Secondly, XML documents can be shared and exchanged online in real time. Although current Internet GIS-based programs can let users share spatial data online, they have the proprietary data model and database structure problems. Thirdly, it can let users exchange data at feature level, while current commercial Internet GIS programs cannot. For example, from a GML-based database, users can just query and download one feature such as a specific road, while from other alternatives users have to download the whole data set. Sharing and exchanging data at feature level in real time are especially important for services such as emergency services. They can greatly reduce the time spending on data acquiring processes. Fourthly, it can be manipulate into other XML technology such as Scalable Vector Graphic (SVG), and provide users a more sophisticated interactive graphic interface and deliver higher quality graphic maps over the Web than most other online alternatives. Fifthly, the OGC Specifications are more flexible than other alternatives. It only defines a basic ADT, which are convenient for user to use. Based on the schemas user can defined their own specific data schema for their spatial data document.

2 INTRODUCTION TO OPENLS SCHEMA
OpenLS Implementation Specification consists of several interfaces that were tightly dependent to each other for specific services. The primary objective of OpenLS is to define access to the core services and abstract data types that comprises the Geomobility Server, an open location service platform [2]. Abstract Data Type information (ADT) is the basic information construct used by the GeoMobility Server and associated Core Services; it consists of well-known data types and structures for location information and is defined as application schemas that are encoded in XML for Location Services (XLS). The release includes 15 supporting XML Schemas and prose specification in two parts. OpenLS: Core Services contains Parts 1-5 which describes the GeoMobility Server (GMS). It also outlines the scope and relationship of OpenLS with respect to other specifications and standardization activities. Part 1 (Directory Service) is a Yellow Pages used to find the nearest or a specific product or service; Part 2 (Gateway Service) fetches the position of a mobile device from the network; Part 3 (Location Utility Service) uses Geocoder/Reverse Geocoder, where Geocoder converts a location, such as a street address to a point with latitude/longitude and Reverse Geocoder transforms a given position into a description of a feature location, such as a street address; Part 4 (Presentation Service) implements map portrayal, and draws a map; Part 5 (Route Service) creates a travel route. OpenLS Part 6 Navigation Service was formerly the Full Profile of the Route Determination Service, which is part of the GMS. The Navigation Service is potentially not needed by all implementations. The OpenLS proposed specification references several other OGC and non-OGC specifications including: (1) OpenGIS Abstract Specification Topic 0: Overview; (2) Guidelines for Successful OGC Interface Specifications; (3) OpenGIS Geography Markup Language (GML), Version 3.0; (4) Recommended Definition Data for Coordinate Reference Systems and Coordinate Transformations; (5) OGC Units of Measure Use and Definition Recommendations; (6) OpenGIS Simple Features Specification for SQL and others. Other standards activities that were reviewed and considered under the OpenLS initiative include related standards initiatives at ISO, W3C, IETF, OMA/LIF, 3GPP, AMIC, MAGIC, WAP, JAIN and Parlay, as well as other emerging and adopted OGC specifications. Other than services schema, OpenLS also define its shared element in the location ADT.

3 DEVELOPING A BASIC FRAMEWORK FOR OPEN LOCATION BASED SERVICE THROUGH SERVICE GENERALIZATION
In our experiment, we first develop a basic framework for a Web Services, using a combination of commercial and open source tools. Our main objective here is to see the implementation of Simple Object Access Protocols (SOAP), which is a standard data transfer for Web Services. Currently, OpenLS specification does not require SOAP-based implementation in the development of the system. SOAP is targeted to be the future data transportation for Web Services, and its implementation should also be considered in LBS Services. As OGC Open Web Services (OWS) was introduced with HTTP GET and POST, our approach to this problem was to use a method called generalization service, using a normal Web Feature Server (WFS). This method was actually used in first introduced by Sarjakoski [11], during the development of GIMODIG project. Other adopter of this method is Da Silva [12], who came up with a multi-dimensional GIS Web Service. Figure 1 shows the basic framework that we have developed for using GeoServer as the WFS Server.

FIGURE 1 BASIC WEB SERVICE FRAMEWORK

Our Service will receive SOAP messages through any SOAP client. Client access all the data through stubs generated by WSDL2Java tool, a feature in Apache Axis 2 Toolkit that allows Java code generation for the client to access the service directly. When the service validate the message, written using XMLBeans Java-XML binding tool the OpenLS request will then be parsed into a WFS request using Extensible Stylesheet Template (XSLT). The benefit of this approach is that the system is accessible in different ways, using normal WFS capabilities or with any SOAP client. WFS already handle a lot of core functionality, such as integration with different data sources and data generalization to GML. All of this process were done inside the server, thus we manage to maintain the main concept of OpenLS Service using its standardize request and response message. Figure 2 shows the data translation flow in our framework.

FIGURE 2 DATA MANIPULATION FLOW