This web site provides information on how to use XBRL to help business users exchange business information. Business information incluldes both financial and nonfinancial information. Everything on this site made available to all under a Creative Commons License. Everything may be reused however one sees fit. All we ask is that you give credit where credit is due. If you have any questions, comments, concerns, suggestions, ideas or other feedback, please contact charles.hoffman@me.com.

The author of this web site assumes all responsibility for this web site and it's content. The views expressed on this web site are the views of the author and may not represent the views of his employer.

I have mentioned the notion of "decidability" when I did a blog post related to description logic. When I discussed the notion of decidability with others, many times they seemed to be lumping other things in with decidability.

And so, I am tuning and I think improving my ability to express what I am trying to say. This is an improved attempt to summarize and synthesize these ideas.

There appears to be four "logical catastrophes" or "failure points" that the type of business system that I am working to create and many other similar types of business systems MUST NEVER HAVE. These characteristics are so catastrophic to the system they must never exist. Besides, these characteristics never exist in the reality that the system is trying to represent in machine-readable form.

This is a summary of these four logical catastrophes or "failure points" which must never exist:

Undecidability: "I don't know" or "unknown" is NOT an option as an answer to any question. A big part of this is making the closed world assumption rather than the open world assumption. What is interesting is that XBRL 1.0 and I am pretty sure XBRL 2.0 allowed for explicitly stating whether the closed world assumption was being made. Also, relational databases make the closed world assumption. On the other hand, many of the "anyone can say anything about anything" folks working to build the semantic web take the open world assumption by default. It is not to say that one assumption is right and the other is wrong. It is to point out that one assumption works one way and the other works another way and business systems generally need to be decidable and would make the closed world assumption. And this is not an "either/or" type question. All one needs to do is be explicit and not make others guess. Digital financial reporting needs to make the closed world assumption and therefore be decidable for the reasons explained here. Why? For the exact same reasons OWL 2 DL makes the closed world assumption.

Infinite loops: It is not hard to understand the problems caused by getting into an infinite loop from which a system can never escape. The reality represented by the business systems that I want to create don't have infinite loops. Therefore, there is no need to express something as an infinite loop. Another term that helps to understand loops from graph theory or network theory is a cycle. This stuff hurts my head to think about, but the basics of what a business professional needs to know is the difference between a directed cycle and an undirected cycle. Basically, never use directed cycles, they cause potentially infinite loops. Again, what is interesting is that XBRL consciously provided a means to eliminate directed cycles from ever appearing in an XBRL taxonomy. I don't think OWL 2 DL has this ability.

Unbounded pieces; unbounded sets: First-order logicor also known as first-order predicate logic can only work on finite systems. An infinite system can never be explained successfully using first-order logic. The pieces that make up XBRL are: fact, characteristic, parenthetical explanation (XBRL Foot note), network, hypercube ([Table]), dimension ([Axis]), member, primary item ([Line Items]), abstract, and concept. EVERYTHING in XBRL is one of those things. You can add any number of those things. You cannot invent new things and arbitrarily add them to a system. While the XBRL Technical Specification does allow for the addition of new things; most systems created have some bounded set of pieces. Further, every set is likewise bounded. There is a specific, countable, number of facts in an XBRL instance; always. This blog post and this blog posthelp you see that the pieces that make up XBRL are well bounded. Likewise, every set of such pieces is finite.

Unspecific logic: It is not expected that the business system at the level of describing the things in the system be able to support "fuzzy logic" or "probabilistic reasoning" or other such stuff. Now, when you use the information from the system, you can do whatever you want. But, describing what is in the system and what is not is not a "probability", it is a fact and the answer is it is there or it is not there; there is no in between and the answer is not a statistical probability. For example, "What is the value of assets?," is a number, not a probability.

That is my best attempt at describing the requirements of the type of business system that digital financial reporting needs to be. This is not a personal preference, this is about science. This is the only type of system what will work the way professional accountants need the system to work. There are a lot of other systems which would have similar requirements. And this is not to say that other systems can have different requirements.

And so the question is this: What logic or calculus should be used to represent such a system? OWL 2 DL might work, but OWL 2 DL does not support mathematical computations because some such computations cause a system not be decidable.

XBRL can do this. There are exactly ZERO catastrophic failures if you read the entire set of XBRL-based financial filings which have been submitted to the SEC. Not one. While the closed world assumption is not explicitly stated, it is assumed. No infinite loops. A bounded set of pieces can be used to construct an XBRL-based report. A bounded, finite number of pieces exist for each XBRL-based report. Fuzzy logic was not used to create the reports, the creation rules are specific.

Now, within the XBRL-based reports there are mistakes in the articulation of meaning. Many inconsistencies such as that. But, that is not remotely close to a catastrophic failure. That is a detail. Those inconsistencies are being detected and corrected.

I would be very interested in the thoughts of others who are knowlegable about how to make such a system work. I am not 100% sure that I am describing this correctly. But I am 100% certain about what I am trying to achieve. What I really don't understand is exactly the best way to achieve it. I have some ideas, but I don't know the answer yet. So please let me know what you think.