Design Considerations for Spatial Decision Support Ontologies Karen Kemp, The Kohala Center

1. Design Considerations for Spatial Decision Support Ontologies Karen Kemp, The Kohala Center Robert Raskin, Jet Propulsion Laboratory Naicong Li, University of Redlands AAG 2009, Las Vegas, Nevada March 22 – 27, 2009

2. Design considerations for SDS ontologies • About the project: • Part of the Spatial Decision Support Knowledge Portal project • Initiated by the Redlands Institute, University of Redlands (fall 2007) • Collaborative workshops on SDS ontologies held at The Redlands Institute (Feb 2008, May 2008) • Establishment of the SDS Consortium (May 2008) • Portal development at The Redlands Institute • Several consortium internal release so far • Plan to open to public in April 2009

3. Design considerations for SDS ontologies • Outline • The need for SDS ontologies • Intended users • Scope and coverage • Development process • Choice of classification scheme • Degree of formalization • Treatment of natural language • Modular design and Potential interface with other ontologies • Advantages of ontology-based Knowledge Portal • Conclusion and future work

4. Design considerations for SDS ontologies Definition of Spatial Decision Support (SDS) Spatial decision support is the computational or informational assistance for making better informed decisions about problems with a geographic or spatial component. This support assists with the development, evaluation and selection of proper policies, plans, scenarios, projects, interventions, or solution strategies. SDS Consortium, based on http://geoanalytics.net/VisA-SDS-2006/

5. Design considerations for SDS ontologies • Intended users • People facing spatial decision problems - decision makers, practitioners, etc. • University researchers and students • Usage: • Find resources for spatial decision support • Learn about spatial decision support

6. Design considerations for SDS ontologies • The need for SDS ontologies • To formally represent the body of knowledge in the field of SDS • To organize the Information about SDS resources • To promote semantic clarity of commonly used terms within a user community, in the area of spatial decision making

7. Design considerations for SDS ontologies • The need for SDS ontologies • To facilitate the development of modular, re-usable, interoperable tools/services • To facilitate the evaluation of existing spatial decision support systems and tools in terms of their functionality and interoperability • The need for SDS ontologies

8. Design considerations for SDS ontologies • Scope and coverage • The body of knowledge is vast • Focus: • Decision problem types • Decision context • Decision process (phases and steps) • Methods and techniques • SDSS functionalities • Sets of properties describing SDS resources: • Tools and models • Data sources, data models • Decision process workflow templates • Case studies • Literature

9. Design considerations for SDS ontologies • Developmentprocess • Literature review for a set of essential concepts and definitions • Review of related web sites for user needs • Collaboration among domain experts (SDS Consortium members) on critical issues: • What to include • Overall structure of ontology set (partition of concepts) • Discussion/debate/agreement on definitions of critical concepts (two workshops; online discussions) • Review of the ontology implementation • Iterative process of addition/review

10. Design considerations for SDS ontologies • Modular design • 8 major components • 35 ontologies

11. Design considerations for SDS ontologies

12. Design considerations for SDS ontologies

13. Design considerations for SDS ontologies

14. Design considerations for SDS ontologies

15. Towards Developing an SDS Solution Portal

16. Design considerations for SDS ontologies • Choice and inclusion of classification schemes • E.g. Classification of methods and technique • Based on their functions serving spatial decision process steps • Based on whether they are for multi-objective or multi-attribute decision making, whether they can handle uncertainty, etc. • E.g. Classification of SDS systems and tools • Based on their software type (system vs. tool) • Based on their the decision process steps they server • Based on their modeling application area (e.g. habitat suitability modeling)

17. Design considerations for SDS ontologies • Choice and inclusion of classification schemes •  The SDS ontologies can accommodate multiple classification schemes for the same group of concepts. •  When a choice needs to be made, often it is driven by the need of the intended user community.

18. Design considerations for SDS ontologies • Degree of formalization • Concepts in SDS ontologies are defined by • Natural language description • Set of formally defined attributes • e.g. analysis-unit attribute of an SDS tool • Set of formally defined relations to other concepts • Parent-child/sibling relations with other concepts • Other associative relations among concepts • e.g. method A is “implemented by” tools X and Y

19. Design considerations for SDS ontologies A method used for this step – simple additive weighting Abbreviation: SAW Synonyms: weighted summation; boolean overlay; weighted linear combination method; WLC; scoring method Definition: SAW is a multiattribute procedure based on the concept of a weighted average; it calculates a total score for each alternative by multiplying the importance weight assigned to each attribute by the scaled attribute value and summing the products over all attributes; the alternative with the highest overall score is best; the procedure can beperformedusing GIS supporting overlay operations. Source of description: Malczewski 1999, p.199 Decision type Deterministic decision problem Individual decision making Multiattribute decision making Decision Maker Interaction Level Moderate Editor ... • Attribute score • Criterion weight Multiattribute decision rule discussed in implemented by is a kind of input Alternative ranking ... (publications) used for • IDRISI • EMDS • ... Simple additive weighting method output • Ordinal ranking

20. Design considerations for SDS ontologies EMDS – a tool implementing simple additive weighting Name: Ecosystem Management Decision Support Acronym: EMDS Overview: The Ecosystem Management Decision Support (EMDS) system provides decision support for integrated landscape evaluation and planning. The system provides decision support for landscape-level analyses through logic and decision engines integrated with ArcGIS 8.1+. The logic engine evaluates landscape data against a formal logic specification, designed with NetWeaver Developer, to derive logic-based interpretations of ecosystem conditions such as biodiversity and sustainability. The decision engine evaluates NetWeaver outcomes (and data related to additional factors such as feasibility and efficacy of land management actions) against a decision model for prioritizing landscape features with decision models built in CriteriumDecisionPlus Platform: Windows XP Cost: Free ... software required analysis unit analysis extent • ArcGIS 9.x • Crriterion Decision Plus • NetWeaver • Sandy River Basin Anchor Habitat Project • ... • Condition assessment • Choice • ... accept data of process types • Multiattribute decision rule • Uncertainty methods • User specified • User specified • EMDS Consortium • Biophysical process • economic process • management process • Social process • ... used for decision process phase/steps used in case studies tool maker methods implemented EMDS EMDS

21. Design considerations for SDS ontologies • Degree of formalization • Use of inverse relations, for example, • for decision process phases / steps and commonly used methods and techniques  specify the reciprocal relations between a method and a process phase/step. • methods and techniques implemented / implemented by tools specify the reciprocal relations between a tool and a method. • used for decision process phases / steps and commonly used tools specify the reciprocal relations between a tool and a process phase/step

22. Design considerations for SDS ontologies • Degree of formalization •  Dictated by the purpose of the ontologies •  Set of attributes and relations that are minimal, but sufficient for the automation of information access as well as reasoning (to derive implicit knowledge)

23. Design considerations for SDS ontologies • Treatment of natural language • Natural language term for concept • Abbreviations or acronyms • Synonyms • Description • Editorial notes (comments, editor, editor’s notes, etc.)

24. Design considerations for SDS ontologies abbreviation SDS Knowledge Repository description synonyms natural language term

25. Design considerations for SDS ontologies • Modular design • 800 concepts, and • 200 attributes and relations, partitioned into • 35 ontologies, grouped into • 8 major components

26. Design considerations for SDS ontologies

27. Design considerations for SDS ontologies • Potential interface with other ontologies • “Upper level ontologies” potentially replaced by available better defined ontologies • Based on part of iso-19115.owl by Drexel University. Data topics re-implemented as classes instead of instances for future expansion for better topic granularity.

28. Design considerations for SDS ontologies • Advantages of an ontology-based SDS Knowledge Portal • Attributes and relations among concepts and formalized to facilitate automatic information retrieval • Search query expansion based on multiple natural language references to the same concept • Search query expansion based on parent-child relations • “Implicit knowledge” extraction based on relations that are inverse, transitive, etc. • “Smart” recommendations based on semantic similarity among concepts

29. Design considerations for SDS ontologies • Conclusion and future work • SDS ontologies provide a conceptual framework for • Formally representing the body of knowledge in the field of SDS • Organizing various types SDS resources • Formally describing SDS resources for interoperability • Future work • Improve the definition of concepts, especially in the area of collaborative decision making • Include more representative, modular, reusable SDS resources, especially tools and models • Consideration for different “dialect” among different user communities (language and dialect tags on rdfs:label property of concepts)

30. Design considerations for SDS ontologies Thank You Karen Kemp, karenkemp@geokemp.com Robert Raskin, Robert.G.Raskin@jpl.nasa.gov Naicong Li, naicong_li@spatial.redlands.edu