Digital Financial Reporting

I have been doing some experimentation with RDF, RDFS, OWL, and SPARQL.  I have not been able to create a lot so far; the learning curve is rather flat now. What I have created is interesting from a number of perspectives.

I am working with this randomly selected SEC XBRL financial filing. What I want to do is two things.  First, generated the model structure of the filing in RDF and second, validate the model structure against an OWL ontology (or RDFS) to see if is possible.

To start, consider a few things.  This is the presentation linkbase of that filing.  That is expressed in XBRL using XLink.  It is VERY hard to work with this raw XBRL.  No problem, send the XBRL file to an XBRL processor and generate an easier to use XML infoset.  If you look at that XML infoset, you can start to understand the model.  It is way easier to use that the raw XBRL/XLink.  Next, I serialized that exact same information in RDF. 

If you look at that you might say two things. First you might say, "Now wait a minute, that is harder to read than the XML infoset." And you would be right.  The second thing you might see if you looked at this is the remarkable parallel between XLink and RDF.

All three of those technical syntaxes say EXACTLY the same thing: the XBRL presentation linkbase expressed in XLink, the XML infoset in just raw XML, and the RDF.  EXACTLY the same thing.

However, there are HUGE differences between the three serializations.

1. The XBRL presentation relations expressed in XLink can be validated.  BUT, it can be validated only to the extent that the XBRL processor understands the information.  All XBRL processors understand the XBRL syntax of course.  HOWEVER, what XBRL processors do NOT understand is how the presentation relations should be structured, whether those presentation relations are consistent with the XBRL calculation relations and XBRL definition relations.  Why? Well, because XBRL only has "parent-child" (http://www.xbrl.org/2003/arcrole/parent-child) type relations in the presentation linkbase. What does the parent-child relationship mean?  What relations are allowed?  You cannot express that in XBRL beyond "parent-child" and you therefore cannot validate that you are building the relations correctly or consistently across all linkbases with XBRL.
2. The XML infoset relations are WAY clearer.  They are WAY easier for a human to read, WAY easier for an XML parser to work with, and ALL the information you want to work with is there.  (If you go back to the XBRL presentation relations you will note that you have to go grab information from the XSD file to have information about the report elements.)  If this format is so much better, then why doesn't XBRL use this format?  Well, because the XML infoset format is not extensible.  That is WHY XBRL used XLink.  But there is something else wrong with the XML infoset format.  You still cannot tell if (a) the information expressed is CORRECT and (b) you cannot tell if the information is CONSISTENT with the XBRL calculations and XBRL definition relations.  You can write a validator very, very easily to perform the tests to see if the relations are CORRECT; but, that is work.
3. RDF (work in progress), I think, can solve the validation problem.  I say "I think" because I have not actually gotten this to work yet.  THAT is what I am trying to make work. (I did get this to validate per the W3C RDF validator.)

To do this, I first built a simple ontology using OWL.  This is the ontology.  If you look at this and criticize how bad this is right now, you are totally missing the point.  Yes, it is bad.  I don't understand how to best use OWL yet.  (If YOU do, please rewrite the OWL ontology, sent it to me, and I won't have to spend the time figuring this stuff out. Please!)  Not helping things is the fact that if you think XBRL is flexible and hard to use, you should try RDF, RDFS, OWL, and SPARQL!!!  So why do I bother?  Well, (a) because it is far easier for me and other business people to use RDF, RSFS, and OWL than it is to learn to program all this stuff but more importantly (b) there are WAY, WAY, WAY more things that I want to be able to validate.

To fiddle around with the RDF I am using Protege.  (This is a web based version of Protege, works in Google Chrome, does not seem to work in Microsoft Internet Explorer)  Now, Protege is not a business user tool.  VERY hard to figure out.  But again, it is worth it.  Part of Protege is a SPARQL query tool. Here is my first SPARQL query (paste it into Protege, try it for yourself):

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

PREFIX model: <http://www.xbrlsite.com/2013/FinancialReportOntology/ReportElement.xml#>

SELECT ?subject ?object WHERE { ?subject model:hasAxis ?object }

Why am I doing all this? Folks, this is extremely powerful stuff! There is an absolute boatload of leverage which seems achievable from RDF, RDFS, OWL, and SPARQL. That is what the Financial Report Ontologyis all about.  Other domains have created ontologies.  Economics. Biomedical. Others.

Frankly, I don't get all the details of this stuff yet.  But, then again, I did not get XBRL when I first started either.  But, hundreds if not thousands of hours trying to figure this stuff out is paying off. I can tell you this...while it might be a lot of work for accountants to understand this technology stuff; it would be WAY more work for technology people to grasp accounting.  Business users don't need to learn everything about the technology; just enough to communicate effectively to the technology people who do understand this stuff.

This Columbia University white pater, An Evaluation of the Current State and Future of XBRL and Interactive Data for Investors and Analysts, is interesting at a number of levels.  It is worth reading.

The net, net if it all is this statement:

So it is not a matter of whether a method for structuring and communicating interactive, machine-readable data will arise, but more a matter of which method of collecting and consuming such data will both arise and remain relevant, in light of ever-advancing technological changes, as well as ever-growing demands for data by consumers.

Digital financial reporting is inevitable.  The truth be known, semantic, model-based, structured authoring of financial information is easier that current legacy approaches.  Time will prove this to be true.  Longer term, this is where things are going.  In the shorter term, who knows what will happen.

Inline XBRL is not a panacea or other "magic bullet" which will make all problems related to XBRL go away.  Some people seem to believe that it is some universal solution for all that ails XBRL implementations.

This is the way I see the moving pieces related to using Inline XBRL.  First off, it is really not a question of "Inline XBRL" (some people call it iXBRL) or not.  There seem to be the following factions applying XBRL to financial reporting. You have your:

1. Inline XBRL camp
2. Datapoint Model camp (includes Table Linkbase)
3. Global Filer Manual camp (this includes the SEC and US GAAP Taxonomy implementation of XBRL, used for SEC XBRL financial filings)
4. "Go it alone" camp, they just ignore what everyone else is doing

Are these seen as alternatives which are 100% interoperable?  XBRL is a "global standard", why would these not be interoperable? Camp #4 means less than 100% interoperability. So, throwing out option 4, will there ever be one global approach to creating a digital financial report?  Well, that really boils down to whether there will be a world with only IFRS or whether there will be a world with both IFRS and US GAAP. So say we are looking for one and only one approach.  Which is best?  Or, does it matter; are all three approaches interoperable/interchangeable?

So that begs two questions: (a) What does each approach offer? (b) What common issues do all three approaches share?

There is an issue which Inline XBRL, Data Point Model, and the Global Filer manual camps share.  I will give you an example of that issue in a moment.  But first, let me decouple that issue from another issue which many people confuse as the only issue.

The issue is obtaining a human readable rendering of information communicated by XBRL.  Both Inline XBRL and the Data Point Model try and solve this rendering issue.  It is my view that both the Data Point Model and Inline XBRL are both trying to solve something that I am not 100% sure is even a problem.  But, it could be a problem.

The problem is commonly seen as "viewing the information."  I am 100% certain that Inline XBRL solves that problem to the extent that HTML can solve that problem because (a) Inline XBRL uses HTML and (b) HTML does a pretty good job with getting very close to "pixel perfect rendering". 

I am pretty sure that the Data Point Model, which uses the lesser understood table Linkbase, gets very close to what HTML can do if not 100% at the same as HTML and therefor does the same thing as Inline XBRL.  I can believe that from this "viewing the information" perspective, Inline XBRL and the Data Point Model (with the table linkbase) are equivalent.

So from that perspective, let us just say that the two are equivalent.  If they are not, then the specific differences should be quantifiable.

While the Global Filer Manual (of which SEC XBRL financial filings is a subset) are rather poorly rendered by the SEC Interactive Data Viewer and most other software in many cases (and therefore does not seem like an adequate solution); there are generally two reasons for most or at least many rendering problems:  (1) poorly modeled information and (2) rendering engines which do not leverage known information semantics.

And so what I am saying is that it might be possible for an "adequate" rendering could be achieved by simply improving modelings and leveraging information, patterns, within those models.

If it is the case that a rendering engine understands information semantics, and if it is the case models are constructed correctly and consistently; then it is in the realm  of possibility that a rending engine can create an understandable and useful rendering.

Now, that rendering will not be "pixel perfect" or exactly as every person would want to see it because there are so many DIFFERENT ways people might want to see this information.  But, would be a usable rendering?  I am about 98% sure that such a rendering is possible, but because I have not seen such a rendering for 100% of all use cases I cannot say for certain that I am 100% sure.

So, the REAL questions are: (a) what is the target rendering the market needs, "pixel perfect" or "usable" and (b) is it possible to hit that target leveraging what exists in the XBRL instance and XBRL taxonomy plus know and agreed upon semantics and patterns in those semantics of the information.

And so those two questions (what is the target and can that target be achieved) is different than the real thing which ails XBRL.

This issue will NEVER be solved by Inline XBRL nor by the Data Point Model as far as I can tell.  This issue can likewise be broken down into two parts: (a) do domains express enough metadata so that interchangeable models can be created and (b) does XBRL have enough expressive power verification capabilities to verify that good models are being created?

In my view, this is the REAL issue.  XBRL cannot capture enough of the semantics which are necessary in a global-standard way to build high-quality, interoperable financial information which can be effectively exchanged.  Just to remind you again, neither Inline XBRL nor the Data Point Model address this issue.  Also, just packing the XBRL definition linkbase with "stuff" will not solve the problem.

If you look at this visualization of an ontology for a financial report that I am creating you will start to understand what I mean:

http://xbrl.squarespace.com/journal/2013/1/18/financial-report-ontology-draft.html

Like I said, this problem has two moving pieces:  First, many times the semantics are not defined by reporting standards and second, XBRL has no agreed upon way to express the semantics. 

While pretty much anything can be expressed using the XBRL definition linkbase (such as how XBRL Dimensions uses the XBRL definition linkbase to express and then validate multidimensional information); the important point is "agreed upon way to express the information". 

To understand what I am saying all you really need to do is look at the expressive power of something like UML (Unified Modeling Language) which is a modeling tool and how you can have different types of relations (associations, aggregations, etc.) and how UML can express those use cases.  Or, if you look at RDF/RDFS/OWL and the expressiveness of those tools and then if you think of how you would express the same information using XBRL, you then begin to realize the limitations of XBRL for expressing needed information.

A specific example of XBRL's limitations is XBRL Dimension's expression of meaning of the relationships between the members of a domain.  All you can do is basically express that there is a relation, which is unlike UML or RDF/OWL which lets you express the type of relation.

Another example of this is how one would express the relations between the components of a reporting entity.  The 2013 US GAAP Guide, published by Wiley, provides an excellent example of both an inadequate expression of the semantics of the components of a reporting entity by US GAAP (this is NOT a problem of XBRL, it is a problem within the domain of financial reporting) and exactly the type of relations which need to be expressed. 

US GAAP defines terms used to describe these sorts of entity components differently in different places within US GAAP.  It also uses different names and does not even define some terms which relate to expressing the components of a reporting entity.

This includes such terms as parent holding company, consolidated entity, reporting unit, asset group, disposal group, subsidiary, business segment, geographic area, business unit, legal entity, operating segment.  (I am NOT saying that some of these terms are not defined.  Some are.  What I am saying is that some of these terms are not defined, some are defined ambiguously in GAAP, some are defined in multiple ways but mean exactly the same thing.)

If you try and model information about the relations between the components of a reporting entity then you begin to understand what is necessary from XBRL to make information expressed using XBRL truly interchangeable between business users (i.e. no ambiguity).  Further, you gain additional insight if you look at the current set of SEC XBRL financial filings.  If you do so you get an even better understanding of the limitations of XBRL and the needs of any reporting scheme or system making use of XBRL appropriately to make the information usable.

Like I said, neither Inline XBRL nor the Data Point Model (with the table linkbase) solves this problem.  And therefore, if one moves to Inline XBRL or the Data Point model, one will be disappointed that the move did not get you where you really wanted to be.

Another thing which is related to this is that I now understand the problem which some people had with XBRL Dimensions.  Its expressiveness is missing certain key pieces. 

This is a work in progress, so stay tuned!  I have created a financial report ontology. The "things" used in the financial report ontology will be defined in human readable terms here. A visual representation of the "things" can be found here.

Still to come is a UML (Unified modeling language) representation and an RDF/RDFS/OWL (Semantic Web Technologies) representation.

Why am I doing this?  See here and here.

If you want to participate and learn a lot, please contact me and I will get you dialed in.

I mentioned this comparison utility tool in a prior blog post, but it is worth elaborating on a bit more.

This comparison utility tool was created by me in collaboration with Cirrus and XBRL Cloud.  I use the XML infosets of an SEC XBRL financial report provided by XBRL Cloud and ideas from Cirrus and wrote an Excel application which generates the comparison that you see below (click on the image to see a bigger image, click here to download the Excel spreasheet):

Comparison of Costco and Wal Mart Income StatementsOn the left you see the Costco income statement.  On the right you see the Wal Mart income statement.  Between the two you see red cells and green cells.  The green cells have the row number of the matching report element within the other financial report component being compared.  Yellow highlighting indicates no matching report element, white rows indicate that there was a match. Downloading the Excel spreadsheet and looking at it makes it more clear how this works.

The Excel spreadsheet has the income statement and balance sheet comparisons.  But, you can compare any two components from any SEC XBRL financial filing.  While this is helpful for looking at the primary financial statements, it is even more helpful in analyzing the many disclosures. You can also use this comparison tool to look at changes between the 2012 and 2013 US GAAP Taxonomy.

This comparison is useful because how other reporting entities model a component of a financial report is good information which can be used to be sure you are modeling your financial report appropriately.  This is particularly true if the other reporting entity is in your peer group.

If you are interested in using this comparison utility please contact Cirrus, XBRL Cloud, or send me an email.