Factor out event generator tools into a special skill

[ssardina]

Do we need

• getTeamMemberPercepts(..)
• getGameEntityPercepts(...)

in PerceptAggregator?

https://github.com/ssardina-agts/agtcity-sarl-mw/blob/7daebf4374d365f6b4ccdaacb2ac86c0aadeb52c/src/main/sarl/au/edu/rmit/agtgrp/agtcity/sarl/mw/aggregator/PerceptAggregator.sarl#L240

These two methods build sets of events. They are not about data, but about communication.

So, either we don't need them or we should move them to some part about communication?

[ayoung012]

I guess similar decisions need to be made about getStorageSensedPercepts() etc..

These only seem useful in cases where visibility is a factor, ie resourceNodes, enemy players, wells, etc. They are low priority in the case of JAS, as we deal with these exclusively in Prolog.

They would be more useful for a more SARL reliant solution, where these events would be utilised. This increases the amount of java code reliant on the city environment data structures. These should go in a new skill - Massm Data as discussed in issue #6

[ayoung012]

It might help to think about three layers of assistance the middleware could provide.

Layer #1: Raw percept data, as given to us by eis every single step. If the server sent it as XML that step, we pass that on in basic Percept form

Layer #2: Aggregated data, percept data processed into data structures, and updated with a new belief set every step, based on the percept data in Layer #1. I see this as being most descriptive of the aggregator

Layer #3: Aggregated data sent as specific city scenario oriented events emitted for SARL agents to react to. I see this being most useful for dynamic data, like resource nodes, wells positions, opponent positions...

This last layer seems like a lot of work, and is one of the reasons why we chose to just do it all in prolog for jas, the middleware already dumped everything we needed straight into the kb, no need for all this extra sarl event handling infrastructure specific to the city scenario :) The only big venture into SARL events and communications was the contract system, where cooperation was required. Having events emitted for percepts received just didn't make any sense, it's already in the knowledge base.

Hopefully this gives some clarity on my stance.

[ayoung012]

Maybe Sebastian R. would have more to say on what you would do with percepts emitted as event data to some agents other than just storing it as information. Maybe some sort of hierarchy of agents within each agent through which the information is delegated down to one who can process it effectively.. Much like his presentation last year on SARL spaces and hierarchical design.

[ssardina]

It might help to think about three layers of assistance the middleware could provide.

Layer #1: Raw percept data, as given to us by eis every single step. If the server sent it as XML that step, we pass that on in basic Percept form

Layer #2: Aggregated data, percept data processed into data structures, and updated with a new belief set every step, based on the percept data in Layer #1. I see this as being most descriptive of the aggregator

Layer #3: Aggregated data sent as specific city scenario oriented events emitted for SARL agents to react to. I see this being most useful for dynamic data, like resource nodes, wells positions, opponent positions...

This last layer seems like a lot of work, and is one of the reasons why we chose to just do it all in prolog for jas, the middleware already dumped everything we needed straight into the kb, no need for all this extra sarl event handling infrastructure specific to the city scenario :) The only big venture into SARL events and communications was the contract system, where cooperation was required. Having events emitted for percepts received just didn't make any sense, it's already in the knowledge base.

Hopefully this gives some clarity on my stance.

This is very good perspective, I have dumped this in the wiki to not forget and document it.

If I understand correctly, layer #1 is almost taken from EISMASSIM right? We don't do much. Well what we do is to provide an API to SARL agents to access Percepts. Correct?

Then we provide Layer #2, with data structures from protocol. And API to update and query those data structures.

Regarding level #3, I think it is interesting and needed in a MW to support building SARL controlers for this domain. Basically convenient ways to generate events related to knowledge. BUT as you said it is not a priority and we should not do it because we aim to do everything in Proog anwyays.

Now, we ave already some stuff to build events. We can move those to another skill within the MW that can be loaded or not, to build specific events. Agree?

[ssardina]

From #12, @ayoung012 pointed out to use the set of changed entities to generate events for data that has changed. This is cool.

[ssardina]

BTW, @joshuahansen may be interested to think whether it makes any sense to find changes in the KB in Prolog and for those changes generate an event in SARL from Prolog. This can be done because Prolog can also call Java (we have always restricted to Java calling Prolog, but JPL also provides the other way around). So, if Prolog detects a change, it can generate a Java event.

[ssardina]

This will be suspended, not a priority by far and not clear how to do it best.

It is useful to provide certain event types. But where does the generation wrt the current state should be and how?

[ssardina]

Seems this issue would be #27 now