Digital Financial Reporting

In order for your XBRL information work on the Semantic Web or within your internal semantic web, or in any computer system for that matter, your data and metadata need to be unambiguous.

Before I get started here, I want to explain a few terms to business people.  Business people need a working knowledge of these terms in order to understand what is important to making your systems work, to making your XBRL unambiguous.

Why is this Important?

You may have heard terms like "metadata" and "semantic web".  But what do these terms mean and how do they relate to you.  In his book Pull, David Siegel explains these two important terms and how they will change the Web.  While the terms are defined in the book, what provides you the understanding are the countless examples of what having a "semantic web" will mean to you.

For anyone who lived through the beginning of the Web, to say there was hype surrounding the notion of how the Web would change life as we know it on planet earth is an understatement.  However, you have to admit that a lot of things have changed.  Just because there is hype does not mean that the Web is "empty", nor is it the case that "the Semantic Web" is empty.  In fact as I understand it, the Semantic Web was Sir Tim Berners-Lee's vision of what the Web needs to be, the Web as we know it today is just an interim step in that direction.

Metadata

It has been my experience that technical people like to complicate the notion of "metadata".  Perhaps they like to keep things mysterious.  You can go search the Web for a definition, in fact here is an explanation of metadata on Wikipedia.  I even hear techies use the term "meta-metadata"!

So what is metadata?  Metadata is just data.  It is just at a different level from what you normally thing of as data.  Metadata, like data, describes something.  That is it.  What is more important is to understand why metadata or data is important.  Computers are not magical things.  They can do magical things, but all this is enabled by the data and metadata which is provided by and linked together by humans.  For example, if you have a list of files on your computer you can only sort them in ways you have information about those files, the "data" or "metadata" about a file; such as the date you saved the file or the name of the file or the type of file.  The more data or metadata you have, the more a computer can do with data.

Semantic Web

Metadata and data is the foundation of the Semantic Web.  David Seigel gives a very simple explanation of the Semantic Web by posing two simple questions:

1. Is it unambiguous?
2. Is it on the Web?

So now we have a number of other terms floating around here: semantic and unambiguous. If you are a glutton for punishment, you can go here and read about semantic.  Fundamentally, semantic is about unambiguous meaning.

When I say Semantic Web, you can look at the scope of the "web" in a number of different ways.  It woulc be the "Semantic Web" meaning the open to the public on the Web, it could mean "semantic web" meaning only available within your organization, or it could just be some smaller subset of users in some sort of closed system, not open to everyone.  The type of web makes no difference.

As David Seigel explains in his book,

Data that is semantic means exactly the same thing to any system or person who uses it.

That is the key to making data usable to a computer.  You need to be unambiguous.  This is not to say that everyone has to interpret the information in the same way, this is about consistency in the meaning of the data and metadata.

Making XBRL Unambiguous

So, if you are creating XBRL you want to be unambiguous.  This does not mean unambiguous to you, it means unambiguous in general, to everyone.  There are ways to test to see if your information is unambiguous. As a business person you don't actually have to do these things yourself, you can ask the technical people implementing the system if they have done any of these.)

• Try to express it in RDF (Resource Description Framework) /OWL (Web Ontology Language).  If you can, and it makes sense, then it is unambiguous.
• Try and express your information model in UML (Unified Modeling Language) and see if it makes sense.  Again, if the UML model makes sense, then the data and metadata will likely make sense.
• Try and use the data.  If the system works, then the data and metadata are unambiguous and logical.  If not, then something needs to be fixed.

If you have not tested your systems there is a high probability that your system is not providing information which is unambiguous.  It is the testing which helps you achieve this desired goal and makes your system usable.

This is particularly true when your system allows extensibility, where those submitting information can make any sort of adjustment to an XBRL taxonomy.  Those extending your XBRL taxonomy have to be given guidance to create those extensions as you had anticipated and consistently with one another.

This testing is best done during the time when you are architecting your XBRL taxonomy and other aspects of your system, not when your system is live.  Waiting until your system goes live to do this testing may mean the need to re-architect your system.

This is a nice little OLAP cube tutorial.  Remember though!!!  XBRL wants the "multidimensional model" part of business intelligence, it does not want the "OLAP" piece which focuses only on numeric content (because XBRL also deals with text) or the aggregation part (because not everything needs to be aggregated, it already could have been aggregated.

For more information, see the OLAP Council White Paper.

OK, so maybe I am a slow learner.  

The FINREP taxonomy got me thinking about something.  Someone asked the question "is there a presentation linkbase which can help business users view the taxonomy." At first I was appalled that someone would publish a taxonomy without a set of presentation relations.  How could you possibly read the taxonomy without the presentation relations.

Auto-generation of definition linkbase

I started to think about this further and thought, "Well, can't one simply generate a useful set of presentation relations from the definition linkbase which is provided?"  The reason I thought this is what when we created the US GAAP Taxonomy (I was part of the team which created that) we auto-generated the definition linkbase from the presentation linkbase rather than create both by manually.

If you look at the US GAAP Taxonomy presentation linkbases (here is one) you can see the metadata in the labels such as the "[Table]" and "[Axis]" and "[Line Items]" things tacked on to the end of the labels.  Also how the relationships are organized explains things about the information model.  The US GAAP Taxonomy Architecture explains these things which are tacked on to the labels and how the relations are organized (see section 4.5).  This approach to "documenting" the relations (called "styles" in the US GAAP Taxonomy Architecture) was developed to help people see these relationships more clearly.

So basically a careful organization of things in the presentation linkbase and validation helps to make sure you get this correct can allow you to auto-generate the definition linkbase from the presentation linkbase.  The US GAAP Taxonomy is pretty much guaranteed to have a 100% consistent relation between the presentation and the definition linkbase because the presentation needs to be correct in order to get the definition linkbase generated correctly.

Changing perspective by 180 degrees

When I really started thinking about this I realized that the definition linkbase metadata was very strict and enforced by XBRL.  When you expressed the relations information in the presentation linkbase (like the US GAAP Taxonomy) you had to build validation to enforce the relations.  Then I thought about the calculation linkbase.  That has metadata also.  There is also metadata about computation relations in the XBRL Formula linkbase for a properly constructed taxonomy, meaning that the computation relations in a roll forward (movement analysis) is needed.

This is when I had an epiphany!  The first part of the epiphany was that one could generate a presentation linkbase which looks like the US GAAP Taxonomy from metadata contained in the definition linkbase, the calculation linkbase, and XBRL Formula information which expressed computation relations which cannot be expressed in the calculation relations.  Not only could you auto-generate a US GAAP type presentation relations; you could generate ANY presentation "scheme" you desired.  All the presentation relations are is one organization of the real "information model".  The presentation relations themselves is NOT the information model, the metadata is the information model.  Basically, the mistake I was making was to think that the presentation relations WERE the information model!

Presentation can be created "virtually"

Taxonomies don't need a "presentation linkbase".  What they need is a way for business users can view the taxonomy.  What that is, it seems to me, is an organization of the metadata of the taxonomy in some useful form.  I can read those "tree view" interpretations, I have had to learn how because that is all that exists in today's software.  The typical business users will never be able to relate to those tree views, nor should they have to.  For example, think of the upside down calculation relations shown by most taxonomy tools and even by XBRL calculation validation reports.  Why can't these look more like the things accountants use today with the double underscore for the grand total at the bottom of the report, single underscores for sub totals, etc.

Well, it can.

The whole notion of "editing the presentation linkbase" and "editing the calculation linkbase" and "editing the definition linkbase" is a misdirection caused by thinking too much from an XBRL prespective and not enough from a business report perspective.  This is a mistake.

Is an information model important?  Absolutley!  Just like a database schema is important and a good data model is important, you do need to understand the data and follow good data modeling practices. But some contrived representation is not important, you can contrive any number of different ways of looking at the information model.  A tree view is only one.  The presentation linkbase is another, which can be expressed as a tree view.  But the information model and viewing the informtion model are two different things.

What business users need is more creative interfaces from software vendors.  To get that we need more consistent and well structured taxonomies.

Some possible issues

I can see a couple of possible issues.  The weights in calculations don't seem to be an issue, but potentially could be an issue.  It seems to me this would be more of a presentational issue, not an issue relating to a correct interpretation of the taxonomy metadata.  The hierarchies of the presentation linkbase might be an issue; although there are no restrictions of hierarchies in the definition linkbase.  Creating the XBRL Formulas for the roll forwards might be an issue, but I think not.  All that really needs to be expressed in a software application interface is the fact that there is a roll forward relationship between two concepts.  The XBRL Formula piece can be, again, auto-generated.

Bottom line

Business user, you care about this.  This is all about making XBRL easier to understand and use. Wouldn't that be nice?  Ask software vendors why they are forcing you interact with the XBRL syntax.

I thought the readers of my blog would be very interested in the following book:

Pull: The Power of the Semantic Web to Transform Your Business

The book, written by David Siegel, explains the Semantic Web in business terms.  The book has an entire chapter on XBRL.  There are 12 reviews, 11 are "5 star" and 1 is "4 star".  From one of the reviews:

"I was looking for something that explains the Semantic Web more from a strategic rather then a technical perspective. This book really helped me to understand how the Semantic Web can be applied. There are numerous real-live examples. From shipping products to health-care, tax, real estate, financial data (XBRL), search & security - everywhere you will find examples of businesses that already use or transition to the Semantic-Web."

The book has a companion web site which can be found here. One of the very interesting things about the web site is a series of "tours" of the Semantic Web.  Entrepreneurs, managers, investors, and standardistas each have their own tour.

Like I said in a previous post, business professionals who don't understand what metadata is is at a disadvantage.  The Semantic Web is important.  It is strategic.

I want to point something out.  XBRL has been referred to as "One of the more successful Semantic Web metadata formats."  XBRL started 10 years ago.  The US SEC and many other regulators around the world are "priming the Semantic Web pump", so to speak.  You may not want to become an expert in XBRL or the Semantic Web.  But it seems to me that at a minimum the "risk" that something is going on here is worth the price of the book and a few hours of reading it to see for yourself what is going down.