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.
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.
4 Outline Hobsons Choice Choosing an Ontology Federation Subject Maps Federating Ontologies with Subject Maps Observations Conclusion
5 Hobsons Choice Cambridge, England 16 th -17 th Century Renting horses to students, who requested the same horses Some horses being overworked Hobsons Choice: Take the horse closest to the door, or take none at all Appearance of free choice where none exists at all
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
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?
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 weBottom line is that we are the source of ontologies
9 Hobsons 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).
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 Hobsons Choice? My way or the highway? Federation anyone?
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
14 Federation 2 Benefits –No Hobsons 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
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!
16 From TMRM to Subject Maps TMRM Legend Subject Map Abstract Concepts Syntax, Disclosures, Ontological Commitments Implementation
17 Subject Map: Subjects SubjectsSubjects: –anything that can be discussed in conversation. Subject PropertiesSubjects are represented by collections of Subject Properties Subject ProxiesSubject Properties are collected in Subject Proxies Subject Proxy Locator=rose Name=rose language=EN language=FR language=DE subOf=#flower Name=роза language=RU
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
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
20 Subject Map: Disclosure legendTMRM specifies the requirement for a legend. discloseLegend authors disclose: rules –Merging rules types –Subject Property types Legends govern the ontological commitments that can made by a proxy author
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
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.
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
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
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
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)
27 A C+N B C D N P M A B D P M Two OntologiesOne Subject Map
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))))
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-c379636f7270 direct instance of: #$ExistingObjectType direct specialization of: #$ChemicalObject
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
31 Atom: Cyc Proxy Properties –SpecializationOf => ChemicalObject –instanceOf => ExistingObjectType –AtomicNucleus => 1 –Charge => none –Text => A specialization of … –Cyc => Logic and syntax
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
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
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
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
36 SM ExistingObjectType instanceOf electron nucleus proton Two OntologiesOne Subject Map SUMO Class => atom Electron => 1 or more Proton => 1 or more Nucleus => 1 Cyc Class => atom SpecializationOf => ChemicalObject instanceOf => ExistingObjectType AtomicNucleus => 1 atom SUMO specializationOf ChemicalObject atom Cyc
37 SM ExistingObjectType instanceOf electron nucleus proton Two OntologiesOne Subject Map Merged Proxy Class => atom SpecializationOf => ChemicalObject instanceOf => ExistingObjectType AtomicNucleus => 1 Electron => 1 or more Proton => 1 or more Nucleus => 1 atom SUMO specializationOf ChemicalObject atom Cyc
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.
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
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
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
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
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
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
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
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.