Re: [Repast-developer] Topology Notes

[Andy C. <ac...@ll...>]

At 01:32 PM 1/28/2003 -0600, you wrote:

>Having said all this, I think that there is a semantic argument still to
>made here.  I think that your identification of spaces as contexts is
>particularly important.  IF we think of them as spaces, this will never
>be consistent. (A social network is different than a grid).  But if they
>are contexts, which can be layered and represent different kinds of
>relationships, then the semantic difference is eliminated.  Some
>contexts are static others are dynamic.  I think that this has potential
>to be the way forward.  What do others think?
>
>-Tom

This has the aesthetic ring of being "right" that I look for in semantic 
definitions like this, so let me be one to encourage the continuation of 
this conversation. How exactly it should be realized in a software design, 
both one starting "from scratch" and one building on the current Repast 
code base, remains far from clear to me though.

Somewhere in between those two, though, I'll make the following fairly 
newbie-ish observation that I think might be obscurely relevant: when I 
first started studying Repast, I was disturbed that I couldn't find the 
documentation on the basic agent classes and interfaces. Of course, I 
eventually learned that that is because Repast does not actually have them; 
perhaps this is an overly strong statement in its details, but at a general 
level, Repast says nothing about agents at all... They are implicitly 
assumed to be there, but there is nothing explicit in the framework 
mentioning them (like I said, not exactly true). There are, I am sure, lots 
and lots of reasons for that, but whatever they are, there are also 
arguments for introducing them as explicit concepts into an ABM framework. 
One of those reasons is that it can help to decouple agent implementations 
from "simulation implementations", including the "spaces" that the 
simulation has, by defining common behaviors and interfaces that all agents 
must support, in essence providing a beginning to "standardizing" the 
relationships between agents and the rest of the simulation. Since the 
specific issue you are discussing here falls into this class (standardizing 
the relationships between agents and the rest of the simulation, where, let 
me be careful, I'm overloading the term "relationship"... Here I refer to 
the interaction between agents and the rest of the simulation at a code 
level, not "relationship" in the sense that the spaces are capturing 
relationships between agents), it might be a relevant observation.

At a code level, I'd certainly encourage finding a way to capture these 
common behaviors in interfaces rather than base classes if at all possible 
because of the inheritance issue. One can even imagine extending Repast in 
a backward compatible way by defining some interfaces and support for 
agents. If a user wants to provide their own SimModel and their own agents 
that work together without using the Repast agent stuff, fine, that's still 
there. But what could emerge if done correctly is a growing body of 
developers that implements agents that are reasonably swappable into other 
simulations because they implement common interfaces and behaviors and have 
simulations that in turn depend largely on those common things...

Cheers,
Andy