If we think of a collective mind as a set of knowledge artefacts (data, knowledge, community and member skills, opinions, awareness, practices, policies …), then by improving the collective mind we assume activities that improve the state of the knowledge artefacts (where improvements are eventually evaluated against collective mind success metrics set by the community).
-
(from the Colabo.Space Manifesto)
Those knowledge improvements happen over time incrementally (Shipman III, 1994) by various actions (supported by various tools) and community members. Such tools for incremental improvement of the incremental collective mind instruments MindStuff (in the context of the collective mind) or colabo puzzles (in the context of the Colabo.Space) (fig. mindstuff).
Figure mindstuff: MindStuff - a conceptual diagram of tools for incremental evolution of the collective mind. At the bottom is KnAllEdge collective knowledge, and at the top are various MindStuff (IBIS, BrainStorming, …) used by users to tweak the knowledge space.
Mindstuffs implement the ColaboDialogue principle where actors are all participants in the Mindstuff activity, knowledge is the knowledge affected by Mindstuff on behalf of the actors.
MindStuffs (End-user tools) are realized through the composition of the basic building blocks; for example IBIS and Presentation MindStuff are realized as a composition of KnAllEdge but and ColaboGrammar, while the CoEvoLudens methodology is realized as a composition of ColaboFlow, KnAllEdge, RIMA, and ColaboFramework.
Technical Implementation
Colabo Puzzles (MindStuffs) are implemented as independent components that are packed, published and provided as a separate package - a puzzle-package. They can exist at any level (backend-service, backend-logic, frontend-service, frontend-component, frontend-plugin (for extending another puzzle)). Each package can contain multiple puzzles if they are conceptually similar.
The Colabo.Space instance is agnostic of additional puzzles at the code, compile and build level. The given system instance is extended with a given puzzle through a configuration file and each puzzle describes preferences as to how, where and what they want to be integrated in/with. Each puzzle-package declares through its configuration file which puzzles it offers and which puzzles it requires.
We provide procedures and a set of tools (colabo-cli) for reporting, creating (fig. colabo-cli-tool-puzzle-create) and managing puzzle-packages [1] and the puzzle config file. It simplifies the process, and it is available globally on the developer's machine. Eventually, we aim to expand the tool to make more advanced operations over living colabo.space instances.
Figure colabo-cli-tool-puzzle-create: Creating a new frontend puzzle, "knowledge gardening", with the colabo CLI tool
In the running code, the system accesses a puzzle through a dependency injection [2], which keeps code-testing simple and enables declarative run-time dependencies. Each puzzle communicates with other puzzles or system components using a publish-subscribe pattern [3], avoiding hardcoded code dependency and awareness.
Puzzles can use ColaboGrammar to describe their interest in other puzzles, user interface integration, and knowledge types of interest.
Puzzles and their architecture are continuously tested on our systems, with third parties (Earth System Bridge, funded by NSF's grant scheme EearthCube; AudioCommons, funded by EC's grant scheme H2020) and open-source programs. This process helps us to understand opportunities and frictions. Observed problems external developers experienced with puzzle development was the reason for introducing the Colabo tool.
References
Shipman III, F. M., & McCall, R. (1994, April). Supporting knowledge-base evolution with incremental formalization. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 285-291)
Colabo (CLI) Tools https://www.npmjs.com/package/@colabo/cli ↩︎
Dependency Injection: https://en.wikipedia.org/wiki/Dependency_injection ↩︎
Publish-subscribe pattern https://en.wikipedia.org/wiki/Publish–subscribe_pattern ↩︎
