Kennisacquisitie en -modellering

Periode 3Informatiekunde & Informatica

‘Knowledge engineering’: een inleiding

• Hoe, wat en waarom van KE• Practicumopdracht• Opzet van de module• Zelftest

deels gebaseerd op boek en slides ‘The CommonKADS Methodology’

WAAROM?Knowledge engineering

Waarom KE?

• in veel ICT-systemen zit tegenwoordig kennis ingebouwd

• Vb. serious games, simulaties, trainingsomgevingen, e-learning systemen, coaching systemen, beslissingsondersteunende systemen, bewakingssystemen etc.

• Het gaat om expertkennis maar ook kennis over gebruikers, hun werk- en/of leefomstandigheden, bezigheden en taken, etc.

Waarom KE (2)?

En ook omdat:

• kennis zit in mensen, hoe kan een organisatie zijn kennis behouden?

 • kennis is aanwezig in een organisatie, hoe kan deze worden

gedeeld? • er ontbreekt kennis in een organisatie, wat is er precies mis

en hoe kan het gat worden gevuld?

Waarom KE (3)?

Voor het oplossen van problemen veroorzaakt door het ontbreken van kennis in een expliciete vorm.

En verder: NBIC convergentie

• Nanotechnologie

• Biologie

• Informatietechnologie

• Cognitieve wetenschappen

-> Informatietechnologie raakt vervlochten met andere kennisgebieden

WAT?Knowledge engineering

Data, informatie & kennis

• Data– ongeïnterpreteerde signalen

. . . - - - . . .• Informatie

– betekenis toegevoegd aan dataS O S

• Kennis– doel en competentie toegevoegd aan informatie – mogelijkheid tot actie over te gaan

om hulp gevraagd ® begin reddingsoperatie

‘Knowledge engineering’

proces van het– eliciteren,– structureren,– formalizeren en– operationalizeren van

de informatie en kennis betrokken in een kennisintensief probleemdomein

met als doel een programma te bouwen dat een moeilijke taak vakkundig kan uitvoeren

Wat zijn de problemen van KE?

• ingewikkelde, complexe informatie en kennis zijn moeilijk te observeren

• experts en andere bronnen verschillen

• meerdere representaties:– textboeken– grafische representaties– vaardigheden– heuristieken

Wat is het belang van goed KE?

• Kennis is waardevol en blijft vaak langer bestaan dan een bepaalde implementatie– kennismanagement

• Fouten in een kennisbank kunnen tot serieuze problemen leiden

• Eisen van uitbreidbaarheid en onderhoud– veranderen in de loop van de tijd

HOE?Knowledge engineering

Een korte geschiedenis van kennissystemen

1965 19851975 1995

general-purpose zoekmachines

(GPS)

eerste generatie regel- gebaseerde systemen

(MYCIN, XCON)

gestructureerde

(early KADS)

volwassen methodologieën(CommonKADS)

=> van kunst naar discipline =>

methoden

Eerste generatie expertsystemen

• oppervlakkige kennisbank

• enkel redeneerprincipe

• uniforme representatie

• beperkte uitlegvaardigheden

redeneermechanisme

kennisbank

werktop

‘Transfer View’ van KE

• Extraheren van kennis van een menselijke expert– “delven naar de juwelen in

het hoofd van de expert”

• Overbrengen van de expertkennis in een systeem – expert wordt gevraagd

welke regels van toepassing zijn

– vertaling van natuurlijke taal naar een regelformaat

Problemen met de ‘transfer view’

De ‘knowledge providers’, de ‘knowledge engineer’ en de ontwikkelaar van het kennissysteem zouden een

– gemeenschappelijk beeld van het proces van probleemoplossen moeten delen

– alsook een gemeenschappelijk vocabulair

om van de ‘knowledge transfer’ een geschikte manier van ‘knowledge engineering’ te maken

‘Rapid Prototyping’

• Positief– legt nadruk op elicitatie en interpretatie– motiveert de expert– (overtuigt het management)

• Negatief– groot gat tussen verbale data and implementatie– architectuur beperkt de analyse

• dus model vervormt– moeilijk weg te gooien

Methodologische pyramide

wereldbeeld

theorie

methodes

tools

gebruikfeedbackcase studies

applicatie projecten

CASE toolsimplementatie-omgevingen

life-cycle model, procesmodel,richtlijnen, elicitatietechnieken

graphische / textuele notatiesworksheets, documentstructuur

modelgebaseerde ‘knowledge engineering’hergebruik van kennispatronen

Wereldbeeld: Modelgebaseerde KE

• De keuzeruimte van ‘knowledge engineering’ kan tot op zekere hoogte onder controle worden gehouden door het gebruik van een aantal modellen.

• Elk model benadrukt bepaalde aspecten van het systeem en abstraheert van andere aspecten.

• De modellen vormen een decompositie van het proces van ‘knowledge engineering’. Tijdens het bouwen van een model kunnen andere aspecten tijdelijk genegeerd worden.

CommonKADS principes

• ‘Knowledge engineering’ is wat anders dan het delven in het hoofd van een expert. Het bestaat uit het bouwen van verschillende modellen van menselijke kennis.

• Het ‘knowledge-level’- principe: tijdens het modelleren van kennis, concentreer je op de conceptuele structuur van kennis, en laat de programmeerdetails voor later.

• Kennis heeft een stabiele interne structuur die analyseerbaar is door het onderscheiden van specifieke kennistypes en kennisrollen.

CommonKADS theorie

• De constructie van een systeem bestaat vooral uit een aantal modellen die samen (een deel van) het product van een project vormen.

• Geeft de ontwikkelaar een verzameling van model ‘templates’.

• Deze ‘template’-structuur kan verder configureert, verfijnt en ingevuld worden tijdens het project.

• De mate van detailering en verfijning hangt af van de specifieke context van een project.

CommonKADS Modelverzameling

OrganizationModel

TaskModel

AgentModel

KnowledgeModel

CommunicationModel

DesignModel

Context

Concept

Artefact

Modelverzameling overzicht (1)

• ‘Organization model’– ondersteunt de analyse van een organisatie– doel is het ontdekken van problemen,

mogelijkheden en mogelijke impact van een KBS (kennisgebaseerd systeem)

• ‘Task model’– beschrijft taken die uitgevoerd of zullen uitgevoerd

worden binnen de organisationele omgeving• ‘Agent model’

– beschrijft bekwaamheden, normen, preferenties en permissies van agenten (agent = uitvoerder van een taak)

Modelverzameling Overzicht (2)

• ‘Knowledge model’– geeft een implementatie-onafhankelijke beschrijving van

de kennis betrokken bij een bepaalde taak

• ‘Communication model’– beschrijft de communicatieve transacties tussen

agenten

• ‘Design model’– beschrijft de structuur van het te bouwen systeem

Principes van de modelverzameling

• ‘Divide and conquer’

• Configuratie van een geschikte modelverzameling voor een specifieke applicatie

• Modelontwikkeling wordt gedreven door de doelstellingen en risico’s van het project

• Verschillende modellen kunnen gelijktijdig ontwikkeld worden

Modellen bestaan in verschillende vormen

• ‘Model template’– voorgedefinieerde, vaststaande structuur die

geconfigureerd kan worden• ‘Model instance’

– objecten die gemanipuleerd worden tijdens het project• ‘Model versions’

– versies van een modelinstantie kunnen bestaan.• ‘Multiple model instances’

– verschillende instanties kunnen ontwikkeld worden– voorbeeld: '‘huidige'' en '‘toekomstige'' organisatie

Het product

• Geinstantieerde modellen– representeren de belangrijke aspecten van de omgeving

en het ontwikkelde KBS

• Additionele documentatie – informatie die niet gerepresenteerd staat in de

ingevulde ‘model templates’ (bijv. projectmanagementinformatie)

• Software

Terminologie

• Domein– bepaald interessegebied

• bankieren, voedingsindustrie, kapotte mobiele telefoons, autoindustrie

• Taak– iets dat gedaan moet worden door een agent

• het monitoren van een process; de creatie van een plan; het analyseren van afwijkend gedrag

• Agent– the uitvoerder van een taak in een domein

• typisch een mens of een softwaresysteem

Terminologie (2)

• Applicatie– De context gegeven door de combinatie van een taak en

een domein waarin deze taak uitgevoerd wordt door agenten.

• Applicatiedomein– Bepaald interessegebied betrokken in een applicatie

• Applicatietaak– De (hoogste niveau) taak die uitgevoerd moet worden in

een bepaalde applicatie

Terminologie (3)

• Kennissysteem (KS) of kennisgebaseerd systeem (KBS)– systeem dat betrekking heeft op het oplossen van een

‘real-life’ probleem gebruik makend van kennis over het applicatiedomein en de applicatetaak

• Expertsysteem– kennissysteem dat een bepaald probleem oplost wat, als

het door een mens zou worden gedaan, de nodige expertise zou vragen

WIE?Knowledge engineering

Rollen in de ontwikkeling van KBS

• ‘knowledge provider’• ‘knowledge engineer/analyst’• ‘knowledge system developer’• ‘knowledge user’• ‘project manager’• ‘knowledge manager’

N.B. ‘many-to-many’-relaties tussen rollen en mensen

‘Knowledge provider’/specialist

• “traditionele” expert

• persoon met uitgebreide ervaring in een applicatiedomein

• kan ook een plan geven voor ‘domain familiarization’– “waar zou een beginner moeten beginnen?”

• verschillen tussen ‘providers’ komen veel voor

• hoe maak en onderhoud je een goed werkrelatie met een ‘provider’?

‘Knowledge engineer’

• specifiek soort systeemanalyst

• moet vermijden een “expert” te worden

• speelt een brugfunctie tussen toepassingsdomein en systeem

‘Knowledge-system developer’

• persoon die een kennissysteem implementeert op een bepaald platform

• moet algemene ontwerp- en implementatievaardigheden hebben

• moet ‘knowledge analysis’ begrijpen– maar slechts op een “use”-level

• deze rol wordt vaak ook door een ‘knowledge engineer’ gespeeld

‘Knowledge user’

• Primaire gebruikers– interacteren met het nieuwe systeem

• Secondaire gebruikers– worden indirect door het systeem beinvloed

• Kennis- en vaardighedenniveau is een belangrijke factor• Moet wellicht intensief met het systeem gaan

interacteren– uitleg en training

• Zijn of haar werk wordt vaak beinvloed door het systeem– houd rekening met attitude en een actieve rol

‘Project manager’

• is verantwoordelijk voor het plannen, roosteren en het monitoren van het werk

• onderhoudt contact met client

• typisch voor medium-size projecten (4-6 mensen)

• plukt de vruchten van een gestructureerde aanpak

‘Knowledge manager’

• rol op de achtergrond

• ‘monitoring’ van de organisationele doelen van – het te ontwikkelen systeem– de ontwikkelde ‘knowledge assets’

• initieert (‘follow-up’) projecten

• zou een belangrijke rol moeten spelen bij hergebruik

• zou kunnen helpen in het opzetten van een geschikt projectteam

Overzicht van rollen

knowledgeprovider/specialist

projectmanager

knowledgesystem developer

knowledgeengineer/analyst

knowledgemanager

knowledgeuser

KBS

managet

managetgebruikt

ontwerpt &implementeert

valideert

eliciteert kennis van

eliciteertrequirements

van

geeftanalysemodellen

aan

definieert strategieinititieert projectenfaciliteert distributie van kennis

PRACTICUMOPDRACHT

Practicum: doel

• ‘gap’

• menselijke (expert)kennis en ervaring

• kennissysteem

• overbruggen

• acquisitie en modellering

Practicum: stappen

1. Projectkeuze2. Analyse organisatie / context en meerwaarde3. Modellering taak4. Modellering domein en inferenties5. Terugkoppeling en afronding model6. Eindrapport met advies

Opdracht 1: Team en project

• Team

• Expert

• Domein

• Taak

• Taaktype

Wat is een geschikte expert?

Voorbeelden

• Skileraar– Keuze: ‘Wat is de beste snowboardpiste?

Voorbeelden

• Diëtiste– Waarom werkt een bepaald dieet bij een persoon niet?

Voorbeelden

• Faalangsttrainer– Wat is het meest geschikte begeleidingstraject voor een

kind / scholier met faalangst?

Voorbeelden

• Recruiter– Is een bepaald persoon geschikt voor de talentenpool?

Voorbeelden

• Inplanner– Wat is de juiste hijskraan voor een bepaald project?

Voorbeelden

• Ayurvedische arts– Taak (classificatie): ‘Wat is de dosha van deze persoon?’

Voorbeelden

• ICT-projectontwikkelaar– Beslissing: ‘Moet deze freelancer in het

contactennetwerk worden opgenomen?’

Voorbeelden

• Ambulancepersoneel– Beslissing: ‘Moet deze persoon wel of niet meegenomen

worden naar het ziekenhuis?’

Voorbeelden

• Medewerker CBR– Beoordeling: ‘Is deze vraag geschikt als

rijexamenvraag?”

Voorbeelden

• Kok– Ontwerp: ‘Stel het

nieuwe maandmenu samen.’

Kennisintensieve taken

taken waarin intensief wordt geredeneerd, verbanden worden gelegd en / of regels toegepast van de vorm:

als … dan …

knowledge-intensive

task

analytictask

classification

synthetictask

assessment

diagnosis

configurationdesign

planning

scheduling

assignment

modelling

prediction

monitoring

design

Taaktypen

Taaktypen: tegenvoorbeelden

• Coaching• Recruiting• Competentiemanagement• Helpdesk• Projectmanagement• Systeembeheer• Administratie• Accountmanagement• IT consultancy

-> nog te weinig toegespitst (nog niet aangesloten op CommonKADS)

Succescriteria voor project

• kennisintensief • veel redeneren, denken, beslissen

• zinvol• nuttig met betrekking tot een kennisprobleem

• haalbaar• de expert is goed beschikbaar (gunfactor)

• leuk • interessant en eenvoudig doch uitdagend

Opdracht 2: Analyse organisatie / context en meerwaarde

• kennismaking• process• taken • knowledge assets• huidige situatie • toekomstige situatie• afbakening, • in- en uitvoer, • meerwaarde, • (on)mogelijkheden • begrippenlijst

CommonKADS Worksheets Organization Model

Problems &

Opportunities

GeneralContext

(Mission,Strategy,

Environment,CSF's,...)

PotentialSolutions

OM-1 OM-2

OrganizationFocus AreaDescription:

Structure

Process

People

Culture & Power

Resources

Knowledge

OM-3 OM-4

ProcessBreakdown

KnowledgeAssets

Worksheets

• OM-1: Probleem• OM-2: Proces• OM-3: Taken• OM-4: Kennis• OM-5: Project• TM-1: Taak in detail• TM-2: Kennis in detail• AM: Betrokkenen• OTA: Veranderingstraject

Steeds meer inzoomen

• het onderzoeksterrein stelselmatig steeds verder afbakenen en inzoomen op de kern van de zaak

• hulpmiddel: een serie afhankelijke worksheets

bepalen meerwaarde project

Opdracht 3: Modellering taak

• protocol analyse • transcriptie • activity diagram • decompositie • kennisrollen • besturingsstructuur• domeinonafhankelijk

Voorbeeld tussenproduct opdr 3

Opdracht 4: Modellering domein en inferenties

• concepten • regeltypes • domeinschema • kennisbank • repertory grid • inferenties • transferfuncties • kennisrollen • inferentiestructuur• domain mapping

Opdracht 5 en 6: Afronding en eindrapport

• terugkoppeling• afronding model• kennismodel• organisatiemodel • overzicht elicitatiemethoden

– motivatie – materiaal – procedure – resultaten– gebruik– evaluatie

• advies

Projectvoorbeelden

• goede voorbeelden– waarom goed?

• kennisintensief• herhaling / routine• aansluiting bij taaktypen

• slechte voorbeelden– waarom slecht?

• niet aangesloten bij CommonKADS• te groots, abstract, uiteenlopend, vaag, …

OPZET VAN MODULE

Leerdoelen

Vaardigheden

het toepassen van methoden en technieken van kennisacquisitie; het ontwikkelen van een organisatie- en een kennismodel;

Kennis

theoretische aspecten van kennisacquisitie en -modelleren en, in breder verband, het ontwikkelen van kennissystemen.

Uitdagingen (1)

• knowledge engineering is waarschijnlijk anders dan dat je gewend bent

• het duurt even voordat je de methode ‘snapt’

• niet-ingewijden:– lijkt het nodeloos ingewikkeld– raken verstrikt in details– verliezen het overzicht– weten niet meer waar ze mee bezig zijn– weten niet meer waar het naar toe moet

Uitdagingen (2)

• acquisitie: inzicht krijgen in een onbekend domein/vakgebied

• elicitatie: boven water krijgen van kennis• modellering: kennis computationeel maken • methodologie: geen hap snap maar het consequent

toepassen en geheel uitwerken (behalve implementatie) van één methode (CommonKADS)

• creativiteit: uniek en relevant project maken

Boek

De practicumopdracht

Lijkt op een wettekst van requirements

practicumbegeleiding

Simon Rosman Pepijn Gramberg

Werkcolleges

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

2. afronden opdracht 1, werken aan opdracht 23. afronden opdracht 2, opstarten opdracht 34. 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)

Inleveren via submit

• Behalve opdracht 1: via een googledocs-document

College-onderwerpen

1. Introductie (hfdst 1 en 2)

2. Context models & knowledge management (hfdst 3 en 4)

3. Knowledge model basics (hfdst 5)

4. Knowledge model construction (hfdst 7 en 8)

5. Template knowledge models: analysis (hfdst 6, 1e deel) 6. Template knowledge models: synthesis (hfdst 6, 2e deel)

7. Communication & advanced modelling (hfdst 9, 13)

Raadpleeg geregeld het uitgewerkte voorbeeld in Hoofdstuk 10 vh boek

Becijfering en aanvullende toets

• Cijfer: gemiddelde van practicum (PR) en tentamen (T):

(0.5 * PR) + (0.5 * T)

waarbij zowel PR als T voldoende (dwz 5.5 of hoger) zijn.

• Het tentamen kan herkanst worden via een aanvullende toets (AT):

(0.5 * PR) + (0.5 * AT)

waarbij zowel PR als AT voldoende dienen te zijn.

http://www.cs.uu.nl/docs/vakken/kam

ZELFTEST

Vraag 1

Op welk niveau bevindt het ‘knowledge model’ zich?

A) Artefact layerB) Concept layerC) Context layer

Vraag 2

Is een kennissysteem een voorbeeld van een expertsysteem?

A) JaB) Nee

Vraag 3

Is de ‘transfer view’ onderdeel van de CommonKADS methode?

A) JaB) Nee

Vraag 4

Wat heeft meer waarde?

A) de applicatieB) de kennis

Werkcollege

11:00 – 12:45 uur

• BBG 103• BBG 106• BBG 109