XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

This blog post summarizes information which is helpful in understanding one of the more powerful but under utilized features of XBRL: XBRL definition relations.

First, it is important to understand a few important things.

An important thing to realize is that information can be exchanged to the extent that the information is clear and usable by the computer which is making use of the information. This blog post about attaining high semantic clarity explains that statement in detail. A part of that semantic clarity is to provide some sort of classification system. Classification systems differ in the amount or level of information they provide.

Here is a summary of different types of classification systems in order to show the differences between the many types of classification systems:

List: A list is just that, a simple list of things. A dictionary is an example of a list. All it does is provide a list of the "things" you are working with.
Taxonomy: A taxonomy provides a list of the "things" you are working with just like a list, but it also provides "relations between the things". A taxonomy provides one or more sets of these relations generically in the form of some sort of hierarchy which articulates relations.
Ontology: An ontology is similar to a taxonomy in that it provides a list of "things" and the "relations between the things". Ontologies tend to be more formal, more comprehensive. Ontologies provide representations of entities, ideas, and events, along with their properties and relations, according to a formal system of categories.

In essence, the difference between a list, a taxonomy, and an ontology is the thoroughness to which it expresses information about some domain which the list, taxonomy, or ontology describes.

There are all sorts of ways that lists, taxonomies, or ontologies can be created. There are four important factors to consider when you try and express the "things" and "relations between the things" in a domain.

Expressiveness: First, the expressiveness of the scheme you are using. How capable is the method you want to use to express the things, the properties of the things, the interrelationships, the properties of the interrelationships.
Standardness: Second, is the scheme you are using a global standard approach or is the approach proprietary.
Human readability: The scheme you use to express information needs to be readable by the domain experts who can tell you if the things and the relations of things are accurate and by technical people who have to build software to interact with your representation. Human readablity is important when the information is initially created and also for maintenance of the information.
Machine readability: Last but not least, the things and relations between things you express needs to be readable by computers who will make use of the information.

Many people who build formal, rich expressions of the information for a domain use OWL (Web Ontology Language) or RDFS (RDF Schema), both of which are global standards. One of the major problems with expressing business information using OWL or RDFS is that many times the business information is numeric and the relations between business information is computation related in nature and neither OWL nor RDFS handle the expression of that computation related information particularly well. To address that issue, the W3C created RIF (Rule Interchange Format) and a third-party created SPIN (SPARQL Interface Notation).

Most people don't realize that XBRL can also be used to create rich ontologies which express the things and relations between the things within a business domain. While most people understand how to express "the things" in the form of an XBRL taxonomy schema, general relations between the things using XBRL presentation relations, basic roll up computations using XBRL calculations, and to a lesser extent more complex computation and other types of relations using XBRL Formula; fewer people understand XBRL's power for expressing other sorts of relations.

Both a great example of what can be done with XBRL definition relations and additional semantics expressed by XBRL definition relations is the XBRL Dimensions specification. The XBRL Dimensions specification uses the power of XBRL definition relations to achieve its objective. One approach to learning about the power of XBRL definition relations is to reverse engineer the XBRL Dimensions schema. Check out the schema and check out XBRL definition relations provided in SEC XBRL financial filings and you can see how to wire things together.

Another way to learn about XBRL definition relations is to build something. This explains what I built.

The first thing you will want to do to express information using XBRL definition relations is to define the types of relations you will be expressing. This is done by defining an arcrole. Arcroles work like the predicate in an RDF-type subject-predicate-object relation. Defining an arcrole (predicate) is straightforward enough. Here are two examples which I defined: (both of these are prototypes)

RDF-type relations and whole-part type relations: These are some RDF-type relations such as "class-subclass" and a set of different types of whole-part relations which I defined.
Financial disclosure specific relations: These are some financial reporting specific types of relations which I created. I don't want to spend time explaining these relations right now, just consider these examples.

So again, defining the arcroles themselves are pretty straight forward. Understanding WHAT arcroles you need to create is harder.

A very important aspect of arcroles to understand is the XBRL Link Role Registry (LRR). Rather than have a bunch of different groups define arcroles which mean the same thing, there is a way to get your arcroles included in the global standard. These are existing arcroles which are in the global standard. The advantage of making your arcroles part of the global standard is that software support would likely be better and more consistent.

You can further describe information needed by your arcroles by putting properties on the definitionArcs. This is an XBRL taxonomy schema which I created with some made up properties.

Finally, I created relations between things and expressed those relations using an XBRL definition linkbase. The first definitionArc has the properties which I defined.

Now, XBRL definition relations work similar to the RDF-type subject-predicate-object scheme. In XBRL definition relations rather than using subject-predicate-object you use XLink (XML Linking Language) style syntax using from-arcrole-to. So by using XBRL definition relations and arcroles you define, you could basically redefine anything OWL or RDFS defines using XBRL.

If you want some additional examples, check out the financial report ontology. That contains plenty of examples.

A very good question would be WHY would you do this? Why would you define using XBRL what you could define using RDFS or OWL. Well, there are four primary reasons why I am doing this:

RDFS and OWL are insufficient: RDFS and OWL are insufficient for expressing all the semantics which need to be expressed for the domain I am personally interested in which is financial reporting. I need to make use of XBRL calculations, XBRL Formula. So basically, my goal is to implement everything that I need and all that is necessary for what I need to achieve using XBRL syntax.
Easier: I personally find this easier. The syntax is easier, the tools are easier to use. I have struggled, and struggled, and struggles trying to get the RDFS and OWL correct and I have not been able to achieve that goal.
Flexibility: Syntax really does not matter. What is important is to get the semantics correct. If the semantics are correct, then the syntax which is used to express those semantics can be converted to any other syntax. Basically this boils down to flexibility. I would suspect that people who know RDF syntax can take the XBRL-based information and then convert that information into RDFS, OWL, or whatever format they might desire really.
Standard: I want to avoid proprietary formats. There really is no point to reinventing some proprietary format if a global format works. I already have most of my information in a relational database already, moving to XBRL or RDF syntax, or any other syntax for that matter is a snap.

All this is like the wild, wild west currently. Who knows what syntax will be used in the future. Smart people are realizing the power of high semantic clarity in making machines serve humans, in attaining the quality level necessary, etc.