\label{sec:futurework} \label{sec:hatching}
Within the context of the ongoing COINVENT project \cite{coinvent14}, we are interested in using computational theory blending to realise certain aspects of this model in a stand-alone architecture. It will be useful to consider how we can take both the discovery step, which combines a serendipity trigger \(T\), and prior preparation \(p\), to produce a classification \(T^{\star}\) – and the invention step, which combines the classified trigger \(T^{\star}\), and preparations \(p^{\prime}\), and produces a novel result \(R\) – to be blends in the sense of Joseph Goguen .
The epistemological framework of discovery gives some important clues about how to compute a common base between \(T\) and \(p\), a key step for blending, since these common features will typically be preserved in the blend. Although \(T\) was previously uninteresting, it will have attributes or attribute-types that match the patterns recognised by \(p\) (e.g. van Andel’s One surprising observation). In the invention step, reasoning, experimentation, social interaction strategies rely on \(p^{\prime}\), which might draw on patterns like van Andel’s Successful error in order to pinpoint the seeds of a useful result within \(T^{\star}\). One important guidepost for implementation is the theory-building orientation that says that outcomes may include new patterns of behaviour that the system can draw on in subsequent interactions.
What is particularly needed is an approach to encoding patterns and methods for pattern discovery in a computationally accessible manner. Here we are drawn to the approach taken by the design pattern community \cite{alexander1999origins}, although we recognize that we would be using design patterns in rather nonstandard way:
We want to encode our design patterns directly in runnable programs, not just give them to programmers as heuristic guidance.
We want the (automated) programmer to generate new design patterns, not just apply or adapt old ones.
We want our design patterns to help describe new problems, not just capture the solutions to existing problems.
describe the typical scenario for design pattern writers: “You are an experienced practitioner in your field. You have noticed that you keep using a certain solution to a commonly occurring problem. You would like to share your experience with others.” They also remark that “What sets patterns apart is their ability to explain the rationale for using the solution (the ‘why’) in addition describing the solution (the ‘how’).” Regarding the criteria that pattern writers seek to address, they write: “The most appropriate solution to a problem in a context is the one that best resolves the highest priority forces as determined by the particular context.” Their article describes a number of criteria relevant at the meta-level of pattern writing, e.g. Clear target audience, Visible forces, and Relationship to other patterns. A good pattern describes the resolution of forces, but it also resolves certain forces itself. In terms of our now-familiar diagram:
This diagram does not suggest that every instance of “a solution to a problem in a context” is serendipity – on the contrary, that is just the discovery step. To van Andel’s assertion that “The very moment I can plan or programme ‘serendipity’ it cannot be called serendipity anymore” – of course, if the context is fully determined in advance, and if the solution is completely replicable, then some of the fundamental conditions for serendipity are not met. However, we can also describe patterns with built-in indeterminacy:
Van Andel’s example – Post-it Notes
– You run a creative organisation with several different divisions and many contributors with different expertise. Unexpected discoveries are often made.
– One of the members of your organisation discovers something with interesting properties, but that no one knows how to turn into a product with industrial or commercial application.
– You create a space for sharing and discussing interesting ideas on an ongoing basis (perhaps a Writers Workshop).
– You suspect it’s possible that one of the other members of the firm will come up with an idea about an application; you know that if a potential application is found, it may not be directly marketable, but at least there will be a prototype that can be concretely discussed.
– Writing down and promulgating the Successful error pattern using this template gives one such prototype.