Rule driven agent-based modeling systems

[Owen Densmore]

Folks: This is an OK talk on neo4j & graph dbs:
   http://www.scribd.com/doc/17062895/Neo4j-The-Benefits-of-Graph-Databases
Here's the pdf in case you find scribd as annoying as I do!
   http://backspaces.net/temp/Neo4jTalk.pdf

     -- Owen


On Aug 25, 2009, at 6:29 PM, Owen Densmore wrote:

> Hmm..just a thought: Have you considered "semantic networks"?  Marko  
> Rodriguez:
>  "Marko A. Rodriguez" <[hidden email]>
> .. has drawn several of us into considering "triple stores" as an  
> adjunct to our work, both in redfish and the santa fe complex.
>
> The triple stores contain many triples of the nature of
>  A verb B
> .. where A & B are nouns: Marko Knows Steve.  Knows is a link  
> between Marko and Steve.
>
> The triple store is a graph database such as:
>  http://neo4j.org/
> RDF is the "semantic web" use of triple stores:
>  http://en.wikipedia.org/wiki/Resource_Description_Framework
> .. and neo4j has an RDF layer, I believe.
>
> From your description, I could see models where agents were nodes  
> with links between themselves.  The dynamic nature you describe  
> could be simply removing and adding links.
>
> I think the graph database idea is on the brink of exploding upon  
> the computing scene.  Its been around for quite a while, but folks  
> are just starting to understand just how powerful a notion they  
> are.  Definitely NOT sql structured .. but might work very well in a  
> Big Table like Google's App Engine.
>
>    -- Owen

============================================================
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

[Russ Abbott]

Thanks Owen.

Yet another very interesting development that I had completely missed.  From the introductory papers it seems to me the primary advantage is in what they call semi-structured data. (At least that's what the "KNOWS" examples in the two tutorial-level papers seem to illustrate.) Basically KNOWS is a relation -- either a link in their ontology or a table in a traditional relational DB. The attributes that hang off it and the attributes that hang off the entities being related are much more open-ended than in a traditional Relational DBMS. 

But they give up SQL in the process. Now, I've always thought SQL was ugly. But at least its declarative. Their substitute consists of Java methods that facilitate navigating around their database. So agents aren't going to be writing new navigational methods.  Perhaps everything can be raised to a sufficiently abstract level that new navigational methods aren't needed. I guess that's to be seen.

Since my model will certainly be network-oriented, Neo4j may be a good choice for a way to store and manipulate it. I actually hadn't begun to consider how the network should be stored. I figured that nodes would be just linked together somehow.  And I hadn't thought about persistence at all!  So Neo4j answers questions I hadn't begun to ask.

Thanks.

-- Russ

On Wed, Aug 26, 2009 at 10:44 AM, Owen Densmore <[hidden email]> wrote:

Folks: This is an OK talk on neo4j & graph dbs:
 http://www.scribd.com/doc/17062895/Neo4j-The-Benefits-of-Graph-Databases
Here's the pdf in case you find scribd as annoying as I do!
 http://backspaces.net/temp/Neo4jTalk.pdf

   -- Owen

On Aug 25, 2009, at 6:29 PM, Owen Densmore wrote:

Hmm..just a thought: Have you considered "semantic networks"?  Marko Rodriguez:
 "Marko A. Rodriguez" <[hidden email]>
.. has drawn several of us into considering "triple stores" as an adjunct to our work, both in redfish and the santa fe complex.

The triple stores contain many triples of the nature of
 A verb B
.. where A & B are nouns: Marko Knows Steve.  Knows is a link between Marko and Steve.

The triple store is a graph database such as:
 http://neo4j.org/
RDF is the "semantic web" use of triple stores:
 http://en.wikipedia.org/wiki/Resource_Description_Framework
.. and neo4j has an RDF layer, I believe.

>From your description, I could see models where agents were nodes with links between themselves.  The dynamic nature you describe could be simply removing and adding links.

I think the graph database idea is on the brink of exploding upon the computing scene.  Its been around for quite a while, but folks are just starting to understand just how powerful a notion they are.  Definitely NOT sql structured .. but might work very well in a Big Table like Google's App Engine.

  -- Owen

============================================================
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

============================================================
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

[Marcus G. Daniels]

Russ Abbott wrote:
> But they give up SQL in the process. Now, I've always thought SQL was
> ugly. But at least its declarative.
I believe many of these graph database / triple store packages support
SPARQL..
 
     http://www.w3.org/TR/rdf-sparql-query/


============================================================
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

[Gary Schiltz-4]

Unfortunately, a glaring hole in SPARQL is lack of add or update  
capability. Jena (http://jena.sourceforge.net), the framework  
sponsored by HP Labs, includes an implementation of a proposed update  
language for SPARQL - see http://jena.sourceforge.net/ARQ/update.html.  
The other major framework for RDF is Sesame (http://openrdf.org), and  
they appear to emphasize their own propietary language (SeRQL) that is  
considerably more powerful, but only supported by Sesame. All the  
same, semantic web technology is worth keeping an eye on, even if it  
is still in its infancy.

;; Gary

On Aug 25, 2009, at 10:04 PM, Marcus G. Daniels wrote:
> Russ Abbott wrote:
>> But they give up SQL in the process. Now, I've always thought SQL  
>> was ugly. But at least its declarative.
> I believe many of these graph database / triple store packages  
> support SPARQL..
>    http://www.w3.org/TR/rdf-sparql-query/

============================================================
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

[Russ Abbott]

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the Drools Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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

[Douglas Roberts-2]

"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 <[hidden email]> wrote:

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the DroRuss.Abbott@..., The Friday Morning Applied Complexity Coffee Group <friam@...>ols Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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
[hidden email]
[hidden email]
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

[Russ Abbott]

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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the DroRuss.Abbott@..., The Friday Morning Applied Complexity Coffee Group <friam@...>ols Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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
[hidden email]
[hidden email]
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

[Russ Abbott]

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, 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the DroRuss.Abbott@..., The Friday Morning Applied Complexity Coffee Group <friam@...>ols Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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
[hidden email]
[hidden email]
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

[Douglas Roberts-2]

Hi, Russ.

As you might suspect from my previous comments, I have spent many years building models, most of them ABMs, many of them large distributed ones.  What I have found over the years is that each problem domain is significantly different from other domains, meaning there there is very little generic agent behavior or functionality that could realistically be captured and reused in an "ABM framework".

There is some, however, and in fact I have built my own very lightweight framework (in C++) that uses it.  I chose C++ because it is a language that is well-supported in HPC environments. 

In an abm, agents interact, and their interactions result in changes to the system to occur.  Some of the changes to the system occur instantaneously; some interactions will cause a change to occur in the future.  An example of the latter is when an agent causes disease to be be transmitted through interactions with other agents.  After a latent period some or all of the infected agents will become symptomatic.

My framework therefore has a mechanism to cause the simulation clock to advance as a result of agent interactions.

My distributed agent framework also has an interface that allows agents to migrate between cpus on a distributed machine, and to send messages between agents residing on different cpus.  It also has a mechanism to keep the distributed machine synchronized in time as part of the time update mechanism.

That's all the framework does.  All of the other logic that defines the agent interactions is written by the model developer. Since the framework is implemented in C++, agents are implemented as C++ objects.  As with any well-designed OO code, the objects contain their state information as object member data, and their logic definitions (rules) as object member methods. There is a very simple API that allows the agents to recognize the system clock and to cause it to be updated as interactions dictate.  That's where the framework functionality stops. 

There is no generic rule generation in the framework.  There is no rule rewriting.  The framework does not provide any generic genetic algorithms. There are no classes of agents.  No doctor agent classes. No stock arbitrage agent classes.  No hospital patient agent classes.  No car agent classes.  No house agent classes.  No airplane agent classes. These are all examples of application-specific agent functionality that may or may not be required to implement an abm for a specific problem definition.

This is my abm design methodology as it relates to implementation within my own abm framework:

• The model developer defines his agents at a level of resolution that is sufficient to capture the information required to address the problem that (this specific) abm is intended solve.
  
• The model developer identifies all state data that an agent will be required to maintain (for this specific abm).
  
• The model developer identifies all of the (specific for this application) rule logic definitions which will control the interactions of the agents with each other, and within (this specific) simulation state-space.
• The agents are implemented as C++ objects
  

I looked at the AMP platform that Miles mentioned, and it appears to me to be extremely constraining, and not well-suited to implementing large abms as it only appeared to support serial, non-distributed compute architectures.  I think I would feel like a slave to the AMP IDE were I to try to use it.  I would prefer more flexibility that it seems to provide.

Regards,

--Doug

On Mon, Aug 31, 2009 at 8:36 PM, Russ Abbott <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the DroRuss.Abbott@..., The Friday Morning Applied Complexity Coffee Group <friam@...>ols Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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
[hidden email]
[hidden email]
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

[Russ Abbott]

The system you describe reminds me of WarpIV by Jeff Steinman. I haven't kept up with this work in a few years, but it might be worth looking at. It's intended for very large simulations that run on diestributed processors. It includes a time warp capability so that processors aren't required to be synchronized at all time.

-- Russ

On Tue, Sep 1, 2009 at 5:13 AM, Douglas Roberts <[hidden email]> wrote:

Hi, Russ.

As you might suspect from my previous comments, I have spent many years building models, most of them ABMs, many of them large distributed ones.  What I have found over the years is that each problem domain is significantly different from other domains, meaning there there is very little generic agent behavior or functionality that could realistically be captured and reused in an "ABM framework".

There is some, however, and in fact I have built my own very lightweight framework (in C++) that uses it.  I chose C++ because it is a language that is well-supported in HPC environments. 

In an abm, agents interact, and their interactions result in changes to the system to occur.  Some of the changes to the system occur instantaneously; some interactions will cause a change to occur in the future.  An example of the latter is when an agent causes disease to be be transmitted through interactions with other agents.  After a latent period some or all of the infected agents will become symptomatic.

My framework therefore has a mechanism to cause the simulation clock to advance as a result of agent interactions.

My distributed agent framework also has an interface that allows agents to migrate between cpus on a distributed machine, and to send messages between agents residing on different cpus.  It also has a mechanism to keep the distributed machine synchronized in time as part of the time update mechanism.

That's all the framework does.  All of the other logic that defines the agent interactions is written by the model developer. Since the framework is implemented in C++, agents are implemented as C++ objects.  As with any well-designed OO code, the objects contain their state information as object member data, and their logic definitions (rules) as object member methods. There is a very simple API that allows the agents to recognize the system clock and to cause it to be updated as interactions dictate.  That's where the framework functionality stops. 

There is no generic rule generation in the framework.  There is no rule rewriting.  The framework does not provide any generic genetic algorithms. There are no classes of agents.  No doctor agent classes. No stock arbitrage agent classes.  No hospital patient agent classes.  No car agent classes.  No house agent classes.  No airplane agent classes. These are all examples of application-specific agent functionality that may or may not be required to implement an abm for a specific problem definition.

This is my abm design methodology as it relates to implementation within my own abm framework:

• The model developer defines his agents at a level of resolution that is sufficient to capture the information required to address the problem that (this specific) abm is intended solve.
  
• The model developer identifies all state data that an agent will be required to maintain (for this specific abm).
  
• The model developer identifies all of the (specific for this application) rule logic definitions which will control the interactions of the agents with each other, and within (this specific) simulation state-space.
• The agents are implemented as C++ objects
  

I looked at the AMP platform that Miles mentioned, and it appears to me to be extremely constraining, and not well-suited to implementing large abms as it only appeared to support serial, non-distributed compute architectures.  I think I would feel like a slave to the AMP IDE were I to try to use it.  I would prefer more flexibility that it seems to provide.

Regards,

--Doug

On Mon, Aug 31, 2009 at 8:36 PM, Russ Abbott <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the DroRuss.Abbott@..., The Friday Morning Applied Complexity Coffee Group <friam@...>ols Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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
[hidden email]
[hidden email]
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

[Douglas Roberts-2]

Posture?

Russ asked for my input; I gave it to him. 

And that's my posture on this issue.

;-}

On Tue, Sep 1, 2009 at 10:29 AM, Miles Parker <[hidden email]> wrote:

OK, I'm going to sign off this discussion now. Don't really care enough to posture like this.

On Sep 1, 2009, at 5:13 AM, Douglas Roberts wrote:

Hi, Russ.

As you might suspect from my previous comments, I have spent many years building models, most of them ABMs, many of them large distributed ones.  What I have found over the years is that each problem domain is significantly different from other domains, meaning there there is very little generic agent behavior or functionality that could realistically be captured and reused in an "ABM framework".

There is some, however, and in fact I have built my own very lightweight framework (in C++) that uses it.  I chose C++ because it is a language that is well-supported in HPC environments. 

In an abm, agents interact, and their interactions result in changes to the system to occur.  Some of the changes to the system occur instantaneously; some interactions will cause a change to occur in the future.  An example of the latter is when an agent causes disease to be be transmitted through interactions with other agents.  After a latent period some or all of the infected agents will become symptomatic.

My framework therefore has a mechanism to cause the simulation clock to advance as a result of agent interactions.

My distributed agent framework also has an interface that allows agents to migrate between cpus on a distributed machine, and to send messages between agents residing on different cpus.  It also has a mechanism to keep the distributed machine synchronized in time as part of the time update mechanism.

That's all the framework does.  All of the other logic that defines the agent interactions is written by the model developer. Since the framework is implemented in C++, agents are implemented as C++ objects.  As with any well-designed OO code, the objects contain their state information as object member data, and their logic definitions (rules) as object member methods. There is a very simple API that allows the agents to recognize the system clock and to cause it to be updated as interactions dictate.  That's where the framework functionality stops. 

There is no generic rule generation in the framework.  There is no rule rewriting.  The framework does not provide any generic genetic algorithms. There are no classes of agents.  No doctor agent classes. No stock arbitrage agent classes.  No hospital patient agent classes.  No car agent classes.  No house agent classes.  No airplane agent classes. These are all examples of application-specific agent functionality that may or may not be required to implement an abm for a specific problem definition.

This is my abm design methodology as it relates to implementation within my own abm framework:

• The model developer defines his agents at a level of resolution that is sufficient to capture the information required to address the problem that (this specific) abm is intended solve.
  
• The model developer identifies all state data that an agent will be required to maintain (for this specific abm).
  
• The model developer identifies all of the (specific for this application) rule logic definitions which will control the interactions of the agents with each other, and within (this specific) simulation state-space.
• The agents are implemented as C++ objects
  

I looked at the AMP platform that Miles mentioned, and it appears to me to be extremely constraining, and not well-suited to implementing large abms as it only appeared to support serial, non-distributed compute architectures.  I think I would feel like a slave to the AMP IDE were I to try to use it.  I would prefer more flexibility that it seems to provide.

Regards,

--Doug

On Mon, Aug 31, 2009 at 8:36 PM, Russ Abbott <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Hi Miles,

I got both of your messages.  Thanks.

Our situation is that we have embarked on building a framework based on the DroRuss.Abbott@..., The Friday Morning Applied Complexity Coffee Group <friam@...>ols Expert 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, 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 <[hidden email]> 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: [phone]
o Check out my blog at http://russabbott.blogspot.com/

On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[hidden email]> 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
--- -. .   ..-. .. ... ....   - .-- ---   ..-. .. ... ....
[hidden email]
(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
[hidden email]
[hidden email]
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

[Russell Standish]

On Tue, Sep 01, 2009 at 06:13:37AM -0600, Douglas Roberts wrote:

> Hi, Russ.
>
> As you might suspect from my previous comments, I have spent many years
> building models, most of them ABMs, many of them large distributed ones.
> What I have found over the years is that each problem domain is
> significantly different from other domains, meaning there there is very
> little generic agent behavior or functionality that could realistically be
> captured and reused in an "ABM framework".
>
> There is some, however, and in fact I have built my own very lightweight
> framework (in C++) that uses it.  I chose C++ because it is a language that
> is well-supported in HPC environments.
>

Doug, did you ever take a look at EcoLab? (http://ecolab.sf.net) It is
a C++ ABM framework that I've worked on that addresses similar issues
to yours. One of its key features is adding automatic reflection to
C++ making it extremely easy to migrate agents between processors. A
couple of years ago, I did a 13.5 million agent simulation running on
8 processors, which worked like a charm.

Anyway, given your experience, I'd be interested in your honest
opinion on it.


--

----------------------------------------------------------------------------
Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 [hidden email]
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------

============================================================
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

[Douglas Roberts-2]

Sorry, it's the first I've heard of it.  Looks interesting, though.

--Doug

On Tue, Sep 1, 2009 at 4:21 PM, russell standish <[hidden email]> wrote:

On Tue, Sep 01, 2009 at 06:13:37AM -0600, Douglas Roberts wrote:
> Hi, Russ.
>
> As you might suspect from my previous comments, I have spent many years
> building models, most of them ABMs, many of them large distributed ones.
> What I have found over the years is that each problem domain is
> significantly different from other domains, meaning there there is very
> little generic agent behavior or functionality that could realistically be
> captured and reused in an "ABM framework".
>
> There is some, however, and in fact I have built my own very lightweight
> framework (in C++) that uses it.  I chose C++ because it is a language that
> is well-supported in HPC environments.
>

Doug, did you ever take a look at EcoLab? (http://ecolab.sf.net) It is
a C++ ABM framework that I've worked on that addresses similar issues
to yours. One of its key features is adding automatic reflection to
C++ making it extremely easy to migrate agents between processors. A
couple of years ago, I did a 13.5 million agent simulation running on
8 processors, which worked like a charm.

Anyway, given your experience, I'd be interested in your honest
opinion on it.


--

----------------------------------------------------------------------------
Prof Russell Standish                  Phone [phone] (mobile)
Mathematics
UNSW SYDNEY 2052                         [hidden email]
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------

============================================================
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

============================================================
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