Advanced Knowledge Modeling Additional domain constructs Domain-knowledge sharing and reuse Catalog of inferences Flexible use of task methods

Advanced Knowledge Modeling

Additional domain constructs

Domain-knowledge sharing and reuse

Catalog of inferences

Flexible use of task methods

Advanced knowledge modelling

2

Viewpoints

need for multiple sub-type hierarchies sub-type-of = "natural" sub-type dimension

typically complete and total

other sub-type dimensions: viewpoint represent additional ways of "viewing" a certain concept

similar to UML "dimension" helps to introduce new vocabulary through multiple

specialization ("inheritance")


3

Two different organizations of the disease hierarchy

infection

meningitis pneumonia

bacterialpneumonia

acute viralpneumonia

chronic viralpneumonia

viralpneumonia

infection

meningitis pneumonia

chronicpneumonia

acute viralpneumonia

acute bacterialpneumonia

acutepneumonia


4

Viewpoint specification

concept infection;super-type-of: meningitis, pneumonia;viewpoints:

time-factor:

acute-infection, chronic-infection;causal-agent:

viral-infection, bacterial-infection;

end concept infection;concept acute-viral-meningitis;

sub-type-of: meningitis, acute-infection, viral-infection;

end concept acute-viral-meningitis;


5

Viewpoint: graphical representation

infection

acuteinfection

chronicinfection

viralinfection

bacterialinfection

meningitispneumonia

acute viralmeningitis

causal agenttime factor


6

Expressions and Formulae

need for expressing mathematical models or logical formulae

imported language for this purpose Neutral Model Format (NMF)

used in technical domains see appendix


7

Rule instance format

See appendix for semi-formal language Guideline: use what you are comfortable with May use (semi-)operational format, but for conceptual

purposes! Implicit assumption: universal quantification

person.income < 10.000 suggests loan.amount < 1.000

“for all instances of person with an income less than 10.00 the amount of the loan should not exceed 1.000


8

Inquisitive versus formal rule representation

Intuitive rule representationresidence-application.applicant.household-type = single-personresidence-application.applicant.age-category = up-to-22residence-application.applicant.income < 28000residence-application.residence.rent < 545 INDICATESrent-fits-income.truth-value = true;

Formal rule representationFORALL x:residence-application x.applicant.household-type = single-person x.applicant.age-category = up-to-22 x.applicant.income < 28000 x,residence.rent < 545 INDICATES rent-fits-income.truth-value = true;


9

Using variables in rules to eliminate ambiguities

/* ambiguous rule */employee.smoker = true ANDemployee.smoker = false IMPLIES-CONFLICTsmoker-and-non-smoker.truth-value =true;

/* use of variables to remove the ambiguity */VAR x, y: employee;x.smoker = true ANDy.smoker = false IMPLIES-CONFLICTsmoker-and-non-smoker.truth-value =true;


10

Constraint rules

Rules about restrictions on a single concept No antecedent or consequent

component

componentconstraint

RULE-TYPE component-constraint; CONSTRAINT: component;END RULE-TYPE component-constraint;

Example constraints (car is a component):

car.weight < 500 kgcar.length < 5.5 m


11

Knowledge sharing and reuse: why?

KE is costly and time-consuming general reuse rationale: quality, etc

Distributed systems knowledge base partitioned over different locations

Common vocabulary definition Internet search, document indexing, …. Cf. thesauri, natural language processing

Central notion: “ontology”


12

The notion of ontology

Ontology =

explicit specification of a shared conceptualization that holds in a particular

context”

(several authors)

Captures a viewpoint an a domain: Taxonomies of species Physical, functional, & behavioral system descriptions Task perspective: instruction, planning


13

Ontology should allow for “representational promiscuity”

ontology

parameterconstraint -expression

knowledge base A

cab.weight + safety.weight = car.weight:

cab.weight < 500:

knowledge base B

parameter(cab.weight)parameter(safety.weight)parameter(car.weight)constraint-expression(

cab.weight + safety.weight = car.weight)constraint-expression(

cab.weight < 500)

rewritten as

viewpointmapping rules


14

Ontology types

Domain-oriented Domain-specific

– Medicine => cardiology => rhythm disorders– traffic light control system

Domain generalizations – components, organs, documents

Task-oriented Task-specific

– configuration design, instruction, planning

Task generalizations – problems solving, e.g. UPML

Generic ontologies – “Top-level categories”– Units and dimensions


15

Using ontologies

Ontologies needed for an application are typically a mix of several ontology types Technical manuals

– Device terminology: traffic light system– Document structure and syntax– Instructional categories

E-commerce Raises need for

Modularization Integration

– Import/export– Mapping


16

Domain standards and vocabularies as ontologies

Example: Art and Architecture Thesaurus (AAT) Contain ontological information

AAT: structure of the hierarchy Ontology needs to be “extracted”

Not explicit Can be made available as an ontology

With help of some mapping formalism Lists of domain terms are sometimes also called “ontologies”

Implies a weaker notion of ontology Scope typically much broader than a specific application domain Example: domain glossaries, WordNet Contain some meta information: hyponyms, synonyms, text


17

Ontology specification

Many different languages KIF Ontolingua Express LOOM UML ......

Common basis Class (concept) Subclass with inheritance Relation (slot)


18

Additional expressivity (1 of 2)

Multiple subclasses Aggregation

Built-in part-whole representation Relation-attribute distinction

“Attribute” is a relation/slot that points to a data type Treating relations as classes

Sub relations Reified relations (e.g., UML “association class”)

Constraint language First-order logic Second-order statements


19

Additional expressivity (2 of 2)

Class/subclass semantics Primitive vs. defined classes Complete/partial, disjoint/overlapping subclasses

Set of basic data types Modularity

Import/export of an ontology Ontology mapping

Renaming ontological elements Transforming ontological elements

Sloppy class/instance distinction Class-level attributes/relations Meta classes


20

Priority list for expressivity

Depends on goal: Deductive capability: “limit to first-order logic” Maximal content: “as much as (pragmatically) possible”

My priority list (from a “maximal-content” representative)1. Multiple subclasses

2. Reified relations

3. Import/export mechanism

4. Sloppy class/instance distinction

5. (Second-order) constraint language

6. Aggregation


21

Art & Architecture Thesaurus

Used forindexing stolen art objects in Europeanpolice

databases


22

The AAT ontology

descriptionuniverse

descriptiondimension

descriptor

value set

value

descriptorvalue

object

object type object class

classconstraint

has feature

descriptorvalue set

in dimension

instance of

class of

hasdescriptor

1+

1+

1+

1+

1+

1+


23

Document fragment ontologies: instructional


24

Domain ontology of a traffic light control system


25

Two ontologies of document fragments


26

Ontology for e-commerce


27

Top-level categories:many different proposals

Chandrasekaran et al. (1999)


28

Catalog of inferences

Inferences are key elements of knowledge models building blocks

No theory of inference types see literature

CommonKADS: catalog of inferences used in practice guideline: maintain your own catalog


29

Catalog structure

Inference name Operation

input/output features

Example usage Static knowledge

features of domain knowledge required

Typical task types in what kind of tasks can one expect this inference


30

Catalog structure (continued)

Used in template reference to template in the CK book

Control behavior does it always produce a solution? can it produce multiple solutions?

Computation methods typical algorithms for realizing the inference

Remarks


31

Inference “abstract”

Operation: input =data set, output= new given Example: medical diagnosis: temperature > 38 degrees is

abstracted to “fever” Static knowledge: abstraction rules, sub-type hierarchy Typical task types: mainly analytic tasks Operational behavior: may succeed more than once. Computational methods: Forward reasoning, generalization

Remarks:. Make sure to add any abstraction found to the data set to allow for chained abstraction.


32

Inference “cover”

Operation: given some effect, derive a system state that could have caused it

Example: cover complaints about a car to derive potential faults.

Static knowledge: uses some sort of behavioral model of the system being diagnosed. A causal network is most common. e.

Typical task types: specific for diagnosis. Control behavior: produces multiple solutions for same input. Computational methods: abductive methods, ranging from

simple to complex, depending on nature of diagnostic method Remarks: cover is an example of a task-specific inference. Its

use is much more restricted than, for example, the select inference.


33

Multiple methods for a task

Not always possible to fix the choice of a method for a task e.g. choice depends on availability of certain data

Therefore: need to model dynamic method selection Work-around in CommonKADS

introduce method-selection task


34

Dealing with dynamic method selection

associativegeneration

generatehypothesis

model-basedgeneration

generationstrategy

heuristicmatch

causalcovering

generatehypothesis

causalcovering

single methodfor hypothesis

generation

work-around for multiple methods for the same task

obtainnature of data


35

Strategic knowledge

Knowledge about how to combine tasks to reach a goal e.g. diagnosis + planning

If complex: model as separate reasoning process! meta-level planning task

Documents

Advanced Knowledge Modeling Additional domain constructs Domain-knowledge sharing and reuse Catalog of inferences Flexible use of task methods