Avoiding Hobson's Choice In Choosing An Ontology :1 Avoiding Hobson's Choice In Choosing An Ontology Ontolog Presentation 27 April, 2006 Jack Park – jack.park@sri.com Patrick Durusau – patrick@durusau.net © 2006, Jack Park and Patrick Durusau License: http://creativecommons.org/licenses/by/2.5/legalcode


Abstract:2 Abstract Most users of ontologies have either participated in the development of the ontology they use and/or have used it for such a period of time that they have taken ownership of it. Like a hand that grows to fit a tool, users grow comfortable with "their" ontology and can use another only with difficulty and possibly high error rates. When agencies discuss sharing information, the tendency is to offer other participants a "Hobson's Choice" of ontologies. "Of course we will use ontology X." which just happens to be the ontology of the speaker. Others make similar offers. Much discussion follows. But not very often effective integration of information. In all fairness to the imagined participants in such a discussion, unfamiliar ontologies can lead to errors and/or misunderstandings that may actually impede the interchange, pardon, the accurate interchange information. Super-ontologies don't help much when they lack the granularity needed for real tasks and simply put off the day of reckoning when actual data has to move between agencies.


Slide 3:3 The Topic Maps Reference Model is a paradigm for constructing a mapping of ontologies that enables users to use "their" ontologies while integrating information that may have originated in ontologies that are completely foreign or even unknown to the user. Such mappings can support full auditing of the process of integrating information to enable users to develop a high degree of confidence in the mapping. Topic maps rely upon the fact that every part of an ontology is in fact representing a subject. And the subject that is being represented is known from the properties of those representatives. Such representatives are called subject proxies in the Topic Maps Reference Model. Those properties are used as the basis for determining when two or more subject proxies represent the same subject. Information from two or more representatives of the same subject can be merged together, providing users with information about a subject that may not have been known in their ontology. Park and Durusau explore the philosophical, theoretical and practical steps needed to avoid a Hobson's Choice in ontology discussions and to use the Topic Maps Reference Model to effectively integrate information with a high degree of confidence in the results. All while enabling users to use the ontology that is most familiar and comfortable for them.


Outline:4 Outline Hobson’s Choice Choosing an Ontology Federation Subject Maps Federating Ontologies with Subject Maps Observations Conclusion


Hobson’s Choice:5 Hobson’s Choice Cambridge, England 16th-17th Century Renting horses to students, who requested the same horses Some horses being overworked Hobson’s Choice: Take the horse closest to the door, or take none at all Appearance of free choice where none exists at all


Who uses ontologies?:6 Who uses ontologies? Fact: Most knowledge/information users rely on ontologies of one sort or another Including libraries, research institutes, financial institutes, schools, governments, and more Premise: All meaningful information is recorded with respect to some ontology That is, all information is thought to mean something when recorded


Where do ontologies come from?:7 Where do ontologies come from? Handed out at graduation? No. Wedding present? No With Drivers License? No With Voter Registration? No Hmmm, where do ontologies come from?


Where Ontologies Come From:8 Where Ontologies Come From People use concepts that represent their world view Those concepts have relationships to other concepts Those concepts and relationships are associated with the real world Actions are taken and reasoning based upon those concepts Bottom line is that we are the source of ontologies


Hobson’s Choice and Ontologies:9 Hobson’s Choice and Ontologies To “ontologize” Ontolog an ontology is required Which ontology? “Well, the one closest to my door of course!” Problem: We all have different doors next to which stand our ontologies. Solution: “The choice is obvious, we will use (insert your ontology).”


Ontology Levels:10 Ontology Levels Middle Ontology (Domain-spanning Knowledge) Most General Thing Upper Ontology (Generic Common Knowledge) Products/Services Processes Organizations Locations Lower Ontology (individual domains) Metal Parts Art Supplies Lowest Ontology (sub-domains) Washers © Mitre Corporation, Source [1]


Slide 11:11 Ontology Representation Levels Meta-Level to Object-Level Meta-Level to Object-Level Language Ontology (General) Knowledge Base (Particular) © Mitre Corporation, Source [1]


Freedom of Choice?:12 Freedom of Choice? Facts Upper ontologies are diverse Middle ontologies are even more diverse Lower ontologies are more diverse still Premise: Ontological diversity is a given and increases as we approach users. Conclusion: Do we give users a Hobson’s Choice? My way or the highway? Federation anyone?


Federation:13 Federation Requirements Use with any ontology (formal or otherwise) Maintain ontological diversity Merge information from diverse ontologies Maintain audit trails for information Preserve individual world views in merged subjects Create wormholes between ontologies


Federation 2:14 Federation 2 Benefits No Hobson’s choice for architects, designers or users of information systems User interact with system that reflects their world view (greater accuracy, less training) Designers build systems using their world views Architects reach understandings that span particular world views


Federation with Subject Maps:15 Federation with Subject Maps Topic Maps Reference Model (TMRM) Abstract model with no syntax or data model The same subject can have multiple ways to be identified, one by each community. A rose by any other name…is still a rose!


From TMRM to Subject Maps:16 From TMRM to Subject Maps TMRM Legend Subject Map Abstract Concepts Syntax, Disclosures, Ontological Commitments Implementation


Subject Map: Subjects:17 Subject Map: Subjects Subjects: anything that can be discussed in conversation. Subjects are represented by collections of Subject Properties Subject Properties are collected in Subject Proxies Name=“роза” language=“RU”


Subject Map: Subject Proxies:18 Subject Map: Subject Proxies One, and only one proxy exists for any particular subject in a subject map. Proxies serve as binding points for all that is known about a subject Proxies marshal properties: Subject Identity Relationships with other subjects Other properties of the subject


Subject Map: Subject Properties:19 Subject Map: Subject Properties Properties are key/value pairs Property Keys are references to other subjects disclosed* in the map Property values can be References to other proxies Literals * More on disclosure following


Subject Map: Disclosure:20 Subject Map: Disclosure TMRM specifies the requirement for a legend. Legend authors disclose: Merging rules Subject Property types Legends govern the ontological commitments that can made by a proxy author


Subject Map: Merging:21 Subject Map: Merging Merging rules define when two or more proxies represent the same subject If subject maps are merged from different property/merging disclosures (legends), those disclosures continue to govern the properties they define


Subject Maps/RDF: Separated at Birth?:22 Subject Maps/RDF: Separated at Birth? Triples: RDF: subject : predicate : object Subjects, predicates, objects: identified by single URI TMRM: subject : (key : value) (repeatable) Subject identified by any number of key/value pairs. Subjects do not appear in a subject map but are identified in one.


Subject Identity Example 1:23 Subject Identity Example 1 Looking for “Diced Tomatoes” Is the name/URI enough? No, some have added sugar (bad for diabetics) Lesson: Must compare the properties of subjects to determine identity


Example 1 Extended:24 Example 1 Extended Keys of the diced tomatoes Nutrition information: all list sugar Ingredients: some list sugar So which to consider? Nutrition or Ingredients? Keys alone are not enough Must know which subject each key represents


Subject Identity Summary:25 Subject Identity Summary Properties identify subjects Properties = key/value pairs Keys are references to subject proxies Values maybe references to subject proxies Properties represent ontological commitments of the author


Federation with Subject Maps:26 Federation with Subject Maps Concepts in ontologies represent subjects Concepts in ontologies have properties (either literals or relationships to other concepts) Need to disclose the properties that identify the subject to be represented (basis for merging rules)


Two Ontologies—One Subject Map:27 Two Ontologies—One Subject Map


Federation: SUMO “atom”(subclass Atom ElementalSubstance)(documentation Atom "An extremely small unit of matter that retains its identity in Chemical reactions. It consists of an &%AtomicNucleus and &%Electrons surrounding the &%AtomicNucleus.")(=> (instance ?ATOM Atom) (exists (?PROTON ?ELECTRON) (and (component ?PROTON ?ATOM) (component ?ELECTRON ?ATOM) (instance ?PROTON Proton) (instance ?ELECTRON Electron))))(=> (instance ?ATOM Atom) (forall (?NUCLEUS1 ?NUCLEUS2) (=> (and (component ?NUCLEUS1 ?ATOM) (component ?NUCLEUS2 ?ATOM) (instance ?NUCLEUS1 AtomicNucleus) (instance ?NUCLEUS2 AtomicNucleus)) (equal ?NUCLEUS1 ?NUCLEUS2)))):28 Federation: SUMO “atom”(subclass Atom ElementalSubstance)(documentation Atom "An extremely small unit of matter that retains its identity in Chemical reactions. It consists of an &%AtomicNucleus and &%Electrons surrounding the &%AtomicNucleus.")(=> (instance ?ATOM Atom) (exists (?PROTON ?ELECTRON) (and (component ?PROTON ?ATOM) (component ?ELECTRON ?ATOM) (instance ?PROTON Proton) (instance ?ELECTRON Electron))))(=> (instance ?ATOM Atom) (forall (?NUCLEUS1 ?NUCLEUS2) (=> (and (component ?NUCLEUS1 ?ATOM) (component ?NUCLEUS2 ?ATOM) (instance ?NUCLEUS1 AtomicNucleus) (instance ?NUCLEUS2 AtomicNucleus)) (equal ?NUCLEUS1 ?NUCLEUS2))))


Federation: Cyc “atom” #$Atom atoms (inanimate objects) (tangible things) (things with a location) A specialization of #$ChemicalObject. Each instance of #$Atom is a microscopic-scale object with exactly one atomic nucleus (see #$AtomicNucleus) and some number of electrons (see #$Electron). A typical instance of #$Atom has no net charge, i.e., it has as many instances of #$Electron as it does of #$Proton. For the collection of atoms that do have non-zero charges, see #$AtomicIon. guid: bd5891ef-9c29-11b1-9dad-c379636f7270direct instance of: #$ExistingObjectTypedirect specialization of: #$ChemicalObject :29 Federation: Cyc “atom” #$Atom atoms (inanimate objects) (tangible things) (things with a location) A specialization of #$ChemicalObject. Each instance of #$Atom is a microscopic-scale object with exactly one atomic nucleus (see #$AtomicNucleus) and some number of electrons (see #$Electron). A typical instance of #$Atom has no net charge, i.e., it has as many instances of #$Electron as it does of #$Proton. For the collection of atoms that do have non-zero charges, see #$AtomicIon. guid: bd5891ef-9c29-11b1-9dad-c379636f7270direct instance of: #$ExistingObjectTypedirect specialization of: #$ChemicalObject


Atom: Sumo proxy:30 Atom: Sumo proxy Properties Electron => 1 or more Proton => 1 or more Nucleus => 1 Subclass => Elemental Substance Documentation => “An extremely small …” SUMO => Logic and syntax


Atom: Cyc Proxy:31 Atom: Cyc Proxy Properties SpecializationOf => ChemicalObject instanceOf => ExistingObjectType AtomicNucleus => 1 Charge => none Text => “A specialization of …” Cyc => Logic and syntax


SUMO + Cyc Proxy?:32 SUMO + Cyc Proxy? How to merge? Different keys, values, etc. sameAs anyone? Works but: On what basis was merging done? Still concealed in the mind of the author. Must be replicated for every ontology, every time one is added. Merging with auditing: add properties


SUMO + Cyc with Auditing:33 SUMO + Cyc with Auditing Properties Electron => 1 or more Proton => 1 or more Nucleus => 1 Class => atom SpecializationOf => ChemicalObject instanceOf => ExistingObjectType AtomicNucleus => 1 Class=> atom


SUMO + Cyc with Auditing:34 SUMO + Cyc with Auditing The class => atom property was added to both proxies, with a merging rule that triggered merging. Not only have the two proxies merged (not all properties are shown) but the reason why they merged is known. BTW, the colored properties for each proxy were the subject identity properties


SUMO + Cyc Wormholes:35 SUMO + Cyc Wormholes Merged proxy has (among others) Electron => 1 or more SpecializationOf => ChemicalObject Both the keys and properties are references to other concepts in their respective ontologies This single location acts as a portal between the two ontologies, a wormhole


Two Ontologies—One Subject Map:36 ExistingObjectType instanceOf electron nucleus proton Two Ontologies—One Subject Map atom SUMO specializationOf ChemicalObject atom Cyc


Two Ontologies—One Subject Map:37 ExistingObjectType instanceOf electron nucleus proton Two Ontologies—One Subject Map atom SUMO specializationOf ChemicalObject atom Cyc


Food Aid Example:38 Food Aid Example Delivery of food aid How many trucks capable of carrying 2,000 pounds of aid? Problem: From different ontologies, different property types (different names) that actually represent the same property: Load capacity vs. Rated weight Solution: Disclose merge rules that cause those property types to merge as representing the same subject. Result: Query for trucks returns the correct number, with use of either term.


Intelligence Example:39 Intelligence Example Federating the workproduct of two analysts Analyst # 1 Analyst # 2 Disclosures allow a map to recognize: VoteToHaltPayments same subject as DecideToStopPayments Hamas serves as a proxy for Palestine in this context Both work products merge


Intelligence Example Extended:40 Intelligence Example Extended How does merging happen? Combination of Automated merging Merge rules as disclosed in legends Human suggestions Human dialog Part of federation facilities Reach Agreements Manual intervention/override of merge process


Observations:41 Observations Preserves all information from merged ontologies Provides a wormhole/portal between ontologies Provides explicit definition of subject sameness Supports auditable merging of information from different ontologies


Observations 2:42 Observations 2 Business systems (accounting/inventory) have differing ontologies If disclose what subjects are being identified, can map directly into such systems Auditors become able to peer down into otherwise incompatible or inconsistent information systems


Observations 3:43 Observations 3 Not required to be top down ontolgoies (expensive/time consuming) Empowers users to make their own ontologies Enables users to use their ontologies, not foreign or unfamiliar ones Mapping possible between ontologies with incompatible or inconsistent assumptions


Subject Map Coda:44 Subject Map Coda Subject maps have no required syntax or structure (read use existing information systems in place) Subject maps leverage on existing ontologies and expertise Subject maps enable wormholes between ontologies Subject maps depend upon existing expertise in ontological work


Conclusion:45 Conclusion Do subject maps replace ontologies? No Can subject maps federate ontologies? Yes Do subject maps empower users? Yes Do subject maps empower ontologists? Yes


Postscript:46 Postscript Remember the properties of subjects? Exist before data has been “ontologized” Can view data as per your ontology or your data as it would appear in another ontology Subject maps enable ontological reasoning even in the absence of data being formally “ontologized.”


References:47 References [1] Obrst, Leo, Ontolog Invited Speaker, 2006-01-19, OntologySpectrumSemanticModels--LeoObrst_20060112.ppt http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2006_01_12