Digital Financial Reporting

It is slow going, but progress is being made toward achieving an RDF/OWL representation of a financial report. If you are interested in this you may want to follow the Semantic XBRL group on LinkedIn.  Here is information helpful to this process.

1. Financial report in XBRL: This is what I call a reference implementationof a SEC-type XBRL-based financial report.  To convert the XBRL technical syntax to OWL, the first step is to convert the XBRL technical syntax to the semantics of the report.
2. Semantics of financial report (Model Structure and Fact Table):  The XBRL instance and XBRL Taxonomy are converted from a syntactic representation into a semantic representation.  There are two primary parts: the model structure which articulates the relations between the pieces of a report and the fact table which is the information contained in the financial report.  Here are human readable versions of the model structure and fact tables.
3. Initial target, the fact table:  While there is really a lot that needs to be converted to OWL in addition to the model structure and fact tables, such as business rules; but the initial conversion target is just the fact table.  Once that is done, other parts can be built out in OWL.  To help visualize this, I wrote an Excel macro which imported the fact table. So this is the information which should be converted to RDF/OWL expressed in Excel (within a ZIP archive).
4. TopQuadrant "table" model:  If you look at the Excel spreadsheet in #3, you will notice that the fact tables of a financial report fit nicely into an Excel spreadsheet.  TopQuadrant built a little OWL ontology that can be used to represent information that fits into a spreadsheet.  Here is that OWL ontology.
5. Initial attempt at RDF:  This is an initial attempt at getting the fact table information into the proper RDF/OWL format. This is pitiful I know, but it is progress.
6. Semantics of a financial report:  This is the most succinct explanation of the semantics of a financial report that I have at this point: Understanding the Mechanics of an SEC-type XBRL-based Digital Financial Report.  I know it is probably not suscint enough yet, but it is getting where it needs to be.
7. Key semantics and spreadsheet analogy:  So this is my thinking. Just like a Workbook has spreadsheets, spreadsheets have rows, and rows have columns in the TopQuadrant representation; in a financial report a report has components (similar to how workbook has sheets), components have facts (similar to how spreadsheets have rows), and fact has aspects (similar to how rows have columns).

Perhaps it is misguided, but that is my thinking.  Got a better idea?  Post it to the Semantic XBRL group.

An updated prototype of the Financial Report Ontology (FRO) has been made available.  You can get to this most current version of the prototype here:

http://www.xbrlsite.com/2013/FinancialReportOntology/Prototype03/

If interested, you can follow discussions about the FRO on the Semantic XBRL LinkedIn Group.

This blog post is part of a project on the Semantic XBRLgroup in LinkedIn.  The goal of the project is to convert some XBRL formatted digital financial information into RDF/OWL. The intent is to use the proper financial report semantics to structure the RDF, enforce that structure to the extent possible using OWL, and then be able to do useful SPARQL queries against that digital financial report information expressed in RDF/OWL.

This blog post is intended to be a resource to help those working on that project to understand the financial report semantics, have access to information which helps them understand the process and steps, provide test cases and examples, etc.

NOTE!!! Because this is a work in progress things may not tie together as well as they need to.  For example, terminology is adjusted as new things are learned and examples may use a mixture of old and new terms.  The goal is to tune and get all these sorts of things in sync as part of this project.

Understanding the semantic representation

The first step in this process is to understand the semantics which we will be working with. The document Financial Report Semantics and Dynamics Theory summarizes those semantics. You can see those semantics implemented here within the XBRL Cloud Evidence Package. 

• Here is a rendering of a balance sheet which is one "component" of a financial report. 
• Here is the fact table which lays out the facts and their characteristics for the report component.
• Here is the model structure which shows the relations between the facts within the fact table and provides other details.
• NEW!!! Here is a ZIP file which contains an Excel spreadsheet application which reads numerous model structure and fact table infosets and loads them into the spreadsheet.  It also uses the models structure, the fact table, and additional rendering information to create a prototype, but limited, rendering.

So that is a representation of this information in human readable form.  All those pieces relate to this reference implementation of an SEC XBRL financial filing. From that page you can get to all the pieces of that digital financial report. (NOTE!!! Something else which is helpful is this HTML version of that digital financial report. HOWEVER, that HTML is a older example so the HTML will not tie exactly to the current reference implementation.)

Another view of the exact same information is an XML infoset of the fact table and the model structure.  PLEASE NOTE!!! The element names are not totally correct in these examples.  There are extra attributes which don't belong in the infoset.  There are pieces which SHOULD be in the infoset which are not there.  Remember, this is a work in progress.

The Financial Report Ontologyis a greatly expanded set of financial report semantics. Again, this is a prototype.  Pieces of this are shown in OWL, but this is NOT what the end product will look like.  What you see today is the best that a CPA can do given a good understanding of financial reporting, a good understanding of XBRL, and a basic understanding of RDF/OWL.  This ontology will evolve to what it needs to become.

Something which is helpful in understanding the overall represention which the Financial Report Ontology will represent, or rather the best guess for now, is this VUE mind map. The point of this mind map is to provide something helpful to business users.  The formal representation of the ontology will likely be in UML or OWL or whatever the technical people decide works best.  But business users MUST be able to understand the ontology in their terms.  Eventually, I believe that will be within working software applications.  Until that software is build, some method to explain the moving parts of a financial report is necessary.  This is my best attempt to communicate such information.

Further, we are NOT ARTICULATING 100% of this financial report ontology in this project.  This project is focused on only the financial report level semantics at this phase.  The goal of this phase is to convert only the XML Infosets into RDF.  That is all for this first phase.  And so, we will be dealing with the report components, facts, characteristics which describe those facts.

Implementation model

The reference implementation is of an SEC XBRL Financial Filing.  Such filings make use of the US GAAP Taxonomy.  The US GAAP Taxonomy uses specific structures and terminology.  Those terms are not financial reporting related, nor are they totally XBRL related.  They basically bridge a gap.  This terminology uses term such as Network, Table, Axis, Member, Line Items, Concept, and Abstract.  You can see these terms explained here.

If you notice the XML infosets, they follow this representation within the fact table and model structure. That could be a mistake.

The XML infosets were generated by XBRL Cloud who has implemented these infosets.  The Arelle open source XBRL processor has an implementation of the model structure infoset, but not the fact table infoset at this time. What would be highly desirable is to have the Arelle open source XBRL processor output both the XML infosets and output RDF.

Prototype output

This blog post has some experimentation with serializing XBRL as RDF and running a SPARQL query to return some useful results.

This RDF, which uses this OWL ontology, when loaded into Protege, and you try and run these SPARQL queries, do work.

For phase 1, I propose a goal of the following:

1. RDF of the reference implementation fact table and model structure which loads into Protege correctly.
2. OWL ontology which supports the RDF.
3. SPARQL query which returns the model structure of a report component.
4. SPARQL query which returns the fact table of a report component.
5. SPARQL query which tests the model structure and fact table against the OWL ontology to make sure the RDF follows the semantics of a financial report (relates to relations between report components, facts, characteristics as expressed by networks, tables, axis, members, concepts, abstracts.

Another thing that the Business Reporting Logical Model does is enhance comparability and interoperability. Or to be more precise, the Business Reporting Logical Model minimizes the effort required to achieve comparability and interoperability. It opens the possibility of a business domain to create comparability, should they desire to do so. Interoperability means easier to use software and less costly software for business users.

Here is why.

Comparability

(Here is a link to a PDF of this graphic.)

Today, there is no logical model below the XBRL syntax level. The only model any business domain has to work with is the XBRL syntax or some model they create. Creating that model and all the infrastructure to enforce that model takes time and costs money.

Or, another way of looking at this is that each company desiring to use XBRL for, say, financial reporting could create their own model using XBRL. That model could be 100% XBRL compliant (i.e. comply with the global standard).  Each company would have to deal with all the "stuff" in the middle such as which GAAP (accounting standards they would use), create their own XBRL taxonomy, and so forth.

The "middle ground" needs to be created.  The US GAAP Taxonomy created some of this middle ground.  You can see that middle ground in the US GAAP Taxonomy Architecture. But, the US GAAP Taxonomy is not enough.  That is why the SEC had to create a boatload of additional EDGAR XBRL Validation tests (see this list of errors, here is the test suite). Of course, the SEC would probably never want XBRL International to deal with 100% that that specific regulator needs to deal with, nor would XBRL International members do that; it would be like everyone agreeing to do business reporting exactly like the SEC does it, that would become the XBRL standard.

Business information exchange is a balancing act. Where agreement is achieved has ramifications for business users. Too much flexibility has its issues, too much comparability (or requiring things too high in the stack) has its issues. Where comparability exists within the "stack" (the diagram above) is up to the business domain's implementation of XBRL.  XBRL itself does not control this. How XBRL is used does.

Interoperability

There is another piece to this puzzle.  XBRL is a standard. What a system needs to make business information exchange work properly, it seems to me, is a protocol.  There is a difference between a standard and a protocol. A difference worth understanding. Erez Ascher (Ascher Consulting & Development) articulates the difference between a protocol and a standard as: 

• A protocol is a series of prescribed steps to be taken, usually in order to allow for the coordinated action of multiple parties.  In the world of computers, protocols are used to allow different computers and/or software applications to work and communicate with one another.  Because computer protocols are usually formalized, many people consider protocols to be standards.  However, such is not actually the case.
• Standards are simply agreed-upon models for comparison, such as the meter and the gram.  In the world of computers, standards are often used to define syntactic or other rule sets, and occasionally protocols, that are used as a basis for comparison.  Some good examples include ANSI SQL, used to compare derivations of the SQL database query language, and ANSI C, used to compare derivations of the C programming language. 

In other words, it seems to me that protocols can be standards, but standards may not contain all that is necessary to "allow different computers and/or software applications to work and communicate with one another". Therefore, every business system, such as the SEC XBRL filings system, must add "stuff" to XBRL to turn the standard into a protocol it seems. For every system to have to do this is both inefficient and ineffective because you really don't get cross business system interoperability. What you get is what we have today - many point solutions or one-to-one integrations.

So not only does the Business Reporting Logical Model enhance comparability, it also enhances interoperability. The Business Reporting Logical Model can provide the pieces which can turn the XBRL standard syntax into a business reporting protocol. I am not sure if it is all the pieces, time will tell. But I am sure XBRL alone is not enough to give business users what they need from XBRL.

The Bigger Picture - Financial Reporting in the Age of the Semantic Web

There is a bigger picture here.  Consider this blog post titled "Why the Semantic Web Will Fail". The post is pretty good, but what is really interesting are the comments to the post. The way I read that post and all the comments is that the Semantic Web is inevitable, but no one knows when it will arrive.

I contend that the Semantic Web is already here. The US Securities and Exchange Commission (every US public company financial in XBRL by July 2011), XBRL US (US GAAP Taxonomy), Tokyo Stock Exchange, Japan Financial Services Agency, Korean Stock Exchange, China Securities Regulatory Commission and Shenzhen Stock Exchange, Japan's EDINET, the Commission of European Banking Supervisors, the US Federal Deposit Insurance Corporation, the International Accounting Standards Board (IFRS, standardized financial reporting meta data expressed in the XBRL syntax) among others have already created pieces of it for financial reporting. The US SEC, Japan FSA, and IASCF are already reconciling their implementations of the XBRL standard to make them more interoperable. The Business Reporting Logical Model will make it so others don't have to go through this reconciliation process.

Is XBRL perfect? Certainly not. But XBRL is not RDF/OWL. Who cares, both XBRL and RDF/OWL are just syntax. On can convert from one syntax to another easy enough. The hard part, agreeing on the meta data and getting vendors to support the idea, is done (for US GAAP and IFRS). The IASB started on IFRS in the 1970's, even before the Internet existed. Most countries have either switched to IFRS already or will. Even if they all don't (i.e. the US will converge, but may not convert), reconciling US GAAP to IFRS is not that much of a challenge really. Oracle, SAP, and IBM all support XBRL within their software.

Maybe I am wrong, but it seems to me that a better question might be "When will others catch up to how the financial reporting business domain has embraced the Semantic Web?" That may by an over statement, financial reporting has a ways to go. The Business Reporting Logical Model will help others get into the Semantic Web easier than the early pioneers.

How did XBRL International get to where it is? Back in 2003 Joan Starr wrote an article Information politics: The story of an emerging metadata standard. Here is the article's abstract:

Information politics: The story of an emerging metadata standard by Joan Starr

This is the story of how one commercial metadata standard — XBRL, or Extensible Business Reporting Language — has attracted the participation and support of some of the world’s most powerful public and private organizations. It begins with a look at the nature and use of financial information in today's Internet-enabled environment and discusses three information use patterns: Transaction, retrieval, and reporting. While numerous, sometimes competing standards have been developed for transaction information, XBRL alone has emerged to address reporting formats. Today, the XBRL specification has wide support across the accounting, financial, and regulatory communities. This has come about largely through the efforts of the standards’ governing board, which has pursued a strategy of careful definition of market scope, deliberate courtship of important allies, and establishment of a culture of aggressive outreach for members. The results are impressive. Members of the organization are now positioned to take greatest advantage of a number of new entrepreneurial opportunities that have been created by the organization. Additionally, some participants are now representing the XBRL metadata standard as a key tool for the restoration of public confidence in the scandal-rocked accounting and investment industries. This may create a serious problem for researchers and investors as unaudited financial statements formatted in XBRL proliferate on the Web sites of corporations anxious to demonstrate a commitment to what some are calling "the new transparency."

XBRL seems to have achieved the right mix of technical and business participation. While what the technical people did was very good and very important, I think that what the business people who participated in XBRL created was perhaps even more important. Business users of XBRL should try and understand and push for the Business Reporting Logical Model to be standardized within XBRL International.

This will provide the flexibility where flexibility is needed, but also the things needed for a protocol to work well, be effective, and be efficient. Having every implementation of XBRL undertake this task will hurt XBRL, making comparability of XBRL based information more challenging and interoperability of XBRL software and different implementations near impossible.

So that is what I see. How do you see it?

I spent about 4 hours trying to find some reasonable resources for getting started with OWL (Web Ontology Language).  I figured I would summarize what I did to get all set up and going with OWL.

OK, here are the key resources for getting started with OWL.

• The book Programming the Semantic Web (O'Reilly) is a good starter book for non-programmers.  This basically paints the big picture.
• The tool Protege, is an OWL editor mentioned in that book.  This web page is a good get started guide.  It has links to download the free application, a quick overview, etc.
• This 10 minute walk through helps you get going and points to two plug-ins you will likely want.
• This is a 100 page PDF on how to use Protege.

Even if you don't want to be an XBRL taxonomy master, OWL is a good thing to understand. It will really help you grasp where the world is going.