Yes, Robert's right. What seems to be missing from Russ' (arrogantly named) "solution" is that there _are_ no interfaces that "get implemented" and there _are_ no "entities" that emerge. Subjectively, sure, we observe or measure patterns of interaction (often stable over cosmological time scales) and we measure various coherent blobs behaving in such a way that preserves identity for the blobs. But, ontologically, such things are transient approximations... idealizations... abstractions arrived at by the observer.
Even in his paper, Russ claims that emergence is fundamentally abstraction (though "levels" is an irresponsible misnomer). And abstraction is an attribute arrived at via measurement, not a property that exists objectively. In fact, we don't even need the observer/observed dichotomy for this to be true. Any operation will be dependent on some and independent of other aspects of its operand. I.e. any process will ignore some stuff and be totally dependent on other stuff. So, for example, an avalanche depends on type of snow but not on, say, whether my cat scratches me. (There's not much snow where me and my cat live. ;-) The range of an operator, as applied, is a measurement. Emergence depends on the characteristics of the domain and range of some (set of) operator(s). In some cases, the operator is defined by a conscious observer and in some cases, it isn't. Hence, Robert is right that (some) emergence is (solely) in the eye of the observer. But in some cases, emergence is "out there", particularly when the operator isn't defined by a conscious observer, meaning Nick and Russ are right that (some) emergence exists objectively. It's important to note, however, that this CAN be orthogonal to implementation. It is primarily a function of the domains and ranges of the various operators being applied. In software, these are called "aspects". And although aspect-oriented methods tend to take Russ' approach and try to build a simple map between aspect and mechanism, that's not necessary for any software. Aspects are defined by the _usage_ patterns of the users, not the mechanisms that implement the aspects. Yes, the two can be engineered to correspond; but they need not be. A piece of software can exhibit aspects that are not (easily) traceable to the organization of the mechanisms that implement them. In fact, a piece of software can exhibit aspects that forever cease to obtain when the users stop using the software in that way... and in some cases, it only takes a tiny, invisible tweak in the way people use it... hence the script-kiddie exploits and the blossoming domain of software security. That leads to a question: is an aspect _implemented_ if the software is never used in a way that exhibits that aspect? Yes, it is implemented. Does it emerge? No, because an aspect only shows up if the mechanism is _used_ in a particular way. No usage pattern, no aspect, no emergence. Hence, emergence is distinct from implementation, at least in some identifiable cases. (This existence proof, disproves Russ' claim, absent lots of semantic gymnastics surrounding the vague and useless term "emergence".) If the operator isn't applied, there is no emergent attribute. Hence, emergence is not the dual of implementation. Emergence is the result of applying particular operators to the mechanism. I.e. emergence is in the eye of the beholder, even where the beholder is another mechanism. (This extension allows one to hypothesize that there are many other cases where implementation is distinct from emergence.) Thus spake Robert Cordingley circa 09/07/2009 06:57 AM: > IMHO, I thought 'to see', 'observations', 'arrangements' and 'order' > were also largely 'in the eye of the beholder'! If emergence is ever to > become a (part of) science, repeatable measurements (from verifiable > observations) leading to one or more calculated parameters is the only > way to bring 'emergence' in from the cold/limbo/twilight zone, where it > appears to be right now. Statistical and/or structural pattern > recognition <http://en.wikipedia.org/wiki/Pattern_recognition> seem to > be good places to start. (See also descriptive statistics) > <http://en.wikipedia.org/wiki/Descriptive_statistics> I don't know if > this has yet been attempted/done but hope to hear otherwise. Perhaps > it's just too hard. -- glen e. p. ropella, 971-222-9095, http://agent-based-modeling.com ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
