Digital Financial Reporting

I think I have all this figured out, then I learn more and I recognize that I still do not have it totally figured out.  I am trying to figure out the best logic to use to process XBRL-based digital financial reports.  This blog post explains where I stand now. 

Figuring out which logic to use is a "dance" between expressivity and tractability, trying to get the right equilibrium for the task being performed.  The logic needs to be as powerful as possible but also as reliable as possible (i.e. controllable).

Nothing has both the maximum expressivity and maximum control. What I do know for certain is that an "ontology" alone is not enough.  You need "ontology + rules".  SQL alone does not seem to be enough but I am not 100% sure.  XBRL Formula alone is not enough, certain specific things are missing. More needs to be added to SQL or XBRL based systems to get them to work effectively.

My confidence is pretty high that all of the following seem to provide enough logic, but most also have specific known control issues associated with them: 

• Ontology + Rules (knowledge graph):  For example, OWL (or SWRL) + RDF (or N3) + SHACL provide sufficient fragments of first order logic. (Some call this Modern Symbolic AI)
• Modern Prolog:  Prolog such as SWI Prolog or Scryer Prolog seem to have all of the necessary functionality.  The up side is that there are a lot of Prolog implementations. The down side is that none of these Prologs can call it self "the standard". Each has pros and cons. Prolog interoperates with relational (SQL) databases.
• ISO Prolog: ISO has created a standard Prolog.  ISO Prolog can be regarded as a subset of Full Prolog.  There is solid motivation for implementations to support ISO Prolog as the international standard Prolog, many already do to one degree or another.
• Datalog: Datalog, or "function-free Horn Logic", is more tractable than Horn Logic (Pure Prolog) and ISO Prolog (Full Prolog). RuleML.org points out,  “Datalog is the language in the intersection of SQL and Prolog. It can thus be considered as the subset of logic programming needed for representing the information of relational databases, including (recursive) views.” So Datalog interoperates with relational databases. (Then there is Vadalog which is a modern version of Datalog.)
• PSOA RuleML (multi-paradigm): PSOA (Positional-Slotted Object-Applicative) RuleML is a multi-paradigm, particularly graph-relational, data and rule language. PSOA interoperates with relational databases and graph databases (including labeled property graphs). RuleML.org points out, “PSOA RuleML's databases (fact bases) generalize the instance level of Graph and Relational Databases; its knowledge bases complement facts by rules for deductive retrieval (extending the Datalog-level, function-free expressiveness of Deductive Databases to the Horn-logic expressiveness of Logic Programming), interoperation, and reasoning, as well as for optionally emulating part of the schema level.” Here is a PSOA tutorial.
• GQL/Cypher (labeled property graph): GQL is an ISO project to create a global standard query language (like SQL) for graph databases, graph query language.  Open Cypher which is based on Cypher which is the query language of Neo4j.
• XBRL+SBRM+More: XBRL  is an open standard technical syntax published by XBRL International, SBRM  is a forthcoming standard to be published by OMG that formalizes a logical conceptualization of a business report.  While XBRL provides the functionality to represent all that is needed to express knowledge and much of what is necessary to process that knowledge and prove the knowledge is represented correctly.  However, certain specific processing is missing that must be supplemented to create a complete system.  As such, that additional processing logic must be provided.
• SQL+More (relational database): While it is proven that you can store XBRL-based information in a relational database; you have to add functionality to process the information.  Essentially, you have to construct a rules engine to process the information and prove the system is properly functioning.  This is very possible but tends to not be very effecient.

There are other logics that can be used to process XBRL-based digital financial reports. Other completely different approaches such as the decision model approach could possibly be used but would need to include an ontology-type component.  Any syntax used should be 100% convertible to all other syntaxes and be able to round tripped back into the original syntax.  Then, you could switch between whatever approach.

I can tell you this.  "Rolling your own" system like we did for Pesseract is expedient for many things, but is significantly less powerful and it would be hard to compete with any of the approaches above in terms of power.  The specific pieces missing from XBRL Formula can be added.

For a more comprehensive analysis, please see here.

Taxonomies, Ontologies, Knowledge Graphs

Graph Databases will Change your Freakin' Life

Graph Databases: The best kept secret for effective AI

Robert Kowalski: Algorithm = Logic + Control

This link has the full paper.

Automation is defined as, "Automation is the technology by which a process or procedure is performed with minimal human assistance."

Algorithms is how automation is implemented.

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