Entering the Era of the Knowledge Graph

The article by Dan McCreary, Knowledge Graphs: The Third Era of Computing, points out that we are entering a new era in computing.  Interestingly, the article starts out explaining that "computing" began about 5,000 years ago in around 3,000 BCE when accountants created what amounts to the first knowledge graph in the form of facts stored in the rows and columns of a table on a clay tablet.

Those clay tablets were replaced by papyrus scrolls; the papyrus scrolls were eventually replaced by paper; and the paper, as the author puts it, was replaced by tables in a relational database of an enterprise resource planning (ERP) system that could be processed using COBOL which was an early computer language used for processing business information.

Further, as pointed out by the article, accountants demanded ultra high quality in their representations and a clever Italian accountant figured out that if you used two independent but synchronized representations and as part of your control process you compared the two representations you could better control the information and reduce the potential for errors and also differentiate an unintentional error from an intentional error (a.k.a. fraud).  Luca Pacioli documented this mechanism which is now a global standard referred to as the Venetian Method of double entry bookkeeping.

(As a bit of a side note, in referencing this article I ran across an article describing the Florentine Approach to accounting which appears to be slightly different than the Venetian Approach/Method.)

A big difference between how things have been done during the past 50 years of computing and how things will likely be done in the next 50 years is an increase in the declarative approach to programming and less use of the imperative approach to programming.

In imperative programming, code is written and the business logic used by the code is included within the code.  In declarative programming, the business logic is separated from code and stored separately.  That means the business rules (a) can be reused by other code and (b) the business rules can be maintained by business professionals rather than computer programmers.  

This declarative approach of separating code and rules is advocated by The Business Rules Manifesto. This is just one of the big changes between the current era of computing and the new era of computing which we are evolving to.  There are other specific changes.  In the video, Knowledge Graph Seminar Session 9, and engineer from Inuit explains how Intuit is embracing this new era of computing.  At minute 23, that developer shows this graphic which summarizes other changes. (Note that "procedural" is a type of imperative programming and "knowledge graph" means that the declarative business rules are stored in the form of a knowledge graph.)


One thing not listed in that table above is the notion that rather than writing a bunch of IF...THEN statements and hooking statements together using logic gates (AND, OR, NOT, etc.) a BUSINESS RULE ENGINE or logic processing engine or semantic reasoner would be used to process the business logic.

Anyway; lots going on!

In writing this article I recognized that I could be wrong about something.  So my notion of two separate representations, or knowledge graphs, might not be necessary to achieve what double entry bookkeeping provides.  One knowledge graph and a compete set of declarative business rules might provide the same capability.  I think that the knowledge graph plus the declarative business rules could be referred to as a theory.  That is how PROLOG and DATALOG appear to work, using a theory.

So there is an entire series of videos available that explain knowledge graphs available in this YouTube playlist; Knowledge Graphs Seminar.

Additional Information:

Comments

Popular posts from this blog

Getting Started with Auditchain Luca (now called Luca Suite)

Relational Knowledge Graph System (RKGS)

Professional System for Creating Financial Reports Leveraging Knowledge Graphs