Your SlideShare is downloading. ×
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
A Introduction To Common Kads
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A Introduction To Common Kads

1,827

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,827
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
38
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. A introduction to CommonKADS: structured knowledge engineering Guus Schreiber www.commonkads.uva.nl
  • 2. Activities in knowledge-system development Business context modelling Communication modelling Knowledge modelling System design
  • 3. Why context modeling?
    • Often difficult to identify profitable use of (knowledge) technology
    • Laboratory is different from the ''real'' world
    • Acceptability to users very important
    • Fielding into ongoing process not self evident
    • Often not clear what additional measures to take
  • 4. How to analyze a knowledge-intensive organization ?
    • describe organization aspects:
      • opportunity/problems portfolio
      • business context, goals, strategy
      • internal organization:
        • structure
        • processes
        • people (staff: functional roles)
        • power and culture
        • resources (knowledge, support systems, equipment,…)
    • do this for both current and future organization
      • comparison, and first decisions on where to go
  • 5. Worksheets Organization Model
  • 6. Process “Housing”
  • 7. Example OM-3 for “Housing” 5 Yes Assignment & urgency rules Residence Assignment Assigner 4. Residence assignment 5 Yes Assessment criteria Residence assignment Assigner 3. Application assessment 2 No - Residence assignment Data typist / automated telephone 2. Data entry applications 3 No - Public service Magazine editor 1. Magazine production Signifi- cance KI? Knowledge asset(s) Where Performed by Task
  • 8. Knowledge modelling
    • Specific type of conceptual modelling
      • Only gradual differences with “general” conceptual modelling
    • Knowledge modelling from scratch is time-consuming and difficult
      • Knowledge reuse is important theme
    • Patterns exist for types of problem-solving tasks
      • Base on typology of problem-solving tasks
  • 9. Analytic versus synthetic tasks
    • analytic tasks
      • system pre-exists
        • it is typically not completely "known"
      • input: some data about the system,
      • output: some characterization of the system
    • synthetic tasks
      • system does not yet exist
      • input: requirements about system to be constructed
      • output: constructed system description
  • 10. Task hierarchy
  • 11. Knowledge categories
    • Task knowledge
      • goal-oriented
      • functional decomposition
    • Domain knowledge
      • relevant domain knowledge and information
      • static
    • Inference knowledge
      • basic reasoning steps that can be made in the domain knowledge and are applied by tasks
  • 12. Knowledge model overview
  • 13. Domain knowledge
    • domain schema
      • schematic description of knowledge and information types
      • comparable to data model
      • defined through domain constructs
    • knowledge base
      • set of knowledge instances
      • comparable to database content
      • but; static nature
  • 14. Constructs for domain schema
    • Concept
      • cf. object class (without operations)
    • Relation
      • cf. association
    • Attribute
      • primitive value
    • Rule type
      • introduces expressions => no SE equivalent
  • 15. Example rule type
  • 16. Inference
    • fully described through a declarative specification of properties of its I/O
    • internal process of the inference is a black box
      • not of interest for knowledge modeling.
    • I/O described using “role names”
      • functional names, not part of the domain knowledge schema / data model
    • guideline to stop decomposition: explanation
  • 17. Example inference: cover
  • 18. Inference structure
  • 19. Task knowledge
    • describes goals
      • assess a mortgage application in order to minimize the risk of losing money
      • find the cause of a malfunction of a photocopier in order to restore service.
      • design an elevator for a new building.
    • describes strategies (methods, PSMs) that can be employed for realizing goals.
    • typically described in a hierarchical fashion:
  • 20. UML activity diagram for method control
  • 21. Assessment
    • find decision category for a case based on domain-specific norms.
    • typical domains: financial applications (loan application), community service
    • terminology: case, decision, norms
    • some similarities with monitoring
      • differences:
        • timing: assessment is more static
        • different output: decision versus discrepancy
  • 22. Example assessment task: mortgage assessment
  • 23. Mortgage domain information
  • 24. Assessment: abstract & match method
    • Abstract the case data
    • Specify the norms applicable to the case
      • e.g. “rent-fits-income”, “correct-household-size”
    • Select a single norm
    • Compute a truth value for the norm with respect to the case
    • See whether this leads to a decision
    • Repeat norm selection and evaluation until a decision is reached
  • 25. Mortgage domain knowledge
  • 26. Template (pattern) for assessment task case abstracted case norms norm value decision abstract select match specify evaluate norm
  • 27. Assessment control
  • 28. Claim handling for unemployment benefits
  • 29. Normen en beslisregels voor WW beoordeling
    • Normen:
    • Verzekerd
    • Werkloos
    • Wekeneis
    • Jareneis
    • Beslisregels
    • ALS niet verzekerd of niet werkloos of niet voldoet aan wekeneis DAN geen WW
    • ALS wel wekeneis en niet jareneis DAN korte basisuitkering
    • ALS wel jareneis DAN loongerelateerde uitkering
  • 30. In applications: typical task combinations
    • monitoring + diagnosis
      • Production process
    • monitoring + assessment
      • Nursing task
    • diagnosis + planning
      • Troubleshooting devices
    • classification + planning
      • Military applications
  • 31. Example: apple-pest management
  • 32. Summary
    • Knowledge engineering is a specialized form of software engineering
    • CommonKADS: model-based approach to knowledge engineering
    • Reuse of task-specific knowledge models is important theme
    • Knowledge model often outlives application

×