Skip to content

Instantly share code, notes, and snippets.

@holtzermann17
Last active September 10, 2015 09:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save holtzermann17/405f82e217ea7f62a7c3 to your computer and use it in GitHub Desktop.
Save holtzermann17/405f82e217ea7f62a7c3 to your computer and use it in GitHub Desktop.
patterns for concept invention

Hi all: I've typed up notes that we collaboratively produced at the recent workshop at Goldsmiths! We generated 8 patterns and 15 associated concepts. I will look forward to talking more with you all about how we can use this stuff in our ongoing design work. One meta-level "next step" will be to think about the connections between these patterns. What are some generalizations or "bridge concepts" (blends?) of the patterns that would help connect them to one another, and to our core methodology?

One thing I'd like to invite you all to consider would be to join in a not quite last-minute submission to the Pattern Languages of Programming conference (http://www.hillside.net/plop/2014/). The deadline is April 28th, and so if we're going to do this, we have to work fast!

I think that blending and patterns could be a strong match, and I think this work can be of value not only for our design of the COINVENT system, but also, ultimately, as a way to make our work useful to many other programmers and computer scientists. This is a long-term vision, but my hope this month is just to outline the first steps.

Again, you are all invited to co-author this; to help speed that along, I'm copying the text of this post here: http://socrates.io/#tzwBopu - this is a real-time collaborative editor for MarkDown, so very quick indeed. Please hop on and make any changes or additions any time, or add comments here. If we get enough material together to for a submission, we can move to some other format for final polishing. I'll recopy contents from the real-time system to this post periodically.

Thanks again for your participation in the interactive session! Check out the patterns and concepts after the jump.

  • Joe

About the patterns

These patterns are developed using a slight variation on Christopher Alexander's (1977) original pattern schema. The same technique has been used to generate and codify a set of patterns that form the core of the “Peeragogy Handbook” (Rheingold et al., 2014). The Peeragogy pattern catalog is designed to help upstart groups build collaborative practices of peer learning and peer production.

The challenges in the COINVENT project, particularly the social creativity side, are different. We are working with computers, not people. However, many of the same issues will apply -- peer production by a collection of "bots" should have some features in common with peer production by a collection of humans. We are charged with building a "simulation of social creativity," and while we do not need to make a simulation of human creativity, we do need to make a convincing case that we are modeling "social dynamics" in some meaningful way.

The pattern catalog that is being developed here has its origins in an interactive session held at Goldsmiths college during the April 2014 meeting of the COINVENT EU project. Participants were invited to write patterns down on small pieces of paper, and to tape these onto a whiteboard, where arrows could be drawn connecting the individual patterns. Stand-alone concepts were added using sticky-notes. The next round of revisions and problematics moved to the group blog and a real-time editor (socrates.io). Key questions include:

  • How to take patterns that have been *quasi-*formalised, with humans in mind, and translate them into something a machine can use?

  • Can the formal "blending" paradigm adopted by COINVENT, in the mode of Joseph Goguen (1999, 2004), be useful for pattern-based design in the mode of Gamma et al. (1995) and Richard Gabriel (‎1996)?

If so, this may lend useful formality to the design pattern approach. COINVENT itself can be taken as a test-case for bootstrapping. Can we use the patterns described below be formalized and connected to a blending apparatus? What other features will we need in order to model social creativity in such a system?

Since the COINVENT project is just getting started, the current paper is very much a design exercise. Each pattern will be accompanied by Commentary that looks at the ways in which the pattern can be formalized using blends.

Collaborative creativity

Definition: A collaboration between people, agents, or machines to do something original and worthwhile.

Problem:

  • communication and understanding
  • focus
  • agreement on what's important

Solution:

  • Creating a language that everybody understands
  • reusing old solutions
  • delegate repetitive tasks to computers

Challenges:

  • division of work
  • implicit assumptions
  • divergence of interest

What's next: Finding domains where roles of humans and computers interact with humans and computers.

Commentary

This seems like a good place to start, since we have to make our own breakdown of tasks, even to work on this paper.

Informal to formal

Definition: These patterns, and maybe all "social stuff" is somewhat informal.

Problem: How can we deal with this informal stuff inside this relatively formal project?

Solution: Find ways to "eat our own dogfood", i.e. document our process of social creativity and try to formalize bits of it using the tools we make.

Challenges: Is this a valid method for doing research? And... will it work?

What's next: Write up this workshop as an example.

Commentary

This seems like a useful point of reference too. Surely there are some well-known approaches for doing programming based on design patterns -- that's what they're "for". Even Alexander includes a section in his book about "construction". So let's look at that. What can be learned from these earlier quasi-formal approaches that might be relevant to programmatic concept (read: code) generation using the COINVENT system?

Knowledge rich

Definition: Per common sense computing, we may need a large knowledge base.

Problem: If we want to invent anything new, we might have to build on a lot of what's old.

Solution: Let's build a database of computer math, or reuse what's available

Challenges: Mohan Ganesalingam's PhD thesis -- parsing! -- extending the existing knowlege base will take work.

What's next: Surveying what knowledge bases exist that we could use.

Commentary

A knowledge rich system is in some ways compensating for the absence of "informal" knowledge. For the computer, by and large, things are entirely "formalised," although the programming methodology may have varying degrees of messiness and room for error/interpretation. Programming helps to squeeze out any "implicit assumptions" (xref: Collaborative creativity).

Fill the gaps between generalization and instantiation

Definition: In basic sciences and natural sciences, there are two main directions of discovery: (1) constructing general theories to describe phenomena; and (2) building on examples and specific experiments to get general explanations.

Problem: The two primary main directions have been shown to be insufficient for building a global and more general explanation or formal description of natural and abstract phenomena in the world.

Solution: Integrate the two directions of research in a unified approach.

Challenges: Find a suitable meta-formalism (semantic and syntactic) in order to express formally what a "scientific" problem or conjecture is.

What's next: State of the art research and finding inspiring instances of the main intuitions.

Commentary

"Patterns" as the name indicates, generalise. But, indeed, if we can make some patterns that allow us to describe specific experiments, then we can get the best of both worlds. If we just build pattern catalogs without code, then we stay at the general level. On the other hand, if we build code without thinking about the patterns, that's not so good either. If we cannot connect these two by progressively formalising the way programs are written, we may be missing the trick. On the other hand, since programming does, for now, usually involve humans, we should not underestimate the magnitude of this task.

Michael Atiyah: "What is the good of a theory if it does not solve problems and what is the good of an infinite collection of disjoint problems, however interesting each individual one may be. We must bear in mind that mathematics is a human activity, that the aim of solving problems or doing mathematics is presumably to pass on information you have gained for posterity. The main problems in mathematics can be cumulatively built up, sifted out, and the important ones retained. We have the main-stream of mathematics flowing but we have lots of tributaries, lots of sidestreams that come in and feed the main-stream.”

Pattern of use for COINVENT

Definition: Use of a blending system.

Problem: The user wants to reconcile two existing domains. What concepts arise? Do they exist already?

Solution: The computer suggestions "blend" concepts and links to existing material or knowledge about novel concepts.

Examples: An engineer wants to model a system with a combination of two theories, say fluid mechanics and statics.

What's next: State of the art research and finding inspiring instances of the main intuitions.

Commentary

What does it mean to work in two different domains? It means working with two different sets of assumptions (whether implicit or explicit), two different ways of working. For example, the candidate domains in this paper are pattern-based design and computational blending. In what ways do "blends" allow us to compress or integrate findings from different fields? Perhaps we build new ways of working that combine aspects of two other ways of working. In this case, we are not just inventing new "concepts,” but new practices. (This is similar to working at the process level, in the FACE formalism from Colton et al.) If these new ways of working are subject to a fitness assessment, they may or may not be passed on to posterity (xref: Fill the gaps between generalization and instantiation). I would like to propose that any robust "pattern of use" will include an evaluation or evolutionary component (xref: Evaluation of blended ontologies). This would match the semiotic perspective of Goguen and could connect it for instance to the work of Paul Kockelman (2010, 2011).

What can we learn from rational reconstructions?

Definition: What do we learn when software does something vaguely similar to a rational reconstruction of something vaguely similar to how Hamilton invented quaternions?

Problem: How can we present this as a step forward?

Solution: Don't present it as:

  • A simulation of what Hamilton did
  • Understanding the human mind in general
  • A tool for new inventions

Do present it as: A valuable computational model which was cognitively inspired. Why valuable? It is a tool which others can use to guide psychology tests where human cognition is predicted.

Challenges: Aiming for new inventions in mathematics and music.

What's next: Build a catalog of rational reconstructions that will only to be looked at the end of the project.

Commentary

What are the relevant cognitive inspirations/foundations? How would the quaternions look if we approached them as a (pattern-based) design problem rather than a blend? Can we make a very naive and informal reconstruction as a "bridge" to the rational reconstruction? More broadly, can we find a place for naive, evolving, notions within the theory of concept blending? Here's an almost paradigmatic example:

Gilles Deleuze: "A well-known test in psychology involves a monkey who is supposed to find food in boxes of one particular colour amidst others of various colours: there comes a paradoxical period during which the number of 'errors' diminishes even though the monkey does not yet possess the 'knowledge' or 'truth' of a solution in each case: propitious moment in which the philosopher-monkey opens up to truth, himself producing the true, but only to the extent that he begins to penetrate the coloured thickness of a problem.”

Real blends versus toy blends

Definition: We want to understand and build blends: how do we go about it?

Problem: To tackle blending in real-world applications, we start with toy examples, but it is hard to project the toy solution onto the real applications.

Solution: Let's use made up examples with a large size.

Challenges: It's easier to understand simple toy examples!

What's next: Focus on "realistic" problems.

Commentary

This pattern seems to be making a "methodological" point. Anything that is large-size enough to be considered "real-world" will also be relatively knowledge-rich (xref: Knowledge rich). So, again, building up some knowledge base of examples seems likely to be worthwhile. One example that is on the "edge" of real-world is mathematics, and it's not terribly hard to build a computational-accessible knowledge base of mathematical concepts; there are in fact many examples. Working at the level of individual definitions and theorems taken from the written record is somewhat different from working at the highly-computational generative level exemplified by HR. It would be interesting to combine these two levels, giving HR a massive cross-domain search space to play/work with.

Evaluation of blended ontologies

Definition: After we build the infrastructure and provide the language for doing blending, we have to assess the results.

Problem: How to sort out the interesting/creative blends from the rest?

Solution: Use the idea of requirements to formulate properties (e.g. probabilistic theories). Surely, the user experience matters, and breaking down "how to do it" into steps will allow an analysis of the whole workflow.

Challenges:

  • How to find requirements?
  • No current tools or software products do what we're trying to do
  • What are the right questions to ask?
  • Sorting out reasoning in/about ontologies

What's next: Develop "competency workflow" in Ontohub.

Commentary

Looking at Annex I, we have a list of potential users. The COINVENT dev team came up with a list of potential applications (which could be abstracted into a set of tests, for test-driven development of the system). In addition to needing more concreteness around these tests, again, the idea of an evolutionary approach seems important! What we need are some notions -- and probably abstract notions -- of "quality". Indeed, we could apply the blending paradigm here, too. Given a population O, and an environment X, what does O.X produce in the next iteration? Surely we should be able to implement standard things like low-pass and high-pass filters as "blends", for example.

Annex I: Who are the end users of coinvent?

  • pure mathematicians
  • applied mathematicians and engineers
  • mathematical modeling
  • musicians
  • nonmathematicians and non-musicians
  • software developers
  • poets and artists

Annex II: Concept pool

Evaluation of blends in art

Common sense approaches in AI

Large dataset

Generic instances

Instantiation

Theorization

Cognitively inspired model

Production system

Scalability

Metacognition

Social creativity

Narrative: singular, homogenous timeline

Multiplicity: simultaneously, many things are true

Rational reconstructions

"Simulation" of the past

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment