whitepaper - iaoa...gist consists of two parts. the first, a core module, is the main subject of...

11 Old Town Square Suite 200 / Fort Collins, CO 80524 / (970) 490-2224 / www.semanticarts.com

whitepaper

INTRODUCTION TO GIST

BUILDING AN ENTERPRISE ONTOLOGY WITH GIST, A MINIMALIST UPPER ONTOLOGY FOR BUSINESS

MICHAEL USCHOLD & DAVE MCCOMB

JANUARY 2013 Copyright © 2013 Semantic Arts, Inc. All Rights Reserved.


2

INTRODUCTION

gist1 is a minimalist upper ontology aimed at a business audience. It is intended to act as a

starting point for any organization or individual that wishes to build an ontology for their

business. The ontology might be enterprise-wide or for a major sub-area within a large

enterprise.

gist consists of two parts. The first, a core module, is the main subject of this whitepaper. It

covers concepts common to most enterprises and is relatively mature. The second part is a set of

several much smaller subgists, which go into more detail on specific topics, for example,

organization, measure, temporal, event, finance. They are generally not as mature, and might

represent a "point of view" that might not be accepted by the population at large. At this time,

these are available only to our clients and by special arrangement. Contact us if you are

interested.

BENEFITS OF AN UPPER ONTOLOGY

The main benefits of using an upper ontology to build your enterprise ontology include:

1. you can save time by reusing the hard work that went into identifying and organizing

important concepts that you are likely to need;

2. it can enforce a discipline that improves the quality of the ontology resulting in less

ambiguity and fewer errors;

3. if you base a number of applications on the same upper ontology, then they will more

easily inter-operate due to the common semantic foundation.

BENEFITS OF GIST

The benefits of using gist, compared to some other upper ontologies, include:

1. its roots are in business, not academia;

2. it strikes a business-friendly balance between being rigorous enough to significantly

reduce ambiguity, and simple enough to be understandable;

3. it is carefully scoped and comparatively small,

gist aims to cover most of what you need, and little of what you don’t;

4. its size and structure make it relatively easy to learn;

5. in the future, gist will be mapped to other upper ontologies, so you can leverage them

where appropriate.

Using Gist:

1 Copyright Semantic Arts, Inc. Rights to use are conveyed under the Creative Commons Attribution-ShareAlike 3.0 license. The

current version is at: http://ontologies.semanticarts.com/gist/gist.owl.

http://creativecommons.org/licenses/by-sa/3.0/legalcode



http://ontologies.semanticarts.com/gist/gist.owl


3

Whatever the context, the nuts and bolts of using gist to build your enterprise ontology consists

of two main tasks:

1. Map: given a concept in your business that you need to model, find the corresponding concept in gist that your concept most closely relates to and determine the relationship

between your concept and the gist concept you found.

2. Extend: extend one or more gist concepts to be specific enough to capture the concepts

you need.

In this whitepaper, we describe the background and motivation for gist and the design principles

that make it easy to do the above tasks and achieve the above benefits. We give an overview of

what gist consists of and summarize how it can be used. This is the first in a series of

whitepapers on gist in particular and upper ontologies in general. Later whitepapers will cover:

1. Technical details of how to use gist;

2. Cases studies with specific examples showing how gist adds value;

3. How gist compares to other widely known upper ontologies.

BACKGROUND AND MOTIVATION

WHY ENTERPRISE ONTOLOGY?

gist is designed to assist in the process of creating an enterprise ontology, but why would you

want one in the first place? One very important reason is to lay a foundation to for improving

interoperability and integration among the IT systems in your business. Data and application

heterogeneity is a big problem for most organizations. Ontologies are an important way to

address this. This was highlighted by John Bottega, Chief Data Officer, Bank of America at the

March 12, 2012 Demystifying Financial Services Semantics Conference2. He emphasized the

challenges that arise from the many adapters and transformations that are required in the finance

industry due to the heterogeneity of data and applications. The problem is particularly acute in

companies that grew by acquisition. Two main problems arise:

1. Data quality suffers: each transformation results in some loss of data fidelity, and

multiple transformations cause serious degradation.

2. The cost of creating and maintaining so many adapters is extremely high – not only the

direct cost, but also the opportunity cost of things that are not done because they take too

long or cost too much.

The problem is the lack of shared meaning in the organization. Having an ontology for your

organization is an important part of a solution to this problem. Indeed, the whole point of an

ontology is to have shared meaning, in a computer-processable format. gist is a way to build your

enterprise ontology faster, and to get a better result.

2 http://www.omg.org/news/meetings/FS-CONF/index.htm

http://www.omg.org/news/meetings/FS-CONF/index.htm


4

Figure 1: Enterprise Ontology: A Semantic Foundation for your Organization The key to longevity and flexibility in a building is called “pace layering” in Stewart Brand’s book How Buildings Learn. The

site of a building will almost never change. The idea is that each layer can change independently from the layer below. Here

we draw an analogy with IT in Enterprises.

Laying a foundation for interoperability and integration works in two stages. In the short term,

you can use the enterprise ontology as a lingua franca among all the different systems. This will

eliminate the need to write an exponential number of adapters between all pairs of data sources

or applications. With an ontology as a repository of clearly defined terms, adding a new system

means the number of adapters just grows linearly. If you add one more system to the mix, you

don’t have to write an adapter between it and every other system; you just write one between it

and the ontology. Basing your SOA messages on an upper ontology can have an even more

profound effect.

In the medium and longer term, you can build all data stores and applications based on the shared

ontology. This way, they interoperate from the start by virtue of their shared semantic heritage.

After the initial cost of creating the ontology and building a culture of using it on a regular basis,

you start to get a lot of interoperability and integration for free.

In summary, an enterprise ontology is a good way to address the interoperability/integration

problem, and using gist is a good way to build an enterprise ontology.

Naming and font conventions: We use the currier fixed width font to represent formal ontology

concepts. We use the naming convention that classes names are capitalized (e.g.,

gist:Person) and property names are lower camelcase, and are often followed by the inverse

property in parentheses – e.g., gist:hasPart(partOf). Most ontology concepts will be

from gist, so we will only use the gist namespace prefix for emphasis, or to distinguish it from

Site

Systems

Skin

Structure

Stuff

Space

Enterprise Ontology

Enterprise Arch

Formal Taxonomy

Capability

Navigation & Search

Aesthetics


5

other ontologies. For example, myeo:Country might be used to refer to a class in a new

ontology based on gist (myeo denotes “my enterprise ontology”).

ORIGINS AND BENEFITS OF GIST

gist grew out of several projects that included building enterprise ontologies for government

organizations and large companies in a variety of industries that include labor, transportation,

manufacturing, finance, legal research and health. Our clients include three departments in the

State of Washington: Employment Security, Transportation, and Labor & Industries. Commercial

clients include Procter and Gamble, Sallie Mae, LexisNexis and Sentara. The concepts that

turned up over and over became the foundation of gist. We built our own upper ontology rather

than start with an existing one because each of the then-current offerings fell short of our needs.

The ontologies were too large, complicated or hard to understand; in addition some of the key

things needed for business were either missing or too hard to find.

By contrast, gist has evolved with an aim to include a relatively small number of concepts. A

concept is right for gist if the majority of business enterprises are likely to encounter it in their

applications. If a concept is relevant to only a minority of business enterprises, we aim to have an

upper level concept that it can be based on, but do not include it directly. In the gray area in

between, we are developing a number of subgists which elaborate on recurring themes that apply

to a significant number of enterprises.

The main benefits of gist are:

1. It helps build your ontology faster

2. It helps you build a better ontology

Our minimalist philosophy is key to achieving these goals. We aim to cover the majority of

business concepts with the smallest number of gist concepts, clearly defined and non-

overlapping (see Figure 2).

Studying and using gist can also help you learn OWL because of the rich set of exemplars and

interesting ontology patterns deployed.

BUILD YOUR ONTOLOGY FASTER

We don’t want you to reinvent the wheel. While many of the things you require are specific to

your organization, most of them are rooted in more general concepts that apply to any business.

There is no point in starting from scratch to represent things that we have already done for you.

gist encapsulates our thinking and experience in building enterprise ontologies much like the one

you might wish to build. You can avoid common pitfalls and learn from our prior mistakes.

Once you get familiar with gist, when you are adding a new concept to your ontology, you can

see what is similar in gist, and either reuse it or build off of it. For example, you probably don’t

need a separate class for representing people; you can just use gist:Person. If you are a

healthcare company, or a legal firm interested in patients and lawyers, you could quickly notice

that all lawyers and patients are people. Thus, it could make sense to model lawyers and patients


6

as subclasses of Person. If you are modeling contracts, you would quickly realize that a

contract is not a place or a person. Scanning the other major categories, you might notice

gist:Agreement, which is a good place to start looking. You don’t have to start from scratch

Figure 2: Providing Benefits from gist

This figure shows how gist helps building better ontologies faster.

and think about how to model agreements; we have done that for you. An agreement involves at

least two parties, and each party has an obligation to the other. You start by deciding what is

unique about the agreements you need, and build the ontology accordingly.

Note that if you can build your ontology faster, that means you can get more done in the same

amount of time, which can leave more time to do a better job. This leads to the next goal.

BUILD A BETTER ONTOLOGY

In addition to helping you get going and move more quickly at the outset, using gist should also

result in a better ontology. This has three aspects:

1. Improved clarity

2. Improved accuracy

3. Reduced complexity


7

Improved clarity happens in various ways. First, when you create a subclass or subproperty of a

gist concept, the meaning of your concept will be more evident because it inherits the meaning of

the super-concept that exists in both the text definition and in the axioms. These are things that

you might not have thought to include; having them helps to reduce ambiguity by decreasing the

likelihood of unintended interpretations.

Second, the discipline of deciding which gist concept your concept is most related to forces you

to ask more questions about your concept than you might have otherwise considered. This teases

out nuances of meaning that further improve clarity. For example, suppose you need to model the

concept of a country. Classes in gist that may be relevant include GeoRegion,

CountryGovernment, Organization and GovernmentOrganization. Relevant

properties include: governs and recognizedBy. If your main concern is climate, then you

might be thinking of country as a GeoRegion. If your main concern is international politics,

you might be thinking of country as a special kind of Organization (e.g., that is

governedBy a CountryGovernment). If your concern bridges climate and politics, then

you might wish to model country as an Organization that is somehow linked to a

GeoRegion. The property, hasJurisdiction can be used to model that link. Either way,

being forced to think about where your concepts fit into gist forces you to think more clearly

about what you mean; this further reduces ambiguity.

Finally, improved clarity can result from reduced complexity (this is explained further below).

Improved accuracy arises in two ways. First, the improved clarity resulting from the discipline of

using gist gives rise to fewer errors. Second, by connecting your ontology to gist, an inference

engine can help find many kinds of errors ranging from simple typos to very subtle

inconsistencies that would be almost impossible to notice just by looking. One powerful way to

catch errors is the set of mutually disjoint high level classes in gist. These include, for example,

Organization, GeoPrimitive, PhysicalThing and Event. If you inadvertantly

create a class that is a subclass of two or more of these disjoint classes, the inference engine will

flag the class as being unsatisfiable, i.e., it cannot possibly have any member individual.

Continuing with the country example, one might create a class called myeo:County and make

it a subclass of both Organization and a GeoRegion. However, GeoRegion is a subclass

of GeoPrimitive, which is disjoint from Organization. Therefore, no individual can be

both a gist:GeoRegion and an gist:Organization, so the inference engine will flag

myeo:Country as being unsatisfiable. Some ontology tools will give you an explanation

stating which axioms caused the problem (see Figure 3). This is a very powerful feature, and is

especially helpful early on when you are getting familiar with gist. It helps reinforce what the

gist concepts really mean.


8

Figure 3

Reduced complexity is the third way that gist helps to improve the quality of your enterprise

ontology. When building ontologies, it is easy to create two or more different concepts that mean

nearly the same thing. This is especially so if the ontology is large, or if it is being built by

multiple parties. This makes things complicated and hard for others to understand. The discipline

of identifying gist concepts for each of the concepts in your ontology helps you spot these cases

of “undiagnosed similarity” where two concepts that appear different at first blush are actually

the same. This results in fewer overlapping concepts that have unnecessary distinctions giving a

smaller simpler ontology. For example, we once went into an organization that had about 25

different ways to say “approximately,” for example, estimated, budgeted, projected, allotted,

funded, allocated, assigned, booked, reserved, apportioned, and predicted were all used with

respect to budgeting. After a careful analysis, it was determined that there were really only four

categories that were substantially different from one another. As we mentioned above, reduced

complexity also contributes to clarity and ease of use.

Figure 4: gist Design Rationale

This figure shows how we designed gist to make it easy to use.


9

DESIGN PRINCIPLES

To realize these benefits, we designed gist to be as easy as possible to use and extend. This

section elaborates various design principles and how they combine to make gist easy to use (see

Figure 4). We look to your feedback for further improvements.

One way we help make gist easy to extend is to favor object properties over datatype properties.

We cannot anticipate all the creative uses you might put our properties to, and using datatype

properties can limit you. For example, there is a gist property called hasPreferredTerm. We

could have easily made this a string datatype property, which would be fine for some purposes.

Instead, we made it an object property with range gist:Text. This way, anyone who wishes to

keep more information about preferred terms can easily do so, e.g., for tracking provenance. In

the event that you want a string datatype property, you can create your own, just like you will

create many other things you need that are not in gist.

To make it easy for you to find the right gist concept to match your needs, we have the design

goal that it is easy to find a unique gist concept that most closely matches a given concept in your

business. Our approach to achieving this is manifest in the following principles and guidelines.

These are intended to guide rather than constrain. Any break from these guidelines is done with

care. Our design principles and guidelines are:

1. to have adequate coverage of common business concepts (so you can find what you need)

2. for gist to be easy to learn and understand

a. to have a minimal number of concepts3 (so you don’t have too many things to

look through)

b. to have the meaning of each gist concept be clear and unambiguous (so you can

quickly rule out wrong concepts and identify right ones)

c. to organize the major concepts to align with how ordinary human brains

categorize information rather than starting with schemes that are rooted in

academic philosophy

d. to use everyday terms to name concepts, rather than terms that are used in the

philosophical literature

3. to have minimal overlap in concepts (so there is only one ‘right’ concept to choose from)

4. to structure the sets of classes and properties into major sub-areas (to quickly narrow in

on a small set of concepts most likely to contain the concept you are looking for)

a. to have a small number of top-level classes and top-level properties that are

mutually disjoint

b. minimize the number of ‘orphan’ concepts (those with no parent).

c. to organize the classes into topic areas, that are separate from the subclass

3 At the time of this writing, there are just 251 concepts (96 classes and 155 properties).


10

hierarchy.

For example, groups of classes include: time, place, people, document. Property groupings

include: features, containment, causality, peer-to-peer.

One way we keep the number of primitives small is to avoid creating a subproperty if its

meaning is essentially the same as the superproperty, but has a more restricted domain or range.

We illustrate this with an example in the genealogy domain. Suppose we have the property

myeo:siblingOf and we want to model brothers and sisters. One way would be to create two

subproperties, myeo:brotherOf and myeo:sisterOf, whose domains are myeo:Male

and myeo:Female respectively, and define the class myeo:Brother as “brotherOf min

1”, and myeo:Sister as “sisterOf min 1”. This introduces two new classes and two

new properties.

However, we can easily capture the semantics of brother and sister without introducing any new

properties. Brother is defined as “Male and siblingOf min 1” and Sister is defined

as “Female and siblingOf min 1”. This way we can define the brother and sister

concepts entirely in terms of existing primitives with the same number of classes and without

creating any new properties. The only thing we are getting from brotherOf and sisterOf is

the more restricted domain; we have put that instead in the class expressions defining brother and

sister. We have essentially moved the semantics of brother from the domains of two new

properties into the definitions of the brother and sister classes (see Figure 5).


11

Figure 5

This example shows how you can avoid creating new primitives by using existing ones. The semantics of Brother and Sister can be in those classes instead of in new properties that don’t add much.

Female

Person

Male

brotherOfmin 1 owl:Thing

Equivalent to

--- AND ---

Brother

Female

sisterOfmin 1 owl:Thing

Equivalent to

--- AND ---

Sister

Male

hasSibling(siblingOf)

Domain:Person Range:Person

hasBrother(brotherOf)

Domain:Person Range:Male

hasSister(sisterOf)

Domain:Person Range:Female

hasSibling(siblingOf)

Domain:Person Range:Person

Female

Person

Male

siblingOfmin 1 owl:Thing

Equivalent to

--- AND ---

Brother

Female

siblingOfmin 1 owl:Thing

Equivalent to

--- AND ---

Sister

Male


12

Keeping the number of primitives low helps because the fewer things you have, the easier it is to

find what you need. It helps during ontology development. Very importantly, it also helps

downstream when others evolve and apply the ontology.

LEARNING GIST

As noted above, gist consists of two parts, a mature core module and a collection of less mature

subgists on a variety of topics. The discussion here will be on the core module.

OVERVIEW AND LAYOUT

As you read this, you might wish to load gist into your favorite Owl ontology editing or viewing

environment to check things out as we go along. In addition, we provide two graphical layouts to

help you visualize gist. One is the ontology itself, as authored in an in-house Visio 2007 plugin

called e6tOWL exported as a pdf. We also provide a high level overview which is formatted for

printing on 11x17 paper. It is a summary of gist that can be used as an index into the larger, more

detailed, Visio layout. The two views for classes and properties are given in Figures 6-9.

Figure 6: gist Classes: Overview and Index This overview of gist classes can be used as an index into the complete set of definitions in Figure 7.

PhysicalThing

MolarQuantity

MoleUnitElectricalCurrentUnit

ElectricCurrent

LuminescenceUnit

Luminance

TemperatureUnit

Temperature

January 2013

http://ontologies.semanticarts.com/gist/gist.owl www.semanticarts.com/gistDocumentation:

UnitOfMeasure

BaseUnit

Magnitude

now

Time

TimeInstant

LocalInstant

TimeInterval

OrderedCollection

Collection

RatioUnit

Percentage

Ratio

here

Place

GeoSegment

GeoPoint

GeoRoute

TimeZone

GeoRegion

GeoPrimitive

home

DurationUnit

Landmark

Landmark

Building

Room

Artifact

PhysicallyLocatable

BuildingAddress

RelativeLocation

Origin

Location

Duration

DistanceUnit

Extent

me

Person

LivingThing

Person

TelephoneNumber

PostalAddress

SocialBeing

MediaType

AreaUnit

Area

VolumeUnit

Volume

CurrencyUnit

Monetary

this

Document

Content

Media

Text

Message

ElectronicMessageAddress

Address

Term

ComputerLanguage

NaturalLanguage

Language

CountingUnit

Count

must

Agreement

Obligation

Agreement

Offer

ProductOffering

ServiceOffering

Offering

MassUnit

Weight

happen

Event

Movement

Conversion

SpeechAct

Event

ComputerProgram

want

Intention

Goal

Intention

Requirement

Permission

Restriction

Criteria

ARule

Template

Available in a

separate unit

ontology

gist 6.7 Upper Enterprise Ontology: Classes

OrderedMember

it

Stuff

PhysicalSubstance

PhysicalIdentifiableItem

NonPhysicalSubstance

Money

Ownable

DegreeOfCommitment

Category

ID

us

Organization

MarriedCouple

UnitedNations

Organization

CountryGovernment

GovenmentOrganization

Agent

DelegatedAgent Behavior

Shapes with colored fill: Regular classes. The color indicates the topic. Gray

means no particular topic.

Shapes with white fill: Abstract classes defined in terms of more primitive classes.

These are mostly used for domain, range or as filter classes in property

restrictions. If the border is colored, the class is defined using terms only in the

topic corresponding to that color.

Shapes with colored fill with white dots: Available in separate ontology outside of

gistCore.

Legend

TemporalRelation


13

Lower means more psychologicaly basic.

NB: Additional Units of measure and conversion factors may be

found in a separate units ontology that imports this one.gist 6.7 Classes Units and Measures

Subclass of

gist:Ratio

gist:PercentageThis is a ratio class where the numerator

and denominator are of the same unit of

measure. This would have to be enforced

as a SWRL rule. Note: there are various

ways to represent percentage: 50/100

could be represented as "50" or "0.5". We

have chosen the later as it involves fewer

conversions for subsequent use.

gist:UnitOfMeasure

gist:numeratorsome gist:UnitOfMeasure

gist:denominatorsome gist:UnitOfMeasure

gist:RatioUnitRatio Units are composed of two units, a

numerator and denominator (for instance,

miles/hour). Conversion factor will not be

on the ratios, but will be on the numerator

and denominator (i.e., there won't be a

conversion factor from miles/hour to

kilometers/sec, but there will be one to

convert the miles to kilometers and the

hours to seconds).

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:RatioUnit

gist:Ratio

--- AND ---

gist:second gist:meter gist:squareMeter gist:cubicMeter gist:uSDollar gist:kilogram gist:each

gist:BaseUnit

gist:Organization

gist:GeoPrimitive

gist:Content

gist:UnitOfMeasure

gist:Magnitude

gist:Event

gist:PhysicalThing

gist:Obligation

gist:Intention

gist:ID

gist:Language

gist:Category

--- ALL DISJOINT ---

- gist:second

gist:meter

gist:squareMeter

gist:cubicMeter

gist:uSDollar

gist:each

gist:kilogram

--- ALL DIFFERENT ---

has a GeoRegion, is not the GeoRegion. The

same TZ could have a different region later on.

2012-04-19

Place

gist:hasAltitudesome gist:Extent

gist:latitudesome double

gist:longitudesome double

gist:GeoPointIndividual point on Earth's surface,

including latitude, longitude and altitude. If

altitude is missing, assumed to be at the

earth's surface, however, altitude is

measured from sea level.

--- AND ---

gist:geoDirectlyContainssome gist:GeoPoint

gist:hasMagnitudesome gist:Area

gist:GeoRegionBounded region(s) on surface of the earth.

At this level a geoRegion could be non-

contiguous; e.g. the region governed by

the USA is the region governed by the

lower 48 states plus that of Alaska and

Hawaii). Child classes in lower ontologies

can make this distinction.

--- AND ---

gist:OrderedCollection

gist:hasDirectPartsome gist:GeoSegment

gist:GeoRouteOrdered set of GeoPoints that define a

route from starting point to ending point.

--- AND ---

gist:fromPlaceexactly 1 gist:GeoPoint

gist:toPlaceexactly 1 gist:GeoPoint

gist:GeoSegmentSingle segment.

--- AND ---

gist:GeoRegion

gist:offsetToUniversalsome gist:Duration

gist:TimeZoneI haven't found a definitive source for time

zone names or their geoboundaries. I'll

suggest the tz database for now.

--- AND ---

gist:GeoPoint

gist:GeoRegion

gist:GeoSegment

gist:GeoPrimitiveAny of the primary geographical shapes.

--- OR ---

gist:RelativeLocation

gist:GeoPrimitive

gist:Location

--- OR ---

(N) gist:regardingsome gist:Origin

(N) gist:xOffsetsome gist:Extent

(N) gist:yOffsetsome gist:Extent

(N) gist:zOffsetsome gist:Extent

gist:RelativeLocationLocation relative to an origin.

gist:OriginDescription of a place, physical or abstract,

that can be used to position other items

relatively. The origin might be the top left of

a screen or form, or it might be the back,

lower left corner of a trailer.

Person

gist:Agent

gist:onBehalfOfsome gist:SocialBeing

gist:DelegatedAgent

--- AND ---

gist:SocialBeing

gist:ComputerProgram

gist:Agent

--- OR ---

gist:PhysicalIdentifiableItem

gist:offspringOfsome gist:LivingThing

gist:hasBirthsome gist:TimeInstant

gist:LivingThingSomething that is or at some point was

alive and growing.

--- AND ---

gist:LivingThing

gist:namesome string

gist:offspringOfsome gist:Person

gist:PersonThis is a member of homo sapiens, who

has lived at some point, and may or may

not be dead. With open world you never

know if someone has died. Fictitious

people are not persons.

--- AND ---

gist:Person

gist:Organization

gist:SocialBeingThis is the Cyc term, if we can, I'd like to

think of something better. Until then this

is just the union of people and

organizations. it is a superset of objects

that can enter into contracts. We're not

calling it a party as that is the relationship

to the contract more than the entity that

might be able to enter into one.

--- OR ---

Organization

gist:hasMembersome gist:Person

gist:OrganizationA generic organization that can be, e.g.,

formal or informal, legal or non-legal.

gist:GovernmentOrganization

gist:directlyRecognizedBysome gist:UnitedNations

gist:CountryGovernment

--- AND ---

gist:Organization

gist:recognizedBysome gist:CountryGovernment

gist:governssome gist:GeoRegion

gist:GovernmentOrganizationEstablished either by fiat (as a conquering

army overtakes a land and declares a

government) or by delegation from a fiat

government, such as a state or local

government or a specific agency. Differ

from corporations in that they cannot be

owned.

--- AND ---

Subclass of

gist:Organization

(N) gist:partyexactly 2 gist:Person

(N) gist:directlyRecognizedBysome gist:GovernmentOrganization

gist:MarriedCoupleThe entity that can engage in contracts, as

joint tenants, tenants in common, etc.

Subclass of

gist:Organization

(N) gist:directlyRecognizedBysome gist:GovernmentOrganization

gist:UnitedNations

Stuff

Subclass of

gist:NonPhysicalSubstance

(N) gist:hasMagnitudesome gist:Monetary

gist:MoneyPaper or electronically transferrable

monetary asset. Not a price, but an asset.

(N) gist:madeUpOfsome gist:PhysicalSubstance

(N) gist:identifiedBysome gist:ID

gist:PhysicalIdentifiableItemYou could at least in principle put an RFID

tag on members of this class. Physical

things are made of something, e.g., statues

are made of bronze.


gist:PhysicalSubstance

gist:PhysicalThing

--- OR ---

Subclass of

gist:Category

gist:MediaTypeThe first level is media types like oil, or

marble, paper or electronic, then we get to

specific MIME types

gist:Ownable

gist:producedBysome gist:Agent

gist:hasGoalsome gist:Intention

gist:ArtifactSomething intentionally made

--- AND ---

gist:Content

gist:Organization

gist:Permission

gist:PhysicalThing

gist:Money

gist:OwnableThat which can (at least theoretically) be

owned. All current jurisdictions have rules

against owning people, but that needs to

be expressed in rules rather than

definitions.

--- OR ---

gist:NonPhysicalSubstanceA substance in the sense that there is

measurably more or less of it, but not

necessarily physical (money and content, for

instance).

(N) gist:hasMagnitudesome gist:Weight

(N) gist:hasMagnitudesome gist:Volume

gist:PhysicalSubstanceNon corporeal material. That is, "stuff"

which can be divided in half and stil retain

its essence (i.e., water, penicillin and even

h. pilori bacteria except for those very rare

cases where someone is studying an

individual bacterium).

X

Document

gist:Content

gist:expressedInsome gist:ComputerLanguage

gist:ComputerProgramContent (code) that converts inputs into

outputs

--- AND ---

gist:Content

gist:fromAgentsome gist:Agent

gist:toAgentsome gist:Agent

gist:MessageA specific message from an Agent to at

least one other agent. Could be email, a

phone call, a voice message or a Web

Service message between applications.

--- AND ---

Subclass of

gist:Address

(N) gist:regardingsome gist:Agent

gist:ElectronicMessageAddressAny place a message can be sent (email,

fax, etc.).

gist:PhysicalSubstance

gist:categorizedBysome gist:MediaType

gist:MediaLow level primitive for stored information,

e.g., could be paper, electronic, etc.

--- AND ---

gist:Content

gist:expressedInsome gist:Language

gist:textsome string

gist:TextContent in words.

--- AND ---

Subclass of

gist:Content

gist:AddressA place (real or virtual) that can be located

by some routing algorithm and where

messages or things can be sent to or

retrieved from. E.g. PO Box or URL to a pdf

file.

gist:expressedInsome gist:Media

gist:aboutmin 1 gist:Ownable

gist:ContentDocuments, programs, images and the

like. Categories are not content until they

are written down.

--- AND ---

Subclass of

gist:Content

gist:TermNarrative description of the specifics of an

offer. This is "term" in the sense of the

"terms" of a contract.

Agreement

gist:partymin 2 gist:SocialBeing

gist:hasDirectPartmin 2 gist:Obligation

gist:AgreementContract or other binding agreement,

usually evidenced by signature(s).

--- AND ---

gist:giversome gist:SocialBeing

gist:gettersome gist:SocialBeing

gist:governedBysome gist:Offer

gist:categorizedBysome gist:DegreeOfCommitment

gist:ObligationA future commitment from one social

being to another. Contracts are sets of

oblgations to do or forebear, or indemnify

or warrant.

--- AND ---

gist:plannedEndsome gist:TimeInstant

gist:hasMagnitudesome gist:Monetary

gist:giversome gist:SocialBeing

gist:hasDirectPartsome gist:Offering

gist:OfferSomething which could be offered

commercially. Includes products, services,

guaranties, warranties, encumbrances,

etc.

--- AND ---

(N) gist:describedInsome gist:Term

gist:OfferingA description of the thing being offered,

(its features, etc.).

gist:Offering

gist:regardingsome gist:Ownable

gist:ProductOfferingOffering something which could be

warehoused.

--- AND ---

gist:Offering

gist:producesome gist:Behavior

gist:ServiceOfferingA description of something that can be

done for a person or organization (which

produces some form of an "act").

--- AND ---

Event

gist:Event


gist:affectsmin 1 gist:Ownable

gist:fromPlacesome gist:Location

gist:toPlacesome gist:Location

gist:MovementThe event of something moving along a

route from A to B where some Agent

does the moving. The thing moved is

Ownable. This excludes things that

move on their own e.g., water down a

hill.

--- AND ---

gist:BehaviorWays of categorizing events, e.g.,

differentiating drilling versus cutting.

gist:Event


gist:affectsmin 1 gist:Ownable

gist:inputmin 1 owl:Thing

gist:outputmin 1 owl:Thing

gist:ConversionAn event where one or more inputs is

transformed by an Agent in some way to

produce one or more outputs. E.g.

calculation, manufacturing process

--- AND ---

gist:Event

gist:producedBysome gist:SocialBeing

gist:affectsmin 1 owl:Thing

gist:SpeechActA communication event, such as making a

commitment, placing an order, making a

request, complaining, issuing a warning or

refusing. Not necessarily oral. Loosely

based on Searle, We will say that People

and Organizations can make speech acts,

but not computer programs.

--- AND ---

gist:TimeInterval

gist:characterizedAssome gist:Behavior

gist:EventSomething happening over some period of

time, often characterized as some kind of

activity being carried out by some agent.

E.g. speaking, converting, moving.

--- AND ---

Intention

rdfs:commentEXAMPLE: a form. A filled-in form has

the structure of the form with data

entered into some or all of the fields.

rdfs:commentNOTE: Use gist:basedOn to link the

instantiation of a Template back to its

Template.

gist:TemplateA structure that is used as the basis for

generating new individuals that have that

structure.

gist:IntentionGoal, desire, aspiration. This is the

"teleologic" aspect of the system that

indicates things are done with a purpose.

gist:Intention

gist:allowsome gist:Behavior

gist:PermissionA description of things one is permitted to

do; could be broad such as free speech,

but more often is very specific such as the

right of egress through a particular

property.

--- AND ---

gist:ARuleAn evaluatable set of criteria (might be

machine interpretable but in this case mostly

human interpretable).

Subclass of

gist:Intention

gist:GoalA specific intentional endpoint.

gist:Intention

gist:preventsome gist:Behavior

gist:RestrictionA description of things one is prevented

from doing; could be broad such as free

speech, but more often is very specific

such as the right of egress through a

particular property.

--- AND ---

Subclass of

gist:Intention

gist:CriteriaA set of guildelines used in making a

decision. General term that covers Rules,

Laws and programmable criteria.

gist:requiresome gist:Behavior

gist:Intention

gist:RequirementA generic description of things that one

is required to do.

--- AND ---

Time

(N) gist:universalDateTimesome dateTime

(N) gist:universalDatesome string

(N) gist:universalTimesome string

gist:TimeInstantA point on a time line. Could be a literal

instant (as in 12:01.0001 January 1, 2008),

or a broader but still single point in time

(January 1, 2008). Time and dates are in

xsd: DateTime format in Universal Time.

(N) gist:startsome gist:TimeInstant

(N) gist:endsome gist:TimeInstant

(N) gist:hasMagnitudesome gist:Duration

gist:TimeIntervalA specific interval on a time line. So this is

January 1, 2008 to January 8, 2008, which

has a duration , but isn't a duration. Note

has two instants. The endDate is assumed

to be greater than the start, but this is not

enforced.

(NS) gist:hasMembermin 1 owl:Thing

gist:CollectionA number of things of any sort grouped

together.

(N) gist:occurredAtsome gist:TimeZone

(N) gist:localDateTimesome dateTime

(N) gist:localDatesome string

(N) gist:localTimesome string

gist:LocalInstantA point in time expressed relative to a local

time zone. Can be converted to Universal

Time using the time zone offset.

(N) gist:startsome gist:TimeInstant

(N) gist:endsome gist:TimeInstant

(N) gist:connectedTomin 2 owl:Thing

gist:TemporalRelationA relationship holding for a period of time.

E.g. employs-Employment,

hasStreetAddress-EstablishedLocation.

One important context for reifying a

property.

Subclass of

gist:Collection

(N) gist:hasOrderedMembersome gist:OrderedMember

(N) gist:hasOrderedMemberall gist:OrderedMember

rdfs:commentNOTE: The precedence relationships

hold only between members of the same

OrderedCollection. For example,

consider the two OrderedCollections:

{1,2,3} and {badsmell, nosmell,

goodsmell}. Even though 1 and nosmell

are both OrderedMembers, {1, nosmell}

is not an OrderedCollection since there

is no ordering relationship between 1

and nosmell. OWL cannot express this

constraint.

rdfs:commentNOTE: the ordering may be specified

manually or algorithmicaly.

gist:OrderedCollectionEach member of the ordered collection

either precedes, is the same order as or

is preceded by every other member. This

gives rise to a rank order where more

than one member can occupy a given

rank. The rankings themselves are

totally ordered.

(NS) gist:orderedMemberOfsome gist:OrderedCollection

gist:precedessome gist:OrderedMember

gist:precededBysome gist:OrderedMember

Subclass of

--- OR ---

gist:OrderedMemberA member of an OrderedCollection;

necessarily precedes or is precededBy

another OrderedMember in the same

collection (last part cannot be stated in

OWL). No OrderedMember can be in

more than one OrderedCollection.

gist:BaseUnit

gist:hasUoMsome gist:UnitOfMeasure

gist:decimalValuesome decimal

gist:MagnitudeA scalar value which is either measured,

estimated or set as a refernece value.

Magnitudes of the same dimensional type (

i.e., duration or electric current) can be

compared with a greater than or less than

operator, but can still differ in their

relationToTheWorld type (i.e., you can

compare actuals to estimates or

references as long as the dimension is the

same).

--- AND ---

gist:convertToBasesome double

gist:baseUnitexactly 1 gist:BaseUnit

gist:UnitOfMeasureEach unit has a base unit and a conversion

factor to the base. The bases are from SI.

This is the number you multiple a Unit by

to get to base or divide by to get from

base. So the convertToBase for inch is

0.0254 to get you to the base (meter)

--- AND ---

gist:convertToBase - 1.0 float

gist:second

gist:second

gist:baseUnit ->

gist:UnitOfMeasure

gist:baseUnithas gist:second

gist:DurationUnitUnits to measure passage of time, hours,

days, years.

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:DurationUnit

gist:DurationTime, but not on time line. For instance

one week, or seven days, but not Jan 1,

2008 to Jan 7, 2008 (which is an interval).

Intervals have durations but aren't

durations.

--- AND ---


gist:meter

gist:meter

gist:baseUnit ->

gist:UnitOfMeasure

gist:baseUnithas gist:meter

gist:DistanceUnitUnits to measure linear distance such as

feet and kilometers.

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:DistanceUnit

gist:ExtentA measure of distance which could be

distances over the earth, and could also be

height, width, length, depth, girth, etc.

--- AND ---


gist:squareMeter

gist:squareMeter

gist:baseUnit ->

gist:UnitOfMeasure

gist:baseUnithas gist:squareMeter

gist:AreaUnitUnits of two-dimensional area such as

square inches and hectares.

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:AreaUnit

gist:AreaTwo-dimensional area.

--- AND ---


gist:cubicMeter

gist:baseUnit ->

gist:cubicMeter

gist:UnitOfMeasure

gist:baseUnithas gist:cubicMeter

gist:VolumeUnitUnits of three dimensional volume (cubic

inch) as well as fluid volume (ounces).

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:VolumeUnit

gist:VolumeThree dimensional space or equivalent

fluid measurement.

--- AND ---


gist:uSDollar

gist:uSDollar

gist:baseUnit ->

gist:Magnitude

gist:currencyValuesome decimal

gist:hasUoMsome gist:CurrencyUnit

gist:MonetarySpecial type of magnitude due to the way

rounding is handled in math and temporal

aspect of conversion.

--- AND ---

gist:UnitOfMeasure

gist:baseUnithas gist:uSDollar

gist:CurrencyUnitUnits of money. Note: this is the only unit

whose conversion factors include time

(i.e., the conversion rates change on a

daily basis).

--- AND ---

gist:kilogram

gist:baseUnit ->


gist:kilogram

gist:UnitOfMeasure

gist:baseUnithas gist:kilogram

gist:MassUnitUnits of weight, e.g., pounds, kilos, etc.

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:MassUnit

gist:WeightMagnitude of mass. Assumes object is

near the earth's surface, so weight and

mass are equivalent for our purposes.

--- AND ---

gist:each

gist:baseUnit ->


gist:each

gist:UnitOfMeasure

gist:baseUnithas gist:each

gist:CountingUnitUnits of counting, especially "each" but

also units such as dozens.

--- AND ---

gist:Magnitude

gist:hasUoMsome gist:CountingUnit

gist:CountMeasures that involve countable amounts

("eaches" as well as cases, etc.). Can be

decimal. Note: we did not make count

disjoint with all the other magnitudes as

there are some magnitudes that could

conceivably be counted (say distance in

rods, it's a bit of a stretch admittedly but

shouldn't harm anything).

--- AND ---

many

rooms do

not have

door

numbers,

should be

optional.

Landmark

gist:PhysicallyLocatable

gist:isDirectPartOfsome gist:Building

gist:identifiedBysome gist:ID

gist:RoomAn enclosed area within a building.

--- AND ---

Subclass of

gist:Address

(N) gist:regardingsome gist:SocialBeing

gist:PostalAddressA set of codes the postal authorities can

use to deliver mail. Could be a street

address, could be a postal address, could

be the route codes.

Subclass of

gist:Address

gist:regardingsome gist:Agent

gist:TelephoneNumberSome phone numbers accept faxes, some

allow Internet access, etc.

Subclass of

gist:Address

(N) gist:regardingsome gist:Building

gist:BuildingAddressAn address that you can send mail to or

that you could find in the physical world.


gist:permanentGeoContainedInsome gist:GeoRegion

gist:Landmark

--- AND ---

Subclass of

gist:Landmark

Subclass of

gist:Artifact

gist:Building


gist:GeoPrimitive

gist:PhysicallyLocatableCan be found in the real world; includes

counties as well as cars.

--- OR ---

Subclass of

gist:Category

gist:DegreeOfCommitmentHow obligated you are to the commitment,

which often includes what legal remedies

exist for non compliance.

(N) gist:allocatedBysome gist:Domain

gist:CategoryInstances of this class are used to

categorize other instances informally. This

could be tags, folksonomies or formal

definitions from other systems.

gist:LanguageA recognized, organized set of symbols and

grammar.

Subclass of

gist:Language

gist:ComputerLanguageA language which could be executed by a

computer.

Subclass of

gist:Language

gist:NaturalLanguageA human language such as English or

Spanish.

gist:allocatedBysome gist:Agent

gist:uniqueTextsome string

gist:IDA string of characters that refers to a

referent in the real world (person, place,

organzation, vehicle, etc.), a concept or an

event. Intended to be unique within a

domain (but generally no guarantee of

this).

--- AND ---

Figure 7: gist Classes This is the complete set of classes in gist, as depicted as authored.


14

Figure 8: gist Properties: Overview and Index This overview of gist properties can be used as an index into the complete set of definitions in Figure 9.

hasPart[T]

(partOf)

hasDirectPart

(directPartOf)

hasOccupant

(occupantOf)

geoDirectlyContains

(geoDirectlyContainedIn)

giver

(giverOn)

getter

(getterOn)

hasFeature

(featureOf)

hasAltitude

hasMagnitude

start

plannedStart

actualStart

hasBirth

end

plannedEnd

actualEnd

planned actual

recognizedBy[T]

(recognizes)

directlyRecognizedBy

(directlyRecognizes)

fromAgent

(agentFrom)

toAgent

(agentTo)

occurredAt

(occurrences)

offsetToUniversal

denominator

numerator

baseUnit

hasUoM

recordedOn

hasA

(of)

xOffset

yOffset

zOffset

Peer relationships.No superior/subordinate

relationship between

Subjects and Objects

Descriptives

IdentifiedBy [IF]

(identifies)

universalTimetime

universalDate date

localDate date

localTime time

localDateTime datetime

universalDateTime datetime

time time date datedatetime datetime

geoContains[T]

(geoContainedIn)

Mereology

Spatial

Contains

contains

(containedIn)

hasMember

(memberOf)Membership

useUp

(usedUpBy)

hasGoal

(goalOf)

produceOffspring

(offspringOf)

guardianOver

(hasGuardian)

hasJurisdiction

(presidedOverBy)

affects

(affectedBy)

Causal

Subject affects or causes Object

produce

(producedBy)

use

(usedBy)basisFor

(basedOn)

governs

(governedBy)

controls

(controlledBy)

owns

(ownedBy)

cause

(causedBy)

prevent

(preventedBy)

allow

(allowedBy)

connectedTo

(hasConnection)

party

(partyTo)

input

(inputOn)

output

(outputOn)

fromPlace

(placeFrom)

toPlace

(placeTo)

delegatesTo

(onBehalfOf)

allocatedTo

(hasBeenAllocated)

regarding

(inRegardOf)

about

(describedIn)

hasPreferredTerm[F]

(preferredTermOf)

hasStreetAddress

(streetAddressOf)

supercede

(supercededBy)

hasCommunicationAddress

(communicationAddressOf)

expressedIn

(usedToExpress)

categorizedBy

(categorizes)

decimalValue decimal

currencyValue decimal

latitude double

longitude double

convertToBase double

conversionOffset double

sequence integer

text string

uniqueText string

label string

name string

madeUpOf

(madeInto)Constitution

Superior subordinate relationships.

Subject exclusively

has Object

Features

Measurement

related

ContainsSubject contains or is in some way a whole

with respect to the Object.

gist 6.7 Upper Enterprise Ontology: Properties Subproperties represented by indentation and open-ended arrows.

Inverse Properties indicated in parentheses.

Domain/Range Domain color on left, Range color on right.

Datatype Propertiess: indicated with rectangle with datatype range inset.

Legend

January 2013

characterizedAs

(characterizes)

hasOrderedMember [IF]

(orderedMemberOf)

require

(requiredBy)

precedes[T]

(precededBy)

strictlyPrecedes

(strictlyPrecededBy)

allocates

(allocatedBy)

hasPermanentLocation

(permanentLocationOf)

hasPhysicalLocation

(physicalLocationOf)


15

Author: Dave McComb

Last Updated: 1/8/2013

Superior subordinate relationships

Features

Mereology

Spatial

Contains

Measurement

related

TemporalNote: most dates have a start/end parent and a planned/actual parent

Peer RelationshipsObjects have peer (i.e., non subordinate) relationship to subjects.

Causal relationsSubject affects or causes object.

Descriptives

Membership

Constitution

GIST ATTRIBUTION for when it is used:

This work is derived from and/or directly uses concepts from gist, a copyrighted ontology from Semantic Arts, Inc. Rights to use are conveyed under the Creative Commons Attribution-ShareAlike 3.0 licensehttp://creativecommons.org/licenses/by-sa/3.0/legalcode

gist 6.7 Properties

gist:characterizedAs(gist:characterizes)

Domain:gist:Event Range:gist:Behavior

The kind of Behavior that took place during an

Event.

gist:fromPlace(gist:placeFrom)

Range:gist:PhysicallyLocatable

a point or region that something came from

gist:toPlace(gist:placeTo)

Range:gist:PhysicallyLocatable

a point or region that something went to

gist:fromAgent(gist:agentFrom)

Range:gist:Agent

The source of a message or shipment.

gist:toAgent(gist:agentTo)

Range:gist:Agent

Comment: this is not the inverse of

fromAgent. A message can be from

someone. If we made it the inverse the

person would be "to" the message

gist:output(gist:outputOn)

Domain:gist:Event

The material (physical or otherwise) that

comes out of a doing event of some kind.

gist:input(gist:inputOn)

Domain:gist:Event

The material (physical or otherwise) that

goes into a doing event of some kind.

gist:numeratorDomain:gist:RatioUnit Range:gist:UnitOfMeasure

Fiirst term in a ratio unit of measure. (Distance in

the ratio unit "speed.")

gist:denominatorDomain:gist:RatioUnit Range:gist:UnitOfMeasure

Second unit in the ratio unit of measure (Duration

(time) in "speed.")

gist:giver(gist:giverOn)

Obligations have one party that is

giving and one receiving (getting).

gist:getter(gist:getterOn)

Obligations have receivers of the

obligation.

gist:party(gist:partyTo)

Range:gist:SocialBeing

The people or organizations that

are e.g. in an Agreement

gist:connectedTo(gist:hasConnection)

A non owning, non causal, non-subordinate (ie.

peer to peer) relationship.

gist:madeUpOf(gist:madeInto)

Range:gist:PhysicalSubstance

gist:dateDomain:gist:TimeInstantstring

gist:timeDomain:gist:TimeInstantstring

gist:dateTimeDomain:gist:TimeInstantdateTime

gist:categorizedBy(gist:categorizes)

Range:gist:Category

Points to a taxonomy item or other less formally

defined class.

gist:convertToBaseDomain:gist:UnitOfMeasuredouble

The conversion factor used to get to the base unit. E.g., multiplying by 0.0254 gets

you from inches to meters. Divide by this number to go the other way. Used in

conjunction with conversionOffset to convert from one unit to another.

Degrees K = (Degrees F - conversionOffset) * convertToBase. Or K = (F-(-469.67)) *

(5/9). To go the other way: F = (K * 9/5) -469.67. Try it on Google.

gist:decimalValueDomain:gist:Magnitudedecimal

gist:currencyValuedecimal

Currencies are rounded to specified precision

gist:conversionOffsetDomain:gist:UnitOfMeasuredouble

Add this number to get to the zero point. On the Celsius scale, the

conversionOffset is -273.15 degrees C. On the Fahrenheit scale it is -459.67

degrees. Is equal to 0 when the unit has the same zero point as the base unit. e.g.

inch, meter.

gist:hasUoMDomain:gist:Magnitude

Range:gist:UnitOfMeasure

Which unit of measure you are using. All

measures are in some uom, even if we don't know

what it is initially.

gist:zOffsetDomain:gist:Origin Range:gist:Extent

How far in the "z" dimension this item is from its

local origin.

gist:yOffsetDomain:gist:Origin Range:gist:Extent

How far in the "y" dimension this item is from its

local origin.

gist:xOffsetDomain:gist:Origin Range:gist:Extent

How far in the "x" dimension this item is from its

local origin.

gist:uniqueText [F]string

This is used for the actual value of

a key or ID where you don't want

the possibility of having more than

one.

gist:governs(gist:governedBy)

The subject controls or inhibits the object in some

way. Ownership is one case, as is jurisdiction,

inhibiting, custodianship.

gist:owns(gist:ownedBy)

Domain:gist:SocialBeing Range:gist:Ownable

Owning adds legal title to governance.

gist:guardianOver(gist:hasGuardian)

Domain:gist:SocialBeing Range:gist:Ownable

gist:hasJurisdiction(gist:presidedOverBy)

Domain:gist:SocialBeing

gist:controls(gist:controlledBy)

This is the essential agentive relationship. If I've been

delegated the right to enter into a contract on

someone's behalf, I'm their agent in that context, but

we'll say they control the the ability to enter into a

contract.

gist:occurredAt(gist:occurrences)

Range:gist:GeoPrimitive

Location where an event occured.

gist:universalDate gist:universalDateTime gist:universalTime

gist:latitudeDomain:gist:GeoPointdouble

gist:longitudeDomain:gist:GeoPointdouble

gist:textstring

gist:labelstring

gist:sequenceinteger

For ordering ordered lists.

gist:namestring

This is the casual definition of

name. For some items it might be

more appropriate to use a sub type

of identifiedBy.

gist:allocatedTo(gist:hasBeenAllocated)

Meaning that the subject has been assigned

or reserved or set aside to the object. Funds

can be allocated to projects, people (really

their time) can be allocated to tasks,

departments, or organizations. There will

likely be many subproperties of this with

varying shades of meaning for how flexibly

the allocation has been made.

gist:affects(gist:affectedBy)

These are relationships where the domain end has

some sort of effect on the range end. As much as

possible, these will be verb tense independent, so we

won't have use, uses, used, but just use.

gist:hasGoal(gist:goalOf)

Range:gist:Intention

A process or agent that has a specific intention.

gist:produceOffspring [AS](gist:offspringOf)

Domain:gist:LivingThing Range:gist:LivingThing

To be the biological parent of. Used instead of parent

because parent is highly overloaded term.

gist:produce(gist:producedBy)

The subject creates the object, i.e., a task produces a

deliverable; a template produces a program.

gist:useUp(gist:usedUpBy)

The subject consumes or consumed the object, either

wholly or partially, i.e., Painting useUp Paint. This will

also be used for "liqudate" and "partially liquidate" as

in an invoice will liquidate a PO, or a payment will

liquidate a debt.

gist:use(gist:usedBy)

To consume. The subject uses the object. Using it up

(consuming it) is a subtype of using, but the object

may not be used up but just necessary.

gist:offsetToUniversalDomain:gist:GeoRegion Range:gist:Duration

Decimal hours ahead of (+) or behind (-) GMT.

gist:hasA(gist:of)

High level property meaning to exclusively have or

possess. Superior, subordinate relationships

between subjects and objects.

gist:hasPart [T](gist:partOf)

Containing something that has

independent existence. We can say a car

hasPart seat or engine, but not hasPart

weight. The weight cannot exist

independent of the car. No cascading

delete.

gist:hasDirectPart(gist:isDirectPartOf)

Use hasDirectPart to associate parts. Allow

t's parent (hasPart) to complete the

transitivity.

gist:identifiedBy [IF](gist:identifies)

Range:gist:ID

This is like a uri: a thing can have more than one ID,

but each of the IDs must refer to a unique thing.

gist:Language

gist:Media

--- OR ---

Range

gist:expressedIn(gist:usedToExpress)

Domain:gist:Content

Intellectual Property (computer programs,

documents, inventions, etc.) are expressed in

either media or a language and usually both.

gist:hasOccupant(gist:occupantOf)

Domain:gist:Building Range:gist:SocialBeing

More specific form of incumbent where we are

referring to residing at or working at, or doing

business at a very specific location.

gist:geoDirectlyContains(gist:geoDirectlyContainedIn)

Domain:gist:GeoRegion

Range:gist:GeoRegion

Located at a specific place on the earth.

gist:recordedOn Range:gist:TimeInstant

Date that something was posted, not necessarily the

date it occurred. Must be after the occurred date, but

could be before or after the planned date. (Unusual,

but I could record today that I expected to be paid last

week.)

gist:hasAltitude Range:gist:Extent

Distance above sea level

gist:hasFeature(gist:featureOf)

A feature is something that an individual has

exclusively, and that if the individual were to go away

so would the feature. All datatype properties are

features, but in OWL it wouldn't work to have a

datatype property be a subtype of an object property.

hasFeature is just for the object type features that

work like dataType properties. It implies a cascading

delete.

gist:actualStart Range:gist:TimeInstant

When something did start, therefore noting an

historical event.

gist:plannedStart Range:gist:TimeInstant

A date/time that was at least at some point in time in

the future. It may be in the past now, but when we

planned it, it was in the future.

gist:start Range:gist:TimeInstant

Generically when something did or should start.

gist:planned Range:gist:TimeInstant

Dates that were in the future at the time they were

made.

gist:actualEnd Range:gist:TimeInstant

When something did end.

gist:plannedEnd Range:gist:TimeInstant

A date/time that was at least at some point in time in

the future. It may be in the past now, but when we

planned it, it was in the future.

gist:end Range:gist:TimeInstant

Generically when some thing did or should end.

gist:actual Range:gist:TimeInstant

historical Dates

gist:hasPreferredTerm [F](gist:preferredTermOf)

Range:gist:Text

If there are many terms for a concept or specific

instance, this is the one to use.

gist:supercede [AS](gist:supercededBy)

Domain:gist:Content Range:gist:Content

Subject supercedes the object, i.e., is a newer

version of it.

gist:hasCommunicationAddress(gist:communicationAddressOf)

Domain:gist:SocialBeing Range:gist:Address

The general class of places you can send

messages including postal addresses, fax

numbers, phone numbers, email, web site, etc.

gist:hasStreetAddress(gist:streetAddressOf)

Domain:gist:Building

Range:gist:BuildingAddress

A place that can be found on a map, has geo

coordinates; you could live or work there.

gist:regarding(gist:inRegard)

The Object in some way describes the Subject

gist:about(gist:describedIn)

Domain:gist:Content

Subject matter of a document.

gist:delegatesTo(gist:onBehalfOf)

gist:basisFor(gist:basedOn)

Reason, law, rule, etc. behind an action or decision.

gist:hasBirth Range:gist:TimeInstant

Date a living thing was "born" (or germinated, for

plants).

gist:localDate gist:localDateTime gist:localTime

gist:geoContains [T](gist:geoContainedIn)

Domain:gist:GeoRegion

Range:gist:GeoRegion

Located at a specific place on the earth.

gist:cause(gist:causeBy)

The subject will or did cause the object

gist:prevent(gist:preventedBy)

The subject will or did prevent the object

gist:allow(gist:allowedBy)

The subject will or does allow the object

gist:recognizedBy [T](gist:recognizes)

Legally acknowledging the existence of.

gist:directlyRecognizedBy(gist:directlyRecognizes)

Legally acknowledging the existence of.

gist:contains(gist:containedIn)

Generic relationship meaning the Subject contains or

includes the Object in some way.

gist:hasMember(gist:memberOf)

members in collections, organization etc

gist:hasMagnitude Range:gist:Magnitude

To have a comparable numerical value. Each

magnitude has a unit.

gist http://ontologies.semanticarts.com/gist#

Namespaces

gist

This is an upper enterprise ontology, copyright Semantic Arts Inc. Rights to use are

conveyed under the Creative Commons Attribution-ShareAlike 3.0 license http://

creativecommons.org/licenses/by-sa/3.0/legalcode. Current version at http://

ontologies.semanticarts.com/gist/gist.owl

Base URI : http://ontologies.semanticarts.com/gist/gistCore6.7

Version URI : http://ontologies.semanticarts.com/gist/gistCore6.7

Default Namespace : http://ontologies.semanticarts.com/gist#

X

gist:allocates(gist:allocatedBy)

Domain:gist:Agent

The subject (an Agent) sets aside or

reserves the Object (usually an Ownable).

gist:hasPhysicalLocation(gist:physicalLocationOf)

Domain:gist:PhysicalThing

Range:gist:Location

Indicates the location of a physical thing.

gist:hasPermanentLocation(gist:permanentLocationOf)

Domain:gist:PhysicalThing Range:gist:Location

This is for things attached to the earth. Permanent

is a relative term, but it is more than saying a car is

in a particular city, it's more that a building or tree,

or lake is (they don't move very often).

gist:baseUnitDomain:gist:UnitOfMeasure

Range:gist:UnitOfMeasure

The Object is the BaseUnit of the Subject.

gist:require(gist:requiredBy)

The Subject did or will require the Object.

rdfs:commentNOTE: Is logically a subproperty of

connectedTo, OWL2 does not permit it.

gist:precedes [T](gist:precededBy)

A generic ordering relation indicating that

the Subject has the same order as or

comes before the Object. The 'greater than

or equal to' symbol is often used for this

relation.

rdfs:commentNOTE: This is Irreflexive, but saying so can give an OWL error.

gist:strictlyPrecedes(gist:strictlyPrecededBy)

A generic ordering relation indicating that the Subject comes

before the Object, it may not be of equal rank. The greater

than symbol is often used for this relation.

gist:hasOrderedMember [IF](gist:orderedMemberOf)

Domain:gist:OrderedCollection

An inverse functional version of

hasMember to ensure that no

OrderedMember can be in more than one

OrderedCollection., which can quickly

lead to problems.

Figure 9: gist Properties This is the complete set of properties in gist, depicted as authored.

Classes: Note that gist is laid out into different topical groups of classes, each a different color

(Figures 6, 7). The major topic areas correspond to basic everyday notions, e.g., now, here,

home, me, us, it, this, must, do and want. The topics that these correspond to, respectively, are:

Time, Place, Landmark, Person, Organization, Stuff, Document, Agreement, Behavior and

Intention. This makes it easier to narrow in on the classes you might be looking for.

The class hierarchy is not depicted directly, but is easily viewed in any traditional ontology tool.

The classes are laid out so that the most primitive ones are on the bottom. They are often used to

define classes that are higher up.

Properties: The properties are arranged into four major hierarchies that are mostly disjoint

(Figures 8, 9). This makes it easier to narrow in on the properties you might be looking for.

COMMON PATTERNS

Here we summarize a few key patterns that we frequently employ in gist.


16

HIGH LEVEL DISJOINTS

First, we have a set of high-level classes that are all disjoint. These are shown below:

gist:Organization

gist:GeoPrimitive

gist:Event

gist:PhysicalThing

gist:Content

gist:Obligation

gist:Intention

gist:ID

gist:Language

gist:Position

gist:Magnitude

gist:UnitOfMeasure

gist:Category


Some of these are familiar and easy to agree on, for example, PhysicalThing (occupies

space and has mass), Event (occurs over a period of time), Person (human being, living or

dead), UnitOfMeasure (e.g., meter). In other cases, we just have to decide and agree:

Intention, Organization and Obligation.

DEFINE CONCEPTS FROM PRIMITIVES

As noted above, two key design goals are to keep the number of primitives small and to use

inference to ensure better ontologies. One thing we do that helps meet both of these goals is to

define concepts in terms of more primitive concepts. For example, consider the following

definitions:

gist:Organization

gist:recognizedBysome gist:CountryGovernment

gist:governssome gist:GeoRegion

Equivalent to

--- AND ---

gist:GovernmentOrganizationEstablished either by fiat (as a conquering

army overtakes a land and declares a

government) or by delegation from a fiat

government, such as a state or local

government or a specific agency. Differ from

corporations in that they cannot be owned.

gist:Person

gist:Organization

Equivalent to

--- OR ---

gist:SocialBeingThis is the Cyc term, if we can, I'd like to think

of something better. Until then this is just the

union of people and organizations. it is a

superset of objects that can enter into

contracts. We're not calling it a party as that is

the relationship to the contract more than the

entity that might be able to enter into one.


17

In e6Tools notation, the shape on the left defines a gist:GovernmentOrganization to be

the intersection of three sets:

1. Organizations

2. Things that are recognized by at least one country government.

3. Things that govern at least one geographic region.

The shape on the right defines gist:SocialBeing as the union of the two sets:

4. Persons

5. Organizations

Some concepts cannot usefully and readily be fully defined in terms of other concepts. For these,

we add axioms that state necessary truths about the concepts to further clarify the meaning. This

usually means using subclass and property restrictions. Consider the definition of

gist:BuildingAddress:

Subclass of

gist:Address

(N) gist:regarding

some gist:Building

gist:BuildingAddress An address that you can send mail to or

that you could find in the physical world.

This states that a BuildingAddress is always an Address, and that the building address is

necessarily regarding (i.e., specifically has something to do with) some Building. The (N) in the

restriction means “necessary.” It is translated into OWL by stating that class

BuildingAddress is a subclass of the restriction “gist:regarding some

gist:Building” (in Manchester syntax).

AVOID ORPHAN CONCEPTS

We have a small number of high-level classes, and whenever we add a new class, we attempt to

fit it into one of the existing high-level classes. We do the same for properties. There are four

main kinds of properties, and the vast majority of gist properties are under one of these. Most of

the properties tend to be disjoint in practice, but we have not forced this.

COMPLEX CLASSES FOR DOMAIN AND RANGE AND FOR RESTRICTION FILTERS

In some cases we want a class to specify a domain or a range or a filter on a restriction, but the

class is abstract and not something you would ordinarily model for its own sake. For example,

the range of the property expressedIn can be either Language or Media. Instead of using

a class called LanguageOrMedia we use a complex unnamed class, as depicted below. It


18

results in the generation of a blank node in OWL.

gist:Language

gist:Media

--- OR ---

Range

gist:expressedIn(gist:usedToExpress)

Domain:gist:Content

Intellectual Property (computer programs,

documents, inventions, etc.) are expressed in

either media or a language and usually both.

In some cases, it might be convenient to use such classes multiple times. Then, it might make

sense to give the class a name in the usual way and reuse it, rather than creating several copies of

what is essentially the same blank node. Sometimes we intentionally don’t give such classes text

definitions because the meaning is clear from the definition. To highlight these classes, we depict

them in the overview diagram (Figure 6) as non-colored shapes with gray or colored borders.

As an example of using such classes as a filter class for a restriction, consider the idea of

something that is Ownable, which in turn is used both to define a ProductOffering and for

the range of guardianOver.

gist:Content

gist:Organization

gist:Permission

gist:PhysicalThing

gist:Money

gist:OwnableThat which can (at least theoretically) be

owned. All current jurisdictions have rules

against owning people, but that needs to

be expressed in rules rather than

definitions.

--- OR ---

gist:guardianOver(gist:hasGuardian)


Range:gist:Ownable

gist:Offering

gist:regardingsome gist:Ownable

gist:ProductOfferingOffering something which could be

warehoused.

--- AND ---

In other cases, we do something very similar, but the class we create is something that is a useful

abstraction that is meaningful to have on its own. For example, we have an owns property and

we want to specify the domain to be either a Person or an Organization. We do this by creating a

complex class as we saw above. SocialBeing is a useful abstraction that is frequently used,


19

for example, as the domain of a property called hasCommunicationAddress.

KEY CLASSES

In this section, we introduce the main classes in gist.

TIME

Humans’ most primitive concept about time is “now.” In gist, we have the following concepts

related to time:

TimeInstant: a point on a timeline with no specified length in universal time. (It might be

instantaneous, but it might also be a date.)

TimeInterval: an interval on a time line has a beginning and end. It has a duration, but it

isn’t a duration.

TemporalRelation: a relationship that holds for a period of time. You could use this to

model the idea of employment, which captures the fact that a gist:Person is in the

myeo:employedBy relationship with a gist:Organization over a period of time.

PLACE AND LANDMARK

A human being’s most primitive notion of place is ‘here.’ It is implemented in GPS devices. We

model [absolute] geographic locations as regions, lines or points on the earth’s surface.

GeoPrimitive: any of the three primary geographical objects: GeoRegion, GeoPoint, or

GeoSegement. Defined as the union of the latter three classes.

We model relative locations too, and the more abstract class Location, which is the union of

relative locations and geographic locations.

RelativeLocation: a place defined as being offset with respect to some origin.

Location: the union of GeoPrimitive and RelativeLocation

There is also the notion of being at or in a place, the most fundamental one being at ‘home.’

Other key places that one may be in or at include:

Landmark: a physical object that has a permanent location, e.g., a building, a lamppost

Building: a human-made structure that is designed for occupancy. Because it also has a

permanent location, it is modeled as a subclass of Landmark. See also (see gist:Artifact

below about human made things).

Room: An enclosed area within a building.

We also have a class that leverages the fact that physical things are sometimes used as proxies

for locations in common usage. For example, we might send something to a geographic region,


20

or we could send it to a building (which occupies a geographic region). The building acts as a

proxy for its location. The class that captures this is:

PhysicallyLocatable: something that can be located in space. It may be an actual

geographic location or something that has a geographic location. It is formally defined as the

union of PhysicalIdentifiableItem and GeoPrimitive.

PERSONS, ORGANIZATIONS AND AGENTS

We represent human beings and living things.

Person: A human being, alive or dead. Not a fictional character.

LivingBeing: Something that is or at some point was alive and growing. A superclass of

Person.

We also represent the very general idea of an organization, leaving it to users to define more

specific kinds as needed.

Organization: A generic organization that can be formal or informal, legal or non-legal.

There are so many kinds of organizations, it is hard to think of anything that applies to them all.

Some don’t even have members. What seems to be true for just about every organization is that it

exists for some purpose. This is not required at this time.

We include some very common organizations: MarriedCouple, UnitedNations,

CountryGovernment and GovernmentOrganization.

SocialBeing: Sometimes it is convenient to talk about a thing that you know is either a

Person or an Organization, but you don’t care which. For example, only Persons and

Organizations can enter into contracts. We capture this abstraction with the class: SocialBeing.

Agent: Similarly, it is sometimes convenient to talk about a thing that you know can perform

some kind of task, but it could be a Person, an Organization or maybe a

ComputerProgram. We created Agent to capture this abstraction.

An agent that is acting onBehalfOf some person or organization is called a

DelegatedAgent.

STUFF, PHYSICAL, NON-PHYSICAL, ARTIFACTS

PhysicalThing: all and only things that take up space and have mass. There are two main

kinds:

PhysicalSubstance: Something that breaks up into pieces that are the same kind of thing,

e.g., water, sand

PhysicalIdentifiableItem: Something whose parts are never the kind of thing as the


21

whole, e.g., building, pencil.

We also allow for non-physical things like Money.

NonPhysicalSubstance: a non-physical thing whose parts are the same kind of thing as the

whole.

Artifact: an artificially created thing that may or may not be physical, but that may be

owned. There is always an intention behind an artifact, the reason it was created, the purpose it is

intended to serve.

The class Ownable captures the idea of anything that can be owned. This includes Content,

Organization, Permission, PhysicalThing, and Money. Note that this allows for a

person to be owned. This is generally not legal, but it is ontologically and socially possible.

CONTENT, DOCUMENTS AND MEDIA

The main class we have is called Content. It includes documents, programs, images, etc. We

also have Media, which is how the content is stored, e.g., paper and hard drives. Specific kinds

of content that we have classes for include:

Message: for example, an email or a letter which is sent from one agent to another.

Text: for when the content is in words.

ComputerProgram: in practice, this is almost always in text, but we do not require it.

Term: description of one or more conditions in an agreement or offer. It may correspond directly

to an obligation (see below).

Address: description of a place that can be located by some routing algorithm and where

messages or things can be sent to or retrieved from. It can be to a physical place (building

address) or a virtual place (email address). There are various kinds of addresses in gist:

TelephoneNumber, ElectronicMessageAddress, BuildingAddress and

PostalAddress.

AGREEMENT, OBLIGATION AND OFFER

Agreements are the bedrock of commerce. Almost all commerce consists of making and

following up on agreements and the obligations inherent in them. Quotes, purchase orders, price

lists, invoices, and even checks are obligations. In gist, an Agreement has two parties and two

Obligations whereby each party is obliged to the other in some way. For instance, a sales

order entails an obligation to ship and an obligation to pay.

An Obligation is a future commitment from one party to another. To track who is obliged to

whom, each obligation has a giver and a getter. There is also the substance of the

obligation, e.g., what you are allowed, required or prevented from doing. These things are


22

covered in the next section on Intention.

An Offer is essentially a one-sided agreement that converts to a two-sided gist Agreement

when the offer is accepted. The product or service for sale is called an Offering. A

ProductOffering is for things that can be inventoried. A ServiceOffering is for

activities that can be performed on the purchaser’s behalf.

EVENT

If agreements are the bedrock of commerce, events are the bread and butter. Anything that

happens corresponds to an Event.

Event: a time interval during which something happened, associated with the doing of some

kind of activity or behavior which is said to characterize the event. We identified three kinds of

events that are particularly important in business:

SpeechAct: A communication event, such as making a commitment, placing an order, making

a request, complaining, issuing a warning or refusing. It need not be oral. People and

organizations can make speech acts, but computer programs cannot.

Movement: The event of something moving along a route from A to B where some Agent does

the moving. The thing moved is Ownable. This excludes things that move on their own, e.g.,

water down a hill.

Conversion: An event where one or more inputs is transformed by an Agent in some way to

produce one or more outputs. Some conversions are physical, e.g., manufacturing; some are not,

e.g., calculation.

INTENTION

This is the teleological part of the ontology, that is, having to do with causes and goals and

reasons for doing things. It is the least validated part of the model. The main class is for

intention, for instance, the reason why you perform a task or project. We also include the classes

for the following closely related concepts: goal, rule, criteria, permission, requirement and

restriction.

OTHER CLASSES: COLLECTIONS, CATEGORIES, POSITIONS, IDENTIFIERS AND LANGUAGE

In addition to the major topics, there are a number of other important concepts. These include

collections, categories, positions, identifiers and language.

CATEGORIES, COLLECTIONS AND POSITIONS

When you are using gist, there are three different ways to create buckets and put things in those

buckets. The default choice is not to use gist, but to use OWL itself by creating a class and

assigning instances to the class. This approach uses the language constructs owl:Class and


23

rdf:type. A special case of this is the use of the ENUM construct, which creates a class with

explicitly named individuals.

A second way to create a bucket and put things in it is to use the class gist:Category and

the property gist:categorizes(categorizedBy) to place individuals into the bucket.

The main inspiration for this class is to be able to represent tags that categorize arbitrary things.

Categories are also sometimes used to represent types of things, e.g., MediaType.

The third way to create a bucket and put things into it arises when you have a collection of things

but you don’t want to use OWL classes and the rdf:type property to track the members.

Examples include:

1. members of a jury

2. a group of documents that need to be tracked

3. a financial report, which is really nothing more than a collection of entries on a ledger.

For this we provide the class gist:Collection with the property

gist:hasMember(memberOf) to put things into the bucket. A collection in gist has at least

one member, and anything that has a member is a collection.

Some collections are ordered, e.g., some items in the collection are in some sense before/after or

greater/smaller than other items. We capture this with a generic ordering property called

precedes(precededBy) which is used to define OrderedMember and

OrderedCollection. It is also used to define the idea of a RankedPosition in a

collection. The idea of a Position is more general than for just collections. An organization may

have an open job position. In general, a Position is a placeholder that may be filled. When it

is filled, it is a FilledPosition.4

IDENTIFIERS

In every business as well as in everyday life, unique identifiers play very important roles, from

your social security number to your car’s license plate to the serial number on your computer.

A gist:ID uniquely identifies something. By unique, we mean that the ID only refers to a

single thing; it does not hold the other way around. For example, if you have dual citizenship,

you will have two unique IDs for tax purposes, one for each country. An ID necessarily has some

text associated with it, and it may also have other information, such as the date created, who

assigned it to the object, etc.

LANGUAGE

We have the general class Language and two subclasses, ComputerLanguage and

4Starting with version 6.7 of gist, some more specialized classes and properties related to collections, and all classes and

properties related to positions, have been moved from gistCore to a “subgist” called gistCollection. It imports gistCore.


24

NaturalLanguage, to distinguish languages that naturally evolve and are used by humans to

communicate vs. formal languages designed for computers.

KEY PROPERTIES

In keeping with the goal to make it easy to find things, we organize gist properties into four

mainly distinct hierarchies (Figure 9). These are described below. A property is used to assert a

relationship between two things. For example, we say that a specific laptop (a

PhysicalThing) is identifiedBy a particular serial number (an ID). Note that the order

is important; the serial number is not identified by the laptop. It is often helpful to give a name to

the property that goes in the other direction. In this case, we can say the serial number

identifies the laptop. As previousely noted, we sometimes indicate the inverse of a property

in parentheses right after it, e.g., identifiedBy(identifies). To keep the order straight,

we refer to the first entity in the assertion as the Subject and the second as the Object. Also, the

property is sometimes referred to as the predicate. See the table below.

Subject Property/Predicate Object

Laptop identifiedBy Serial number

Serial number identifies Laptop

Next we cover the four main property hierarchies:

1. Exclusively having

2. Relating wholes and parts

3. Causality

4. Peer to peer relationships

EXCLUSIVELY HAVING

Properties of this type are such that the Subject in some sense exclusively ‘has’ the Object, so

much so that the very existence of the Object is predicated on the existence of the Subject. Some

common examples include:

1. start and end times of an event: There can be no start time for an event that does not

exist.

2. recordedOn: for recording the date on which something occurred. One cannot speak of

the recording date of something, unless that something exists.

3. identifiedBy: One cannot speak of an identifier for something unless that something


25

exists, e.g., a social security number can only exist if the person to whom it is assigned

exists.

4. hasMagnitude: relates something to e.g. one of its physical properties like weight:

One cannot speak of the weight of Joe Bloggs if there is no Joe Bloggs.

Counter Examples

The properties partOf a whole and memberOf a collection do not fit this pattern because the

parts and the members in general do have independent existence.

RELATING WHOLES AND PARTS

For properties of this type, the subject contains or includes the object in some way, and there is

no restriction that the object’s existence is predicated on the subject’s existence. Examples

include:

1. Mereology: hasPart(partOf)parts of a composite whole, e.g., a wheel is part of a

car, a department is part of a company.

2. Membership: gist:hasMember(memberOf) members of a collection, e.g., a person

can be a on a jury of 12 individuals, a member of a committee or one of a group of

buildings on a campus.

3. Constitution: gist:madeUpOf(madeInto) what things are made of: Relates a

physical object to the kind of physical material it is made up of, e.g., a ring is made up of

some quantity of gold.

4. Spatial containment: gist:geoContains e.g., California includes San Francisco; a

county contains the region a building is on. Loosely, we say the county contains the

building.

CAUSALITY

Properties of this type are such that the subject in some way affects the object. Some common

examples include:

1. influencing and governing: gist:govern the subject controls or inhibits the object in

some way. For example, a government governs a country, a CEO run a company.

Regulatory bodies and police departments have jurisdictions that they control.

2. producing/creating: gist:produce the subject causes the object to come into being.

Examples include having a child, writing a book, minting a new social security number,

drafting legislation. A less obvious example is an election producing the tenure of office

for an elected official.

3. using something up: gist:useUp the subject makes use of the object in some way

and, in the process, affects the object (usually adversely). A wood carver uses up a block

of wood to carve a statue; a project uses up time resources of the workers on the project.

This excludes using things that do not affect the thing in any substantial way (using a


26

pencil, a laptop).

4. justification: gist:basisFor(basedOn) the reason, law, etc. that is the basis for

some action of decision. The basis for getting life imprisonment is the law regarding first

degree murder. Details of a specific purchase from a contracted vendor are justified by

the contract in place.

5. to prevent, allow or require: gist:prevent(preventedBy),

allow(allowedBy), require(requiredBy) the subject restricts, allows or

requires some behavior, e.g., law prohibits one from running a red light; tax law permits

one to take tax deductions for dependents.

PEER-TO-PEER RELATIONSHIPS

All three of the above major property hierarchies have the subject being super-ordinate to the

object, albeit in different ways. The final major category of properties is for peer-to-peer

relationships where neither subject nor object is super- or sub-ordinate to the other. This is rather

broad and covers a lot of territory, a somewhat catch-all group of properties. Some broad

categories and examples include:

1. participation: A subject, which can be almost anything, plays some role in, e.g., an event,

or agreement. For example,

a. parties to agreements, e.g., buyer and seller

b. inputs and outputs of processes, gist:input(inputOn)

output(outputOn)e.g., raw materials and final product

c. to and from roles, e.g., a shipment of goods

i. from one place to another place

gist:fromPlace(placeFrom) & gist:toPlace(placeTo)

ii. from one person or organization to another

gist:fromAgent(agentFrom) & gist:toAgent(agentTo)

d. locations, e.g., where an event occurred gist:occurredAt(occurrences)

2. precedence and ordering: gist:precedes(precededBy) we have a precedence

relationship that can place things in a certain order.

3. allocation: gist:allocatedTo(hasBeenAllocated)something can be reserved

or set aside for some specific purpose, e.g., resources on a project.

4. delegation: gist:delegatesTo(onBehalfOf) one agent can delegate

responsibility to another

5. descriptives: a major sub-category of peer-to-peer relationships is where one item in

some way describes the other. The top-level property in this sub-category is called

gist:regarding. Some examples are:

a. hasStreetAddress(streetAddressOf) & gist:

hasCommunicationAddress(communicationAddressOf) having an address of


27

some type

b. relating Content, e.g., an article or document, to

i. gist:about(describedIn) real things in the world that are being

talked about,

e.g., a hurricane or a city

ii. gist:expressedIn(usedToExpress) the language or media in

which it is expressed

c. gist:categorizedBy(categorizes) relating something to the category

it is in.

USING GIST

In the section “Introduction: Using Gist:,” we highlighted two main tasks that are the nuts and

bolts of using gist:

1. mapping your concept to a gist concept

2. extending a gist concept to meet your needs.

We showed how the gist design principles support performing the first of these tasks. In this

section, we summarize the overall process of using gist, and provide a few tips, guidelines and

examples.

USAGE SCENARIOS

Before you start on either of the above two tasks, you need to consider the broader architectural

context in which you will be using gist. There are three main options, listed below in order of

decreasing degree of commitment and potential value.

1. Direct Extension: import gist into your ontology as the starting point. Use as many

concepts as you can that are directly relevant. Where new concepts are needed, make a

concerted effort to place them in the appropriate place in the gist class or property

hierarchy.

2. Mapping: create a new [bridging] ontology that imports gist as well as the ontology you

are building, and map concepts from one to the other.

3. Inspiration: examine the modeling decisions we made, and use these insights to inspire

design decisions for your ontology.


28

Each approach can save you time in building your ontology, and can lead to a better ontology.

Which approach is best for you depends on how closely the gist view of the world matches the

one you need for your enterprise.

When you use the direct extension approach to develop enterprise ontologies (as we do for our

clients) you get the most benefits. You just import gist and get started. You get the full benefit of

consistency checking from the inference engine. You also get the benefits of newer versions of

gist as they are released. It could make sense for you if you accept the gist view of the world and

can work with all the axioms. One potential downside is if you change your mind later and start

to disagree with things that gist has. Or gist could evolve in a way that you did not agree with. In

the latter case, you are still protected, because you have the option of just using the copy of gist

you have, and not using new versions. This is a tradeoff.

The mapping approach might be more appropriate if there are many things in gist that you agree

with, and also some important things that you do not agree with. You just map to the things you

agree with, and ignore the rest. This gives you partial benefits from inference and consistency

checking and allows you to have more independence and control. The downside is you do not get

all the benefits of inference and consistency checking.

The last approach (inspiration) could make sense if you had major disagreements with some of

our high-level decisions that are so basic to gist that you cannot just make a few changes and

smooth over the differences. Nevertheless, you may still derive benefit from gist in specific

areas, by adapting what we have done to the different fundamental design choices you have

made. In fact, other upper ontologies can also be useful for this. We recommend using other

upper ontologies for inspiration also, in cases where gist does not suit your needs.

SOME SIMPLE EXAMPLES

Here we look at a few examples of how you would use gist to build your enterprise model. In a

future whitepaper, we go into much more depth on how this works.

Let’s say you are building an enterprise ontology for a healthcare organization5. Two of the most

5 See Building Enterprise Ontologies: Report from the trenches at the 14 min mark for a model of hospitals.

http://www.youtube.com/watch?v=lbR8UzlF9B8&list=PLA_PbqRGYBCFApiBWxVs_r3quMVjzhlxb&index=12&feature=plpp_video


29

central concepts are hospital and patient. Let’s consider hospital first. The question to ask is:

“What class in gist is closest in meaning to a hospital?” First, let’s get clear on what a hospital is.

It is not just a building; a single hospital can be spread across many buildings. Conversely, more

than one hospital can occupy a single building. In fact (at least in the US), a hospital is an

organization licensed to deliver health care. So, we look at the classes overview/index (Figure 6)

and skim to see if there is anything related to organization. The light blue column in the middle

has what we need. We decide that a hospital is a specific kind of organization, so we create a new

class called myeo:Hospital and make it a subclass of gist:Organization. We also

want to be able to say that a hospital occupies one or more buildings, so we need the idea of a

building. Fortunately, the class gist:Building is already there.

For patient, we do the same thing. We decide exactly what concept we want to model that we are

going to call ‘Patient.’ We might conceive as a patient as a role played or filled by a person, or

we might conceive the patient as a kind of person. We will adopt the latter, simpler approach.

Again, we scan the classes overview/index and see a major topic area in red called Person. We

create a class called myeo:Patient and make it a subclass of gist:Person.

We now want to connect hospitals to buildings and patients. Let’s start with buildings. The first

thing to decide is what the relationship is that connects a hospital to a building. The hospital may

own the building or they may be renting or leasing space in it, which are all different. What is

common for all three is that the hospital has permission to and does in fact carry out its business

operations in the building. This is very much like a person living in a building or apartment,

whether or not they own it. This relationship between a person or organization and a building is

that they are occupying the building. There is already a property in gist for this:

gist:occupantOf(hasOccupant).

Finally, let’s see how to connect hospitals to patients. As is often the case, there are various ways

to do this. One could explicitly model a patient visit as an event. A simpler option is to have a

property that associates a patient with a hospital if that patient is planning to receive, is currently

receiving, or has already received care from that hospital. We might call that property

myeo:giveCareTo(myeo:receiveCareFrom). We now want to see if there is already a

property in gist for this. Given that gist is not specific to any industry, we will not expect to see

something related to healthcare. Instead, we look to see which of the four main property

hierarchies it may belong to. We ask the following questions:

1. Is the existence of the hospital giving care predicated on the existence of the patient

receiving care, or vice versa?

2. Does the hospital giving care to a patient mean in some sense that the hospital in some

sense includes or contains the patient – or vice versa?

3. Does the hospital giving care to the patient mean that in some way the hospital affects the

patient?

4. Is the hospital giving care more or less a peer of the patient, or is one sub-ordinate to the

other?

For 1, the answer is clearly no. No specific patient will cease to exist if the hospital ceases to

exist, whereas the edge of a table immediately ceases to exist if the table ceases to exist. Do not

be confused by the fact that in general hospitals will not exist for long if there are not patients.


30

For 2, we might notice that when a patient is in a hospital, then the hospital is spatially

containing the patient, but that is a separate thing from delivering care. In fact, some forms of

care related to a hospital stay can be delivered over the phone, by email, etc. The act of

delivering care does not itself necessarily mean that the hospital in any sense contains the patient.

For 3, there is a plausible match: the patient is certainly affected by the stay in the hospital. If

they are lucky they will get better and not catch a nasty bug.

For 4, it seems that the hospital may be in some sense super-ordinate to the patient, in that it is in

control, giving the patient some care. So this not a strong candidate.

The best match here seems to be 3. Next, we look to find the best place in that property hierarchy

for myeo:giveCareTo. Scanning the list, none of gist:produce, useUp, basisFor,

hasGoal, governs, cause, prevent and allow seem a particularly good fit. Sometimes

you need to look at the definitions. We see that governs means “to inhibit or control” in some

way. This is pretty general and seems to be a reasonable fit for the delivery of care. So we make

myeo:giveCareTo a subproperty of gist:governs.

EVOLUTION OF GIST

MANAGING DIFFERENT VERSIONS

We are actively evolving gist, and will continue to do so. We recognize though that if you are

using gist, any change involves a risk that something you had depended on no longer works as

you intended. Alfred North Whitehead said, “The art of progress is to preserve order amid

change and to preserve change amid order.” Here’s our approach to evolving gist.

Versions:

All changes from the previous version will be documented in the change log, each entry

indicating which version the change was made in. The larger changes are further documented

in supplementary notes.

We categorize each change depending on the nature and degree of impact. Purely visual

changes that only affect layout in Visio have the least impact. Backwards incompatible

changes have the most.

Some versions referenced in the change log are internal only. The last public version before

6.6 was 6.2; there was no public release of 6.3, 6.4 or 6.5.

Every ontology will have a version number, e.g., gistCore6.6. Once published, the ontology

will not change. When gist changes, it will have a new version number. The old one will

always be available.

The version URI and the base URI are identical. This is the most conservative position right

now. Not all tools recognize version IRIs.

Deprecation:

We use the OWL2 deprecation mechanism which allows keeping around things that have


31

been removed while annotating them as being deprecated. We have a separate section of the

ontology for this (see Figure 10). Importantly, it also includes axioms that have been

removed. NB: there is no OWL mechanism for indicating deprecated status of axioms.

There are four common deprecation patterns: remove property, rename property, remove

class, and rename class. Rename is equivalent to a remove and an add.

Tool support for deprecated concepts varies, so if you are starting from a clean slate and do

not need the deprecated items for backward compatibility, we will have a separate version

that has been cleaned of the deprecated things called, e.g., gistCore6.7c.owl. This may

change as tool support evolves.

From time to time there will be changes that are not backward compatible even using

deprecation. In these cases, we will provide supplementary notes with guidelines on how to

manually bring your ontology up to date.

Deprecated things will stay around for one version only and be gone in the next, i.e., a class

in version N that is deprecated in version N+1 will be gone in version N+2.

WHAT WE ARE WORKING ON NOW

gist is undergoing active use and development. While most of it is fairly stable, certain things

continue to evolve. Currently there are two main thrusts:

1. improving the documentation and overall clarity

2. improving accuracy and elegance.

Clarity and documentation:

We are improving the consistency of naming, adding clearer text documentation for each

concept, and creating more examples illustrating how to use gist classes and properties. Some of

this will be in the ontology itself, and some will be manifest in a series of whitepapers of which

this is the first. Future whitepapers will address the following topics:

1. Technical details of how to use gist (adding depth to the material in this document)

2. Case studies where gist has been used

3. Comparing gist to other upper ontologies.

Accuracy and elegance:

We are going over every concept with a fine-toothed comb and fixing any issues we find. Some

areas need a bit of attention and re-work; e.g., in the area around intention. We will also identify

classes and properties that have proven to get little use and remove them from the core. Only

when there is nothing more to take out could gist ever be ‘finished.’ We may also add a very

small number of concepts that have proven their utility in a number of enterprise ontologies.


32

KEY for Change Log

V: Visio/Vsualization changes only, not affect the owl (callouts, layout, grouping etc)

CL: for clarity only, better comments, fixing typos, laying out differently, etc.

AD: purely additive, will not affect anything already existing.

RF: refactoring, no semantic import. Includes changing names where old name is deprecated.

SU: has semantic import from usage perspective, e.g. a comment changes usage which could give semantic errors.

SI: has semantic import from inference perspective. axiom added, removed, changed etc.

BI: Backwards incompatible

Process for Deprecation

Find all occurrences of the item to be deprecated, and make the

necessary changes. Often it is just a simple name change, but each

case should be carefully considered.

It is harder to find all references in comments and URIs, but try

anyway. Run this SPARQL query to get all the comments into a text

file then search that.

SELECT ?Thing ?Comment

WHERE {?Thing rdfs:comment ?Comment}

e.g. I would never have found gist:GeoPrimitiveOrProperty so I could

change it to gist:GeoPrimitiveOrOwnable, had I not done this.

Save out new versions of any affected ontologies.

Put the deprecated item here in this area of gistCore.

Bring over any axioms that were originally there, but are no longer

needed.

Load gist complete. Check that there are no other occurrences of the

deprecated item besides the one right here. Make sure the deprecated

items it appear and that they are correctly related to the non-

deprecated things in gist core.

Deprecated URIs and Axioms

gist 6.7 Change Log & Deprecated Concepts Deprecation Patterns

gist:newProperty

(gist:newPropertyInverse)

owl:deprecated true

gist:oldProperty

(gist:oldPropertyInverse) oldProperty comment

gist:newPropertyInverse

owl:deprecated true

gist:oldPropertyInverse

Renaming an existing property

and its inverse.Renaming an existing class.

Equivalent to

gist:NewClass

owl:deprecated true

gist:OldClass Deprecated use gist:NewClass. Renamed

for clarity.

owl:deprecated true

gist:oldProperty

(gist:oldPropertyInverse) oldProperty comment

owl:deprecated true

gist:oldPropertyInverse gist:superproperty

Removing an existing property

and its inverse.Removing an existing class.

Subclass of

gist:SuperClass

owl:deprecated true

gist:OldClass OldClass comment

The original

subproperty, if

there was one.

The original

superclass, if

there was one.

These patterns are not ‘live’

to copy paste live ones, go

to the depracation tab.

Evolving gistOur intention is to continue to evolve gist. We recognize though that if you are using gist, any change involves a risk that something you had depended on no longer works as you intended. Alfred North Whitehead said: “The art of progress is to preserve order amid change and to preserve change amid order”. Here’s our approach to evolving gist.

VERSIONS

All changes from the previous version will be documented in the change log, each entry indicating which version the change was made in. The larger changes are further documented in supplementary notes.

We categorize each change depending on the nature and degree of impact. Purely visual changes that only affect layout in Visio have the least impact. Backwards incompatible changes have the most.

Some versions referenced in the change log are internal only. The last public version before 6.6 was 6.2; there was no public release of 6.3, 6.4 or 6.5

Every ontology will have a version number (e.g. gistCore6.6). Once published the ontology will not change. When gist changes, it will have a new version number and the old one will always be out there.

We will have the version number as the base URI as well as the version URI. This is the most conservative position right now. Not all tools recognize version IRIs

DEPRECATION

We use the OWL2 deprecation mechanism which allows keeping around things that have been removed while annotating them as being deprecated. We have a separate section of the ontology for this. Importantly, it also include axioms that have been removed – NB there is no OWL mechanism for indicating their deprecated status.

There are two main kinds of situations where deprecation is needed for a class or property: remove and rename. The latter is equivalent to a remove and an add. This gives rise to four common deprecation patterns.

Deprecated things will stay around for one version only and be gone in the next. So a class in version N that is deprecated in version N+1 will be gone in version N+2.

Tool support for deprecated concepts varies, so if you are starting from a clean slate and do not need the deprecated items for backward compatibility, we will have a separate version that has been cleaned of the deprecated things (called e.g. gistCore6.6c.owl). This may change as tool support evolves.

There will from time be changes that are not backward compatible even using deprecation. In these cases, we will provide supplementary notes with guidelines on how to manually bring your ontology up to date.

6.7 6/14/2012 SI: (MFU) Removed range from input and output properties. Too restrictive.

6.7 6/14/2012 CL: (MFU) Improved comment on GeoRegion so region not confused with geopolitical entity.

6.7 6/25/2012 RF: (MFU) Renamed 'wordsOfLanguage' to 'usedToExpress' (more meaningful name).

Should have been changed on 4/4/2012.

6.7 4/4/2012 RF: (MFU) Renamed 'thingsCategorized' to 'categorizes' (consistent naming).

Should have been changed on 4/4/2012.

6.7 8/28/2012 RF: (MFU) Made owl:Thing the Filter Class for all unqualified cardinalities. e6 workaround.

6.7 9/16/2012 CL: (MFU) Changed comment for Address, expand meaning to include getting from.

6.7 10/16/2012 CL: (MFU) Added comment for OrderedCollection

6.7 10/22/2012 SI: (MFU) Made supercede and produceOffspring properties asymmetric.

6.7 10/23/2012 AD/CL: (MFU) Made gist:allocates a subproperty of connectedTo, added a comment and an inverse (oversight)

6.7 10/23/2012 SI: (MFU) Replaced allocatedFrom with allocatedBy in restrictions for Category and ID (oversight)

6.7 10/24/2012 RF: (MFU) Removed AgreementOrObligation, not being used in gistCore any more (oversight)

6.7 10/24/2012 RF: (MFU) Converted MediaOrLanguage and GeoPrimitiveOrOwnable to Bnodes

6.7 11/1/2012 SI: (MFU) geoContains Range is now GeoRegion (bugfix)

6.7 11/1/2012 SI: (MFU) create hasPhysicalLocation and hasPermanentLocation properties (bugfix)

6.7 11/1/2012 SI: (MFU) replace the property permanentGeoContains with hasPermanentLocation (bugfix)

6.7 11/1/2012 SI: (MFU) change restriction in ID to be allocatedBy some Agent

6.7 11/1/2012 RF: (MFU) Remove Domain and DomainID (move to Organization subgist)

6.7 11/1/2012 SI: (MFU) move baseUnit property from hasA to regarding (bugfix)

6.7 11/1/2012 AD: (MFU) Add Requirement class and require property, analogous to Permission and Restriction

6.7 11/5/2012 AD: (MFU) Added TemporalRelation (was in a subgist)

6.7 11/5/2012 RF: (MFU) Moved hasEvidence(evidencedBy) and Signature out of gistCore

6.7 11/5/2012 SI: (MFU) Remove Signature restriction on Agreement class and change comment accordingly.

6.7 11/5/2012 RF: (MFU) Renamed Rule to ARule to avoid conflict with Rule as a common keyword.

6.7 11/5/2012 SI: (MFU) Replace hasJurisdictionRegion with the more general hasJurisdiction, change domain/range.

6.7 12/13/2012 BI: (MFU) Removed ObligationOrRule class and the three restrictions using it

(Restriction, Permission and Requirement).

6.7 12/12/2012 RF: (MFU) Move a number of classes and properties related to Collection and Position

to new Collection subgist which is now imported by Organization and Measure subgists.

6.7 12/16/2012 SI: (MFU) ARule no longer a subclass of Criteria

6.7 12/13/2012 SI: (MFU) Broadened definition of Template which was too restrictive. More restrictive definition used in Event

subgist.

6.7 12/27/2012 AD: (MFU) Added precedes and hasOrderedMember properties and OrderedMember class.

Used in a new way to define OrderedCollection.

6.7 12/29/2012 CL: (MFU) Improved layout of start/end planned/actual properties

Change Log for next version

6.3 8/10/2010 (MFU) replaced directlyRecognizedBy with recognizedBy in GovernmentOrganization restriction

6.3 8/10/2010 CL: (MFU) Removed all location fields on imports, only used by Jena.

6.4 8/10/2010 RF: (MFU) moved Units stuff into new tab in gistcomplete

6.4 8/10/2010 RF: (MFU) removed and deprecated the singleton BaseUnit subclasses.

6.4 8/10/2010 SI: (MFU) Changed the restriction type from some to has for the xxxUnit classes.

6.4 8/10/2010 SI: (MFU) Changed the type of the unit instances to be gist:BaseUnit.

6.4 8/10/2010 SI: (MFU) Made all the base unit individuals different from each other.

6.4 8/10/2010 RF: (MFU) Created CoreBaseUnit as an (AllDifferent) ENUM of the base units in gist core.

6.4 8/11/2010 SI: (MFU) changed range of hasJurisdictionRegion

6.4 8/11/2010 RF: (MFU) Deprecated and changed name of hasBiologicalParent to produceOffspring.

6.4 8/11/2010 V: (MFU) removed erroneous gist:test default label

6.4 8/24/2010 SU: (MFU) changed hasA coment to say exclusive.

6.4 8/25/2010 CL: (MFU) took "contain or include" out of hasA comment.

6.4 8/25/2010 SI: (MFU) made contains new top of 'part' family, added madeUpOf and hasMember

6.4 8/25/2010 SI: (MFU) regarding is now a subproperty of connectedTo, new comments.

6.4 8/25/2010 CL: (MFU) Changed comment for characterizedAs

6.4 8/25/2010 SI: (MFU) Changed Doman of characterizedAs to Event

6.4 8/26/2010 SI: (MFU) (Bug) Changed filter class on UnitOfMeasure restriction to BaseUnit.

6.4 8/26/2010 CL: (MFU) Re layed out classes

6.4 9/12/2011 SI: (MFU) Removed Collection from high level disjoints.

6.4 9/19/2011 AD: (MFU) Added gist:PhysicalThing defined as Union of PhysicalIdentifiableItem and Substance

6.4 9/19/2011 SI: (MFU) Replaced gist:Substance with gist:PhysicalThing in high level disjoints

6.4 9/19/2011 SI: (MFU) Replace filter class in affects restriction in PhysicallyMove and PhysicallyConvert to be PhysicalThing

6.4 9/19/2011 RF: (MFU) Deprecated and changed the name of Substance to PhysicalSubstance.

6.4 10/21/2011 (DMc) put version number in the version URI

6.4 10/21/2011 (DMc) Changed definition of Room to be identifiedBy:ID instead of PII (bugfix).

6.4 10/21/2011 (DMc) changed toPlace and fromPlace to have a range of PhysicalLocatable to include buildings (and I guess

moveable objects as well)

6.4 10/29/2010 BI: (MFU) Removed restriction for gist:Organization so that it is a generic organization, not a legal organization.

6.4 10/29/2010 RF: (MFU) Replaced gist:Organization in Marriage and UnitedNations with the restriction removed from

gist:Organization.

6.4 10/29/2010 RF: (MFU) Remove Organization from being subclass of Corporation and GovernmentOrganization

6.4 10/29/2010 SI: (MFU) replaced gist:Corporation with gist:Organization in definition of Ownable.

6.4 10/29/2010 RF: (MFU) deprecated and renamed gist:Property to gist:Ownable

6.4 10/29/2010 CL: (MFU) Added comment to gist:Domain

6.5 10/17/2011 BI: (MFU) Major changes to how Events and Behaviors are modeled and naming conventions. See release

notes.

6.5 10/17/2011 SI: (MFU) Changed restriction on gist:Domain to be "allocates some gist:ID"

6.5 10/25/2011 SI: Changed restriction on GeoRoute to be hasDirectPart some gist:GeoSegment.

6.5 2/1/2012 SI: (MFU) Bugfix. Added new inverses for transformTo and transformFrom

6.5 2/1/2012 SI: (MFU) (Oversight) MarriedCouple and UnitedNations are now subclasses of Organization

6.5 2/1/2012 SI: (MFU) (Oversight) Room is now a subclass of PhysicallyLocatable

6.5 2/1/2012 SI: (MFU) Moved Volume stuff back here from units in gist complete.

6.5 2/1/2012 SI: (MFU) Changed range of currencyValue from float to decimal.

6.5 2/1/2012 SI: (MFU) Changed all other occurrences of float to double (except for range of decimalValue).

6.5 2/1/2012 SI: (MFU) Changed all occurrence of string that should be dateTime to dateTime. xsd:date and xsd:time still

don't work for inference.

6.5 9/28/2011 CL: (MFU) Added and changed several comments: name, regarding, Criteria and Event

6.5 3/1/2012 CL: (MFU) Tidied up change log, put in some missing entries.

6.6 3/2/2012 RF/CL: (MFU) Moved ratio unit and percentage back to core from unit subgist. Tidied up layout.

6.6 3/2/2012 RF: (MFU) Added gist:input and gist:output to use instead of gist:transformFrom(To). Several steps, see

release notes.

6.6 3/11/2012 V: (MFU) Created locked Grouping layer for for colored boxes and labels. Makes it easie to select things.

6.6 3/11/2012 V: (MFU) Created Comments layer for callouts (non-printing by default)

6.6 4/3/2012 RF: (MFU) Renamed 'allocatedFrom' to 'hasBeenAllocated' (more meaningful name).

6.6 4/3/2012 V: (MFU) Moved Location, RelativeLocation and Origin to Place column

6.6 4/4/2012 V: (MFU) Swapped order of Stuff and Organization columns

6.6 4/4/2012 RF: (MFU) Renamed 'wordsOfLanguage' to 'usedToExpress' (more meaningful name).

6.6 4/4/2012 RF: (MFU) Renamed 'thingsCategorized' to 'categorizes' (consistent naming).

6.6 4/4/2012 RF: (MFU) Renamed 'realizedIn' to 'characterizes' (consistent naming).

6.6 4/4/2012 RF: (MFU) Renamed 'AgentOnBehalfOf ' to 'DelegatedAgent' (more natural name).

6.6 4/4/2012 RF: (MFU) Removed CoreBaseUnit, no longer needed.

6.6 4/24/2012 RF: (MFU) Removed all Behavior subclasses and uses of gist:characterizedAs. Put into a new behavior

subgist.

6.6 4/24/2012 RF: (MFU) Removed all but three Events, moved the rest to a new behavior subgist. This included removing

Decision, used for the Deciding event. In effect renamed Speaking to SpeechAct, which was a Behavior in 6.2. Renamed Converting

to Conversion and Moving to Movement.

6.6 4/25/2012 SI: (MFU) Remove produce some Convert restriction from ComputerProgram. The execution event produces

the Conversion.

6.6 4/24/2012 V: (MFU) Changed Behavior column label to Event.

6.6 4/24/2012 V: (MFU) Changed some topic headings from plural to singular.

6.6 4/24/2012 V: (MFU) Moved Artifact to Stuff column, shifted a bunch of things around to make fit.

6.6 4/24/2012 V: (MFU) Chaned layout of some classes so that the superclass is always on the top of the subclass shape.

6.6 4/30/2012 RF: (MFU) Removed default namespace.

6.6.1 5/16/2012 SI: (MFU) Fixed deprecation annotations, added two that were missing.

Change Log

Renaming wordsOfLanguage to

usedToExpress.

owl:deprecatedtrue

gist:wordsOfLanguage

gist:usedToExpress

Renaming thingsCategorized to

categorizes.

owl:deprecatedtrue

gist:thingsCategorized

gist:categorizes

Removing AgreementOrObligation

& ObligationOrRule

gist:Agreement

gist:Obligation

owl:deprecatedtrue

gist:AgreementOrObligation

--- OR ---

gist:Language

gist:Media

owl:deprecatedtrue

gist:MediaOrLanguage

--- OR ---

Removing MediaOrLanguage &

GeoPrimitiveOrOwnable

(using Bnodes instead)

gist:Ownable

gist:GeoPrimitive

owl:deprecatedtrue

gist:GeoPrimitiveOrOwnable

Used for Range of object property

--- OR ---

Removing

permanentGeoContains

and its inverse.

Subclass of

gist:ID

owl:deprecatedtrue

gist:DomainIDThe ID of an agent or an artifact that sets up the

context within which IDs are meant to uniquely

refer to one item.The US Social Security Admin

is a domain which is supposed to assure that a

given Social Security Number refers to a single

person. Could also be a next avail number

routine. gist:Agent

gist:allocatessome gist:ID

owl:deprecatedtrue

gist:DomainAn Agent that is responsible for issuing unique

IDs in its scope.

--- AND ---

owl:deprecatedtrue

gist:hasEvidence(gist:evidencedBy)

Range:gist:Signature

Evidence of authentication or agreement.

gist:hasA

(N) gist:hasEvidencesome gist:Signature

gist:Agreement

Adding back a

removed axiom.

Subclass of

gist:Content

owl:deprecatedtrue

gist:SignatureEvidence of agreement or authentication; could

be an electronic signature or a reference to a

wet ink signature.

Moving Signature & hasEvidence

(Moved to Agreement subgist.)

Renaming Rule to ARule

(to avoid conflict with “Rule” as a common keyword)

Equivalent to

gist:ARule

owl:deprecatedtrue

gist:RuleDeprecated use gist:ARule. Renamed to avoid

conflict with "Rule" as a common keyword.

owl:deprecatedtrue

gist:hasJurisdictionRegion(gist:regionPresidedOverBy)

Domain:gist:GovernmentOrganization

Range:gist:GeoPrimitiveOrOwnable

gist:hasJurisdiction(gist:presidedOverBy)


owl:deprecatedtrue

gist:regionPresidedOverBy NB this inverse is made up because it was the

same as the one now used for hasJurisdiction.

Generalizing hasJuristictionRegion

(unnecessarily specific).

gist:Obligation

gist:Rule

owl:deprecatedtrue

gist:ObligationOrRule

--- OR ---

owl:deprecatedtrue

gist:evidencedBy

Collections and Positions

(Moved to Collections subgist and updated.)

gist:Collection

gist:hasAsome gist:InclusionCriteria

owl:deprecatedtrue

gist:IntensionalCollection

--- AND ---

Subclass of

gist:Collection

(N) gist:hasMagnitudesome gist:Count

owl:deprecatedtrue

gist:ExtensionalCollectionA collection defined by a set of explicitly

named members. The hasMagnitude Count

refers to the number of members.

Collections and Ordering

Subclass of

gist:Criteria

owl:deprecatedtrue

gist:InclusionCriteriaRules for including something in an

intensional set (could be OWL, but could be

SQL or just natural language).

gist:Position

gist:Organization

gist:GeoPrimitive

gist:Content

gist:UnitOfMeasure

gist:Magnitude

gist:Event

gist:PhysicalThing

gist:Obligation

gist:Intention

gist:ID

gist:Language

gist:Category


This is just

adding Position to

all the disjoints.

Might be a better

way.

Positions

Subclass of


owl:deprecatedtrue

gist:OrdinalCollection An ordinal collection is ordered, but has the

additional property that the ordering

represents a "greater than" relationship.

Amazon uses an ordered collection for rating

the quality of used books (Unacceptable,

Acceptable, Good, Very Good, Like New,

New). If you do a query to get the lowest

price for a particular book in the "Good"

category, you will get only "Good" ones. If

the collection were an ordinal collection, you

could get the lowest price on all the items

"Good" or greater.

gist:ExtensionalCollection

gist:hasDirectPart

some gist:RankedPosition


--- AND ---

owl:deprecatedtrue

gist:Position Placeholder in a collection or an organization

for someone or something. A slot.

gist:sequence

some integer

gist:Position

owl:deprecatedtrue

gist:RankedPosition A position in a collection where the position is

ordered. It is the responsibility of the

collection to maintain the ordering, but the

position has an order feature.

--- AND ---

gist:Position

gist:hasIncumbent

min 1

owl:deprecatedtrue

gist:FilledPosition

--- AND ---

owl:deprecatedtrue

gist:hasIncumbent(gist:incumbentOf)

Domain:gist:Position This is to relate something ephemeral (a

position) with something potentially more real

(i.e., an employee).

owl:deprecatedtrue

gist:incumbentOf

This is the old

definition.

gist:geoDirectlyContains

owl:deprecatedtrue

rdfs:commentNOTE: the subproperty link to

geoDirectlyContains has been removed. It

causes an error with the new way to represent

permanent locations.

gist:permanentGeoContains

(gist:permanentGeoContainedIn) This is for things attached to the earth.

Permanent is a relative term, but it is more than

saying a car is in a particular city, it's more that a

building or tree, or lake is (they don't move very

often).

owl:deprecatedtrue

gist:permanentGeoContainedIn

Figure 10: Evolution of gist

CONCLUSION

gist is an upper ontology for business. It will help you build better ontologies faster, for your

enterprise. It has been designed to have “everything you need and nothing you don’t,” i.e., every

concept that is important in the majority of business enterprises. It is intentional that we leave out

a lot of detail.

Compared to other upper ontologies, gist is a good choice for commercial use because it roots

are in business, not academia. It strikes an appropriate balance between being rigorous enough to

support automated reasoning and simple enough to be easy to learn and use. This is one reason it

is being used commercially. Finally, gist is actively evolving, so you will not be left on your

own.


33

ABOUT THE AUTHORS

MICHAEL USCHOLD

Michael F. Uschold, Ph.D. is an internationally recognized expert with 25

years experience in developing and transitioning semantic technology from

academia to industry. Michael pioneered the field of ontology engineering, co-

authoring the first paper and giving the first tutorial on the topic in 1995. This

leveraged the work he did in creating the influential “Enterprise Ontology.” He

spent 11 years at Boeing defining, leading and participating in numerous

projects applying semantic technology to enterprise challenges. Michael is a

regular invited speaker and panelist at national and international events, and has

given numerous tutorials and training classes. He received his PhD in Artificial

Intelligence from The University of Edinburgh in 1991.

DAVE MCCOMB

Dave McComb is President and founder of Semantic Arts, Inc. His focus is on

project management and business applications, as well as bringing an overall

enterprise architecture approach to the firm’s engagements. He has nearly 30

years of experience managing multi-million dollar development projects for

major clients including: Georgia Pacific, Boise Cascade, Norton Abrasives,

Wildish Construction, US Geological Survey, Trus Joist, Far West Federal

Savings and Loan, Haw Par Trading (Singapore), Bougainville Copper, US

West Materiel Resources, Colorado Department of Transportation, Martin

Marietta, Johns Manville, Micro Planning International, BSW Architects, Dean

Medical Center, Velocity.com, World Minerals, CommerceOne and the

Washington State Department of Labor & Industries.

SEMANTIC ARTS

Semantic Arts is a boutique IT consulting firm specializing in Semantic

Technology and enterprise IT architecture design. We help our clients remove

complexity from their information systems, so you can

Make small changes economical.

Make large changes possible.

Reduce the risks of systems migration.

Learn more about us by visiting our website at www.semanticarts.com.

http://www.semanticarts.com/