Ghislain Fourny of 28msec, creators of SECXBRL.info, came up with the notion of the Cell Store which he describes in a paper he wrote on the subject. He describes a cell store as:
Cell stores provide a relational-like, tabular level of abstraction to business users while leveraging recent database technologies, such as key-value stores and document stores. This allows to scale up and out the efficient storage and retrieval of highly dimensional data. Cells are the primary citizens and exist in different forms, which can be explained with an analogy to the state of matter: as a gas for efficient storage, as a solid for efficient retrieval, and as a liquid for efficient interaction with the business users.
The XBRL standard helped to inspire the idea of the cell store. One thing that the paper does not mention but should have mentioned is the XBRL Abstract Model 2.0. The XBRL Abstract Model 2.0 basically articulates the high-level semantic model of a business report.
There are a handful of other adjustments that I would make to the Cell Stores paper.
First, the paper is not clear enough on how business rules are used to both enforce quality and enforce semantics between cells. Cells can be related to other cells. Part of the power of a cell store is the complexity of what can be represented. A perfect example of this is public company financial filings. Those are complex documents with many, many complex relations. Fundamental relations such as "assets = liabilities and equity" and more complex relations. These business rules are critical because they keep the information quality high. But the business rules provide something else: increased reasoning capacity of software applications.
Second, the notion of "concept arrangement patterns" and "member arrangement patterns" are not explained well in the paper and some errors exist. This is partly my fault. These names have changed (from pattern, to metapattern, to accounting concept arrangement pattern, and finally to concept arrangement pattern). These relations exist and they are critical to making this system work correctly. The notion of a "whole-part" relation is left out all together.
Third, the paper says that these concept arrangement patterns and member arrangement patterns exist "according to me". That is not the case. What I have done is observed and documented. These patterns exist in SEC XBRL financial filings. It is those financial reports that state that these patterns exist. I simply made the observation and wrote the information down. Empirical evidence proves that these relations exist, not my opinion.
Finally, the paper points out very clearly that XBRL enables the interchange of "data" between different systems. What the paper does not point out clearly enough is that not only can you exchange "the data" but you can also exchange "the model", the metadata. This is a crucial distinction. Which brings us to NOLAP.
Another notion that Ghislain came up with was NOLAP. NOLAP, which is explained in the Cell Store paper and which I explain here, overcomes issues with OLAP. Here is a summary of issues with OLAP:
Over the years I have mentioned the notion of a "semantic spreadsheet". NOLAP (not only OLAP) is essentially the same thing as my idea of a semantic spreadsheet. This video of the application Quantrix is the closest visual that I have of what a semantic spreadsheet is and how it might work. (Here are more videos)
But Quantrix has issues:
I point out these issues not to knock Quantrix, but to point out what NOLAP needs to be. Imagine a ubiquitous spreadsheet format (i.e. not owned by Microsoft) that works within Microsoft Excel, Google spreadsheet, Apple Pages, OpenOffice, connected to relational databases, other proprietary applications, etc.
The application is not like a normal spreadsheet which is "glued" together presentationally with the notion of a workbook, worksheet, row, column, or cell. The spreadsheet is glued together with meaning. Because the spreadsheet is glued together with meaning, in order to understand how to use it you only need to understand the meaning. The spreadsheet acts more like a pivot table. The pivot table is read/write. Information is stored not locally (although it could be, that format would be XBRL), but within a cell store. Or, the information could be taken out of one cell store and transferred into another cell store internal to your organization or external to your organization.
Folks, you don't have to imagine this. You can experience this, right now, today. Call me crazy, but the XBRL-based EDGAR system of public company financial information is exactly that. But there are some issues.
There are some details that are not quite working as they need to work. OK fine, fix the issues. Here are the issues and how to fix each issue:
Maybe I missed a few details. But that is all they are, details. I count 22 software vendors who already support the creation of XBRL-based SEC financial filings. 28msec already has a database. There are several other databases that I am aware of. XBRL Cloud has the validation capabilities, see their EDGAR Dashboard. There is already analysis software. What is missing is (a) software vendors collaborating to put these pieces together and (b) an understanding of the existence of a general application profile for doing this.
Companies that don't innovate risk becoming extinct. Do you want to take that risk?