Use Case: Apple Orchids Coop & Freelancing harvesters

[elf-pavlik]

capturing from PR #259 (comment)

In case of a Process where people harvest apples. Some people doing harvesting stay affiliated with Agent, a coop running that process, and participate in mentioned above 'income distribution' based on a set of 'value equations' that apply. At the same time in the same process some people doing harvesting work, don't stay affiliated and freelance / act as independent contractors. So their work (exactly the same harvesting work) dosn't happen under any umbrella coop affiliation agreement but happens under some specific agreement one per freelancing person. The 'Process Recipe' should not make any assumption about those agreements, it may just have n x 'Flow Recipe' - work (harvesting apples), once Process gets created and 'scaled' it will have 10 x 'Flow Intent' and later it will result in 10 x 'Flow Commitment' but each one can stay under a different agreement.

[elf-pavlik]

For use case above I would like to create one Process and multiple Agreements.

• from the Process Recipe we create a Process and from each Flow Recipe we create Flow Intent
• whenever some person affiliated with a coop picks up the task, a Flow Commitment gets created for a Flow Intent under the agreement person created when affiliating with the coop - let's say an income redistribution
• whenever someone freelancing wants to pick up the work, Conversation for Action happens based on lets say 3 available Agreement Recipes, person can just choose one of those 3, an Agreement gets created from that recipe with work Commitment under that Agreement for a Flow Intent in that planned process
• we can add another situation here, one of the freelancers found a way to have Conversation for Action not limited to those 3 Agreement Recipes and negotiated an Agreement not based on any of those recipes.

available Agreement Recipes:

• harvesting work for 10% of harvested apples (by that person) - kind of barter or more specific 'shared benefit'
• harvesting work 1h for faircoins 5FC
• harvesting work 3h for usage of one of the bungalows 1day - barter

For above we could relate Flow Recipe work to each Agreement Recipe as options to choose from

available extra Flow Intent (not Flow Recipe) which the last freelancing harvester matched to create an Agreement without any Agreement Recipe

• ownership of an old but still working bicycle - serial number 39824932834
• 10h of harvesting

[elf-pavlik]

Thinking about composing processes https://github.com/valueflows/valueflows/issues/264#issuecomment-355753653

We can also have version of this use case where they off-load part of the workload to another coop and that other coop provides a service which includes m x work (harvesting) and they have they own processes (group transportation etc.) in place to provide that service. So some of the work inputs don't get to harvesting process directly but indirectly via another process run by another agent.

To make it more interesting, that other process providing service may also off-load some of the use events and bundle them into that process.

I think agreement between coops would 'include' all those events from that service process. While agreements between other coop and people working with it may also need get referenced from same commitments and events. So we may need an event or commitment to reference many agreements as under.

[bhaugen]

@elf-pavlik just curious: I can see where such a configuration might be possible, but is it a real use case? If so, can we get some real data?

[elf-pavlik]

I don't base it on a use case I know, at the same time I see it as reasonable possibility that I would like VF handle as well.

[fosterlynn]

The 'Process Recipe' should not make any assumption about those agreements

👍

Experimental recipe data (don't worry about the names or the incompleteness, I'm just trying to see how the recipes might connect):

R1: process: harvest
     input: work 20 hours, resource classification: harvesting
     output: 50 bushels, resource classification: jonagold apples
R2: agreement: 
     xfer: work 1 hour, resource classification: harvesting
     reciprocal xfer: give 1/2 bushel, resource classification: jonagold apples
R3: agreement: 
     xfer: work 1 hour, resource classification: harvesting
     reciprocal xfer: give 20 $, resource classification: cash account
R4: agreement:
     xfer: work 1 hour, resource classification: harvesting
     reciprocal xfer: give 1 coop-credit, resource classification: coop-credit account

But then, should these recipes be connected in some way besides that the resource classifications connect them, just like everywhere else in the model? I tentatively think not.

[edit] I'm not totally comfortable with the quantities on the agreement xfers, but I can also see where they might be useful in some situations. The reasons I'm not comfortable are: 1) exchange recipes might need to be more generic 2) sometimes the quantities are way more complex, like quantity discounts, blablabla. I wonder if the quantities don't belong until the plan / observation layers?

[fosterlynn]

Oops, I made the above comment without seeing the intermediate comments, forgot to refresh.... sorry!

[elf-pavlik]

output: 50 bushels, resource classification: jonagold apples

I don't think we have resource classification unless we consider person's skill of harvesting as resource classified as harvesting. Anyways we still need to work quite a bit on how to model work.

Thinking about #259 we would have those input and output as vf:FlowRecipe / vf:RecipeFlow ?

R2: agreement: 
     xfer: work 1 hour, resource classification: harvesting
     reciprocal xfer: give 1/2 bushel, resource classification: jonagold apples

Just like in Process and Agreements - Intent, Commitment and Event reference Process with inputOf & outputOf and Agreement with under, we may want to take the same approach for FlowRecipe / RecipeFlow. It seems that we don't have any explicit reciprocal reference but infer it based on references to agents with provider & receiver / recipient. In agreement recipes we would probably just use some kind of variables rather than references to particular agents. http://rdf.js.org/#variable-interface When creating proposal from such recipe, agent will need to choose to which of the variables for agents it wants to bind oneself and which leave open for matches.

I think reusable Agreement Recipe would cover cases like: https://en.wikipedia.org/wiki/List_price (EDIT: captured in #266 )

[fosterlynn]

I don't think we have resource classification unless we consider person's skill of harvesting as resource classified as harvesting. Anyways we still need to work quite a bit on how to model work.

I know you have done some work on skills where it is a more complex structure, so we should look at that at some point. In the meantime, in our release skills and/or types of work are resource classifications, no?

Just like in Process and Agreements - Intent, Commitment and Event reference Process with inputOf & outputOf and Agreement with under, we may want to take the same approach for FlowRecipe / RecipeFlow.

Sure. I was just trying out the resource flow connections, and showing the structure conceptually.

It seems that we don't have any explicit reciprocal reference but infer it based on references to agents with provider & receiver / recipient.

I think in a recipe you need something to say what is reciprocal. I understand it is sometimes hard to see what is primary and what is reciprocal. And I'm totally good with finding some other way to name them. But I do know that Sensorica for example had purchases where there were 3 transfer types, so you couldn;t assume that one is reciprocal for the other, which you can do when there are 2.

[elf-pavlik]

But I do know that Sensorica for example had purchases where there were 3 transfer types, so you couldn;t assume that one is reciprocal for the other, which you can do when there are 2.

I didn't say anything about assuming but inferring it from provider & recipient references to a variables which in proposal get substituted with agents. Could you maybe share in #266 the use case with '3 transfer types' from Sensorica?

We probable get again to the Agreement Recipe vs. Agreement Template and it seems that in Recipe only variables (for agents) get referenced, while in Agreement Template some of the variables can already stay bound (substituted) and particular agent(s) get referenced.

[fosterlynn]

I didn't say anything about assuming but inferring it from provider & recipient references to a variables which in proposal get substituted with agents

I don't understand how this helps? Maybe I'm missing something....

[elf-pavlik]

Let's continue in #266 with your '3 transfers example' and hopefully we clarify it there by looking at observed agreement (exchange in your case) and how recipe for that agreement could look.

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/valueflows/-/issues/261.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.