Radically Tailorable Tool

In 2009 I authored a blog post, XBRL Killer App: A Radically Tailorable Tool. In this blog post I would like to revisit that same notion. Back in 2009 I could only use my intuition and imagination to contemplate that such a "radically tailorable tool" is possible.  Now, I have more a more tangible understanding of exactly how such a radically tailorable tool might actually work.

Models were invented for a reason.  Models can serve many purposes.  Below you see a visualization of a logical model that I defined for a financial report and use in my Seattle Method: (here is the same thing for a general business report)

Of course, that is a visualization that is understandable by a human, perhaps a business professional or information technology professional.  There are other more formal and detailed representations of such a model such as in an axiomatic theory, XBRL, in UML, RDF (prototype SBRM), and other such formats for representing information with clarity.

Imagine being able to dynamically configure or reconfigure a software application using metadata provided within some model.  Imagine being able to "tailor" a software application to your needs by simply reconfiguring declarative metadata as contrast to having to write software code.  How valuable would that be?

In a paper, Experiments with Oval: A Radically Tailorable Tool for Cooperative Work, the authors contemplate such a "radically tailorable tool".  The authors provide the notion of a "tailoring language" which might include objects, views, agents, and links.

Auditchain Labs AG Luca Suite software application is not a radically tailorable tool.  Meaning, the GUI/UX of Luca Suite is not dynamically autogenerated from the above model of a financial report or business report.  Further, the financial report model metadata does not have all the information that is necessary to provide that sort of capability. But you can dynamically configure the information in the application by using different reporting scheme models.

However, I believe that (a) the financial report model could be built out using, say, RDF + OWL + SHACL and then it could have all the necessary information to enable such an application to be autogenerated and (b) I can see how software can read that provided information and, quite possibly, autogenerate an entire software application dynamically.

In fact, there are pieces of the Luca Suite application that give clues that such an autogenerated software GUI is very possible.  This HTML is of a report is completely autogenerated by Luca Suite from XBRL-based information and common knowledge. And this Inline XBRL is also autogenerated and has even more capabilities than the HTML.

As an example, here are three characteristics within Luca Suite that are reconciled to the financial report model shown above.

Structures

Here are the six different types of structures (Network, Component, Hypercube, Block, Fragment, and Disclosure) implemented within Luca Suite reconciled to the financial report model:

Luca Suite has all those different types of structures because each is necessary to provide different perspectives into the reported information.  But if a strict report model were used, then only perhaps the Block and Disclosure view might be necessary.

Report elements

Formal names are used to work with the different types of report elements.  Luca Suite uses the terms "Hypercube" and "Dimension".  US GAAP and IFRS reporting uses the terms "Table" and "Axis".


Views

Various different views are provided within Luca Suite which are consistent with the views provided in the financial report model.
Other software might not want to or need to provide all these different views into the information being worked with in a different software application.

Under the current reporting paradigm, spreadsheets tend to be too flexible and don't have the appropriate guardrails; while software applications tend to be too rigid and don't offer enough flexibility for some tasks.  A radically tailorable reporting tool can offer a middle ground.

Everything is information.  An application GUI is defined and generated through formatting information provided by what might be seen as an "information plane" for rendering that GUI.  Currently, that information is provided within software code in most all software applications.  Why can't this application logic information be stored as declarative rules rather than in the form of code?  Doing so can make a software application "tailorable" to certain specific needs and enable business professionals, as contrast to programmers, do this sort of tailoring. Composition of a GUI can easily be driven by declarative rules.

Processing I don't quite get my head around quite yet.  Maybe smart contracts can drive processing. Maybe software can be dynamically configured or "complied" by pulling a bunch of declarative information together rather than writing functional code. This is the way XSLT works.

Additional Information:












Comments

Post a Comment

Popular posts from this blog

Microsoft CEO: "AI Agents will Replace All Software"

Image
We have entered the "agentic era"; the era of the agent or intelligent software agent . Others refer to this as the "algorithmic economy".  Maybe think many very intelligent  microservices  exchanging information with each other and can work globally. In an interview with BG2, Microsoft CEO Satya Nadella predicts that (paraphrasing) SaaS (software as a service) is dead and that AI agents will replace all software. The entire interview is the first link in "Additional Information" below.  These three videos provide a focused look at this statement: LinkedIn post including short video AI Insights Explorer video  (Microsoft CEO Predicts: "AI Agents Will Replace ALL Software") Microsoft CEO's Shocking Prediction: "Agents will replace ALL software" Here is my personal interpretation of what Satya Nadella is saying and what it means.  First, Nadella says that we are "on the brink of a monumental shift".  I agree with that statem...
Read more

New Tool for Accountants, Auditors, Analysts

Image
A new type of tool will be available (is becoming available) to support professional accountants.  This tool is somewhat similar to the traditional electronic spreadsheet but it works differently and provides different capabilities to professional accountants. This new tool will supplement the arsenal of tools available to accountants, auditors, and analysts. This new tool is semantic oriented, model-based, and a global standard technical format.  To describe this tool in the past I have used the terms " modern spreadsheet " and " professional knowledge graph " and " deductive apparatus " and " semantic oriented accounting and audit working papers " and " knowledge product " and " logical spreadsheet " and " logic programming " and " logical digital twin of financial reports ". This new type of tool will help usher in modern accountancy . In this new era, machines will support accountants, auditors, and ana...
Read more

Named Graphs

Image
A named graph is a concept in the Semantic Web architecture where a set of Resource Description Framework ( RDF ) statements (a graph) are identified using an internationalized resource identifier ( IRI ). This allows for descriptions to be made about that set of statements, such as context, provenance information, or other metadata. In an RDF database, a named graph is essentially a subset of data that has been given a unique label (referred to as a name). A graph database can contain multiple named graphs alongside its default graph, and each fact can be present in or absent from any graph. Named graphs form a patrician of information that can be used. Named graphs are useful for managing sets of RDF data within an RDF store, enabling fine-grained access control, and managing chains of provenance for pieces of data. Additional Information : Named Graphs (ScienceDirect) Graph Search Algorithms: Developer's Guide Named Graphs, Chapter 5. Data Management Patterns Wolfram, Nonahed...
Read more