See Future of Reporting Using Wikidata
On a conference call I was on the other day, someone mentioned Wikidata. I knew that Wikidata existed, but I really did not understand what Wikidata really was, how it worked, or what you can do with Wikidata. And so I thought it was time for me to kick the tires of Wikidata and figure out what it actually was.
To learn about Wikidata I modeled the accounting equation and SFAC 6 elements of financial statements using Wikidata.
Seeing what I could do with Wikidata can totally changed my life.
Wikidata calls itself a "free knowledge base that anyone can edit". But what Wikidata is is much, much more than that. Wikidata is a well engineered cloud-based, web-based collaborative platform. Wikidata is free, anyone can read from the knowledge base or write/edit to add or change information in the knowledge base similar to how you can modify Wikipedia. Not only can humans use the GUI/UX to create/read/update/delete (CRUD); so can machines.
Another thing which does not seem to be highlighted very well by Wikidata is that it can be semantic oriented. While the "data" aspect is interesting; personally I wish Wikidata were really Wikiinformation. Wikidata currently looks like a big mess to me. But hidden inside that mess are jewels. Wikidata is pretty much a free-for-all at the moment; but over time that will be sorted out.
What is the most enlightening thing about Wikidata is getting information OUT of Wikidata. Wikidata Query Service is the tool for getting information out. The query service is based on the W3C standard SPARQL. SPARQL is flexible, powerful, standard, and extremely hard for the average person to actually use. However, don't be fooled by SPARQL's complexity. Most people will not need to use raw SPARQL. Leveraging high-level models and clever GUI/UX designs, SPARQL will be used "under the hood" with great affect.
I say what you could do with SPARQL way back in like 2013. TopQuadrant's TopBraid is the tool that I saw. What TopBraid could do with SPARQL influenced how I thought about XBRL-based reports.
Wikidata's Query Service is an excellently engineered piece of software and a very cool tool. What is particularly interesting is the capability to provide a RESTFUL URL to the query tool.
So click on this link and your web browser will open a query, specified by the RESTFUL URL, within the query tool. Press the BLUE BUTTON on the left to run the query.
But what is even more interesting is this. Click on this link which simply adds "embed.html" to the query URL and you see the query results only, rather than the tool.
While creating SPARQL is hard, I actually successfully used ChatGPT to generate SPARQL queries that run on Wikidata query tool. That simplifies things a lot, but it is still too complicated for most people to use, just as SQL is too hard for most people and SPARQL is an order of magnitude harder that SQL.
Now, try this. Open the URL above (this) and look on the LEFT and RIGHT side of the query on that HTML page. You may need to move the mouse cursor or hover over something to see those two sets of icons. Hover over the icons, you get a menu with additional options.
If you see what is going on, then you likely see the same thing that I do. If you don't get it; don't worry, software developers will get you the tools to work with so you don't have to imagine the possibilities.
This is what I see. So imagine having a similar sort of mechanism for XBRL-based reports. Imagine being able to query an entire report or a “block” of information or an entire “disclosure”. But rather than the complexity of Wikidata (you have to know SPARQL) you use a higher level model, Standard Business Information Model (SBRM). What you would see might look more like this example below of an XBRL-based financial report. Granted, what I am showing below is simple, but what you could se is anything in my Showcase of Reports. What you see looks like the screen shot below with TABS being optional views of the information in the BLOCK or DISCLOSURE. You can see this today in Auditchain Luca. Basically anything from that Showcase of Reports would work this way: (here is the actual report below)
Now, Auditchain does not have an easy way to query like this, but it DOES have the query capability and similar infrastructure via SWI-PROLOG. You can see this via the Auditchain Pacioli Power User Tool. That tool is built on top of SWI-PROLOG. SWI-PROLOG using XBRL basically offers similar capabilities as Wikidata.
But XBRL-based reports using the Seattle Method offers even more. Verification. A leverageable high-level model so users don't need to work with lower-level technical artifacts.
Also, you can work with one BLOCK of information. You can recast that query and use ANY or ALL information from one report. Or, you can query across an entire repository of XBRL-based reports. This is “information as a service”. Further, all of the information is VERIFIED. Verification is BUILT IN. While Wikidata is a bit of a “free-for-all”, the Seattle Method DOES NOT ALLOW THAT free-for-all. The Seattle Method provides “boundaries” and “guardrails” to guide business users in the right direction to successfully SPECIFY reporting schemes, CREATE reports per those specified reporting schemes, VERIFY that a report is consistent with the reporting scheme, ANALZE information from one report or across a repository of reports. Comparisons, etc.
Twinfox.ai also sees this vision. They refer to this idea as a "logical twin", a term they coined. I personally use the term logical digital twin of a financial report. Think "logical Lego blocks" of information that can be configured by a query of a knowledge base; just like Wikidata does now in that example.
That is where all this XBRL-based digital reporting is going. And this is not just for financial reports. This works not only at the financial report level, but also at what I call the "mezzanine" level (accounting working papers, audit schedules), and at the transaction or business event level if you have that detailed information available.
Personally, this is one heck of a vision. Not only is it a vision, it is unfolding as we speak. TopBraid, SWI-PROLOG, Wikidata already does this. What makes you think this is not possible for XBRL-based financial reports? While you do have to use your imagination a little to understand; TopBraid, SWI-PROLOG, and Wikidata prove that this works. Other platforms are being created which provide similar capabilities such as TerminusDB.
Capabilities such as rules engines or reasoners integrated with the database, being able to use any resource provided anywhere on the internet or within a private intranet with proper access rights make solutions even more compelling. Graph databases will very likely provide similar capabilities using the new global standard GQL.
Additional Information:
Comments
Post a Comment