valueflows / exchange

exchange has moved to https://lab.allmende.io/valueflows/exchange
3 stars 4 forks source link

define Commitment #21

Closed elf-pavlik closed 4 years ago

elf-pavlik commented 8 years ago

based on conversation from #14

I think we need to take few use cases and based on them try to define commitment. In some cases they seem to me similar to Transfer of rights. Example showing a clear difference between those two would help with drawing a stronger distinction.

bhaugen commented 8 years ago

From “The Ontological Foundation of REA Enterprise Information Systems" (Guido Geerts and William.E. McCarthy) working paper, Michigan State University (August 2000)

Commitment ... Ijiri (1975,p.130) defines a commitment as an “agreement to execute an economic event in a well-defined future that will result in either an increase of resources or a decrease of resources.” Commitments are important economic phenomena, and we use Ijiri’s term “executes” for the relation between them and the actual economic events that follow them. We model the pair-wise connection of requited commitments in a fashion similar to actual exchanges except we substitute a reciprocal relationship between the two commitments where an actual exchange has a duality relationship. Because of the importance of reciprocal relationships, we take the additional step of reifying them at a higher level of abstraction as economic agreements, and we differentiate between two different types of agreements: contract and schedule, the definition of which depends on the ultimate nature of the economic exchange. A transfer executes a contract while a transformation executes a schedule. For example, a sale executes a sales order which is part of a contract, and a production job executes a production order which is part of a schedule. Two additional relationships are needed to integrate the commitments with the exchange description: reserves and partner. Reserves is a special kind of stock-flow relationship that describes the scheduled inflow and outflow of resources. A sales order results in a reservation of the finished goods to be delivered, while a production order results in a scheduled completion of finished goods.

bhaugen commented 8 years ago

A contractual commitment requires a conversation for action where each participant agrees.

elf-pavlik commented 8 years ago

How do we use it in Dental Care use case discussed in #14?

bhaugen commented 8 years ago

This is a general statement about commitments and claims: the difference between commitment or claim and right is that a right is something you have now, as a result of an economic event that already happened, while a commitment or claim is an expectation of a transfer of rights in the future, rights that you do not have now.

gcassel commented 8 years ago

a commitment or claim is an expectation of a transfer of rights in the future, rights that you do not have now.

++ A systematically valid commitment or claim is a mutually recognized expectation / understanding

bhaugen commented 8 years ago

Commitments must be mutually agreed. Claims arise situationally in a set of reciprocal commitments when one commitment is fulfilled. Explicit agreement is not necessary. Is that understandable?

If two people agree on a set of reciprocal commitments, it's a different situation if they both change their minds (cancel the agreement) than if one person fulfills their commitment. This is true in good behavior as well as common law.

gcassel commented 8 years ago

^ I was sloppy: I meant that the validity of a claim must be implicitly present in the mutually agreed commitment which it derives from. (Along with a lack of delivery, which can't precisely be proven, but that's life!)

bhaugen commented 8 years ago

the validity of a claim must be implicitly present in the mutually agreed commitment which it derives from

Agreed.

elf-pavlik commented 8 years ago

I added Exchange Chain to use cases (see also #19)

It looks like concept of Claim may only apply to 1-on-1 exchanges. For multi party exchanges it seems that we only can track fulfilment of the particular commitment (by rea:EconomicEvent?)

bhaugen commented 8 years ago

It looks like concept of Claim may only apply to 1-on-1 exchanges. For multi party exchanges it seems that we only can track fulfilment of the particular commitment (by rea:EconomicEvent?)

Consider a 3-party exchange: a supplier, a customer and a trucker. When the customer pays for a product from the supplier, or the supplier transfers a product to the customer, whichever rea:EconomicEvent happens first triggers a claim from the counterparty.

Likewise if the trucker delivers the product first, the trucker has a claim against whoever agreed to pay for shipping. Of if one of the parties paid in advance for shipping, they have a claim against the trucker to deliver the goods.

elf-pavlik commented 8 years ago

Have you looked at Exchange Chain use case? I think you discuss 3 agents having two independent 1-on-1 exchanges. Use case which I created illustrates a chain of transfers between 4 agents (or at least 3 as variant note suggests, it may differ when delivery arrangements come into play #27 ). In described case we can NOT distinguish any 1-on-1 exchange and it doesn't seem that Claim can appear in that case, maybe except last stage when just last commitment stays not fulfilled (I can add more parties to that use case to make it more prominent)

elf-pavlik commented 8 years ago

YAML snippet provided by @ahdinosaur in https://github.com/valueflows/valueflows/pull/115#issuecomment-220808238

'@type': vf:Commitment
'vf:name': local delicious apples for sale
'vf:agent': ex:supplier
'vf:validUntil': <a week from today>
'vf:action':
  '@type': vf:Transfer
  'vf:flow':
  - '@type': Give
    'vf:from': ex:consumer
    'vf:to': ex:supplier
    'vf:resourceType': 'ex:dollar'
    'vf:amount':
      '@type': qudt:QuantityValue
      'qudt:numericValue': 100
      'qudt:unit': unit:Unitless
  - '@type': Give
    'vf:from': ex:supplier
    'vf:to': ex:consumer
    'vf:resourceType': ex:apple
    'vf:amount':
      '@type': qudt:QuantityValue
      'qudt:numericValue': 50.4
      'qudt:unit': unit:Kilogram

I think it needs two instances of vf:Transfer and somehow express dependency between them. Since we talk about commitments we should also use separate namespaces for different agents to not get impression of working with a centralized data silo.

Trying to make minimal changes:

'@id': supplier:commitment/6246062062
'@type': vf:Commitment
'vf:name': commitment to exchange 50kg of apples for 100USD
'vf:author': supplier:people/dan
'vf-x:signature': <dan's signature>
'vf:validUntil': <a week from today>
'vf-x:promise':
  '@type': vf:Transfer
  'vf:from': supplier:identity
  'vf:to': consumer:identity
  'vf:resourceType': supplier:resource-types/apple
  'vf:amount':
    '@type': qudt:QuantityValue
    'qudt:numericValue': 50.4
    'qudt:unit': unit:Kilogram
'vf-x:expectation':
  '@type': vf:Transfer
  'vf:from': consumer:identity
  'vf:to': supplier:identity
  'vf:resourceType': iso4217:USD
  'vf:amount':
    '@type': qudt:QuantityValue
    'qudt:numericValue': 100
    'qudt:unit': unit:Unitless
bhaugen commented 8 years ago

@elf-pavlik wrote upthread:

In described case exchange chain we can NOT distinguish any 1-on-1 exchange and it doesn't seem that Claim can appear in that case, maybe except last stage when just last commitment stays not fulfilled (I can add more parties to that use case to make it more prominent)

Agreed. Your addendum "Food Coop commits 1 box to Sofia and she transfers this commitment to Maria" makes the claim of Sofia to 1 box from Food Coop a lot more clear.

But these chains are really interesting in terms of mutual coordination economics.

elf-pavlik commented 8 years ago

Do you notice that at stage where Beto already taught percussion to Sofia but she haven't helped in FoodCoop with distribution yet, Beto has no claims even that he already fulfilled his promise from the commitment.

bhaugen commented 8 years ago

I think I need a diagram.

exchange chain

If this were a mutual credit network, Beto would have received mutual credit hours from Sofia for teaching percussion, and could have exchanged those with the Food Coop for his box of vegetables.

(I know, the use case was not a mutual credit system, but I'm just thinking about how different systems handle exchange chains. But depending on how Beto and Sofia agreed on Beto's teaching, he might have had a claim against Sofia. So why did Sofia give the box to Maria? Inquiring people want to know...)

elf-pavlik commented 8 years ago

But depending on how Beto and Sofia agreed on Beto's teaching, he might have had a claim against Sofia.

What kind of claim? "Please go help in a food coop as you promised so that I can get a box of mixed vegetables". Sofia doesn't promise anything she could offer directly to Beto, in her commitment she makes promise to Food Coop which in turn makes promise to Beto. So we can have promises fulfilled by events, promises not fulfilled (yet) but often we will have no claims.

bhaugen commented 8 years ago

depending on how Beto and Sofia agreed on Beto's teaching etc...

I misread the use case. Missed that those were commitments, not events.

almereyda commented 4 years ago

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/21.

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