We present a next step in our ongoing effort to conceive innovative support approaches for collaborative modeling. We propose to blend the well-established Collaboration Engineering approach (rooted in CSCW) with the Dialogue Game approach (rooted in Conceptual Modeling), viewing the second as a specialized extension of the first, and describing how they can complement each other. We hope to eventually link not only the approaches, but also the two fields. We provide a small but realistic illustration of our proposal at the hand of a real, industrially used elicitation pattern from knowledge modeling, and briefly show how this pattern can be wrapped up as an ʻm-thinkLetʼ.
In the field of collaborative modeling
Once we move away from the ‘collaborative diagram drawing’ approach and
into more limited and focused conceptualization (closer to the stakeholders’
familiar concepts and requiring less skill in dealing with abstract syntax and
complex visualizations and verbalizations), we can also move towards more
closely guided, wizard-like conceptualization support
Such ‘conceptualization games’ bear considerable resemblance to the thinkLet
concept central in Collaboration Engineering or CE
The Dialogue Game (DG) approach to collaborative modeling is rooted in a
theoretical view on modeling as a conversation
From the rule-based RIM approach, it is a small step to viewing modeling
sessions as enacted games (instantiations of a game type). In addition, there is a
theoretical link between the RIM approach and ‘dialogue games’, a known
concept in Argumentation Theory
Let us now consider the CE approach (involving thinkLets) and see how this approach relates to the DG approach to collaborative modeling. Please note that lack of space prevents us from providing a full scale, detailed comparison between the CE and DG approaches here; we intend to do this elsewhere, including identification of overlap between existing thinkLets and (parts of) Dialogue Games. Indeed we know such overlap exists. However, our strategy is to first focus on the creation of playable game implementations; analysis and (re)use of generic patterns (thinkLets) in these games will have to come later.
The CE concepts we refer to below are based on
In
In dealing with the optimal trade-off between constraint and freedom in
guiding interaction, much can be learned from game dynamics. In addition, taking
the game metaphor seriously suggests some interesting possibilities: the use of
advanced interfacing from gaming to make collaborative interaction more
accessible and engaging; even the use of devices like score systems or local
competition embedded in over-all collaboration
The DG approach recognizes the long term goal (also highly prominent in CE)
of removing the facilitator as much as possible (disintermediation), yet it
currently focuses on simplifying and structuring the facilitator’s role rather than
removing it. A DG for modeling is typically viewed as two entwined games with
distinct sets of goals and rules: one (or more) for the stakeholder-participants, one
for the facilitator-participants. Again this merges the notion of ‘rules’ with the
notion of ‘script’, including the facilitator as a role in the game. Such a setup was
successfully executed in a pilot DG for Group Model Building, transforming a
script into a DG
In modeling (as opposed to generic collaboration), a key notion is that of a
meta model or modeling language. Though this aspect is in principle covered by
thinkLet design concepts, it could benefit from additional, further specialized
views from the DG approach. The pragmatic focus of a DG (the intended use of
the conceptualization it renders: its desired resulting contents) is driven by focus
questions; its semantic-syntactic focus (the modeling language or conceptual
format of the result) constrains the formulation of focused answers
CE uses the concept of “parameters” of thinkLets: content-specific variables, for example focus questions. One could view such parametrization as an important aspect of the development of m-thinkLets. However, the creation of mthinkLets would involve the setting of parameters that would still be generic for a certain flavor of modeling, e.g. ontological modeling, process modeling, and so on. Indeed, m-thinkLets require a specific, focused approach to the use of parameters extending into ‘syntax setting’ for m-thinkLet results.
CE covers ‘moves of the game’ that relate to the rendering of results of
thinkLets. Discussion is explicitly included as a possible ‘action’ in thinkLets, but
CE does not guide, constrain, or log its ‘mechanics’. Contrarily, the DG approach
considers the typical interactions of discussion and argumentation as discrete
‘moves of the game’
Having explored key similarities and differences between CE and the DG
approach, let us consider a realistic example of a potential DG based m-thinkLet.
Example: The ‘Weighted Factor Elicitation Game’
An exemplary ‘m-thinkLet’ interaction pattern was created in context of a project
in which a radical new distributed model was conceived for scheduling Dutch
railway traffic
The facilitator (a knowledge engineer) initiated the session by introducing a limited set of scenarios that can lead to a conflict. These scenarios were presented by schematic diagrams (Fig. 1).
The diamonds in Fig. 1 represent junctions. The other icons represent trains. The goal of the game is for the players to set parameters such that, for a specific scenario, there is a given p% chance (e.g. 75%) that the trains will raise a conflict (i.e. arrive at the same time) at the junction. During the game, the facilitator actively varies scenario details like the types of trains involved (e.g. length, load) or events occurring (e.g. wind conditions, engine failure ).
For example: “let domain expert 1 be the red train. This red train is a long cargo train carrying a heavy load. Domain expert 2 is the blue train which is IC train with high priority. Domain expert 3 is a junction that will assess continuously the chance of collision. Assignment: for this situation, collaboratively conceive and set factors so that there is a 75% chance the trains collide”. The actual, utilitarian goal of the game is to collaboratively define a stable set of factors influencing the chances of collisions taking place. Factor types thus elicited included speed, maintenance record, weather influences, weight, type of engine, priority of passengers and cargo; weights (high/low) indicated the importance of the factors.
The domain experts involved had no experience in creating formal models. The described session was one in a series of nine interrelated sessions, each of a similar focused nature. In each session the focus (both pragmatic and semanticsyntactic) was set differently to address a specific aspect: the train, the infrastructural points, creating conflict, creating a plan to prevent a conflict, determining a cost function to evaluate a plan, decision making on plans, determining follow-up conflicts, define a stop criterion for evaluating uncertain follow-up conflicts. By breaking up the problem into small, focused sessions, in the end a very complex distributed scheduling system was collaboratively modeled, without any ‘comprehensive diagram drawing’ (in fact, such a diagram would have too complex to draw in the first place: it was represented as a set of mathematical formulae).
The same patterns have later been reapplied in other projects in need of a real time distributed workflow scheduling solution. For example, the patterns have been used to develop a system for scheduling ground operations at Zaventem airport, scheduling autonomous operating robots in Rotterdam’s largest container handling terminal port, creating simulations to solve traffic jam problems in Holland and for developing an order picking system for distribution centers of a Dutch super market chain.
The technique presented above is an excellent example of a ‘Focused
Conceptualization’ or ‘FoCon’ as introduced in
Various given scenarios and given chances of collision Trains, junctions, situations (diagrams); properties of trains, partly based on results of ongoing elicitation; given chance of collision (P-value, e.g. 0.75) Train traffic management experts, not trained in formal modeling, some system thinking ability, homogeneous professional background List, generalized over all scenarios used, of weighted factors influencing collision risk
Factor types, weight for each factor type (high/low impact) “IN” “OUT”
Info Concepts People Info (pragm. focus) Concepts (sem.-synt. focus) Social req.
Argumentation We hope the table sufficiently illustrates how a FoCon analysis can serve as a basis for designing both Dialogue Games and m-thinkLets. Note that in the example, ‘argumentation’ plays a role in the actual elicitation process (arguments can be looked up during a running game and are a source of ideas about factors for the players) but argumentation is also logged for future reference to details in the discussion (otherwise lost). Structure is inherently provided by the DG setup.
We leave out considerations of mappings between m-thinklets, aptly called
“transitions”
This paper results from the Agile Service Development project (http://www.novay.nl/okb/projects/agileservice-development/7628), a collaborative research initiative focused on methods, techniques and tools for the agile development of business services. The project consortium consists of BeInformed, BiZZdesign, CRP Henri Tudor, Everest, HU University of Applied Sciences Utrecht, IBM, Novay, O&i, PGGM, RuleManagement Group, Radboud University Nijmegen, Twente University, Utrecht University, and Voogd & Voogd. The project is part of the program Service Innovation & ICT of the Dutch Ministry of Economic Affairs.