Human Readable Knowledge Graph of Business Report Model

The following is my best effort to define the knowledge graph of a business report from multiple interoperable technical implementations including:

A business report, including financial reports, are composed of blocks of information that can be identified as specific "disclosures" or in the case of financial reports, financial disclosures.

(Image from Wikicommons)

This same business report model was implemented by five different software vendors and are interoperable.  

However, there are three issues with my business report model that I am aware of.  First, the model has an XBRL bias.  I  don't understand how to remove that bias or I would.  Second, I am not an information technology professional or knowledge engineer so I don't have professional skills related to building sound models.  This is basically the best that I could do given my understanding of XBRL, financial reporting, and how to create a knowledge graph. Third, while this model works well for the "financial report" level of granularity and what I call the "mezzanine level" of accounting working papers and audit schedules; it is not "elegant" when it comes to explaining business events or the accounting transactions that represent those business events.

Someone endeavoring to "see" this model, can use this Auditchain viewer of the PROOF business report.  This is what I have:

  • Business report
    • Base information
      • Code (local or imported schema)
      • Namespace prefix
      • Namespace identifier
      • Schema location
      • Default language
      • Taxonomy description (really should be schema description)
    • Terms
      • Category of term
      • Namespace prefix of term (which schema)
      • Name of term
      • Data type of term (applies only to concepts)
      • Period type of term (applies only to concepts)
      • Balance type of term (applies only to concepts)
    • Labels (collection)
      • Role of label
      • Language
      • Label
    • References (collection)
      • Role
      • Reference parts (can vary)
        • Publisher
        • Name
        • Paragraph
        • URL
        • URL date
    • Structures
      • Name (identifier)
      • Title
    • Associations
      • Type of association (presentation, calculation, definition)
      • Structure name (identifier)
      • From term name
      • Role of association (type of association)
      • To term name
      • Preferred label role (presentation type associations only)
      • Calculation polarity (calculation type associations only)
      • Order of association
    • Rules (a.k.a. constraint); each rule is ONE of the following types
      • Consistency type rule (a.k.a. Arithmetic)
        • Rule identifier
        • Structure name (identifier)
        • Rule XPath (a.k.a. constraint)
        • Concept (from within set of terms with type of Concept)
        • Commentary (optional)
      • Roll forward type rule
        • Rule identifier
        • Structure name (identifier)
        • Rule XPath (a.k.a. constraint, always same pattern)
        • Concept (from within set of terms with type of Concept)
        • Commentary (optional)
      • Member aggregation type rule
        • Rule identifier
        • Structure name (identifier)
        • Rule XPath (a.k.a. constraint), this is always the same for every member aggregation type rule)
        • Concept (from within set of terms with type of Concept)
        • Dimension (from within set of terms with type of Dimension)
        • Commentary (optional)
      • Adjustment type rule (a.k.a. restatement, correction of error)
        • Rule identifier
        • Structure name (identifier)
        • Rule XPath (a.k.a. constraint, always same pattern)
        • Concept (from within set of terms with type of Concept)
        • Dimension (from within set of terms with type of Dimension)
        • Member prior (represents prior period)
        • Member current (represents current period)
        • Commentary (optional)
      • Variance type rule (a.k.a. difference)
        • Rule identifier
        • Structure name (identifier)
        • Rule XPath (a.k.a. constraint), this is always the same rule for every variance type rule)
        • Dimension (from within set of terms with type of Dimension)
        • Member actual (represents actual scenario)Member budget (represents another scenario)
        • Member variance (represents the variance or difference between actual scenario and other scenario)
        • Commentary (optional)
      • Derivation type rule
        • Rule identifier
        • Structure name (identifier)
        • Rule XPath (a.k.a. constraint)
        • Precondition
        • Derived fact (a.k.a. name of the fact concept)
        • Based on source fact (a.k.a. copy the context of this fact)
        • Commentary (optional)
      • Nonstandard type rule (a.k.a. all other rule patterns)
        • Rule identifier
        • Structure name (identifier)
        • Rule XBRL (a.k.a. XBRL formula syntax for the rule)
        • Commentary (optional)
    • Facts
      • Reporting entity aspect (core dimension)
        • Period aspect (core dimension)
        • Concept aspect (core dimension)
        • Fact value (can be numeric or nonnumeric)
        • Units (numeric fact values only)
        • Rounding (numeric fact values only)
        • Fact id (optional)
        • Dimensions (collection, noncore dimensions)
          • Dimension name
          • Member name
    • Blocks (collection, derived)
        • Associations (collection)
        • Rules (a.k.a. constraints collection)
        • Facts (collection)
    • Disclosures (collection, derived)
        • Blocks (collection)

Perhaps you can do better.  If so, please ping me.  Always interested in improving the explanation.

Additional Information:

Comments

Post a Comment

Popular posts from this blog

Getting Started with Auditchain Luca (now called Luca Suite)

Image
(Note that a newer, production version as opposed to only the development version , of Luca Suite is available) The Innovator's Dilemma points out that disruptive innovations often look like toys that are doing everything wrong. Auditchain Luca , which is part of the Auditchain Suite , is a unique approach to creating a knowledge graph .  To experience using Auditchain Luca, have a look at the Getting Started with Auditchain Luca instructions. Be sure to grab the Excel and JSON import files used for this getting started exercise.   This getting started exercise uses one of several different approaches to getting information into a tool for constructing and viewing professional quality knowledge graphs .  Additional getting started guides will be made available over time. Auditchain Luca might not make sense to you if you don't understand the paradigm shift that is occurring and if you have not shifted your mental map. For the next step in your journey, consider t...
Read more

Relational Knowledge Graph System (RKGS)

Image
Relational Knowledge Graph System (RKGS) is an interesting idea that combines the relational paradigm and the knowledge graph paradigm.  This documentation, Why RKGS , explains the idea. This gets even more interesting with the notion of "relational AI".  RelationalAI is described as follows by the company of the same name, Relational.ai : “RelationalAI is a cloud-based relational knowledge graph management system, with state of the art probabilistic processing and declarative reasoning at scale to make developing Data Applications a superpower for your business.” This notion of knowledge graphs represented in relational databases fits into my belief that knowledge graphs have two aspects: the expression SYNTAX and the logic of what is expressed or SEMANTICS. While the LOGIC of a knowledge graph is always the same regardless of technical syntax used to express that logic; there are many, many different technical syntaxes that can be used to represent a knowledge graph. There...
Read more

Professional System for Creating Financial Reports Leveraging Knowledge Graphs

Image
The document Professional System for Creating Financial Reports Leveraging Knowledge Graphs explains a new approach, a new paradigm, for creating financial reports.  The document provides a practical, nontechnical description of a professional system for creating provably high-quality financial reports where the report creator is using financial reporting schemes (such as US GAAP and IFRS) where report creator is permitted to modify the report model which leverages global standard knowledge graphs represented using XBRL. This new approach is useful, it is highly novel, and the details were highly complicated to pull together.  This is certainly not an incremental innovation.  It is definitely a disruptive innovation and it could very well be a foundational innovation. You can decide which for yourself. Foundational technologies have two dimensions that need to be considered: novelty and complexity. The more novel the technology is, the more effort needed to ensure users ...
Read more