Machine Readable Knowledge Representation Using XBRL for

Digital Financial Reporting Charles Hoffman, CPA

December 11, 2014

Understanding the Importance of Knowledge

• The only way a meaningful exchange of information can occur is the prior existence of agreed upon: – technical syntax rules,

– domain semantics rules, and

– workflow/process rules.

• Rules are basically knowledge entry verification constraints against the knowledge representation description constraints (i.e. quality control, for example “Assets = Liabilities and Equity”)

• Knowledge is justified true belief

• Software can guide users through a process using knowledge entry verification constraints helping those users comply with domain knowledge

More information: http://xbrl.squarespace.com/journal/2013/11/17/knowledge-is-justified-true-belief.html

http://xbrl.squarespace.com/journal/2013/3/1/achieving-meaningful-exchange-of-information.html

http://xbrl.squarespace.com/journal/2014/8/22/understanding-the-difference-between-standard-and-arbitrary.html

Understanding System Boundaries

• First-order logic can be used to express a theory which fully and categorically describe structures of a finite domain (problem domain). No first-order theory has the strength to describe an infinite domain.

Financial Report Semantics and Dynamics Theory: http://xbrl.squarespace.com/fin-report-sem-dyn-theory/

Lowest Level Structure in XBRL - Fact

Lowest level structure in XBRL is the fact. Facts are hard-wired together by the XBRL Technical Syntax. A fact ALWAYS has the characteristics reporting entity, period, concept, and value; if value is numeric also has units and decimals.

PRO: If this is what you need, this is great because you don’t need to wire all this stuff together yourself using something like RDF+OWL. CON: If this is NOT what you need, then this because a problem.

Fact

• A fact defines a single, observable, reportable piece of information contained within a financial report, or fact value, contextualized for unambiguous interpretation or analysis by one or more distinguishing characteristics (properties of the fact). A fact value is one property of a fact. Every fact has exactly one fact value.

Characteristic

• A characteristic describes a fact. A characteristic or distinguishing aspect provides information necessary to describe a fact or distinguish one fact from another fact. A fact may have one or many distinguishing characteristics.

Add Characteristics

XBRL allows you to add additional characteristics. In the example above, a “Legal Entity” characteristic was added. Any new number of characteristics can be added.

Add Components

XBRL allows you to add any number of components. Above you see fragments of two components: an income statement and a balance sheet.

Component

• A component is a set of facts which go together (tend to be cohesive and share a certain common nature) for some specific purpose within a financial report.

Model Structure

• Component = Network + Table (Hypercube) • Characteristic = Axis + Member and context

entity and context period and LineItems which are XBRL Dimensions primary items

• Fact = Set of characteristics, value, units, decimals

Model Structure Implementation Details

Very detailed, see: http://www.xbrlsite.com/2012/Library/20_ImplementationModel.pdf

Model Structure

Allowed relations are shown in cells, provable by examining SEC XBRL filings. For more information see: http://xbrl.squarespace.com/journal/2014/12/10/example-of-expressing-semantics-using-xbrl-definition-relati.html

Relations Between Members

Members of an Axis are related in some way. These are called member arrangement patterns. Generally, they are “whole-part” type relations. Parts of a whole may be related in different ways. The following is a summary of subclasses of whole-part types of relations which may, or may not, be applicable to financial reporting. Other subclasses of whole-part relations may exist.

– Component-integral object: Indicates that a component contains some integral object. For example, the component handle is part of the integral object cup; wheels are a component part of a car; a refrigerator is a component of a kitchen.

– Member-collection: Indicates that some member is part of some collection. For example a ship is part of a fleet. Or, a subsidiary is part of an economic entity.

– Portion-mass: Indicates that some portion is part of some mass. For example a slice is part of a pie.

– Stuff-object: Indicates that some "stuff" is part of some object. For example steel is part of a car.

– Feature-activity: Indicates that some feature is part of some activity. For example the feature "paying" is part of the activity "shopping".

– Place-area: Indicates that some physical place is part of some area. For example the place "Everglades" is part of the area "Florida".

For more information: http://csjarchive.cogsci.rpi.edu/1987v11/i04/p0417p0444/MAIN.PDF

http://www.xbrlsite.com/DigitalFinancialReporting/MemberArrangementPatterns/2013-05-15/

Member Arrangement Patterns Example

Relations Between Concepts

Concepts within a set of LineItems are related in specific ways. These are called concept arrangement patterns.

– Roll up: A roll up computes a total from a set of concepts (stock or flow). This equation is: A + B + n = Total..

– Roll forward: A roll forward reconciles a balance (stock) between two points in time (flow). This equation is: beginning balance + changes = ending balance.

– Adjustment: An adjustment reconciles an originally stated balance to a restated balance between two different report dates. This equation is: originally reported balance + adjustment = restated balance.

– Complex computation: A complex computation thought of as a hierarchy plus a set of commutations between different concepts within that hierarchy which are more challenging to model than a roll up or roll forward. The type of computations can vary significantly, thus the challenging in modelling. For example, the computation of earnings per share is a complex computation.

– Hierarchy: A hierarchy denotes a hierarchy of concepts with no numeric relations. If no numeric relations exist, then the component is a hierarchy. Basically, anything can be modelled as a hierarchy. Generally mathematical relations turn a hierarchy into some other pattern.

– Text block: A text block contains, by definition, only one concept and that concept expresses what amounts to a narrative or prose as escaped HTML within that one concept.

For more information: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2013-05-15/ and

http://www.xbrlsite.com/2013/ReportingTemplates/2013-05-15/TemplateIndex/index.html

Concept Arrangement Patterns Example 1

Roll forward

Concept Arrangement Patterns Example 2

Roll up

Component Block

• A component may contain one or more component block.

• A component block has a concept arrangement pattern (roll up, roll forward, hierarchy, etc.)

• A component block MUST have one of the prescribed concept arrangement patterns.

• Generally, putting more than one component block per Table (hypercube) causes harder to read renderings

Component Block Example 1

Component with three component blocks: two [Hierarchy]s and one [Roll Up]

Component Block Example 2

Component with four component blocks: two [Roll Forward]s, a [Roll Up] and a [Hierarchy]. Note that all component blocks share the same Defined Benefit Plan Category [Axis]. Because each “block” of the component is explicitly separated, the rendering is easy to understand even though there is a lot to the rendering.

Categorizing and Classes 1

• Not all concepts are or act the same, concepts fit into some class or group.

• Concepts cannot change groups or classes; for example if a concept was intended for one thing then used for something else, problems occur.

• There is a difference between a requirement, an option, a choice, and a policy. A “policy” is a choice of an option which then becomes a requirement. For example, if interest is categorized as financing rather than investing; then it is always categorized as financing.

Categorizing and Classes 2

Some concepts are required, some optional, some can be extended, some make no sense to extend.

• Concept required: it would make no sense to extend concept. For example, there are obvious examples of such concepts like dei:EntityRegistrantName and dei:DocumentFiscalYearFocus. It absolutely, 100% makes zero sense to allow extension of such concepts.

• Optional concept: it would make no sense to extend concept. This is similar to the category above, but the concept is NOT required to be reported, such as dei:TradingSymbol, or the concept would only be reported if the filer actually had the concept, such as us-gaap:InventoryNet.

• Allowed to add subclasses of concept, but not extend concept: For some concepts, it makes a lot of sense to allow a filer to add a subclass for that concept or as some people think about it, to add a "child". But, it makes no sense to extend the concept. So again take the concept us-gaap:InventoryNet. It is hard to imagine the need to provide for some other concept "my:InventoryNet".

• Allowed to create extension concept: Suppose that some SEC filer wanted to disclose carbon credit information in their financial report but the US GAAP XBRL Taxonomy contained no such concepts. Pretty clear than an extension concept could be created.

Expressing Relations between Concepts and Classes is Knowledge 1

• RDF+OWL has the features to express information about relations between classes and concepts

• Why would XBRL not need those same features?

• Knowledge representation achieve two things: – knowledge description constraints

– knowledge entry verification constraints against the descriptions (i.e. quality control, for example “Assets = Liabilities and Equity”)

• For more information: – http://xbrl.squarespace.com/journal/2014/12/9/understanding-xbrls-role-in-knowledge-representation.html

– http://xbrl.squarespace.com/journal/2014/12/10/example-of-expressing-semantics-using-xbrl-definition-relati.html

Expressing Relations between Concepts and Classes is Knowledge 2

• Equivalent to owl:Class, rdfs:Class and rdfs:type. The element A is a defined to be class B. (Example, the taxonomy element us-gaap:Assets (which is an individual) is defined as being the class fro:Assets) (I AM NOT SURE THAT THIS IS CORRECT. As I understand it, the closest thing that XBRL has to articulating a class is the substitutionGroup attribute. However, that is not assignable after a taxonomy has been published. The US GAAP XBRL Taxonomy, for example, has a boatload of classes which need to be assigned after publishing of the taxonomy because the taxonomy does not provide this information.)

• Equivalent to rdfs:subClassOf. Class A is a specializetion of Class P. Ability to organize classes into a hierarchy of general-special terms. Similar to SKOS notion of broader terms versus narrower terms.

• Equivalent to owl:equivalentClass. Class A and class B have the exact same members. (Example, class LiabitiesAndPartnerCapital and the class LiabilitiesAndStockHolderEquity are both equivalent to LiabilitiesAndEquity.)

• Equivalent to owl:sameAs. Class A and class B are the exact same real world thing. (Example, the class Equity and the class NetAssets are exactly the same thing.)

• Equivalent to owl:differentFrom. Class A and class B are the NOT the same real world thing. (Example, the class Assets and the class NetAssets are NOT the same thing.)

• Equivalent to owl:disjointWith. Things belonging to one class A cannot also belong to some other class B. (Example, a member of the Person class set of things can never be a member of the Country class set of things.)

• Equivalent to owl:complementOf. Things that are members of one class A are all the things that do not belong to the other class B (Example, a member of the class of LivingThings set of things is the entire set of things that do not belong to the DeadThings set of things.)

• Equivalent to owl:inverseOf. A relationship of type X between A and B implies a relationship of type Y between B and A. (Example, IF starsIn inverseOf hasStar; AND IF MenInBlack hasStar WillSmith; THEN WillSmith starsIn MenInBlack)

• Equivalent to owl:unionOf. The members of set C include all the members of set A and all the members of set B.

• Equivalent to owl:intersectionOf. The members of set C include all the members of set A that are also members of set B.

• Neither OWL nor RDFS has equivalent. The whole A has part B. (Example, the whole BalanceSheet has part Assets.)

• Neither OWL nor RDFS has equivalent. The part A is part of the whole B. (Example, the part Assets is part of the whole BalanceSheet.)

Finite, Defined Boundaries

• The “moving pieces” of the financial report model are finite

• There are a finite number of disclosures (I have identified about 1000a). Need more? Add more.

• HOWEVER, you must follow established patterns.

– Missing pattern? Add new pattern.

– Missing concept? Add new concept but put it into an existing class

– Missing a class? Add a new class

Goal is to Achieve a Purpose

• Digital financial reporting is useful, it enables machines to perform useful work effectively.

• Recognize that there is no singular objective reality but in spite of that; if we create a useful, practical, common enough shared reality we can achieve a purpose.

• Goal is to make the reality of the financial reporting domain appear to be objective and stable in certain specific and agreed upon ways in order to create digital financial reporting.

• Making digital financial reporting work is a choice. • How digital financial reporting works is a choice. More information: http://xbrl.squarespace.com/journal/2014/7/28/data-and-reality-what-is-the-purpose-of-sec-xbrl-financial-f.html

Summary

• Digital financial reports are a finite set of thousands of structured pieces • Digital financial reports are made up of components • Components contain facts which are distinguished by characteristics • Components, facts, and characteristics have relations • Components, facts, and characteristics fit into classes • Relations and classes follow rules • Rules are knowledge • Knowledge both describes the domain and enables verification that

representations follow the rules of those descriptions • Another name for this is knowledge entry verification constraints (i.e.

quality control, for example “Assets = Liabilities and Equity”) • Software can guide users through a process using knowledge entry

verification constraints helping those users comply with domain knowledge