1

Avoiding Hobson's Choice In Avoiding Hobson's Choice In Choosing An OntologyChoosing An Ontology

Ontolog Presentation27 April, 2006

Jack Park – jack.park@sri.comPatrick Durusau – patrick@durusau.net

© 2006, Jack Park and Patrick DurusauLicense: http://creativecommons.org/licenses/by/2.5/legalcode

2

AbstractMost 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

• Hobson’s Choice

• Choosing an Ontology

• Federation

• Subject Maps

• Federating Ontologies with Subject Maps

• Observations

• Conclusion

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

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

• Bottom line is that wewe are the source of 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).”

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 PartsArt Supplies

Lowest Ontology(sub-domains)

Washers

© Mitre Corporation, Source [1]

11

Ontology Representation LevelsLevel Example Constructs Knowledge Representation (KR) Language (Ontology Language) Level:

Meta Level to the Ontology Concept Level

Class, Relation, Instance, Function, Attribute, Property, Constraint, Axiom, Rule

Ontology Concept (OC) Level:

Object Level to the KR Language Level, Meta Level to the Instance Level

Person, Location, Event, Parent, Hammer, River, FinancialTransaction, BuyingAHouse, Automobile, TravelPlanning, etc.

Ontology Instance (OI) Level:

Object Level to the Ontology Concept Level

Harry X. Landsford III, Ralph Waldo Emerson, Person560234, PurchaseOrderTransactionEvent6117090, 1995-96 V-6 Ford Taurus 244/4.0 Aerostar Automatic with Block Casting # 95TM-AB and Head Casting 95TM

Meta-Level to Object-Level

Meta-Level to Object-Level

Language

Ontology (General)

Knowledge Base

(Particular)

© Mitre Corporation, Source [1]

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?

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 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

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

TMRMTMRM

LegendLegend

Subject MapSubject Map

Abstract Concepts

Syntax, Disclosures, Ontological Commitments

Implementation

17

Subject Map: Subjects• SubjectsSubjects:

– anything that can be discussed in conversation.

• Subjects are represented by collections of Subject Subject PropertiesProperties

• Subject Properties are collected in Subject ProxiesSubject 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 IdentitySubject 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

• TMRM specifies the requirement for a legendlegend.

• Legend authors disclosedisclose:– Merging rulesrules– Subject Property typestypes

• 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

DN

P

M

A

BD

P

M

Two Ontologies—One 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-c379636f7270direct 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 Ontologies—One Subject Map

SUMOClass => atom

Electron => 1 or moreProton => 1 or moreNucleus => 1

CycClass => atom

SpecializationOf => ChemicalObjectinstanceOf => ExistingObjectTypeAtomicNucleus => 1

atom

SUMO

specializationOf

ChemicalObject

atom

Cyc

37

SM

ExistingObjectType

instanceOf

electron

nucleus

proton

Two Ontologies—One Subject Map

Merged ProxyClass => atom

SpecializationOf => ChemicalObjectinstanceOf => ExistingObjectTypeAtomicNucleus => 1

Electron => 1 or moreProton => 1 or moreNucleus => 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

• <Israel> <VoteToHaltPayments><Hamas>

– Analyst # 2• <Israel><DecideToStopPayments><Palestine>

• 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.”

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