In a RuleML technical memo; Graph-Relational Data, Ontology, Rules; Harold Boley points out that there tends to be three general paradigms for problem solving using machines: knowledge graphs, graph databases, and logic programing. In that paper he provided a graphic that showed the intersections of these three paradigms.
The following is an enhanced version of that same graphic. Dr. Boley helped me make the adjustments. Different organizations use different problem solving paradigms. In fact, within many organizations different paradigms are used. So how do you cross between different paradigms? RuleML's PSOA helps with that.
Saying the same thing in a different way; different people and organizations have different preferences in how they store, retrieve, process, and make available information. Those different approaches can be grouped into those three categories. But effectively, you are using "data" and "ontologies" (or ontology-like things) and "rules". You are storing information in the form of a "tree" (a graph really) or a "table" (a database).
(Note that different people use different terms to describe the same thing or what could be different things; I may be using terms in different ways than you are used to so I am describing each term in detail)
- Knowledge graphs: By knowledge graph I am specifically referring to the W3C semantic web stack. This approach uses RDF, SWRL, OWL, N3, SHACL, SPARQL, and other such W3C standard technologies for representing data, ontologies, and rules. Other terms for this are enterprise knowledge graph. One top knowledge graph vendor is TopQuadrant. This is TopQuadrant's description of knowledge graphs.
- Graph databases: By graph databases I am specifically referring to graph databases that will ultimately support the forthcoming ISO standard graph query language (GQL). I am pretty sure this means labeled property graphs such as Neo4j. But it might mean something else; here is a list of software vendors that seem to be behind ISO standard graph query language. The GQL Manifesto is a good explanation of what is going on here.
- Logic programming: By logic programming I am specifically referring to Modern Prolog on top of relational (SQL) databases. By Modern Prolog I mean SWI Prolog or Scryer Prolog or something similar that is both safe and powerful. This Wikipedia article on logic programming describes this paradigm. Note that Answer Set Programming (ASP) is included in the logic programming paradigm.
So what PSOA RuleML does is tie these paradigms together. PSOA RuleML is a "translation" or "bridging" mechanism. Because each of the three paradigms above use different terminology, structures, association types, rule types, and other such philosophies, there needs to be some sort of "Rosetta Stone" to tie things together.
Remember the days before the internet when there was no one global standard network protocol? That all changed with the invention of the Web Browser. See this history of the Internet.
TCP/IP was not necessarily the "best" network protocol, but it worked and everyone ultimately agreed with and supported that standard. It is that agreement that created the magic of the Internet and World Wide Web.
Will people ultimatly agree on some standard problem solving paradigm? Maybe, maybe not. Does there need to be only one? I don't know.
What I do know is that I have been able to represent XBRL-based financial reports using all three of these paradigms and convert from one paradigm to another. Effectively, the SEC's implementation of XBRL, the ESMA's implementation of XBRL, and the SBRM implementation of XBRL (a) fit into that PSOA RuleML intersection box and (b) can be used to create a provably properly functioning logical system. The SEC, the ESMA and SBRM all avoid potential problem areas plus XBRL effectively supports the creation of "data", the creation of "ontologies", and the creation of "rules". XBRL is powerful enough for financial reporting and it can be made to work by, for example, following my method. This is provable and I have proven it effectively. Further, these same ideas can be applied to nonfinancial reporting use cases.
Properly functioning technology makes things seem to work like magic. But, there is really no magic. For example, consider the OSI model. You use that model every day if you use a computer. You very likely take the OSI model for granted, if you even understand what it is and what it does.
XBRL-based digital financial reporting and in fact computational professional services will ultimatly work as well. Why do I know that? Because it has to. If it does not, then it simply will not be useful and therefore it will not be used.
#########################
Note the intersections between Knowlege Graphs and Logic Programming in the diagram above. These documents help understand that: An Introduction to Prolog and RDF; Comparison of Prolog and RDF.
Note the intersections between Graph Databases and Knowledge Graphs in the diagram above: RDF Triple Stores and Labeled Property Graphs: What's the Difference?; Comparison; Knowledge Graphs vs Property Graphs;
Note the intersections between Logic Programming and Graph Databases in the diagram above: A Graph DB vs Prolog;
#########################
Property Graphs: Training Wheels on the Way to Knowledge Graphs
Alan Morrison's comparison of the pros and cons of property graph databases and RDF/OWL triplestores
Contrasting PROLOG and Graph Databases
Neo4j vs Grakn Part 2: Semantics
KgBase Knowledge Graph (Requires Chrome)