Semantic Model Support for Geographic Information Systems

1. Semantic Model Support for Geographic Information Systems Sudha Ram Department of Management Information Systems The University of Arizona

2. Agenda • Research Motivation • GIS Data Management Problems • Need for a Semantic Model • USM* Constructs and Formal Definitions • Architecture of the Data Management System • Advantages of Using the USM* • Lessons Learned • Future Research Directions

3. Natural Resource Management • Requires large amount of spatial & temporal data. • Example: Risk management assessment concerning fire: • Lack of understanding about how fire behaves. • Typical questions that are investigated: • “How fast will the fire move under specified conditions?” • “How hot will the fire be at certain points?” • Understanding action of fire can be done using models. • Simulation Models + GIS Databases • Requires experts from both areas

4. A fire simulation requires: Weather model temperature, wind speed, cloud cover, and other climatological factors Fire model weather model, fuels, time of the day, terrain, etc. Data about the area of interest terrain, slope, aspect, fuels, firebreaks, etc. Two experts are required: Modeler GIS technician A fire simulation model Risk Management Assessment Process - Fire Model Weather Model Fire Model GIS Data + + Two Experts User

5. Objective of Research • To define a formal model (USM*) to capture semantics of spatiotemporal data. • To facilitate the integration of simulation models with GIS databases.

6. Why do we need a Semantic Model • To narrow the gap between users and data/models. • Currently existing data models do NOT: • combine both spatial and temporal data. • link simulation models and GIS data. • capture dynamic behavior of spatiotemporal objects (e.g., fire). • Why not object-oriented data model? • Relationships between/among spatial objects are explicit in a semantic model. • Constraints are explicit in a semantic model. • Dynamic behavior is explicitly captured in a semantic model. • All of the above is hidden in the methods in OO models.

7. Existing Data Models Proposed in the Literature • Semantic Models Chen (1976), Hammer and McLeod (1981), Hull and King (1987), Abiteboul and Hull (1987), Peckham and Maryanski (1998), Ram (1995) • Object-Oriented Models Alves, D. (1990), Herring (1992), Lipeck and Neumann (1986), Wiegand and Adams (1994), Worboys et al. (1990) • Spatial Models Gambosi et al. (1988), Goodchild (1992), Guptill (1990), Gutting (1988), Orenstein and Manola (1988), Raper and Bundock (1991), Worboys (1992) • Temporal Models Elmasri and Wuu (1990), Newell et al. (1992), Langran and Chrisman (1988), Wuu and Dayal (1992)

8. Constructs for Modeling Spatiotemporal Data (USM*) • Spatiotemporal entity class (e.g., riparian zone) • Dynamic entity class (e.g., fire, erosion) • Spatiotemporal aggregates • Spatial aggregate (e.g., states - cities, counties, rivers…) • Temporal aggregate (e.g., climate - aggregate of weather) • Simple spatiotemporal aggregate (e.g., weather) • Spatiotemporal interaction relationship • Topological relationship (e.g., overlap, disjoint, touching) • Spatial order relationship (e.g., above, below, left_of, right_of) • Metric relationship (e.g., within) • Fuzzy relationship (e.g., near, far) • Motion relationship (e.g., spreads, enters) • Cause-effect relationship (e.g., changes, erodes)

9. GEOLOGY SOIL_LAYER described_by describes COUNTIES WATER Spatial Agg covered_by SOIL covers contains found_in S RIPARIAN_ZONE eroded_by WEATHER erodes VEGETATION SOIL_EROSION enum induces FUEL changed_by impacts spreads SLOPE ASPECT ELEVATION FIRE TERRAIN Spatial Agg Example USM* - Part 1

10. WATER SOIL S S S adjacent P GROUND_WATER SUBSURFACE_WATER RIPARIAN_ZONE SURFACE_WATER falls U SUR_SUBSURFACE_WATER INFILTRATION S S P POND STREAM discharge infiltrates discharged_by PRECIPITATION CHANNEL S RUNOFF TEMPERATURE RAINFALL P determines determined_by OVERLAND_FLOW S SUNSHINE HUMIDITY WIND Simple ST Agg WEATHER CLIMATE Temporal Agg Example USM* - Part 2

11. Graphical Representation of USM* Constructs Entity Name Entity Name Entity Name Spatiotemporal Entity Class Dynamic Entity Class Spatiotemporal Aggregate Entity Class STAGG Spatiotemporal Aggregate Relationship Cause-Effect Relationships Spatiotemporal Interaction Relationships

12. Formal Definition:Spatiotemporal Entity Class Entity Name • Definition - A set of spatiotemporal entities which have spatial (i.e., location) and temporal information, denoted as S = { ei }, • where ei = n-tuple { a1, a2, …, an, si, t }, and i = 1, 2, …, n. • Attributes ai (i = 1, 2, …, n) are non-spatiotemporal attributes, • si is a spatial index that describes locational information for ei and is defined as a subset of the Cartesian product of coordinate sets, si, and • t is a temporal index (e.g., time stamp). • If the value of either one of ai or si changes, a new ei is added with a new value t. • The underlying data can be represented in either a raster-based or a vector-based system. • Examples - riparian zone, vegetation, surface water, runoff, etc.

13. Formal Definition:Dynamic Entity Class Entity Name • Definition - A roster-defined subclass of the spatiotemporal entity class, denoted as D = { di }, • where di = n-tuple defined the same way as ei in the spatiotemporal entity class. • Dynamic (process-oriented) behavior. • A definite birth-to-death state. • The granularity of time interval for the birth-to-death state may be different for different dynamic entity classes. • One of the most crucial components in the simulation environment. • Examples - fire, wind, soil erosion, etc.

14. Formal Definition: Spatiotemporal Aggregates Entity Name STAGG • Definition - The members of the spatiotemporal aggregate entity class are physically or logically made up of members or sets of members from some other spatiotemporal entity class(es), denoted as STA = n-tuple { stai }, • where each stai is defined as an n-tuple { Ei }, where Ei is a spatiotemporal entity class. • Each stai has • a set of spatial indexes si (defined earlier) and • a set of temporal intervals (ti, tj) associated with it, where i, j { 1, 2, …, n } and i j. • Examples - states, counties, climate, weather, etc.

15. Formal Definition: Spatiotemporal Aggregates • SpatialAggregate • A constant time index • For example, entity class STATES is a spatial aggregate whose members are sets of cities, counties, rivers from entity classes CITY, COUNTY, and RIVER. • Temporal aggregate • A constant spatial index. • For example, Arizona CLIMATE is an aggregation of WEATHER in Arizona over time. • Simple spatiotemporal aggregate • A constant spatial and temporal index • For example, Tucson summer WEATHER

16. Formal Definition: Spatiotemporal Interaction Relationships • Definition - A spatiotemporal interaction relationship among n spatiotemporal entity classes, E1, E2, ..., En, defines a set of associations among entities from each of these classes, and denoted as , STI = {stii} • where stii associates n entities (e1, e2, …, en) and each entity ei belongs to Ei, 1  i  n, where Ei is a spatiotemporal entity class. • Associations between and among only spatiotemporal entity classes. • Examples - touching, overlap, inside, above, within, near, far, etc

17. Formal Definition: Spatiotemporal Interaction Relationships • There are five subclasses, each depicted by type t where t = { {topological relationships}, {spatial order relationships}, {metric relationships}, {fuzzy relationships}, {motion relationships}}. • Topological: covers, disjoint, equal, inside, touching, overlap, etc. • Spatial order: above, below, left, right, north, south, in_front_of, behind, etc. • Metric: describe distances and directions, e.g., “list all public buildings within 3 miles from White House.” • Fuzzy: near, far, etc. • Motion: spreads, enters, etc. • These subclasses are NOT mutually exclusive. • The interaction between (instances of) entity classes may change over time as a result of an event.

18. Formal Definition: Cause-Effect Relationship • Definition - An association that relates a set of affectors (or affectees) to a set of affectees (or affectors), and defined as CR = ordered tuple { {Ei}, {Ej} }, • where (EiDEjD )  (EiDEjD ), and D is the set of dynamic entity classes. • Affector: a set of entities that affects the status of other entities, attributes, and relationships • Affectee : a set of entities, attributes and relationships being affected by the affectors. • Examples - A fire changes the composition of vegetation.

19. Formal Definition: USM* Schema (Extended Part Only) • A 2-tuple S = (S, R), where • S is a set of all spatiotemporal entity classes (defined earlier). • R is a set of all spatiotemporal relationships (defined earlier).

20. USM* Metamodel (Extended Part Only)

21. Architecture of the Data Management System

22. Accessing Spatiotemporal Data Through the USM* • Metadata Access • Example query: “Display all different types of fuels about which data is available.” • The browser uses the metadata dictionary and mapping dictionary. • Metadata and Data Access (Spatial Queries) • Example query: “Display all counties where each type of vegetation is found.” • The data accessor uses the metadata dictionary, mapping dictionary and metadata directory, and calls proper data access object wrappers. • Data Access • Example query: “Show a particular county about which vegetation data is available.” • The data accessor uses the metadata dictionary, mapping dictionary and metadata directory, and calls proper data access object wrappers. Mediators will perform necessary conversions and resolve (or inform) the semantic conflicts. • Access to Output from Simulation • Example query: “How fast is the fire spreading and which area will be affected by it?”

36. Implementation • Common repository resides in Oracle Server 8. • Domain knowledge is encoded using Java. • Applications are written in Java (& Swing). • stand-alone application • accessed via Java enabled web browser. • Cross platform (NT Pentium Workstation & SUN Ultra 1 Workstation). • Three-tier architecture.

37. Advantages of using the USM* • Users can easily understand the contents of databases and models available in underlying geographic databases. • Users do not need to learn to program using the GIS commands. • Users are spared from having to learn the details of the storage formats and naming conventions. • Data can be accessed in terms of what the user understands. • Allows access to both spatial and temporal data.

38. Lessons Learned • Initial evaluation of the system has been done by a group of ecosystem analysts at the University of Arizona. • The metadata repository is a very important. • USM* constructs evolved over time (e.g., dynamic entity classes and cause-effect relationships). • Access to simulation output through the semantic model. • Access to derived data and models.

39. Future Directions • Detecting & resolving semantic heterogeneity in spatiotemporal data. • Semantic mediators. • Ontology for semantic mediators. • Support for schema evolution.