Digital Financial Reporting

I have been doing some experimentation with RDF, RDFS, OWL, and SPARQL.  I have not been able to create a lot so far; the learning curve is rather flat now. What I have created is interesting from a number of perspectives.

I am working with this randomly selected SEC XBRL financial filing. What I want to do is two things.  First, generated the model structure of the filing in RDF and second, validate the model structure against an OWL ontology (or RDFS) to see if is possible.

To start, consider a few things.  This is the presentation linkbase of that filing.  That is expressed in XBRL using XLink.  It is VERY hard to work with this raw XBRL.  No problem, send the XBRL file to an XBRL processor and generate an easier to use XML infoset.  If you look at that XML infoset, you can start to understand the model.  It is way easier to use that the raw XBRL/XLink.  Next, I serialized that exact same information in RDF. 

If you look at that you might say two things. First you might say, "Now wait a minute, that is harder to read than the XML infoset." And you would be right.  The second thing you might see if you looked at this is the remarkable parallel between XLink and RDF.

All three of those technical syntaxes say EXACTLY the same thing: the XBRL presentation linkbase expressed in XLink, the XML infoset in just raw XML, and the RDF.  EXACTLY the same thing.

However, there are HUGE differences between the three serializations.

1. The XBRL presentation relations expressed in XLink can be validated.  BUT, it can be validated only to the extent that the XBRL processor understands the information.  All XBRL processors understand the XBRL syntax of course.  HOWEVER, what XBRL processors do NOT understand is how the presentation relations should be structured, whether those presentation relations are consistent with the XBRL calculation relations and XBRL definition relations.  Why? Well, because XBRL only has "parent-child" (http://www.xbrl.org/2003/arcrole/parent-child) type relations in the presentation linkbase. What does the parent-child relationship mean?  What relations are allowed?  You cannot express that in XBRL beyond "parent-child" and you therefore cannot validate that you are building the relations correctly or consistently across all linkbases with XBRL.
2. The XML infoset relations are WAY clearer.  They are WAY easier for a human to read, WAY easier for an XML parser to work with, and ALL the information you want to work with is there.  (If you go back to the XBRL presentation relations you will note that you have to go grab information from the XSD file to have information about the report elements.)  If this format is so much better, then why doesn't XBRL use this format?  Well, because the XML infoset format is not extensible.  That is WHY XBRL used XLink.  But there is something else wrong with the XML infoset format.  You still cannot tell if (a) the information expressed is CORRECT and (b) you cannot tell if the information is CONSISTENT with the XBRL calculations and XBRL definition relations.  You can write a validator very, very easily to perform the tests to see if the relations are CORRECT; but, that is work.
3. RDF (work in progress), I think, can solve the validation problem.  I say "I think" because I have not actually gotten this to work yet.  THAT is what I am trying to make work. (I did get this to validate per the W3C RDF validator.)

To do this, I first built a simple ontology using OWL.  This is the ontology.  If you look at this and criticize how bad this is right now, you are totally missing the point.  Yes, it is bad.  I don't understand how to best use OWL yet.  (If YOU do, please rewrite the OWL ontology, sent it to me, and I won't have to spend the time figuring this stuff out. Please!)  Not helping things is the fact that if you think XBRL is flexible and hard to use, you should try RDF, RDFS, OWL, and SPARQL!!!  So why do I bother?  Well, (a) because it is far easier for me and other business people to use RDF, RSFS, and OWL than it is to learn to program all this stuff but more importantly (b) there are WAY, WAY, WAY more things that I want to be able to validate.

To fiddle around with the RDF I am using Protege.  (This is a web based version of Protege, works in Google Chrome, does not seem to work in Microsoft Internet Explorer)  Now, Protege is not a business user tool.  VERY hard to figure out.  But again, it is worth it.  Part of Protege is a SPARQL query tool. Here is my first SPARQL query (paste it into Protege, try it for yourself):

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

PREFIX model: <http://www.xbrlsite.com/2013/FinancialReportOntology/ReportElement.xml#>

SELECT ?subject ?object WHERE { ?subject model:hasAxis ?object }

Why am I doing all this? Folks, this is extremely powerful stuff! There is an absolute boatload of leverage which seems achievable from RDF, RDFS, OWL, and SPARQL. That is what the Financial Report Ontologyis all about.  Other domains have created ontologies.  Economics. Biomedical. Others.

Frankly, I don't get all the details of this stuff yet.  But, then again, I did not get XBRL when I first started either.  But, hundreds if not thousands of hours trying to figure this stuff out is paying off. I can tell you this...while it might be a lot of work for accountants to understand this technology stuff; it would be WAY more work for technology people to grasp accounting.  Business users don't need to learn everything about the technology; just enough to communicate effectively to the technology people who do understand this stuff.

Inline XBRL is not a panacea or other "magic bullet" which will make all problems related to XBRL go away.  Some people seem to believe that it is some universal solution for all that ails XBRL implementations.

This is the way I see the moving pieces related to using Inline XBRL.  First off, it is really not a question of "Inline XBRL" (some people call it iXBRL) or not.  There seem to be the following factions applying XBRL to financial reporting. You have your:

1. Inline XBRL camp
2. Datapoint Model camp (includes Table Linkbase)
3. Global Filer Manual camp (this includes the SEC and US GAAP Taxonomy implementation of XBRL, used for SEC XBRL financial filings)
4. "Go it alone" camp, they just ignore what everyone else is doing

Are these seen as alternatives which are 100% interoperable?  XBRL is a "global standard", why would these not be interoperable? Camp #4 means less than 100% interoperability. So, throwing out option 4, will there ever be one global approach to creating a digital financial report?  Well, that really boils down to whether there will be a world with only IFRS or whether there will be a world with both IFRS and US GAAP. So say we are looking for one and only one approach.  Which is best?  Or, does it matter; are all three approaches interoperable/interchangeable?

So that begs two questions: (a) What does each approach offer? (b) What common issues do all three approaches share?

There is an issue which Inline XBRL, Data Point Model, and the Global Filer manual camps share.  I will give you an example of that issue in a moment.  But first, let me decouple that issue from another issue which many people confuse as the only issue.

The issue is obtaining a human readable rendering of information communicated by XBRL.  Both Inline XBRL and the Data Point Model try and solve this rendering issue.  It is my view that both the Data Point Model and Inline XBRL are both trying to solve something that I am not 100% sure is even a problem.  But, it could be a problem.

The problem is commonly seen as "viewing the information."  I am 100% certain that Inline XBRL solves that problem to the extent that HTML can solve that problem because (a) Inline XBRL uses HTML and (b) HTML does a pretty good job with getting very close to "pixel perfect rendering". 

I am pretty sure that the Data Point Model, which uses the lesser understood table Linkbase, gets very close to what HTML can do if not 100% at the same as HTML and therefor does the same thing as Inline XBRL.  I can believe that from this "viewing the information" perspective, Inline XBRL and the Data Point Model (with the table linkbase) are equivalent.

So from that perspective, let us just say that the two are equivalent.  If they are not, then the specific differences should be quantifiable.

While the Global Filer Manual (of which SEC XBRL financial filings is a subset) are rather poorly rendered by the SEC Interactive Data Viewer and most other software in many cases (and therefore does not seem like an adequate solution); there are generally two reasons for most or at least many rendering problems:  (1) poorly modeled information and (2) rendering engines which do not leverage known information semantics.

And so what I am saying is that it might be possible for an "adequate" rendering could be achieved by simply improving modelings and leveraging information, patterns, within those models.

If it is the case that a rendering engine understands information semantics, and if it is the case models are constructed correctly and consistently; then it is in the realm  of possibility that a rending engine can create an understandable and useful rendering.

Now, that rendering will not be "pixel perfect" or exactly as every person would want to see it because there are so many DIFFERENT ways people might want to see this information.  But, would be a usable rendering?  I am about 98% sure that such a rendering is possible, but because I have not seen such a rendering for 100% of all use cases I cannot say for certain that I am 100% sure.

So, the REAL questions are: (a) what is the target rendering the market needs, "pixel perfect" or "usable" and (b) is it possible to hit that target leveraging what exists in the XBRL instance and XBRL taxonomy plus know and agreed upon semantics and patterns in those semantics of the information.

And so those two questions (what is the target and can that target be achieved) is different than the real thing which ails XBRL.

This issue will NEVER be solved by Inline XBRL nor by the Data Point Model as far as I can tell.  This issue can likewise be broken down into two parts: (a) do domains express enough metadata so that interchangeable models can be created and (b) does XBRL have enough expressive power verification capabilities to verify that good models are being created?

In my view, this is the REAL issue.  XBRL cannot capture enough of the semantics which are necessary in a global-standard way to build high-quality, interoperable financial information which can be effectively exchanged.  Just to remind you again, neither Inline XBRL nor the Data Point Model address this issue.  Also, just packing the XBRL definition linkbase with "stuff" will not solve the problem.

If you look at this visualization of an ontology for a financial report that I am creating you will start to understand what I mean:

http://xbrl.squarespace.com/journal/2013/1/18/financial-report-ontology-draft.html

Like I said, this problem has two moving pieces:  First, many times the semantics are not defined by reporting standards and second, XBRL has no agreed upon way to express the semantics. 

While pretty much anything can be expressed using the XBRL definition linkbase (such as how XBRL Dimensions uses the XBRL definition linkbase to express and then validate multidimensional information); the important point is "agreed upon way to express the information". 

To understand what I am saying all you really need to do is look at the expressive power of something like UML (Unified Modeling Language) which is a modeling tool and how you can have different types of relations (associations, aggregations, etc.) and how UML can express those use cases.  Or, if you look at RDF/RDFS/OWL and the expressiveness of those tools and then if you think of how you would express the same information using XBRL, you then begin to realize the limitations of XBRL for expressing needed information.

A specific example of XBRL's limitations is XBRL Dimension's expression of meaning of the relationships between the members of a domain.  All you can do is basically express that there is a relation, which is unlike UML or RDF/OWL which lets you express the type of relation.

Another example of this is how one would express the relations between the components of a reporting entity.  The 2013 US GAAP Guide, published by Wiley, provides an excellent example of both an inadequate expression of the semantics of the components of a reporting entity by US GAAP (this is NOT a problem of XBRL, it is a problem within the domain of financial reporting) and exactly the type of relations which need to be expressed. 

US GAAP defines terms used to describe these sorts of entity components differently in different places within US GAAP.  It also uses different names and does not even define some terms which relate to expressing the components of a reporting entity.

This includes such terms as parent holding company, consolidated entity, reporting unit, asset group, disposal group, subsidiary, business segment, geographic area, business unit, legal entity, operating segment.  (I am NOT saying that some of these terms are not defined.  Some are.  What I am saying is that some of these terms are not defined, some are defined ambiguously in GAAP, some are defined in multiple ways but mean exactly the same thing.)

If you try and model information about the relations between the components of a reporting entity then you begin to understand what is necessary from XBRL to make information expressed using XBRL truly interchangeable between business users (i.e. no ambiguity).  Further, you gain additional insight if you look at the current set of SEC XBRL financial filings.  If you do so you get an even better understanding of the limitations of XBRL and the needs of any reporting scheme or system making use of XBRL appropriately to make the information usable.

Like I said, neither Inline XBRL nor the Data Point Model (with the table linkbase) solves this problem.  And therefore, if one moves to Inline XBRL or the Data Point model, one will be disappointed that the move did not get you where you really wanted to be.

Another thing which is related to this is that I now understand the problem which some people had with XBRL Dimensions.  Its expressiveness is missing certain key pieces. 

This is a work in progress, so stay tuned!  I have created a financial report ontology. The "things" used in the financial report ontology will be defined in human readable terms here. A visual representation of the "things" can be found here.

Still to come is a UML (Unified modeling language) representation and an RDF/RDFS/OWL (Semantic Web Technologies) representation.

Why am I doing this?  See here and here.

If you want to participate and learn a lot, please contact me and I will get you dialed in.

This information is taken from the TopQuadrant web site, Ontology Development page. I am still trying to understand some of this information.

More people understand CSV files (comma separated values), relational databases, Microsoft Excel spreadsheets, and perhaps even XML for approaches to storing and using information better than they might understand an ontology. (See this blog post if you are trying to understand what an ontology is.)

Ontologies are powering the next generation of software applications. Ontologies are active models of information that are like and unlike other information modeling approaches you may be more familiar with:

• Like databases, ontologies are used by software applications at run time to provide information to the users of the software applications. HOWEVER, unlike databases, relationships in the ontologies are ‘first-class’ constructs, have rich explicit semantics and are used locally or globally because the nature of the information and the syntax of the information can be exchanged between business systems (as opposed to use being restricted to your internal database because the syntax is proprietary or the semantics are hard coded into the software)
• Like object models, ontologies describe classes and attributes (properties). HOWEVER, unlike object models, ontologies are set-based. (I don't understand what this means, I will try and figure this out...watch for a subsequent post.)
• Like business rules, ontologies encode business rules which are basically some formal and implementable expression of a user requirement; HOWEVER, unlike business rules, ontologies organize rules using class structures (they are formally grouped), they are written using a global standard format, which means that the business rules can be effectively exchange between business systems.
• Like XML schemas, ontologies are native to the web and can be serialized in XML; HOWEVER, unlike XML schemas, ontologies are graphs (not trees), can be used for reasoning, an infinite number of explicit relations can be expressed (rather than the one implicit relation of an XML schema).

XBRL is closer to something like RDF than it is to XML Schema. In fact, that is why the elements within an XBRL taxonomy are "flat".  XBRL tried to overcome the limitations of XML Schema by using only parts of it.  This is why tuples in XBRL are so bad for extensibility; they basically go back to using XML Schema.

The XBRL definition relation is similar to RDF-type expressions of information.  Definition relations are somewhat standard in that they use XLink.  But, it does not seem that XLink is catching on.

This webcast is an excellent introduction to SKOS, Simple Knowledge Organization System. This is part of resource made available by the W3C for SKOS, which you can get to here.

This is a SKOS System Organization Primer.

The most important thing which I got out of this webcast was a better understanding exactly what SKOS brings to the table and the difference between a controlled vocabulary, a thesaurus, a taxonomy, an ontology:

• Controlled vocabulary. Basically a set of standard terms.  For example, "Yes" and "No" is a controlled vocabulary.  May seem odd; but one could also use "yes" and "no"; "true" and "false"; "yeah" and "nay"; you get the point.  A listing of postal codes for each of the states in the United States is a controlled vocabulary.
• Taxonomy. A taxonomy adds the notion of a hierarchy between the members of a controlled vocabulary.  For example, the terms "horse" and "cat" and "dog" are all types of "mammals".
• Thesaurus.  A thesaurus provides a specific type of relationship, a similar term, a broader term, or a narrower term.
• Ontology. An ontology allows you to define your own types of relationships; specific, explicit types of relationships rather than general "parent-child" type relationships.

So SKOS is the global standard way for defining controlled vocabularies, taxonomies, thesauri.  SKOS is also a standard way to build other ontologies, it seems.  SKOS leverages the standards RDF and OWL.  So basically, SKOS is a standard way of using the RDF and OWL standard to extend the SKOS framework.  So, SKOS is extensible in a controlled manner.

Why is this important for XBRL?  Two reasons.  First, this clearly shows the weakness of things like the "parent-child" relationship in the XBRL presentation relations.  "Parent-child" has no real meaning.  But, people building taxonomies (a) imply meaning, (b) imply meaning differently thus creating inconsistencies, (c) don't communicate that meaning to others using the XBRL taxonomy.  This is true of both the IFRS and US GAAP financial reporting taxonomies.

Second, the XBRL definition relations DO provide a mechanism for communicating meaning of relations.  For example, the XBRL Dimensions specification does exactly this, defining "all", "not-all", "hypercube-dimension", "dimension-domain", "domain-member" relations.  Now, these are more technically oriented-type relations; but they are explicit.  Other explicit type relations can be defined.  However, is XBRL the best mechanism for articulating more relationships?  Is SKOS better? Or OWL?