Digital Financial Reporting

The following is a summary of the business case for PROLOG that I have gleaned from various other sources including this and this and this and this. 

• Modern implementations of Prolog (PROgramming LOGic) are based on technology that has been around for over 40 years.  Prolog has a long, proven track record.
• Prolog is an ISO standard. There is a core set of Prolog notation which tends to be provided by most Prolog systems and there is now an ISO standard for that specific subset of the language.
• The Prolog relational paradigm fits well with tabular data such as that within a relational database management system (RDBMS), while optimized support for recursive code fits well with graph or "tree" shaped information such as RDF or graph databases.
• Prolog reduces development costs and maintenance costs.  With declarative logic programming languages like Prolog, code is generally more reusable, business logic can be separated from program flow logic, Prolog code is more readable than languages like Java or C++ or C#, and therefore software maintenance costs (which can be 60% of total development cost) is significantly reduced.
• Prolog is Turing complete. Turing complete means reliability and predictability. While most programming languages these days are Turing complete, they may not be used that way.
• There are 20 different Prolog implementations.
• Free versions of Prolog exist such as SWI Prolog. Open source Prolog implementations exist.  There are many, many open source Prolog related projects.
• Here are other specific Prolog features.

Prolog is not a tool business professionals would ever be exposed to.  Business professionals would be exposed to high-level interfaces that they understand and can work with.

As pointed out in the article, Building a Custom Rules Engine with Prolog, there benefits to using the right tool for the right job. Here are some exerpts from that article: 

The primary problem was that the flow-of-control branching if-then statements of a procedural language did not have the same semantics as the pattern-matching if-then rules of logical relationships. Developers must make arbitrary decisions of where in the flow-of-control to code each branch, thereby entangling the declarative rules in the thread of execution.

This is clearly an advantage over the procedural approach, and also a big advantage over rule-based approaches that do not provide ontologies. In a pure rule-based approach, these definitions would all have to be implemented as rules. Having the writers of the rules stick to a limited vocabulary doesn't work because so many different vaccines and spellings appear in the medical records. It is the ontology that makes it practical to use the existing medical records.

Unlike factual or procedural knowledge, logical knowledge is difficult to encode in a computer. However, the ability for organizations to successfully encode their logical knowledge can lead to better services for users. The question, then, is how best to encode logical knowledge. It can be shoe-horned into data- and procedure-based tools, but the encoding is difficult, the knowledge becomes opaque, and maintenance becomes a nightmare. Rule-based and logic-based tools are better suited to the encoding of logical knowledge, but require the selection of the proper tool for the knowledge to be encoded, and the learning of how to use that tool. Off-the-shelf rule or logic tools sometimes provide a good solution, but often the knowledge representation of the tool doesn't fit the actual knowledge, or the reasoning engine doesn't use the knowledge as it is supposed to be used. This leads to the same coding and maintenance problems experienced with conventional tools, but to a lesser extent depending on how big the semantic gap is between the knowledge and the tool.

A viable alternative is the building of a custom logic-based language and reasoning engine. This allows for the closest fit between the coding of the knowledge and the actual knowledge, and for the cleanest integration between the tool and the rest of the application context.

Specialized tools are easier to use that general tools.

An example of using PROLOG is PROLEG which is programming logic for the legal industry.  PROLEG is described as an "interactive system for arranging issues". This video, Introduction to PROLeg, and this paper, PROLEG: An Implementation of the Presupposed Ultimate Fact Theory of Japanese Civil Code by PROLOG Technology, and this paper Introduction to PROLEG provide examples of the capabilities of PROLEG.  Effectively, this seems to be a specialized subset of Logical English.  This is very likely how financial reporting rules will be written in the near future.

Prolog seems to be a possible candidate for the unifying logic framework for business that I was seeking.

##########################

Have you Heard of PROLOG?

Fifty Years of PROLOG and Beyond

PROLOG at 50

2022: The Year of Prolog