Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Designing for knowledge maturing: from knowledge driven software to supporting the facilitation of knowledge development


Published on

Software engineering has been transformed in recent years by understanding the interaction with customers and the target context as an ongoing learning process. Responsiveness to change and user-centered design have been the consequences. In a similar way, knowledge and ontology engineering are undergoing fundamental changes to acknowledge the fact that they are part of a collective knowledge maturing process. We explore three examples: (i) social media based competence management in career guidance, (ii) ontology-centered reflection in multi-professional environments in palliative care, and (iii) aligning individual mindlines in pratice networks of General Practitioners. Based on these, we extract four levels of designing for knowledge maturing and associated technical implementations. This shows that future technology support should especially target facilitation of self-organized, but tool-mediated knowledge development processes, where, e.g., workplace learning analytics can play a prominent role

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Designing for knowledge maturing: from knowledge driven software to supporting the facilitation of knowledge development

  1. 1. Designing for knowledge maturing: from knowledge-driven software to supporting the facilitation of knowledge development I-KNOW 2014, Graz, Austria Andreas P. Schmidt Karlsruhe University of Applied Sciences Christine Kunzmann Pontydysgu Ltd.
  2. 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. 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. 4. Knowledge Maturing Model: How knowledge develops 4
  5. 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. 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. 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. 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. 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. 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
  11. 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. 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. 13. Example People Tagging: SOBOLEO 13
  14. 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. 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. 16. Example: LivingDocuments (2) 16
  17. 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. 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. 19. Contact Christine Kunzmann Pontydysgu Ltd. Ankerstr. 47 75203 Königsbach-Stein Tel: +49-7232-4093309 mail: 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: