<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">A Scenarios Mediated Approach for Tacit Knowledge Acquisition and Crystallisation: Towards Higher Return-On-Knowledge and Experience</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Cheah</forename><surname>Yu-N</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">School of Computer Sciences School of Computer Sciences Universiti Sains Malaysia</orgName>
								<orgName type="institution">Universiti Sains Malaysia</orgName>
								<address>
									<postCode>11800, 11800</postCode>
									<settlement>Penang, Penang</settlement>
									<country>Malaysia, Malaysia</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Syed</forename><surname>Sibte</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">School of Computer Sciences School of Computer Sciences Universiti Sains Malaysia</orgName>
								<orgName type="institution">Universiti Sains Malaysia</orgName>
								<address>
									<postCode>11800, 11800</postCode>
									<settlement>Penang, Penang</settlement>
									<country>Malaysia, Malaysia</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Raza</forename><surname>Abidi</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">School of Computer Sciences School of Computer Sciences Universiti Sains Malaysia</orgName>
								<orgName type="institution">Universiti Sains Malaysia</orgName>
								<address>
									<postCode>11800, 11800</postCode>
									<settlement>Penang, Penang</settlement>
									<country>Malaysia, Malaysia</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">A Scenarios Mediated Approach for Tacit Knowledge Acquisition and Crystallisation: Towards Higher Return-On-Knowledge and Experience</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">1537B0342738F387122055B4F2C49F9D</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T19:12+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>The 'Knowledge Age' has fuelled the need to capitalise on organisation-wide Intellectual Capital with the aim of gaining competitive advantage vis-à-vis a higher return-on-knowledge and experience. In this paper, we propose a novel tacit knowledge acquisition and representation strategy using Scenarios based on the assumption that tacit knowledge can best be explicated through controlled challenge situations. We also describe in detail, a knowledge crystallisation algorithm that is used to refine the acquired tacit knowledge by modelling the natural mechanics of crystallisation and annealing. We conclude by asserting that our approach would further enhance organisation-wide performance through its superior quality and value-added delivery of organisational services.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>In today's 'Knowledge Age', there is an ever increasing demand for more sophisticated Knowledge Management (KM) methodologies and techniques to provide the socalled 'next-generation business solutions'-solutions that endeavour to provide a higher return-on-knowledge to the parent enterprise <ref type="bibr" target="#b7">[Lan99]</ref>. It is widely acknowledged that an organisation's competitive advantage and its capacity to achieve higher return-on-knowledge is derived from the effective operationalisation and management of its Intellectual Capital. With definitions abound, Intellectual Capital is generally described as comprising the Human Capital, Structural Capital, and Relational (or Social) Capital of an organisation. Put simply, Human Capital is the knowledge, skills, experiences and intuitions possessed by individuals in an organisation; Structural Capital refers to knowledge that is embedded within an organisation operational system, i.e. an organisation's processes, workflows, systems, policies and procedures; and finally Social Capital refers to the organisation's relationships with its network of customers as well as its network of strategic partners and stakeholders. Of the three facets of Intellectual Capital, in this paper we will focus on Human Capital.</p><p>Vis-à-vis Human Capital, the knowledge possessed by an individual can be broadly differentiated between Explicit Knowledge and Tacit Knowledge. Explicit Knowledge can best be described as canonical knowledge, i.e. knowledge formalised within databases, business rules, manuals, protocols and procedures and so on. Tacit Knowledge is non-articulated or non-canonical knowledge, i.e. knowledge that does not manifest as rules. Rather it exists as the domain experts' skills, common sense and intuitive judgement whilst solving problems <ref type="bibr" target="#b2">[Che00]</ref>. The problem in many organisations today, we believe, is that explicit knowledge has been given more prominence and that experience-and skill-rich tacit knowledge is ineffectively or even hardly captured and utilised. This reliance on explicit knowledge may also result in rigid policies and thinking patterns that would hinder an organisation's ability to gain competitive advantage and, thus, resulting in low return-on-knowledge and experience.</p><p>In this paper, we will focus on knowledge creation strategies <ref type="bibr" target="#b10">[Non94]</ref>, in particular the acquisition, representation and crystallisation of tacit knowledge with the aim of allowing tacit knowledge to be utilised effectively to gain competitive advantage with higher return-on-knowledge and experience. By using healthcare as an exemplar domain, we present a novel tacit knowledge explication approach that purports the presentation of Scenarios pertaining to hypothetical problem situations to healthcare experts and in turn to record their 'tacit' problem-solving methodology and knowledge in solving the given problems. The specialised knowledge extracting 'scenarios' are custom designed to reflect atypical problems -i.e. not the kind of problems that can be solved by routine procedures. Rather, these are</p><p>The copyright of this paper belongs to the paper's authors. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Proc. of the Third Int. Conf. on Practical Aspects of Knowledge Management (PAKM2000)</head><p>Basel, Switzerland, 30-31 Oct. 2000, (U. Reimer, ed.) http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-34/ problems whose solutions may demand an interplay of informal and ad hoc intuitive (or based on experience) judgements with formal problem-solving strategy.</p><p>The forthcoming discussion spans across the lifecycle of knowledge creation; initiating with a discussion on the proposed specialised knowledge extracting Scenarios visà-vis mental models (as suggested in cognitive science literature). We will discuss in detail, a scenario structure and representation scheme that makes reference to the notion of Meta-Scenario and its components. Next, we will proceed to discuss scenario acquisition mechanisms. Finally, we will present the latest extension of our work, i.e. a technique for incremental knowledge refinement and categorisation through knowledge crystallisation which is based on the novel notion of Knowledge Nucleation and Growth <ref type="bibr" target="#b2">[Che00]</ref> -the formation of knowledge crystals by the amalgamation of multiple contextually/structurally similar scenario items. The work reported here purports a synergy between artificial intelligence techniques (for representation, reasoning and learning purposes) with existing concepts and practices in knowledge management. In conclusion, we assert that our approach would further enhance organisation-wide performance through its superior quality and value-added delivery of organisational services.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Tacit Knowledge Acquisition and Representation Using Scenarios</head><p>Generally, traditional approaches, such as the interviewing of domain experts, and subsequently observing and analysing their problem solving methodologies <ref type="bibr" target="#b8">[Mor91]</ref>, obtaining knowledge from reference materials and databases, and other techniques such as role playing, talkback, 20 questions, repertory grid, etc. only work well to procure explicit knowledge. With this in mind, it is widely contended that traditional strategies are ineffective when it comes to acquiring an expert's tacit knowledge. This is because traditional knowledge acquisition techniques do not take into account the intrinsic origin and composition of tacit knowledge during its acquisition.</p><p>In view that tacit knowledge is highly intangible, abstract and hidden, one can attribute its origin to be seemingly incorporated, embedded or interleaved with certain innate and essential skills -problem-solving skills, analytical skills and generalisation or abstraction skills. We argue that it is the selective and systematic manipulation of these innate skills, subject to the nature and specification of the problem to be solved, that brings into relief the so-called tacit knowledge that we seek to capture. Furthermore, with regards to representation schemes, the mention of schemata and mental models visà-vis tacit knowledge representation is of relevance here as it posits that mental models are perceptions of the world. Thereby, an insight into tacit knowledge representation (within our minds) can be achieved by understanding the cognitive make-up of such mental models.</p><p>In order to acquire tacit knowledge from domain experts, we propose a strategy that is grounded in the assumption that tacit knowledge can best be explicated by provoking domain experts to act and apply their knowledge and skills to solve novel or atypical problems. Such a provocation is to be achieved by repetitively presenting domain experts 'hypothetical' Scenarios <ref type="bibr" target="#b2">[Che00]</ref> pertaining to novel or atypical problems and then observe and analyse the domain expert's tacit knowledgebased problem-solving methodology and procedures. In this context, the proposed problem-specific scenario presents domain experts the implicit opportunity to introspect their expertise and knowledge in order to address the given problem, to explore their 'mental models' pertaining to the problem situation and solution, and finally to apply their skills and intuitive decision making capabilities. This sequence, allows tacit knowledge to be 'challenged', explicated, captured and finally to be stored. This strategy is in line with the notion of 'contrived' knowledge acquisition techniques <ref type="bibr" target="#b17">[Spe99,</ref><ref type="bibr" target="#b16">Sha90]</ref>.</p><p>The novelty of our approach draws from the way 'hypothetical' atypical problem situation (a problem-rich scenario that characterises the various elements and peculiarities of a possible real-life situation) is derived. Another novelty stems from the goal of the our strategyi.e. to explicate tacit knowledge vis-à-vis charting out the domain expert's thought processes, or more appropriately, mental models (as in cognitive science) for a set of welldefined problems. Having introduced and discussed the rational behind the use of scenarios, we will now provide a description of scenarios.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Description of Scenarios</head><p>A scenario, by itself, is a customised, goal-oriented narration or description of a situation, with a mention of actors, events, outputs and environmental parameters. Put simply, a scenario (a) depicts a sequence of distinct actions that might be taken to accomplish a particular task; and (b) details the sequence of interactions -comprising exchange of messages and responses to intermediate outcomes -performed or experienced by entities to fulfil the goal <ref type="bibr" target="#b0">[Bee98]</ref>. In essence, a scenario is a collection or sequence of hypothetical (but mimicking real) situations encountered by a domain expert, together with the intermediate responses/actions by the domain expert and henceforth describes one or more episodes or events of the scenario.</p><p>From a cognitive science perspective, a scenario can be deemed as a means to explicate the domain expert's mental model of the problem and its solution. Mental models are not explicit and need to be inferred from by putting them into action. This description of mental models therefore relates closely to the qualities of tacit knowledge and its acquisition through the use of scenarios <ref type="bibr" target="#b5">[Far88]</ref>.</p><p>From an artificial intelligence perspective, a scenario is very similar to a Case. However, the major distinction between the two is that a case is a real-life situation-action structure, whereas a scenario represents a sequence of hypothetical situations carefully designed to draw out tacit knowledge. Furthermore, cases are merely 'frozen' snapshots of an episode with no apparent attempt to capture significant temporal or sequential elements. On the contrary, as per our specifications, scenarios can manifest a temporal nature whereby they can capture the sequence of events as they may have occurred during a particular episode. In summary, we posit that a scenario is seemingly a more apt representation of an episode or situation, as compared to the traditional case-based representation.</p><p>Functionally, the proposed scenarios is akin to the Scripts knowledge representation construct <ref type="bibr" target="#b14">[Sch77]</ref>, However, we would like to point out that scripts are somewhat limited in representing the context of the situation in its entirety. On the contrary, our proposed scenarios cater for the clear representation of context visà-vis the provision for the linking of contextual documents to the sequence of events (described within the scenario). We believe that the explicit characterisation of the full context -i.e. a description of the social settings, resources and goals of the users <ref type="bibr" target="#b9">[Nar92]</ref> -in describing a particular situation is an important consideration with regards to situational descriptions. Since tacit knowledge is both rich in content and is also 'deep rooted', such contextual information is imperative for the successful illustration of the bigger picture, i.e. the sequence of episodes and events. To support our claim pertaining to the efficacy of a scenario-based representation, we will now discuss in detail the proposed generic structure of a scenario.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Generic Scenario Structure and</head><p>Representation: An Overview Scenarios may be composed of four main components <ref type="bibr" target="#b15">[Sch97,</ref><ref type="bibr" target="#b13">Pot94]</ref>: Meta-Scenario, Scenario-Construct, Episode and Event. For pragmatic reasons, scenarios are represented by a four-tier scheme where Meta-Scenarios are placed at the top level followed by Scenario-Constructs, Episodes and Events at the bottom level (see Figure <ref type="figure">1</ref>). The scenario storage medium -i.e. a Scenario Baseadheres to the same scheme such that the various components of a scenario are stored in distinct repositories. An exemplar Scenario-Construct with a sample Episode, Event and Parameter-Value List Element from a cardiopulmonary resuscitation scenario base are shown in Figure <ref type="figure">2</ref>. We discuss, below, the four scenario components.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>SCENARIO-CONSTRUCT</head><note type="other">Trigger</note></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">The Meta-Scenario Component</head><p>The Meta-Scenario component serves to implement a twolevel (class and sub-class) categorisation of scenarios. Each category is called a class of scenarios and would have a series of Sub-Class List Element (one for each subclass). Each meta-scenario could have the representation shown in Figure <ref type="figure" target="#fig_1">3</ref>.  </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">The Scenario-Construct Component</head><p>The Scenario-Construct -a constituent of a scenariostores the description of individual scenarios. The representation for the Scenario-Construct is shown in Figure <ref type="figure" target="#fig_2">4</ref>. Scenario-Constructs comprise a sequence of episodes that are arranged in chronological order to mimic the temporal characteristics of the scenario. Such a representation scheme ensures tractability in terms of the sequencing (or chaining) of multiple episodes within a scenario.  A unique feature of the Scenario-Construct is the Contextual Link field, which stores keywords to help locate (through a search on specific document bases) formal or informal documents containing contextual information pertaining to the episodes and events of a particular scenario.</p><p>The Scenario-Construct also has a Crystallisation Factor field that indicates how often the scenario was accessed and judge as useful. The role of this field will be further discussed in Section 5.2.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">The Episode Component</head><p>The Episode component stores details of individual episodes of a scenario (see Figure <ref type="figure" target="#fig_3">5</ref>). Each Episode comprises an Event List that stores the sequence of events that make up an episode in a scenario.  </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.4">The Event Component</head><p>The Event component stores details about individual events. The representation for an Event is shown in Figure <ref type="figure" target="#fig_4">6</ref>. There are three Event Types: Normative -events that are expected to occur on a normal basis, Obstacle -events that hinder the progress of the task, and Action -events that define the course of action undertaken by an actor. In our scenario structure, episodes and events are generic in nature until they are bound at the Scenario-Construct (scenario base) level through the order in which they are arranged and also through the effect of the Start and End Timestamps. Having formalised the scenario representation, we would now discuss the scenario-based (tacit) knowledge acquisition methodology.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Example</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Tacit Knowledge Acquisition Methodology: The Use of Scenarios</head><p>To facilitate organisational knowledge acquisition activities, we have developed a tool called the Scenario Composer <ref type="bibr" target="#b2">[Che00]</ref> that facilitates domain experts to respond to a given scenario through the use of a series of electronic forms whose attributes correspond to a particular component of a scenario, i.e. Meta-Scenarios, Scenario-Constructs, Episodes and Events. They prompt domain experts to provide information or suggest values to the various scenario-defining attributes presented in the electronic form.  The result is a challenge scenario that is then presented to the domain expert for the explication of his/her tacit knowledge (see Figure <ref type="figure">9</ref>). The construct following the Challenge and POI captures the domain expert's response, i.e. the explicated tacit knowledge. For practical purposes, once a scenario base is sufficiently populated with knowledge -derived from both solved and challenge scenarios -it can then be used for an assortment of knowledge-driven activities. In the healthcare domain, for instance, it can be used for Healthcare Enterprise Modelling [CA99, Che99b].</p><p>As it turns out, there is no restriction on the terms used by the experts. Therefore, there is a need to integrate domain ontologies with the Scenario Composer to enforce a certain degree of standardisation. Without doubt, domain ontologies hold an important place in our scenario-based tacit knowledge acquisition mechanism. This is because experts tend to use different, though similar, terms in expressing themselves. The inconsistent use of terms could cause serious problems especially when scenarios are eventually used for inferencing purposes.</p><p>Ontologies, in our scenario context, could be integrated or implemented in a pre-or post-input fashion. We can also view it as being proactive or reactive. This means that we could perform standardisation either before or after a scenario is accepted into the scenario base. Ideally, this should be done before a scenario is accepted to avoid ambiguity in the event the expert is no longer unavailable to provide clarification. Upon detecting a potentially ambiguous terminology (such as those that are applicable in more than one context, or those that have more than one meaning), this pre-input mechanism would suggest standardised terms for the expert to choose. In the postinput version, the expert has little or even no control of how this mechanism would standardise the terms used.</p><p>The process of acquiring tacit knowledge and making it explicit is only a small step in the ongoing efforts to 'create' knowledge <ref type="bibr" target="#b10">[Non94]</ref>. Moreover, the scenario base in its 'natural' state is deemed inefficient in view that the scenario items are not categorised in such a way that would guide potential inferences by limiting an inference engine's search scope. Therefore, in the following sections, we would explore further on the modes and phases of knowledge creation leading to the refinement and categorisation of the scenario base through the crystallisation of the explicated tacit knowledge.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Knowledge Crystallisation</head><p>Nonaka proposes four processes or modes that effectuate the transformation between tacit knowledge and explicit knowledge <ref type="bibr" target="#b10">[Non94]</ref>. These transformations span across five distinct phases, as shown in Figure <ref type="figure">10</ref>. In a KM parlance, crystallisation is an integral process in the creating concepts phase-it refers to the process where  the various departments in an organisation, test the reality and applicability of the created concepts. As a consequence, knowledge that is proven effective, useful and objective is maintained and perpetuated. Now, from a chemical parlance, crystallisation is interpreted to mean to 'solidify and internally arrange'.</p><p>In our work we intend to map the notion of chemical crystallisation to a knowledge creation context, whereby: (a) knowledge items (scenario items in our case) mimic molecules, ions or atoms in a supersaturated chemical solution; and (b) the creation of concepts is achieved by the satisfaction of mutual constraints and unification amongst an ensemble of knowledge items, akin to the process of arrangement of ions, as per chemical rules, to form a crystal. We call the knowledge unit created by our crystallisation process as a Knowledge Crystal.</p><p>A knowledge crystal can be viewed as a structure with a repetitive arrangement of scenario items in various perspectives, with the objective refine the scenario base at the Scenario-Construct level. Basically, there can be two stages in knowledge crystal formation: 1. Nucleation: The formation of a new child knowledge base in a heterogeneous (complex) knowledge base. 2. Growth: The repetitive addition of free scenario items.</p><p>A prerequisite for both processes is supersaturation of scenario items. This means that crystallisation could only occur when the knowledge density of a knowledge base exceeds a predefined level <ref type="bibr" target="#b1">[Bun96]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.1">Nucleation</head><p>Nucleation begins with the presence of Knowledge Seeds in the knowledge base and they are analogous to impurities in a chemical solution. In the state of supersaturation, these knowledge seeds form the nuclei for the growth of knowledge crystals. Conceptually, knowledge seeds serve as a platform on which scenario items grow on.</p><p>There are three types of knowledge seeds:  Nucleation could be initiated when needed by the scenario base administrator or through an automated seeding process. This automated process follows an analysis of the knowledge base's content and nucleation occurs as often as needed depending on the requirements in creating child knowledge bases.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.2">Growth</head><p>Growth occurs after nucleation is established. It is a repetitive addition of scenario items to the nuclei (knowledge seed) through the formation of links to the nuclei. Depending on the knowledge seed, these scenario items can be of the same structure and/or the same context.</p><p>Ideally, these links should be established between scenario items of similar structure and context, i.e. originating from a combination knowledge seed. Not only would this fit closely to the original definition of chemical crystallisation but it would also facilitate the implementation and operationalisation of emergent child knowledge bases. Child knowledge bases, comprising scenario items of similar structure and context, can therefore be envisaged as being more subject-focused in terms of their application domain and are also easier to manipulate in terms of query construction.</p><p>Besides the knowledge seeds' structural and contextual properties, we posit that the scenario items' 'temperature' or energy level (akin to that in simulated annealing <ref type="bibr" target="#b18">[Tay99,</ref><ref type="bibr" target="#b6">Kir83]</ref>) is an important factor in the growth stage. The notion of the energy of a scenario item could be translated into the amount of activity surrounding a particular scenario item, i.e. the number of times it was referred or used by the system. We propose that when a scenario item is referred to and is frequently judged as useful, its accessibility is said to increase. Thus, its level of energy (or activity) decreases, i.e. for a scenario item to be easily accessed, it should not 'move' too much. When the energy level of the scenario item decreases, its ability to crystallise or link to other scenario item increases (in line with thermodynamic principles). Conversely, when a scenario item is referred to and is frequently judge as not useful, its accessibility decreases and energy increases. When this occur, it is less likely to bind with other scenario items. These relations are summarised in Table <ref type="table">1</ref>.</p><p>It should also be noted that a scenario item can only crystallise when its energy level drops below a certain level, i.e. it is accessed and judged as useful frequently enough. Therefore, a scenario item's frequency of 'useful' access would need to exceed a predefined threshold before it can crystallise.</p><p>In order to facilitate the crystallisation process, a Crystallisation Factor (CF) field is added to the Scenario-Construct representation (as mentioned in Section 3.2) to store the number of times the scenario item was accessed and judged as useful. The CF would be decremented when it is not judged as useful after a specified period of time. It is possible for the CF to have a negative value in the event that it is not useful for a long time.</p><p>Upon completing the crystallisation process, the resultant scenario base may contain (free) scenario items as well as knowledge crystals. Free scenario items are the</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Frequency of Access Accessibility Energy Level Crystallisation</head><formula xml:id="formula_0">↑ ↑ ↑ ↑ ↓ ↓ ↑ ↑ ↓ ↓ ↓ ↓ ↑ ↑ ↓ ↓</formula><p>Table <ref type="table">1</ref>: The Relation between Frequency of Access, Accessibility and Energy Level in the process of Crystallisation.</p><p>items of the original scenario base that did not bind to any of the formed crystals. In fact, the resultant scenario base changes from time to time depending on whether new scenario items are added to the scenario base. Figure <ref type="figure" target="#fig_0">12</ref> illustrates the states before and after (or during) crystallisation.</p><p>In the Figure <ref type="figure" target="#fig_0">12</ref>, two crystals are formed with two different types of knowledge seeds. Scenario Item 'E' is shown linking with the crystal on the left as they are of similar context and/or structure. Scenario Item X (a free scenario item) is on its own, as there are no crystals with a structure or context similar to its own. With reference to Figure <ref type="figure" target="#fig_0">12</ref>, crystallisation is shown as an on-going repetitive process, executed in parallel even while more knowledge is accessed, shared and added into the scenario base. Functionally, crystallisation is terminated momentarily when the density of scenario items falls below the predetermined threshold.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.3">The Crystallisation Algorithm</head><p>In an attempt to crystallise the scenario base, we have incorporated into the Scenario Composer, a knowledge crystallisation component. The steps executed by this component in the crystallisation process are as follows (A flowchart of the algorithm is shown in Figure <ref type="figure" target="#fig_1">13</ref>):</p><p>Step 1: Create Knowledge Seed: A knowledge seed is created by the domain expert or scenario base administrator using the representation detailed in Section 5.1. For a newly created knowledge seed, the Scenario Item List is an empty list.</p><p>Step 2: Embed Knowledge Seed: The knowledge seed is 'placed' into a scenario base to initiate the crystallisation process.</p><p>Step 3: Attract Similar Knowledge Units: Search the scenario base for scenario items that have a similar context and/or structure as the seed (depending on the Seed Type field). Y.-N. Cheah, S.S.R. Abidi</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>5-9</head><p>Step 4: Select Most Similar Knowledge Unit: Among the matched items, select the scenario item that has been frequently accessed and judged as being the most useful, i.e. having the highest CF.</p><p>Step 5: Associate Knowledge Unit to Knowledge Seed:</p><p>Link the selected scenario item to the knowledge seed by way of adding the scenario item's Scenario ID to the seed's Scenario Item List.</p><p>Step 6: Prioritise Selected Knowledge Units: Rearrange the Scenario Item List (of the seed) so that the CF of the scenario items is in descending order. Note that crystallisation begins after Step 2, provided the scenario base is sufficiently populated by free scenario item. A user-defined threshold determines the number of free scenario items that are needed to initiate the crystallisation process.</p><p>In Step 4, as mentioned before, the selected scenario item must have a CF that exceeds a predefined threshold before it can be linked to the knowledge seed in Step 5.</p><p>In Steps 4 and 5, the matched items could have simply been sorted according to their CF in descending order and then added en bloc to the seed's Scenario Item List. However, we choose not to do this (at least for the time being) to mimic more closely the crystallisation process in chemistry (which is incremental in nature). The incremental approach is also more time consuming. Nevertheless, from a chemistry point of view, the slower the crystallisation process, the better the quality of the crystals formed. However, at the moment we are not able to demonstrate any clear advantage for our choice.</p><p>Step 6 allows the Scenario-Construct with the highest CF to be at the head of the Scenario Item List. This increases the efficiency of potential inferencing strategies as the most reliable or useful scenarios are considered first. In the previous section, we proposed that the CF of the Scenario-Construct will be decremented, after a predetermined period of time, if it is deemed not useful. This strategy ensures that outdated or less useful scenario items would eventually be among the last to be considered during inferencing. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Wait</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Start</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Yes</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>No</head><p>Step 1</p><p>Step 2</p><p>Step 3</p><p>Step 4</p><p>Step 5</p><p>Step 6</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Crystallisation</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Factor exceeds threshold</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Yes</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>No</head><p>Figure <ref type="figure" target="#fig_1">13</ref>: The Knowledge Crystallisation Flowchart.</p><p>After Step 6, if the number of free scenario items still exceeds the threshold, the process continues from Step 3. The crystallisation process stops momentarily when the number of free scenario items drops below the threshold only to resume when the threshold is exceeded. We argue that the manner in which crystallisation is taking place by modelling chemical crystallisation does in fact conform to Nonaka's original view where the explicated tacit concepts are tested for reliability and applicability <ref type="bibr" target="#b10">[Non94]</ref>. When a user accesses and evaluates a particular scenario item, he/she is actually testing and affirming its applicability and usefulness. Therefore, we argue that the more a scenario item is accessed and judged as useful, the more applicable the scenario item is deemed to be and more crystallised the concepts or scenarios.</p><p>The crystallisation algorithm can be adapted to perform garbage collecting functions, i.e. the removal of scenario items that prove to be very isolated cases and are not useful. Garbage collecting can potentially be executed in parallel with the existing crystallisation algorithm after</p><p>Step 3 where instead of selecting the most popular and useful scenario item for crystallisation, we select the one that is least accessed and hence is removed from the scenario base. A detailed discussion of scenario-based garbage collecting is beyond the scope of this paper. Nevertheless, we take this opportunity to highlight its practicality and possibility.</p><p>In general, we will like to point out that our approach for knowledge crystallisation renders a more physical and autonomous connotation such that the knowledge itself undergoes a proactive automatic categorisation as compared to the original, more social and reactive approach. Note that our approach to crystallisation aims to link scenario items to a knowledge seed in a crystalforming paradigm that ranks the scenario items in terms of their applicability and usefulness.   </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.4">The Final Representation of Scenarios</head><p>Ideally, the explicated and crystallised tacit knowledge would be stored in a representation language that is portable, flexible and expressive. Currently, a likely choice of representation language is the Extensible Markup Language (XML). The choice of XML is justified further by the fact that it is easily parsed and thus, facilitates the translation of the XML document into other representational language. Exemplar Document Type Definition (DTD) fragments for the Scenario-Construct, Episode and Event representations and their XML instances are shown in Figures <ref type="figure" target="#fig_12">14 and 15</ref> respectively.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6">Concluding Remarks</head><p>We believe that we have initiated a novel scenariomediated approach to facilitate the capture and utilisation of the domain experts' tacit knowledge, thereby leading to the crystallisation of the acquired knowledge. Here we will like to point out that we do understand that the basis of our tacit knowledge acquisition approach is to some extent akin to traditional knowledge acquisition strategies, such as critiquing, role playing and simulation. However, we believe that the novelty of our approach derives from the following facts: (1) tacit knowledge is 'invoked' by not mere interviewing the domain expert or document analysis, rather by subjecting the domain expert to solve 'controlled' challenges (hypothetical' atypical problem situation) that itself are derived from existing solved reallife scenarios; (2) the scenario knowledge construct represents the hierarchical make-up of tacit knowledge in terms of an ensemble of distinct knowledge units; (3) the acquisition of tacit knowledge follows the formal structural specification of the scenario, thereby ensuring a mapping of user-mediated knowledge items (with varying degrees of specificity and context) to a scenario structure; and (4) the crystallisation of acquired tacit knowledge in terms of the chemical crystallisation process.</p><p>In this paper, we have discussed the said tacit knowledge acquisition and representation approach that attempts to capture the essence of expert-quality problem-solving using scenarios. We have also seen how natural phenomena, such as crystallisation and annealing, can be effectively adapted into Knowledge Management efforts to refine and categorise knowledge and to allow it to dynamically evolve into scenario or knowledge bases that are capable of providing relevant and up-to-date knowledge on-demand. The definition and development of scenarios, the crystallisation algorithm and the Scenario Composer are ongoing. Nevertheless, it is hoped that our methodology would lead to the improvement of organisation-wide return-on-knowledge and experience resulting in the superior quality and value-added delivery of organisational services.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Figure 1 :Figure 2 :</head><label>12</label><figDesc>Figure 1: The Scenario Structure outline.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Figure 3 :</head><label>3</label><figDesc>Figure 3: Representation of a Class in a Meta-Scenario. Shaded rows indicate a Sub-Class List Element.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Figure 4 :</head><label>4</label><figDesc>Figure 4: Representation of a Scenario-Construct.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head>Figure 5 :</head><label>5</label><figDesc>Figure 5: Representation of an Episode.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_4"><head>Figure 6 :</head><label>6</label><figDesc>Figure 6: Representation of an Event. The IDs of parameters and values of an event (in the form of Parameter-Value List Elements) are stored in the Parameter-Value List.In our scenario structure, episodes and events are generic in nature until they are bound at the Scenario-Construct (scenario base) level through the order in which they are arranged and also through the effect of the Start and End Timestamps. Having formalised the scenario representation, we would now discuss the scenario-based (tacit) knowledge acquisition methodology.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_5"><head></head><label></label><figDesc>Figure 7: Scenario-Construct screenshot.</figDesc><graphic coords="5,77.76,342.48,226.80,163.20" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_6"><head>Figure 8 :</head><label>8</label><figDesc>Figure 8: Episode, Event and Parameter-Value List Element screenshot.Our novel scenario acquisition exercise distinguishes between two types of scenarios:1. Solved Scenarios: Scenarios that define actual situations/problems that have already been encountered and solved/addressed by domain experts. They are akin to traditional form-based cases that are acquired through traditional knowledge acquisition techniques. Scenario bases start out as having only solved scenarios. 2. Challenge Scenarios: Scenarios that represent atypical situations and are posed to domain experts as a challenge to their expertise. Challenge scenarios are in line with our contention that tacit knowledge is best explicated when experts are required to solve atypical problems. In most instances, challenge scenarios are derived from existing solved scenarios by way of selecting a Point of Interrogation (POI) -a distinct point in the scenario between two events of type Obstacle or Normative and an event of type Action.The result is a challenge scenario that is then presented to the domain expert for the explication of his/her tacit knowledge (see Figure9). The construct following the Challenge and POI captures the domain expert's response, i.e. the explicated tacit knowledge. For practical purposes, once a scenario base is sufficiently populated with knowledge -derived from both solved and challenge scenarios -it can then be used for an assortment of knowledge-driven activities. In the healthcare domain, for instance, it can be used for Healthcare Enterprise Modelling [CA99, Che99b].As it turns out, there is no restriction on the terms used by the experts. Therefore, there is a need to integrate domain ontologies with the Scenario Composer to enforce a certain degree of standardisation. Without doubt, domain ontologies hold an important place in our scenario-based tacit knowledge acquisition mechanism. This is because experts tend to use different, though similar, terms in expressing themselves. The inconsistent use of terms could cause serious problems especially when scenarios are eventually used for inferencing purposes.Ontologies, in our scenario context, could be integrated or implemented in a pre-or post-input fashion. We can also view it as being proactive or reactive. This means that we could perform standardisation either before or after a scenario is accepted into the scenario base. Ideally, this should be done before a scenario is accepted to avoid ambiguity in the event the expert is no longer unavailable to provide clarification. Upon detecting a potentially ambiguous terminology (such as those that are applicable in more than one context, or those that have more than one meaning), this pre-input mechanism would suggest standardised terms for the expert to choose. In the postinput version, the expert has little or even no control of how this mechanism would standardise the terms used.The process of acquiring tacit knowledge and making it explicit is only a small step in the ongoing efforts to 'create' knowledge<ref type="bibr" target="#b10">[Non94]</ref>. Moreover, the scenario base in its 'natural' state is deemed inefficient in view that the scenario items are not categorised in such a way that would guide potential inferences by limiting an inference engine's search scope. Therefore, in the following sections, we would explore further on the modes and phases of knowledge creation leading to the refinement and categorisation of the scenario base through the crystallisation of the explicated tacit knowledge.</figDesc><graphic coords="5,77.76,146.16,226.80,163.20" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_7"><head>Figure 9 :Figure 10 :</head><label>910</label><figDesc>Figure 9: A portion of a Challenge Scenario showing the Challenge, Point of Interrogation (POI) and the Domain Expert's Response.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_9"><head>Figure 11 :</head><label>11</label><figDesc>Figure 11: Structure of a Knowledge Seed.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_10"><head>Figure 12 :</head><label>12</label><figDesc>Figure 12: The Scenario Base Before and After (or During) Crystallisation.</figDesc><graphic coords="8,186.48,507.84,263.04,136.08" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_11"><head>Figure 14 :</head><label>14</label><figDesc>Figure 14: Exemplar Scenario-Construct DTD.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_12"><head>Figure 15 :</head><label>15</label><figDesc>Figure 15: Exemplar Scenario-Construct instance in XML.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_4"><head></head><label></label><figDesc>This field lists down the Scenario IDs of all Scenario-Constructs that is linked to the seed, i.e. crystallised.</figDesc><table><row><cell cols="2">1. Structural: The structural knowledge seed ensures that</cell></row><row><cell cols="2">only scenario items of the same structure may</cell></row><row><cell cols="2">interlink to it. The scenario base could potentially</cell></row><row><cell cols="2">contain Scenarios, Episodes and Events that have</cell></row><row><cell cols="2">different structural composition.</cell></row><row><cell cols="2">2. Contextual: The contextual knowledge seed ensures</cell></row><row><cell cols="2">that only scenario items of the same context may</cell></row><row><cell cols="2">interlink to it. It forms a knowledge crystal that is</cell></row><row><cell cols="2">contextually uniform.</cell></row><row><cell cols="2">3. Combination (Structural and Contextual): This</cell></row><row><cell cols="2">knowledge seed ensures that only scenario items of</cell></row><row><cell cols="2">the same structure and context may interlink to it.</cell></row><row><cell cols="2">The structure of a knowledge seed may consist of the</cell></row><row><cell cols="2">following items (see Figure 11):</cell></row><row><cell cols="2">1. Seed ID: States the identification number of the</cell></row><row><cell cols="2">knowledge seed.</cell></row><row><cell cols="2">2. Seed Type: Determines if the seed is a Contextual or</cell></row><row><cell cols="2">Structural knowledge seed or a Combination.</cell></row><row><cell cols="2">3. Context: States the context of the knowledge seed.</cell></row><row><cell cols="2">This will be used as the basis to attract scenario items</cell></row><row><cell cols="2">and ensures that the knowledge crystal is contextually</cell></row><row><cell>uniform.</cell><cell></cell></row><row><cell cols="2">4. Scenario Structure: This field lists down the attributes</cell></row><row><cell cols="2">(fields) of scenario items that can be bound to the</cell></row><row><cell cols="2">Knowledge Seed. This ensures that only scenario</cell></row><row><cell cols="2">items that are structurally the same can link to the</cell></row><row><cell cols="2">seed (as per Structural Knowledge Seeds).</cell></row><row><cell cols="2">5. Scenario Item List: Example</cell></row><row><cell>Seed ID</cell><cell>KS0001</cell></row><row><cell>Seed Type</cell><cell>Contextual</cell></row><row><cell>Context</cell><cell>First-aid</cell></row><row><cell>Scenario</cell><cell>["Scenario ID", "Scenario</cell></row><row><cell>Structure</cell><cell>Description", "Contextual Link",</cell></row><row><cell></cell><cell>"Start Timestamp", "End Timestamp",</cell></row><row><cell></cell><cell>"Trigger Event", "Episode List",</cell></row><row><cell></cell><cell>"Concluding Event"]</cell></row><row><cell>Scenario</cell><cell>["s.19990713.1520", ...]</cell></row><row><cell>Item List</cell><cell></cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_5"><head>Create Knowledge Seed Select Scenario Base Search Scenario Base for Scenario items with same context and/or same structure as Knowledge Seed. Among matched items, select Scenario item that has the highest CF. Link Scenario item to Knowledge Seed by adding the Scenario item's Scenario ID to the seed's Scenario Item List. Free Item count exceeds threshold Rearrange Scenario Item List with the CF of Scenario items in descending order.</head><label></label><figDesc></figDesc><table /></figure>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0" />
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<author>
			<persName><forename type="first">G</forename><forename type="middle">W</forename><surname>Beeler</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><surname>Rishel</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">M</forename><surname>Shakir</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Walker</surname></persName>
		</author>
		<title level="m">Message Development Framework Version 3.1</title>
				<imprint>
			<publisher>Health Level Seven, Inc</publisher>
			<date type="published" when="1998">1998</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<author>
			<persName><forename type="first">H</forename><forename type="middle">R</forename><surname>Bungay</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Iii</forename></persName>
		</author>
		<ptr target="http://www.esb.ucp.pt/~bungah/coag/crys.htm" />
		<title level="m">Crystallization</title>
				<imprint>
			<date type="published" when="1996">1996</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">A Strategy for Knowledge Acquisition and Representation: A Case for Scenarios</title>
		<author>
			<persName><forename type="first">Y.-N</forename><surname>Cheah</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><forename type="middle">S R</forename><surname>Abidi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">3rd Int. Conf. on The Practical Application of Knowledge Management (PAKeM 2000)</title>
				<meeting><address><addrLine>Manchester</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">Healthcare Knowledge Management Through Building and Operationalising Healthcare Enterprise Memory</title>
		<author>
			<persName><forename type="first">Y.-N</forename><surname>Cheah</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><forename type="middle">S R</forename><surname>Abidi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Medical Informatics Europe (MIE &apos;99)</title>
				<editor>
			<persName><forename type="first">P</forename><surname>Kokol</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">B</forename><surname>Zupan</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">J</forename><surname>Stare</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">M</forename><surname>Premik</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">R</forename><surname>Engelbrecht</surname></persName>
		</editor>
		<meeting><address><addrLine>Ljubljana, Slovenia, Amsterdam</addrLine></address></meeting>
		<imprint>
			<publisher>IOS Press</publisher>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Evaluating the Efficacy of Knowledge Management and Organisational Memory Toward Healthcare Enterprise Modelling</title>
		<author>
			<persName><forename type="first">Y.-N</forename><surname>Cheah</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><forename type="middle">S R</forename><surname>Abidi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">16th Int. Joint Conf. on Artificial Intelligence (IJCAI &apos;99)</title>
				<meeting><address><addrLine>Stockholm</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
	<note>Workshop on Knowledge Management and Organizational Memories</note>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">A Survey of Formal Tools and Models for Developing User Interfaces</title>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">U</forename><surname>Farooq</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><forename type="middle">D</forename><surname>Dominick</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Int. Journal of Man-Machine Studies</title>
		<imprint>
			<biblScope unit="volume">29</biblScope>
			<biblScope unit="page" from="479" to="496" />
			<date type="published" when="1988">1988</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">Optimization by Simulated Annealing</title>
		<author>
			<persName><forename type="first">S</forename><surname>Kirkpatrick</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><forename type="middle">D</forename><surname>Gerlatt</surname><genName>Jr</genName></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">P</forename><surname>Vecchi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Science</title>
		<imprint>
			<biblScope unit="volume">220</biblScope>
			<biblScope unit="page" from="671" to="680" />
			<date type="published" when="1983">1983</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Traffic Road Accidents Return on Experience. Discovering, Organizing and Sharing Knowledge to Minimize Risks and Costs in a Mutual Insurance Company</title>
		<author>
			<persName><forename type="first">A</forename><surname>Lancini</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Mercier-Laurent</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">6th Int. Symp. on the Management of Industrial and Corporate Knowledge (ISMICK &apos;99)</title>
				<meeting><address><addrLine>The Netherlands</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">Knowledge Acquisition: The Acquire® Approach</title>
		<author>
			<persName><forename type="first">I</forename><surname>Morrison</surname></persName>
		</author>
		<author>
			<persName><forename type="first">B</forename><forename type="middle">A</forename><surname>Schaefer</surname></persName>
		</author>
		<author>
			<persName><forename type="first">B</forename><surname>Smith</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">1st Semi-Annual Conf. in Policy Making and Knowledge Systems</title>
				<imprint>
			<date type="published" when="1991">1991</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">The Use of Scenarios in Design</title>
		<author>
			<persName><forename type="first">B</forename><forename type="middle">A</forename><surname>Nardi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">SIGCHI Bulletin</title>
		<imprint>
			<date type="published" when="1992-10">October, 1992</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<monogr>
		<title level="m" type="main">A Dynamic Theory of Organizational Knowledge Creation</title>
		<author>
			<persName><forename type="first">I</forename><surname>Nonaka</surname></persName>
		</author>
		<imprint/>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<analytic>
		<title/>
	</analytic>
	<monogr>
		<title level="j">Organization Science</title>
		<imprint>
			<biblScope unit="volume">5</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="14" to="37" />
			<date type="published" when="1994">1994</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b12">
	<monogr>
		<title level="m" type="main">The Knowledge-Creating Company</title>
		<author>
			<persName><forename type="first">I</forename><surname>Nonaka</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Takeuchi</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1995">1995</date>
			<publisher>Oxford University Press</publisher>
			<pubPlace>New York</pubPlace>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<analytic>
		<title level="a" type="main">Inquiry-Based Scenario Analysis of System Requirements</title>
		<author>
			<persName><forename type="first">C</forename><surname>Potts</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Takahashi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Anton</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Int. Conf. on Requirements Engineering (ICRE &apos;94)</title>
				<meeting><address><addrLine>Colorado Springs</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1994">1994</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b14">
	<analytic>
		<title level="a" type="main">Scripts, Plans, and Knowledge</title>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">C</forename><surname>Schank</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">P</forename><surname>Abelson</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Thinking: Readings in Cognitive Science</title>
				<editor>
			<persName><forename type="first">P</forename><forename type="middle">N</forename><surname>Johnson-Laird</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">P</forename><forename type="middle">C</forename><surname>Wason</surname></persName>
		</editor>
		<meeting><address><addrLine>Cambridge</addrLine></address></meeting>
		<imprint>
			<publisher>Cambridge University Press</publisher>
			<date type="published" when="1977">1977</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b15">
	<analytic>
		<title level="a" type="main">Learning to Break Things: Adaptive Testing of Intelligent Controllers</title>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">C</forename><surname>Schultz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">J</forename><surname>Grefenstette</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><forename type="middle">A</forename><surname>De</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Jong</forename></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Handbook of Evolutionary Computation</title>
				<editor>
			<persName><forename type="first">T</forename><surname>Baeck</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">D</forename><forename type="middle">B</forename><surname>Fogel</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">Z</forename><surname>Michalewicz</surname></persName>
		</editor>
		<meeting><address><addrLine>Bristol</addrLine></address></meeting>
		<imprint>
			<publisher>IOP Publishing Ltd</publisher>
			<date type="published" when="1997">1997</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b16">
	<analytic>
		<title level="a" type="main">Knowledge Elicitaion</title>
	</analytic>
	<monogr>
		<title level="m">Evaluation of Human Work: A Practical Ergonomics Methodology</title>
				<editor>
			<persName><forename type="first">J</forename><forename type="middle">R</forename><surname>Wilson</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">E</forename><forename type="middle">N</forename><surname>Corlett</surname></persName>
		</editor>
		<meeting><address><addrLine>London</addrLine></address></meeting>
		<imprint>
			<publisher>Taylor and Francis</publisher>
			<date type="published" when="1990">1990</date>
			<biblScope unit="page" from="321" to="345" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b17">
	<analytic>
		<title level="a" type="main">Knowledge Mapping for Industrial Purposes</title>
		<author>
			<persName><forename type="first">P.-H</forename><surname>Speel</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Shadbolt</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><surname>Vries</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><forename type="middle">H</forename><surname>Van Dam</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>O'hara</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">12th Workshop on Knowledge Acquisition, Modeling and Management (KAW &apos;99)</title>
				<meeting><address><addrLine>Banff</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b18">
	<monogr>
		<author>
			<persName><forename type="first">T</forename><surname>Tay</surname></persName>
		</author>
		<ptr target="http://www.comp.nus.edu.sg/~tayhanbo/cs1305/index.html" />
		<title level="m">Groping the Elephant</title>
				<imprint>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
