Digital Financial Reporting

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...

I am continuing to fiddle around with RDF/OWL.  I updated my little index page which summarizes my brainstorming. I added an RSS feed to enable grabbing all of the ontologies with an application.  In doing that a question that popped into my mind is whether the "RSS feed" really should also be an ontology or in RDF rather than in RSS.  So, I did some checking.  I don't know that I got this correct, but I created an ontology of ontologies.  I will get to the correct approach, but if you look at this you should have the same questions that I had.

Another thing I tried to do is model all the pieces that I am seeing, which I did in this little box diagram. There are many things that I am seeing from that diagram which I will get to later in other posts.  One primary thing I see is something which I touched on before, but now want to expand on a little.

There seems to be a "spectrum" of approaches to implementing a system for exchanging information:

• Something: Some approach, proprietary pieces and standard pieces, does not even have to be XML, it could be JSON based or CSV files, whatever.
• XML + Something: You could use XML and the old approach of a DTD, and a bunch of other proprietary or standard stuff.
• XML + XML Schema + Something: You could use XML and XML Schema plus some other proprietary and standard stuff.
• XBRL + Something: You could use XBRL and some other proprietary and/or standard stuff.
• XML-based Language + Something: You could use some other XML language and then add some other proprietary and/or standard stuff.
• RDF + Something: You could use RDF alone and then add some other proprietary and/or standard stuff.
• OWL/RDF + Something: You could use OWL/RDF and then some other proprietary and/or standard stuff.

This analysis may seem odd, but I see two things.  First, each solution needs "something" more.  The second is that the something can be a combination of standard and proprietary stuff.  That "something" has a cost associated with it.

The truth is you probably have a multitude of systems which exchange information, maybe even one from every option in the spectrum.  Well, that is what the Semantic Web is about, solving the problem of multiple formats and using the information from all the different systems as one big set of information.  That grand vision is what RDF and OWL are for, the standard format.

So, what is that "something"?  Think about it.  Knowing that is really the $64,000 question.  Knowing the answer helps one choose between the different options.  What, you don't exchange business information with anyone?  Really.

I will look at breakind down that "something" in later blog posts.  Stay tuned...

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!