When you say high-level support for agent state, space, and composition, would you mind giving examples. In most cases the agent state and space (beyond networks and grids) will probably be fairly problem-specific. (I'm not sure what you mean by composition.) Other than building our own version of something like AMF <http://www.eclipse.org/proposals/amp/>, which is very ambitious and beyond the scope of our current capability, what sort of high-level support can be provided? Besides, why wouldn't we want to use AMF itself when we get to that point? As the AMP page<http://www.eclipse.org/amp/>says, "AMF generates models for Escape, Ascape and Repast Simphony." Why not plan to extend it to include models for our system as well if/once it becomes useful enough to want to generate models for it?
-- Russ On Tue, Sep 1, 2009 at 1:00 PM, Miles Parker <[email protected]> wrote: > > Hi guys, > > Well, if you want support for high-level representations of agent state, > space (including networks) and composition, it would be a hell of a lot > easier than building your own. :) You can then generate actual code for > various APIs or roll your own implementations. Is that answering your > question? > > (Same thing on runtime side; AMP provides loosely coupled API for agent > execution and visualization within Eclipse IDE.) > > > > > On Aug 31, 2009, at 7:36 PM, Russ Abbott wrote: > > Hi Doug, > > I got Miles message as well, but I want to ask you about this one anyway. > I'd be interested to know what your answer to your question about added > value would be for you to think that an ABM framework is worth the trouble > to build. I'm not asking as a challenge but so that I have some guidance > about what you think would be valuable/important to include in our system. > > I'm copying Miles who may not actually be on the list. > > Miles, I'd be very interested in your answer also. How would you respond to > Doug's added-value question wrt AMF > > -- Russ > > > On Tue, Sep 1, 2009 at 11:35 AM, Douglas Roberts <[email protected]>wrote: > >> *"As I see it, Drools is essentially a layer above Java that supplies a >> great many of the capabilities I want. It doesn't have the notion of agent >> at all. But we can build that."* >> >> I think I get it. >> >> Layers of abstraction, piled upon more layers. That's the answer. I >> forget what the question was. >> >> I can get behind that (hey, I work for a living too). >> >> Aside: Warning flag #2 usually goes up when I see the words "Schwa, schwa, >> schwa, Framework, schwa, schwa" preceding the description of some >> historically-vetted simulation approach, or another. >> >> What I would really love to see is a concise statement of what the added >> value that this proposed approach is supposed to bring to the table. >> >> --Doug >> >> >> On Mon, Aug 31, 2009 at 6:54 PM, Russ Abbott <[email protected]>wrote: >> >>> Hi Miles, >>> >>> I got both of your messages. Thanks. >>> >>> Our situation is that we have embarked on building a framework based on >>> the [email protected], The Friday Morning Applied Complexity >>> Coffee Group <[email protected]>ols >>> Expert<http://jboss.org/drools/drools-expert.html>Rete rules engine. Drools >>> was developed within JBoss for controlling >>> distributed J2EE applications. It wasn't developed with agent-based modeling >>> in mind. Nonetheless I like it as a starting point for a number of reasons. >>> >>> - Its rule language is both simple and open. It supports get/set >>> operations on Java objects. So it it not limited to operating on any >>> particular category of things. In addition, the rule language allows any >>> java method call to be embedded within a rule. That may seem too open, >>> but >>> it allows new primitives to be added to the repertoire of agent >>> operations >>> very easily. The rules may be written in MVEL<http://mvel.codehaus.org/>, >>> which is a Java expression language. Although I'm not an expert in either >>> Drools or MVEL, my expectation is that one could embed a Genetic >>> Programming >>> capability within agents by using the MVEL parser. What's interesting >>> about >>> MVEL (from the little I've read about it) is that it's basically the >>> kind of >>> code that one would write in a Java method. That is, it doesn't have >>> class >>> declarations, but it supports Java procedural and evaluation constructs >>> within an expression-oriented framework. >>> - Drools allows one to add rules dynamically. >>> - One can instantiate as many Drools Rete engines as one likes. They >>> can share the same workspace. They can run in separate threads. >>> >>> As I see it, Drools is essentially a layer above Java that supplies a >>> great many of the capabilities I want. It doesn't have the notion of agent >>> at all. But we can build that. Each agent can have its own Rete engine and >>> run in its own thread. That would be the next layer. All this is still >>> really just Java libraries. In adopting Drools and building some agent-like >>> capabilities on top of it, we are not yet cutting off our ability to add >>> features in straight Java. >>> >>> Part of my vision is that the framework will support what I've been >>> calling service oriented agent-based modeling. That means that everything an >>> agent does can be understood as a service that another agent can make use >>> of. The simple paradigm is that an agent operates on objects in its >>> environment -- including possibly other agents. An agent rule would take >>> objects as input and produce either new objects or modified objects as >>> output. Clearly this is an extraordinarily simple paradigm. But I think it >>> supports a great deal of what I think we need in a modeling environment. >>> >>> Once we have that layer going, I'd like to develop mechanisms to hook >>> agents up in networks. (Again, something quite simple.) A simple version of >>> such a network within my basic paradigm is a supply chain. But the network >>> would allow loops and it would be dynamically reconfigurable. The agents >>> could restructure it as circumstances suggest. So what I'm saying here is >>> that a networking capability would be another layer in this framework. One >>> wouldn't be forced to use it, but it would be there. >>> >>> My question for you is what would you want to see as additional agent >>> support in a project that took this route? >>> >>> -- Russ >>> >>> >>> On Tue, Sep 1, 2009 at 9:22 AM, Miles Parker <[email protected]>wrote: >>> >>>> >>>> Hi Russ! >>>> >>>> I am developing two components that could be useful here. The AMP >>>> project itself is overall infrastructure for this kind of modeling, and you >>>> can use the olde Ascape API is you wanted for that. You can add rules in >>>> mid-run w/ Ascape *but* they apply to a collection of agents. An >>>> alternative >>>> is to roll your own rule sets and have them fired as part of a single >>>> Ascape >>>> rule. At least all of the other ABM stuff would be supported. >>>> >>>> The more directly aplicaable bit is the Agent Modeling Framework whihc >>>> is similar to the Eclipse Modeling Framework. There is a very high level >>>> represeentation for agent behavior using a Query->Control->Transofmration >>>> paradigm that would suit *I think* what you say well -- though it would be >>>> good to have an example to know for sure. Now.. the issue with AMF right >>>> now >>>> is that it is designed for static rules / behaviors. That is, the >>>> infrastructure uses code generation at design time, but there is no such >>>> limitation for models themselves -- but that is a distinction with a >>>> difference at the moment as there is no way to execute such agents. :). >>>> Marcus Daniels especially has convinced me of the importance of >>>> self-modifying/dynamic rulesets and I think it is also a potential big >>>> advantage of the Meta-Model approach because it provides clean high-level >>>> semantics. One (of many many) things that I would love to see happen with >>>> AMF is a dynamic / interpreted run time for self-modifying models. EMF does >>>> a similar thing quite well and there is no reason that in principal this >>>> couldn't be done with AMF. Basically, instead of generating code that maps >>>> the high-level AMF description to some existing API toolset (e.g. Repast, >>>> Ascape) you'd have an execution environment that loaded an AMF model and >>>> then invoked API calls through reflection. Obviously you'd take a >>>> performance hit but if you had nice high-evel APIs that mapped well to the >>>> AMF meta-model it needn't be huge. >>>> >>>> Sorry if this is somehwat confused but hopefully enough info to see if >>>> there is any potential here. >>>> >>>> cheers, >>>> >>>> Miles >>>> >>>> On Aug 23, 2009, at 2:15 PM, Russ Abbott wrote: >>>> >>>> Hi Miles, >>>> >>>> We exchanged some mutually appreciative emails some time ago but haven't >>>> spoken in quite a while. I hope things are well with you. >>>> >>>> I'm looking for an ABM framework in which (a) agents are driven by >>>> forward chaining rules (i.e., a "blackboard" system) and (b) those rules >>>> are >>>> themselves first class citizens in the model so that, for example, an agent >>>> can create a new agent with dynamically generated rules or an agent can >>>> modify its own rules dynamically. >>>> >>>> Owen Densmore of the FRIAM group suggested (see below) that you may be >>>> working on something like this. Are you? I can't find the reference Owen >>>> referred to. >>>> >>>> Thanks, >>>> >>>> -- Russ Abbott >>>> _____________________________________________ >>>> Professor, Computer Science >>>> California State University, Los Angeles >>>> Cell phone: 310-621-3805 >>>> o Check out my blog at http://russabbott.blogspot.com/ >>>> >>>> >>>> >>>> On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[email protected]>wrote: >>>> >>>>> Isn't this close to Miles Parker's latest work? His WedTech talk >>>>> seemed to suggest that. His proposal was accepted, and he's got a project >>>>> page: >>>>> http://www.eclipse.org/amp/ >>>>> .. he may have become less ambitious in the rule-driven approach, not >>>>> sure. >>>>> >>>>> -- Owen >>>>> >>>>> >>>>> >>>>> On Aug 22, 2009, at 9:58 PM, Stephen Guerin wrote: >>>>> >>>>> Russ, >>>>>> >>>>>> I haven't seen a system like your describing. It shouldn't be too hard >>>>>> to assemble though if the rule grammar was simple. >>>>>> >>>>>> -S >>>>>> --- -. . ..-. .. ... .... - .-- --- ..-. .. ... .... >>>>>> [email protected] >>>>>> (m) 505.577.5828 (o) 505.995.0206 >>>>>> redfish.com _ sfcomplex.org _ simtable.com _ lava3d.com >>>>>> >>>>>> On Aug 22, 2009, at 9:13 PM, Russ Abbott wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> I'm interesting in developing a model that uses rule-driven agents. I >>>>>>> would like the agent rules to be condition-action rules, i.e., similar >>>>>>> to >>>>>>> the sorts of rules one finds in forward chaining blackboard systems. In >>>>>>> addition, I would like both the agents and the rules themselves to be >>>>>>> first >>>>>>> class objects. In other words, the rules should be able: >>>>>>> • to refer to agents, >>>>>>> • to create and destroy agents, >>>>>>> • to create new rules for newly created agents, >>>>>>> • to disable rules for existing agents, and >>>>>>> • to modify existing rules for existing agents. >>>>>>> Does anyone know of a system like that? >>>>>>> >>>>>>> -- Russ >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> ============================================================ >>> 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 >>> >> >> >> >> -- >> Doug Roberts >> [email protected] >> [email protected] >> 505-455-7333 - Office >> 505-670-8195 - Cell >> > > >
============================================================ 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
