vf-apps-recipes issueshttps://lab.allmende.io/valueflows/vf-app-specs/vf-apps-recipes/-/issues2021-11-11T11:55:54Zhttps://lab.allmende.io/valueflows/vf-app-specs/vf-apps-recipes/-/issues/2How to publish Recipes in Git repositories2021-11-11T11:55:54ZBob HaugenHow to publish Recipes in Git repositories**Preliminary comment:** Valueflows Recipes are still work in process. We have a lot of learning from the [Recipes in the NRP project](https://speakerdeck.com/mikorizal/5-nrp-recipe-concepts-and-tutorial), [a collaboration with Sensoric...**Preliminary comment:** Valueflows Recipes are still work in process. We have a lot of learning from the [Recipes in the NRP project](https://speakerdeck.com/mikorizal/5-nrp-recipe-concepts-and-tutorial), [a collaboration with Sensorica](http://nrp.sensorica.co/).
But now we are talking to other projects who may also want something like Recipes. They (and we) want Recipes that can be published and shared in Git repositories, where they can be collaborated on, versioned, branched, forked, and merge pull requests.
Git likes to manage files. The current VF software projects do not produce nice neat files. They use Web user interfaces with HTML Forms where users enter data in form fields which will then go through the VF [GraphQL API](https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/tree/sprout/lib/schemas) and then be stored in (probably relational) databases.
Here's a couple of mockups of two upcoming VF apps. They show UIs for planning, not recipes, but the structure is pretty much the same.
![mockup 1](https://mikorizal.org/VF_UI_Mockup1.jpg)
![mockup 2](https://mikorizal.org/VF_UI_Mockup2.jpeg)
They could also be stored in an RDF format, but nobody is doing that yet. But as you can see, pretty different from text files...
@lynnfoster and I are now talking to people from at least 2 different projects about agreeing on a format for manufacturing documentation:
* [FabCity](https://fab.city/) and
* [GOSH](https://openhardware.science/)
See also our intro wiki page about that conversation, [Recipes vs Bills of Material and Routings vs Resource Flows](https://lab.allmende.io/valueflows/valueflows/-/wikis/Recipes-vs-Bills-of-Material-and-Routings-vs-Resource-Flows).
Julian Stirling from GOSH has developed a project called [GitBuilding](https://gitbuilding.io/) which uses a markdown file-based manufacturing documentation format called BuildUp.
I think GitBuilding can cover most of the requirements for VF:Recipes. Here is an example:
https://build.openflexure.org/openflexure-microscope/v7.0.0-alpha1/high_res_microscope.html. Here is another: https://gitbuilding.io/usage/complex-projects.
So then what I think will be needed is program functions to export the Recipes created in Web UIs to GitBuilding files, and then to import GitBuilding files back into VF Recipe apps, where people can use the nice UIs with dropdown selections of components and validations of entries.
We already have Python code in the Vocabulator to output several formats including Yaml, a text format that we use a lot for examples: http://valueflows.pythonanywhere.com/
Buildup could be another.
Does this make sense to everybody?https://lab.allmende.io/valueflows/vf-app-specs/vf-apps-recipes/-/issues/1How to model recipes in ValueFlows2018-07-30T20:54:22ZBob HaugenHow to model recipes in ValueFlowsA starter or suggested model, with some questions:
![recipe-plan-observation](https://rawgit.com/valueflows/valueflows/master/release-doc-in-process/process-layer.png)
(Some of those names have been changed, so I'll use the new nam...A starter or suggested model, with some questions:
![recipe-plan-observation](https://rawgit.com/valueflows/valueflows/master/release-doc-in-process/process-layer.png)
(Some of those names have been changed, so I'll use the new names in the text and change the diagram later.)
RecipeProcess in the diagram has been changed to ProcessClassification. ResourceCategory has been renamed to ResourceClassification. RecipeInput and RecipeOutput have not been renamed. Yet.
**Basic recipe model:**
A chain or tree or graph of ProcessClassifications with RecipeInputs and RecipeOutputs. One ProcessClassification may be connected to another if the ResourceClassification of one of its RecipeOutputs or RecipeInputs is the same as the ResourceClassification of a RecipeInput or RecipeOutput of another ProcessClassification.
So the basic node in a recipe is a ProcessClassification.
**Variations:**
* Include ExchangeClassifications as nodes so a recipe can encompass Exchanges as well as Processes. That would require something analogous to RecipeInputs and RecipeOutputs for ExchangeClassifications.
* Allow for something like Workflow Recipes in NRP, where the input Resource has the same identity as the output Resource but is changed by the Process. Bill McCarthy calls such resources Carrier Resources. In food processing manufacturing systems, they were called Stream Resources. They need special treatment to differentiate the CarrierResource at one process stage from the same CarrierResource after another process has changed it. NRP used a "stage" property which was a link to the ProcessClassification of the Process that had last changed the Resource. This model has also been used in supply chain planning systems, and is documented in the book [The Haystack Syndrome](https://www.goodreads.com/book/show/1032538.The_Haystack_Syndrome).
![nrp recipe tutorial 1](https://user-images.githubusercontent.com/117439/43370898-09d8495a-934d-11e8-90bf-bbc6b25284f8.png)
This type of recipe in NRP was originally designed for translations, as in this example:
![nrp recipe tutorial](https://user-images.githubusercontent.com/117439/43370908-33c74c02-934d-11e8-84d8-c7d6b80926f3.png)
They have subsequently used a lot by Sensorica for organizational processes.
**Major design question:**
Should a recipe have a container class, probably called Recipe, that is connected to a set of recipe nodes? Such a container is not necessary. NRP does not have one, you can start a recipe in NRP from any output ResourceClassification and a ProcessClassification that can create it, and you can traverse for display or planning purposes from the ProcessClassification through all of its RecipeInputs to other ProcessClassifications where the ResourceClassification of the first ProcessClassification is specified in a RecipeOutput.