Dave McComb Semantic Arts Semantic Technology Conference June 1x, 2009

Basing your ontology on an upper ontology can increase your productivity and the quality of the resulting ontology Basing your ontology on an upper ontology will make interoperation with others using that upper ontology much easier Not all upper ontologies are alike

Modular and layered ontologies: how and why Facets: breadth, depth, understandability Understanding gist Experience report Whats next

Ontologies can get Large, and Complex This has three downsides Inference slows down There is more for the humans to understand There may be stuff in there you dont agree with

When you import an ontology its not like a library of subroutines where you only use what you want You get it all, and all the implications Hence the term committing to an ontology

A commits to B does not imply that B commits (or even knows about) A AB

Two ontologies that commit to a third common ontology have some basis for exchanging information Its limited to the scope of their use of the shared ontology But at least its something

The smaller your shared ontology + number of things based on the shared ontology, the more scope for sharing

What would you want in an upper ontology? Our contention is that you would 1) want it to cover most of the concepts you have in your domain 2) with minimal ambiguity or overlap 3) easy to understand

foaf dublin core skos Cyc sumo

Concepts typically expressed in a business system foaf Mostly people and their relationships

Concepts typically expressed in a business system dc Documents, authors, publishers, rights

Concepts typically expressed in a business system skos essentially a thesauruss

Concepts typically expressed in a business system cyc hundreds of thousands of common sense terms axiomized

Concepts typically expressed in a business system sumo tens of thousands of terms tied to word net and axiomized

Ease of understanding Breadth foaf dc skos cyc sumo xbrl ebXML gist

gist has xx properties xx primitive classes xx partially defined classes xx fully defined classes

Person (human being, living or dead) Substance (occupies space and has mass) Location (geospatial) Time (specific dates and times in the past and future and intervals of time)

Organization Units of measure, including currency Ownership and rights Documents and content Recorded events, including transactions Agreements, contracts, obligations and offers

Superior/Subordinate (Whole/part, contains/contained) Reference (about, regarding) Datatype attributes (name, amount, date, time, text) Features (non simple attributes) (start/end dates, ids,

TimePlacePersonThingStuffDocBehaviorAgreeGoalCategory

Now

HereHomeMe

Time Instant (i.e. Sept 11, 2001) Time Interval (i.e. 12/25/ /1/2009) Duration (one week) Duration unit of measure (week, month, second ) etc Unit of Measure Measurement (the act of taking the measure) Measurement Type (ie Measured, Estimated, Predicted or Reference) second

Almost all of business is about the management of commitments or obligations (quotes, purchase orders, price lists, invoices, even checks are obligations) Obligation is the key concept: There are two parties (if you only have one party and rules about who can be the second party you have an offer) There is the substance of the obligation (to do, or refrain from doing something, including pay or provide service) Substance is described in term(s) One party is the giver and one the getter of this obligation

An agreement (i.e. a contract) is a bundle of obligations between two or more parties (givers and getters) The simplest agreement has two obligations: an obligation for giver (A) to provide a product or service to getter (B) and an obligation for giver (B) to pay getter (A) Note that this says nothing about the timing (pay first, pay later etc)

Highly axiomized Units of Measure defined by their standard unit Logically fewest datatype properties Heavy use of subproperties

Qualified Cardinality (more for sub ontologies) Disjoint properties Property chains

Borrow simons slide

giver and getter

Ownership and Location

Two major Enterprise Ontologies based on gist Washington State Employment Security Division A large (modest) loan company Using gist greatly sped up the ontology capture process Most concepts had either an identical or more general class in gist, which avoided a lot of negotiation Very high coverage of both properties and classes Most of the concepts in the EOs were decedents of gist concepts

current version archived versions documentation (including this presentation)

For you: Download gist, and the documentation Learn it Experiment with it Base your next ontology on it Let us know your experience (good and bad) For us: Mapping to other high level and medium level ontologies Continued refinement

Basing your ontology on an upper ontology can increase your productivity and the quality of the resulting ontology Basing your ontology on an upper ontology will make interoperation with others using that upper ontology much easier Not all upper ontologies are alike