Artificial Intelligence Giancarlo Guizzardi ([email protected] )[email protected] Computer Science Department Federal University

Artificial Intelligence

Giancarlo Guizzardi([email protected] )http://nemo.inf.ufes.br

Computer Science DepartmentFederal University of Espírito Santo (UFES),

Brazil

mailto:[email protected]

http://nemo.inf.ufes.br/

Ontological Engineering• There are currently several existing methods for addressing

the many different activities that comprise the process of Ontological Engineering– METHONTOLOGY (Gomez-Perez et al.)– SKELETAL METHODOLOGY (Uschold and King)– TOVE Method (Gruninger and Fox)– On-to-Knowledge (Karlsruhe)– NeOn Methodology– SABiO (Falbo)– OntoClean (Guarino and Welty)– oQual (Gangemi et al.)– OntoQA (Sheth et al.)

Ontological Engineering• There are currently several existing methods for addressing

the many different activities that comprise the process of Ontological Engineering– METHONTOLOGY (Gomez-Perez et al.)– SKELETAL METHODOLOGY (Uschold and King)– TOVE Method (Gruninger and Fox)– On-to-Knowledge (Karlsruhe)– NeOn Methodology– SABiO (Falbo)– OntoClean (Guarino and Welty)– oQual (Gangemi et al.)– OntoQA (Sheth et al.)

Basic Development Methodology1. Purpose and Scope Identification (Requirements

Engineering)2. Ontology Reuse3. Ontology Conceptual Modeling4. Ontology Integration5. Ontology Design

• Transformation Patterns and Guidelines

6. Ontology Codification7. Ontology Evaluation


Engineering)2. Ontology Reuse3. Ontology Conceptual Modeling4. Ontology Integration5. Ontology Design

• Transformation Patterns and Guidelines

6. Ontology Codification7. Ontology Evaluation


Engineering)• The objective here is to understand all the concepts which are

central to the domain, i.e., the meaning of the relevant types, properties (instrinsic and relational), events and domain laws.

• Define the scope of ontology, its purposes and expected applications (competence of the ontology)

• A technique of particular relevance here is the definition of the so-called Competence Questions, i.e., the definition of what are the questions which ontology are expected to be able to answer

• Competence Questions is a technique for Scope and Purpose Definition, but also for validation


Engineering)• Scope definition is a critical aspect since several different (correct)

ontologies can be defined for the same domain with different scopes in mind

• In any case, try to be as generic as possible. The role is capture the conceptualization of a domain in reality, not a database schema!


Engineering)• Scope definition is a critical aspect since several different (correct)

ontologies can be defined for the same domain with different scopes in mind

• In any case, try to be as generic as possible (Minimal Ontological Commitment). The role is capture the conceptualization of a domain in reality, not a database schema!

• If the domain is two complex, an important technique is Domain Modularization so that different (ideally) orthogonal aspects of the domain can be capture in different subontologies

UFO & OBO Relation

Ontology

Anatomy subontoloty

Heart Electrophysiology

subontology

ECG subontology

ECG Ontology Modularization

Basic Development Methodology2. Ontology Conceptual Modeling

• The use of the support of a Foundational Ontology is fundamental in this phase.

• The objective is to maximize expressiveness, truthfulness w.r.t. the domain at hand and conceptual clarity

• In this course, we will use the UFO ontology and a particular language based on it termed OntoUML

• Initially we will deal exclusively with Structural Aspects of the domain

• Represent all elements in the Universe of Discourse– Model Types of Objects (both dependent and independent)

» Including Higher-Order Types– Model Categories of Object Types– Model Types of Properties (both Relational and Intrinsic) and

Property Value Spaces– Model Derived Types and Derivation Rules– Model Integrity Constraints

Basic Development Methodology2. Ontology Conceptual Modeling

• Define a Dictionary of Terms specifying in Natural Language and by using examples the primitive elements of the ontology

• Analyze the Ontology using Analysis Patterns• The use of Visual Language is very important in this phase• The use of a Model-Based Editor can be of great help• Validate Conceptual Model

– Model Simulation

OntologyConceptual Model

(OntoUML)

Ontology Codification1

Ontology Design Model1

Ontology Codification2Ontology Codification3

Ontology Design Model1

ComputationalIndependentModel (CIM)

PlatformIndependent

Model (PIM)

PlatformSpecific

Model (PSM)

A WHIRLWIND INTRODUCTION TO THE UML 2.0 CLASS FRAGMENT

Classes and Attributes• A class describes the common features (e.g., intrinsic and

relational properties) shared by a (possible multitude of) entities which are then said to be the instances of that class

• Instances of a class must contain values for each attribute that is defined for that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.

• Attributes represent (more or less intrinsic) properties of shared by members of a class

age:AgeValues[1]height:HeightValues[1]ssn:SSNValues[0..1]

Person

Classes and Attributes• A class describes the common features (e.g., intrinsic and

relational properties) shared by a (possible multitude of) entities which are then said to be the instances of that class

• Instances of a class must contain values for each attribute that is defined for that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.

• Attributes represent (more or less intrinsic) properties of shared by members of a class

age:AgeValues[1]height:HeightValues[1]ssn:SSNValues[0..1]

Person

attribute name

attribute type attribute

multiplicity

Specialization• Classes can be related to each other via specialization

relations forming a taxonomic structure• All properties of a class are inherited through a

specialization chain• A class can be a specialization of multiple classes• The specialization relation is a anti-symmetric and transitive

relation, i.e., If A specializes B then B cannot specialize AIf A specializes B and B specializes C then A specializes C

age:AgeValuesheight:HeightValuesssn:SSNValues

Person

Man

Specialization• Classes can be related to each other via specialization

relations forming a taxonomic structure• All properties of a class are inherited through a

specialization chain• A class can be a specialization of multiple classes• The specialization relation is a anti-symmetric and transitive

relation, i.e., If A specializes B then B cannot specialize AIf A specializes B and B specializes C then A specializes C


Person

Man

supertype

subtype

Generalization Set• Classes sharing a common direct supertype can be group in

what is called a generalization set

• There are two meta-attributes that can be used ascribe a stronger semantics to a generalization set, namely, the complete and disjoint meta-attributes


Person

Man Woman

Specialization (Set-Theoretical Semantics)


Person

Man

PERSON

Man


Person

Man Woman

PERSON

ManWoman

Complete• If a generalization set is complete then the subclasses

exhaust the instances of the common direct superclass. • In other words, in this case, there is no instance of the

superclass which is not an instance of one of the subclasses participating in the generalization


Person

Man Woman

{complete}

Man

Woman

Man andWoman

PERSON

PERSON

ManWoman

Disjoint• If a generalization set is disjoint if all the subclasses

participating in the generalization are mutually exclusive • In other words, the intersection between these any of these

subclasses pairwise is necessarily empty

neither Man or Woman


Person

Man Woman

{disjoint}

Disjoint and Complete• If a generalization set is disjoint and complete then the

subclasses participating in this generalization set form a partition.

• In other words, every instance of the common superclass is an instance of one and only one of the subclasses

• In this case, the common superclass is an abstract class


Person

Man Woman

{disjoint, complete}

Man

Woman

PERSON

Associations• An association declares that there can be links between

instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.

Person Property

1..* *

ownership

Associations• One specify multiplicity constraints for each end of the

association

• The possibilities for cardinality constraints are:

Person Property

1..* *

ownership

Min Max UML notation

0 1 0..1

0 n (n> 1 indefinido) *

1 1 1

1 n (n> 1 indefinido) 1..*

min

max

Associations• When one or more ends of the association are ordered,

links carry ordering information in addition to their end values.

• To each association end, one can specify a rolename definying the “role played by objects of that type in the association”

Persondate:Date

Symptonpatient

1 1..*{ordered}

exhibits4

Associations• When one or more ends of the association are ordered,

links carry ordering information in addition to their end values.

• To each association end, one can specify a rolename definying the “role played by objects of that type in the association”

Persondate:Date

Symptonpatient

1 1..*{ordered}

exhibits4

rolename reading directionality

tagged valued representingassociation end’s orderingmeta-attribute

Associations• One can define type-reflexive associations, i.e., associations

in which both association ends are connected to the same type

Person

parent *

offspring *

parenthood

Datatypes• A Datatype represents the set of possible values that an

attribute can take.• If attributes are seen as functions (mapping the extension of

a class to a datatype) than they are the range of that function

• Datatypes have no instances in the real sense, they are simply sets of values. They have members which are abstract individuals, i.e., they are not explicitly created or destroyed but are simply assumed to exist

age:AgeValues

Person «datatype»AgeValues

Person

* 1

Datatypes• There are simple and structured datatype. The “attributes”

of a structured datatype are named datatype fields • The members of a datatype with n fields are n-uples. For

instance, the members of the color datatype below are triples <h,s,b> of hue, saturation and brightness values

hue:Huesaturation:Saturationbrightness:Brightness

«datatype»Color

Enumeration

• Since datatypes are sets we have that: (i) two datatypes are the same iff they have the same members

• One can define a datatype by explicit enumeration, i.e., by explicitly defining its member values

SundayMondayTuesdayWednesdayThursdayFridaySaturday

«enumeration»Days of the Week

DERIVED TYPES AND DERIVATION CONSTRAINTS

Derived Types • We distinguish between Base Types and Derived Types• Derivability has to do with how the population of a type is

generated• E.g., contrast Book with Borrowed Book, Person with Adult Person

Book

/BorrowedBook

Person

/Adult Person

Derived Types and Derivation Rule • For each derived types there is an associated derivation rule

describing necessary and sufficient conditions for classification (instantiation)

E.g., Every Adult Person is a Person who is older than 18

age:AgeValues

Person

/Adult Person

x AdultPerson(x)

Person(x) (Age(x) 18)

x AdultPerson(x)


SVBR (Semantics of Business Vocabularies and Rules)



E.g., Every Adult Person is a Person who is older than 18

age:AgeValues

Person

/Adult Person

x AdultPerson(x)


x AdultPerson(x)


x AdultPerson(x) =def Person(x) (Age(x) 18)



E.g., Every Borrowed Book is a Book with an associated Rental Object

x AdultPerson(x)


x AdultPerson(x)


age:AgeValues

Person

/Adult Person

DR1

age ≥ 18



E.g., Every Borrowed Book is a Book with an associated Loan

x AdultPerson(x)


x AdultPerson(x)


Book Book Loan

1 *

3 loan of




x AdultPerson(x)


x AdultPerson(x)


x BorrowedBook(x) =def Book(x) y(BookLoan(y) associated-with(y,x))

Book

/BorrowedBook

Book Loan

1 *

3 loan of




x AdultPerson(x)


x AdultPerson(x)


Book

/BorrowedBook

Book Loan

1 *

3 loan of

DR1

x y

x



E.g., Every Available Book is a Book without an associated Loan

x AdultPerson(x)


x AdultPerson(x)


Book

/AvailableBook

Book Loan

1 *

3 loan of

DR1

x y

x




x AdultPerson(x)


x AdultPerson(x)


Book Book Loan

1 *

3 loan of




x AdultPerson(x)


x AdultPerson(x)


Book

/BorrowedBook Loan

1 1..*

Derived Types Quadrilateral is a Polygon with exactly four sides

numberOfSides:PolygonSides

Polygon

/Quadrilateral

DR1

numberOfSides = 4

3..20

«enumeration»PolygonSides

Derived Types

A BorrowedBook is a Book associated to a Loan and a BorrowingClient is a Person associated

to a Loan

Book

/BorrowedBook Loan

1 1..*

Person

1..* 1

/BorrowingClient

President

/DemocraticPresident

1 1..*{ordered}

elected in4

date:Dateprocedure:Appointment Procedure

Election

/DirectElection

DR1

procedure = direct

DirectIndirectAutocratic

«enumeration»Appointment Procedure

Derivation by Specialization• A types is defined as a specialization of another type which

has specific (intrinsic or relational) properties E.g., A Democratic President is a President elected by a Direct Election

Procedure

x AdultPerson(x)


x AdultPerson(x)


PRESIDENT

Democratic President

President

/DemocraticPresident

1 1..*{ordered}

elected in4

date:Dateprocedure:Appointment Procedure

Election

/DirectElection

DR1

procedure = direct

DirectIndirectAutocratic

«enumeration»Appointment Procedure

Derivation by Specialization• A types is defined as a specialization of another type which

has specific (intrinsic or relational) properties E.g., A Democratic President is a President elected by a Direct Election

Procedure

x AdultPerson(x)


x AdultPerson(x)


ELECTION

Direct Election

Also known as Derivation by Participation

• A types can be derived by specialization of multiple supertypes (also known as derived by intersection)

E.g., A Adult Student is a Student who is an Adult Person

Derivation by Intersectionx AdultPerson(x)


x AdultPerson(x)


Person

/Student Educational Institution

* 1..*

enrolled at4

Child

Adolescent

Adult

{complete,disjoint}

/Adult Student





x AdultPerson(x)


Child

Adolescent

Adult

Person = Child Adolescent Adult Child Adolescent Adult =

PERSON





x AdultPerson(x)


Child

Adolescent

Adult

StudentPerson = Child Adolescent Adult Child Adolescent Adult = Student Person

AdultStudent = Adult Student

PERSON

Derivation by Union• A type is defined as a Union of a number of other types

• A Derivation by Union constraint implies a number of specialization relation between T1…Tn and the derived type T, such that T1…Tn form a complete generalization set

x AdultPerson(x)


x AdultPerson(x)


Person

Man Woman

{complete,disjoint}

Derivation by Union• A type T is defined as a Union of a number of other types

T1…Tn if: in every situation, x is an instance of T iff x is an instance of T1 or T2 or….Tn

x AdultPerson(x)


x AdultPerson(x)


Person = Man WomanMan

Woman

PERSON

Derivation by Unionx AdultPerson(x)


x AdultPerson(x)


Person = Man WomanPerson = Child Adolescent AdultAdultMan = Adult Man

Man

Woman

PERSON

Adolescent

Child

AdultPerson

Man

Child

Adolescent

Adult

{complete,disjoint}

Adult Man

Woman

{complete,disjoint}

Derivation by Exclusion• A type T1 derived as a complement of T2..Tn w.r.t. T

• A Derivation by Exclusion constraint implies a number of specialization relations between T1…Tn and the type type T, forming a disjoint and complete generalization set

x AdultPerson(x)


x AdultPerson(x)


Person

Child

Adolescent

/Adult

{complete,disjoint}

Derivation by Exclusion• A type T1 is defined by exclusion of T2…Tn with respect to T

if: in every situation, x is an instance of T1 iff x is an instance of T and not an instance of (T2 or….Tn)

x AdultPerson(x)


x AdultPerson(x)


Person = Child Adolescent Adult

Adult = Person – (Child Adolescent)Child

Adolescent

Adult

PERSON

Important Point• We will see later how these derivation constraints interact

with the modeling primitives of OntoUML (e.g., are implied by, automatically deduced from)

INTEGRITY CONSTRAINTS

Admissible state of affairs according to the conceptualization underlyingO1

State of affairs represented by the valid models of Ontology O1

Unconstrained Model

Admissible state of affairs according to the conceptualization underlyingO1

State of affairs represented by the valid models of Ontology O1 + Integrity Constraints

Constrained Model

Integrity Constraints1. Disjointness Constraints (DC)

• For the case of types, typically, DCs are transformed into derivation constraints (e.g., disjoint generalization sets)

• DCs between relationships can be expressed visually but one has to be very careful

/ClubMember ClubMembershipCard

1 1..*

purchases4

Person

1 1..*

is granted4

{XOR}


• For the case of types, typically, DCs are transformed into derivation constraints (e.g., complete generalization sets)


/ClubMember ClubMembershipCard

1 *

purchases4

Person

1 *

is granted4

{XOR}


• For the case of types, typically, DCs are transformed into derivation constraints (e.g., complete generalization sets)


/RegularMember ClubMembershipCard

1 1..*

purchases4

Person

1

1..*

is granted4

/HonoredMember

{disjoint}

Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)

• Typically transformed into derivation constraints or specialization relations (e.g., complete sets)

Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints

• Define the type of entities that can participate in a relation• Unecessary in a language such as UML

Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints4. Other Epistemological Constraints

• These are all constraints directly derived from the concrete syntax of the language

Integrity Constraints

/BankClient

Person

Account

1 1..3

has account4


/BankClient

Person

Account

1 1..3

has account4

A type of constraint (inclusion constraint)

PERSON

Bank Client

• Other constraint of this kind is parthood• The semantics is (supposed to be) included

in the metamodel of the language• This includes the meta-properties of these

relations

Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints4. Other Epistemological Constraints5. Domain Constraints


/BankClient

Person

Account

1 1..3

has account4

x BankClient(x) 1 #{ y | hasAccount(x,y)} 3

A customer cannot have more than 3 accounts


Person

/OrganDonor

/OrganDonee

Transplant

1 1..*

donor in4

1..*

1donee in4

/TransplantSurgeon

1..*

1

operates4


x Transplant(x) y,z,w OrganDonor(y) OrganDonee(z) TransplantSurgeon(w) (xy) (xz) (xw) (yz) (yw) (zw) donorIn(y,x) doneeIn(z,x)

operates(w,x)

Person

/OrganDonor

/OrganDonee

Transplant

1 1..*

donor in4

1..*

1donee in4

/TransplantSurgeon

1..*

1

operates4

The participants in a transplant (i.e., donor, donee and transplant surgeon) are necessarily mutually distinct


Meeting Room

* 1

has location4

TimeInterval1 *

3 happens in*

*intersects

Integrity ConstraintsTwo (different) meetings cannot take place in the

same room at the same time

Meeting Room

* 1

has location4

TimeInterval1 *

3 happens in*

*intersects



x,y,t1,t2,l Meeting(x) Meeting(y) happensAt(x,t1) happensAt(y,t2) hasLocation(x,l) hasLocation(y,l)

intersect(t1,t2) (x = y)

Meeting Room

* 1

has location4

TimeInterval1 *

3 happens in*

*intersects

Integrity Constraints• Domain Integrity constraints can be re-written as

Inconsistency Predicates

x,y overlapsWith(x,y) =def Meeting(x) Meeting(y) t1,t2,l happensAt(x,t1) happensAt(y,t2)

hasLocation(x,l) hasLocation(y,l) intersect(t1,t2)

Meeting Room

* 1

has location4

TimeInterval1 *

3 happens in*

*intersects

**

/overlapsWith





Meeting Room

* 1

has location4

TimeInterval1 *

3 happens in*

*intersects





Meeting Room

* 1

has location4

TimeInterval1 *

3 happens in*

*intersects


• Meta-Properties of Domain Relations

Integrity Constraints• A number of Meta-Properties can be defined for (type-

reflexive) relationsPerson

1..*1..*

3 descends from

/Ancestor /Descendent


reflexive) relations

• Someone cannot be his own ancestor• Someone cannot be an ancestor of an ancestor of his• Someone´s ancestors include the ancestors of his

ancestors

Person

1..*1..*

3 descends from



reflexive) relations

• Someone cannot be his own ancestor• Someone cannot be an ancestor of an ancestor of his• Someone´s ancestors include the ancestors of his

ancestors

Person

1..*1..*

3 descends from


Irreflexive, asymmetric and transitive relation, i.e., a partial order relation


• Meta-Properties of Domain Relations• Temporal Constraints

Temporal Constraints• A customer cannot open two accounts on the same day• A handler must be assigned to an account up to 1 month

after the accounts creation• The balance of the account when first opened must be non-

negative• A client cannot have more than three accounts at the same

time

/BankClient

Person

balance:Money

Account

1 1..*

has account4

/AccountHandler

0..1

1..*

is responsible for4

Temporal Constraints• A customer cannot open a new account if he has one which

is overdrawn• A customer cannot open a new account if he has an account

overdrawn for more than 30 days in that same year

/BankClient

Person

balance:Money

Account

1 1..*

has account4

/AccountHandler

0..1

1..*

is responsible for4

Temporal Constraints

x initialState(x) (balanceOf(x) 0)

/BankClient

Person

Account

1 1..*

has account4

/AccountHandler

balance:Money

AccountState

1 1..*{ordered}

constituted by4

TimeInterval

*

1

3 happens inAssignment

1

1..*

0..1

1

/InitialState

*

*precedes

Temporal Constraints

x,y,z hasAccount(x,y) constitutedBy(y,z) OverDrawnState(z) (w,q hasAccount(x,w)

constitutedBy(w,q) initialState(q) intersect(z,q))

/BankClient

Person

Account

1 1..*

has account4

/AccountHandler

balance:Money

AccountState

1 1..*{ordered}

constituted by4

TimeInterval

*

1


1

1..*

0..1

1

/InitialState

*

*precedes

/OverDrawnAccountState

DR2

balance < 0

{disjoint}

Important Point• There are a number of constraints that must be included in

UML models as domain constraints because of the nature of the language

• Some of these cannot even be properly represented!

/BankClient

Person

Account

1 1..*

has account4

/AccountHandler

balance:Money

AccountState

1 1..*{ordered}

constituted by4

TimeInterval

*

1


1

1..*

0..1

1

/InitialState

*

*precedes

/OverDrawnAccountState

DR2

balance < 0

{disjoint}



• Some of these cannot even be properly represented!• We will see later how these constraints (e.g., dependence,

parthood, dynamic vs. static classification, explanation for relationship meta-properties) become part of the language in OntoUML. Similar to the notion of epistemological constraints here...However, those are constraints of a true ontological nature!

Side Effects in Derivation by Immutable Participation

x ,y Sale(x) Product (x,y) saleOf(x,y) (unitprice(x) = priceOf(y))

/unitprice:Money

Sale

price:Money

Product

* 1


/SalesPerson

/Customer

Sale

1 1..*

/responsible for4

1

1..*

3 saleOf

1..*

1

assigned to4

DR

xy

y

z

x z



• Some of these cannot even be properly represented!• We will see later how these constraints (e.g., dependence,

parthood, dynamic vs. static classification, explanation for relationship meta-properties) become part of the language in OntoUML. Similar to the notion of epistemological constraints here...However, those are constraints of a true ontological nature!

• Moreover, we can provide systematic techniches for identifying those modeling mistakes


/SalesPerson

/Customer

Sale

1 1..*

/responsible for4

1

1..*

3 saleOf

1..*

1

assigned to4

DR

xy

y

z

x z

M+

M-

M+

http://nemo.inf.ufes.br/[email protected]

Documents

Artificial Intelligence Giancarlo Guizzardi ([email protected] )[email protected] Computer Science Department Federal University