1 / 47

ONTACWG: Coordinating Knowledge Classifications

ONTACWG: Coordinating Knowledge Classifications. Patrick Cassidy MITRE Corporation* Presented at the Fourth Semantic Interoperability for E-Government Conference February 9, 2006 MITRE–McLean, Virginia

pia
Télécharger la présentation

ONTACWG: Coordinating Knowledge Classifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ONTACWG: Coordinating Knowledge Classifications Patrick Cassidy MITRE Corporation* Presented at the Fourth Semantic Interoperability for E-Government Conference February 9, 2006 MITRE–McLean, Virginia * NOTE: The author’s affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE’s concurrence with, or support for, the positions, opinions or viewpoints expressed by the author.

  2. ONTACWG Ontology and Taxonomy Coordinating Working Group A working group of the Semantic Interoperability Community of Practice (SICoP) To assist in the development and cross-referencing of Knowledge Classification Systems (Ontologies, taxonomies, thesauri, graphical knowledge representations) by: maintaining on-line resources where such efforts can share: data; utilities to help create such resources; and pilot programs to demonstrate how to use such knowledge classifications for practical purposes (2) To adopt and extend, as a community, a Common Semantic Model that can serve as the “defining conceptual vocabulary” adequate to specify the meanings of the terms used within all of the participating communities, and relate the community terms to each other precisely.

  3. ONTACWG Projects • Forum – e-mail discussion • Web site with resources • http://colab.cim3.net/cgi-bin/wiki.pl?OntologyTaxonomyCoordinatingWG • Repository Working Group • COSMO Working Group

  4. Where Are We? • Many Taxonomies and Ontologies • Few Mappings of One to the Other • No Agreed Standard of Meaning

  5. Where Do We Want To Go? • Powerful Search • Semantic Interoperability • Automatic Knowledge Extraction

  6. How Do We get There? • Create Agreed Standard of Meaning: a Common Semantic Model (COSMO) • Use Existing Upper Ontology or adapt one for our own use • Define (map) terms in Existing Taxonomies and Ontologies by use of Common Defining Concepts

  7. Why Is a Top-Level Ontology Needed? • To support semantic interoperability by serving as a Common Semantic Model, functioning as a common defining vocabulary, allowing systems developed in different locations to share their definitions and reason with each other’s data • To provide a well-tested inventory of basic concepts that can be combined to specify the meaning of domain-specific concepts in a form suitable for reasoning

  8. What Does it Mean to “Specify the meaning of a term”? • “The biological mother of a person is a woman who has given birth to that person” • {{?Mother isTheBiologicalMotherOf ?Child} impliesThat (ThereExists {((exactly one) ?Event) and ((exactly one) ?Date) and ((exactly one) ?Location)} suchThat {{?Event isa BirthEvent} and {?Event occurredOn ?Date} and {?Event occurredAt ?Location} and {?Mother is (The Mother in ?Event)} and {?Child is (The Baby in ?Event)} and {(The BirthDate of ?Child) is ?Date} and {(The BirthPlace of ?Child) is ?Location}})}

  9. The Integrating Function of the Common Semantic Model GenericObligation SameAs SameAs Obligation Duty

  10. The Integrating Function of the Common Semantic Model –via Domain-level Mapping GenericObligation SameAs Obligation SameAs Duty

  11. Taxonomy Mapping for Search • When a category in one taxonomy can be identified with a category in another taxonomy, the documents associated with each node are relevant to the other • When documents indexed by another taxonomy are not of interest to a local community, they can nevertheless be used to train an associative document classifier, which can find the documents in the community document collection that are relevant to that topic

  12. ONTACWG for Search • ONTACWG might maintain, for each topic within a community KCS: • a set of sample documents that can be used to classify a local document collection by associative document-matching techniques • one or more sample queries that are known to find pages on the www relevant to the topic (possibly different for each search engine) • a list of www pages relevant to the topic

  13. Taxonomy Mapping For Interoperability • Communities build and maintain their own terminologies and KCSs, using them in any way they wish for their own community purposes • When community members want their semantic information to interoperate with other domain knowledge, where logical inference is needed, they can use the mappings to the Common Semantic Model

  14. Taxonomy Mapping for Natural Language Understanding • Language understanding requires recognition of the context in which linguistic statements are made • Maintaining a large public set of documents or document fragments illustrating particular topics can help natural language programs to recognize known textual contexts

  15. The Long-Term Goal Semantic Interoperability: The ability of computers to accurately communicate conceptual information; to correctly interpret the meanings of communicated information and make appropriate decisions By adopting or building a common conceptual language for computers, which can be used to specify and relate the meanings of terms in any community terminology.

  16. What A Common Semantic Model Is A means to allow computers to accurately communicate conceptual information – in effect, a common language for computers – Fo use when the users want to communicate

  17. What A Common Semantic Model Isn’t • A controlled vocabularyEach community can choose its own words to refer to concepts • A mandated standardUsers can use any common ontology or none, as their own needs dictate

  18. Communities and Controlled Vocabularies • Whenever a community of interest or community of practice is sufficiently homogeneous to agree on a controlled vocabulary, that vocabulary can serve as a linguistic signature of a particular context, which will be helpful in machine interpretation of text documents. • i.e., multiple controlled vocabularies are good things. The Common Semantic Model can specify the relations between terms in community vocabularies.

  19. Concepts vs. Words • Mathematical • Theory •  • / | \ •    • / \ \ / •    • | \ / \ •    • | \ \ / •   • | \ / •   • Axioms: • (Every Cat has (( 4) Legs)) • (Every House has ((atLeast 1) Door)) Ontological Theory Terminology “House” “Residential House” “Haus” “maison” “дом” Cat House シャム猫 Siamese “Siamese” “Siamese feline” “Siamese Cat” “chat siamois” “Siamesische Katze”

  20. Categorical Ambiguity can be represented as a union of categories • Metaphor • Poetry • Double entendre • Rhetoric • “Jack went fishing last weekend and caught three trout and a cold.” • Intentionally Ambiguous Word UseNot at issue in formal classification

  21. Who Needs a Common Semantic Model? • Any computer system that needs to accurately communicate conceptual information needs a language in common with the receiving system "Money is being spent on labs and hiring smart people who make products do unnatural acts together.” Alan Shockley, manager of Enterprise Information Technology at EDS Estimated costs of lack of data interoperability nationwide is over 100B/yr

  22. Will Any Upper Ontology Serve? Lenat’s Dictum (Building Large Knowledge-Based Systems, 1990, p. 20): • Do the top layers of the global ontology correctly • Relate all the rest of human knowledge to those top layers

  23. OpenCyc SUMO DOLCE Omega (SENSUS) OCHRE BFO WordNet (?) MSO ISO 15926 Will Any Upper Ontology Serve?Publicly Available Upper Ontologies: Comparison of Upper Ontologies: http://www.mitre.org/work/tech_papers/tech_papers_04/04_0603/04_1175.pdf European Initiative: WonderWeb New American Initiative: NCOR DTO project: IKRIS

  24. A Merged Upper Ontology –One Possible Method • Merge the compatible elements of the Cyc, Omega, SUMO, MidLevel, DOLCE, BFO, and ISO 15926, and add Other concepts as desired by participants, and map this to Wordnet: • => COSMO • COmmon Semantic MOdel • or Cyc, Omega, Sumo, Midlevel, Other

  25. COSMOThe Common Semantic Model • We need an inventory of logically defined higher-level concepts adequate to specify the meanings of the terms and concepts in all domain Knowledge Classification Systems used by participants. • Structured as a set of precisely interrelated ontologies without duplicated concepts and with a set of logically consistent default core concepts

  26. How Many Defining Concepts? Clues: • LDOCE uses a controlled defining vocabulary of ~ 2000 words, to define over 65,000 words • Japanese students learn ~1850 kanji • AMESLAN dictionary has ~5000 signs

  27. When Do We Need a New Primitive Defining Concept? • If any of the content words in the natural-language definition have no corresponding concepts in the existing COSMO • If it is necessary to use a “disjoint” relation to distinguish a new concept from others in the ontology

  28. Requirements • Tools to make the COSMO easy to understand and easy to use • Tools to view and extract only those concepts of interest for a particular application • Pilot and Demonstration applications that illustrate the benefits of using the COSMO

  29. TOOLS • KCS Building and Maintenance Tools • Protege http://protege.stanford.edu/ • UML http://www.uml.org/ • Concept Maps http://cmap.ihmc.us/ • Representation Formalisms • KIF/SKIF/ESKIF/CL/IKL/Conceptual Graphs • OWL • OWL extensions (SWRL, RuleML, OWL-Flight, ?)

  30. CONTROLLED ENGLISH • ClearTalk (Skuce, 1996) http://www.csi.uottawa.ca/~kavanagh/Ikarus/Cleartalk.html • Effective NL Paraphrasing of Ontologies on the Semantic Web http://www.mindswap.org/papers/nlpowl.pdf • Sowa’s “Common Logic Controlled English” http://www.jfsowa.com/clce/specs.htm • ESKIF (developmental)

  31. Example of Problem without a COSMOClass: Wine <owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#locatedIn"/> <owl:someValuesFrom rdf:resource="&vin;Region"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:label xml:lang="en">wine</rdfs:label> </owl:Class>

  32. ObjectProperty: locatedInFrom wine.rdfhttp://www.w3.org/2001/sw/WebOnt/guide-src/wine.rdf <owl:ObjectProperty rdf:ID="locatedIn"> <rdf:type rdf:resource="&owl;TransitiveProperty" /> <rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" /> <rdfs:range rdf:resource="#Region" /> </owl:ObjectProperty> <Region rdf:ID="MedocRegion"> <locatedIn rdf:resource="#BordeauxRegion" /> </Region> <Region rdf:ID="BordeauxRegion"> <locatedIn rdf:resource="#FrenchRegion" /> </Region>

  33. Medoc (Wine) • <owl:Class rdf:ID="Medoc"> • <rdfs:subClassOf> • <owl:Restriction> • <owl:onProperty rdf:resource="#hasColor" /> • <owl:hasValue rdf:resource="#Red" /> • </owl:Restriction> • </rdfs:subClassOf> • <rdfs:subClassOf> • <owl:Restriction> • <owl:onProperty rdf:resource="#hasSugar" /> • <owl:hasValue rdf:resource="#Dry" /> • </owl:Restriction> • </rdfs:subClassOf> • <owl:intersectionOf rdf:parseType="Collection"> • <owl:Class rdf:about="#Bordeaux" /> • <owl:Restriction> • <owl:onProperty rdf:resource="#locatedIn" /> • <owl:hasValue rdf:resource="#MedocRegion" /> • </owl:Restriction> • </owl:intersectionOf> • </owl:Class>

  34. <owl:Class rdf:ID="Medoc"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Bordeaux" /> <owl:Restriction> <owl:onProperty rdf:resource="#locatedIn" /> <owl:hasValue rdf:resource="#MedocRegion" /> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasColor" /> <owl:hasValue rdf:resource="#Red" /> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasSugar" /> <owl:hasValue rdf:resource="#Dry" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> Fig. 1. OWL Class ‘Medoc’ in the Wine Ontology Serialized in RDF/XML ‘Medoc is a sweet, red color wine located in the Medoc region.’

  35. ESKIF Version • {{Medoc isaTypeOf Wine} and (Every Medoc is {Dry and RedColored and (ProducedIn (the MedocRegion))})} SKIF: • (isaSubclassOf Medoc Wine) • (necessarily Medoc hasAttribute Dry) • (necessarily Medoc hasAttribute RedColored) • (necessarily Medoc hasAttribute (ProducedIn MedocRegion)

  36. ESKIF • Like SKIF, but statements in braces have first two arguments inverted • {ColonelMustard killed MissScarlet} ≡ (killed ColonelMustard MissScarlet) {{ColonelMustard killed MissScarlet}, (in (the Conservatory)) (with (A Knife))} {(The Person named “Albert Einstein”) proposed (The Theory called “The Theory of Relativity”)}

  37. Basic Components of An Ontology Hierarchy of Types Semantic Relations (slots/associations) Instances Functions Axioms Constraints Procedural Methods

  38. Handling Different Perspectives • It is widely recognized that different communities are interested in different aspects of the same entities • These can be represented in a logically consistent manner by allowing dynamic creation of classes with only some of the known attributes and relations of the physically realistic class • This corresponds to the use of anonymous classes in an OWL restriction • Many different contexts may need to be distinguished

  39. Different Interests How big is the diamond? How much does it cost?

  40. Flexible View Creation Entity SelectiveView DetailedEntity isaSubViewOf PricedObject DiamondRing

  41. Knowledge: Search and Deploy Community Goals Action enables Retrieved Knowledge dictate • Comprehensive • Formalized • Knowledge •  • / | \ •    • / \ \ / •    • | \ / \ •    • | \ \ /    • | \ / •   •   •  •    •     Document Collection provides provides Automated Reasoning Community Knowledge Needs Keyword Search Graphic Search Browsing Search Human Friendly Machine Friendly Community Graphical View TS Community Taxonomy or Thesaurus

  42. Registries for KOSs • A registry will provide information to allow the public to determine whether a KOS is suitable for their purposes – metadata about the KOS. • A registry that can describe the relations between KOS systems (dependency, similarity) requires special types of metadata.

  43. Special KOS registry requirement • In order to be reusable outside the originating community, a KOS should have information specifying whether the meanings of its terms depend on any other KOS, or are related to terms in any other KOS. • In the event that an upper ontology is used to specify meanings in a KOS, that needs to be explicitly represented. • If an ontology is intended to be independent and self-describing, that needs to be specified.

  44. For the Skeptical Help the process: It will be useful to have a set of use cases or scenarios that would provide a practical challenge for the developers of integrating technologies such as the Common Semantic Model. What would satisfy the variable ?this: “If you can do ?this, I will be convinced that a Common Semantic Model is valuable.”

  45. ONTACWG

  46. SWSL Logic Inventory

More Related