Skip to content

Home

Jump to bottom
pospi edited this page Nov 14, 2018 · 12 revisions

Welcome to the future home of the REA client application interface.

Background info

This application attempts to be a new frontend to existing 'Open Value Network' client / server apps. Much work has been done on the OVN protocol and related specifications by many contributors too numerous to list here. An extremely brief history goes as follows- follow the links to learn more about the theory and concepts behind OVNs.

  • Early 1980s: Bill McCarthy first defines Resource-Event-Agent (REA) model for accounting systems and publishes many papers on the topic.
  • Mid 1990s: Bob Haugen commercially develops 'Quick Response Engine' & becomes interested in supply chain systems.
  • 1995-2000: Bob discovers REA, he and Bill further develop REA as a semantic model for internet supply chain collaboration.
  • 2000: Verna Allee coins the term "Value Network" to describe and model tangible & intangible economic value within organisations.
  • 2002: ISO adopts REA as their economic and accounting ontology.
  • 2005: Bob begins to write about the importance of expanding REA to cover ad-hoc networks of external economic entities.
  • 2005-2011: Bob works closely with Lynn Foster under the name 'Mikorizal Software' on several open supply chain projects; targeting timber, food networks & fishing industries.
  • 2012: Open hardware manufacturer Sensorica gets involved with REA and coins the term "Open Value Network" (OVN). They develop the Network Resource Planning (NRP) software in collaboration with Bob & Lynn. This is the first iteration of the software on which django-rea and its forks are based.
  • 2013 - Joshua Vial of Enspiral proposes an Open App Ecosystem. Mikey Williams proposes a common method of inter-app communication which settles on Json-LD and Linked Open Data.
  • 2014 - Lynn Foster, Elf Pavlik, Mikey Williams, and Jon Richter start the Value Flows project to develop a common vocabulary for apps in economic networks using Linked Open Data. Other people arrive and help, including Kalin Maldzhanski, Paul Mackay, and Elio Qoshi.
  • 2016: Bill expands upon the concept of an Open Value Network, building on his prior REA model.
  • Q1 2016: Sensorica's NRP software is forked by FreedomCoop and becomes OCP (Open Collaboration Platform). Many updates are made and integrations with digital currencies (FairCoin) begin.
  • Q3 2016: Another fork of NRP is made by GoPacifica and further development continues on that project.
  • 2016-2017 Lynn and Bob join with others to continue work on developing the REA ontology, incorporating learnings from prior projects & concepts, including NRP & OVN, as well as others. The project name is genericised to "Value Flows" and becomes focused on working towards common standards.
  • Dec 2016: Valueflows team members discuss and outline requirements for a modular & community-centered design process around OVN-compatible apps.
  • Q1 2017: Members from GoPacifica, FreedomCoop, Sensorica & Mikorizal begin to collaborate on unifying the multiple forks of NRP to a single generic codebase so that development effort can be shared.
  • Q2 2017: @pospi and @fosterlynn begin the creation of a GraphQL API for the OCP system. They ensure to the best of their ability that the GraphQL additions do not cause heavy changes within the original NRP codebase, so that the GraphQL API can easily be merged back in to the original NRP project if desirable. @ivanminutillo begins creating React-driven interfaces for the data exposed by GraphQL, and a new breed of REA-capable software is born.
  • Oct 2018: @ivanminutillo publishes an outline of an economic markdown syntax & grammar which may be used to describe complex economic processes and commitments from simple interactions.
  • Q4 2018: @sqykly begins prototyping a Holochain implementation of an REA system. @ivanminutillo re-aligns his interface work built for the client/server NRP system to work on top of @sqykly's Holochain APIs, with help from @pospi in creating GraphQL protocol glue.

General roadmap

This project is a continuation of the refactoring / genericisation work already started on the NRP codebase forks with the ultimate aim of bringing the focus of all projects back together and reducing effort required by all parties. It has three broad general aims:

  1. To iterate the frontend design of NRP, OCP & DEEP and achieve a more approachable and user-friendly interface to the software.
  2. To create a bedrock of modular, reusable UI components which can be recycled and adapted by other projects wishing to build interfaces to OVN systems.
  3. To further the understanding of the ValueFlows vocabulary and create more formal descriptions of higher-level concepts.

1. New user interface

The main goal here is to create a modern and beautiful web app which can target a variety of platforms. To achieve this, we've chosen to use React for its simplicity, large ecosystem of contributors, modular design philosophy and platform-agnostic architecture.

The core app will be built to work across web, mobile and desktop environments; and all will share the same codebase. Platform-specific features will be implemented using Webpack loaders to import different modules at compile-time (simply name components as *.js, *.android.js, *.ios.js etc). Areas of the application which will need to target specific platforms include:

  • Views (src/components). Web-based views are implemented by default; equivalent mobile app views are implemented with React Native components. By working at the component level it becomes much simpler to create consistent interfaces across the different platforms.
  • Routing (src/routes.js). React Router handles all routing for the app when run on the server (to pre-render pages) or in the browser. In native versions we will probably use the native version of react-router rather than the built-in Navigator classes of react-native for consistency with the web-based apps.
  • Build system. The React Native build system is far more complicated than a web build, but can easily coexist alongside it. Desktop apps can be built using Electron using the same source files as for web. There will be subtly different Webpack configurations for the web, mobile and desktop apps; but all will share the same core configuration. In this way we should be able to setup multiple NPM scripts to target the different platforms that are easy enough for anyone familiar with the tools to run.

For more info on some of the libraries and techniques used in this app, see learning material.

2. Modular UI components

You can find more info on the UI component architecture and design philosophy at UI Component Architecture.

3. ValueFlows vocabulary and APIs

A part of developing this project will be expanding the API component of the OVN apps to expose the necessary data. The plan is to use this process as a way of surfacing the key information required to run an OVN system; as well as exposing more of the Valueflows vocabulary in a formal implementation that is self-documenting and true to the model.

It is expected that a GraphQL-based API is the most appropriate approach for fulfilling these requirements. It would give us built-in support for easily querying entity relationships across relationship graphs, a concept that the OVN apps are heavily based on. The work has been started in a feature branch of OCP but has a very long way to go! django-graphene offers us the following possibilities:

  • Distinct binding between graph types and internal models, to provide insight into how external entites from the Valueflows vocabularies map to internal OVN system types, database tables etc.
  • Custom filtering keywords and logic can be bound to graph types, which allows us to easily build up useful searching options on top of the raw data structures.
  • Entity relationships are also defined in the graph types, providing detailed and accessible insight into the wider structure of the Valueflows vocabs and OVN system core.

We should also attempt to use the API to generate RDF-compatible output so that it can become the central resource for communicating data between multiple OVN apps located on different servers- though this may be better done by other means more directly provided by Graphene.

On the client side, things can be integrated relatively easily with Apollo, or GraphQL requests can be sent as regular POSTs and the response data managed manually if necessary. We probably wouldn't choose Relay due to its opinionated conventions and separation from Redux- Apollo looks easier to integrate with client-side application state.

About this codebase

For new contributors

Clone this wiki locally