Principles
@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.
- The model must enable collaboration between different people in different organizations using different software on different platforms using different human and programming languages.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.