Modeling exchanges using claims

[fosterlynn]

I'm starting a new issue for this, although I see several I could just add on to. So here are some references: #29 #22 #19 #17 #16 #9 as well as https://github.com/valueflows/valueflows/issues/165 which triggered some of the recent gitter chat and my renewed interest in getting concepts around "transfer" nailed down sooner than later.

I've thought for a while that the Transfers within an Exchange (a la NRP) is the wrong model because it doesn't support the real world many-to-many relationships between transfers in terms of the reciprocity. So I basically think we should ditch the Exchange class. But I think Exchange Template and whatever structure there is around that may continue to be useful.

Status: I've done a few use cases, but need to do a whole lot more. I have questions on the actual events to use in some cases. I want to review all related issues so far to make sure aspects are not forgotten, will do that soon. In other words, this is preliminary, but I thought worth getting out there in case people want to start commenting to steer it certain directions.

Here is the basic model (in ERD format, sorry about that):

Basically, certain events (IPOEvents and maybe transfer events) create claims, then other events respond to those claims, creating records of reciprocity. Events and claims are many-to-many.

Here are examples of how it might work. Note the arrows are more for direction of things happening, and are not UML relationship arrows. Also, I haven't used any transfer events.... yet. Still thinking about that. I am using the pseudo-transfer events vf:issue and vf:receive until I need more. Also, note these are pretty much in the perspective of one context.

Distributions based on contributions

(This is how NRP distributions work now.)

Timebanks

Note that a service event output could be used as easily as a work event input for this model. Note also that since we are using events, there is no need to create a vf:WorkResource or vf:ServiceResource to use in recording reciprocity. I know this doesn't help when a service resource goes into another process, but in this case it saves us from a construct with unclear relationship to reality.

Conventional business sales

Just to document it for standard exchanges, which always have been M:M in terms of partial payments and payments for >1 shipment.

[elf-pavlik]

I find this direction you explore interesting and I look forward to your further investigations!

Basically, certain events (IPOEvents and maybe transfer events) create claims, then other events respond to those claims, creating records of reciprocity.

I miss here agreements. Looking at first diagram, pretty much just 1 & 2

I understand that Claim 1. came as a result of prior agreement: "Donald agrees to do 3 hours of particular work in exchange for $60 from Bruce" and Claim 2. came as result of prior agreement: "Lucy agrees to give $40 to Bruce and he will give also $40 back to her".

Based on discussion with @bhaugen in #22 Claim only appears in exchange agreement once one side satisfy expectation put toward it. Before that agreement has some of Promises which represent those expectations. Maybe we could see how this flow will look in this Timebank use case? 1. Make exchange agreement 2. Work promise fulfillment creates a Claim for Timebank Hours 3. Delivery of Timebank Hours to agreed account fulfills that Claim and ends this exchange transaction.

Also while some of those events reference IPOEvents. It all seems to happen in dimention of agent <-> agent agreements and neither Claim or ClaimEvent appear as part of IPO but only augment IPO with references to relevant agent <-> agent agreements.

I'll also see how it works with #19 multi-party exchanges https://github.com/valueflows/valueflows/blob/master/use-cases/exchange-chain.md

It seems that agreements may include order in which parties agreed to fulfill their promises. And depending on #27 (agreement on delivery) sometimes issue event fulfills the promise(or claim) and sometimes receive event fulfills it (FOB origin | destination)

[fosterlynn]

I miss here agreements.

It would be good to get agreements into the model. To your point, there is no claim until the observation layer.

Looking at first diagram, pretty much just 1 & 2
I understand that Claim 1. came as a result of prior agreement: "Donald agrees to do 3 hours of particular work in exchange for $60 from Bruce" and Claim 2. came as result of prior agreement: "Lucy agrees to give $40 to Bruce and he will give also $40 back to her".

Actually, in Sensorica it is much less direct. In 1. Donald did 3 hours of work that contributed to some product that may (or may not) get sold. In 2. Lucy contributed $20 to the same product, maybe to buy a component.

That is not to say there aren't agreements. In this case, the agreement is that people who contributed to this product will share in income in specific ways, like work is valued at $20/hour and financial contributions will be paid back without interest. (The agreement in this case is captured in the value equation.)

Maybe we could see how this flow will look in this Timebank use case? 1. Make exchange agreement 2. Work promise fulfillment creates a Claim for Timebank Hours 3. Delivery of Timebank Hours to agreed account fulfills that Claim and ends this exchange transaction.

I think in the timebank, the main agreement is how the timebank group functions - that all hours will be treated equally and people will have individual timebank-hour accounts. Maybe that there are limits to how far a person can go in the hole, etc.

Then yes, there is an agreement between Paul and Mary that Paul will do plumbing work for Mary using the timebank rules. And your 1., .2,, 3. are correct. So in this case, the specific agreement is somewhere in the plan layer, and afaik is not recorded in the timebank software. But it would be a commitment to do the work and to reciprocate for the work in timebank-hours, or something like that.

[fosterlynn]

Also while some of those events reference IPOEvents. It all seems to happen in dimention of agent <-> agent agreements and neither Claim or ClaimEvent appear as part of IPO but only augment IPO with references to relevant agent <-> agent agreements.

I think that is right. This just connects different IPO chains together because an exchange or reciprocity came into play somewhere in the separate flows.

It seems that agreements may include order in which parties agreed to fulfill their promises.

Yes, like sometimes people are required to put half down, or whatever. Sometimes very complicated stuff, like how to repay a mortgage.

[fosterlynn]

Well, I may have been premature in ditching Exchange. From @elf-pavlik comments, it was clear we need to not ignore the other layers, although not all agreements are explicit on those layers.

Here is another very early attempt to think about it. Won't know how much of this is right until I do some detailing out - I'm suspicious I may have fudged a bit - maybe some YAML is in the cards.

[fosterlynn]

A brief picture of apartment rental, this one needs some yaml. This could also be done some different ways (all valid), but this seems like one way.

[elf-pavlik]

What do you think about

Agreement (based on Plan)

Monthly 'exchange template' - repeat until agreement end date

1. Commitment - Bob use the flat for duration of the whole month (continuous)
2. Commitment - Alice receive $500 on bank account nr 21942892

Observation

1. Event - Bob use the flat .... fulfills Commitment 1 and turns Commitment 2 into a (Claim define Claim #22)
2. Event - Alice receive $500 ... fulfills Commitment 2

Since Event -> Commitment already works M:M I don't know why we need ClaimEvent besides that. Especially that outside of the 'exchange' based transactions we may not even have case that Commitment becomes a Claim.

[fosterlynn]

Since Event -> Commitment already works M:M

How does it do that? Certainly more than one event could fulfil a commitment..... do you see it working the other way too?

Especially that outside of the 'exchange' based transactions we may not even have case that Commitment becomes a Claim.

I think that "commitment becomes a claim" can be true, but is somewhat misleading. The specific trigger for something to become a claim is an event. That event could have a commitment or not. And if it has a commitment, it could be different than the commitment. @bhaugen please disagree if you see the need, I think you made that statement originally...

Especially that outside of the 'exchange' based transactions we may not even have case that Commitment becomes a Claim.

Yes, I'm basically working on things that are exchanged, or at least where there is some reciprocity going on, may be more complex than an exchange.

[fosterlynn]

I would like to propose we change the name of "Claim" to something less legalistic sounding.

Suggest "Reciprocity"?

[bhaugen]

All of these event relationships are working off what Bill McCarthy calls Duality, which can be oversimplified into "why did you do that" economic event?

I know @elf-pavlik does not care about the legality of contracts, but they are derived from common law, which is some kind of summary of human economic experience. I wouldn't take it as gospel, but that's where the word "claim" comes from. And I don't care about the word, am fine with some other word.

I had a long lesson in legal contracts from a standards lawyer back when I was working on ebXML, a B2B ecommerce standard, and then the ISO Economic Ontology, around 2000. He said the courts take a lenient view of whether a contract exists or not. Does not need to be written down, can be verbal, can be as simple as a posted price for an item. But one of the essential features of a contract is called "consideration", which means somebody gave somebody something of value to the recipient, and in a contract, each party is supposed to give some consideration to their counterparty. So if one party gives something to the other party (an economic event has occurred), the giver might very well expect something in return, based on some understanding, whether written, verbal, or customary. That expectation could be called a claim, or reciprocity, or consideration, or compensation (which is what Good Relations uses).

For @gcassel these are all about agreements.

So anyway, to cut closer to the chase, an expectation of reciprocity may arise from the performance of an economic event, with or without formal agreements (commitments), although the situation will be a lot more clear if the prior commitments exist. They could exist formally on a policy level without being explicitly defined for every exchange, though. Like, whenever somebody gives you a ride in their vehicle, you are expected to help pay for gas. [edit] Or give them a ride some other time, like in carpooling.

It is also true, as @fosterlynn wrote above, that an event may be different from a commitment: might be less in quantity, as in partial fulfillment, might be greater in quantity, as in payment for more than one receipt, might be different in type, as in a substitute product. Payment for more than one receipt or more than one payment for one receipt is where the M:M cardinality arises. So structurally, some kind of associative entity, whatever you call it, is required to connect events in duality relationships.

I hope that all made sense and was not terminally boring.

[elf-pavlik]

They could exist formally on a policy level without being explicitly defined for every exchange, though. Like, whenever somebody gives you a ride in their vehicle, you are expected to help pay for gas. [edit] Or give them a ride some other time, like in carpooling.

Or simply say thank you in appreciation to driver's kindness knowing that very likely you will never meet that person again and can't return the favor but only "pay it forward", like in hitchhiking. [edit] I used to hitchhike a lot, and quite often drivers were referencing kindness of other drivers when they were hitchhiking 20 or 30 years earlier - "pay it forward" in action.

So structurally, some kind of associative entity, whatever you call it, is required to connect events in duality relationships.

When some kind of 'exchange agreement' exists, possibly relevant events can reference that agreement or event directly precise commitments if the agreement includes such commitments. BTW I understand better @fosterlynn reasoning that sometimes claim can arise based on agreement and events without need for specific commitment beforehand.

How about trying to write YAML for examples above? I also would like to add variants for barter based exchanges, including usage for usage, work for work, product for product.

When it comes to reciprocity, we will have cases which don't involve any prior agreement so also don't have any claims. For example, I can fix a software bug in OFN codebase, just because I wanted to help (no prior agreements). Some time later in a future, apple juice producer may feel grateful for that bug fix and express one's gratitude through a gift of 10L apple juice directly to me. We have a case of reciprocity (with no prior agreement or claim) where that gifting of product may want to reference the work (or service) which I donated to OFN project.

[bhaugen]

@elf-pavlik I agree with all of that. I also agree with another idea that I think you posted somewhere in VF about reciprocity chains or cycles. Our first economic network software experiment was for a timber network in Wisconsin, and for that one, we summarized all of the economic events from time to time and figured out who owned whom how much for what. Not exactly as flexible an idea as what you expressed, but along the same lines. @fosterlynn and I discussed reciprocity cycles after I wrote my comment above, and figured if you wanted to formalize anything about them, it would need to be like that: materialize graphs of events after the fact and see if and when and where they balance or don't balance.

[fosterlynn]

. @fosterlynn and I discussed reciprocity cycles after I wrote my comment above, and figured if you wanted to formalize anything about them, it would need to be like that: materialize graphs of events after the fact and see if and when and where they balance or don't balance.

One thing to be worked out in that scenario is to try to get things into some at least roughly same unit of measure. Otherwise it will be lists, not summarized data.

[bhaugen]

One thing to be worked out in that scenario is to try to get things into some at least roughly same unit of measure.

Here is one idea of how to do so. I'm not saying it is the correct idea, just an example:
https://netplanetaryvalue.wordpress.com/

Timebanks value everything in hours of work, so if you followed that idea, you would need to convert e.g. some carrots into equivalent hours of work. This is also the Labor Theory of Value, which uses the concept of socially necessary labor time, to avoid the situation where it takes me forever to do something that somebody else could do in an hour.

[elf-pavlik]

Timebanks value everything in hours of work, so if you followed that idea, you would need to convert e.g. some carrots into equivalent hours of work.

I would like to not make any assumptions when logging data of how different agents may want to use it to develop their perception of 'valuing'. This way, different agents running analysis on the same dataset can use different models to do their evaluations and focus on different metrics. Some will put emphasis on how human labor adds up in process of transforming natural resources into consumable goods. Others will do calculations around different forms of energy consumed in the IPO chains. Others will also include various reputation metrics and include their ethical worldviews in those evaluations. In short, everyone can have different preferences in evaluating economic data, but no one should expect everyone else to have the same preference.

[bhaugen]

I would like to not make any assumptions when logging data of how different agents may want to use it to develop their perception of 'valuing'.

I think we have all agreed on this principle from the beginning. Does anybody disagree? Or, has anybody here disagreed?

For example, @fosterlynn and I came into VF having the experience of value equations, which are defined by a project to value peoples' contributions. And the same project can have many value equations, each of which can value the contributions differently. So, while we are not assuming any other groups will want to use value equations as Sensorica does, we do assume the probability of many different valuations for the same sets of events from different perspectives.

[gcassel]

I don't have time to read or respond thoroughly right now, but I like the general flow of discussion here. I really like the term "claim" as an indication of an agent's official description of an action or event. By "official" here, I mean official in the context of a specific group agent or context agent. I use the term "claim" as an auxiliary to the term "report" in Agreement-Based Organization, section 1.7.11, although that needs work.

Claims can be informally endorsed or "seconded", and of course they can be integrated into mutually signed agreements.

[fosterlynn]

@gcassel thanks. However, I think your definition of claim here is different that the one I started with (and suggest changing) here. An official description of an action or event - like claiming something happened. Vs I was using it as a claim for economic reciprocity from some other agent based on an economic event from me. If I ship something to you (which you ordered), I have a claim for a payment from you (to use a common kind of exchange in capitalism).

Possibly another reason to find a different term. :)

[gcassel]

Good point @fosterlynn , and if others here think that it's important or valuable to use "claim" in that way, it's certainly okay with me. I can't think of any obvious replacement terms right now.

You're talking about situations where an agent formally requests (or demands?) that another agent fulfill responsibilities or (usually) commitments, right?

I think we're talking about "reciprocal understandings", which I usually call "mutual understandings". I think that the term "reciprocity", by itself, is potentially misleading here. I'm not directly interested in assuming, or expecting, that agents engage in mutually beneficial or 'fair' exchanges, as long as they mutually consent to transfers. For instance, significant expected donations or gifts may result in formal commitments and formal agreements at times. In such cases, the expected recipient might (nicely) file a "claim" at some point.

^ Explanatory/ emphatic p.s.: expected donations, gifts, or otherwise imbalanced interactions can often figure prominently into important planning decisions.

[fosterlynn]

I also would like to add variants for barter based exchanges, including usage for usage, work for work, product for product.

Here is a simple attempt. The tricky part is agreeing how to make it equivalent.

[fosterlynn]

Thought I better start doing some YAML on this idea, to discover the devils. 😊 Since I was already in the middle of this, I'll borrow it and complete for claim stuff. I made the transfers into issue-receive processes to not get this issue confused with that one. (Although they are connected, I'd like to work over here to see if this direction will make sense, without tainting it with the transfer discussions.)

Basically, Daniel is exchanging part of his shares in the 3d printer with Ahmed for money. Ahmed is only paying $150 for $200 worth of shares because Daniel needs cash now, and it may be awhile (if ever) that the printer shares completely are repaid from usage fees.

before

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Daniel
'@type': 'vf:ShareResource'
'skos:note': Daniel ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 1000
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Ahmed
'@type': 'vf:ShareResource'
'skos:note': Ahmed ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 300
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/virtual-account-Daniel
'@type': 'vf:Resource'
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 25
'vf:underlyingResource': https://sens.example/main-bank-account

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/virtual-account-Ahmed
'@type': 'vf:Resource'
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 500
'vf:underlyingResource': https://sens.example/main-bank-account

first process

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/7d756cb1-1391-454e-aef5-9682dd64311f
'@type': 'vf:Process'
'vf:io':
  - 'vf:action': vf:issue
    '@id': https://sens.example/ey7qyruui-issue-shares-event
    'vf-x:resource': https://sens.example/FDM-printer-shares-4574564#Daniel
    'vf-x:agent': https://daniel.example/
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:CAD
      'qudt:numericValue': 200
  - 'vf:action': vf:receive
    '@id': https://sens.example/ey7qyruui-receive-shares-event
    'vf-x:resource': https://sens.example/FDM-printer-shares-hjk43j3#Ahmed
    'vf-x:agent': https://ahmed.example/
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:CAD
      'qudt:numericValue': 200

as a result of this process

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/46787678#reciprocity
'@type': 'vf-x:Claim' 
'vf-x:remainingQuantity':
   '@type': qudt:QuantityValue
   'qudt:unit': unit:CAD
   'qudt:numericValue': 150
'vf-x:claimedQuantity':
   '@type': qudt:QuantityValue
   'qudt:unit': unit:CAD
   'qudt:numericValue': 150
'vf-x:agreement': https://sens.example/454323#commitment
'vf-x:claimingAgent': https://daniel.example/
'vf-x:againstAgent': https://ahmed.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/46787678#reciprocity-event
'@type': 'vf-x:ClaimEvent' 
'vf-x:affectedQuantity':
   '@type': qudt:QuantityValue
   'qudt:unit': unit:CAD
   'qudt:numericValue': 150
'vf-x:event': https://sens.example/ey7qyruui-receive-shares-event
'vf-x:claim': https://sens.example/46787678#reciprocity
'vf-x:effect': vf-x:increment

reciprocal process

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/7d756cb1-Ahmed-to-Daniel-pmt
'@type': 'vf:Process'
'skos:note': Ahmed paid $150 to Daniel for $200 share in 3d printer
'vf:io':
  - 'vf:action': vf:issue
    '@id': https://sens.example/ey7qy777i-issue-cad-event
    'vf-x:resource': https://sens.example/Ahmed-virtual-account
    'vf-x:agent': https://ahmed.example/
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:CAD
      'qudt:numericValue': 150
  - 'vf:action': vf:receive
    '@id': https://sens.example/ey7qy777i-receive-cad-event
    'vf-x:resource': https://sens.example/Daniel-virtual-account
    'vf-x:agent': https://daniel.example/
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:CAD
      'qudt:numericValue': 150

after both processes

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/46787678#reciprocity
'@type': 'vf-x:Claim' 
'vf-x:remainingQuantity':
   '@type': qudt:QuantityValue
   'qudt:unit': unit:CAD
   'qudt:numericValue': 0
'vf-x:claimedQuantity':
   '@type': qudt:QuantityValue
   'qudt:unit': unit:CAD
   'qudt:numericValue': 150
'vf-x:agreement': https://sens.example/454323#commitment
'vf-x:claimingAgent': https://daniel.example/
'vf-x:againstAgent': https://ahmed.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/46787678#reciprocity-event
'@type': 'vf-x:ClaimEvent' 
'vf-x:affectedQuantity':
   '@type': qudt:QuantityValue
   'qudt:unit': unit:CAD
   'qudt:numericValue': 150
'vf-x:event': https://sens.example/ey7qy777i-receive-cad-event
'vf-x:claim': https://sens.example/46787678#reciprocity
'vf-x:effect': vf-x:decrement

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Daniel
'@type': 'vf:ShareResource'
'skos:note': Daniel ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 800
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Ahmed
'@type': 'vf:ShareResource'
'skos:note': Ahmed ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 500
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/virtual-account-Daniel
'@type': 'vf:Resource'
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 175
'vf:underlyingResource': https://sens.example/main-bank-account

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/virtual-account-Ahmed
'@type': 'vf:Resource'
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 350
'vf:underlyingResource': https://sens.example/main-bank-account

[elf-pavlik]

I find it confusing that everything has unit:CAD, for shares of 3d printer i would expect that they use some unit that add up to 100%

Ahmed is only paying $150 for $200 worth of shares

I wouldn't say '$200 worth of shares', Ahmed agreed to exchange some % of 3d printer shares for $200, someone else could agree to exchange the same % for $500 and yet someone else the same % for a 20kg of peanuts and another person same 20% for 100% shares of a particular bicycle. I doesn't mean that this % of shares 'is worrth' any of those three quantities of some other resource.

[fosterlynn]

Yes that is confusing. Although I think it could be true. That's why I used different numbers to highlight the issue. But perhaps a bad example, and maybe better to say 200 shares, and have agreement that 1 share = 1 CAD. I don't think % would work for them very well because they get paid back gradually and it would involve a bunch of unnecessary calculations.

This use case is true, but they don't handle it with shares of any kind (NRP software doesn't support underlying resource). The value flow created by the $ contributions and the purchase of the printer enables NRP to distribute fees to the contributors when people use the printer. But it doesn't give the contributors a way to transfer their contributions/shares to someone else. VF will be better.

[elf-pavlik]

Here is a simple attempt. The tricky part is agreeing how to make it equivalent.

I don't see need here to consider any kind of equivalency, both events just need to fulfill the agreement.

[bhaugen]

I don't see need here to consider any kind of equivalency, both events just need to fulfill the agreement.

Equivalency is this historical problem with human economic relationships that gave rise to currencies as universal equivalents. So it's all fine for the individuals involved if you stick to explicitly defining equivalent use values in every exchange, but that gets tedious, and runs into problems in any larger context than those two agents.

[fosterlynn]

I don't see need here to consider any kind of equivalency, both events just need to fulfill the agreement

By the way, I don't see this claim structure (or whatever we come up with to document how exchanges are realized) as required. If 2 agents plan and make a trade and everyone is happy, good enough.

But if you do want to keep track of all of that, the claim needs to go to zero, or it is still a claim.

[stevebosserman]

Much earlier (due to my slowness!), @bhaugen stated:

Timebanks value everything in hours of work, so if you followed that idea, you would need to convert e.g. some carrots into equivalent hours of work. This is also the Labor Theory of Value, which uses the concept of socially necessary labor time, to avoid the situation where it takes me forever to do something that somebody else could do in an hour.

With the increasing availability of affordable, labor-saving technologies that help people meet their basic needs coupled with an increasing recognition that the cost to cover people's basic needs is less than the cost to counteract the destruction of environment, infrastructure, and civilization caused when people do not have access to the means necessary to meet their basic needs, the concept of how one spends one's time changes. Tasks that precipitated a battle either against drudgery or for equivalency according to the Labor Theory of Value can now be done by the machine. Furthermore, people with their basic needs covered can now spend most of their time doing what they want (elimination of drudgery) regardless of competitive advantage in terms of skill and efficiency (equivalency). As timebanking evolves in response to this greater freedom of choice, members will make more offers in companionship, advocacy, distribution, handiness, and services that tend to expand and strengthen trusted relationships among them and build a more caring and nurturing and ultimately sustainable community overall because it increases their wellbeing. While I suppose this constitutes "work" and generates "value" in a traditional sense, I would argue that there is a happiness or contentment value which bears acknowledgement in these formulae, not only for simple exchanges, but as repositories of much-needed data to support policy changes as evidenced in this Naked Capitalism article posted today. In other words, perhaps our efforts here could be counted as "well-controlled trials...) as stated in the closing paragraph in the article. Thoughts?

Happiness and Policy Analysis

At last the map of happiness is becoming clearer and usable for policy analysis. We now need thousands of well-controlled trials of specific policies from which we can obtain estimates of the effects on life satisfaction in the near and longer term (where our book can contribute valuable coefficients). We can then compare those gains to the net cost of the policies. The optimal mix will surely be very different from the one we have now.

[bhaugen]

@stevebosserman thanks a lot for that course correction. I hope I was not advocating efficiency. I agree that we will have many other preferences when we get good at being human than efficiency.

[elf-pavlik]

👍 @stevebosserman thank you for this reality check ☮️

@fosterlynn: But if you do want to keep track of all of that, the claim needs to go to zero, or it is still a claim.

I would say - the commitment needs to get fulfilled (and if we have pair of reciprocal commitments with one already fulfilled we can consider the remaining commitment as claim #22). At the same time we can't expect that each commitment we can base on some quantitative value and keep decrementing it by events also with some quantitative value (including %) till they reach 0. Sometimes we can have more of a qualitative (not quantitative) commitments, possibly case of many kinds of services, which to filfill require assessment which doesn't boil down to just using algebra.

[bhaugen]

Sometimes we can have more of a qualitative (not quantitative) commitments, possibly case of many kinds of services, which to filfill require assessment which doesn't boil down to just using algebra.

Agreed. That's part of the Conversation for Action protocol: is everybody satisfied at the end? For whatever reason.

[elf-pavlik]

Based on above diagram illustrating exchange (barter) between a farm and factory. Example snippets for two (out of four) Commitments and first two events starting to fulfill them:

'@id': https://factory.example/9bbac402-3a67-42c0-8a53-b163f81e4821#agreement
'@type': vf-x:Agreement
'vf-x:includesCommitment':
  - https://factory.example/ad435016-3927-4389-bbee-de978fce3ef9#commitment
  - #TODO somethings
  - https://farm.example/c6c881bb-3a0e-4279-ad74-0d76f2f187d9#commitment
  - #TODO carrots
# signatures

'@id': https://farm.example/616ee231-9150-417c-8f49-14d9ddfec61a#agreement
'@type': vf-x:Agreement
'vf-x:includesCommitment':
  - https://factory.example/ad435016-3927-4389-bbee-de978fce3ef9#commitment
  - #TODO somethings
  - https://farm.example/c6c881bb-3a0e-4279-ad74-0d76f2f187d9#commitment
  - #TODO carrots
# signatures

'@id': https://factory.example/ad435016-3927-4389-bbee-de978fce3ef9#commitment
'@type': vf:Commitment
'vf:action': vf:issue
'vf-x:affectedShouldMatch':
  '@type': vf-x:ResourceTemplate
  'vf:model': https://factory.example/widgets#model
'vf-x:promissedBy': https://factory.example/
'vf:affectedQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 5

'@id': https://farm.example/c6c881bb-3a0e-4279-ad74-0d76f2f187d9#commitment
'@type': vf:Commitment
'vf:action': vf:issue
'vf-x:affectedShouldMatch':
  '@type': vf-x:ResourceTemplate
  'vf:category': prodont:Potato
'vf-x:promissedBy': https://farm.example/
'vf:affectedQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Kilogram
  'qudt:numericValue': 5

'@id': https://factory.example/08280dda-9cca-4781-9116-f6d83b4ac910#event
'@type': vf:IPOEvent
'vf:action': vf:issue
'vf-x:affects': https://factory.example/6ed619d1-11ac-47e7-9494-2a68923246e2#resource
'vf-x:executedBy': https://factory.example/
'vf-x:fulfills': https://factory.example/ad435016-3927-4389-bbee-de978fce3ef9#commitment
'vf:affectedQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 3

'@id': https://farm.example/433c6882-4d42-47a2-ba42-8a666f50031f#event
'@type': vf:IPOEvent
'vf:action': vf:issue
'vf-x:affects': https://farm.example/ff744546-5ea0-4502-9f75-21d0c4322cd7#resource
'vf-x:executedBy': https://farm.example/
'vf-x:fulfills': https://farm.example/c6c881bb-3a0e-4279-ad74-0d76f2f187d9#commitment
'vf:affectedQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Kilogram
  'qudt:numericValue': 10

[fosterlynn]

Re. fulfilling commitments - we could add a status that is "fulfilled" "unfulfilled" or similar, to take care of the more qualitative cases.

[bhaugen]

Seems likely to me that commitments need their own internal set of states or possibly state machine.

[bhaugen]

P.S. commitments need their own states, plus they need to be related to intents and conversations for action. There is a whole evolution of intents that goes through CfA to commitments and economic events that needs to be fleshed out. I see bits and pieces in a lot of the current examples and yaml. So far, seems to focus on the data, but maybe misses some of the protocol.

[elf-pavlik]

We discussed with @fosterlynn that sometimes new Commitment(s) can supersede some prior Commitment(s).

So far, seems to focus on the data, but maybe misses some of the protocol.

We should start thinking more about the interaction flow and how data emerges from it, which apps creates which records, which records gets published in which namespace, which records get signed and possibly a copy gets republished, which records require approval (eg. signature) from which agent etc.

[fosterlynn]

Seems likely to me that commitments need their own internal set of states or possibly state machine.

There has been some discussion with @elf-pavlik that the state of a plan before someone has actually committed to a task is still an "intent" (rather than say a "plan"). Then when someone commits to the task, it is a commitment. Anyway, there is still analysis to be done here; agree it is worth looking at a state machine.

We discussed with @fosterlynn that sometimes new Commitment(s) can supersede some prior Commitment(s).

I'm not sold on this - yet. :) I think that changes to expectations on reciprocity based on events should probably be something else. But we're still kicking it around.

We should start thinking more about the interaction flow and how data emerges from it, which apps creates which records, which records gets published in which namespace, which records get signed and possibly a copy gets republished, which records require approval (eg. signature) from which agent etc.

👍

[fosterlynn]

[deleted my post] missed yesterday's posts, one of them mine.... mind is going too....

[bhaugen]

Lynn and I kept discussing this topic, and I wonder if we should rename Commitment.

Bill McCarthy's original definition of commitments in REA was Event Image, as the image of an economic event that had not yet happened. But the name also suggests that people have committed to it, which is not always the case, and seldom the case when a plan is just proposed.

Anyway, a lot of related concepts float in this evolution from the idea to the execution. Might be a state machine, might be a transformation from stage to stage, might be a protocol, might be a combination of all the above.

[fosterlynn]

But the name also suggests that people have committed to it, which is not always the case, and seldom the case when a plan is just proposed.

Yeah, this is where @elf-pavlik suggested, and I agreed, that it could still be an intent before someone has actually committed to it. This is our current working proposition, but lots of nuances there...

[stevebosserman]

Recent posting in Aeon, In Proof We Trust about blockchain technology that may be germane to this discussion. Here's a telling quote:

This is possibly the most significant and detailed record in all history, an open-source structure of permanent memory, which grows organically. It is known as the blockchain. It is the breakthrough tech behind the digital cash system, Bitcoin, but its impact will soon be far wider than just alternative money.

Perhaps future blockchain technologies can account for the value flows of various capitals as they are applied to convert commitment and intent into documented actions that yield measurable outcomes...

[bhaugen]

Blockchains were a brilliant invention, the first practical implementation of global consensus (in the computer consensus sense).

The difficulties with blockchains and value flows are that:

• value flows are networks, not chains; and
• blockchains are centralizing mechanisms, even though they claim to be decentralized. By that I mean, while a blockchain typically has many distributed copies, they are, and must be, exactly the same. So a blockchain is a global singleton.

I am not a decentralization purist at all. Our NRP software is monolithic and centralized, although it could be federated using value flows, by different networks connecting with each other.

But we are seeing the weight of dependency in our work with Fair Coins and a fork of NRP. It is now dependent on a blockchain. We can't even test locally without connecting to the blockchain.

I should add, that I could be wrong about all of those opinions, and here are some places you could look to find out if I am wrong or not:

• Jim Anastassiou of Sensorica, Jake Knoppers of ISO, and Bill McCarthy of REA are planning a blockchain REA implementation that might make me eat all of those words, but we'll see.
• The Provenance project has apparently implemented provenance networks on blockchains. I should look at their code some time...

But lots of devils in details...

[stevebosserman]

I don't know enough about blockchain technology to have an informed opinion so I apologize in advance for asking you all to educate me, but...

@bhaugen stated:

The difficulties with blockchains and value flows are that:
value flows are networks, not chains;

Couldn't one argue that flow of value in a value flow "network" is an account of commitments / intents and the claims generated by them which are filled completely, in part, or not at all? And isn't a fulfilled claim a transfer of resources (or capital of some sort) from one "owner" to another? As such, can't a blockchain application account for (verify / confirm) that such a transfer occurred and who / what is the new "owner" of that capital? And wouldn't that approach establish a "computer consensus" (I'm referring to terminology @bhaugen used in his excellent post to the the SENSORICA Google Group which I would encourage to be cross-posted on GitHub, if not done already and I just don't know where to find it) which leads to human consensus and thereby builds trust through transparency?

@bhaugen went on to state:

blockchains are centralizing mechanisms, even though they claim to be decentralized. By that I mean, while a blockchain typically has many distributed copies, they are, and must be, exactly the same. So a blockchain is a global singleton.

And here's where I really betray my ignorance, but can't a blockchain platform, if you will, be setup to document resource transactions / exchanges among members of a given community who participate in localized value flows? In other words, can such a blockchain serve to act as a "community currency" chartered by members of a cooperative or collaborative (democratic?) structure (maybe a variation on a public bank) that takes responsibility for community assets held in common?

[bhaugen]

post to the the SENSORICA Google Group which I would encourage to be cross-posted on GitHub

The one where Jim Anastassiou and I swap roles, and I defend blockchains? Here 'tis:
https://groups.google.com/d/msg/Sensorica/YPs9CEko5_0/gQD-PrXnDQAJ

but can't a blockchain platform, if you will, be setup to document resource transactions / exchanges among members of a given community who participate in localized value flows?

Yes. Good use of a community blockchain. But the community will then be dependent on that blockchain. We had an instance in the Freedom Coop project where the system we were using got banned by the blockchain system because of a bug in our system. Well-deserved ban, but it should give you a sense of what such a dependency means.

The same is true of a timebank system that the community depends on. It's not that dependencies are all bad, but they do give the lie to the decentralization claims of blockchain enthusiasts.

[stevebosserman]

In my opinion, technology is changing faster, e.g., distributing more information into the long tail, than our largely centralized "trust structures" can adapt. Just like we're experiencing now in the aftermath of our presidential election, we don't know which information sources to trust which lowers our confidence in our governance structures - particularly at international and national levels and especially when it comes to information about ownership and control of resources. The emergence of new trust structures will begin at the community level and extend from there.

A long-winded setup to say that the primary role of blockchain, which began its initial cycle a mere 8-years ago, could be to support the development of community-based trust structures that quickly morph into an infrastructure for more expansive, integrated governance structures at national / international levels. In other words, as blockchain (or its successor) rapidly evolves (as it inevitably will) into the truly decentralized platform you envision over its next 8-year development cycle, this development will be synchronized with / supportive of globally expanding trust structures. As a result, the community dependency is short-lived. More importantly, the critical learning that comes from communities experimenting with various trust structures and cross-fertilizing their experiences make the risk of adverse effects of residual dependency worth it. Again, in my opinion!

[fosterlynn]

@elf-pavlik and I have been working on a model to support exchanges and other reciprocity. Still a work in progress, but I think we are getting to something. And I hope he does too!

We have looked at standard exchanges (sales, barter, etc.), gift economy, contributory economy, timebank.

Here is a UML of where I see it at right now. UML diagrams are notoriously static, so see notes below. (We've done a bunch of more object-y action-y pictures, which we can post when we have discussed all of them with each other.)

Notes:

1. The core is Commitment-Fultillment-Event. This forms a bottom up web (as complex as needed) of what events fulfill what commitments. Reciprocity is based on events, not resources directly. This allows trading of work, for example. Or more standardly, an issue of a resource.
2. In some cases, Commitments come first and are part of an ExchangeAgreement. In these cases, that is the way you can tell events are in reciprocity to each other.
3. In other cases, there is no Commitment, and an Event must trigger creation of a Commitment based on an Agreement. (Contributory economy, probably timebank (assuming commitments are not created explicitly there)). Once the Commitment is created, other Events can fulfill it.
4. I'm guessing Intent - Commitment is a many to many, but haven't studied it enough yet. It is at least 1:many. Note that in this model, a Commitment is committed. So a plan for example is still an Intent. Again, we weren't focusing on this part.
5. For gift economy, you basically just get Events. The Event-Appreciation-Event is there in case someone wants to explicitly acknowledge what the gift Event is in appreciation for.
6. I'm sure the Agreement piece can use a lot of development. @gcassel So far, we have identified Exchange Agreements (aka Exchange, ties together reciprocal Commitments), Distribution Agreements (aka Value Equations). And of course there are lots of levels of contracts, and blanket agreements of various kinds. Like for timebanks, there is a basic agreement that if people work x hours of any type of work, they get x credits. But basically, you can reference an agreement to explain how or why something came into being.
7. Don't worry about names!!!

More later......

[fosterlynn]

Timebank YAML based on the above model, first draft.

'@id': https://timebank.example/eqrr1341234-Paul-offer
'@type': vf-x:Offer
'vf:action': vf:work
'vf:resource':
  '@type': vf-x:ResourceTemplate
  'vf:category': prodont:Plumbing
'vf-x:offeredBy': https://timebank.example/Paul
'vf-x:beginDate': 20161201
'skos:note': Licensed retired plumber, can do any residential plumbing.

Then Mary calls Paul and arranges for him to come and fix her faucet, they set a date (not recorded in the system). When Paul is done, Mary checks it out, and credits his account for the hours he worked. Looks like this when done (which is all at once).

'@id': https://timebank.example/d83b4ac910#work-event
'@type': vf:IPOEvent
'vf:action': vf:work
'vf:intent': https://timebank.example/eqrr1341234-Paul-offer
'vf:resource':
  '@type': vf-x:ResourceTemplate
  'vf:category': prodont:Plumbing
'vf-x:provider': https://timebank.example/Paul
'vf-x:receiver': https://timebank.example/Mary
'vf:affectedQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Hour
  'qudt:numericValue': 5

'@id': https://timebank.example/c6c881b8#commitment
'@type': vf:Commitment
'vf:action': vf:issue
'vf-x:basedOn': https://timebank.example/d83b4ac910#work-event
'vf-x:provider': https://timebank.example/Mary
'vf-x:receiver': https://timebank.example/Paul
'vf:resource':
  '@type': vf:Resource
  '@id': https://timebank.example/Mary-timebank-hr-acct
'vf:originalQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:timebank-hour
  'qudt:numericValue': 5
'vf:remainingQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:timebank-hour
  'qudt:numericValue': 0

'@context': https://w3id.org/valueflows/v1
'@id': https://timebank.example/7d756cb1
'@type': 'vf:Process'
'vf:io':
  - '@id': https://timebank.example/oiure331b8#Mary-event
    '@type': vf:IPOEvent
    'vf:action': vf:issue
    'vf-x:provider': https://timebank.example/Mary
    'vf:resource':
      '@type': vf:Resource
      '@id': https://timebank.example/Mary-timebank-hr-acct
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:timebank-hour
      'qudt:numericValue': 5
  - '@id': https://timebank.example/oiure331b8#Paul-event
    '@type': vf:IPOEvent
    'vf:action': vf:receive
    'vf-x:receiver': https://timebank.example/Paul
    'vf:resource':
      '@type': vf:Resource
      '@id': https://timebank.example/Paul-timebank-hr-acct
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:timebank-hour
      'qudt:numericValue': 5

'@id': https://timebank.example/oiure331b8#fulfillment
'@type': vf-x:Fulfillment
'vf-x:sourceEvent': https://timebank.example/oiure331b8#Mary-event
vf-x:fulfillsCommitment': https://timebank.example/c6c881b8#commitment
'vf:affectedQuantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:timebank-hour
  'qudt:numericValue': 5

Note in this case, although commitments could be recorded before the work is done, I don't think that actually is done, so this then becomes a case where the reciprocal commitment is created based on the actual first event.

[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/exchange/-/issues/32.

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