« OLAP Cube Tutorial | Main | Pull: The Power of the Semantic Web to Transform Your Business »

Having Second Thoughts about Using Presentation Linkbase to Express Information Model

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.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.