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:
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!