172 Geospatial Image Metadata Catalog Services 1. Introduct Ion As earth observation continues worldwide, large volumes of remotely sensed data on the Earth’s climate and environment have been collected and archived. In order to maintain the data archives efciently and to facilitate discovery by users of desired data in the holdings, each data provider normally maintains a digital metadata catalog. Some online catalogs provide services to users for searching the catalog and discovering the data they need through a well-established Application Programming Interface (API). Such services are called Catalog Services. The information in the catalog is the searchable metadata that describe individual data entries in the archives. Currently most Catalog Services are provided through Web- based interfaces. This chapter analyses three open catalog service systems. It reviews the metadata stan- dards, catalog service conceptual schemas and protocols, and the components of catalog service specications. 2. rev Iew of geosp At IAL IMAge cAt ALog ser vIces 2.1 Pilot Catalog Service Systems The Federal Geographic Data Committee (FGDC) Clearinghouse is a virtual collection of digital spatial data distributed over many servers in the United States and abroad. The primary intention of the Clearinghouse is to provide discovery services for digital data, allowing users to evalu- ate its quality through metadata. Most metadata provide information on how to acquire the data; in many cases, links to the data or an order form are available online. The NASA Earth Observing System Clear- ingHOuse (ECHO) is a clearinghouse of spatial and temporal metadata that enables the science community to exchange data and information. ECHO technology can provide metadata discovery services and serve as an order broker for clients and data partners. All the NASA Distributed Ac- tive Archive Centers (DAACs), as data providers, generate and ingest metadata information into ECHO. The Open Geospatial Consortium (OGC) has promoted standardization and interoperability among the geospatial communities. In catalogue service aspect, OGC has dened the Catalog Service implementation standard (OpenGIS, 2004) and published two recommendation papers (OpenGIS, 2005a; OpenGIS 2005b). The George Mason University (GMU) CSISS Catalog service for Web (CSW) system is an OGC-compliant catalog service, which demonstrates how the earth science community can publish geospatial resources by searching pre-registered spatial and temporal metadata information. In particular, the GMU CSISS CSW catalog service is based on the OpenGIS implementation standard, and the ebRIM application prole (OpenGIS, 2005). It provides users with an open and standard means to access more than 15 Terabytes global Landsat datasets. 2.2 Conceptual System Architecture Since these geospatial catalog services address similar needs, it is not surprising that they have almost the same conceptual system architecture, as shown in Figure 1. From the point of view of metadata circula- tion, a catalog service usually consists of three components: metadata generation and ingestion, a conceptual schema for catalog service, and a query interface for catalog service. Metadata generation and ingestion is always based on applicable metadata standards, such as the Dublin Core (DCMI, 2003), Geographic information – Metadata (19115) from Interna- tional Organization for Standard (ISO, 2003), Content Standard for Digital Geospatial Metadata (CSDGM) from Federal Geographic Data Com- 173 Geospatial Image Metadata Catalog Services mittee (FGDC, 1998), or the ECS Earth Science Information Model from National Aeronautics and Space Administration (NASA, 2006). Metadata structures, relationships and deni- tions, known as conceptual schemas, play a key role in catalog services. They dene what kind of metadata information can be provided and how the metadata are organized. The concep- tual schemas are closely related to those of the pre-ingested metadata information, but are not necessarily identical. Catalog service conceptual schemas are always oriented toward the eld of application and may be tailored to particular ap- plication proles. The query interface for a catalog service denes the necessary operations, the syntax of each operation, and the binding protocol. To facilitate access and promote interoperability among catalog services, the interface denition may be kept open. 2.3 Metadata generation In this section, the three open catalog services identied in Section 2.2 are analyzed on the follow- ing two aspects regarding metadata generation. 2.3.1 Base Metadata Standard The base metadata standard is the public geospatial metadata standard on which the catalog service is based and to which the catalog service is tai- lored, to meet a given agency’s requirements. In addition to international and national geospatial metadata standards, such as ISO 19115 and FGDC CSDGM, several agencies may have de-facto standards in their production environment, such as NASA ECS. The metadata used by the FGDC Clearing- house follows FGDC CSDGM. Each afliated catalog service site must organize their metadata information following the CSDGM standard before they join the clearinghouse. The ECHO Science Metadata Conceptual Model has been developed based on the NASA Earth Observation System Data and Information Core System (EOSDIS) Science Data Model, with modications to suit project needs. GMU CSISS CSW builds up its metadata con- ceptual model by combining the ebRIM informa- tion model and the ECS science data model. 2.3.2 Automatic Generation of Metadata As the volume of spatial datasets keeps growing, generation of metadata becomes increasingly time-consuming. An automatic mechanism for generating metadata will facilitate the generation and frequent update of metadata. Metadata information needs to be organized as TXT or SGML or HTML les before a node Figure 1. Conceptual Architecture of Catalog Service Catalog Service Client Catalog Service Metadata Holdings Data Holdings Query Interface Conceptual Schema User 174 Geospatial Image Metadata Catalog Services joins the FGDC clearinghouse. Some metadata generation tools are available in addition to the commercial software packages. These tools are advertised on the FGDC website. To help the user set up a clearinghouse node easily, a software package, ISite, is provided. With this software, a qualied clearinghouse node server can be set up in minutes. All the ECHO metadata holdings are obtained directly from the data providers. DAACs can use some ECS tools to automatically generate metadata information. GMU CSISS is developing Java-based tools to automatically extract metadata information from each granule. The Hierarchical Data Format (HDF), Hierarchical Data Format - Earth Observ- ing System (HDF-EOS), GeoTIFF and NetCDF data formats are currently supported. 2.4 Metadata Ingestion 2.4.1 Metadata Distribution This function deals with the physical distribu- tion of metadata information within the catalog service. The FGDC Clearinghouse is a decentralized system of servers that contain eld-level meta- data descriptions of available digital spatial data located on the Internet. The metadata informa- tion is physically managed within the afliated server node. Even though in ECHO scenario, the metadata information is periodically generated by those distinct data centers, they are centrally managed by the ECHO operation team. That is, in the design time, metadata information in ECHO is distributed; while in the run time it is managed centrally. The GMU CSISS CSW maintains more than 15 Terabytes of global Landsat images. All the metadata information for these images has been registered into a centralized metadata database. 2.4.2 Ingestion Type This section examines how each catalog service ingests metadata. It focuses on two aspects: remote vs. local and automatic vs. manual. In the FGDC Clearinghouse, all the metadata information is manipulated only in the afliated server node. Remote ingestion is not supported in server nodes. The ingestion has to been manu- ally. Due to a centralized metadata information, a database approach is taken. Metadata ingestion in ECHO involves two steps. Data centers need to up- load their current metadata information remotely to a dedicated File Transfer Protocol (FTP) server, and the ECHO operation team is responsible for ingesting these metadata information into the ECHO operational system. GMU CSISS CSW provides published inter- faces. As long as the metadata information is well organized, it can be remotely ingested into the GMU CSISS CSW metadata database. All the metadata information in that database is online and ready for client’s query. 2.5 Conceptual Schema We examine how the metadata conceptual schema is dened in each catalog service. In each FGDC Clearinghouse collection, all the metadata information is organized according to the FGDC CSDGM. The conceptual schema of FGDC Clearinghouse collection is exactly the same as that of the FGDC CSDGM. In ECHO, all the metadata information col- lected in the NASA DAACs is based on the ECS science data model, with some modications necessary to suit project needs. GMU CSISS CSW denes its conceptual schema based on the ECS science data model combined with ISO 19115. Since GMU CSISS CSW supports metadata queries and data retrieval (through the OGC services), an ebRIM-based prole has been selected to support dening the 175 Geospatial Image Metadata Catalog Services association between a data granule instance and applicable geospatial service instances. 2.6 t ransfer protocol A catalog service usually provides a standard, API-based interface to support the client’s query. This “design-by-contract” mechanism promote third party members’ contribution to develop new query interfaces, besides those web-based query interfaces provided by the catalog server itself. The backbone of the FGDC Clearinghouse is Z39.50 (ISO, 1998). This protocol was initially developed by the library community to discover bibliographic records using a standard set of attri- butes. To guide how to implement FGDC metadata elements within a Z39.50 service, the FGDC has developed an application prole for geospatial metadata called "GEO," which provides sets of attributes, operators, and rules of implementation that suit geospatial needs. In fact, the node server is a Z39.50 server, which enables FGDC query utilities to search its metadata holdings on the y through Z39.50 protocol and GEO prole. ECHO exposes the Session Manager and a lim- ited set of the ECHO services as Web Services de- ned via the Web Services Description Language (WSDL). ECHO also provides two client packages, Façade and EchoTalk, for client developers. The syntax of the communication protocol between client and ECHO is based on the Web Services Interoperability (WS-I) Basic Prole. However, the semantics of the communication protocol are dened by ECHO itself. Specic query syntax, in Extensible Markup Language (XML) format, has been proposed and implemented. GMU CSISS CSW’s communication protocol is based on the OGC Catalog Service Implementa- tion Specication, which species the interfaces and several applicable bindings for catalog ser- vices. Operations, core information schema and query language encodings are included. The transportation-related communication protocol follows this specication. 2.7 System Distribution This section examines the physical distribution of catalog service systems. The FGDC Clearinghouse has 400 worldwide registered nodes as of March 22, 2006. FGDC maintains several Web-based search interfaces to carry out distributed searches across multiple clearinghouse nodes. ECHO acts as an intermediary between data partners and client partners. Data partners provide information about their data holdings, and client partners develop software to access this informa- tion through ECHO Query and Order Web Service interface. End users who want to search ECHO's metadata must use one of the ECHO clients. Although ECHO has close connections with the DAACs and ECHO Clients, ECHO itself is not a distributed system. It does not need to build a distributed search across multiple agencies and nodes at run time. GMU CSISS CSW is a standalone service. Like ECHO, it is not a distributed system. 2.8 Review Summaries Table 1 summarizes the results of the analysis. 3. conc Lus Ion And dIscuss Ion We have reviewed three public catalog services — FGDC Clearinghouse, NASA ECHO and GMU CSISS CSW— considering the following aspects: metadata generation, metadata ingestion, catalog service conceptual schema, query protocols and system distribution. This review shows how it is becoming possible to query metadata hold- ings through public, standard Web-based query interfaces. The review results also show that the catalog service providers still must dene a catalog service schema that meets their particular needs. These application-oriented approaches can meet projects 176 Geospatial Image Metadata Catalog Services requirements, but they will make it more difcult to create future cross-federation multi catalog services. We recommend that a standard, common and discipline-oriented-metadata based schema be used for future implementations of catalog services in the same and/or related elds. r eferences DCMI. (2003). DCMI Metadata Terms. Retrieved March 8, 2007, from http://dublincore.org/docu- ments/dcmi-terms/ß ECHO. (2005). Earth Observing System Clearing- house. Retrieved March 8, 2007, from http://www. echo.eos.nasa.gov/ FGDC. (1998). Content Standard for Digital Geospatial Metadata (CSDGM). Retrieved March 8, 2007, from http://fgdc.er.usgs.gov/metadata/ contstan.html FGDC. (2005). FGDC Geospatial Data Clear- inghouse Activity. Retrieved March 8, 2007, from http://www.fgdc.gov/clearinghouse/clear- inghouse.html ISO. (1998). ISO 23950: Information and documentation - Information retrieval (Z39.50) - Application service denition and protocol specication. ISO. (2003). ISO 19115: Geographic Information - Metadata. LAITS. (2005). LAITS OGC Catalog Service for Web - Discovery Interface. Retrieved March 8, 2007, from http://geobrain.laits.gmu.edu/csw/ discovery/ NASA. (2006). EOSDIS Core System Data Model, Retrieved March 8, 2007, from http://spg.gsfc. nasa.gov/standards/heritage/eosdis-core-system- data-model OpenGIS. (2004). OpenGIS Catalogue Service Implementation Specication. Retrieved March 8, 2007, from http://www.opengeospatial.org/ specs/?page=specs OpenGIS. (2005a). OGC Recommendation Pa- per 04-17r1: OGC Catalogue Services- ebRIM (ISO/TS 15000-3 profile of CSW. Retrieved March 8, 2007, from http://www.opengeospatial. org/specs/?page=recommendation Tables 1. Review summaries Evaluation Points FGDC Clearinghouse NASA ECHO GMU CSISS CSW Metadata generation – Base standard FGDC CSDGM ECS Core ECS Core/ISO 19115 Metadata generation – Generation automation manually with tools manually with tools automatically Metadata ingestion – Metadata Distribution distributed centralized centralized Metadata ingestion – Ingestion Type N/A Remotely and automatically Locally and automatically Conceptual Schema FGDC CSDGM Based on ECS Core Based on ISO 19115 and ebRIM Transfer Protocol Z39.50 and GEO profile Proprietary and based on Web Service OGC Catalog Service and HTTP binding System distribution Distributed Centralized Centralized 177 Geospatial Image Metadata Catalog Services OpenGIS. (2005b). OGC Recommendation Pa- per 04-038r2: ISO19115/ISO19119 Application Prole for CSW 2.0. Retrieved March 8, 2007, from http://www.opengeospatial.org/specs/ ?page=recommendation key t er Ms Catalog Service: A set of information, con- sisting of some or all of directory, guide, and in- ventories, combined with a mechanism to provide responses to queries, possibly including ordering data. (Source: Earth Science and Applications Data System) Catalog System: An implementation of a directory, plus a guide and/or inventories, inte- grated with user support mechanisms that provide data access and answers to inquires. Capabilities may include browsing, data searches, and placing and taking orders. A specic implementation of a catalog service. (Source: Earth Science and Applications Data System, Interagency Working Group on Data Management for Global Change, European Patent Organisation). Service: A distinct part of the functionality that is provided by an entity through interfaces. (Source: ISO 19119: Geographic information – Services) Interface: A named set of operations that characterize the behavior of an entity. (Source: ISO 19119: Geographic information – Services) Operation: A specication of a transformation or query that an object may be called to execute. (Source: ISO 19119: Geographic information – Services) Transfer Protocol: A common set of rules for dening interactions between distributed systems. (Source: 19118: Geographic information - Encoding) 178 Chapter XXIII Geospatial Semantic Web: Critical Issues Peisheng Zhao George Mason University, USA Liping Di George Mason University, USA Wenli Yang George Mason University, USA Genong Yu George Mason University, USA Peng Yue George Mason University, USA Copyright © 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited. Abstr Act The Semantic Web technology provides a common interoperable framework in which information is given a well-dened meaning such that data and applications can be used by machines for more ef- fective discovery, automation, integration and reuse. Parallel to the development of the Semantic Web, the Geospatial Semantic Web – a geospatial domain-specic version of the Semantic Web, is initiated recently. Among all the components of the Geospatial Semantic Web, two are especially unique – geo- spatial ontology and geospatial reasoning. This paper is focused on discussing these two critical issues from representation logic to computational logic. 179 Geospatial Semantic Web Introduct Ion Inspired by Tim Berners-Lee (Berners-Lee, 1998; W3C, 2006), inventor of the Web, a growing number of individuals and groups from academia and industry have been evolving the Web into another level - the Semantic Web. By represent- ing not only words, but their denitions and contexts, the Semantic Web provides a common interoperable framework in which information is given a well-dened meaning such that data and applications can be used by machines (reason- ing) for more effective discovery, automation, integration and reuse across various application, enterprise and community boundaries. Compared to the conventional Web, the Semantic Web excels in two aspects (W3C, 2006): 1) common formats for data interchange (the original Web only had interchange of documents) and 2) a language for recording how the data relates to real world objects. With such advancements, reasoning engines and Web-crawling agents can go one step further – and inductively respond to questions such as “which airelds within 500 miles of Kandahar support C5A aircraft?” rather than simply returning Web pages that contain the text “aireld” and “Kan- dahar”, which most engines do today. Figure 1 shows the hierarchical architecture of the Semantic Web. At the bottom level, XML (Extensible Markup Language) provides syntax to represent structured documents with a user- dened vocabulary but does not necessarily guarantee well-dened semantic constraints on these documents. And XML schema denes the structure of an XML document. RDF (Resource Description Framework) is a basic data model with XML syntax that identies objects (“resources”) and their relations to allow information to be exchanged between applications without loss of meaning. RDFS (RDF Schema) is a semantic extension of RDF for describing the properties of generalization-hierarchies and classes of RDF resources. OWL (Web Ontology Language) adds vocabulary to explicitly represent the meaning of terms and their relationships, such as relations between classes (e.g. disjointness), cardinality (e.g., “exactly one”), equality and enumerated classes. The logic layer represents the facts and derives knowledge, and deductive process and proof validation are deduced by the proof layer. A digital signature can be used to sign and export the derived knowledge. A trust layer provides the trust level or a rating of its quality in order to help users building condence in the process Figure 1. Semantic Web architecture (Berners-Lee, 2000) 180 Geospatial Semantic Web and quality of information(Antoniou & Harmelen, 2004). Parallel to the development of the Semantic Web, the Geospatial Semantic Web – a geospatial domain-specic version of the Semantic Web, is initiated recently. Because geospatial information is heterogeneous, i.e. multi-source, multi-format, multi-scale, and multi-disciplinary, the impor- tance of semantics on accessing and integration of distributed geospatial information has long been recognized (Sheth, 1999). The advent of the Semantic Web promises a generic framework to use ontologies to capture the meanings and rela- tions for information retrieval. But this framework does not relate explicitly to some of the most basic geospatial entities, properties and relationships that are most critical to a particular geospatial information processing task. To better support the discovery, retrieval and consumption of geospatial information, the Geospatial Semantic Web is initiated to create and manage geospatial ontologies to capture the semantic network of geospatial world and allow intelligent applications to take advantage of build-in geospatial reasoning capabilities for deriving knowledge. It will do so by incorporating geospatial data semantics and exploiting the semantics of both the processing of geospatial relationships and the description of tightly-coupled service content (Egenhofer, 2002; Lieberman, Pehle, & Dean, 2005). The Geospatial Semantic Web was identied as an immediately-considered research priority early in 2002 (Fonseca & Sheth, 2002) by UCGIS (Uni- versity Consortium for Geospatial Information Science). As an international voluntary consensus standards organization, OGC (Open Geospatial Consortium) conducted the Geospatial Semantic Web Interoperability Experiment (GSW-IE) in 2005 aiming to develop a method of discovering, querying and collecting geospatial content on the basis of formal semantic specications. The architecture of the Geospatial Semantic Web is similar to that portrayed in Figure 1. The Geospatial Semantic Web and the Semantic Web share top level (general) ontology, ontological lan- guages, and general reasoning mechanisms. The Geospatial Semantic Web extends the Semantic Web with domain-specic components. Among all the components of the Geospatial Semantic Web, two are especially unique – geospatial ontology and geospatial reasoning. The former aims at expressing geospatial concepts and re- lationships, specialized processing of geospatial rules and relationships, and self-described Web service with its highly dynamic geospatial con- tent beyond the purely lexical and syntactic level (Egenhofer, 2002; Lieberman et al., 2005; O'Dea, Geoghegan, & Ekins, 2005). The latter embraces sets of geospatial inference rules on the basis of geospatial ontologies and techniques to conduct automated geospatial reasoning by machine with less human interaction for deriving geospatial knowledge. These two are the foci to be elaborated in the following two sections in this paper. Two application cases are presented to show the syn- dicated achievements of the Geospatial Semantic Web. A short summary is given at the end. geosp At IAL ont oLogy It is widely recognized that ontology is critical for the development of the Semantic Web. Ontology originated from philosophy as a reference to the nature and the organization of reality. In general, an ontology is a “specication of a conceptual- ization” (Gruber, 1993). In the computer science domain, ontology provides a commonly agreed upon understanding of domain knowledge in a generic way for sharing across applications and groups (Chandrasekaran, Johnson, & Benjamins, 1999). Typically, ontology consists of a list of terms (classes of objects) and the relationships between those terms. Moreover, ontology can also represent property information (e.g., an aireld has runways), value restrictions (e.g., aircraft can only take off at an aireld), disjointness statements (e.g., aircraft and train are disjoint), and speci- 181 Geospatial Semantic Web cation of logical relationships between objects (e.g., a runway must be at least 400 meters long for supporting C5A aircraft). In the geospatial domain, a specic range of geospatial ontolgoies are needed to dene a formal vocabulary that sufciently captures the semantic details of geospatial concepts, categories, rela- tions and processes as well as their interrelations at different levels. A geospatial ontology does not simply give a denition, but also represents relationships between concepts. For example, an ontological denition of “surface water” describes its properties and characteristics but also carries relationship meanings to other entities, such as “surface water” belongs to “hydrosphere”, and “river” is a kind of “surface water”. A well-formatted geospatial ontology is very useful in the following areas: • Int eroperability. Since the geospatial sci- ences deal with phenomena across a variety of scales and disciplines, the semantics of geospatial information is essential for the development of interoperable geospatial software and data formats. Geospatial ontol- ogy provides a common understanding of not only general geospatial concepts but also complex geospatial scientic computing. Through geospatial ontology, the different geospatial data models and representations can be integrated. • Spa tial reasoning about geospatial associa- tions and patterns, e.g., topological relations (connectivity, adjacency and intersection of geospatial objects), cardinal direction (relative directions among geospatial ob- jects, such as east, west and southwest), and proximity relations (geographical distance between geospatial objects, such as A is close to B and X is very far from Y, and contextual relations, such as an obstacle separates two objects that would be considered nearby space, but are considered far because of the obstacle) (Arpinar, Sheth, & Ramakrishnan, 2004). • Reu se and organization of information, such as standardizing libraries or reposi- tories of geospatial information and work- ows. Compared to general ontologies, geospatial ontologies specically encode 1) spatial concepts, e.g., location and units, 2) spatial relationships, e.g., inside, near and east, 3) physical facts, e.g., physical phenomena, physical properties and physical substances, 4) geospatial data, e.g., data properties, such as instruments, platforms and sensors, and 5) geospatial computing processes, e.g., disciplines, parameters and algorithms. According to the interactions and the role within the context of the Geospatial Semantic Web, geospatial ontology can be classied into several large groups with hierarchical relationships as Figure 2 in which the ontologies at upper levels are consistent to the ontologies at lower levels. General ontology is the core upper level vo- cabulary representing common human consensus reality that all other ontologies must reference. It is domain independent. The widely used Dublin Core Metadata (Dublin, 2006) provides a standard for metadata vocabularies to describe resources that enable the development of more intelligent information discovery systems. OpenCyc (Open- Cyc, 2006) is the world's largest and most com- plete general knowledge base and commonsense reasoning engine dening more than 47,000 upper level concepts and 306,000 assertions about these concepts. Geospatial feature ontology, dening geospa- tial entities and physical phenomena, provides the core geospatial vocabulary and structure, and forms the ontological foundation of geospatial information. It should be coordinated with the development of geospatial standards to dene its scope and content, such as the ISO 19100 series and the OGC specications. Geospatial factor ontology describes geospatial location, unit conversion factors and numerical exten- sions. To enable geospatial topological, proximity [...]... UCL Campbell, A., Pham, B., & Tian, Y.-C (20 05, Dec 1 2-1 5, 20 05) A delay-embedding approach to multi-agent system construction and calibration Paper presented at the International Congress on Modelling and Simulation, Mebourne, Australia Chen, C.-C., Thakkar, S., Knoblock, C A., & Shahabi, C (2003) Automatically annotating and integrating spatial datasets Paper presented at the Proceedings of the Eighth... Improve Performance of GIS Web Services Proc of International Conference on Information Technology (ITCC) 2004 Volume II, Las Vegas, NV Vinoski, S (1997) CORBA: Integrating diverse applications within distributed heterogeneous environments IEEE Communications Magazine, 45( 2), 4 6 -5 5 Whiteside, A (Ed.) (20 05) OpenGIS web services architecture description Open Geospatial Consortium, Discussion paper key T... creation of GML-based application, GML provides GML profiles that are XML schemas that extend the very GML specification in a modular fashion A GML profile is a GML subset for a concrete context or application but without the need for the full GML grammar, simplifying thus the adoption of GML and facilitating its rapid usage Some common examples of GML profiles that have been published are Point Profile,... are interested in the different interpretations and typologies of agents in different contexts may refer to Weiss (2000) and Nwana (Nwana, 1996) for an in-depth discussion In this context, the definition focuses on the most commonly agreed-upon property of agents - namely, their autonomous ability This is the backbone in forming multi-agent systems Multi-agent systems are formed by many agents that... Applications, 26(4), 2 8-3 3 ISO 19119:20 05, Geographic Information – Services ISO/TC 211 Geographic information/Geomatics Kaye, D (2003) Loosely coupled: the missing pieces of Web services, Marin County, California: RDS Press Lara, R., Roman, D., Polleres, A., & Fensel, D (2004) A conceptual comparison of WSMO and OWL-S Proc of European Conference on Web Services 2004, Springer LNCS, 25 4-2 69 McIlraith, S .A., ...Geospatial Semantic Web Figure 2 The hierarchy of geospatial ontology Geospatial Service Ontology Geospatial Data Ontology Geospatial Domain-Specific Ontology Geospatial Factor Ontology Geospatial Relationship Ontology Geospatial Feature Ontology General Ontology and contextual reasoning, geospatial relationship ontology represents geospatial and logical relationships between geospatial features The RDF... Conference on e-Technology, e-Commerce and e-Service, Hong Kong, China Hakimpour, F (2003) Using Ontologies to Resolve Semantic Heterogeneity for Integrating Spatial Database Schemata University of Zurich, Zurich, Swiss Hare, M., & Deadman, P (2004) Further towards a taxonomy of agent based simulation models in environmental management Mathematics and Computers in Simulation, 64(1), 2 5- 4 0 Hraber, P T., Jones,... perspective Autonomous Robots, 8(3), 3 45 383 JADE: Java Agent Development Framework One of the most popular open source agent frameworks implemented in the Java language Torrens, P M (2006) Simulating sprawl Annals of the Association of American Geographers, 96(2), 24 8-2 75 Multi-Agent Simulation: The simulation of a multi-agent system where agents are located in an environment In such an environment, agents... technologies Intl Journal on Very Large Data Bases, 12(1), 5 9-8 5 Alameh, N (2003) Chaining Geographic Information Web Services IEEE Internet Computing, 7 (5) , 2 2-2 9 Fielding, R.T (2000) Architectural Styles and the Design of Network-based Software Architectures PhD thesis, University of California, Irvine Hobona, G., James, P., & Fairbain, D (2006) Web-Based Visualization of 3D Geospatial Data Using... modeling/simulation, and geospatial data mining These applications are just the tip of the iceburg Many are beyond the scope of this Table 1 Properties of an agent(Franklin & Graesser, 1997; Russell & Norvig, 2002; Weiss, 2000) Propert y Description Reactive reaction based on its sense Autonomous responses based on its own experiences Rational maximize its own interest goal-oriented pursue an goal temporally continuous . generation and ingestion, a conceptual schema for catalog service, and a query interface for catalog service. Metadata generation and ingestion is always based on applicable metadata standards,. evalu- ate its quality through metadata. Most metadata provide information on how to acquire the data; in many cases, links to the data or an order form are available online. The NASA Earth. requirements. In addition to international and national geospatial metadata standards, such as ISO 191 15 and FGDC CSDGM, several agencies may have de-facto standards in their production environment,