Principles

[bhaugen]

@fosterlynn @ahdinosaur @elf-pavlik @simontegg and to whom it may concern:

I'm talking about "the model" (or "the ontology" if you prefer) here instead of "the vocab" because it ain't about the words.

I'd like to roughly agree on some principles for this vocab and the model behind it. In this rant on another issue, I said something to Elf about changes that might "break the model", and he responded, "I definitely don't want to break anything in your model 😉".

Which gets into this swamp called "my model", and I would like to crawl out of that swamp please.

A. It ain't my model. It belongs to Bill McCarthy and the REA community, to which I contribute in small ways. We have changed it for OVNs, but the core model as well as our changes are just the seeds for this exercise, not the end.
B. To the extent that it is my (and Lynn's) model, as in the model behind NRP (valnet), it is incomplete (although it does have running code behind it, and it does work), it is under constant change, and it is most likely wrong in one way or another.

So I'd like to work out some principles that the openvocab/ovn model should follow, and then we can start to say that some change (or some existing element) does or does not follow the principles.

1. The model must enable collaboration between different people in different organizations using different software on different platforms using different human and programming languages.
2. The model must be able to form global networks which can track the flows of resources (values) forwards and backwards. Or maybe it would be better to say "in any direction", but forwards means in the direction of value creation, and backwards means in the direction of return or compensation.
3. Corollary: the model must be able to support value equations that distribute income (rewards) according to peoples' contributions to the creation of the values that generated the income or rewards, regardless of where and when in the network configuration those contributions occurred.
4. The model must also be able to support coordinating work between different people in different organizations. People who are not concerned with rewards may still want to coordinate work.
5. The model must be fractal. It must support global views of networks in aggregate as well as drilling down to lower and lower levels of detail. Those lower levels of detail, for example inside one organization, may require permissions.
6. The model must also work on the Recipe, Plan and Event levels (whatever those get called in the end), where the objects on each level are linked appropriately to the other levels.
7. The model must support non-business-as-usual organizational forms and economic relationships in addition to traditional business organizations and relationships.

[Aside: I was unhappy with where the discussion with Elf was left. Maybe this will clarify and get it out of the "my model" swamp: A principled statement of "to break the model" means "to break the flows". So, for example, in the Good Relations Conceptual model, I think the Compensation concept, as part of their Agent-Promise-Object-Compensation exchange model, while useful to specify prices in a business exchange, is a dead end in the flows.]

What happens in any economic exchange is that (typically two) Agents exchange resources. Compensation is a relationship between resource flows (economic events), typically goods or services from one agent and money from the other agent, but it would not have to be money, it could be barter.

And even if it's money, it came from somewhere, it has a history, which might be important in terms of network resource flows. For example, Sensorica is now crowd-funding a 3D printer, not through Kickstarter but from their immediate community. Each of the financial contributions goes into a fund which will purchase the printer, and when the printer is used for commercial work, the income will flow back to the contributors to the fund.

I would also suggest we use the IETF principle, "rough consensus and running code". In other words, let's get some rough agreements on the table and then start coding from some actual collaborating systems to see if those agreements work in practice. So, for example, if we get some rough agreement on the organizational model, we try it out between (for example) NRP, Holodex and PLP. If we get some agreement on recipe components, we try them out between (for example) NRP, IPOTables and Wevolver.

Please suggest improvements, disagree, add, change, delete, etc. Then if we can agree with some more concise statement of principles, we can put it somewhere handy.

[ahdinosaur]

👍 i love the principles outlined, thanks for this context @bhaugen. ❤️

[bshambaugh]

Thanks for providing this as a point of reference :)

[bshambaugh]

@ahdinosaur Why did you use JSON-Schema? If that is what it is.

[ahdinosaur]

/off-topic @bshambaugh it's a standard schema format with lots of people already using it and existing tooling built around it (validators, html form generators, documentation generators, mock data generators, restful endpoint generators, etc). my plan is to extend the schemas (which is still valid json-schema) and the available tooling to include what i find missing: linked data contexts, relations, etc.

[elf-pavlik]

@bhaugen I would also like to make sure that we support systems where all the contributors can get shares of the outcome to allocate as they wish e.g.

• contributors to renewable energy coop get kWh of electricity to allocate
• contributors to train system get 'km on the railway' to allocate
• contributors to food network, get 'food baskets' to allocate

etc.

In other words, group can choose to introduce various monetary currencies into their flows but can also do all the accounting without introducing such artifacts.

ping @zippy @artbrock

[bhaugen]

@elf-pavlik - I love the idea, and do want to support value flows that do not use money. I tried to say something like that in the commentary after the statement of principles, but agree that it should be added as a principle.

Do you see any difference between (a) "group can choose to introduce various monetary currencies into their flows but can also do all the accounting without introducing such artifacts", and (b) "all the contributors can get shares of the outcome to allocate as they wish"?

Have you seen any live examples of (b)? If so, how did they do it?

[elf-pavlik]

Lately someone in Paris mentioned to me that they can get kWh as part of the payment for work in green energy coop, I'll make sure to dig up the details!

(a) makes much more generic statement about keeping monetary currencies optional
(b) proposes one of possible alternatives to monetary system, while many other can come handy e.g. networked barter like in https://edgeryders.eu/en/makerfox/open-sourcing-network-barter

[xekoukou]

This is certainly the idea. Any monetary system or any other form of
information/cooperation system/ system of property exchange on products is
compatible with the principles.

Me and @artbrock and @elf-pavlik want to change this type of system , each
in his own way.

@bhaugen also doesn't like the monetary system. I am not sure if you knew
that Pavlik, his language is a compromise towards what the audience can
accept. In the same way, maybe Bob doesn't know that you have lived for
many years without money.

On Sat, Mar 21, 2015 at 7:30 PM, ☮ elf Pavlik ☮ notifications@github.com
wrote:

Lately someone in Paris mentioned to me that they can get kWh as part of
the payment for work in green energy coop, I'll make sure to dig up the
details!

(a) makes much more generic statement about keeping monetary currencies
optional
(b) proposes one of possible alternatives to monetary system, while
many other can come handy e.g. networked barter like in
https://edgeryders.eu/en/makerfox/open-sourcing-network-barter

—
Reply to this email directly or view it on GitHub
https://github.com/openvocab/ovn/issues/12#issuecomment-84433610.

[bhaugen]

I've talked to @elf-pavlik enough to understand that...:wink:

For me, it's not about what the audience can accept, it's that we are in this transitional state, where money is often required (as in, Sensorica needs to pay rent on their lab, and it's better that they have a public lab than not). But I don't want to make it required by a system that wants to speed the transition.

[bhaugen]

@elf-pavlik - please suggest how to write up the additional principles here?

(Wow, can't type today...)

[bhaugen]

@elf-pavlik - "someone in Paris mentioned to me that they can get kWh as part of the payment for work in green energy coop, I'll make sure to dig up the details!"

That seems like a great test case for scenario (b)! If the green energy coop was interested in participating in any way, that would be even better! We think of all this stuff as an ongoing series of scientific experiments involving the coders and the living organizations who want to use the code.

[bhaugen]

So is everybody involved in any way at this point good with the principles listed above, with @elf-pavlik 's additions? Or does anybody else have any suggestions for improvement?

If and when they seem good enough for now, I'll put them in a file in the repository under version control so people can offer pull requests from there on in.

[fosterlynn]

@bhaugen I'm good.

[xekoukou]

The way I am thinking at the moment of NRP is of each organization having
a different protocol of coordination/cooperatation inside it.

1. Sure though i haven't figured out how yet. The vocabulary is one
   thing. What about protocols? How is a new deal performed? A Proposes - B
   reviews - B accepts - B returns acceptance - A returns confirmation or
   A proposes and waits for m minutes - if B doesnt respond switch to next
   provider. There are many protocols.

2. Sure though I haven't figured out how yet. Linked Open Data is a good
   candidate here.

3. There is a problem when you want to give revenue for a contribution a
   posteriori from a different part of the network. Contributions need to be
   aknowledged a priori by the network or be forgotten. A good example of this
   is* patents_.
   *I agree_ in general with 3.

4. Sure.
   5)Sure. though I dont know how.

5. I believe that this should be optional, there are use cases where it is
   not needed. It should be pluggable, one should be able to implement it if
   he wants in his organization protocol.

6. Sure.

On Sun, Mar 22, 2015 at 10:53 PM, Lynn Foster notifications@github.com
wrote:

@bhaugen https://github.com/bhaugen I'm good.

—
Reply to this email directly or view it on GitHub
https://github.com/openvocab/ovn/issues/12#issuecomment-84728218.

[bhaugen]

@xekoukou - 1) protocols: in general, we'd start with Conversation for Action, which we discussed here:
https://www.loomio.org/d/69tuWRqB/conversation-for-action
Or, short version: http://conversationsforaction.com/cfa-playground

You can get more elaborate than that, but it's a well-design minimum that assumes P2P relationships. It's a conversational protocol, which could be implemented with many different technologies. The vocabulary should evolve to specify some messages in such conversations. (According to me, anyway...)

For the rest, when I wrote "must be able to do do...", that does not mean any user group must do it, just that the vocabulary and model must be able to do so if somebody wants. So for any user group, almost everything would be optional. Clear enough? Or should that be spelled out more?

[xekoukou]

ok.

On Mon, Mar 23, 2015 at 1:26 AM, Bob Haugen notifications@github.com
wrote:

@xekoukou https://github.com/xekoukou - 1) protocols: in general, we'd
start with Conversation for Action, which we discussed here:
https://www.loomio.org/d/69tuWRqB/conversation-for-action
Or, short version: http://conversationsforaction.com/cfa-playground

You can get more elaborate than that, but it's a well-design minimum that
assumes P2P relationships. It's a conversational protocol, which could be
implemented with many different technologies. The vocabulary should evolve
to specify some messages in such conversations. (According to me, anyway...)

For the rest, when I wrote "must be able to do do...", that does not mean
any user group must do it, just that the vocabulary and model must be able
to do so if somebody wants. So for any user group, almost everything would
be optional. Clear enough? Or should that be spelled out more?

—
Reply to this email directly or view it on GitHub
https://github.com/openvocab/ovn/issues/12#issuecomment-84744018.

[artbrock]

@elf-pavlik Just a note regarding: "group can choose to introduce various monetary currencies into their flows but can also do all the accounting without introducing such artifacts."

If you just drop the word "monetary" you may not need the caveat about accounting without introducing such artifacts. One of the functions of currency is being a unit of account. You could be counting number of gifts given, or average on a 5-star rating, or lines of code contributed, and any accounting you're doing is essentially using a currency, even if a non-monetary one.

Any units you create to do your accounting with to divvy up shares of outcomes are currencies (by my understanding and definition, but not always immediately understood that way by folks who are not used to considering non-monetary currencies as valid currencies).

@bhaugen Whether your model or not, it's great to see the principles of what you're seeking spelled out so clearly.

[bhaugen]

@artbrock - thanks for stopping in! I loved your recent article Reputation is Orthogonal to Exchange. But both in that article and your comment above you are using "currency" in this very expanded meaning that still doesn't quite make sense to me. To me a currency is something that is not only a unit of account (because any inventory has units of account, e.g. carrots or wheels), it is also a medium of exchange. So I'm not sure why you still talk about reputation currencies when you are quite clear that they are not a medium of exchange.

I'm planning to continue a conversation with @zippy about currencies as you guys think about them and maybe I'll start to get it. I'll cc you when I'm ready to do that. (Too much on plate today...)

P.S. I wonder if @elf-pavlik has something like your view of currencies in mind when he thinks about kwh as payment...?

[bhaugen]

Wrote up the principles in the wiki: https://github.com/openvocab/ovn/wiki/Principles-for-this-vocabulary

Comments? Suggestions for improvement?

If none, in a few days, I'll link that wiki page to the README.

[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/forum-valueflo-ws/-/issues/9.

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