Download presentation

Presentation is loading. Please wait.

Published byChad Reader Modified about 1 year ago

1
Artificial Intelligence Giancarlo Guizzardi Computer Science Department Federal University of Espírito Santo (UFES), Brazil

2
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.)

3
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.)

4

5

6

7

8
Basic Development Methodology 1.Purpose and Scope Identification (Requirements Engineering) 2.Ontology Reuse 3.Ontology Conceptual Modeling 4.Ontology Integration 5.Ontology Design Transformation Patterns and Guidelines 6.Ontology Codification 7.Ontology Evaluation

9
Basic Development Methodology 1.Purpose and Scope Identification (Requirements Engineering) 2.Ontology Reuse 3.Ontology Conceptual Modeling 4.Ontology Integration 5.Ontology Design Transformation Patterns and Guidelines 6.Ontology Codification 7.Ontology Evaluation

10
Basic Development Methodology 1.Purpose and Scope Identification (Requirements 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

11
Basic Development Methodology 1.Purpose and Scope Identification (Requirements 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!

12
Basic Development Methodology 1.Purpose and Scope Identification (Requirements 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

13
UFO & OBO Relation Ontology Anatomy subontoloty Heart Electrophysiology subontology ECG subontology ECG Ontology Modularization

14
Basic Development Methodology 2.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

15
Basic Development Methodology 2.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

16
Ontology Conceptual Model (OntoUML) Ontology Codification 1 Ontology Design Model 1 Ontology Codification 2 Ontology Codification 3 Ontology Design Model 1 Computational Independent Model (CIM) Platform Independent Model (PIM) Platform Specific Model (PSM)

17

18
A WHIRLWIND INTRODUCTION TO THE UML 2.0 CLASS FRAGMENT

19
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

20
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 attribute name attribute type attribute multiplicity

21
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 A If A specializes B and B specializes C then A specializes C

22
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 A If A specializes B and B specializes C then A specializes C supertype subtype

23
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

24
Specialization (Set-Theoretical Semantics) PERSON Man PERSON Man Woman

25
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 Man Woman Man and Woman PERSON

26
Man Woman 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

27
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 Man Woman PERSON

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

29
Associations One specify multiplicity constraints for each end of the association The possibilities for cardinality constraints are: MinMaxUML notation n (n> 1 indefinido)* * min max

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

31
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” rolenamereading directionality tagged valued representing association end’s ordering meta-attribute

32
Associations One can define type-reflexive associations, i.e., associations in which both association ends are connected to the same type

33
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

34
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 of hue, saturation and brightness values

35
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

36
DERIVED TYPES AND DERIVATION CONSTRAINTS

37
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

38
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 x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

39
SVBR (Semantics of Business Vocabularies and Rules)

40
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 x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) = def Person(x) (Age(x) 18)

41
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 Borrowed Book is a Book with an associated Rental Object x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

42
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 Borrowed Book is a Book with an associated Loan x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

43
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 Borrowed Book is a Book with an associated Loan x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) x BorrowedBook(x) = def Book(x) y(BookLoan(y) associated-with(y,x))

44
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 Borrowed Book is a Book with an associated Loan x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

45
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 Available Book is a Book without an associated Loan x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

46
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 Borrowed Book is a Book with an associated Loan x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

47
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 Borrowed Book is a Book with an associated Loan x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

48
Derived Types Quadrilateral is a Polygon with exactly four sides

49
Derived Types A BorrowedBook is a Book associated to a Loan and a BorrowingClient is a Person associated to a Loan

50
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) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) PRESIDENT Democratic President

51
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) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) ELECTION Direct Election Also known as Derivation by Participation

52
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 Intersection x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

53
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 Intersection x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) Child Adolescent Adult Person = Child Adolescent Adult Child Adolescent Adult = PERSON

54
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 Intersection x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) Child Adolescent Adult Student Person = Child Adolescent Adult Child Adolescent Adult = Student Person AdultStudent = Adult Student PERSON

55
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) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

56
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) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) Person = Man Woman Man Woman PERSON

57
Derivation by Union x AdultPerson(x) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) Person = Man Woman Person = Child Adolescent Adult AdultMan = Adult Man Man Woman PERSON Adolescent Child Adult

58
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) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18)

59
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) Person(x) (Age(x) 18) x AdultPerson(x) Person(x) (Age(x) 18) Person = Child Adolescent Adult Adult = Person – ( Child Adolescent) Child Adolescent Adult PERSON

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

61
INTEGRITY CONSTRAINTS

62
Admissible state of affairs according to the conceptualization underlying O 1 State of affairs represented by the valid models of Ontology O 1 Unconstrained Model

63
Admissible state of affairs according to the conceptualization underlying O 1 State of affairs represented by the valid models of Ontology O 1 + Integrity Constraints Constrained Model

64
Integrity Constraints 1.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

65
Integrity Constraints 1.Disjointness Constraints (DC) For the case of types, typically, DCs are transformed into derivation constraints (e.g., complete generalization sets) DCs between relationships can be expressed visually but one has to be very careful

66
Integrity Constraints 1.Disjointness Constraints (DC) For the case of types, typically, DCs are transformed into derivation constraints (e.g., complete generalization sets) DCs between relationships can be expressed visually but one has to be very careful

67
Integrity Constraints 1.Disjointness Constraints (DC) 2.Covering Constraints (CC) Typically transformed into derivation constraints or specialization relations (e.g., complete sets)

68
Integrity Constraints 1.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

69
Integrity Constraints 1.Disjointness Constraints (DC) 2.Covering Constraints (CC) 3.Consolidation Constraints 4.Other Epistemological Constraints These are all constraints directly derived from the concrete syntax of the language

70
Integrity Constraints

71
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

72
Integrity Constraints 1.Disjointness Constraints (DC) 2.Covering Constraints (CC) 3.Consolidation Constraints 4.Other Epistemological Constraints 5.Domain Constraints

73
Integrity Constraints x BankClient(x) 1 #{ y | hasAccount(x,y)} 3 A customer cannot have more than 3 accounts

74
Integrity Constraints

75
x Transplant(x) y,z,w OrganDonor(y) OrganDonee(z) TransplantSurgeon(w) (x y) (x z) (x w) (y z) (y w) (z w) donorIn(y,x) doneeIn(z,x) operates(w,x) The participants in a transplant (i.e., donor, donee and transplant surgeon) are necessarily mutually distinct

76
Integrity Constraints

77
Two (different) meetings cannot take place in the same room at the same time

78
Integrity Constraints Two (different) meetings cannot take place in the same room at the same time 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)

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

80
Integrity Constraints Two (different) meetings cannot take place in the same room at the same time 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)

81
Integrity Constraints Two (different) meetings cannot take place in the same room at the same time 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)

82
Integrity Constraints 1.Disjointness Constraints (DC) 2.Covering Constraints (CC) 3.Consolidation Constraints 4.Other Epistemological Constraints 5.Domain Constraints Meta-Properties of Domain Relations

83
Integrity Constraints A number of Meta-Properties can be defined for (type- reflexive) relations

84
Integrity Constraints A number of Meta-Properties can be defined for (type- 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

85
Integrity Constraints A number of Meta-Properties can be defined for (type- 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 Irreflexive, asymmetric and transitive relation, i.e., a partial order relation

86
Integrity Constraints 1.Disjointness Constraints (DC) 2.Covering Constraints (CC) 3.Consolidation Constraints 4.Other Epistemological Constraints 5.Domain Constraints Meta-Properties of Domain Relations Temporal Constraints

87
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

88
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

89
Temporal Constraints x initialState(x) (balanceOf(x) 0)

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

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

92

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

94
Side Effects in Derivation by Immutable Participation x,y Sale(x) Product (x,y) saleOf(x,y) (unitprice(x) = priceOf(y))

95
Side Effects in Derivation by Immutable Participation

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

97
Side Effects in Derivation by Immutable Participation M+ M- M+

98

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google