Re: [Repast-developer] Context - Topology vs. Model - Graph

[Mark R. D. <mdi...@la...>]

Tom Howe wrote:
> I'm feel like the Topology needs to have an internal type as well as the
> context.  Here's why:
> 
> You have a Context called Workplace.  In this Context, there is a
> Reports-To topology,
> a gets-advice-from topology and a friends topology. (Apologies to
> Krackhardt).  But they all fall under the Context called workplace.
> 

I guess I'm more confused by this I don't really understand the whole 
Workspace thing your talking about here.

I'm not suggesting that the topologies shouldn't have designated 
"types". Just that currently these types get set in two different places:

internal to the Topology itself via get/setRelationType and externally 
in the Context, for example in the DefaultContext:

  /**
    * Add a new type of {@link RelationTopology} to this context.
    * @param top
    */
   public void addRelationType(RelationTopology top) {
     relationMap.put(top.getRelationType(), top);
   }

now if someone did:

RelationTopology topo = new ....;

topo.setRelationType("foo");

Context ctx = new ...;

ctx.addRelationType(topo);

topo.setRelationType("bar");

now the mapping in the Context for topo is "foo" but when one gets the 
topo object and calls getRelationType() they get back "bar". This is a 
delema I might assume many model developers are at risk of making. Two 
possible suggestions:

1.) remove the setRelationType("") method from the interface and force 
all RelationalTopologies to either hardcode the type or provide a 
constructor parameter to set it on instantiation.

2.) How many topologies will there ever really be in a context, is it 
logical to assume that a lookup function could be written in the Default 
context that scans a Vector or ArrayList of the RelationTopologies and 
returns the first match using RelationTopology.getRelationType().

I'm unsure which is best.
-Mark



> I do like the comparison with Servlets, etc.  This is very much how I
> was thinking of the Context stuff.  If we think of Context at the
> SimModel level, though, I think that we need to have the ability for
> nested Contexts.  Using the scenario above, I could see a situation
> where someone interacts in a WorkPlaceContext as well as a
> FamilyContext.  These would need to be nested inside GeneralContext at
> the model level.  I actually think that this is a very good idea.  It
> would fall into line with many of the ideas David has about situation
> theory.
> 
> Let me know what you think.
> 
> -Tom
> 
> -----Original Message-----
> From: rep...@li...
> [mailto:rep...@li...] On Behalf Of Mark
> R. Diggory
> Sent: Sunday, July 20, 2003 10:10 AM
> To: repast-developer
> Subject: [Repast-developer] Context - Topology vs. Model - Graph
> 
> 
> I've been trying to get this concept of mapping between Topologies, 
> Graphs and Spaces a little clearer in my own head. Basically I think it 
> boils down to the following:
> 
> 
> Context:
> Simply a Map of existing Topologies based on key "type". Adding a Agent 
> to the Context actually adds it to all the Topologies that are in that 
> Context, removing does the opposite.
> 
> Topology:
> DiscreteSpace, Graph or Other Object that encapsulates the relationships
> 
> between a Set of Objects.
> 
> 
> 1.) I'm concerned about Topologies having "type" defined internally 
> within them. theres always room for errors where the type in the 
> Topology may be able to get out of sync with the type it is mapped to in
> 
> the context. I recommend removing or internalizing/finalizing this and 
> only focusing on mapping by the key/value pairs of the Context.
> 
> 2.) I'm starting to think that a Generic Context could be written into 
> SimModels (or SimModelImpl/SimpleModel) in such a way that we begin to 
> define "Context" in terms of its "generic" definition and the way it is 
> usually applied in the programming community.
> 
> For example, in the JSP/Servlet API, Context refers to attribute 
> "mappings" of various "scopes". ServletContext, SessionContext, 
> RequestContext are various scopes where attribute mappings can occur, 
> each has a certain scope of longevity (Servlet the longest -- request 
> the shortest). There are also usage of Contexts in other Applications; 
> JNDI/LDAP, Jelly, JXPath, Jaxen, Xalan, Saxon to name a few. Mostly 
> oriented to Webapplications, I believe this is where the design pattern 
> originated. In all cases the concept of a "Context" is approximately the
> 
> same. It keeps a set of mapped attributes (or topologies in our case) in
> 
> scope for a specific hierarchy of events/objects that are being
> processed.
> 
> It may be possible to look at a "basic" Repast model to begin to see 
> this applications power:
> 
> 
> Global Context
> (1.SimModel)
>     |
> Spatial Topology --------->  Localized Context
> (2.Space, Graph...)          (3. Agent)
>                                  |
>                               Game Topology -----> Ultimate Decision
>                               (4. a set of possible Decisions)
> 
> 
> This sort of structure would allow one not only to "hot swap" various 
> Spatial and Graph Topologies at level 2, but to also "hot swap" various 
> Gaming strategies applied at the "scope" of each Agent. A Game then 
> becomes a topology of related "decisions" that an Agent may decide 
> between when being processed, different decision topologies would have 
> different content and structure thats independent of the actual 
> "Decisions".
> 
> I've been playing around with "Functors" on another project. Functors 
> are basically Objects that can perform a "function" on a set of objects.
> 
> If "Decisions" were "Functors" in a RePast model then they could 
> encapsulate a coded "action" that is to be performed on an Agent in a 
> Topology of that model. In a generic "Gaming" framework, the user would 
> only need to write "Decisions" that would be performed. The framework 
> could provide generic API's upon which these Decisions would be coded.
> 
> -Mark
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Repast-developer mailing list Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer