In many applications unverified data is processed, which often leads to inconsistence or errors.
Therefore the need for applications to validate this data is high. A lot of types of data can be
verified easily but more complex user data such as full-text-addresses pose a great challenge
towards validation.
This paper proposes an exemplary solution for such a validation by describing the development
of a web service that allows a research conference database 1 to validate conference-location-
strings. The validation consists of checking the plausibility of the location string, correction and
standardization of the spelling, classification (City, State, Country, etc.) and providing corre-
sponding data such as latitude and longitude. For this purpose, the web service accesses the
GeoNames database. Consequently, the conference database receives a rich response which it
can also use to provide further information, e.g., embedded maps or HTML5-Microdata-
Markup.
Table of Contents
1 Introduction
2 Basics
2.1 Web Services
2.1.1 SOAP/WSDL
2.1.2 RESTful Web Services
2.1.3 Conclusion and Decision for RESTful Approach
2.1.4 Slim PHP Framework
2.2 GeoNames
3 System Design
3.1 Problem
3.2 Requirements and Structure
4 Implementation
4.1 Splitting the string
4.2 Validating the Country
4.3 Validating other Parts
4.4 Accessing GeoNames
4.5 Test-Application
5 Testing
6 Conclusion and Outlook
Research Objectives and Core Topics
This paper aims to address the challenges of processing unverified, complex user data, specifically full-text location strings in research conference databases. The primary research goal is to develop an automated web service that standardizes and validates these location strings, ensuring data consistency for downstream applications.
- Comparison and selection of web service architectures (SOAP vs. REST).
- Utilization of geographical databases (GeoNames) for location verification and classification.
- Implementation of robust validation logic using the Slim PHP framework.
- Evaluation of validation accuracy and handling of location-specific edge cases.
Excerpt from the Book
4.1 Splitting the string
In a first step the string of the request from the client is split into different parts by the locationSplit()-Function. In general, the delimiter is a comma, but also other delimiters can occur and are handled. Afterwards the different parts are classified and empty parts are dismissed.
In the sample data one could observe, that the geographical scope gets narrower from the right to the left. Consequently, the validator expects a city-name to be left of the country name etc. This “location-scope-theorem” is used to pre-classify the parts and supports the entire validation process.
The classification of the LocationValidator supports four different location-parts: Place, City, State and Country. A “place” is an unofficial geographical location (usually within a city), which cannot be found in the GeoNames database. Concrete examples for places are Universities and Hotels.
One special case in the sample data was observed: sometimes the location string passed from the client actually consists of more than one location, e.g., “Berlin + Hannover, Germany”. In a naive approach this would lead to a validation error because “Berlin + Hannover” could not be found as a single city name in GeoNames. As a solution, in such a case the split-method treats all of these locations separately by creating new sub instances of itself for each of them and finally merging the result.
Summary of Chapters
1 Introduction: This chapter highlights the problem of unverified location data in conference databases and outlines the objective to build a validation web service.
2 Basics: This chapter introduces fundamental web service technologies, comparing SOAP and REST architectures, and describes the GeoNames database and Slim PHP framework.
3 System Design: This chapter analyzes the technical challenges of extracting location information and defines the requirements for the validation service structure.
4 Implementation: This chapter details the technical development of the LocationValidator, including string splitting logic and the process of querying GeoNames.
5 Testing: This chapter presents the evaluation of the validation service using a set of 500 sample location strings to determine error rates.
6 Conclusion and Outlook: This chapter summarizes the results, discusses the cost-benefit of the implementation, and proposes future improvements like integrating Google Maps.
Keywords
Web Service, RESTful, SOAP, GeoNames, Data Validation, Location Data, PHP, Slim Framework, XML, String Splitting, Full-text Address, Data Consistency, Geographical Database, API, System Design
Frequently Asked Questions
What is the core problem addressed in this paper?
The paper addresses the lack of consistency and accuracy in full-text location data found within research conference databases, which often contains spelling errors or non-semantic text strings.
What are the central thematic fields?
The central fields include web technology architectures, data validation techniques, and the integration of third-party geographical databases to standardize address entries.
What is the primary objective of this research?
The goal is to develop and implement a lightweight, REST-based web service that automatically classifies and validates location information, reducing manual correction effort.
Which scientific or technical methods are applied?
The author uses a RESTful architectural approach, implements a custom LocationValidator class in PHP, and performs empirical testing using a dataset of 500 location samples to measure Type I and Type II error rates.
What is covered in the main section of the paper?
The main sections cover the comparative analysis of web services, the design of the validation logic based on a "location-scope-theorem," the implementation of string processing, and the evaluation of the system's reliability.
Which keywords best characterize the work?
The work is characterized by terms such as RESTful Web Services, Data Validation, GeoNames, and System Design within the context of PHP web development.
Why was the RESTful approach chosen over SOAP?
REST was chosen because the location validation service requires a single, simple functionality, making the complexity and overhead of the SOAP/WSDL "big web services" stack unnecessary.
What is the "location-scope-theorem" used in this work?
It is a heuristic used during string processing based on the observation that geographical scope often narrows from right to left (e.g., country to city), which helps the validator pre-classify address components.
- Quote paper
- Markus Rothenhöfer (Author), 2012, Development of a Location Validation Web Service, Munich, GRIN Verlag, https://www.grin.com/document/198397
