LEXICON ON ONTOLOGIES

Lexicon on ontologies

Together with the OWL documentation manual, this lexicon forms the tutorial for the ontology.

It is 4 single-sided A4-pages long and learning them is a bargain for the return one gets by exploring the ontology.

Further development will be in the field of querying the ontology.

Annotations (annotation properties)

Annotations are properties of classes, class properties, data properties and the ontology itself.

Typical annotations are:

labels: form an easy human readable alternative for the name of objects which have to be 1 continuous sequence of signs.
They can be used to translate in different languages the human readable name of the object.
comments: when applied to the ontology itself, it contains mostly the context in which the ontology is drawn, when applied to other objects, they comment on the meaning and usage of the object
see also: reference to other documents, e.g. in the form of a hyperlink
version information on the level of the ontology
author & right information

Annotations are provided in many formats: strings, numeric, hyperlinks,...

Asserted hierarchy

The hierarchy which is explicitly defined. See also inferred hierarchy.

Cardinality

When considering the properties, one can specify the number of values for a specific relation.

E.g. A financial instrument should have no more and no less than 1 issuer.

The restriction shall be hasPartyIssuer exactly 1 for the class FinancialInstrument.

Classes

All classes are concepts, which can however have physical aspects.

Classes are grouping kinds of individuals, called instances, which are grouped with common definition-levels and relations.

Classes are called entities in ontology philosophy.

Closure Axiom

See under Property Scope.

Clouds

Representation of data in a font size according to quantifications applied on the data.

In OWL-documentation it is standard according to the usage.

For classes this relates to the number of individuals in the class.

Covering Axiom

If a class A is a superclass of other classes, it is not necessary for any individual of class A to be an individual of the subclasses.

Such an individual could be simply loose between the subclasses.

If such situation has to be avoided we create an anonymous class which makes the subclasses cover the full of class A.

E.g. MoodysLongTermCreditRating has 3 subclasses: MoodysInvestmentGrade, MoodysNon-InvestmentGrade and MoodysSpecialGrade. To be sure each individual member of MoodysLongTermCreditRating falls under one of the 3 subclasses a covering axiom is introduced for the class:

MoodysInvestmentGrade or MoodysNon-InvestmentGrade or MoodysSpecialGrade

Context

The context in which the statements are valid.

Risk shall have a different meaning in a finance ontology compared to an insurance ontology.

In the first case we will think about solvability and liquidity risks, while in the second case we'll think about fire, theft, accident,... risks.

Dictionary

The dictionary part consists of the descriptions of both classes and instances.

These descriptions are fed into a kind of property of classes which are called annotations.

Disjoint classes

As a default classes overlap.

E.g. considering the ISIC activity codes we could consider the individuals of class P-Education to be equally individuals of class Q-HumanHealthAndSocialWorkAcitivities.

To separate them we will enter a disjoint statement at the level of the classes where we specify per class the disjoint classes.

Domain

The left side of a relation or role in an object property.

Individuals

Individuals are the elements of classes.

They are the most detailed unit of information about a concept, physical or not.

When put in a data model context, one could compare them with the records of a table.

To these individuals, the properties of the class will apply.

When creating individuals, by default, they are considered to be homologous or synonyms.

To make them distinct from each other we have to specify the individuals they are distinct from.

One can also specify the elements which are synonyms, especially when different groups of synonyms are present.

Inferred hierarchy

The hierarchy which is derived from the asserted information in the ontology.

See also asserted hierarchy.

Knowledge model

A knowledge model is an ontology enriched with individuals for the classes: the effective data.

Ontology

Branch of the Greek philosophy which has the purpose to describe the nature of things.

The description is done on basis of atomic facts and relations about a "thing".

This means you won't find combined knowledge in an ontology model: coding we are used to will be broken up into separate knowledge.

Open world assumption

The assumption that what is not proven to be false can be true.

Most axioms and properties find their reason in this assumption.

Properties (except annotation properties which are applicable to all objects)

Properties enrich the classes with information on top of their annotations (name, label and comments).

We distinguish:

object properties: these properties refer to objects which play a role at the right side of the relation.
Examples of role definitions are:

- has as emitter

- has as custodian

- has as fiscal resident

As the role is clear, we need still to define the left and right side of the relation.

As left side we can point to the class FinancialInstrument.

As right side we can point to the class PartyIssuer.

The full relation reads as FinancialInstrument has as emitter PartyIssuer.

The left side of a relation is called domains (one or more classes) in OWL.

The right side of a relation is called ranges (one or more classes) in OWL

data properties: are properties in the form of data for the right side of the relation.
Data properties can have different forms: enumerations of values, strings, integers, ...
Examples of relations with data properties:
ISO4217-CurrencyCode hasCurrencyNumericalCode Integer

Property arguments

Functional: the right side of a relation can get only one argument (object for object properties, value for value properties)
E.g. the birthdate of a party.
Inverse: refers to the property which is the inverse of the actual property.
E.g. the property isLegalResidentOf has as inverse property hasAsLegalResidents
Inverse functional: the inverse property which is at the same time functional
Transitive: when a relation is valid between objects A and B, and a relation between B and C is valid, then the same relation between A and C is valid.
E.g. Company A isSubsidiaryOfCompany B, company B isSubsidiaryOfCompany C, then company A isSubsidiaryOfCompany C.
Symmetric: if a relation links A to B then the same relation links B to A.
E.g. Employee A isCollegueOf B then B isCollegueOf A
Asymmetric: if a relation links A to B then the same relation cannot link B to A
E.g. FinancialInstrumentA hasAsGlobalCustodian PartyA then PartyA hasAsGlobalCustodian FinancialInstrumentA is never valid.
Reflexive: the relation has to relate the left-side object in the relation to itself.
E.g. BankA isPartyInformationProviderFor FinancialInstrumentA if that instrument is an own issue from BankA.
Irreflexive: the relation cannot link the same individual to itself.
E.g. FinancialInstrumentA hasAsFacialCurrency curr_EUR
Relation chain: if relationA links A to B and relationB links B to C then we can make a relation chain if relationA and relationB.
E.g. FinancialInstrumentA hasPartyGlobalCustodian PartyA, PartyA hasPartyCustodian PartyB, then the relations hasPartyGlobalCustodian could be chained with hasPartyCustodian.

To data properties, only the functional argument can be applied.

The other arguments can be applied to object properties.

Property application

A property can be applied in 3 ways in an ontology:

Unbound property: no condition.
The property can be created with its arguments, a domain and eventually a range.
When the property is not linked to a class, except by its domain value, it means the property can optionally be applied to the domain.
E.g. PartyIssuer hasMoodysRating Moodys might not be applied to an individual in the class PartyIssuer because not all issuers of financial instruments have a rating from the Moody's rating agency.
Necessary property.
The existing property can be bound to a class as a "necessary" condition.
This means to the individuals, to be valid members of the class, they should have at least one value set for the property.
It also means for the individuals, it is not sufficient to fulfill the condition to be a member of the class.
They are found in the classes under the Superclasses heading.
A class with only necessary conditions is called a primitive or partial class.
E.g. Party hasAsLegalResidence ISO3166-ISOCountryCode is a necessary condition because it is not sufficient to have a legal residence to be a party.
Necessary and sufficient property.
The created property can be bound to a class as "necessary and sufficient" condition.
This means to the individuals, all individuals with a value assigned to the property, are mandatory members of the class.
These restrictions are found in the Equivalent classes heading.
A class with at least one necessary and sufficiant condition is called a defined or complete class.
E.g. FinancialInstrument hasPartyIssuer PartyIssuer will be found in the necessary and sufficient conditions because it is sufficient to an individual to have a value for the hasPartyIssuer relation to be a financial instrument.

When properties are bound to classes, we will find them in the equivalent or superclass section of the class descriptions.

The reason is the individuals satisfying the restrictions are considered to form a class on their own: an anonymous class since the class has not been asserted and given a name.

Property scope

Existential restrictions

Those are also called Some of or Some values from restrictions.

At least one relation should exist with the specified class at the right side of the relation.

However, the same relation to other classes at the right side can co-exist.

E.g. FinancialInstrument hasPartyPrincipalPayingAgent some PartyPrincipalPayingAgent

This does however not prevent the usage of individuals from the class of PartyCustodians to act as the right side (range) of the "has Party Principal Paying agent" relation.

The DL Syntax (Description Logics) syntax for the above would be FinancialInstrument ∃ hasPartyPrincipalPayingAgent PartyPrincipalPayingAgent.

Universal restrictions

Those are also called All values from restrictions.

If a specific relation exists, it must be with individuals (members) of the specified class at the right side of the relation.

However, it does not guarantee such a relation exists.

E.g. FinancialInstrument hasPartyPrincipalPayingAgent only PartyPrincipalPayingAgent

The DL Syntax (Description Logics) syntax for the above would be FinancialInstrument ∀ hasPartyPrincipalPayingAgent PartyPrincipalPayingAgent.

Existential + Universal restriction

The combination of both restrictions make that the relation should exist and that the proposed range (right side) becomes mandatory.

Such restriction would be, for a given domain (left side of the relation):

hasPartyPrincipalPayingAgent some PartyPrincipalPayingAgent

AND hasPartyPrincipalPayingAgent only PartyPrincipalPayingAgent

Closure axiom

If we want to link one domain (left hand side class) to specific ranges we will combine those in a universal restriction.

E.g. for our class FinancialInstrument we have a relation hasAsCustodian.

The right side of the relation can be 2 classses: PartyGlobalCustodian or PartyCustodian.

The existential restrictions shall thus be:

FinancialInstrument hasAsCustodian some PartyGlobalCustodian

FinancialInstrument hasAsCustodian some PartyCustodian

To avoid the validity of a relation hasAsCustodian with PartyPayingAgent we formulate the closure axiom in the form of a universal restriction:

FinancialInstrument hasAsCustodian only (PartyGlobalCustodian OR PartyCustodian)

Range

The right side of an equation in an object property.

Reasoners

Reasoners are software which derive knowledge from ontologies and knowledge models.

Examples are Pellet, FaCT++ and RACER.

They commonly use tableaux algorithms to build knowledge on asserted statements.

Relations

Relations however form a cornerstone about the building of knowledge through ontologies.

This approach enables a clearer view on "things" allowing interpretations and deductions by the user.

Relations are called object properties in ontology building.

See more under Properties.

Taxonomy

Hierarchy of classes whereby each underlying class is a specialization of the superclass.

The top of the hierarchy is the concept "Thing".