Digital Financial Reporting

I updated my ontology spectrum graphic that I explained in another blog post. Here is the updated version:

 (Click image for larger view)

One thing worth noting is that a big shift occurs when relatins are defined formally as opposed to informally (the red zig zag in the diagram).

(Disjunction | Transitive | Is-a | Has-a | Part-of | Part relations | Logic gates | Cardinality | Class | Subclass)

As I said in the previous blog post, the graphic above was inspired by this graphic (see slide 4) and some of these other graphics.

In addition to updateing the graphic, I mapped that ontology spectrum to implementations in two technology stacks: XBRL and the Semantic Web Stack.  Recall this blog post where I point out the need for a unifying logic and compare/contrast the XBRL and Semantic Web stacks.

Here are the mappings from the ontology spectrum to:

• XBRL mapped to ontology spectrum
  • XBRL Specifications
• Semantic Web Stack mapped to ontology spectrum (This paper explains the implementation but the paper is 10 years old and does not reference SHACL; see this related to rules)
  • RDFS
  • SKOS
  • RDF | RDF XML | RDF Turtle | RDF N-Triples | RDFa  | JSON LD
  • RDF Data Cube Vocabulary
  • OWL 2
  • SWRL
  • SHACL
  • RIF | RIF and OWL compatability | RIF Framework for Logic Dialects | RIF Basic Logic Dialect
  • DCAT

As I understand it, it is the intent of the Standard Business Report Model(SBRM) to support either technology stack.  This is my view as to what the SBRM will end up looking like. I could be wrong, it is not complete.

What people tend to misunderstand is that the application you are trying to create picks where you need to be on the ontology spectrum.  You don't get to pick.  The level of quality, precision, accuracy, breadth, depth, and leads to a some required level of expressiveness that you need to make your application work effectively.  Impedance mismatches between what you need and what you provide causes problems.

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

Class relations defined using XBRL

Properties defined using XBRL

AI is taxonomies and ontologies coming to life (NOT like humans learn)

See the section "Common Components of Ontologies" in this article

Demystifying the role of ontologies

Framework for evaluating ontologies

Ontologies and fault management (NASA, very good!)

AI - Externalization of Mind (Slide Share)

Demystifing Ontology

In prior blog postsI have pointed out that XBRL Formulas have some specific deficiencies. One of those deficiencies involves chaining.  XBRL Formula processors cannot do forward or backward chaining.

Well, there is a way you can achieve a similar result using XBRL Formula.  What you can do with an XBRL Formula processor is "chain" a process together.  Now, you have to put everything in the right order because XBRL Formula processors cannot do forward or backward chaining as I have pointed out.

The objective is to duplicate these fundamental accounting concept relations continuity cross checks. All of these Excel extraction tools similarly use sequential processes as opposed to forward or backward chaining.

Here is how you do that validation using XBRL Formula:

• Step 1.  You have an XBRL instance. That XBRL instance has 12 facts.
• Step 2: You feed that XBRL instance in Step 1 to an XBRL processor as input; you also provide these XBRL Formulas linkbases:
  • formula-Impute-PullFactsForward.xml(this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-EquityAttributableToNoncontrollingInterest.xml(derive the value for Equity Attributable to Noncontrolling Interest from existing information)
  • formula-Impute-NoncurrentAssets.xml(derive the value for Noncurrent Assets from existing information)
• Interim result A: You get this resulting XBRL instance.  (human readable) That XBRL instance now has 16 facts.
• Step 3: You take interim result A and use that as input; you also provide these XBRL Formula linkbases:
  • formula-Impute-PullFactsForward.xml (again, this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-Equity.xml (derive the value for Equity from existing information and previously derived information)
• Interim result B: You get this resulting XBRL instance. (human readable) That XBRL instance now has 18 facts.
• Step 4: You take the interim result B and use that as imput; you also provide these XBRL formula linkbases:
  • formula-Impute-PullFactsForward.xml (again, this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-Liabilities.xml (derives the value for Liabilities from existing information and previously derived information)
• Final result: You get this resulting XBRL instance. (human readable) That XBRL instance now has 20 facts.
• Consistency checks: You take the final result; you also provide these XBRL formula linkbases:
  • fac-formula-BSC.xml (value assertions which check the consistency of reported fact with expectations)
• Consistency checks validation result: This is the ultimate validation result in human readable form.

And there you have it! While it is true that a human has to string the rules together in the correct order and that this process is not that effecient because you have to reload XBRL instances multiple times; this process does work and so it is effective.

What this example also clearly demonstrates is that there is a use case for deriving facts that were not reported so that consistency checks can be executed.  If it is the case that information about unreported facts cannot be determined, the XBRL instance is fundamentally unusable by automated processes.  At the same time, this shows that information can be used by automated processes since you can chain the process together effectively.

I have run this or had this run through the UBmatrix and Fujitsu XBRL Formula Processors.  I am going to try and get this run through two more processors to confirm that this works consistently.

People are starting to value quality. In an excellent article, A New Approach to Data Quality: Preparing for a RegTech, SupTech and AI Future, DFIN Solutions (Donnelley) make two important points.

The first point is this: (emphasis is mine)

Global reporting and compliance have remained document-bound for too long. With recent advances in artificial intelligence (AI) and other forms of machine learning, however, companies are poised to meet their regulatory and compliance requirements in completely new ways.

The article points out that humans are no longer the primary consumers of information.  For example, the SEC says that 85% of the documents visited in their EDGAR filing system are machines.

Second, they say is to make quality paramount. The article goes on to give numerious specific ways to improve the quality of reported information.  Why is the need for quality so important?  Because machines are dumb and if the information is not of high quality, the information those machines are using is basically garbage and not usable.

In an excellent article, 2019 AI Predictions: Six AI priorities you can’t afford to ignore, PriceWaterhouseCoopers provides good, practical advice about how artificial intelligence should be approached by business professionals.