Digital Financial Reporting

In a RuleML technical memo; Graph-Relational Data, Ontology, Rules; Harold Boley points out that there tends to be three general paradigms for problem solving using machines: knowledge graphs, graph databases, and logic programing.  In that paper he provided a graphic that showed the intersections of these three paradigms.

The following is an enhanced version of that same graphic.  Dr. Boley helped me make the adjustments.  Different organizations use different problem solving paradigms.  In fact, within many organizations different paradigms are used.  So how do you cross between different paradigms? RuleML's PSOA helps with that.

Saying the same thing in a different way; different people and organizations have different preferences in how they store, retrieve, process, and make available information.  Those different approaches can be grouped into those three categories.  But effectively, you are using "data" and "ontologies" (or ontology-like things) and "rules".  You are storing information in the form of a "tree" (a graph really) or a "table" (a database).

(Note that different people use different terms to describe the same thing or what could be different things; I may be using terms in different ways than you are used to so I am describing each term in detail) 

• Knowledge graphs: By knowledge graph I am specifically referring to the W3C semantic web stack. This approach uses RDF, SWRL, OWL, N3, SHACL, SPARQL, and other such W3C standard technologies for representing data, ontologies, and rules.  Other terms for this are enterprise knowledge graph. One top knowledge graph vendor is TopQuadrant.  This is TopQuadrant's description of knowledge graphs.
• Graph databases: By graph databases I am specifically referring to graph databases that will ultimately support the forthcoming ISO standard graph query language (GQL). I am pretty sure this means labeled property graphs such as Neo4j.  But it might mean something else; here is a list of software vendors that seem to be behind ISO standard graph query language. The GQL Manifesto is a good explanation of what is going on here.
• Logic programming: By logic programming I am specifically referring to Modern Prolog on top of relational (SQL) databases. By Modern Prolog I mean SWI Prolog or Scryer Prolog or something similar that is both safe and powerful. This Wikipedia article on logic programming describes this paradigm. Note that Answer Set Programming (ASP) is included in the logic programming paradigm.

So what PSOA RuleML does is tie these paradigms together. PSOA RuleML is a "translation" or "bridging" mechanism.  Because each of the three paradigms above use different terminology, structures, association types, rule types, and other such philosophies, there needs to be some sort of "Rosetta Stone" to tie things together.

Remember the days before the internet when there was no one global standard network protocol?  That all changed with the invention of the Web Browser.  See this history of the Internet.

TCP/IP was not necessarily the "best" network protocol, but it worked and everyone ultimately agreed with and supported that standard.  It is that agreement that created the magic of the Internet and World Wide Web.

Will people ultimatly agree on some standard problem solving paradigm?  Maybe, maybe not.  Does there need to be only one? I don't know. 

What I do know is that I have been able to represent XBRL-based financial reports using all three of these paradigms and convert from one paradigm to another.  Effectively, the SEC's implementation of XBRL, the ESMA's implementation of XBRL, and the SBRM implementation of XBRL (a) fit into that PSOA RuleML intersection box and (b) can be used to create a provably properly functioning logical system.  The SEC, the ESMA and SBRM all avoid potential problem areas plus XBRL effectively supports the creation of "data", the creation of "ontologies", and the creation of "rules".  XBRL is powerful enough for financial reporting and it can be made to work by, for example, following my method. This is provable and I have proven it effectively. Further, these same ideas can be applied to nonfinancial reporting use cases.

Properly functioning technology makes things seem to work like magic.  But, there is really no magic.  For example, consider the OSI model. You use that model every day if you use a computer.  You very likely take the OSI model for granted, if you even understand what it is and what it does.

XBRL-based digital financial reporting and in fact computational professional services will ultimatly work as well.  Why do I know that?  Because it has to.  If it does not, then it simply will not be useful and therefore it will not be used.

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

Note the intersections between Knowlege Graphs and Logic Programming in the diagram above. These documents help understand that: An Introduction to Prolog and RDF; Comparison of Prolog and RDF.

Note the intersections between Graph Databases and Knowledge Graphs in the diagram above: RDF Triple Stores and Labeled Property Graphs: What's the Difference?; Comparison; Knowledge Graphs vs Property Graphs;

Note the intersections between Logic Programming and Graph Databases in the diagram above: A Graph DB vs Prolog; 

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

Property Graphs: Training Wheels on the Way to Knowledge Graphs

Alan Morrison's comparison of the pros and cons of property graph databases and RDF/OWL triplestores

Contrasting PROLOG and Graph Databases

GQL Manifesto

Knowledge Graphs at a Glance

Neo4j vs Grakn Part 1: Basics

Neo4j vs Grakn Part 2: Semantics

KgBase Knowledge Graph (Requires Chrome)

Method of Analytic Tableaux

The Evolution of Semantic Abstraction

Grailog Visualizations

Serenity prayer:

“God grant me the serenity to accept the things I cannot change, courage to change the things I can and the wisdom to know the difference.”

ISO describes IS0 20022, Universal Financial Industry Message Scheme, as "A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives."

The web page above also says:

It describes a common platform for the development of messages using: 

• a modelling methodology to capture in a syntax-independent way financial business areas, business transactions and associated message flows
• a central dictionary of business items used in financial communications
• a set of XML and ASN.1 design rules to convert the message models into XML or ASN.1 schemas, whenever the use of the ISO 20022 XML or ASN.1-based syntax is preferred 

This PowerPoint Introduction to ISO 20022 provides additional information. This is another piece of the computational professional services puzzle!

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

RuleML as a Knowledge Interoperation Hub

RuleML as Knowledge Interoperation Hub

RuleML as Knowledge Interoperation Hub (Slides)

Graph-Relational Data, Ontology, Rules

XBRLogic.com published their quality measurements for XBRL-based financial reports submitted to the SEC for the second quarter of 2020: (click image for larger view)

XBRL Cloud's Edgar Dashboard does not summarize this information, but you can get the details.  Seems like there are many who can benefit from my method of creating high quality XBRL-based financial reports.

The "bolt on" approach to implementing XBRL-based reporting was doomed from the beginning becuase it made absolutely nothing better, faster, or cheaper.  All it did was add more work to existing processes.

Computational professional services is a new approach, in fact it is a completely new paradigm. Some call it "smart regulation", others "algorithmic regulation", others "rules as code", and still others "robo cop".  To make this work, accountants don't need to "learn to code".  Software engineers need to learn to build the right software; software business professionals can realistically use, be effective, maintain their high quality standard.

Here are four different user interface ideas for enabling business professionals to actually use computational professional services.  You have to use your imagination here.  Each of these interfaces is too low a level.  The actual interface I am contemplating is driven by a higher-level metamodel and pre-created metadata.  These simply shows the fundamentals of interacting with "building blocks".  The trick is to have the correct level of building block to interact with and the correct visual image. 

• Scratch: This is a browser based version of the MIT project that started it all.  Here is a tutorial.
• Blockly: This is a browser based version of Blockly which was inspired by Scratch. In my view, this is two levels of abstraction away from what business professionals would use.  Maybe three. The Block Factory lets you construct blocks. Here is information relating to block creation.
• Blawx: This is a browser based version of something based on Blockly which is connected to a logic engine.  This actually works.
• Make Code: This is a browser based version of Make Code which is very similar to Scratch.  Again, this is too low a level, business users would work with higher level models.  Two and maybe three additional levels of abstraction are necessary to get to where you would want to be. (Make  code playground)
• Waterbear: Another alternative, does not seem that great.

So, something inspired by the UI that you see above would be linked to some logic/rules engine.  Here are candidates for such a logic/rules engine: (for details see here and here) 

• OWL/SHACL/RDF (i.e. knowledge graph) using something like TopBraid
• SWI Prolog or Scryer Prolog
• Cypher/Neo4j (i.e. labeled property graph)
• Ergo AI (proprietary logic system)
• Build your own rules engine on top of XBRL Formula (i.e. XBRL Cloud did this)
• Create your own rules engine (i.e. Pesseract)
• Decision model approach (business rules management system)

The actual interface would look more like this; this is what the UI pieces might look like: 

• Pesseract: This is a working proof of concept which has a dynamic interface. (more information)
• XBRL Cloud: This is a static interface but it helps you see what the objects business users would work with.  (here are more examples)

The Logical Theory Describing Financial Report (i.e. SBRM eventually) provides the high-level metamodel for financial reports.  It is those objects that a business user would interact with in the user interface.  That would be driven by metadata that fits into that metamodel, this can be exemplified by the US GAAP Financial Reporting metadata.

All these different layers are tied together.  Technical complexity is buried deep within software, business users interact with high-level logical things that they understand.  Here is a bunch of information which summarizes testing that I have done.

And that is how computational professional services can be implemented. This is a straight forward engineering design process.  If you need more details, look here.  There are no short cuts. Use your imagination, but you have to make this realistically usable by business professionals with a complete set of capabilities that allow business professionals to succeed.