commit 0736de90fd4dec65d6def3b675cd83b1376052a9
parent bbd7c59a9a8e22f9855899db89ccd98f2d45a557
Author: Lynn Foster <foster.j.lynn@gmail.com>
Date: Fri, 16 Aug 2019 14:41:07 -0500
fixes to .3 release (#559)
* fixed actions in ttl
* Changes in response to @bhaugen review of whole doc
Diffstat:
14 files changed, 56 insertions(+), 88 deletions(-)
diff --git a/docs/README.md b/docs/README.md
@@ -7,8 +7,8 @@ Purpose: to enable internetworking among many different software projects for re
Or, with less buzzwords, "let's help a lot of alternative economic software projects that are solving different pieces of the same puzzle be able to work together".
-One of the purposes of this vocab is to support resource flows connecting many software applications. These flows may be oriented around Processes, Exchanges, or combinations of both.
+One of the purposes of this vocab is to support resource flows connecting many software applications. These flows may be oriented around processes that make things, exchanges that trade things, or combinations of both.
-We want to support RDF based and non-RDF based use of the vocabulary, basically any way that people want to use software and data on the internet to help create economic networks.
+The vocabulary is presented in several ways, as Linked Open Data using the Resource Description Framework (RDF) family of languages, as well as a GraphQL API and a UML model, and other notations to come. We want to support RDF based and non-RDF based use of the vocabulary, basically any way that people want to use software and data on the internet to help create economic networks.
You can find us [here on github](https://github.com/valueflows). Or come on over and ask questions in the [Welcome Chat](https://gitter.im/valueflows/welcome).
diff --git a/docs/appendix/dependent-demand.md b/docs/appendix/dependent-demand.md
@@ -8,16 +8,16 @@ Basically, you traverse a graph of Recipe Processes backwards from the last Reci
This description refers to this diagram:
-Take each request for quantities of Resource Category as a demand and start the traversal.
+Take each request for quantities of Recipe Resource as a demand and start the traversal.
**Start:**
-* First check for onhand and available Economic Resources, or previously scheduled Output Intents, that are not yet allocated to any demand.
-* Allocate any that you find to the highest priority demand (where highest priority usually means earliest delivery date). _(Those are soft allocations, known only in the computer system.)_
-* For demands that find no or insufficient available inventory or Output Intents, look for a Recipe Process that can create some. If you can't find a Recipe Process, suggest a purchase.
+* First check for onhand and available Economic Resources, or previously scheduled output Intents, that are not yet allocated to any demand.
+* Allocate any that you find to the highest priority demand (where highest priority usually means earliest delivery date). _(Those are soft allocations, known only in the computer system.)
+* For demands that find no or insufficient available inventory or output Intents, look for a Recipe Process that can create some. If you can't find a Recipe Process, suggest a purchase.
- * _(Note: a Recipe is not really a thing, it's just a graph. A requested Resource Category may have one or more Recipe Processes that can create some Resources of that category. Each of those Recipe Processes may have Recipe Inputs that specify some other Resource Categories, and each of those Resource Categories may have Recipe Processes that can create them, and so on, recursively, until you can't find any more creation Recipe Processes. If you find more than one creation Recipe Processes, you will need some way to select one.)_
+ * (Note: a Recipe is not really a thing, it's just a graph - although in a future release it will be a thing. A requested Recipe Resource may have one or more Recipe Processes that can create some Resources of that specification. Each of those Recipe Processes may have Recipe Flow inputs that specify some other Recipe Resources, and each of those Recipe Resources may have Recipe Processes that can create them, and so on, recursively, until you can't find any more creation Recipe Processes. If you find more than one creation Recipe Processes, you will need some way to select one.)
-* When you find a Recipe Processes,
- * then schedule a Planned Process based on the Recipe Process, with a Output Intent of the required quantity of the demanded Resource Category. Backschedule so that the end of the process meets the timing requirements of the inputs to the processes that will be waiting for them.
- * Then schedule Input Intents for each of the Recipe Inputs of that Recipe Process, with their quantities scaled to the quantity of the planned output.
- * Then start over from the **Start** with each of those new Input Intents as the demand.-
\ No newline at end of file
+* When you find a Recipe Process,
+ * then schedule a planned Process based on the Recipe Process, with an output Intent of the required quantity of the demanded Recipe Resource. Backschedule so that the end of the process meets the timing requirements of the inputs to the processes that will be waiting for them.
+ * Then schedule input Intents for each of the recipe inputs of that Recipe Process, with their quantities scaled to the quantity of the planned output.
+ * Then start over from the **Start** with each of those new input Intents as the demand.
diff --git a/docs/appendix/track.md b/docs/appendix/track.md
@@ -30,6 +30,6 @@ Here is the logic for tracking and tracing.
* a Process or Transfer from which is is an output, or
* if it is an input to a Process or Transfer, the EconomicResource which it affects.
-When more than one resource of the same classification goes from input to output of the same process, use the tracking identifier if you need to track or trace the same resource. And example of this would be less-than-truckload shipments, where many separate resources with different destinations are included in the same shipment process.
+When more than one resource of the same specification goes from input to output of the same process, use the tracking identifier if you need to track or trace the same resource. And example of this would be less-than-truckload shipments, where many separate resources with different destinations are included in the same shipment process.
When the same economic resource is both input and output of a process, sometimes a series of processes, such as for repair or quality testing or a workflow where a resource is refined through stages like writing/editing/etc, the stage must be identified, based on the kind of process the resource was last output of.
diff --git a/docs/introduction/agents.md b/docs/introduction/agents.md
@@ -1,12 +1,12 @@
# Agents
-The agent vocabulary describes networks of people, organizations and networks, constructed using a simple but powerful model of agents and their relationships.
+Agents can be individual persons or organizations. The agent vocabulary describes networks of people, organizations and networks, constructed using a simple but powerful model of agents and their relationships.
In ValueFlows, we are talking about economic agents, agents who can create or exchange value, and make agreements with each other - who have economic agency. But we want to re-use existing vocabularies for commonly defined things (foaf:Agent, foaf:Person, org:Organization), so we have elected to use those as much as possible here, even though they are sometimes more broadly defined.
We also want to acknowledge that some people prefer to think of themselves as independent and decentralized agents who interact in different places in the economy as individuals, and some people think of themselves more as members of different groups and networks and communities and interact more in the context of those groups and networks and communities. Many experiments are going on as people strive towards another economy. We want to support all these experiments, so want to support both of these ways of thinking and organizing ourselves. The agent vocabulary is very flexible, and will support these as well as current conventional structures.
-So, if people want to form a group that has agency as a group, fine. If people want to consider that their group does not have agency as a group, also fine. Not all groups, and especially not all networks, will be Agents in ValueFlows. That depends on the agreement of the people in the group. Note that within the vocabulary, network formations will appear, as agents have economic interactions with each other in the world. This does not mean that the network is necessarily a ValueFlows Agent.
+So, if people want to form a group that has agency as a group, fine. If people want to consider that their group does not have agency as a group, also fine. Not all groups, and especially not all networks, will be Agents in ValueFlows. That depends on the agreement of the people in the group, and what the group needs to do as-a-group. For example, does the group need to make agreements as-a-group with other groups? Or exchange resources with other agents as-a-group? Note that within the vocabulary, network formations will appear, as agents have economic interactions with each other in the world. This does not mean that the network is necessarily a ValueFlows Agent, but it could be, if the participants want.
### Agent Relationships
@@ -18,4 +18,4 @@ There are a number of useful Properties in existing vocabularies that can be use
Relationships have direction: For example, in "Michael is a member of Enspiral", Michael is the subject and Enspiral is the object. In this case the inverse is also valid, "Enspiral has member Michael".
-Relationships can be in a scope (or not): For example, "Kathy is mentor of Sam, in the scope of Enspiral."
+Relationships can be in a [scope](https://valueflo.ws/introduction/scoping.html) (or not): For example, "Kathy is mentor of Sam, in the scope of Enspiral."
diff --git a/docs/introduction/core.md b/docs/introduction/core.md
@@ -2,7 +2,9 @@
The vocabulary has a core that would fit many different kinds of economic formations - value networks, supply chains, joint ventures, business collaboration network....
-The core is based on the REA (Resource, Event, Agent) ontology. You can find all the details by following the [links here](https://valueflows.gitbooks.io/valueflows/content/appendix/rea.html).
+The core is based on the REA (Resource, Event, Agent) ontology. You can find all the details by following the [links here](https://valueflows.gitbooks.io/valueflows/content/appendix/rea.html).
+
+ValueFlows takes the "independent view" of REA, which is a neutral viewpoint in the "collaboration space" between agents. The "trading partner view" happens intenral to one agent. For example, from one agent's viewpoint, the exchange may be a "purchase", from the other agent's viewpoint, it might be a "sale". From the neutral viewpoint, it is an exchange of resources, with usually at least two flows of resources, from different directions.
These are the main concepts in the REA ontology, as pictured in this [document](http://www.msu.edu/user/mccarth4/Alabama.doc):
diff --git a/docs/introduction/estimates.md b/docs/introduction/estimates.md
@@ -8,9 +8,9 @@ Processes can be composed into scenarios at any level. Like scheduled plans, th
Some examples we have seen:
* <b>Plan Refinement</b>. Before the final operation plan is set, sometimes it is useful to make more general plans, which then can be refined further, ending with the scheduled plan. These plans are estimates made using "planning horizons", which are defined durations starting from the planning date - for example year then month, then blending into the actual scheduled plans.
-* <b>Budgeting</b>. A Budget is a summary of input requirements for a scope for a time interval (sometimes corresponding to the organization's "accounting period"), often yearly, as a higher level of planning. Budgets are often created to support a specific goal. Budgets are usually created before operational planning is done, and are estimates. Often a forecast is made consisting of desired or expected deliverables for the period, sometimes using past event history as a starting point. This would create a demand-driven budget. Or sometimes a supply-driven budget makes more sense, for example when all of the producing capacity will be used in any case, and then the outputs will be constrained by the inputs available. In any case, the budgeted inputs and outputs are kept, as they are often compared to actuals later. The budget itself could be represented as a Process, and it could nest line item processes based on type of resource or process. A budget is usually for one scope.
+* <b>Budgeting</b>. A Budget is a summary of input requirements for a scope for a time interval (sometimes corresponding to the organization's "accounting period"), often yearly, as a higher level of planning. Budgets are often created to support a specific goal. Budgets are usually created before operational planning is done, and are estimates. Often a forecast is made consisting of desired or expected deliverables for the period, sometimes using past event history as a starting point. This would create a demand-driven budget. Or sometimes a supply-driven budget makes more sense, for example when all of the producing capacity will be used in any case, and then the outputs will be constrained by the inputs available. In any case, the budgeted inputs and outputs are kept, as they are often compared to actuals later. The budget itself could be represented as a Process, and it could nest line item processes based on type of resource or process. A budget is usually for one scope. Here is [an example](http://urgenci.net/solid-base/).
* <b>Comparative Analysis</b>. Often different plans will be created for the same basic data set. One example is when doing risk analysis or other comparative analysis. Different assumptions might skew a plan in different useful directions, for example a "normal scenario" and a "worst case scenario".
-* <b>Network Analysis</b>. This is an analytical look at all or some of the actual and/or potential resource flows for a scope, often a community or region. This can be modeled using higher level types of processes and types of resources, and could include intents or economic events. One use of this kind of analysis is to identify gaps and opportunities to keep resources circulating in a community to improve economic health and resilience.
+* <b>Network Analysis</b>. This is an analytical look at all or some of the actual and/or potential resource flows for a scope, often a community or region. This can be modeled using higher level types of processes and types of resources, and could include intents or economic events. One use of this kind of analysis is to identify gaps and opportunities to keep resources circulating in a community to improve economic health and resilience. Here is [an example](http://locecon.org/).
Agents can define different scenarios that they want to use. So for example, if a group does yearly budgets, each budget for different years could reference the same "yearly budget" scenario definition.
diff --git a/docs/introduction/flows.md b/docs/introduction/flows.md
@@ -1,6 +1,6 @@
# Flows
-Flows are a fundamental construct in the ValueFlows ontology. When the types of flows are considered in chronological order, they form a progression from potential to scheduled to realized:
+Flows are a fundamental construct in the ValueFlows ontology. The types of flows form a progression from potential to scheduled to realized:
1. Intents which can lead to Commitments
2. Commitments which can lead to Economic Events (or Intents can lead directly to Economic Events)
@@ -12,7 +12,7 @@ Intents describe potential future events which have not been agreed to by other
### Commitment
-Commitments describe potential future events which the involved agents have already agreed to pursue. Commitments can be considered contractual promises from one agent to another. Commitments can be thought of as "mirrors" of economic events, and Economic Events can fulfull Commitments. Commitments can satisfy Intents.
+Commitments describe potential future events which the involved agents have already agreed to pursue. Commitments can be considered contractual promises from one agent to another. Commitments can be thought of as plans of economic events, and Economic Events can fulfull Commitments. Commitments can satisfy Intents.
### Economic Events
@@ -48,12 +48,12 @@ Intents, Commitments, and Economic Events can occur at any granularity that is n
All flows use an action property to designate what the flow is doing and how it will affect an economic resource (or not). Actions are defined as follows.
* vf:produce - new resource created in that process or an existing stock resource added to
-* vf:use - for example a tool used in process, after the process, the tool still exists
+* vf:use - for example a tool used in process; after the process, the tool still exists
* vf:consume - for example an ingredient or component composed into the output, after the process the ingredient is gone
* vf:cite - for example a design file, neither used nor consumed, the file remains available at all times
* vf:work - labor power applied to a process
-* vf:pickup - transported resource or person enters the process, the same resource will appear in output with *vf:dropoff* verb
-* vf:dropoff - transported resource or person leaves the process, the same resource will appear in input with *vf:pickup* verb
+* vf:pickup - transported resource or person enters the process; the same resource will appear in output with *vf:dropoff* verb
+* vf:dropoff - transported resource or person leaves the process; the same resource or person appeared in input with vf:pickup verb
* vf:accept - in processes like repair or modification or testing, the same resource will appear in output with *vf:modify* verb
* vf:modify - in processes like repair or modification, the same resource will appear in input with *vf:accept* verb
* vf:pass - possible output of a testing or reviewing process, indicating the resource passed, the same resource will appear in input with *vf:accept* verb
diff --git a/docs/introduction/plan.md b/docs/introduction/plan.md
@@ -2,7 +2,7 @@
An operational plan is a schedule of related operational processes, that constitute a body of scheduled work with defined deliverable(s). A plan normally contains one or more process resource flows, one for each deliverable.
-A plan can cover more than one scope, if the different scopes are tightly coordinated with pre-agreed rules, for example sub-organizations of a main organization, or an ongoing supply chain. If not, or if the agents prefer, then requirements from one scope could become deliverables for another scope's plan. Different batch sizes could trigger a new plan for inputs to the main deliverable too. But all of this does not affect the vocabulary or model. Plans can relate to each other through resource flows just like Processes.
+A plan can cover more than one [Scope](https://valueflo.ws/introduction/scoping.html), if the different scopes are tightly coordinated with pre-agreed rules, for example sub-organizations of a main organization, or an ongoing supply chain. If not, or if the agents prefer, then requirements from one scope could become deliverables for another scope's plan. Different batch sizes could trigger a new plan for inputs to the main deliverable too. But all of this does not affect the vocabulary or model. Plans can relate to each other through resource flows just like Processes.
Plans are used for understanding and coordinating what needs to happen for specific outputs. The size and complexity of a Plan is up to the people who are planning and coordinating the work.
diff --git a/docs/introduction/proposals.md b/docs/introduction/proposals.md
@@ -6,7 +6,7 @@ Proposals are everywhere in advertising. But we see many groups posting proposa
Proposals can stay directed to broad or specific *audience*. In the broadest case, they stay available for anyone (public proposals). In the most narrow case, the stay available only for specific agent. In between those two extremes a whole spectrum exists, for example two distinct proposals can exist on providing particular product or service - one for club members and one for general public etc.
-Proposals are more general, often not commercial at all, expressed not in identified products but in categories, tags, and text. But they want to find each other. The offers want to find the matching requests. The requests want to find the matching offers.
+Proposals may be specific or more general, often not commercial at all, expressed not in identified products but in categories, tags, and text. But they want to find each other. The offers want to find the matching requests. The requests want to find the matching offers.
When they find their match, those with the matching offer and request enter into a [conversation for action](cfa.html) which might result in an agreement.
diff --git a/docs/introduction/resources.md b/docs/introduction/resources.md
@@ -16,12 +16,12 @@ An economic resource is observable. Its specification or classification defines
So, for example, most listings of things offered for sale on an e-commerce site are specifications, which can be searched using classifications. The one in a box delivered to your door is a resource.
-Or the description of the book entitled "The Power of Babel: A Natural History of Language", ISBN ISBN-13: 978-0060520854,
+Or the description of the book entitled "The Power of Babel: A Natural History of Language", ISBN-13: 978-0060520854,
is a specification. Your library may have two copies that you can check out. Those are resources.
#### The difference between a resource specification and a resource classification
-An economic resource or a flow can have only *resource specification*, defined by `resourceConformsTo`. This defines the lowest level useful type or kind of the resource that is needed. It can be defined within the ValueFlows vocabulary as a ResourceSpecification, or can refer to a specification elsewhere using a uri. Note that often taxonomies and other references on the web can define very specific resource specifications at their leaf levels.
+An economic resource or a flow can have only one *resource specification* in ValueFlows. This defines the lowest level useful type or kind of the resource that is needed. It can be defined within the ValueFlows vocabulary as a ResourceSpecification, or can refer to a specification elsewhere using a uri. Note that often taxonomies and other references on the web can define very specific resource specifications at their leaf levels.
An economic resource or a flow can have any number of *resource classifications*. They are used to filter, match, or group economic resources. Resource classifications can be part of a taxonomy. That means they can be defined very broadly and generally and maybe vaguely, or they can be defined very narrowly, but fit into broader classifications.
@@ -33,7 +33,7 @@ People can use the multitude of existing taxonomies for resource classifications
Resource classifications can also use other schemes, like facets or tags.
-The references to resource classifications are uri's, and not covered inside ValueFlows.
+The references to resource classifications are uri's, and not otherwise defined inside ValueFlows.
#### Identification and Behaviors of Resources
@@ -53,7 +53,7 @@ Substitutability: This defines if any resources of that specification or classif
#### Inventory
Economic Resources can be inventoried, not inventoried but could be, or it doesn't make sense to think about inventory.
-* Inventoried: You want to keep track of it, changes in quantity, and how many you have right now.
+* Inventoried: You want to keep track of it, its changes in quantity, and how many you have right now.
* Not inventoried: You could keep track of it, but it isn't worth it. This usually happens for quantities of small or hard to measure items that are obtained in bulk, like solder or bolts. In this case, you have to look at the actual resource to see if you need more, the data won't tell you.
* Not applicable: This is for types of work (unless scheduled), and other resources where it just doesn't make sense.
@@ -76,7 +76,7 @@ Sometimes part of the logical identification of a resource includes:
Stage is used when the same resource passes through multiple processes in its lifetime, and that information is needed by the next process to determine which resources can be valid inputs. For example, in creating a translation, you might have one translated document pass through translation, editing, proofreading, formatting stages. You don't want to bring that resource into the formatting stage until it has been proofread, for example. Or you might have a testing stage for a component or product, in which case you don't want to consume or transfer the resource until it both has been through the testing stage, and had a `pass` output result.
-These can be defined on the recipe or the plan, showing where an input flow expects a certain stage and/or state of a resource. In user-interface forms for adding EconomicEvents, the input event form should query EconomicResources for required stage and state when offering selections of possible input resources. The stage and state of an EconomicResource can be derived or stored, as preferred.
+These can be defined on the recipe or the plan, showing where an input flow expects a certain stage and/or state of a resource. In that case, [Dependent demand planning](https://valueflo.ws/appendix/dependent-demand.html) will select only those resources that fit the specified stage and state. In user-interface forms for adding EconomicEvents, the input event form should query EconomicResources for required stage and state when offering selections of possible input resources. The stage and state of an EconomicResource can be derived or stored, as preferred.
#### How resources relate to events
@@ -96,8 +96,10 @@ Two different kinds of "inventorying" of resources are affected by transfers.
We are defining two current quantities on the economic resource for these two concepts, accounting quantity for the first and onhand quantity for the second.
+For example, in vendor-managed inventory, the vendor owns the inventory (they see if in their accounting) but the store sees it in their onhand quantities. Or for inventory being shipped FOB source, the intended receiver owns the inventory and sees it in their accounting, but the goods are actually onhand in a truck.
+
#### How resources related to each other: contained resources
If one resource contains other resources, the contained resources are part of, or make up the larger resource.
-For example, a bank account might contain a number of "virtual accounts" that a group manages itself, outside the bank's knowledge. Or, a bike shed resource might contain 10 bikes, which are identified and tracked by their serial numbers as individual resources.
+For example, a bank account might contain a number of "virtual accounts" that a group manages itself, outside the bank's knowledge. Or, a makerspace network shared packages of resources for projects, where the package moved as a whole, but the resources inside were what the project used. Or, a bike shed resource might contain 10 bikes, which are identified and tracked by their serial numbers as individual resources.
diff --git a/docs/introduction/scoping.md b/docs/introduction/scoping.md
@@ -25,8 +25,10 @@ Accounting is usually done for an agent or other bounded scope. Where a computer
### Planning
-Sometimes a generic recipe will cross scope boundaries for particular agents. For example one agent could produce a resource that consumes a component made by another agent. In this case, can the first agent schedule the production of the component by the second agent? Possibly yes, if there are agreements in place for that, and the first agent has verified that inventory does not already exist. Or possibly, based again on agreements, the first agent can assume the second agent will provide the component, with the second agent taking responsibility for checking if it is onhand, and if not, scheduling it for production. Or possibly, the first agent plans only to source the component in some yet-to-be-defined way.
+Sometimes a generic recipe will cross scope boundaries for particular agents. For example one agent could produce a resource that consumes a component made by another agent. In this case, can the first agent schedule the production of the component by the second agent? Possibly yes, if there are agreements in place for that, and the first agent has verified that inventory does not already exist. Or possibly, based again on agreements, the first agent can assume the second agent will provide the component, with the second agent taking responsibility for checking if it is onhand, and if not, scheduling it for production.
### Distributing Incoming Resources
-Some organizations distribute incoming resources backwards on value flows, based on people's contributions to the resources that generated the income. When traversing the value chain, it is useful to know when the traversal has crossed a scope boundary, because it is possible that the rules for distributing the incoming resources will change for a different scope. If the rules change or the rules are unknown, the income can be passed on to the other scope for them to distribute.
+Some organizations distribute income backwards on value flows, based on people's contributions to the resources that generated the income. When traversing the value chain, it is useful to know when the traversal has crossed a scope boundary, because it is possible that the rules for distributing the incoming resources will change for a different scope. If the rules change or the rules are unknown, the income can be passed on to the other scope for them to distribute.
+
+Note that income does not need to be money and can include distributing the output of a process to the contributors, like when a community farm distributes food to its contributors.
diff --git a/docs/introduction/transfers.md b/docs/introduction/transfers.md
@@ -1,16 +1,15 @@
# Transfer
-One kind of transfer is an activity that re-assigns rights and responsibilities for an economic resource from one agent to another, but does not transform or transport the economic resource. A second kind is an activity that operationally changes physical custody or possession of an economic resource from one agent to another, without affecting rights, and without rising to the level of a process required to make that transfer.
+One kind of transfer is an activity that re-assigns rights and responsibilities for an economic resource from one agent to another. A second kind is an activity that operationally changes physical custody or possession of an economic resource from one agent to another, without affecting rights.
+
+Note that a transfer is a one-way activity. Two or more reciprocal transfers form an exchange.
We think that now, and more so in the future, there will be more gradations of rights and responsibilities for resources than are sometimes considered now. For example, as a society we may decide that we should take more responsibility for recycling or upcycling resources at the end of their useful life for us, or not wasting them. The concept of "ownership" may transition more into "stewardship" in a concept of the world that does not put humans in a position of controlling the world's resources or abdicating responsibilities to the ecosystem in the name of ownership. So, we are for the most part avoiding talking about ownership in this vocabulary, as we work towards more of an ecosystemic perspective.
#### Examples
-* For example, perhaps some agent has many apple trees, and plans on pressing apple cider. Another agent has an apple press and agrees to exchange use of the press (a resource) for a portion of the apple cider. The use of the press involves some rights (to use the press for some period of time) and responsibilities (to not run it beyond its capacity and to clean it up before returning it). The rights and responsibilities to a portion of apple cider is transferred in exchange for the transfer of use of the press.
+* For example, perhaps some agent has many apple trees, and plans on pressing apple cider. Another agent has an apple press and agrees to transfer use of the press (a resource) in exchange for a reciprocal transfer of a portion of the apple cider. The use of the press involves some rights (to use the press for some period of time) and responsibilities (to not run it beyond its capacity and to clean it up before returning it).
-* Or in a library, a book can be checked out for a period of time. The agent who checks it out can read it and is responsible for caring for it and returning it on time, another transfer.
+* Or in a library, a book can be checked out, a transfer from the library to the reader. The agent who checks it out can read it and is responsible for caring for it and returning it on time, another transfer.
* Or let's say that a community has farmland and equipment held in common. The community transfers responsibility for the land and equipment to some farmers to use and take care of. The community also transfers seeds every year to the farmers, enough to grow the food the community needs. During the year, the harvests are distributed (transferred) to the community members for their consumption. In reciprocity, the community provides for other needs of the farmers.
-
-In spite of these examples, we also want to note that transfers do not imply explicit or implicit exchanges, only a one-directional flow.
-
diff --git a/docs/introduction/usedfor.md b/docs/introduction/usedfor.md
@@ -7,36 +7,12 @@ For example, the [Madison WI Mutual Aid Network](http://www.mutualaidnetwork.org
## Developing "native" Value Flows apps
The other, possibly more interesting direction, is developing new tools where the value flows vocab and protocols are "native", and composing systems out of those VF-native apps, or using them to interact with each other.
-That was the original idea of the Open Apps Ecosystem. The current examples of this direction are Holodex, Personator, and the Linked Data Browser.
+That was the original idea of the [Open App Ecosystem](https://www.loomio.org/g/exAKrBUp/open-app-ecosystem).
-Following this direction, we will need to figure out the sweet spots for component size and shape for Value Flows Open Apps. If we do that well, many people should be able to create variations on any of the components, and they might be able to work together with any of the other variations. (Depending on devils in details...)
-
-### Two possible patterns of native VF apps:
-
-#### Composing bigger apps from many smaller apps
-
-This means assembling a bunch of smaller apps into some kind of whole, like a network resource planning or social network platform made out of many components, but presenting themselves to users as a unified system.
-
-People are doing this now; sometimes called microservices. This is what the [Open Apps Ecosystem](https://docs.google.com/document/d/1lfy9Q2OdssTMPm-mZ23UVDutfsCYhH_z0qz1bpsOfco/edit?usp=sharing) was thinking about.
-
-#### Networks of apps interacting with one another
+Two possible patterns of native VF apps:
+* Composing bigger apps from many smaller apps
+* Networks of apps interacting with one another
-This would be something completely different. For example,
-* Think of the [Personator](https://github.com/holodex/personator) expanded to become your personal agent.
-* It would interact with other personal agents on the open Web.
- * They might form groups, which would be instantiated as a different kind of agent on the Web.
- * Those personal agents and their groups could be visualized by [Holodex](https://github.com/open-app/holodex), but each of the agents and the group would have separate URLs in different domains.
-* They might engage in conversations for action with other agents.
-* Those conversations might result in plans for processes, which would be instantiated as another kind of thing on the web.
- * Each of the agents involved in the process would post events to the process.
- * The process would notify each of the agents about what was happening, what the process required, what had been created, whether it was on schedule or not, etc.
-* Those conversations might result in plans for transfers or exchanges. The exchanges would be instantiated as yet another kind of thing on the web. The transfers might just stay between the giving and taking agents.
-
-The [Indie Web](https://indiewebcamp.com/Projects) is sorta going in this direction, but they are mostly focusing on publishing personal blogs and tweet-style messages. [Portable Linked Profiles](https://github.com/hackers4peace/plp-docs) go farther in that direction.
-
-Email and messaging accounts are probably the personal agents that most people are familiar with. Note the array of extra services that are being added to (for example) Gmail. But all those services live in the Google context, not the context of "your personal agent" (which would be what the Indie Web and PLP gangs would want).
-
-**One main difference** between a system composed of apps vs a network of interactions between personal agents and other things on the open Web, is that the composed system would know you by your user account and login credentials, which would most likely be single-signon. Your personal agent would introduce you to the other agents you interact with. No login, no user account.
-
-**Another interesting use case detailed on another page:** [Provenance](https://github.com/valueflows/valueflows/wiki/Provenance)
+Currently, these efforts are becoming distributed. Some examples are the [HoloREA](https://github.com/holo-rea/holo-rea) project, implementing a ValueFlows framework for economic activity using Holochain; [Commonspub](http://commonspub.org/), implementing ValueFlows as an extension of ActivityPub, thus combining social and economic activity; and a few others.
+Following this direction, we will need to figure out the sweet spots for component size and shape for Value Flows Open Apps. If we do that well, many people should be able to create variations on any of the components, and they might be able to work together with any of the other variations. (Depending on devils in details...)
diff --git a/release-doc-in-process/all_vf.TTL b/release-doc-in-process/all_vf.TTL
@@ -703,15 +703,13 @@ vf:decrement a vf:Action ;
vs:term_status "unstable" ;
rdfs:label "decrement" .
-vf:unload a vf:Action ;
- rdfs:label "unload" ;
- vs:term_status "unstable" ;
- rdfs:subPropertyOf vf:increment .
+vf:dropoff a vf:Action ;
+ rdfs:label "dropoff" ;
+ vs:term_status "unstable" .
-vf:load a vf:Action ;
- rdfs:label "load" ;
- vs:term_status "unstable" ;
- rdfs:subPropertyOf vf:decrement .
+vf:pickup a vf:Action ;
+ rdfs:label "pickup" ;
+ vs:term_status "unstable" .
vf:consume a vf:Action ;
rdfs:label "consume" ;
@@ -755,16 +753,6 @@ vf:service a vf:Action ;
vs:term_status "testing" ;
rdfs:label "service" .
-vf:give a vf:Action ;
- rdfs:label "give" ;
- vs:term_status "unstable" ;
- rdfs:subPropertyOf vf:decrement .
-
-vf:receive a vf:Action ;
- rdfs:label "receive" ;
- vs:term_status "unstable" ;
- rdfs:subPropertyOf vf:increment .
-
vf:raise a vf:Action ;
rdfs:label "raise" ;
rdfs:subPropertyOf vf:increment .
