Some design patterns for domain ontology building and
Some design patterns for domain ontology building and analysis Aldo Gangemi a. gangemi@istc. cnr. it LOA-ISTC-CNR, Viale Marx 15, Roma, Italy
What is LOA? § Laboratory_for_Applied_Ontology • -part. Of- Institute_of_Cognitive_Sciences_and_Technology • -part. Of- Italian_National_Research_Council • -member. Numerosity- 125 (70 staff) • -location- {Roma, Trento, Padova} • -head- Cristiano_Castelfranchi • -member. Numerosity- 13 • -location- {Roma, Trento} • -head- Nicola_Guarino • -research. Topic- {axiomatic_theories, foundational_ontologies, domain_ontologies, lexical_ontologies, ontology_development} Manchester, 15/16 January 2004 2
Selected ongoing Projects § IKF : Intelligent Knowledge Fusion (Eureka Project) Ontology of banking transactions (with ELSAG Banklab) Ontology of Service-Level Agreement and IS monitoring (with SELESTA) Ontology of Insurance Services (with Nomos Sp. A) § Wonder. Web (FP 5): Ontology Infrastructure for the Semantic Web (LOA: foundational ontologies for the Semantic Web, ontology of information, ontology of services) § Onto. Web (FP 5 - No. E): Ontology-based information exchange for knowledge management and electronic commerce (LOA: SIG on Content Standards) § FOS (with UN-FAO): Alignment of legacy fishery terminologies, ontology-based query expansion § Metokis (FP 6 - Strep): Middleware between domain knowledge and user task-oriented applications (LOA: Task modelling ontology for the communication of knowledge objects) § SEMANTIC MINING (FP 6 - No. E): Semantic Interoperability and Data Mining in Biomedicine § TICCA (PAT&CNR): Interaction and cooperation with artificial agents (LOA: ontology of social interaction) Manchester, 15/16 January 2004 3
Collaborations § § § § U. of Trento, Padova, Roma, Torino, Verona ITC-IRST ITTIG-CNR, ILC-CNR History of Science Museum, Florence IRIT-CNRS IFOMIS Columbia University U. of Manchester, Leeds U. of Amsterdam, VUA Berlin-Brandenburgische Akademie der Wissenshaften U. of Leipzig, Bremen, Hamburg European Media Lab, Heidelberg U. of Salzburg U. of Queensland ICS-Forth, Heraklion UPM Manchester, 15/16 January 2004 § IBM Italia § Nomos Spa § Selesta Spa § Elsag Spa § Libero/Wind § UN-FAO § Boeing Inc § IBM Watson Research Centre § Ontology Works § Language & Computing 4
Research topics § Logical tools for ontological analysis and development § Domain ontologies § • Physical objects and artifacts • Information and information processing • Social interaction • Legal and financial entities • Biomedical entities • Services and planning • Fishery and agriculture • Cultural heritage Ontology in language and cognition • § Lexical ontologies Ontology-driven information systems • Conceptual modeling • Information access • Information integration Manchester, 15/16 January 2004 5
Levels of Ontological Precision tennis football game field game court game athletic game outdoor game(x) activity(x) athletic game(x) court game(x) athletic game(x) y. played_in(x, y) court(y) tennis(x) court game(x) double fault(x) y. part_of(x, y) tennis(y) game athletic game court game tennis outdoor game field game football Taxonomy Glossary Catalog game NT athletic game NT court game RT court NT tennis RT double fault Thesaurus Axiomatized theory DB/OO scheme Ontological precision: the ability to catch all and only the intended meaning (for a logical theory, to be satisfied by intended models) Manchester, 15/16 January 2004 6
Ontological layers A layering example in molecular biology Manchester, 15/16 January 2004 7
Use of layers in ontology integration Fishery legacy “light” ontologies Onto. Word. Net fragments An example in fishery Manchester, 15/16 January 2004 Fishery core ontology DOLCE foundational ontology 8
WW Foundational Ontologies Library (WFOL) § Reflects different commitments and purposes, rather than a single monolithic view. § A starting point for building new foundational or domain ontologies. § A reference point for easy and rigorous comparison among different ontological approaches. § A common framework for analyzing, harmonizing and integrating existing ontologies and metadata standards. Manchester, 15/16 January 2004 9
The structure of the WFOL § Modules are organized along two dimensions: • visions, corresponding to basic ontological choices made • specificity, corresponding to the levels of generality/specific domains Choose Vision Mappings between Visions/Modules and Lexicons 4 D 3 D Top Choose Specificity Bank Law Formal Links Between Visions and Modules Single Module Manchester, 15/16 January 2004 Single Vision 10
Current “implementation” of the WFOL § Axiomatic (FOL) characterization of three visions (DOLCE, OCHRE, and BFO) § KIF encoding of DOLCE and OCHRE § OWL encoding of (a part of) DOLCE (DOLCE-Lite) § OWL/KIF encoding of (a part of) DOLCE+D&S (DOLCE-Lite+) § OWL/KIF encoding of the web services “ontology” § Formal mapping of OCHRE into DOLCE § Word. Net-DOLCE alignment (in KIF) § … core ontologies extending DOLCE-Lite+ in specificity (time, plans, services, legal, finance, …) § … forthcoming OCML version of DOLCE-Lite+ Manchester, 15/16 January 2004 11
Basic Assumptions of DOLCE § DOLCE: a Descriptive Ontology for Linguistic and Cognitive Engineering § Strong Cognitive/Linguistic bias • Categories mirror cognition, common sense, and the lexical structure of natural language. • Categories as conceptual containers: no “deep” metaphysical implications wrt “true” reality. • No deep commitment on “intellectual economy” of the primitives notions adopted: focus on the simplicity of the representation primitives. Manchester, 15/16 January 2004 12
Basic Ontological Choices in DOLCE § § § Objects/Substances and Events/Processes are distinct categories linked by the relation of participation. Qualities inhere in Objects (Physical Qualities) or in Events (Temporal Qualities) and they corresponds to “individualized properties”, i. e. they inhere only in a specific entity, e. g. “the color of this court”, “the velocity of this serve”, etc. Each kind of Quality is associated to a Quality Space representing the space of the values that qualities can assume • • § § Quality Spaces are neither in time nor in space Different quality spaces associated to the same kind of Quality are admitted. Space and Time are specific quality spaces Different kinds of space and time are admitted. Different Objects or Events can be spatio-temporally co-localized: the relation of constitution is considered Rich axiomatization of classes and relations Manchester, 15/16 January 2004 13
Going practical: Generic Use Cases and Ontology Design Patterns § Foundational ontologies are applied § Sample Generic Use Cases: • • • who does what, when and where? what are the parts of sth? what is it made of? what’s the place of sth? what’s the time frame of sth? how can you do what you do? does my behaviour conform to that rule? what’s the function of that artifact? how is it built? how did that phenomenon happen? what’s your role in that affair? is my scheduling compatible with yours? Manchester, 15/16 January 2004 14
DOLCE-Lite+ library link to built-in representation ontologies Top DOLCE-Lite Extrinsic Descriptions Time m. topology Communication Modalities Places Funct. participation Plans Legal Domain #1 Services WN alignment Biomedical Domain #2 Banking Domain #3 Word. Net Manchester, 15/16 January 2004 15
From foundational ontologies to ODPs Manchester, 15/16 January 2004 16
Related work on design patterns § Theoretical architecture: C. Alexander, The Timeless way of building, 1979 § Software engineering: E. Gamma et al. , Elements of reusable OO software, 1994 • D. Maplesden et al. , Design Pattern Modelling Language • N. Baker et al. , Meta-modelling patterns (-> “descriptive models”) § Ontology engineering (very recent interest): • G. Guizzardi et al. , LINGO: foundation for meta-environments, domain engineering in requirement analysis (bridging OE and OO) • J. R. Reich, patterns of ontology constructs, applied to Mbiology • M. Klein: ontology change/versioning patterns • G. Schreiber: started committee on DPs in OE • ODPs here: focus on the architecture of the content, rather than on the architecture of the logical form that represents that content Manchester, 15/16 January 2004 17
This talk: using UML class diagrams § Non-standard use of UML to visualize ODPs: • • generalisation -> subsumption (“sub. Class. Of”) association -> two-way conceptual relation (“property”) attribute -> one-way conceptual relation (“property”) assuming reasoning capabilities with classification and role chaining • association with no cardinality: 0. . * Manchester, 15/16 January 2004 18
Basic DOLCE pattern (participant match#1 {Enrico, Aldo}) (located {Enrico, Aldo} Milton_Keynes) (located match#1 2004_Jan 18_1: 002: 00 GMT) (part match#1 ace#12) Manchester, 15/16 January 2004 19
Time intervals pattern MTA(x, y) (Mereo. Topological Association) =df weekly connected(x, y) strongly connected(x, y) part(x, y) overlaps(x, y) successor(x, y)) deducible from sufficient conditions [(located match#1 2004_Jan 18_12: 0013: 00 GMT) (located match#2 2004_Jan 23_12: 0013: 00 CET) (successor 2004_Jan 18_12: 0013: 00 GMT 2004_Jan 23_12: 0013: 00 CET)] (precedes match#1 match#2) Manchester, 15/16 January 2004 20
Places pattern not deducible from necessary conditions (place ball#1 racquet#2) [(located ball#1_space) (located racquet#2_space) (weakly_connected ball#1_space racquet#2_space)] Manchester, 15/16 January 2004 21
Extensions of DOLCE (1) Descriptions and Situation § § § It’s an ontology of rationality and epistemology (about “knowledge” objects) Pluggable in any existing “ground” ontology Reified theories, concepts, and states of affairs • • • § § § Reified theories are called s-descriptions (or contexts) Reified concepts are called c-descriptions (or roles) Reified states of affairs are called situations (or configurations) An s-description can be satisfied by a situation An s-description is composed by c-descriptions A situation is constituted by entities in the ground ontology A c-description has systematic relations with sibling c-descriptions, and with entities in the ground ontology There results a typical design pattern to develop “core” domain ontologies D&S is able to explicit: • • • the commited entities in a domain the roles and contexts in which those entities are used, and the expected or desired configurations that appear in those roles/contexts Manchester, 15/16 January 2004 22
Situations § § States of affairs can be extracted from the world in many ways Situations reify states of affairs under a certain descriptive Unity Criterion A situation must satisfy at least one s-description This means that no state of affairs is reified in D&S unless it has an explicit sdescription (constructivist stance) • • § Many uses of D&S involve matching an independently introduced situation to existing s-descriptions (e. g. legal cases vs. jurisprudence, executions of plans vs. plans, clinical conditions vs. diagnoses, etc. ) • § only what we are dealing with … uselessness of providing combinatorial precomputation of SOAs some D&S apps do not involve matching, e. g. narrative descriptions A situation can then be matched either against its generating description (e. g. in plan execution assessment), or against a new one (e. g. in legal cases or in clinical diagnoses) • • the second case can be called redescription these mechanisms are inspired by cognitive processes like Gestalt psychology figureground, and development as re-presentation (cf. Koehler, Karmiloff-Smith) Manchester, 15/16 January 2004 23
some D&S axioms Manchester, 15/16 January 2004 24
Minimal D&S pattern (pluggable into any FO) @( ) means that the situation [(s-description traffic_norm#232) (c-description {driving_task, driver, vehicle, speed_limit) is generated through a “door” (selects driving_task driving#3283376400) s-constituent on the basis of (selects driver Enrico) production rules (selects vehicle Lotus_Elise#M 186 YER) (selects speed_limit 60 mph) (speed_location driving#3283376400 130 mph)] [@(situation driving_sit#666) (setting-for driving_sit#666 {driving#3283376400, Enrico, Lotus_Elise#M 186 YER, 130 mph})] Manchester, 15/16 January 2004 25
DOLCE+D&S pattern Descriptive entities Ground entities Manchester, 15/16 January 2004 26
D&S specialization for norms [(legal_description traffic_norm#232) (legal_course driving_task) (legal_role driver) (legal_role vehicle) (legal_parameter speed_limit) (sequences driving_task driving#3283376400) (played_by driver Enrico) (played_by vehicle Lotus_Elise#M 186 YER) (valued_by speed_limit 60 mph) (speed_location driving#3283376400 130 m)] [@(case driving_sit#666) (setting_for driving_sit#666 {driving#3283376400, Enrico, Lotus_Elise#M 186 YER, 130 m})] Manchester, 15/16 January 2004 27
Extensions of DOLCE (2) Plans and task models § § § Using D&S, some other extensions are being developed A preliminary plan ontology has been defined by starting from the harmonizing of existing clinical guidelines standards Basic distinction between plans as contexts (methods), and plan execution as configuration Typical attributes of plans are different from those of an execution (e. g. “approved” vs. “started”) A plan is composed by tasks, roles, and parameters Tasks sequence actions or processes • • • § § § Succession relations applicable that mirrors temporal relations Task≠Action (cf. “alternative” vs. “running”) Distinction btw action tasks and rational tasks (branching, joining) Roles are played by objects or substances Parameters select regions within quality spaces Plan representation is also addressed by using an ontology of communication Manchester, 15/16 January 2004 28
D&S specialization for plans Manchester, 15/16 January 2004 29
D&S specialization for designs Manchester, 15/16 January 2004 30
Information and symbols pattern Manchester, 15/16 January 2004 31
D&S specialization for inflammations Manchester, 15/16 January 2004 32
D&S specialization for fishery Manchester, 15/16 January 2004 33
Features of ontology design patterns § § § Any ontology is a potential domain design pattern, since it can instantiate a set of states of affairs. An ODP focuses on specialization, rather than instantiation An ODP is similar to top-level or foundational ontologies, but it has certain additional properties: 1. 2. 3. 4. 5. 6. 7. 8. 9. An ODP is a template for solving a domain modelling problem An ODP "extracts" a fragment of a TLO or FO, which is its "background” An ODP is axiomatized according to the fragment it extracts An ODP can be represented in any ontology representation language, although its intuitive and compact visualization seems an essential requirement An ODP can be an element in a partial order, where the ordering relation requires that at least one of the classes or relations in the ODP are specialized An ODP can be intuitively exemplified and catches relevant "core" notions of domains An ODP can be often built from informal or simplified schemes used by domain experts, together with the support of a foundational ontology and a methodology for domain ontology analysis, or by specializing existing ODPs An ODP can/should be used to describe a "best practice" of modelling An ODP is similar to a DB schema, but an ODP is defined wrt a foundational ontology and should have a general character, independently from local design details Manchester, 15/16 January 2004 34
Application of DOLCE (3) Word. Net alignment and Onto. Word. Net § Onto. Word. Net research program jointly with other institutions § 809 synsets from Word. Net 1. 6 directly subsumed by a DOLCE+D&S class • Whole Word. Net linked to DOLCE+D&S • Lower taxonomy levels in Word. Net still need revision § Glosses being transformed into DOLCE+ axioms • Machine learning applied jointly with foundational ontology § Word. Net “domains” being used to create a modular, general purpose domain ontology Manchester, 15/16 January 2004 35
Considerations on domain ontology building § Developing precise domain ontologies is time-consuming, and requires high competences § Not always is deep granularity required § Not always is full expressivity required § Our position: • “lightweight” is ok, but if we a have a level for sharing intuitions and to establish negotiation, it is much better • “local” precise ontologies are ok, but if we have a level to align and merge different locals, it is much better • precision is “heavyweight”, but scalability is reachable by using good patterns and interfaces Manchester, 15/16 January 2004 36
- Slides: 36