commit ac6376282a9a6f05a434679ba8e283eaafcb2623
parent 0736de90fd4dec65d6def3b675cd83b1376052a9
Author: Lynn Foster <foster.j.lynn@gmail.com>
Date: Fri, 16 Aug 2019 15:16:28 -0500
more minor fixes (#561)
* fixed actions in ttl
* Changes in response to @bhaugen review of whole doc
* more small fixes
Diffstat:
5 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
@@ -35,6 +35,7 @@
* [External terms](specification/external-terms.md)
* [Classes and Properties](http://www.essepuntato.it/lode/owlapi/https://raw.githubusercontent.com/valueflows/valueflows/master/release-doc-in-process/all_vf.TTL)
+* [Graphql Reference](https://github.com/valueflows/vf-graphql/tree/master/lib/schemas)
## Examples
diff --git a/docs/introduction/core.md b/docs/introduction/core.md
@@ -4,7 +4,7 @@ The vocabulary has a core that would fit many different kinds of economic format
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.
+ValueFlows takes the "independent view" of REA, which is a neutral viewpoint in the "collaboration space" between agents. The "trading partner view" happens internal 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/flows.md b/docs/introduction/flows.md
@@ -69,16 +69,16 @@ All flows use an action property to designate what the flow is doing and how it
Action | Affect | I/O | Changes existence | Pairs with |
------ | ------ | --- | ----------------- | ---------- |
produce | Increment | Output | Yes | N/A |
-consume | Decrement | Input | Yes | N/A |
+consume | Decrement | Input | Yes | N/A |
use | No effect(1) | Input | No | N/A |
-work | No effect(1) | Input | N/A | N/A |
+work | No effect(1) | Input | N/A | N/A |
cite | No effect | Input | No | N/A |
-pickup | No effect | Input | No | dropoff |
-dropoff | No effect | Output | No | pickup |
-accept | No effect | Input | No | modify |
-modify | No effect | Output | No | accept |
-pass | No effect | Output | No | accept |
-fail | No effect | Output | No | accept |
+pickup | No effect | Input | No | dropoff |
+dropoff | No effect | Output | No | pickup |
+accept | No effect | Input | No | modify |
+modify | No effect | Output | No | accept |
+pass | No effect | Output | No | accept |
+fail | No effect | Output | No | accept |
transfer-custody | Decr+Incr(2) | N/A | No | N/A |
transfer-all-rights | Decr+Incr(2) | N/A | No | N/A |
transfer-complete | Decr+Incr(2) | N/A | No | N/A |
diff --git a/docs/introduction/resources.md b/docs/introduction/resources.md
@@ -21,7 +21,7 @@ is a specification. Your library may have two copies that you can check out. Tho
#### The difference between a resource specification and a resource classification
-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 only one *resource specification* in ValueFlows. This defines the lowest level useful type or kind of the resource that is needed. The ValueFlows vocabulary defines this as the ResourceSpecification. Note that often taxonomies and other references on the web can define very specific resource specifications at their leaf levels, and these can be used if the necessary properties can be found.
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.
@@ -71,8 +71,8 @@ Note in the last case, a transfer of rights means a different resource. This is
##### Stage and state
Sometimes part of the logical identification of a resource includes:
-* stage: the ProcessSpecification of the most recent process the resource was output from, with the `modify` action
-* state: the Action (`pass` or `fail` only) of the most recent economic event the resource was output from
+* *stage*: the ProcessSpecification of the most recent process the resource was output from, with the `modify` action
+* *state*: the Action (`pass` or `fail` only) of the most recent economic event the resource was output from
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.
@@ -94,7 +94,9 @@ Two different kinds of "inventorying" of resources are affected by transfers.
* quantity of the resource where the agent has full (human realm) rights and responsibilities, irrespective of custody
* quantity of the resource where the agent has custody or physical possession, irrespective of rights, more of an operational focus
-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.
+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 so they see it 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.
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.
diff --git a/docs/introduction/status.md b/docs/introduction/status.md
@@ -19,6 +19,8 @@ Other relatively consolidated parts of the vocabulary include:
Less stable are:
* Intents and Proposals
* Budgeting and Analysis
-* Recipes - forking/versioning
-* Conversations for Action/Agreement
* Claims
+
+Coming in future releases are:
+* Forking/versioning of Recipes
+* Conversations for Action
