Digital Financial Reporting

This metadata stuff keeps getting more and more interesting. A post I made to the LinkedIn group Semantic XBRLled to someone mentioning SKOS.

SKOS, or Simple Knowledge Organization System is a standard way to express metadata.  A W3C recommentation, is described this way by an introduction to SKOS:

SKOS provides a standard way to represent knowledge organization systems using the Resource Description Framework (RDF). Encoding this information in RDF allows it to be passed between computer applications in an interoperable way.

Using RDF also allows knowledge organization systems to be used in distributed, decentralised metadata applications. Decentralised metadata is becoming a typical scenario, where service providers want to add value to metadata harvested from multiple sources.

Here is a SKOS primer. Here is a SKOS wiki. Here is an introduction to SKOS provided by XML.COM. Here is a SKOS reader. RDF-Gravity reader.

This is how I see it. You can express metadata using any ole XML.  But, there is leverage if you not only use XML, but rather use the standard such as RDF/OWL.  But even using RDF/OWL you have a lot of flexibility as to how to express things.  SKOS provides an even higher level standard than RDF/OWL for the specific purpose of expressing metadata used in knowledge management systems.

So I used RDF/OWL to express the major categories, topics, disclosure objects, and disclosure templates used for some things I am trying to achieve relating to financial reporting using US GAAP.  Here is that metadata.

Seems that following the SKOS standard provides an even higher level of possible interoperability. Could be wrong, but SKOS seems like the way to go, a standard form of RDF/OWL for the sort of metadata I need to model.

Microsoft PowerPivot helps one see the possibilities which something like XBRL enables. PowerPivot is an Excel add in with gives users the flexibility they need but at the same time gives the IT department the control they need. This videohelps you get an understanding of PowerPivot. (Gemini was the initial name for PowerPivot.) This videoshows how and information mashup can be put together.

I have not tried PowerPivot yet, you need Office 2010 to use it. But now I am very motivated to upgrade and try this free Excel add in. Mr. Excel in the second video says this about PowerPivot:

"Greatest thing I have seen coming from Microsoft in 15 years."

Imagine a PowerPivot "database" (not sure what to call it) which combines information internal to your organization and information external to your organization working seamlessly together to help you manage some aspect of your business supply chain. I have heard this called "external analytics".  Your data set is connected to other data sets external to your organization.  Perhaps the SEC XBRL data set as an example of one publicly available standardized set of information.

Not interested in public company financial information?  That is not the point. While the SEC XBRL data set itself might not be useful to you, think of other data sets which could be useful.

There are four overarching trends which work together to make this sort of vision possible:

• The Internet. If we were not all connected together there would be less of a possibility to be able to exchange information because of the expense of doing so. Lots of people exchanged information before the Internet existed, now anyone can exchange information with anyone else for pennies. I am talking about the Internet here, not the Web. If you don't understand the difference, you definitely want to read about how the Web is dead.
• Model based reporting. Business intelligence (BI) applications are growing in popularity. One example of this is how BI applications are changing the last mile of finance. One of the core pieces of BI is use of the multidimensional model which provides flexibility.  You can use the same piece of information in different ways. The important piece here is not BI, it is the flexibility of the multidimensional model. This OLAP Council white paperhelps you understand why the multidimensional model is important.
• Structured, standard data formats. Unstructured information such as a word processing document or HTML file or PDF file makes reusing the information in those files impossible. But structured information can be put into a database and reusing it is quite easy. But you need your database to connect to someone else's databaes. So if one database is going to be connected to another database; what is the standard database format which you are going to use? Well, of course, it is your database format, right?  Well, others with different database formats would likely disagree. There is no standard database format. Nor should there be. But, you have to somehow link systems together and you need some syntax to do that. XML, RDF/OWL, XBRL, CSV, it really makes little difference.  As long as the format is understood, technically anything can be integrated.
• Semantic and process interoperability. In addition to the technical interoperability, you still need semantic interoperability and process interoperabilityto achieve business system to business system integration. An example of this is how I can use my Apple iMac and create a video in iMovie and then upload it to Google's YouTube.com.  Two different applications, two different companies, working together seamlessly.

All this sound mind-numbingly complicated to you?  Don't worry about it.  That is what technical people do, they make stuff like this work. What is important to understand is that fundamental changes are coming to business processes.  One example is financial reporting.

Don't be fooled into thinking that the SEC's little experiment with XBRL is a misguided regulatory mandate which does little more that add unnecessary costs to a process which works fine today. The SEC is being quite progressive, not something one might expect from a government agency. What the SEC is doing is only part of a larger global trend started by little regulators like the Dutch Association of Water Board as early as 2004 and bigger regulators like the Federal Deposit Insurance Corporation (FDIC), and others. These government regulators are only priming the pump.

While I do think PowerPivot has its short comings such as it requires you to have Excel (i.e. it is proprietary to one vendors software) and it cannot be used to create content, only report on content and it seems to be focused on numeric information (i.e. I have not seen it handle textual information); PowerPivot is a very nice piece of software which helps one see the possibilities.

I mentioned in another blog post that I was creating a prototype State Fact book and using that to compare and contrast XML, XBRL, and RDF. This expands on my brainstorming in another blog post where I was trying to figure out which of the three (XML, XBRL, RDF) were "best".  I expanded that to also include XHTML and iXBRL.

Most of the "raw data" for this comparison is located on this page, the State Fact Book Index.  On this page there are 8 different sets of information.  Each of those sets are made available in XHTML so you can easily see what the data looks like.  I also made each available in XML.  Three sets are available in XBRL (but those three sets contain 100% of the information for the other sets).  The first set also contains an iXBRL (inline XBRL) example and an RDF example. I may, or may not, build out RDF, XBRL, and iXBRL for each set but I really don't need to because I am seeing the things I need to see.

The Story of the Three Bears

Remember the Story of the Three Bears? I am seeing a similar story when I compare and contrast XML, XBRL, and RDF.  Let me leave XHTML and iXBRL for later.

This is what I am seeing: 

• XML is general purpose.  You can use XML for many, many different types of information exchange needs. When you use XML though, you generally start from scratch unless you create some sort of framework to work within. I talk about how, for example, NIEM building an XML framework in this blog post.  The framework helps you be more efficient and effective. That is a good thing.
• RDF powerful, can become complex and is general purpose.  You can do anything with RDF also. RDF is for doing something different than XML.  RDF is for expressing semantic meaning which is way more powerful that XML which is a syntax.  RDF is also somewhat of a least common denominator.  If you wanted to get all the information in the world to be able to work together, you would use RDF to do that.  In fact, that is pretty much the goal of the Semantic Web. Like I said, RDF is extremely powerful and once you start getting into making use of that power, it can become complex.  RDF tools are not really usable by the typical business user.
• XBRL seems like a compromise between XML and RDF. XBRL is a general purpose language also, but its "general purpose" is does not mean everything, the focus of XBRL is on business reporting.  So, it is more of a general purpose business reporting tool.  XBRL can become complex like RDF because it is quite powerful. It is not powerful in the same way that RDF is powerful.  Again, you can do anything with RDF.  XBRL is for business reporting, it is optimized for that scope.  Software which works with XBRL at the syntax level is easier to use than RDF software, but in my view it will still be over the heads of the typical business user. But, it is possible for business users to use XBRL tools to build quite sophisticated solutions using XBRL.  It would be hard for me to believe that these same business users can figure out RDF tools.  Personally, I struggle with RDF and RDF tools.

Making XBRL Less General Makes it Easier to Use

Like I said, XBRL is a general purpose tool for business reporting.  Business reporting is a broad category and XBRL has features or many different business reporting use cases.  But each use case will not need to leverage all the power of XBRL in all areas, different domains and use cases will need different pieces of XBRL.  And making XBRL less general makes it easier to use.  This is where application profiles are helpful.

While the average business user would never be able to use an XBRL tool which operates at the XBRL syntax level, applications build for more specific purposes can be very usable by the average business user.  For example, from what I have heard business users tend to struggle with XBRL software for reporting to the US Security and Exchange Commission in XBRL.  Extending the US GAAP Taxonomy can be challenging for business users. Building the XBRL instance can be challenging.  A lot of companies outsource the entire process to third parties, thus loosing the real value that XBRL could provide.  For this reason, people see XBRL as a regulatory mandate, not for what it really is.  I anticipate that this situation will come to an end when software applications are built specifically for US GAAP financial reporting using XBRL.  That is all they do, these will not be general XBRL tools.  But because they are more focused, they will be easier to use.

So, you can get what I see as an order of magnitude increase in usefulness by turning general XBRL into one or more specific XBRL profiles and building specific applications for each profile. This can happen for two reasons. First, some of these domains are quite large.  For example, US GAAP financial reporting is huge.  The SEC filers number about 20,000.  That is plenty large. Non SEC filers who use US GAAP is somewhere between 8 million and 16 million private companies (these are the estimates I have heard).

The second reason is leverage.  XBRL is an XML framework.  For the same reason you would build an XML framework if you are making use of different forms of XML; you will get leverage when you use XBRL as a framework.  XBRL does have well defined boundaries.  Tools can stay inside those boundaries and provide good bases of functionality.  Complexity can be absorbed by applications by really smart business users or technical users who understand a business domain building profiles other less skilled business users can make use of. This is done by the profile constraining the base application.

Not Either/Or

RDF is also an XML framework.  There are may different RDF syntaxes, but there is one in XML.  But the fact of the matter is that the syntax does not even matter.  There are many things that business reporting needs from RDF which XBRL cannot provide and XBRL should never provide.  There are things which XBRL has today that will eventually be built for RDF such as rules.  XBRL has business rules via XBRL Formula.  RDF is known to need this and things like RuleML, the W3C has an initiative to create a rules language.

Semantic "Haves" and "Have nots"

I think the bottom line here is that if you believe that Web 3.0, the Semantic Web, will exist and from what I can see the evidence is mounting that it will and this will be very useful technology; then you will want to be someone who can use this new power.

XML isn't really a solution, it is more part of the problem because XML is really is about syntax, not semantics. You can make XML "semantic" in many cases, that is what RDF is for.  RDF is quite powerful and there will be many very sophisticated things created using RDF for business users.  Most will not be created by business users themselves.

XBRL is a nice compromise.  It enables a business person to leverage these new  semantic technologies in ways they choose.  It is somewhat like the personal computer and the electronic spreadsheet empowered business users, setting them free from the IT department.

It is possible for a business user to use general XBRL. I can, I am a business user.  I know others who can. Most business users will interact with XBRL and harness the power of semantic technologies via application profiles for more specific use cases making things easier and therefore useful. These applications will likely combine XML, XBRL, RDF, and other technologies.

Semantic Web utopia may never be realized, I think it is a vision, something to be strived for.  But the Semantic Web is coming.  In fact, it is already here and ramping up.  Do you want to be a semantic have or semantic have not?

#######################

Second Coming of XML

I added an additional data set to the State Fact Book prototype I am creating. That data set, which is Set-08, has population trends for the US states and the District of Columbia between 2000 and 2009.

Here is a walk through of how this was done. Hopefully this will give you an appreciation for some of the things XBRL (and other XML syntaxes) can provide. If you take the time to walk through this, you might be able to see some value which XBRL brings to the table.

I am using data from this US Census web site which provides population estimate information. I am using the "National population dataset".  That data set is explained by this PDF file (File Layout).  This is the actual data file (CSV File).

The first thing to note is that the information which describes the data (i.e. the PDF file) is not reference by or connected to the data itself.  When people say XML is "self describing", part of what that means is that the XML both contains the data and describes the data.  XBRL does this also.  The XBRL instance is the data, the XBRL taxonomy describes the data.

Another think to notice about the data is that it is "flat".  CSV shows rows and columns.  You cannot really model complex relations.  If you wanted to relate this data file to another data file, you can do it, but there is no way to validate that you got the relations correct, unless you build tools to check the relations between two different CSV files.  XML and XBRL can connect the data and the information which describes the data (which is referred to as metadata).

I grabbed the CSV, got it into Microsoft Excel which is very easy, then got the Excel into Microsoft Access, again very easy.  I put the information into Access because Access is vastly easier to use to do some things I need to do.  What, Access easier than Excel?  Yes, I need the relational database functionality of Access.  You can do this in Excel, but again, you have to build your own relations.  Why do that when Access can do it for you better.

I used Access to generate XHTML, XML, and XBRLversions of this data. Now, all these formats are "XML".  They are just different syntaxes of XML.  The each has semantics expressed, but each expresses the semantics in different ways, sometimes explicitly, sometimes implicitly.

One piece of the semantics which is not explicitly expressed in the CSV or XML or HTML is that the numbers are supposed to add up.  Each state plus the District of Columbia adds up to the total US population.  XBRL can express this.  In this case, the population trends XBRL taxonomy information which consists of two things, a definition linkbase and a formula linkbase expresses this information. Those two pieces, combined with the general XBRL taxonomies used by the state fact book information gives me this report when run through an XBRL processor which supports XBRL formula.  This report shows that the information adds up correctly.  You can run the XBRL through any XBRL application and you will get the same results because XBRL, a global standard, specifies the rules of how XBRL works, and different software vendors implement those rules.

Validating that the numbers add up does two things as explained in this blog post.  First, it documents what should add up.  Second, it proves that it does add up.  A lot of people first don't realize how big a deal this is.  They think, "Well, I do validation in my application to check to see if things add up."  You have to build that validation and you cannot exchange it with anyone else, because it is proprietary.  With XBRL the validation rules can be exchanged and they are rules engine based and can be used many times, not just once in your system.

A final point I want to make is that the population trends information, the general information, and the financial information can all easily be hooked together.  Those three data sets use the same base metadata which is expressed in the XBRL taxonomy each uses.  Grab the XBRL from the index page (the blue image which says "XBRL" on it).  Try the following:

• Hook the financial information and population information together.
• Separate the population information by "red", "blue" and "purple" state.
• Create your own data set and connect it to one of the data sets from above.

You can actually do this with XML, XBRL, or RDF.  Each syntax has its pros and cons.  I will be discussing those pros and cons in future blog posts.

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.