« Understanding Application Profiles | Main | Auditing SEC XBRL Filings »

Another Step Toward Understanding OWL, RDF and How They Relate To XBRL

This is another step in the journey of understanding OWL, RDF, and how they relate to XBRL.  You can see other blog posts relating to this here.

OK, so I think I am getting more and more dialed in as to what OWL, RDF, and XBRL offers.  At this point I am not totally sure about this.  Consider this blog post brainstorming. I will use this post to get feedback from others who understand these things better than I do and then tune my perceptions.  So be sure to check back later to see where these perceptions end up.

RDF, OWL, and XBRL are all "graphs".  Or maybe I should say that they all share the same approach, graphs, to articulate information of some sort.  That approach was chosen because of the flexibility of graphs to expressing information.  You can do a lot with "subject-predicate-object" relations.  These "subject-predicate-object" relations where not invented by computer science.  Aristotle and Socrates, long ago, used these types of relations in philosophy it seems.

RDF is a "global standard way" of articulating subject-predicate-object relations.  It is a general tool.  It can articulate any subject-predicate-object relation.  If is very flexible.  It is very verbose.  There were lots of different syntaxes for expressing the RDF, one syntax which seems to have been catching on is the XML format of RDF. (I found another useful primer on all this here.)

One issue with RDF is that is that you can express ANY subject-predicate-object relation, whether it is logical or not logical.  OWL is used to express constraints on the subject-predicate-object relations.  (It is also somewhat of a "short cut" approach to creating "common" relations it seems.  But, lets not focus on that).  It seems as though OWL is sort of like a "schema" for the RDF if you understand XML Schema or database schemas.  Basically OWL expresses constraints on the RDF which software can use to determine if the RDF expressed "follows the rules" so to speak.  This is critically important just like a database schema is important or an XML schema is important.

OWL is very, very "powerful".  It goes far, far beyond what a database schema can express or an XML schema can express.  OWL can be used to express semantic meaning, it seems like ANY semantic meaning which can be expressed can be expressed in OWL.

XBRL's architecture uses "graphs" to express many things.  Those that created XBRL did this because XBRL needed flexibility.  The approach of using graphs gives you the flexibility.  You have subject-predicate-object relations in XBRL.  Again, remember that pretty much anything can be expressed in this manner, so clearly XBRL should be expressible in this manner.  And in fact some technical people "expressed XBRL in OWL" (I say this loosely).  You can see those OWL ontologies here.  It is something only your mother could love.  Basically, what they did is run a style sheet over the XBRL schemas and converted them into OWL.  They took one syntax, XML Schema, and converted it into another syntax, OWL.  Not really that useful for business people.  Might have some sort of technical use, that will be seen later.

Now, XBRL took some additional "short cuts".  RDF is built to express anything.  XBRL is built to express business information, a subset of "anything".  Could RDF/OWL be used to express the XBRL syntax.  Yes.  Is this useful?  I think it does have some utility.  But, there are better uses for OWL than expressing a logical model of the XBRL syntax.

So, XBRL is a "short cut" to expressing business information in a form that computers can make use of.  XBRL is a general format.  No one uses "XBRL".  Everyone uses some subset of XBRL, some application profile. This is why the COREP taxonomy does not work with the US GAAP Taxonomy.  Every XBRL taxonomy or system has a different "application profile" because it uses a different architecture.

It seems to me that one thing OWL can be used for is to "express" or "document" those different application profiles.  Other things can be used to model an application profile of XBRL, UML for example could do this.  OWL could be a very, very valuable tool for documenting an application profile.  Today application profiles are either not documented at all or rather poorly documented in a Word document or PDF.  No computer can read those documents.  Computer programmers have to read the documents, extract information, and build applications to work with the different XBRL application profiles.  For example, here is the US GAAP Taxonomy architecture.  Here is the SEC test suite.  Here is the CEBS FINREP taxonomy architecture.

I really don't know if it is possible for an OWL ontology to be constructed and for software to automatically generate "tests" of the XBRL application profile.  That could be nice.  But, having a consistent way to document XBRL application profiles could be nice.  UML could be that way.  OWL could also be that way, it seems.

But there is another thing that OWL can be used for.  What I am seeing is that anything can be expressed in OWL.  Well...almost anything.  There is one big constraint.  What you want to express has to be logical.  If it is not logical, it cannot be expressed.  Therefore, if it IS logical it CAN be expressed.  Additionally, you can see WHAT is expressed!  That is even more interesting and has more utility.

For example, OWL can be used to articulate where a taxonomy can be extended, what the information model can look like, what is allowed, what is not allowed, and so forth.  OWL basically can document how things work.  For example, you could use OWL to document how the US SEC XBRL filings "work".  By seeing that, you can determine things like does it work the way you WANT it to work.  Or, is there a better way.

Another way OWL might help XBRL is adding additional information to XBRL.  Now, XBRL can be used to add additional information.  For example, the definition linkbase of XBRL can be used to express "arcroles" and things which can be used to express meaning.  For example, the XBRL Dimensions specification did this.  But is XBRL really the best way to express additional information?  The XBRL way has its pros and cons.  The OWL way also has its pros and cons.  Does it really matter?  XBRL and OWL are only syntax.  The important thing is that what is expressed is logical, it is done in as standard a way as possible, and it works.

One final thing which I want to mention before I wrap up this post is my realization that RDF/OWL does seem to have one very significant thing "missing".  I really don't know if I really should say it is missing, more it is something that to really make use of RDF/OWL information you have to build domain specific software on top of it.  Like I said, RDF/OWL can be used to express anything.  Its biggest strength is also its biggest weakness.  Because it can be used to express anything, you have to write software which understands the specific subjects, the specific predicates, and the specific objects and does useful things with those relations.  There is one thing which I admit that I don't really grasp yet (at least one thing, could be more).  Software can be built which "learns" from the relations, building additional relations.  This can be useful, but I cannot grasp this right now.  This is in the realm of artificial intelligence.  Maybe this will work, maybe this will not.

By contrast, an XBRL processor only has to understand XBRL.  An XBRL processor can easily convert XBRL into RDF/OWL.  To understand the RDF/OWL syntax but more importantly the SEMANTICS as well as an XBRL processor, you would basically have to rebuild the functionality which exists in an XBRL processor into an RDF/OWL processor.  Why would you do that?  Besides, XBRL processors don't even work at high enough level, they still deal mostly with syntax, not enough with semantics.  And I am not talking about things like XBRL Formula which verifies if the semantics is correct.  I am talking about DOING USEFUL THINGS with the expressed semantics.  No general XBRL tool does this at the level a business person would find particularly useful these days.  I would also point out that XBRL is ahead of RDF/OWL in regard to having a working method of validating semantics.  XBRL has XBRL Formula, the Semantic Web folks have something in the works (i.e. they do realize that this is important).

It seems that no matter what happens, XBRL is going to have to fit into the Semantic Web.  Getting XBRL into RDF/OWL is trivial for an XBRL processor.  Doing anything useful with the RDF/OWL is going to take more than want XBRL processors offer these days.  What an RDF/OWL engine can learn from, say, a data dump from XBRL from something like the entire SEC XBRL filing database could be quite interesting.

So that is what I seem to be seeing.  Not totally sure if I am correct on all of this or any of this.  The next step is to float these ideas by some people who grasp these things better than I do and see what they have to say.  Discussions with some of them have yielded what I have thus far (i.e. this blog entry).  But, there is still a ways to go.

One thing that I can say with a pretty high level of confidence is that if you live in this information age and you are a business person and you don't understand what metadata is and what you can do with it you are at a distinct disadvantage.

What is your opinion?


Posted on Saturday, January 9, 2010 at 07:45AM by Registered CommenterCharlie in , , , | Comments1 Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

Excellent summary! It seems the needs to "write software which understands the specific subjects, the specific predicates, and the specific objects and does useful things with those relations." are achieved by writing SPARQL query these days, but I do agree that something smarter would be preferred which can "learn" how to make senses of the triples...
January 22, 2011 | Unregistered CommenterXian

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.