How to model upper-level processes?
This is to discuss if and/or how we want to support process nesting. I'll do a PR when we have answered these few questions.
There are several requirements that have come up that might fit in here:
- Processes to handle activities that cover a lot of operational processes, often "overhead" processes, like monthly bookkeeping, cleaning the space, etc. If we support nested processes, we can support this kind of thing, still on an operational level. The nesting process can have its own inputs and outputs, and also include the lower-level processes. This was discussed earlier as part of thinking about projects that are not agents.
- Plan. This nests one or more series of processes that flow into one or more final deliverables (outputs) for the plan. It is the same as Work Order in NRP. This is useful to scope to processes that will be coordinated from one context, and are related in some way that makes sense to the users. Like a campaign to inform about a milestone or do fundraising.
- Function. This is from http://locecon.org. It is a higher level process used for analysis of a community, region, etc. to see what can be connected, what gaps can be filled, etc. to make a more resilient economic network.
- Activity. This is from discussion with @almereyda and @y0va around a budgeting app they are designing. This is very similar to Function, and will not be called Activity in any case, but I'm listing it separately because it is not exactly locecon Function. #284 (moved)
These are processes in that they transform or transport inputs into outputs. They might reference all or some of Intent, Commitment, EconomicEvent, depending on the use case. I expect we will come across other examples and needs.
Nesting: See the picture here https://github.com/valueflows/valueflows/issues/284#issuecomment-433746338. Basically, higher level processes are not not driven by a simple taxonomy, they contain processes in value flows. Their inputs and outputs are only the ones that are not created and then consumed within themselves.
Here are the options I can think of.
-
Processes can be in scope of any number of higher level processes, as well as agents, etc. The behavior (purpose, type, role, ?) is defined as an explicit property. Like "plan", "function", etc.
-
Same as 1. but use a more specific relationship for nested processes.
-
Same as 1. or 2. but use just a string for the behavior.
-
Explicitly define the higher level processes as classes, Plan, Function, etc. instead of having higher level processes. Although we still might want that for the first requirement above.
In summary: Here are the questions:
- Do we want to use nesting Processes for anything that basically follows the I-P-O definition we are using? Or do we want to define all of those cases explicitly as different classes?
- If we have higher level processes, how do we define what they are so people writing UIs for example can find all the plans or whatever? Create explicit list? Create user defined list? Let people just put in a string for their own purposes?
- If we have higher level processes, do we use inScopeOf, or something more specific like isNestedIn or similar?