Actions Requirements

[cahidenes]

Actions are one of the key concepts of our project. Any ideas for different use cases or features of actions?

[cahidenes]

My idea is as follows: An action should relate resource(s) with need(s). Instead of types like "rescue action" or "food transportation" there should be 2 types of actions (these can be further extended):

• Physical Actions: These actions are the actions where the sources and needs should be physically together in order to fulfill the action. For example "Food" resource and "Truck" resource goes to some location where "Food" need is fulfilled.
• Non-physical actions: These actions are the actions where the sources and needs don't have to be physically together in order to fulfill the action. For example "Verifier" resource fulfills the "Verify" need.
• I didn't think of partly physical and partly non-physical actions. This can be a new type as well.

[mehmetkuzu]

We need a higher level of abstraction here.

At first thought:

Actions include

• Resources (put to action. Used in action. Spent in action.) An action may also be staged without using any resource
• Needs (this action is about that need.) An action may also be staged without providing to a need.

Human resources (which will part in the action), food (which will be delivered) etc are all resources.

So I think we do not need to seperate actions as physical-non physical.

[cahidenes]

The reason that I mentioned physical - non physical is because of visualization. We can visualize physical actions with flying arrows kind of things. But for non physical, it is not reasonable to visualize with arrows because these won't contain locations.

[mehmetkuzu]

I see.
Some examples will be useful. (Not urgent)

[cahidenes]

For example, some food resource is sent to a food-keeping stock. We can visualize this action with an arrow starting from the location where the food is sent, to the food-keeping stock.

[mehmetkuzu]

These are my first thoughts. I can elaborate on these.
We can have "action definitions" also. To define some standards. So that an action will be in type of that definition. (All are user defined)

• Rescue operation
• Food sent
• Food received
• Food sent and received ( simultaneously)
• Muhaberat
• Verification

I can give some examples but for further work I will be available in 5 days.

Examples
Action 1:
Resource: ResID 10900 (100 kgs of rice, 200 kgs of flour)
Resource: ResID 1900 (Truck with plate number 34 KTL 99 available on March 25 - March 28)
Need: NeedID 20900 (Need food in Samandağ. For about 100 people - we prefer quantities but in many cases the need info will be text like that)
This implies that resource which was ready was sent to Samandağ on the mentioned truck

Action 2:
Resource: ResID 10902 (1000 blankets)
Resource: ResID 1001 (Verifier named Behzat Çaralan)
Notes: Verified that these are useless by Behzat. So right to trash.

[mehmetkuzu]

I can add one thing:

Any resource used in an action might be used (finished) but might continue to live either (a truck is a truck anyway. After it is used in transportation action)

[mehmetkuzu]

A different perspective (after the meeting today)

1. We can define action templates (by design) like:
   • Splitting a resource -> After the action a resource in the system is divided into resources.
   • Packing resources -> After the action more than one resource is packed into one resource (Think about forming a rescue team, with rescue experts (human resource), a truck, 4 shovels etc.)
   • Etc.
2. Am I right when I say: Actions can be:
   • Planned
   • Done
   • Canceled

[cahidenes]

1. I think representing resource packing is not useful information for us to store. So according to me, there shouldn't be any predefined type like "Packing Resources" but "Splitting a Resource" is OK.
   But I think we should design actions such that it can represent various kinds of things even though they are not predefined (e.g. packing resources). For this purpose, I suggest an extension to the previous discussion: An action should contain these attributes:

• Resources that will be used (possibly zero or many)
• Resources that will be created (possibly zero or many)
• Needs that will be fulfilled (possibly zero or many)
• Needs that will be created (possibly zero or many)
• Events that will be deleted (possibly zero or many)
• Events that will be created (possibly zero or many)
  We can add some predefined types (e.g. Rescue Operation, Resource Transportation, Food Delivery, Verification... can be discussed) and fix the attributes (e.g. Food Delivery action will use one or more resources and fulfill one or more needs). For custom types, there will be many options. This is good for flexibility.

2. Makes sense to me.

[mehmetkuzu]

Actually resource packing is not an information. It is just an action template (not represented as data, but a user interface). Using this template a user creates (and maybe makes it done) an action which

• uses some resources (finish them)
• creates some resources (declares them)

Example after a packing action:

• Resources which are packed together become used. (and closed)
• New resource is created with the "things" in these used resources.
  Remember: Resources are actually lists. (Has at least one entry. But can be more than one)

[cahidenes]

Finalized in Meeting 7:
In addition to the current Actions Requirements, the actions will have the following attributes:

• Resources that will be used (possibly zero or many)
• Resources that will be created (possibly zero or many)
• Needs that will be fulfilled (possibly zero or many)
• Needs that will be created (possibly zero or many)
• Related Events (possibly zero or many)