Ontologies Reasoning Components Agents Simulations Ontologies Jacques Robin.

38
Ontologi es Reasonin g Component s Agents Simulatio ns Ontologies Ontologies Jacques Robin
  • date post

    19-Dec-2015
  • Category

    Documents

  • view

    227
  • download

    0

Transcript of Ontologies Reasoning Components Agents Simulations Ontologies Jacques Robin.

OntologiesReasoningComponentsAgentsSimulations

OntologiesOntologies

Jacques Robin

OutlineOutline

Ontologies What is an ontology? Elements of an ontology Services provided by an ontology The pluridisciplinary origin of ontological engineering Typology of ontologies Sub-fields and general issues in ontological engineering

The Object Constraint Language (OCL) What is OCL? Motivating examples OCL expression contexts The link between the OCL and UML metamodels The OCL metamodel OCL Types Inheritance and encapsulation in OCL Local variale definitions The OCL operator library OCL vs. UML OCL vs. Java

What is an Ontology?What is an Ontology?

Definition: explicit, formal (or semi-formal) specification of a shared conceptualization

Conceptualization:Conceptualization: model of entities, relations, constraints and rules of a given domain or field

Formal:Formal: Machine-processable; Allowing automated reasoning; With declarative semantics;

Shared:Shared: By a knowledge community; Allowing common understanding and effective communication of largely

implicitly specified content, completed by inference based on the shared explicit knowledge in the

ontology

Related concepts: Reusable knowledge base Database schema

Elements of an Ontology:Elements of an Ontology:Concept Generalization HierarchyConcept Generalization Hierarchy

Entity Classes: Each entity class defined by a set of slot-facet-value triple Correspond to:

Classes of OO models Entities of relational models Terms of logical models

Property slots x relational slots Filled by atomic values (primitive data types) x by other concepts

Epistemological status of the value (defined by the facet) Precisely known, default, possibilistic, plausibilistic, probabilistic

Generic Relations: With or without generalization hierarchy running parallel to concept

generalization hierarchy Correspond to:

Associations, aggregations, compositions and complex object filled attributes of OO models

Relations of relational model Predicates of logical models

Elements of an Ontology:Elements of an Ontology:Constraints and Derivation RulesConstraints and Derivation Rules

Constraints: On the domain values of attributes from

One concept (type constraints) Several related concepts (integrity constraints)

To prohibit semantically invalid concepts instances or semantically inconsistent concept instance set

Correspond to: Class signatures and invariants in OO models Typing predicates, sorts (partition of constant symbol alphabet) and integrity

constraints in logical models Typing and integrity constraints in database schemas

Rules to derive: The value of attribute concepts from set of other such values The existence of concept instances from the existence of other such

instances Correspond to:

Declarative methods in OO models Implicative clauses of logical models Database views

Elements of an Ontology:Elements of an Ontology:Constraints x Derivation RulesConstraints x Derivation Rules

As a constraint, the formula: C, person(C) ! M, person(M) mother(M,C) prohibits the creation of person concept instances with zero or multiple mothers;

As a derivation rule, this same formula allows inferring:- From the existence of each instance C of the person concept the existence of another instance M of that concept, related to C by an instance of the mother relation;

- From the existence of two instances M and M’ of the person concept, both related to the same third instance C of that concept by the mother relation, that M = M’

Concept instances generally not part of an ontology Exception: special values that correspond to constant value declaration in programming language as opposed to variable binding

Computation Services to Provide to Computation Services to Provide to Make an Ontology UsefulMake an Ontology Useful

Insertion or deletion of element: Entity class, generic relation, constraint, derivation rule

Simple queries: Entity attribute value local retrieval Relation navigation

Queries involving automated reasoning: Entity attribute value retrieval with inheritance Instance classification from its attribute values Subsumption between two entity or relation classes Input constraint verification over an entity class Search for entity classes that satisfy a given input constraint Verification of instance sets against ontology constraints Overall ontology consistency Derivability of given formula

Cross-Disciplinary History of Cross-Disciplinary History of OntologiesOntologies

OrganizationKnowledge

Managementsince 1990

DataIntegrationsince 1995

Multi-AgentSystems

since 1995

WebInformation

Retrievalsince 2000

CognitivePsychologysince 1960

Linguisticssince 1960

ExpertSystems

since 1980

Natural LanguageProcessingsince 1980

OntologiesPhilosophy

since 350 A.C.

SoftwareEngineering

(Business Modeling)since 1990

Ontology Classification DimensionsOntology Classification Dimensions

Specialist x GeneralSpecialist x General Specialist:Specialist: Models a restricted domain or field

ex. geometry, stock market, soccer, viral infections, etc. General:General:

Models common sense knowledge Most generic cognitive categories, reusable in multiple domains, with

domain-specific concepts specializing Common sense ontology provide sound guidance to avoid

Conceptual x Linguistic:Conceptual x Linguistic: Conceptual:

Based on distinctions useful for automated reasoning executing variety of tasks

Linguistic:Linguistic: Based on the vocabulary of one or several natural languages A concept is defined by the synonyms to express it A relation is defined by recurrent, deep thematico-lexical relations

among these synonyms

Ontology Classification DimensionsOntology Classification Dimensions

Structural x BehavioralStructural x Behavioral Behavioral ontology reify as concepts reasoning and problem

solving methods Domain-Level x Meta-LevelDomain-Level x Meta-Level

Meta-Level ontology defines the computational concepts with Meta-Level ontology defines the computational concepts with which to model the domain or common sense conceptswhich to model the domain or common sense concepts

Anything

AbstractObjectsEvents

Sets Numbers RepresentationalObjects

Categories

Sentences Measurements

Intervals PlacesPhysicalObjects Processes

MomentsThings Stuff

Animals Agents

Humans

Solid Liquid Gas

Skeleton of aSkeleton of aTop-Level Common Top-Level Common

SenseSenseOntologyOntology

Ontology Engineering IssuesOntology Engineering Issues

Domain partitioning: How to delimit concepts? What are the distinctions that bring added value?

Scope: What knowledge to include? What is the domain frontier?

Granularity: Down to which level to detail the model?

Validation: How to evaluate the model quality? Why to prefer one modeling solution over another? How to identify key missing concepts?

Since an ontology is by definition meant to be application independent, application requirements cannot be used as guidance

These issues are particularly vexing for conceptual, common sense ontology that can neither fall back on linguistics nor on common requirement of application family for guidance

What is OCL? What is OCL? Definition and RoleDefinition and Role

A textual specification language to adorn UML and MOF diagrams and make them far more semantically precise and detailed

OCL2 integral part of the UML2 standard OCL complements UML2 diagrams to make UML2:

A domain ontology language that is self-sufficient at the knowledge level to completely specify both structure and behaviors

A complete input for the automated generation of a formal specification at the formalization level to be verified by theorem provers

A complete input for the automated generation of source code at the implementation level to be executed by a deployment platform

OCL complements MOF2 diagrams to make MOF2: An object-oriented declarative abstract syntax and semantics specification

language that is self-sufficient at the meta-knowledge/meta-modeling level OCL forms the basis of model transformation languages

such as Atlas Transformation Language (ATL) or Query-View-Transform (QVT) which declaratively specify through rewrite transformation rules the

automated generation of formal specifications and implementations from a knowledge level ontology

OCL expressions are reused in the left-hand side and right-hand side of such rules

To specify objects to match in the source ontology of the transformation To specify objects to create in the target formal specification or code of the

transformation

What is OCL?What is OCL?CharacteristicsCharacteristics

Formal language with well-defined semantics based on set theory and first-order predicate logic, yet free of mathematical notation and thus friendly to mainstream programmers

Object-oriented functional language: constructors syntactically combined using functional nesting and object-oriented navigation in expressions that take objects and/or object collections as parameters and evaluates to an object and/or an object collection as return value

Strongly typed language where all expression and sub-expression has a well-defined type that can be an UML primitive data type, a UML model classifier or a collection of these

Semantics of an expression defined by its type mapping Declarative language that specifies what properties the software

under construction must satisfy, not how it shall satisfy them Side effect free language that cannot alter model elements, but only

specify relations between them (some possibly new but not created by OCL expressions)

Pure specification language that cannot alone execute nor program models but only describe them

Both a constraint and query language for UML models and MOF meta-models

What is OCL?What is OCL?How does it complement UML?How does it complement UML?

Structural adornments: Specify complex invariant constraints (value, multiplicity, type,

etc) between multiple attributes and associations Specify deductive rules to define derived attributes, associations

and classes from primitive ones Disambiguates association cycles

Behavioral adornments: Specify operation pre-conditions Specify write operation post-conditions Specify read/query operation bodies Specify read/query operation initial/default value

OCL: Motivating ExamplesOCL: Motivating Examples

Diagram 1 allows Flight with unlimited number of passengers

No way using UML only to express restriction that the number of passengers is limited to the number of seats of the Airplane used for the Flight

Similarly, diagram 2 allows: A Person to Mortgage the house of

another Person A Mortgage start date to be after

its end date Two Persons to share same social

security number A Person with insufficient income to

Mortgage a house

1

2

OCL: Motivating ExamplesOCL: Motivating Examples

1

2

context Flightinv: passengers -> size() <= plane.numberOfSeats

context Mortgage inv: security.owner = borrowerinv: startDate < endDate

context Personinv: Person::allInstances() -> isUnique(socSecNr)

context Person::getMortgage(sum:Money,security:House)pre: self.mortgages.monthlyPayment -> sum() <= self.salary * 0.3

OCL Expression ContextsOCL Expression Contexts

Operation

OCL Contexts: OCL Contexts: Default Value and Query Default Value and Query

SpecificationsSpecificationsInitial values: context LoyaltyAccount::points : integer

init: 0 context LoyaltyAccount::transactions

: Set(Transaction) init: Set{}

Query operations: context

LoyaltyAccount::getCustomerName() : Stringbody: Membership.card.owner.name

context LoyaltyProgram::getServices(): Set(Services)body: partner.deliveredServices -> asSet()

OCL Contexts:OCL Contexts:Specifying Invariants on AttributesSpecifying Invariants on Attributes

The context of an invariant constraint is a class

When it occurs as navigation path prefix, the self keyword can be omitted:

context Customer inv: self.name = ‘Edward’

context Customer inv: name = ‘Edward’

Invariants can be named: context Customer inv myInvariant23:

self.name = ‘Edward’ context LoyaltyAccount

inv oneOwner: transaction.card.owner -> asSet() -> size() = 1

In some context self keyword is required: context Membership

inv: participants.cards.Membership.includes(self)

Association NavigationAssociation Navigation

Association navigation: context Transaction

def getCustomer():Customer = self.card.owner

Attribute access: context Transaction

def getCustomerName():String = self.card.owner.name

Abbreviation of collect operator that creates new collection from existing one, for example result of navigating association with plural multiplicity:

context LoyaltyAccount inv: transactions -> collect(points) -> exists(p:Integer | p=500)

context LoyaltyAccount inv: transactions.points -> exists(p:Integer | p=500)

Use target class name to navigate roleless association:

context LoyaltyProgram inv: levels -> includesAll(Membership.currentLevel)

Call UML model and OCL library operations

Generalization NavigationGeneralization Navigation

OCL constraint to limit points earned from single service to 10,000 Cannot be correctly specified using association navigation: context ProgramPartner inv totalPoints: deliveredServices.transactions .points -> sum() < 10,000adds both Earning and Burning points Operator oclIsTypeOf allows hybrid navigation following associations and specialization linkscontext ProgramPartner inv totalPoints: deliveredServices.transactions -> select(oclIsTypeOf(Earning)) .points -> sum() < 10,000

OCL Contexts: OCL Contexts: Specifying Attribute Derivation RulesSpecifying Attribute Derivation Rules

context CustomerCard::printedName derive: owner.title.concat(‘

‘).concat(owner.name) context TransactionReportLine: String

derive self.date = transaction.date ... context TransactionReport

inv dates: lines.date -> forAll(d | d.isBefore(until) and d.isAfter(from))

...

OCL Contexts:OCL Contexts:Specifying Pre and Post ConditionsSpecifying Pre and Post Conditions

context LoyaltyAccount::isEmpty(): Booleanpre: -- nonepost: result = (points = 0)

Keyword @pre used to refer in post-condition to the value of a property before the execution of the operation:

context LoyaltyProgram::enroll(c:Customer)pre: c.name <> ‘ ‘post: participants = participants@pre -> including(c)

Keyword oclIsNew used to specify creation of a new instance (objects or primitive data):

context LoyaltyProgram::enrollAndCreateCustomer(n:String,d:Date):Customerpost: result.oclIsNew() and result.name = n and result.dateOfBirth = d and participant -> includes(result)

oclIsNew only specifies that the operation created the new instance, but not how it did it which cannot be expressed in OCL

Links BetweenLinks BetweenOCL and UML Meta-ModelsOCL and UML Meta-Models

ModelElement

Classifier

Constraint

Expression

ExpressionInOcl OclExpression

0..1

+body1

+bodyExpression

1

+constrainedElement

0..*

+constraint

0..*

The OCL Expressions Meta-ModelThe OCL Expressions Meta-Model

The OCL Types Meta-ModelThe OCL Types Meta-ModelStructuralFeature Classifier

OclMessageType OclModelElementType DataType VoidType

TupleType Primitive CollectionType

SetType SequenceType BagType

OrderedSetType

OperationSignal

+elementType

1

+collectionTypes

0..4

0..*

+type

1

+referredSignal0..1 +referredOperation0..1

OCL MetaclassUML Metaclass

OCL TypesOCL Types

Value Types: UML primitive types (including user-defined enumerations) OCL collection types (even of user-defined classifiers ?) Their instances never change value

ex, Integer instance 1 cannot be changed to instance 2, nor can string instance “Lew Alcindor” be changed to string instance “Kareem Abdul-Jabbar”, nor can enumeration Grade instance A can be changed to enumeration instance C.

Object types: UML classifiers Their instances can change value, i.e., the Person instance p1 can

have its name attribute “Lew Alcindor” changed to “Kareem Abdul-Jabbar” yet remain the same instance p1

OclAny: Most generic OCL type, subsuming all others General reflective operations are defined for this type and

inherited by all other OCL types

OCL TypesOCL Types

Primitive data types (from UML): boolean, string, integer, real

Type conformance rules: t1 conforms to t2 if t1 <= t2 in type hierarchy

t1 = collection(t2) conforms to t3 = collection(t4) if t2 conforms to t4

integer <= real

Type casting: Operation oclAsType(s) can be invoked on an expression of type g

to recast it as a type s s must conform to g

OclVoid: Undefined value (similar to null values of SQL) Tested by oclIsUndefined operation of OclAny type

OCL Types: CollectionsOCL Types: Collections

Collection constants can be specified in extension: Set{1, 2, 5, 88}, Set{‘apple’, ‘orange’, ‘strawberry’} OrderedSet{‘black’, ‘brown’, ‘red’, ‘orange’, ‘yellow’, ‘green’, ‘blue’,

‘purple’} Sequence{1, 3, 45, 2, 3}, Bag{1, 3, 4, 3, 5}

Sequence of consecutive integers can be specified in intension: Sequence{1..4} = Sequence{1,2,3,4}

Collection operations are called using -> instead of . Collection operations have value types:

They do not alter their input only output a new collection which may contain copies of some input elements

Most collections operations return flattened collections ex, flatten{Set{1,2},Set{3,Set{4,5}}} = Set{1,2,3,4,5}

Operation collectNested must be used to preserve embedded sub-structures

Navigating through several associations with plural multiplicity results in a bag

OCL Semantics: OCL Semantics: Encapsulation and InheritanceEncapsulation and Inheritance

By default, OCL expressions ignore attribute visibility i.e., an expression that access a

private attribute from another class is not syntactically rejected

OCL constraints are inherited down the classifier hierarchy

OCL constraints redefined down the classifier hierarchy must follow substituability principle Invariants and post-condition

can only become more restrictive

Preconditions can only become less restrictive

Examples violating substituability principle:

context Stove inv: temperature <= 200

context ElectricStove inv: temperature <= 300

context Stove::open()pre: status = StoveState::offpost: status = StoveState::off and isOpen

context ElectricStove::open()pre: status = StoveState::off and temperature <= 100post: isOpen

OCL Expressions: Local VariablesOCL Expressions: Local Variables

Let constructor allows creation of aliases for recurring sub-expressions

context CustomerCardinv: let correctDate : Boolean =

validFrom.isBefore(Date::now) and goodThru.isAfter(Date::now)

in if valid then correctDate = false else correctDate = true endif

Syntactic sugar that improves constraint legibility

OCL Library: Generic OperatorsOCL Library: Generic Operators

Operators that apply to expressions of any type Defined at the top-level of OclAny

OCL Library: Primitive Type OCL Library: Primitive Type OperatorsOperators

Boolean: host, parameter and return type boolean Unary: not Binary: or, and, xor, =, <>, implies Ternary: if-then-else

Arithmetic: host and parameters integer or real Comparison (return type boolean): =, <>, <, > <=, >=, Operations (return type integer or real): +, -, *, /, mod, div, abs,

max, min, round, floor

String: host string Comparison (return type boolean): =, <> Operation: concat(String), size(), toLower(), toUpper(),

substring(n:integer,m:integer)

OCL Library: Generic Collection OperatorsOCL Library: Generic Collection Operators

OCL Library:OCL Library:Specialized Collection OperatorsSpecialized Collection Operators

OCL Constraints OCL Constraints vs.vs. UML Constraints UML Constraints

context ElectricGuitar inv: strings -> forAll(s \ s.oclIsType(MetalStrings))

context: ClassicalGuitar inv: strings-> forAll(s | s.oclIsType(plasticStrings))

context ElectricGuitar inv: strings -> forAll(type = StringType::metal)

context ClassicGuitar inv: strings -> forAll(type = StringType::plastic)

context Guitar inv: type = GuitarType::classic implies strings -> forAll(type = StringType::plasticinv: type = GuitarType::classic implies strings -> forAll(type = StringType::plastic

OCL OCL vs.vs. Java Java Declarative specification of operation post-conditions in OCL is far more concise

than corresponding implementation in mainstream imperative OO language such as Java

This is due mainly to OCL’s powerful collection operators Example: OCL expression

self.parters -> select(deliveredServices -> forAll(pointsEarned = 0)) Corresponding Java code:1. Iterator it = this.getPartners().iterator();2. Set selectResult = new HashSet(); 3. while( it.hasNext() ){ 4. ProgramPartner p = (ProgramPartner) it.next(); 5. Iterator services = p.getDeliveredServices().iterator(); 6. boolean forAllresult = true; 7. while( services.hasNext() ){ 8. Service s = (Service) services.next(); 9. forAllResult = forAllResult && (s.getPointsEarned() == 0); 10. } 11. if ( forAllResult ){ 12. selectResult.add(p); 13. } 14. } 15. return result;