1. Designing for knowledge maturing:
from knowledge-driven software to
supporting the facilitation of
knowledge development
I-KNOW 2014, Graz, Austria
http://knowledge-maturing.com
Andreas P. Schmidt
Karlsruhe University of Applied Sciences
Christine Kunzmann
Pontydysgu Ltd.
http://employid.eu
http://learning-layers.eu

2. Trends in software engineering
 Making software engineering more responsive to change
ÞAgile software development, continuous delivery
 Making complexity of domains more manageable
ÞKnowledge-driven applications, semantic technologies
 Software engineering is a mutual learning process of
designers and users in which designing tools deepens the
understanding of the domain
2
knowledge-driven
what about agility applications?
for But

3. Background: Where we are
 Classic knowledge engineering methods are inspired by
waterfall-like models
 Emphasized strict phases and the formalization step
 Neglected the complexity of social processes that
construct a shared understanding on an ongoing basis
 Recent developments in the direction of „continuous
knowledge engineering“
 mostly based on the Wiki paradigm
3
Does it only change the engineering
process or also the design itself?

4. Knowledge Maturing Model:
How knowledge develops
4

5. Knowledge Maturing & Design Processes
 Design process itself is a knowledge maturing process in
which the knowledge how to support a domain and its
users in the best way develops
 Knowledge maturing distinguishes between the
(collective) knowledge and the artifacts used to represent
 Co-existence of different levels of maturity and formality
 Most knowledge engineering methodologies have so far
focused on phase IV and phase V, some addressed phase
III, neglecting the early phases
5

6. Typology of knowledge-based applications
 We are using a typology to illustrate the impact this
maturing process has on the design
 Design time vs. runtime
 When does knowledge become part of the application?
 Roles for developing knowledge
 Who develops knowledge? Who evolves the
representations in the application?
 Processes for developing knowledge
6

7. I. Hardcoded Knowledge
 During the requirements phase, domain knowledge is
collected by business analysts, modelled in an appropriate
way (UML & Co.) and passed on to developers
 Knowledge becomes implicit in the code
 Weaknesses:
 Responsiveness to change:
• Requires long release cycles
• cannot deal with fast-moving domains
 Knowledge ready at design-time:
• Basic assumption that knowledge can be „collected“ at design
time is fundamentally flawed: it needs to be co-constructed
7

8. 2. Descriptive Knowledge Representation
 Separate algorithms from descriptive knowledge
 Long history in computer science, especially in AI
 Two approaches
 Engineering approaches: humans create the models
 Mining approaches: algorithms create the models
• But co-construction required from a KM-perspective
• Therefore human-understandable descriptive models
 Advantages:
 Knowledge representations can become the focus of
reflection
 Functional framework can be applied to multiple domains as
domain knowledge can be exchanged.
8

9. 3. Participatory evolution
of knowledge representations
 Problem:
 Large time lag between need arising and actual change
 Motivational issues, low rates of feedback, barriers to
negotiation processes
 Increase participation through social-media inspired
approaches
 From controlled vocabularies to tagging
 Wiki-based modelling of domain knowledge
 Knowledge modeling becomes a runtime activity
 From expert-based modelling to broader range of
participants
 Impact on suitable formalism
9

10. Example: SpirOnto
 Improving spiritual care in
a multi-disciplinary setting
 Annotation of patient-care
records with an ontology
to cross-link cases and
reflect on insights
 Links observations to
concepts and possible
interventions
 Ontology can be amended
by users and is subject to
empirical research.
10
http://spironto.de

11. 4. Self-organized
knowledge modelling processes
 Problem:
 Even if knowledge modelling has become a runtime
activity, the rules and processes to regulate contributions
are still part of tool design
 But especially social media has shown: appropriation as
actual use differs from intended use so that built-in
regulations come into the way
 Therefore: socially negotiated processes:
 Gardening
 Implications:
 Tools don‘t provide processes, but support activities
 Processes are negotiated by users
11

12. Example: People Tagging
 Social media approach to competence management
 Supports a self-organized ontology maturing process
 People can be tagged, but the system suggests tags
 Users can merge and hierarchically structure tags
 Results in a SKOS ontology
 Some users assume responsibility for gardening tasks
although no formal role is prescribed.
12

13. Example People Tagging: SOBOLEO
13 http://soboleo.knowledge-maturing.com

14. 5. Facilitated knowledge processes
 Problem: Self-organized processes are a challenge for
users, increasing complexity
 We have only focussed on users, not on helping users
 Facilitation
 Human facilitation
 Facilitation through tool functionality
 Facilitation through environments
 Functionality
 Recommendations, triggers
 Negotiation spaces
 Reflection, analytics
14

15. Example: LivingDocuments
 Facilitation by overcoming social barriers of lack of
confidence to deal with sharing knowledge in early
phases
 LivingDocuments provides a collaborative editing
environment and concentrates on supporting the
negotation processes
 Currently focused on semi-structured documents
 But principle could be extended to more formalized
artefacts
 Facilitating the negotiation process by two key aspects
 Indicate maturity of contributions
 Maturity-aware creation of awareness about changes
15

16. Example: LivingDocuments (2)
16

17. Summary
17
Type Point in time Roles Processes Implications
Hardcoded knowledge design time
designer/
developer
(software engineering) -
Descriptive knowledge
representation
design time /
runtime
admin hardcoded (for admin)
separation of knowledge and
other components
Participatory
evolution of
knowledge
representations
runtime user hardcoded (for users)
knowledge representation
formalisms understandable for
end users; support for user
contributions
Self-Organized
knowledge modeling
processes
runtime user socially negotiated
support for activities instead of
processes; negotiation spaces
Facilitated knowledge
processes runtime
user +
facilitator
socially negotiated with
facilitation support
support for facilitating roles
and activities

18. Conclusions
 Do not hardcode knowledge into designs –
make software knowledge-driven
 Tear down the wall between design time and runtime -
knowledge models can be changed by users
 Let users define their social processes for developing
knowledge models - support activities, not processes
 Support facilitators in this process through analytics:
support guidance activities
Engineering and using
software is a knowledge
maturing process!
18

19. Contact
Christine Kunzmann
Pontydysgu Ltd.
Ankerstr. 47
75203 Königsbach-Stein
Tel: +49-7232-4093309
mail: kontakt@christine-kunzmann.de
http://christine-kunzmann.de
Andreas P. Schmidt
Karlsruhe University of Applied Sciences
Institute for Learning & Innovation in Networks
Moltkestr. 30
76133 Karlsruhe
phone: +49 (0)721 925-2914
mail: andreas_peter.schmidt@hs-karlsruhe.de
http://andreas.schmidt.name
http://knowledge-maturing.com