Modeling exchanges using claims

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.