1. Hydrologic Ontologies Framework Michael Piasecki Department of Civil, Architectural, and Environmental Engineering Drexel University SICOP-Forum Expedition Meeting Arlington, VA June 28, 2005 Page 1 Drexel University, College of Engineering

2. Page 2 Drexel University, College of Engineering Why Hydrologic Ontologies? 1.To resolve semantic heterogeneities between disparate metadata descriptions, e.g. “Gauge Height = Stage = Stream Gauge”, by representing metadata profiles in the Web Ontology Language. 2.To create a Hydrologic Controlled Vocabulary for navigation and discovery of hydrologic data, e.g. a framework that aids discovery (on a more generalized level) and defines markup (on a finer or “leaf” level) to identify specific data sets within a Digital Library. 3.To develop a conceptual representation for the Hydrologic Domain within which data discovery and information extraction can be inferred from knowledge representations. Lets focus on this ……………

3. Page 3 Drexel University, College of Engineering Domain and Scope of Hydrologic Ontologies Basic questions: What is the domain that the ontology will cover? For what we are going to use the ontology? For what types of questions the information in the ontology should provide answers? Who will use and maintain the ontology? Competency questions (litmus test): What streams belong to Hydrologic Unit XYX? What is the net volume flux in watershed A for month Y? What was the accumulated rainfall in region Y because of storm X? What is the discharge time-history at point X as a result of storm Y passing through? ???

4. ISO 19103 Units/Conversion Page 4 Drexel University, College of Engineering Ontology Examples Status We currently have ISO 19108 Temporal ObjectsUSGS Hydrologic Unit CodeISO 19115 Geospatial Hydrologic Processes Sedimentation ARCHydro What we need is Many More Upper Hydrologic Ontology

5. Page 5 Drexel University, College of Engineering Example Use

6. Page 6 Drexel University, College of Engineering GEON sponsored Workshop San Diego Supercomputer Center January 27-28, 2005 Many thanks to Chaitan Baru (agree to sponsor) and Margaret Banton for organizing. Participants Michael PiaseckiDrexel University (convener) David MaidmentUniversity of Texas, Austin Thanos PapanicolaouUniversity of Iowa Edwin WellesNOAA, National Weather Service, OHD Luis BermudezMonterrey Bay Aquarium Research Institute (MBARI) llya ZaslavskySDSC Kai LinSDSC Ashraf MemonSDSC Objective: Discuss concepts for Upper Hydrologic Ontology

7. Page 7 Drexel University, College of Engineering A few rules: 1) There is no one correct way to model a domain— there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate. 2) Ontology development is necessarily an iterative process. 3) Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain. Be cognizant of ……….

8. Page 8 Drexel University, College of Engineering 1 st Alternative Hydrologic Ontologies GeoVolume concept horizontal slices no vertical tracing class:hydrology subclass:precip subclass:……… subclass:…….. subclass:atmos water subclass:surface water subclass:sub-surf. water 15 km ~2 m -1 km Pros: categorization along spatial separations, easy to follow closely linked to hierarchical structure of CV traditional linkage to disciplines and sub-disciplines horizontal flow path is well represented model domains are typically aligned with horizontal layers Cons: vertical flow (budget) not represented well need prior knowledge in which domain to search for data processes are sub-items on low levels of ontology, this may not suit the general idea of moving from more general to more specific concepts

9. Page 9 Drexel University, College of Engineering 2 st Alternative Hydrologic Ontologies Measurement concept everything is a measure expand to include phenomena & features Feature:Basin Curve-# ……

10. Page 10 Drexel University, College of Engineering 3 st Alternative Hydrologic Ontologies “Interests” concept models (prediction, analysis) data models (obs, measurements) processes (phenomena) representations (maps, time series, …) Data Model ArcHydro class:hydrology subclass:Sediment subclass:Heat Flux subclass:Flooding subclass:models subclass:data subclass:processes dimension Type …. Pros: direct link to processes & data models of interest can link data sets directly with processes can make use of many already existing conceptualizations models (statistical, deterministic etc) can be well mapped Cons: not very good for hierarchical navigation there is no general -> specific transition difficult when trying to use for CV or keyword lists might be difficult for “new” knowledge discovery

11. Page 11 Drexel University, College of Engineering Outcomes Hydrologic Ontologies Development of a higher level Hydrologic ontology based on the afore mentioned concepts. The group felt no clear affinity for one or the other concepts. As a result, two top ontologies may need to be developed and placed next to each other. Depending on the task at hand a user may use either one of them to address the objective. Development of lower ontologies that can be merged with the top ontology. a) development of ontologies from database schema (like ARCHydro and the NWIS data base) via XML schema libraries b) development of a processes (or phenomena) ontology c) development of modeling ontology d) inclusion of very task specific (service) ontologies, e.g. units, temporal Development of a well defined Hydrologic Controlled Vocabulary that can be used to query the hydrologic realm. One suggestion made was to use common queries as a starting point to identify important aspects in the taxonomy of the CV.

12. Page 12 Drexel University, College of Engineering HYDROOGLE Application Hydrologic Ontologies Upper Ontology: Measurements Lower Ontology: HUC system coupled with

13. Page 13 Drexel University, College of Engineering Thank you Questions? http://loki.cae.drexel.edu:8080/web/how/me/metadatacuahsi.html

14. Page 2 Drexel University, College of Engineering Pros: direct link to processes & data models of interest can link data sets directly with processes can make use of many already existing conceptualizations models (statistical, deterministic etc) can be well mapped Cons: not very good for hierarchical navigation there is no general -> specific transition difficult when trying to use for CV or keyword lists might be difficult for “new” knowledge discovery