Re: Terminology: ABM, Swarm, MAS, etc. (was: Swarm futures...)

[gepr]

Gulyas Laszlo writes:
 > It seems we are on _really_ different grounds as far as terminology
 > is concerned. Not intending to start an end- and meaninless flame war,
 > but wanting to expose the terminology I 'grew into', I'll put forward
 > my case. Those of you not interested in this kind of bubble may
 > stop reading now...

Well, it certainly won't become a flame war. [grin]  But, I think it's
useful to discuss this (and in a public forum).

 > And finally, there are the concrete versions of ABM tools: Swarm, Repast,
 > Ascape, StarLogo and the like.

Here is where most of the terminology problem enters.  "Swarm", as a
term, was intended (and I welcome different interpretations, BTW) to
refer to a set of building blocks for the synthesis of nonlinear
systems.  (I'm using 'nonlinear' to mean non-analytic... i.e. not
conducive to analysis or the "reductionist method".)  Whether or not
one does "simulation" or "modeling" with the building blocks is a
matter of application, not an inherent property of the blocks
themselves.

That means that "Swarm" represents a style or if we're generous, a
method, for synthesizing systems.  The method has some core features,
hierarchical and lateral composability, tolerance of discrete-event
and continuous structures, agnosticism as to the final cause of 
any "observer" (i.e. humans are treated as equivalent to algorithms
=> hence the probing mechanism), independence of the specification 
language, etc.

All of the concepts "Swarm" encompasses are implementation independent.

It's just unfortunate that the single (though hydra) implementation
that comes in the tarball has become known as the complete, end-all,
be-all, of what Swarm is.  I would like to change that because the
SDG's implementation of Swarm is incomplete, unfinished, and simply
off-the-mark in some places.  Just look at the space library.  It's
obvious that it is a *temporary* implementation of the specification
called "Swarm."

So, no, Swarm is not the bits and bytes that you download, it's the
style or method of approaching a system.  The bits and bytes you
download is an aid in that method.

 > I completely agree with you that we shouldn't be sloppy about terminology
 > and I don't want to be splitting hairs either. But during the last few
 > years I spent in these fields, I've never come across the kind of
 > terminology/classification you put forward. Of course, this is partly
 > because I couldn't participate in the last few SwarmFests... ;-)

Well, I don't get my use of the words from SwarmFests.  Actually, I
find myself fighting exactly this same battle at the SwarmFests. [grin]

I think it's quite clear, though, that the position I'm taking can 
be defended from the literature.  I grant you that there is a vernacular
distinction between MAS and ABM.  And it does fall, as you say, roughly
down the lines where MAS is used in the harder fields and ABM is used
in the softer fields.  But that line is always blurred.  And I believe
it's because ABM must be used to build/design an MAS.  And after engaging
in ABM, one always finds themselves with a MAS on their hands. [grin]

And to make matters even worse, my intentions are not about any of
this, really.  My intentions are to discuss the future of Swarm, the
method of synthesis that the SDG's implementation intended to
encourage and proliferate.

It's fine for the discussion to go in a different direction,
especially if nobody else wants to talk about Swarm.  But, I want to
make the topic as clear as possible.

I think both Darren's and Jason's posts are right on target in the
sense that they are talking about the fundamental issues of the
methods (model expression, model verification, and the basic attributes
of *any* artifact intended to approach a goal).  And it's the methods
that need the work.  I, personally, don't care whether one uses 
Object-based tools, functional tools, or sticks and rubber bands, except
from *within* a discussion about what, precisely, one is trying to 
achieve.

So, my question is, what should the next phase of the Swarm try to
achieve?  And that space of possibilities is open to anything from 
continuing a base-level support for an artifact like our current 
implementation all the way out to trying to start an international
standards organization.

-- 
glen e. p. ropella              =><=                           Hail Eris!
H: 831.335.4950                              http://www.ropella.net/~gepr
M: 831.247.7901                               http://www.tempusdictum.com



                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================