(DRAFT: Liable to change: Please do not save copies.)
See also
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
common project.
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.
E.g.
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
Maintained by
Aaron Sloman
School of Computer Science
The University of Birmingham