Kennisacquisitie en - modellering Rogier van Eijk

Basis van het kennismodelleren

• Domeinkennis• Inferentiekennis• Taakkennis• Zelftest

deels gebaseerd op boek en slides ‘The CommonKADS Methodology’

1Basis van kennismodelleren

MODELLEREN VAN CONTEXT

Vereenvoudigd voorbeeld

Basis van kennismodelleren 2

De expert

• Ademtherapeut en –trainer– (health en wellness)


OM-1: Organisatie

1. zzp-er in netwerk:– huisarts, specialist, fysiotherapeut, psycholoog,

collega’s, cliënten

2. Probleem: – Groot gebrek aan kennis over ademtraining

• bij het grote publiek, cliënten, zelfs medici– Expert komt tijd te kort om zijn kennis over te dragen

3. Oplossing: – kennissysteem dat ademtraining ondersteunt


OM2: Proces


diagnosedoorarts

diagnose door

therapeut

opstellen

programma

instructie en

feedback

OM3: Process breakdown


No Task Performed by

Where? Knowledge asset

Inten-sive?

Signifi-cance

1 Diagnose door arts

Huisarts Praktijk huisarts

Medisch algemeen

Ja 3

2 Diagnose door therapeut

Adem-therapeut

Lesruimte Ademhaling Ja 3

3 Opstellen programma

Adem-therapeut

Lesruimte Oefen-programma’s

Ja 4

4 Instructie en feedback

Adem-therapeut

Lesruimte of huis client

Training en coaching

Ja 5

OM4: Knowledge assets


Knowledge asset

Posessed by

Used in Right form?

Right place?

Right time?

Right quality?

Medisch algemeen

Huisarts Diagnose door arts

Ja Ja Ja Niet altijd

Ademhaling Therapeut Diagnose door therapeut

Niet altijd

Niet altijd

Ja Ja

Oefenpro-gramma’s

Therapeut Opstellen trainingspro-gramma

Niet altijd

Niet altijd

Ja Ja

Training en coaching

Therapeut Instructie en feedback

Ja Ja Ja Ja

OM5: Feasibility en acties

• Goede ademhaling is essentieel voor mentale, emotionele en fysieke gezondheid

• Er ontbreekt benodigde kennis en ervaring bij cliënten, therapeuten (in opleiding) en zelfs bij medici

• Er is met name een groeiende vraag naar een kennissysteem dat ademhalingstraining vanuit het oogpunt van de therapeut als gebruiker ondersteunt


KENNISMODELDeze week



Kennismodel

• gespecialiseerde ‘tool’ voor de specificatie van kennisintensieve taken

• abstraheert van communicatie-aspecten

• centraal thema is: hergebruik


Relatie met andere modellen

organisatiemodeltaakmodel

agentmodelkennis-intensieve

taak

communicatie-model

kennis-model

‘design’model

requirements-specificatie

voor interactiefuncties

requirements-specificatie

voor redeneerfuncties

taak geselecteerd in ‘feasibility’-studieen verder gedetailleerd in

taak- en agentmodellen


De term “kennis”

• “informatie over informatie”– voorbeeld: subklassehierarchie van objecttypes

• geen harde grens getrokken tussen informatie en kennis– zienswijze: kennis is “betekenisvolle informatie”

• doel: “kennisintensieve”-systemen– werken met grote hoeveelheden betekenisvolle

informatie


Uitdagingen in het specificeren van kennis

person

ageincome

loan

amountinterest

Jan heeft een lening van €1,750Harrie heeft een lening van € 2,500

Een persoon met een lening zou minstens 18 jaar oud moeten zijnEen persoon met een inkomen van maximaal € 10.000 kan maximaal een lening van € 2.000 krijgenEen persoon met een inkomen tussen € 10.000 en € 20.000 kan een maximum lening krijgen van €3.000.

INFORMATIE

KENNIS

has loan


Structureren van een kennisbank

Rule 1: IF ... THEN ...Rule 2: IF ... THEN ...Rule 3: IF ... THEN ...

Rule 12: IF ... THEN ...

Rule 4: IF ... THEN ...Rule 5: IF ... THEN ...Rule 6: IF ... THEN ...Rule 7: IF ... THEN ...Rule 8: IF ... THEN ...Rule 9: IF ... THEN ...Rule 10: IF ... THEN ...Rule 11: IF ... THEN ...

<plus many others>

één plattekennisbank

meerdere regelverzamelingenbevatten regelsmet een gelijke structuur

rules of type A

rules of type D

rules of type B

rules of type C


Kenniscategorieën

• Taakkennis– doelgericht– functionele decompositie

• Domeinkennis – relevante domeinkennis en informatie– statisch

• Inferentiekennis– basisredeneerstappen over het kennisdomein

die in een taak kunnen worden uitgevoerd


Overzicht kennismodel

Ziekte(type)

Symptoom(type)

Test(type)

hypothesize(inferentie)

verify(inferentie)

DIAGNOSE(taak)

Taakkennistaakdoelentaakdecompositietaakcontrole

Inferentiekennisbasisinferentiesrollen

Domeinkennisdomeintypesdomeinregelsdomeinfeiten


Voorbeeld: autodiagnose

benzinetankleeg

acculeeg

accumeternul

benzinemeternul

poweruit

gedrag motorstart niet gedrag motor

stopt ermee

benzine in motorfalse

zekeringgesprongen

inspectie van zekeringkapot

1

2 3

4 5

6

7 8 9

Voorbeeld: ademhaling


borst beweegt nauwelijks

buik beweegt nauwelijks

frozen breathing

chest breathing

buik in op inademing

reverse breathing

breath holding pattern

buik uit op uitademing

DOMEINKENNIS



Domeinkennis

• domeinschema– schematische beschrijving van kennis- en

informatietypes– vergelijkbaar met datamodel– gedefinieerd dmv van domeinconstructen

• kennisbank– verzameling van kennisinstanties– vergelijkbaar met inhoud van database– maar: van statische aard


Constructen voor domeinschema’s

• Concept– vgl. objectklasse (zonder operaties)

• Relatie– vgl. associatie

• Attribuut– primitieve waarden

• Regeltype– introduceert expressies => geen SE equivalent


Concept en attribuut

• “Concept” beschrijft een verzameling objecten/instanties

• Georganiseerd in concepthiërarchieën

• Kunnen een willekeurig aantal attributen hebben

• Een attribuut refereert naar een waarde• Waardes zijn atomair en gedefinieerd via waardetypes

• Attributen mogen niet naar andere concepten refereren– gebruik hiervoor het relatie-construct


Voorbeeld: concepten autodomein

VALUE-TYPE dial-value; VALUE-LIST: {zero, low, normal}; TYPE: ORDINAL;END VALUE-TYPE dial-value;

CONCEPT gas dial; ATTRIBUTES: value: dial-value;END CONCEPT gas-dial; CONCEPT fuel-tank;

ATTRIBUTES status: {full, almost-empty, empty};END CONCEPT fuel-tank;

gas dial

value: dial-value

fuel tank

status: {full, almost-empty, empty}


Voorbeeld: concept ademhaling

VALUE-TYPE buikbeweging; VALUE-LIST: {in, uit, geen}; TYPE: NOMINAL;END VALUE-TYPE buikbeweging;

CONCEPT buik; ATTRIBUTES: inademing: buikbeweging;

END CONCEPT buik;

buik

inademing: buikbeweging

uitademing: buikbeweging;

uitademing: buikbeweging


Example: subtypes autodomeincar state

status: universalobservable: boolean

invisiblecar state

observable: {false}

visiblecar state

observable: {true}

car observable

value: universal

fuel tank

status: {full, almost-empty, empty}

battery

status: {normal, low}

fuse

status: {normal, blown}

gas in engine

status: boolean

power

status: {on, off}

engine behavior

status: {normal, does-not-start, stops}

fuse inspection

value: {normal, broken}

gas dial

value: dial value

battery dial

value: dial-value


Voorbeeld: subtypes ademhaling

breaths per minute: natural

breath holdingpattern

frozen breathing

CONCEPT frozen breathing; DESCRIPTION: “oppervlakkig ademen"; SUB-TYPE-OF: breath holding pattern;

;END CONCEPT house;

CONCEPT Hyperventilation; DESCRIPTION: “te veel ademen"; SUB-TYPE-OF breath holding pattern; ATTRIBUTES:

breaths per minute: NATURAL;END CONCEPT hyperventilation;

hyperventilation


Relatie

• typisch tussen concepten– elke ariteit (plaatsigheid)– specificatie van kardinaliteit

• speciale constructie voor binaire relaties

• relaties kunnen attributen hebben

• reificatie van een relatie is toegestaan– relatie fungeert als een concept– vgl. associatieklasse in UML– een vorm van hogere orde relaties


Voorbeeld: relatie autodomein

car person

car person

ownership

ownershippurchase date: date;

a)

b) car personowned-by

c)

0+ 0-1


N-plaatsige relatie

agent

nameposition

observation

valuedatetime

observable

type

location

departmenthospital

patient

namediagnosis


Modelleren van regels

• regels zijn een veelvoorkomende vorm van symbolische kennis

• kennisanalyse is er op gericht regels te vinden met een gemeenschappelijke structuur

• een regel is een instantie van een regeltype

Voorbeeld ademhaling

– frozen breathing -> borst beweegt nauwelijks– frozen breathing -> buik beweegt nauwelijks

– chest breathing -> buik beweegt nauwelijks– chest breathing -> schouders omhoog op inademing

– reverse breathing -> buik in op inademing– reverse breathing -> buik uit op uitademing

• patroon: breath holding pattern -> lichaamsobservatie

Voorbeeld ademhaling II

– frozen breathing -> zachte beweging– frozen breathing -> psychotherapie

– chest breathing -> losmaken schouders– chest breathing -> leren gebruiken van middenrifspier

– reverse breathing -> observeren van de ademhaling– reverse breathing -> samengaan ademen en beweging

• patroon: breath holding pattern -> oefenprogramma


Regeltype

• modelleert een relatie tussen expressies over ‘feature’-waardes (attribuutwaarden)

gas-dial.value = zero -> fuel-tank.status = empty

• modelleert een verzameling van echte-wereld “regels” met een overeenkomende structuur

• afhankelijkheid is meestal niet strict logisch (= implicatie)– specificeer een ‘connection symbol’


Voorbeeld regeltype

loanconstraint

restricts

person.income <= 10,000 RESTRICTS loan.amount <= 2,000

person.income > 10,000 AND person.income <= 20,000 RESTRICTS loan.amount <= 3,000

person

name: stringincome: integer

loan

amount: integerinterest-rate: number

1+


Structuur van regeltypen

• <antecedent> <connection-symbol> <consequent>

• Voorbeeld regel:

fuel-supply.status = blocked CAUSES

gas-in-engine.status = false;

• flexibel gebruik


Regeltypes voor autodiagnose

invisiblecar state car state

car observable

invisiblecar state

manifestationrule

statedependency

causes

hasmanifestation

1 1

11


Kennisbank• partitie, bevat instanties van kennistypes

– regeltype instanties = “regels”

• structuur:– USES: <types used> from <schema>– EXPRESSIONS: <instances>

• representatie van instanties:– intuitieve natuurlijke taal

• connection symbol– formele taal (zie ook: appendix van boek)


Voorbeeld kennisbankKNOWLEDGE-BASE car-network;

USES: state-dependency FROM car-diagnosis-schema, manifestation-rule FROM car-diagnosis-

schema; EXPRESSIONS: /* state dependencies */

fuse.status = blown CAUSES power.status = off; battery.status = low CAUSES power.status =

off; …./* manifestation rules */ fuse.status = blown HAS-MANIFESTATION

fuse-inspection.value = broken; battery.status = low HAS-MANIFESTATION

battery-dial.value = zero; …..END KNOWLEDGE-BASE car-network;

INFERENTIEKENNIS



Inferentiekennis

• beschrijft het laagste niveau van functionele decompositie

• basis informatieverwerkende eenheden: – inferentie => redeneren– transferfunctie => communicatie met andere agenten

• waarom speciale status? – indirect gerelateerd aan domeinkennis– maakt hergebruik van inferenties mogelijk


Voorbeeldinferentie: cover

complaint hypothesiscover

causalmodel

my car does not start fuel tank is empty

fuel tank is empty leads to lack of gas in engineif there is no gas in the engine, then the car does not start

dynamic input role dynamic output role

static role

inference


Inferentie

• volledig beschreven via een declaratieve specificatie van de eigenschappen van de input/output

• interne proces van de inferentie is een black box– verdere details niet relevant voor kennismodel

• Input/output beschreven via “role names”– functionele namen die geen deel uitmaken van het

kennisdomein/domeinschema

• richtlijn om te stoppen met decompositie: uitleg


Kennisrol

• Functionele naam voor data/kenniselementen

• Naam beschrijft de “rol” van het element in het redeneerproces

• Expliciete ‘mapping’ op domeintypes

• Dynamische rol: variërende input/output

• Statisch rol: invariante input – vgl. een kennisbank


Inferentie: voorbeeld

INFERENCE cover; ROLES:

INPUT: complaint; OUTPUT: hypothesis; STATIC: causal-model;

SPECIFICATION: "Each time this inference is invoked, it generates a candidate solution that could have caused the complaint.";

END INFERENCE cover;


Dynamische kennisrollen: vb

KNOWLEDGE-ROLE complaint; TYPE: DYNAMIC; DOMAIN-MAPPING: visible-state;

END KNOWLEDGE-ROLE complaint;

KNOWLEDGE-ROLE hypothesis; TYPE: DYNAMIC; DOMAIN-MAPPING: invisible-state;

END KNOWLEDGE-ROLE hypothesis;


Voorbeeld statische kennisrol

KNOWLEDGE-ROLE causal-model; TYPE: STATIC; DOMAIN-MAPPING: state-dependency FROM car-network;

END KNOWLEDGE-ROLE causal-model;


Transferfuncties

• brengt een stukje informatie over tussen de redenerende agent en een andere agent

• vanuit het perspectief van kennismodelleren: black box– alleen naam en input/output

• gedetailleerde specificatie van transferfuncties is onderdeel van het communicatiemodel

• standaardnamen


Types transferfuncties

obtain receive

present provide

systeminitiative

externalinitiative

externalinformation

internalinformation


Inferentiestructuur

• gecombineerde verzameling van inferenties specificeert het basisinferentievermogen van het kennissysteem

• grafische representatie: inferentiestructuur

• legt ‘constraints’ op voor de controle-‘flow’


Voorbeeld: inferenties auto

complaint

cover

predict compare

obtain

expectedfinding

actualfinding

result

causal model

manifestation model

hypothesis


Gebruik van inferentiestructuur

• Belangrijk communicatiemiddel tijdens het ontwikkelproces

• Dikwijls provisorisch

• Kan moeilijk te begrijpen zijn vanwege “vage” (niet domein-specifieke termen)

• Vaak nuttig om te annoteren met domein-specifieke voorbeelden


Geannoteerde inferentiestructuur

complaint

cover

predict compare

obtain

expectedfinding

actualfinding

result

causal model

manifestation model

hypothesis

engine doesnot start

state dependencyrules

empty fuel tank gas dial = zero/low

gas dial = normal

not equalmanifestation

rules


Hergebruik van inferenties

• Standaardverzameling van inferenties?!– lastig onderwerp

• See catalogus in hfdst. 13

• Gebruik zoveel mogelijk de standaardnamen

TAAKKENNIS



Taakkennis

• beschrijft doelen– diagnosticeer een patiënt zodat deze behandeld kan

worden– beoordeel een hypotheekaanvraag zodat het risico om

geld te verliezen zo laag mogelijk is– ontwerp een lift voor een nieuw gebouw

• beschrijft strategieën die gebruikt kunnen worden om doelen te realizeren

• typisch beschreven op hiërachische wijze


Taakdecompositie voor autodiagnose

diagnosis

diagnosis through

generate-and-test

obtaincover

predict

task

task method

compare

decomposition

inferences

transfer function


Taak

• Beschrijving van de input/output

• Belangrijkste verschil met traditionele functies:

– gemanipuleerde data worden (ook) in een domein-onafhankelijke manier beschreven

– voorbeeld: de output van een medische diagnose zou niet “ziekte” zijn maar een abstracte naam als “foutcategorie”


VoorbeeldtaakTASK diagnosis; GOAL: "Find a likely cause for the complaint of the user";

ROLES:INPUT: complaint: "Complaint about the behavior of the

system"; OUTPUT: fault-category: "A hypothesis explained by the

evidence"; evidence: "Set of observations obtained during the

diagnostic process"; SPEC: "Find an initial state that explains the complaint

and is consistent with the evidence obtained";END TASK diagnosis;


Taakmethode

• beschrijft de realisatie van een taak als een decompositie in subfuncties– subfuncties: een andere taak, inferentie, transferfunctie

• hoofdbestanddeel van een methode: “controlestructuur”– volgorde van subfuncties– klein programma– beschrijft de redeneerstrategie

• additionele taakrollen– om tussentijdse redeneerresultaten in op te slaan


Voorbeeld taakmethode

TASK-METHOD diagnosis-through-generate-and-test; DECOMPOSITION:

INFERENCES: cover, predict, compare;TRANSFER-FUNCTIONS: obtain;

ROLES:INTERMEDIATE:

expected-finding: "The finding predicted, in case the hypothesis is true";

actual-finding: "The finding actually observed";


Voorbeeld methodecontrole CONTROL-STRUCTURE:

REPEAT cover(complaint -> hypothesis);

predict(hypothesis -> expected-finding); obtain(expected-finding -> actual-finding); evidence := evidence ADD actual-finding; compare(expected-finding + actual-finding -> result);

UNTIL result = equal or “no more solutions”;

END REPEAT IF result == equal

THEN fault-category := hypothesis; ELSE "no solution found"; END IF


UML activiteitendiagram voor methodecontrole

cover

predict

obtain compare

[no more solutionsof cover]

[new solutionof cover]

[result = equal]

[result = not equal]

solution found

no solution found

startdiagnosisthrough

generate-and-test


Elementen van controlestructuur I

• “procedure”-aanroepen: – taken, transferfuncties, inferenties

• ‘role operations’– assign, add/append, delete/subtract, retrieve, …

• controleprimitieven– repeat-until, while-do, foreach-do, if-then-else


Elementen van controlestructuur II

• condities:– logische expressies over rollen:– voorbeeld:

• until differential = empty

• twee speciale condities:– has-solution

• invocatie van inferentie die mogelijk faalt

– new solution• invocatie van inferentie die meerdere keren een

oplossing kan geven, bijv ‘cover’ in autodiagnose


Inferentie of taak?

• Criterium:

– “Als voor het uitleggen van het gedrag van het gehele systeem, het interne gedrag van een bepaalde functie belangrijk is, dan dient men deze functie als een taak te modelleren”

• Tijdens ontwikkelproces: provisorische inferentiestructuren

• Functie = taak of inferentie (of transferfunctie)


Kennismodel tov SE analysemodel

• “Data model” bevat “data over data” – = knowledge

• Functies worden onafhankelijk van datamodel beschreven– maakt hergebruik van redeneerfuncties mogelijk

• Nadruk op “interne controle” – strategie van het redeneerproces

• Kennismodel abstraheert van communicatie-aspecten


Het debat tav data en functie

DATAviewpoint

FUNCTIONviewpoint

Object-georieënteerde analyse(OMT, Booch, ....)

‘Structured Analysis’(Yourdon)

CommonKADS:scheiden functie en data

functionele decompositie is startpuntdatatypes worden afgeleid

statische informatiestructuur is startpuntfuncties gegroepeerd met datahergebruik van data/functiegroepen ("objecten")

gelijktijdige functie/data beschrijvingherbruikbare functionele decompositiesherbruikbare data/kennistypes

Samenvatting:Koppeling taak en domein• iedere inferentie uit de taakmethode• heeft kennisrollen • die worden via domain mappings• aan concepten en regeltypes gekoppeld• waarvan de daartoe behorende instanties (feiten en

regels) in de kennisbank staan.

• als hulpmiddel daarbij gebruiken we een inferentiestructuur met annotaties

ZELFTEST

Vraag 1

• Welke kennisrollen heeft een transferfunctie?

A) StatischeB) DynamischeC) Statische en dynamischeD) Noch statische noch dynamische


Vraag 2

• Worden in een kennisbank ‘domain mappings’ beschreven?

A) JaB) Nee


Vraag 3

• Zijn connectionsymbols onderdeel van een domeinschema?

A) JaB) Nee


Vraag 4

• Welke modellering is correct?

A)

B)


VALUE-TYPE buikbeweging; VALUE-LIST: {in, uit, geen}; TYPE: NOMINAL;END VALUE-TYPE buikbeweging;

VALUE-TYPE buikbeweging; VALUE-LIST: {in, uit, geen}; TYPE: ORDINAL;END VALUE-TYPE buikbeweging;

Werkcolleges

1. bestuderen gehele practicumopdracht, werken aan opdracht 1 en opstarten opdracht 2

2. afronden opdracht 1, werken aan opdracht 2

3. afronden opdracht 2, opstarten opdracht 3

4. werken aan opdracht 3, verwerken feedback opdracht 2 (aanwezigheid verplicht)

5. afronden opdracht 3, opstarten opdracht 46. werken aan opdracht 4, verwerken feedback opdracht 3 (aanwezigheid

verplicht)7. afronden opdracht 4, opstarten opdracht 5 en 6 8. werken aan opdracht 5 en 6, verwerken feedback opdracht 4

(aanwezigheid verplicht)


Deadlines

• Wo 11 feb 2015: opdracht 1 (23.59 uur)

• Wo 18 feb 2015: opdracht 2 (23:59 uur)

• Wo 4 mrt 2015: opdracht 3 (23:59 uur)

• Wo 25 mrt 2015: opdracht 4 (23:59 uur)

• Ma 6 apr / wo 8 apr 2015: presentatie

• Wo 15 apr 2015: eindrapport (18:00 uur)


Kennisacquisitie en - modellering Rogier van Eijk

Documents

Transcript of Kennisacquisitie en - modellering Rogier van Eijk