« Difference Between Data and Information | Main | US GAAP Statement of Changes in Equity is Very Odd »

A Contract for Meaning

I make it my business to understand how certain things work. What I have discovered is that if you understand how something works, then you have a better understanding of what you can do with it and what it will not work for.  Back when the Web was growing in popularity (early and mid 90's), I took a year off from work to study the Web because I thought it was important and I did not have the time to make the investment that I felt I wanted to make while having a day job.  That investment paid huge dividends for me in my career as a CPA.

Web 3.0, referred to as the Semantic Web, is a similar deal. There is a difference this time; I don't have to take a year off.  I actually get paid to understand these sorts of things now.  What I want to understand is exactly how XBRL fits into the Semantic Web.

Probably for five or more years I have been trying to truly grasp what is meant by "the Semantic Web" and how the Semantic Web will impact CPAs, internal and external financial reporting, and business in general.  Plus I wanted to know how XBRL will fit into the Semantic Web.  I cannot say that I am totally clear on the impact that the Semantic Web will have on business, but I am getting an idea.  What is becoming clear is how and why the Semantic Web will work and XBRL's role.

Resources to Understand the Semantic Web

I have read a number of books on the Semantic Web.  Two books in particular stand out, providing the most useful information.  These two books are:

  • Semantic Web for Dummies: This book provides a concise summary of key information in terms that a business reader can really relate to.  It really focuses on the issue of exchanging business information between business systems.
  • Programming the Semantic Web: Don't be scared off by the word 'programming' in this book.  The book has an excellent big picture summary of the problems the Semantic Web is trying to solve and how it will actually solve those problems.  It talks a lot about data modeling and has an excellent section titled A Contract for Meaning which is itself worth the price of the book.  You can skip the programming related sections in the book.

A Contract for Meaning

Business users should be able to relate to the notion of a business contract.  What does a contract provide?  It documents understanding between parties for a certain business transaction.  Having no contract at all can lead to misunderstandings and misinterpretations.  Not always.  A well written contract has fewer misunderstandings and misinterpretations, let's call those "issues".  Those issues cost you time and money.  If you don't agree, then you have to get expensive lawyers involved to sort things out.  Not good, for anyone except the lawyers.

Misunderstandings and misinterpretations (i.e. issues) can come up with business information transactions also.  Except that when the issues occur you don't call the lawyers, you call the IT department to solve the issue or more often you may just throw a person at the problem, that is called rekeying.  Both the IT department and those people that do the rekeying cost time and money.

How do you know if you got the business information exchange contract correct?  The system works.  That is the ultimate test.  You get consistent actions based on a set of data, the results you get are expected.  People take this for granted, in fact I think that people SHOULD take this for granted, at least the business users should.  But what makes it work?

What makes this work is that contract for meaning.  How do you write that contract?  Who writes the contract?  One of the things that I learned about in business is that if you are doing an important contract then you want your lawyer to write the document.  That way, you have better control of what goes into that business contract, the subtleties.  When you are creating an information exchange contract, would these better be written by business people or IT people?  If the IT people create that information exchange contract, how do you know that they got it right?  Business people need to be able to understand this stuff.

XBRL Taxonomies: A Contract for Meaning

One form of writing an information exchange contract is an XBRL taxonomy.  How many business people actually understand XBRL taxonomies?  I mean really understand them, not look at them and glean a little information.  Are you sure the XBRL taxonomy works the way you want it to work?  How can you tell if it does?

XBRL and the Semantic Web

There are a lot of forms in which information is stored: relational databases, multidimensional databases, columnar databases like spreadsheets, hierarchical databases, graph databases, object databases, and so forth.  Each type of database has its pros and cons, none is perfect, certain types are better in certain situations.

XML is a serialization or representation of information.  XBRL, an XML language, is likewise a representation of information.  XML is a web technology for exchanging information on the Web.  It is not the only one, there are others.

Web of Information

Let's say you want to query information but the information is in two (or more) different types of databases in two different businesses or government agencies.  That is what the Semantic Web is about, hooking all that information together.  The Semantic Web is about having some least common denominator that lets the databases work together to answer your questions.

How is that done?  That is what RDF (Resource Description Framework) does. RDF uses a technique which was also used by Aristotle during his lifetime in 384 BC to 322 BC where information is broken down into fundamental building blocks of "subject-predicate-object" relations.  Aristotle's logic was used in philosophy, long before computers even existed. These relations are expressed in the form of very flexible graphs.  (Note that XBRL networks are also graphs.)

Basically these subject-predicate-object graphs can be used to express any information.  They are quite flexible.  An ontology provides a precise meaning of the relations which can or must exist within these graphs, it is a way of controlling the graphs.  These models are expressed using OWL (Web Ontology Language).  Ontologies express formal rules.  This is the contract, a contract for meaning.  The purpose is to make it so different software performing specific actions get the same result.  Fundamentally what this means is that if you have the right ontology then things work as expected, if you don't have the right ontology then things don't work.  It is really as simple as that.

An XBRL Taxonomy is an Ontology

They are called taxonomies in XBRL, but they can really be a list, classification, taxonomy, or ontology depending what meaning you put in them. (To understand the difference see this blog post.)  Frankly, the syntax (XBRL, OWL, whatever) is not really relevant.  What is relevant is the meaning that is expressed and whether that meaning can be consistently interpreted by software applications.  An XBRL taxonomy and the related XBRL instance could be expressed using RDF and OWL and the business meaning of either syntax should be exactly the same.

Why this is Important to Business People

Remember what I said about the information contract earlier?  The part about the IT department getting involved and the rekeying.  That means time and money, something that business people can relate to. OWL, RDF, graphs, and subject-predicate-object relations may be harder to relate to. 

Building the right information models and understanding those models and how they work is important to business people.  Partly because it helps you get the right information model.  Another reason is because understanding how these sorts of things work and why they work can mean that you can use these tools strategically and/or tactically to make things better, faster, and cheaper.

XBRL is only one data format which will be part of the Semantic Web, note the capital letters, that is like the Web, the public network.  You will also have your internal semantic web or webs. Your internal webs will likely interact with the external public Semantic Web.

Everyone is a ".com"

I never really understood when people referred to a company as a ".com".  I think that people realize that every organization is a ".com" and needs to leverage the power of the Web, whether you are public, private, government, not for profit, or some other type of company.  It can mean losing sales if your company shows up on page 5 of a Google search, as compared to page 1.  Using semantic information can provide advantages over those what do not, be that information in XBRL or some other format.

If you thought that XBRL was only a regulatory mandate from the SEC or some other regulator, think again.  Just as people eventually recognized that everyone was a ".com", they will likewise recognize that fitting into the Semantic Web has its advantages.  The book Pull: The Power of the Semantic Web to Transform Your Business helps explain this.  You can find more information here.

XBRL is part of this, in fact some refer to XBRL as one of the most successful Semantic Web metadata formats.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (2)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

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.