Digital Financial Reporting

I took the Comprehensive Example, created two additional copies (so that I have three companies), and now have the Comparison Example.

The Comparison Example is the capstone of what someone is likely trying to achieve in XBRL: comparison of some set of business information.  There are three ways business information is commonly used:

• Using a single information set:  For example, using one financial report.
• Comparing across periods: For example, comparing your financial report over a period of time.
• Comparing across entities: For example, comparing three entities at one point in time or for a period of time.

The Comparison Example was created to test these use cases. These three XBRL instances and related XBRL taxonomies are as identical as they can be.  Each company has its own meta data where it needs to.

When you look at this example, consider where the meta data is defined.  There are four levels here in this example:

1. Company taxnoomy: Defining concets at this level provides the least comparability as it is defined at the company level, but at the same time it provides the most flexibility because the company can define anything it wants.  If the GAAP taxonomy follows the FRLM and BRLM, then the compnay does also.
2. GAAP taxonomy: This gives improved comparability because different companies share the same GAAP.  It does not have to be this way, conceivably every company could create their own XBRL taxonomy and create great XBRL.  But, if every company did that individually, comparisons would still be possible, they would just be difficult becuase you would basically have to physically map one company to another.
3. FRLM (Financial Reporting Logical Model) taxonomy: This level provides comparability between GAAP taxonomies, should that be desired.
4. BRLM (Business Reporting Logical Model) taxonomy: This can be use by different domains who want to leverage the Business Reporting Logical Model.  The advantage here is that if a software application were developed at this level, anything above it in this list would be comparable with that software.  The software would still be XBRL compliant, i.e. the BRLM is 100% XBRL compliant.
5. XBRL: Defined by XBRL. Here, you have the least amount of flexibility (i.e. you must follow XBRL to be XBRL compliant) but you also have the most comparability. If everything was defined at this level it would be very comparable, but not very flexible. Basically, if everything were defined at this level it would serve one business domain and would basically be a form.

The level at which things are defined is determined by the business domain applying XBRL. The advantage of the BRLM level is that it allows users to be clear about the business semantics they are using and software applications can leverage that clarity, making the software and XBRL easier to work with.

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

This blog post summarizes several other blog posts.  It may seem rather stream of consciousness and be along the lines of brainstorming, if it does that is because that is what this blog post is.  I am summarizing this information to help myself understand it and learn to better communicate it to other business users. It is hard to say how many years of thinking have gone into this.  But I have to answer this question over and over and I wanted to understand the real answer for myself. The questions are which is 'better': 

• Is XBRL is 'better' than XML, 
• Is RDF/OWL is 'better' than XBRL
• What considerations go into deciding which syntax (XML, XBRL, and RDF/OWL are all syntaxes) is 'best'

The first thing one needs to do is define the problem you are trying to solve.  In general, the problem which seems to need solving is getting business information out of one system, be it internal to your organization or external to your organization, and then automating the process of using that business information within another business system.

Helpful background information

Here is some information which provides helpful background in understanding the moving pieces of this issue. This may seem like a lot of stuff to know, and it is.  But if you want to understand the moving pieces and make the right choice, you do need to understand the moving pieces or have someone help you who does.  This is not about providing you with a two minute sound bite, this is about providing you with the information you need to truly understand the issues you need to consider.

• Structured information, not unstructured information: Two points here.   First, I am talking about structured information.  Second, the world is moving toward structured information because computers cannot parse unstructured information reliably enough and it costs too much.  This video, How XBRL Works, helps you understand the difference between the two.
• Structured for meaning, not structured for presentation: I am talking about information structured for meaning, not information structured for presentation.  Again, the How XBRL Works video helps you understand the difference.
• Global standard, not point solutions: If information is structured you can always convert it into some other structure using some mapping process.  If everyone used their own structure, everyone would have to map to everyone else's structure.
• Use XML:  There are many different data formats.  The world is standardizing on XML.
• Many different forms of XML: There are many different forms of XML.
• Many different forms of XBRL: There are many different forms of XBRL.
• Many different forms of RDF: There are many different forms of RDF.

XBRL builds upon XML

In a previous blog post I explained how XBRL builds on top of XML.  Let me summarize these points here, you can go to that blog post to drill into this information further.  This is also explained in my book XBRL for Dummies (page 33)

XBRL's "Sweet Spot"

XBRL has a 'sweet spot'.  This sweet spot is discussed in my book XBRL for Dummies (page 172) in detail, I summarize the points for you here. 

• Flexibility within rigid systems
• Reconfigurable information
• Rules engine-based validation
• Clear communication and sharing of rich business-level semantics
• Metadata-driven configuration, no IT involvement required
• Zero tolerance for errors
• Achieving agreement with exterior parties

XBRL, RDF/OWL, and the Semantic Web

When people talk about the Semantic Web, terms such as RDF and OWL come up as the information formats of the Semantic Web. If RDF/OWL are the formats of the Semantic Web, then it seems obvious that all information should be expressed in RDF/OWL.  Right?  Do away with all other information formats, move everything to RDF/OWL and life will be good.  That is the only way where you can write "queries" on the information on the Web, if the information is in the same format.

RDF/OWL has benefits beyond what XBRL can provide.  These benefits seem to be:

• OWL has way more power to express semantic meaning than XBRL.  That is what OWL is for, expressing semantic meaning within an ontology.  XBRL is more in the "taxonomy" expression business than the "ontology" expression business. (To understand the difference between a dictionary, a classification system, a taxonomy, and an ontology, see this blog post.)
• RDF/OWL are the W3C information formats for the Semantic Web.
• RDF/OWL can express anything, XBRL is more focused on business information. 

Bottom line: XML, XBRL, RDF/OWL; Which is 'Best'?

From what I can tell, the answer to the question of whether to use XML, XBRL, or RDF/OWL is that it depends on what you are using it for.  What is crystal clear is that XML, XBRL, and RDF/OWL are syntaxes.  What is important to business users is semantics, not syntax.  What ever syntax you choose, you should be able to convert it to any other syntax, be that an external exchange format or an internal storage format such as your relational database.  The semantics (meaning) must be the same in any business system or the information exchange simply will not work.

There are lots of obvious places where clearly XML is the way to go. It seems XML is perfect for specifying large, fixed documents such as DocBook, expressing Excel spreadsheets, XHTML, and such.  XML is also perfect for fixed transactions which rarely change.  What seems to be key here is "fixed".

For "ad hoc" projects, tightly controlled systems which are closed, XML will probably work fine.  When you start talking about enterprise class systems, lots of users, the need to scale, things which need to be rock solid, you need to have some sort of framework.  XML frameworks can be created. NIEM is such a framework (National Information Exchange Model).  The NIEM Introduction provides a very good explanation of why frameworks are important.  Basically, frameworks provide discipline and leverage.

XBRL is a framework.  It provides discipline and leverage.  A primary benefit of XBRL is XBRL Formula, the ability to model business rules in a global standard format.  Being able to express those business rules means that you can validate the semantics (not just the syntax) of information in a global standard  way and exchange those business rules with others. XML cannot do this, it probably never will be able to.  RDF/OWL cannot do this now, but the W3C seems to be working on this.

RDF/OWL offers a powerful tool to express complex semantics in a global standard way, far beyond the capabilities of  XBRL.  RDF/OWL will be the least common denominator of the Web, the way to get different syntaxes to be able to work together.

It seems as though the answer to the question about which is better is that it depends on the system you are implementing really.  What is clear is that clear semantics are critical.  RDF/OWL can help in this regard.  If you cannot clearly express your information model in RDF/OWL, then your information model is broken.  If you can express your model in RDF/OWL, the least common denominator of the Semantic Web and a very powerful tool for expressing semantics, then it will not matter what syntax you use because you will be able to convert to any syntax and the RDF/OWL will document exactly how to do that.

A lot of these details are discussed in my book XBRL for Dummies. The book lays many of these things out so business readers can get their heads around them and understand the right questions to be asking the technical people who have to help them use XML, XBRL and RDF/OWL within their business systems.  The area of RDF/OWL is rather weak in the book, but the key concepts are there.  Watch my blog for more information should you need such information.

More exploring and discovering.  I was able to find some ontologies for XBRL which others have created.  See this web page: http://rhizomik.net/html/ontologies/bizontos/.

On that page, you see several ontologies which relate to XBRL:

• XBRL Instance: http://rhizomik.net/ontologies/2007/11/xbrl-instance-2003-12-31.owl
• XBRL Linkbase: http://rhizomik.net/ontologies/2007/11/xbrl-linkbase-2003-12-31.owl
• XLink: http://rhizomik.net/ontologies/2007/11/xlink-2003-12-31.owl
• XL (Low level stuff used by XLink:  http://rhizomik.net/ontologies/2007/11/xl-2003-12-31.owl
• US GAAP Taxonomy Piece (note that this is an old version): http://rhizomik.net/ontologies/2008/07/us-gaap-ci-2005-02-28.owl

This is stuff is way, way, way too low a level to be even remotely useful in making use of XBRL information.  Maybe this level is necessary, I really cannot tell yet.  But, what is the utility of an OWL model for the XBRL syntax at this level?  Even this level is really too low!

What I am attempting to do with my OWL model is to map the upper level stuff (financial reporting, multidimensional model, taxonomy concepts) to the lower level XBRL syntax which should ultimately be invisible to business users.

Perhaps my XBRL syntax level needs to be connected to the lower level stuff for some technical reason, I really don't know at this point.

Maybe I am missing something, but from what I have seen there appears to be a not seeing the forest through the trees situation when people are trying to reconcile how XBRL and RDF/OWL fit together.

Pressing onward...

Like I had mentioned in several other blog posts, I have been fiddling around with RDF and OWL to try and understand what RDF and OWL can be used for and how they relate to XBRL.

Well, I have some initial prototypes which I was able to put together:

• Prototype Ontologies: These are some prototype ontologies.  I started off creating one ontology and then quickly realize that there are really a number of ontologies working together here, it was better to break them up, to modularize them. The ontologies "link" to one another, or should.  I don't have all those linkages in place yet.
• Prototype RDF: This is information about the US GAAP Taxonomy expressed in RDF.  Here is an HTML version of what is in the RDF file. What the file does is create something readable by a computer application to help them work with the US GAAP Taxonomy files.  For example, imagine a software interface being built which will help a use of the US GAAP Taxonomy find and pick the files they need to use.  (This is as compared to having to read the documentation and ferret through the files to find them.)

I am learning quite a bit. RDF by itself is kind of like using XML without an XML Schema.  What I mean is that XML can be "well formed" but if you don't follow an XML Schema it is easy to break your application or go outside the bounds of what an application expects.  OWL serves somewhat of a similar purpose for RDF.  It "guides" the directed graphs created by RDF, it seems, helping to articulate what is logical and allowed and what is not.  OWL also seems to provide short cuts for articulating relations.  This may not make sense to people, I admit I am not doing a great job of explaining this right now.  More later.

Another thing I am learning is that several people have expressed XBRL in RDF of have talked about it.  From what I am seeing thought is that all attempts appear to be focused on the XBRL syntax.  Personally, I think this is a misguided approach.  This may be minimally useful for some things, but it seems to fall incredibly short of what OWL and RDF really could provide.  OWL is a great way to express the pieces of the domain of financial reporting, how the pieces interrelate, and in ways you can use that information within a software application.

I get the impression that XBRL people seem to be a little "fearful" of OWL/RDF; and that OWL/RDF people think that XBRL is making a big mistake and that XBRL International should have used OWL and RDF for expressing the XBRL syntax.  I don't really understand either of these views.  OWL and RDF did not even exist in a form where they could really have been used by the creators of XBRL.  The use of RDF was discussed and was considered too immature at the time.

Both RDF/OWL and XBRL are syntaxes. XML and XML Schema are syntaxes also.  What is more important is what you can do with the syntaxes.  This is not an either/or deal.  One should be able to switch between RDF/OWL, XBRL, XML/XML Schema just like on can switch between HTML, PDF, and Word syntaxes.  Those are just syntaxes.

What is more important is the semantic model of the domain.  Express that in whatever syntax.

Now, something else that I am realizing is that in order for RDF/OWL or XML/XML Schema to be truly useful one needs to build, on top of those syntaxes, much of what an XBRL processor provides.  That is where the magic is for business users.  The fact of the matter is that most XBRL processors don't even go far enough; they focus on the XBRL syntax!  We need another layer above the XBRL syntax for XBRL to be truly useful in a business domain, for example the domain of financial reporting.

For example, take a look at SEC XBRL financial filings.  All the applications which I have seen focus on the XBRL syntax level of the problem of creating SEC XBRL filings.  I have not seen one that leverages the domain model or the US GAAP Taxonomy Architecture.

Contrast the SEC XBRL implementation to the FDIC implementation of XBRL.  Not many (I am not aware of any) FDIC filers use XBRL tools to file with the FDIC.  They all use specialized software which is used to create bank call reports which are to be filed with the FDIC.  Why can't specialized software be built for doing SEC XBRL filings?  Why can't that specialized SEC XBRL filing software be as easy to use as FDIC filing software?  Well, frankly, I think specialized SEC filing software can be built.  That is my point.  And that software will be vastly easier to use than generic XBRL software.

Even better would be if software was adaptable to either the FDIC, the SEC, or other implementations of  XBRL.  What if XBRL software was configurable to a number of profiles?  After all, all these have to ultimately generate XBRL.  These application profiles should be built not focusing on the XBRL syntax but rather on the business domain semantics.

More later...back to fiddling around with RDF and OWL.  Come on in, the water is great!