CommonKADS

Kennisacquisitie
en -modellering
Periode 3
Informatiekunde & 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’
Knowledge engineering
WAAROM?
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
Knowledge engineering
WAT?
Data, informatie & kennis
• Data
– ongeïnterpreteerde signalen
...---...
• Informatie
– betekenis toegevoegd aan data
S 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
Knowledge engineering
HOE?
Een korte geschiedenis van
kennissystemen
general-purpose
zoekmachines
(GPS)
1965
eerste generatie regelgebaseerde systemen
(MYCIN, XCON)
1975
gestructureerde
methoden
(early KADS)
volwassen
methodologieën
(CommonKADS)
1985
=> van kunst naar discipline =>
1995
Eerste generatie
expertsystemen
• oppervlakkige kennisbank
• enkel redeneerprincipe
• uniforme representatie
redeneer
mechanisme
werkt
op
• beperkte
uitlegvaardigheden
kennisbank
‘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
case studies
applicatie projecten
gebruik
CASE tools
implementatie-omgevingen
tools
life-cycle model, procesmodel,
richtlijnen, elicitatietechnieken
methodes
graphische / textuele notaties
worksheets, documentstructuur
theorie
modelgebaseerde
‘knowledge engineering’
hergebruik van kennispatronen
wereldbeeld
feedback
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
Context
Concept
Artefact
Organization
Model
Knowledge
Model
Task
Model
Agent
Model
Communication
Model
Design
Model
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
Knowledge engineering
WIE?
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
knowledge
manager
definieert strategie
inititieert projecten
faciliteert distributie van kennis
knowledge
provider/
specialist
eliciteert kennis van
valideert
eliciteert
requirements
van
knowledge
engineer/
analyst
managet
project
manager
geeft
analysemodellen
aan
KBS
managet
gebruikt
knowledge
user
ontwerpt &
implementeert
knowledge
system developer
PRACTICUMOPDRACHT
Practicum: doel
• ‘gap’
• menselijke (expert)kennis en ervaring
• kennissysteem
• overbruggen
• acquisitie en modellering
Practicum: stappen
1.
2.
3.
4.
5.
6.
Projectkeuze
Analyse organisatie / context en meerwaarde
Modellering taak
Modellering domein en inferenties
Terugkoppeling en afronding model
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 …
Taaktypen
knowledgeintensive
task
analytic
task
classification
diagnosis
synthetic
task
prediction
planning
design
modelling
assessment
monitoring
configuration
design
assignment
scheduling
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
OM-1
OM-2
Problems
&
Opportunities
Organization
Focus Area
Description:
General
Context
(Mission,
Strategy,
Environment,
CSF's,...)
Structure
Process
OM-3
OM-4
Process
Breakdown
People
Culture & Power
Resources
Potential
Solutions
Knowledge
Knowledge
Assets
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
Kennis
het toepassen van
methoden en technieken
van kennisacquisitie; het
ontwikkelen van een
organisatie- en een
kennismodel;
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 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 4
6. 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 layer
B) Concept layer
C) Context layer
Vraag 2
Is een kennissysteem een voorbeeld van een expertsysteem?
A) Ja
B) Nee
Vraag 3
Is de ‘transfer view’ onderdeel van de CommonKADS
methode?
A) Ja
B) Nee
Vraag 4
Wat heeft meer waarde?
A) de applicatie
B) de kennis
Werkcollege
11:00 – 12:45 uur
• BBG 103
• BBG 106
• BBG 109