1 SOCoP 2012 Workshop: Vision and Strategy Gary Berg-Cross SOCoP Executive Secretary Nov , 2012 U. S. Geological Survey National Center Sunrise Valley Dr., Reston VA

2 Outline for a VoCamp-Style Workshop VoCamp Style is informal Workshop Ingredients 1. Goals 2. Workgroup Teams 3. Logic of Phased Structure Sessions 4. Lightweight Methods 5. From Conceptualizations to Formalizations 6. Cautions and Tradeoffs 7. Ontologies and Ontology Patterns We are not here to teach a new discipline, but to employ multiple disciplines as a team.

3 Goals: “Group Work on Semantic Models of Interest” Building on past workshops and interests: We seek clarified agreement & reduced ambiguities/conflicts on geospatial/earth science phenomena that can be formally represented in: 1. Constrained, engineered models to support understanding, reasoning & data interoperability and/or 2. Creation of general patterns that provide a common framework to generate ontologies that are consistent and can support interoperability. We like data-grounded work since: Much of the utility of geospatial ontologies will likely come from their ability to relate geospatial data to other kinds of information.

4 Workgroups Include Multiple Roles: Semantic Engineering is a Social Process Ontologist Domain/Data Expert Facilitator Note taker

5 Logic of Work Sessions Start Group organization & Introductions, goals and process After lunch Group Work on Concepts, Vocabulary & Model(s) After break Group Work on Draft Models At end of day Group Reports on status At end of day Report back to whole and wrap up 2nd day draft final model & initial formalizations After break Work Groups polish, formalize models After lunch firm up products and test against data After break Prepare Report Day One Intro, Topics, Methods..

6 Lightweight Methods & Products Choose lightweight approaches grounded by scenarios and application needs. Low hanging fruit leverages initial vocabularies and existing conceptual models to ensure that a semantics-driven infrastructure is available for use in early stages of work Reduced entry barrier for domain scientists to contribute data Simple parts/patterns & direct relations to data Ecological.. Triple like parts Constrained not totally Specified. Grounded

7 How Ontologies Arise from “Analysis and Conceptualization ” Adapted liberally from Guarino’s 1998 Formal Ontology in Information Systems 1 World Situations Perceived Distinctions & Situated Experience.. Stream Reaches are segments of surface water with similar hydrologic characteristics Conceptualization starts to adaptively model (part of) the world 2 Abstraction Stream Reach distinction Rationalized Intuition expressed in Some conceptual language Things D in world state W with conceptual relations R C= SW =surface water H=has S = Segments Pragmatic validation Real World Semantics Domain folks and Modelers

8 Ontological Engineering – Formalization 1 World Situations Interaction..That is a type of Stream segment C Conceptualization model (part of) the world Say D Hydrology In some Conceptual Domain space UML OWL 3. To express C we need Language L (Term StreamX corresponds to entity in world) We assign interpretative Functions I & Commitment K. K=<C,I) Models for Domain D Expressible In L Intended Model Fitting C Ontology Models for D Expressed In L using K Adapted liberally from Guarino’s 1998 Formal Ontology in Information Systems Models defines relationship between L syntax and interpretations Logical Model Theories are consistent sets of sentences; closed under logical consequence

9 Caution(s) No single (general or domain) taxonomy or ontology could satisfy all needs. That’s part of the reason we have so many alternative ones. We can make quality, useful ones for one or more purposes. We have intended models of focus. But if we make commitments that make strong claims that are greater our understanding and focus we may be making a mistake(s). Smith and Mark describe a good/quality ontology as one that is: “neutral”, And/or perhaps explicit about what it is not neutral about computationally tractable, acceptable to and reusable by domain people One might add that it is rationalized.

10 Many Challenges – more on this later…. These include tradeoffs between generality and precision. Tom Bittner, for example, notes: “The need for geometric representations, many of which rely on relatively precise boundaries, conflicts with the need for sophisticated classification systems for scientific and integration purposes. “ Vagueness and the tradeoff between the classification and delineation of geographic regions - an ontological analysis  But these, of course, make the work interesting…..

11 Ontologies and Ontology Patterns Many levels & types of ontologies Something like DOLCE is quite complex and so are domain ontologies like SWEET One may pick some small repeating patterns (ODPs) out of large ontologies. ODPs, like OWL, are tools for ontologies They are more easily understandable with good explicit documentation for design rationales Robust Can be used to build on modularly for reoccurring problems needing representation Capture best practices Should help bridging/integrating ontologies We focus on content ODPs using domain expertise rather than logical ODPs etc. owl:Class:_:x rdfs:subClassOf owl:Restric(on:_:y Inflammation>on rdfs:subClassOf (localizedIn some BodyPart) 11 Dolce Ultra Lite? Apps ( Uses Cases & Demos) “Geo”-Domain “Geo” Top Patterns

12 Ontology-ODP Relations Small DUL Portion Social attribute Caratteristica sociale Any Region in a dimensional space that is used to represent some characteristic of a SocialObject, e.g. judgment values, social scalars, statistical attributes over a collection of entities, etc. … ODP Abstract From Use for New Ontology Design “Unfriendly logical structures, some large, hardly comprehensible Ontologies” (Aldo Gangemi)

13 ODP Rationale –Reuse, Minimal Constraints.. Problem It is hard to reuse only the “useful pieces" of a comprehensive (foundational) ontology, and the cost of reuse may be higher than developing a scoped ontology for particular purpose from scratch “For solving semantic problems, it may be more productive to agree on minimal requirements imposed on.. Notion(s) Werner Kuhn (Semantic Engineering, 2009) Solution Approach Use small, well engineered, modular starter set ontologies with explicit documentation of design rationales, and best reengineering practices These serve as an initial constraining network of “concepts” with vocabulary which people may build on/from for various purposes.