(DRAFT: Liable to change: Please do not save copies.)
In my answers to these questions, I can't represent any community. I seem to disagree with most researchers (though fortunately not all), partly because I am trying to understand what biological evolution produced (very many different things) and how it produced them (what were the mechanisms, and what drove them?), whereas many of the research (sub-)communities are trying to do something different, e.g. searching for the one true/best design for an architecture (usually with various biases distorting the search). The following are rapid, largely unedited, off the cuff reactions. 1. What is an architecture and what does it entail? This has a type/token ambiguity. You can talk about the pattern (instance) of marks on a floor, and how worn it is, how long it has been there, etc. That's a token (instance). You can also talk about the pattern (type) common to all the floors in a building, which is a low-level type, or a more abstract high-level pattern that represents a style that includes many different pattern types, all with instances. Likewise with machine architectures, or system architectures, or symphonic architectures, or biological architectures. There's the typical vertebrate architecture, and the typical primate architecture that's a sub species. And a particular ape with bones malformed by a particular genetic disability can have its own skeletal architecture. More abstractly, as with floor patterns, an architecture can be EITHER a type: A specification for a complex system with parts and relationships. OR a token: Something complex located in space and time with parts and relationships, which may or may not satisfy some known specification. (Termite cathedrals and human cathedrals both have architectures.) Instances of the specification may or may not be embedded in an environment (static or changing) with which parts of the architecture interact, either through a single interaction channel or via multiple parallel channels. [Think of all the service connections of a modern skyscraper. Contrast a design for a large mobile machine, like an Airbus, that plugs itself into different environments at different times -- all sharing certain features.] For some architects who design buildings, those external relationships are important aspects of the architecture, whereas others would use 'architecture' to refer to what could be transported and plonked in a quite different environment. The specification for an architecture type may either rigidly specify a fixed structure, or a space of possible architectures with different structures, as in a grammar for a type of architectures. Compare a grammar for questions of a certain type, or (action) plans of a certain type. Two software systems both describable as having a "production system" (rule-based) architecture could have very different detailed structures because of how the rules are clustered and how they interact. Instances of an architecture type may be static (the architecture of a proof, a poem, a monument) or dynamic, with internal and external interactions producing changes (as in the architecture of a large business), e.g. changes -- in components of the architecture -- in the high level structure of the architecture e.g. spawning new components, deleting some, adding or removing connections -- in the environment (e.g. creating new tools, measuring devices, buildings, food sources, influencing competitors, collaborators, prey, predators, etc. etc.) -- in the incoming and outgoing signals and resources/products. Components may be physical (mechanical, chemical, electronic) or virtual (e.g. compilers, interpreters, operating systems, parsers, learning engines, planners, etc. etc.) Where instances are dynamic the specification may be more or less rigid, like a fixed structure within which different coalitions may form and dissolve over time, changing the architecture. Some dynamic architectures have fixed bounds (e.g. the enclosing walls), while others allow unbounded growth of new nodes or links, or sub-functions (like a system using a programming language that includes recursive data-types and recursive procedures). Compare the architectures of ecosystems. In many biological cases the initial specification of an architecture includes boot-strapping mechanisms for new instances, which enable extensions to the specification to be absorbed from the environment, or in some cases created by the system after some interaction with the environment (e.g. self-organising architectures, as in human minds). [Discussed in Chappell and Sloman IJUC 2007 http://www.cs.bham.ac.uk/research/projects/cosy/papers/#tr0609 ] That seems to be typical of epigenetic influences on information processing architectures in organisms. 2. What is design? Like many words, the word 'design' can refer to a process or a product or in some cases products of products. The phrase 'a design' would typically refer to a product of a design process, though it is possible to talk about the design in an evolved, or accidentally produced entity, insofar as it has a collection of features that could be instantiated in other instances. A design type might be shared between projects in a company specialising in designing drivers for interfaces of various sorts. If the purpose of the design process is to create a particular architecture to be deployed to meet a particular collection of needs, the product may be -- a specification, as in 1, above, where the specification may have many different instances (e.g. different running instances of linux, or even different running instances of a version of linux (kernel version 3.6.2-4 plus fedora features) -- or, more commonly, a class of specifications systematically related to different sets of requirements (as in .config files for a linux package that can be tailored at build time or installation time). -- or a (possibly cobbled together) unique instance with parts and features produced by trial and error, like a hand-built house using materials as they became available. And many other possibilities: e.g. a design product could be a complex kit of parts that can be assembled in different ways to meet different collections of requirements in different environments. E.g. the design common to lego kits, or to meccano kits, or to different versions of linux, or a programming language with associated libraries. 3a. What is a design process? Partly answered above: it is a process that could produce a product, a specification, or in some cases merely an instance. (E.g. a particular sculpture.) In some cases, as with the internet over the last few decades, the design process has been an unstructured, unmanaged, uncodified collection of activities involving much collaboration, competition, copying and modification, battling for supremacy, etc., where most of the participants understand only small subsets of what they are jointly creating, and perhaps nobody understands it all. The design of the internet also includes components produced by some designers that are totally opposed to the intentions and preferences of others, e.g. mechanisms to support 'phishing' or 'denial of service' attacks. In that case only a subset of the results of the design process can be documented until miscreants are uncovered and their work analysed. Most biological design development is a process in which there are no explicit goals and the products are not understood by anyone or anything -- until scientists on the planet find new ways of understanding the planet and its products. 3b. How is it 'formulated' (or codified)? There are (at least) two very different things that could be referred to by a formulation: one is the collection of procedures and protocols (including many document templates) intended to constrain the activities of people involved in the process (specially important in some high security design projects). In other cases the formulation or codification specifies the product, not the process. (Compare developer documentation, maintainer documentation and user documentation.) Some people produce designs whose only formulation is the code, perhaps with comments. Others go to a lot of trouble to provide interface specifications for their designs so that people designing other systems can ensure that they work well with the first design. (Many programmers never learn to do any of this with any rigour. That may not matter for small projects whose products don't last long. In other cases it can be disastrous.) One of the amazing things about evolution is how many designs produced by evolution (plus development and learning -- epigenetic processes) lack any formulation that specifies the design and what it's for and how it works -- instead the design is implicit in all the things that play a causal role in producing instances, e.g. the genome, pre-natal features of the mother, the nurturing behaviours of parents, the behaviours of siblings and other conspecifics, the physical features of environments in which individuals develop (that can be different for different members of the same species, or even the same family). Yet there must be an analysable design with many different facets at different levels of abstraction, playing different roles at different phases of development, growth, learning, and mature functioning, even if the design acquires new facets during the life of each individual -- e.g. if one twin becomes a great composer and the other a top-ranking bricklayer or electrician. NOTE: The architecture of the biosphere? I think the whole process of biological evolution, together with the planet on which it happens, has a complex and changing architecture that has never been fully documented, partly because most researchers lack the conceptual frameworks even to ask the questions -- e.g. about how results of biological evolution and environmental change combine to constantly alter the epigenetic landscape that controls further evolution. There's something similar to be said about the developments in applied computing over the last six or seven decades: but making all that explicit will not be quite so difficult. An important feature common to both is the development of virtual machinery with powerful functions that could not be fulfilled purely by physical machinery. I use the label 'Meta-morphogenesis', partly inspired by Turing's 1952 paper, to refer to those still largely unknown architectural features of biological evolution that generate changes in the evolutionary mechanisms and processes. I am collecting examples of the influences of those features in the hope of stimulating more people to join in the project, here: http://www.cs.bham.ac.uk/research/projects/cogaff/misc/evolution-info-transitions.html But that's just a tiny fragment, and still too disorganised. I don't know if this has anything to do with the aims of your workshop, but it's what I'll be working on for some time to come. Historical Note: The word "architecture" has had different uses among computer scientists and AI researchers. At one time (1960s, 1970s?) it referred to some low level physical mechanisms on which everything else depended, for example a Turing machine with its transition table and tape, or a more conventional computer with randomly addressable memory. I think the usage has changed and now covers a much wider range of features of working systems. However there are some people who still think of the architecture of a system that is fixed, like the old physical implementation machinery, while others (including me) think of many organisms as having changing information-processing architectures. E.g. it seems that a human neonate does not have a fixed architecture into which information is sucked, or poured, or created by inference mechanisms. Rather the kinds of information processing mechanisms available seem to develop during epigenesis, partly under the influence of the genome partly under the influence of the environment and the environment's previous influences on the architecture. [A process sketched in Chappell and Sloman 2007, cited above. Most proponents of architectures for AI systems have proposed a particular unchanging architecture, e.g. SOAR or PRS. In contrast, the CogAff schema specifies a framework within which components and connections can change. See the The CogAff Overview
I am not sure I am an appropriate person to contribute. My main interest is not in
designing new useful systems, but in trying to understand the designs produced by
biological evolution and its products (e.g. development, learning, social interactions, in
organisms, including humans and other species).
I did not have any particular personal aims. I tried to guess what the organisers wanted from
me and did what I could in the time available. A full explanation of what I was trying to do,
why, how, how far I had got, what still needed to be done, etc. would have required a lot
more time. (To some extent I had such discussions in private, especially with people
whose interests in biological systems seemed to overlap with mine.)
I can't tell how well the workshop allowed others to achieve their goals: I had the
impression there were several different agendas not all capable of being integrated in a
In particular, apart from people sharing my interest in natural systems, there seemed to
be people interested in:
Perhaps there were other sub-categories.
I am not sure people with these different interests all understood one another or were
interested in one another's work.
There was also, I think, a potential clash between people who felt all research and
development work had to be strongly based on empirical research and those who (like me)
think the available research methods and tools are too limited in scope and likely to
mislead, so that trial-and-error methods driven by deep theories will be more productive.
Is education research a form of alchemy? http://tinyurl.com/BhamCog/misc/alchemy/ (June 2012)There was also a small subset (including me) who feel that current ways of funding the
The flexible timing of presentations and discussions helped. I don't know whether
break-out groups achieved more than continued general discussions could, given that
it was a fairly small workshop.
Many of the topics raised required a lot more time for discussion (including mutual
education) but that could not have been done within the framework of a two day workshop.
I doubt that that particular mixture of people could have reached convergence in two days,
as there were differences of background, and research or development goals, and the topics
are very complex with many unknowns.
I expect there were various sub-groups within which very useful communication occurred and
that's as much as can be expected in a short workshop.
I would be surprised if many people who attended have now significantly changed direction.
I think that rarely happens
School of Computer Science
The University of Birmingham