The following is a summary of the business case for PROLOG that I have gleaned from various other sources including this and this and this and this.
Prolog is not a tool business professionals would ever be exposed to. Business professionals would be exposed to high-level interfaces that they understand and can work with.
As pointed out in the article, Building a Custom Rules Engine with Prolog, there benefits to using the right tool for the right job. Here are some exerpts from that article:
The primary problem was that the flow-of-control branching if-then statements of a procedural language did not have the same semantics as the pattern-matching if-then rules of logical relationships. Developers must make arbitrary decisions of where in the flow-of-control to code each branch, thereby entangling the declarative rules in the thread of execution.
This is clearly an advantage over the procedural approach, and also a big advantage over rule-based approaches that do not provide ontologies. In a pure rule-based approach, these definitions would all have to be implemented as rules. Having the writers of the rules stick to a limited vocabulary doesn't work because so many different vaccines and spellings appear in the medical records. It is the ontology that makes it practical to use the existing medical records.
Unlike factual or procedural knowledge, logical knowledge is difficult to encode in a computer. However, the ability for organizations to successfully encode their logical knowledge can lead to better services for users. The question, then, is how best to encode logical knowledge. It can be shoe-horned into data- and procedure-based tools, but the encoding is difficult, the knowledge becomes opaque, and maintenance becomes a nightmare. Rule-based and logic-based tools are better suited to the encoding of logical knowledge, but require the selection of the proper tool for the knowledge to be encoded, and the learning of how to use that tool. Off-the-shelf rule or logic tools sometimes provide a good solution, but often the knowledge representation of the tool doesn't fit the actual knowledge, or the reasoning engine doesn't use the knowledge as it is supposed to be used. This leads to the same coding and maintenance problems experienced with conventional tools, but to a lesser extent depending on how big the semantic gap is between the knowledge and the tool.
A viable alternative is the building of a custom logic-based language and reasoning engine. This allows for the closest fit between the coding of the knowledge and the actual knowledge, and for the cleanest integration between the tool and the rest of the application context.
Specialized tools are easier to use that general tools.
An example of using PROLOG is PROLEG which is programming logic for the legal industry. PROLEG is described as an "interactive system for arranging issues". This video, Introduction to PROLeg, and this paper, PROLEG: An Implementation of the Presupposed Ultimate Fact Theory of Japanese Civil Code by PROLOG Technology, and this paper Introduction to PROLEG provide examples of the capabilities of PROLEG. Effectively, this seems to be a specialized subset of Logical English. This is very likely how financial reporting rules will be written in the near future.
Prolog seems to be a possible candidate for the unifying logic framework for business that I was seeking.
##########################