Knowledge Graphs vs Prolog – Prolog’s Role in the LLM Era, Part 7

Enterprise Intelligence (Book), Knowledge Graph, Prolog in the LLM Era 26 Minutes

Previously on Prolog’s Role in the LLM Era:

  • We explored the integration of Prolog with large language models (LLMs), focusing on how Prolog’s deterministic logic complements the broad, fuzzy reasoning of LLMs.
  • In the last episode, I described levels of intelligence we could encode with Prolog, from simple recognition to complex, decoupled recognition and action, offering intuition and a little structure towards enhancing the system 1 side of AI.

In this season finale, Prolog makes its stand as a legit part of an AI architecture despite its seeming redundancy with knowledge graphs (KG), its competitor on the System 1 side of AI. In turn, KGs had to make their stand against LLMs through the realization of a symbiotic relationship (which has a few big scenes in my book, Enterprise Intelligence)—LLMs can substantially help with composing KGs and KGs can ground LLMs in reality.

As we navigate through this LLM era of AI, the recognition that AI isn’t just an LLM, Prolog, or KG is rapidly becoming increasingly evident. LLMs, with their vast data processing capabilities and ability to generate human-like responses, have revolutionized the way we approach AI. However, their effectiveness is significantly enhanced when integrated with other technologies that bring structure, logic, and reasoning into the equation.

As mentioned, the KG is one of those technologies that complement LLMs. KGs, preferably built on the W3C’s Semantic Web standards–like RDF (Resource Description Framework) and OWL (Web Ontology Language)—have gained prominence for their ability to organize and interconnect vast amounts of data in a way that is both scalable and semantically rich. The symbiotic relationship between LLMs and KGs is fascinatingly powerful.

In this post, we will take a closer look at the role of Prolog, one of the two OG logic programming languages (Lisp is the other) that predates the rise of LLMs and KGs but remains relevant due to its unique strengths in handling complex logical reasoning and rule-based systems. By comparing Prolog to KGs, we aim to uncover their respective strengths and limitations, and how these choices shaped the approach taken in my book, Enterprise Intelligence. This exploration will not only highlight the inherent trade-offs between these technologies but also shed light on how they can, although mostly redundant, be used together to create more robust and intelligent AI systems.

The picture below is the essence of Prolog to other aspects of a fully-rounded AI. This blog looks at the relationship between Prolog and Knowledge graphs (red line):

Before moving on, here are a couple of thoughts while reading this blog:

  • I need to point out that this series, Prolog’s Role in the LLM Era, isn’t necessarily advocating for Prolog itself. The series is really advocating for the niche Prolog fills. That is, the niche of logic that it fills—versus the niche of ontology that KGs fill.
  • A central idea explored in this blog is the power of “modular Prolog snippets.” This approach emphasizes breaking down Prolog code into small, self-contained units, each handling specific logical rules or relationships. These snippets can act independently, making it easier to manage complex logic within a larger system. Unlike monolithic structures, these modular components allow for targeted, precise logic processing that can be reused and scaled efficiently within broader AI architectures. This modularity is crucial for integrating Prolog with other technologies, such as Knowledge Graphs, to create more flexible and adaptable AI systems.
  • There is a reason we invented the deterministic, purely logical computers that has profoundly changed the world. Humans and computers make a great team. LLMs are really two additional team members:
    • LLMs make a very good translator between us and the languages we use to communicate with computers (as well as other people).
    • LLMs are an abstraction of a vast trove of the knowledge recorded in our human writings. Like an abstract painting, it doesn’t fully reflect reality, but it means more than is readily obvious.

SQL Server, OLAP Cubes, KGs, and Graph Databases

I apologize, but I need to take one of my patented digressions. Please stick with me since I think the similar situation from the past I’m about to describe will be essential towards driving home the difference between Prolog and KGs.

We’ve all been here before when there are competing technologies we should choose from. All choices will come with trade-offs, but hopefully for one, the trade-offs are minor and it is easier to deal with. Hopefully, for the trade-offs, there are workarounds that might be cumbersome, but come into play infrequently enough that we can live with it.

My analytics origin story began in 1998 with a very exciting stint as a programmer with the OLAP Services team at Microsoft. OLAP Services was later renamed. “SQL Server Analysis Services” (SSAS), a name that should be familiar to those with business intelligence (BI) experience dating back to at least 2010 (before the heyday of Big Data and the Cloud).

Note: Today, I’m a Principal Solutions Architect at Kyvos Insights, a very modern rendition of all that SSAS was back in the day.)

Although SSAS OLAP cubes and BI had been the focus of my career since 1998, a third partner of equal status were data warehouses (DW) and data marts, usually implemented on good old, almost ubiquitous, relational databases such as SQL Server and Oracle. Such SQL relational databases had been popular for well over a decade before OLAP cubes began to find mainstream traction in the early 2000s.

Since OLAP cubes were usually built from data warehouses and data marts, my potential SSAS customers usually had a background with relational SQL databases. As I explained how SSAS worked, I could see the gears in their minds translating it into their familiar SQL terms. It’s not hard. In a nutshell, 90% of OLAP cube understanding could be thought of in terms of GROUP BY forms of SQL. So why again do we need this OLAP thing?

It forces the question of whether we need to implement another kind of database and learn a new language (MDX) when we could do everything with SQL. That is, until you run slice and dice queries off a multi-year history of data consisting of millions of rows (this was back in the early 2000s when millions was a big number-even to Dr. Evil). That performance could be bad for even one concurrent user.

The benefits are hard to see at small scale, where everything works well. But at large scale (today that would easily be in the trillions of rows) mechanisms break down and performance can be horrendous. Additionally, with more complicated analytics, the expressiveness of SQL breaks down and the elegance of MDX in a “slice and dice” situation shines.

In another example, a more recent one, potential customers of enterprise-scale graph databases such as Neo4j (also document databases such as MongoDB) might recall similarly wondering why such a thing is needed. Many of the developers might recall proudly resolving the problem graph databases seem to address with their “key/value” (sometimes “open schema”) massively self-joining tables. It’s something I’m sure millions of SQL developers have self-discovered, only to run into performance problems at large scale with all the self-joins at query time.

Yes, a relational SQL database can do anything an OLAP database or graph database or document database can do … just not as elegantly and optimally in their respective niches. It’s not surprising since SQL relational databases are often called “general purpose databases”.

Beyond performance at scale, other reasons customers might resist an OLAP cube database or a graph database when perfectly fine SQL databases exist include:

  • It’s another non-trivial skill requirement with yet another vendor. Poor IT manager needs to fill yet another hard to fill role.
  • There is a healthy pool of talent in the world with good to great experience on the widely used technology. New technologies developers demanding early-adopter level pay.
  • Queries can perform adequately on our current technology (relational database) most of the time. We’ll live with that “occasionally” poor query performance.

The moral of the story highlights how seemingly minor trade-offs can become valuable assets in another place and time, in some parallel universe, especially when facing large-scale challenges. The question to ponder is: Under what conditions might that minor trade-off be a real opportunity or pain to be remedied.

There is a similar problem between KGs and Prolog. Prolog is to KGs as OLAP cubes are to SQL relational databases. KGs have been picking up traction lately thanks to the emergence of high-quality enterprise-class graph databases, authoring and visualization tools (ex. Protege, Grafo), and a growing population of knowledge graph experts (ex. Ashleigh Faith). In contrast, Prolog is like COBOL—interesting and nostalgic, but well past its prime as a go to option.

In the case of KGs and Prolog, while both can encode knowledge, Prolog excels in capabilities required for deductive reasoning (Prolog is really the software manifestation of deductive reasoning) such as recursion, nesting, and backtracking, which are crucial for more complex logical reasoning. Here’s a brief explanation of these concepts:

  • Recursion: This is a method where a function or rule calls itself within its own definition. In Prolog, recursion is commonly used to solve problems that can be broken down into simpler, repetitive tasks. For instance, calculating the factorial of a number or traversing a hierarchical data structure like a family tree.
  • Nesting: Nesting involves placing one structure within another, such as nested conditions or loops. In Prolog, nesting can be used to handle complex logical operations where one condition depends on the outcome of another, allowing for more sophisticated decision-making processes.
  • Backtracking: This is a problem-solving technique where Prolog systematically searches through possible solutions and, if a solution path fails, backtracks to try a different path. It is essential in logic programming for finding all possible solutions to a query, especially in scenarios with multiple potential outcomes.

These features make Prolog particularly well-suited for tasks requiring intricate logical deductions and problem-solving strategies, offering a level of expressiveness that can be more cumbersome to achieve with KGs alone. By understanding these strengths, it becomes clear that Prolog remains a valuable tool in situations where complex logic needs to be encoded efficiently.

Neo4j vs. Stardog

In the early stages of writing Enterprise Intelligence, I found myself at a crossroads, needing to choose the right tools to support the book’s central thesis. Almost every decision related to writing an AI book in 2023-2024 is a moving target!

One of the first major decisions was selecting the primary graph database—Neo4j (property graph database) or Stardog (triple store-subject_verb_object triples). Each had its merits, but the book is already pulling together too many pieces (data mesh, knowledge graphs, BI, LLMs graph databases, etc.). I didn’t have room for two candidates playing for the part of Graph Database.

Neo4j, with its widespread use and robust community support, presented a compelling option. Its simplicity, particularly in terms of setup and use, meant that it could be more easily adopted by readers without requiring deep expertise in graph databases. Neo4j’s focus on property graphs over RDF also made it a straightforward choice for those familiar with graph theory but not necessarily with the complexities of the Semantic Web.

On the other hand, Stardog, while powerful and deeply integrated with the W3C’s Semantic Web framework, forced a level of complexity that wasn’t necessary for the scope of the book. Stardog’s strengths lie in its ability to handle advanced reasoning and ontologies, but these features would have required more time to explain and justify within the book’s already vast narrative.

In the end, the decision to go with Neo4j was driven by the need to keep things accessible and focused, ensuring that the core concepts could be communicated clearly without getting bogged down in the intricacies of the technology:

  • If a developer even knew what a graph database is, it seemed like more than 90% had worked with (or significantly played with) Neo4j – with a fairly positive experience.
  • Neo4j doesn’t work “natively” with the W3C’s Semantic Web, but there is a plugin to support the Semantic web (neosemamtics). BTW, Neo4j’s plug-in system is very good.
  • I think the flexibility of Neo4j’s “property graph database” mitigated needing to get too deep in the Semantic Web technologies for the purposes of my current book.
  • Neo4j’s “free download” edition is easy to install and fairly easy to pick up (once you get the basics of Cypher down), Note that SPARQL is easier to learn for a SQL developer than Cypher, but I do think Cypher better encapsulates graph database concepts.

However, the Semantic Web does play a crucial role in my book. I decided I will focus more on the Semantic Web and Stardog in the follow-up book.

Knowledge Graphs is to Prolog as Ontology is to Logic

Before I had to decide between Neo4j and Stardog, I needed to decide between a KG and Prolog to play the system 1 role in my book. As with my decision between Neo4j and Stardog, my decision to choose KG over Prolog was more a matter of mitigating the number of moving parts in my already big and ambitious book. In an ideal world, I would have liked to include both options, but my 500-page book would probably exceed a thousand pages and taken a year longer—which in “AI-time” is an eternity.

Although KGs and Prolog could fill the niche of system 1 well, they really are two rather distinct sides of the same coin. That is, ontology versus logic:

  • Ontology (in KGs): Ontology is about structure and relationships—it defines how concepts are related in a domain, often in a hierarchical or networked manner. KGs, through their ontological frameworks, allow us to map out and organize knowledge in a way that’s scalable and understandable, particularly for managing large datasets and complex interrelations.
  • Logic (in Prolog): Logic, on the other hand, is about reasoning and deduction. Prolog excels at applying rules and deriving new knowledge from existing facts, especially when these rules involve complex logical operations like recursion, nesting, and backtracking.

In essence, while KGs provide the structure needed to represent knowledge, Prolog enables the logical reasoning necessary to draw conclusions and solve problems based on that structure. The comparison highlights how these technologies can complement each other in AI systems.

Ontologies, taxonomies, and knowledge graphs are about structure—they define how concepts are related, laying out a map of knowledge that systems can traverse. Ontologies use formal languages like OWL to describe these relationships, creating a framework where each entity and its connections are clearly defined.

Prolog and logic, however, are about reasoning. Prolog doesn’t just traverse a map; it applies rules and deduces new knowledge, drawing conclusions from the relationships defined by the structure. While knowledge graphs provide the scaffolding, Prolog brings the logic that animates it, turning static connections into dynamic reasoning processes.

In simpler terms, ontologies and KGs say, “Here’s how everything is connected”, while Prolog says, “Given these connections, here’s what we can conclude.” It’s the difference between mapping out a landscape and navigating through the inconvenient differences between the map and reality with purpose and insight.

Prolog, with its ability to elegantly express complex logic through recursion, nesting, and dynamic rule evaluation, was incredibly tempting for my book. It’s a tool that can handle sophisticated logic with a kind of precision that KGs struggle to match.

I ultimately chose KGs for their broader adoption, scalability, and compatibility with modern AI infrastructures like LLMs. KGs also benefit from being part of a well-established ecosystem, including public ontologies (ex: FIBO, FoaF)and platforms like Wikidata and Google’s Knowledge Graph. These factors made KGs a more practical choice, especially given the book’s goal to reach an audience beyond my usually BI-centric audience.

Integrating Prolog would have required exploring logic programming to a degree that could have shifted the book’s focus and made it more challenging for readers to grasp the core theme (application of BI in AI). By opting for KGs, I could maintain a balance between depth and accessibility, ensuring that the concepts were both powerful and understandable within the book’s scope.

Prolog vs. Knowledge Graphs: Complementary Roles and Capabilities

Prolog versus Knowledge Graphs is like Commander Spock or Commander Riker. Both play the role of top advisors to their Captain—they support decision making with expertly-crafted advice. A good way to think of it is Spock is like an actual photo whereas Riker is like an “artist’s rendition”. In other words, did an engineer or subject-matter expert create this?

As we explore the respective strengths of Prolog and KGs in the system 1 role, it becomes clear that these two technologies, while different in their approaches, offer complementary capabilities that can be leveraged to create more robust and intelligent AI systems.

Prolog’s Strengths

Prolog stands out in its ability to express and manage complex rules that involve recursion, nesting, iteration, and intricate relationships between multiple rules (often referred to as “rule sets”). This flexibility in handling sophisticated logic makes Prolog a powerful tool for tasks that require deep, rule-based reasoning. Unlike more declarative systems, Prolog allows for dynamic evaluation of logic, meaning that rules can be recursively applied or iterated upon until a solution is found.

However, this power comes with its own set of challenges, particularly in terms of computation intensity. The way Prolog handles logic—through backtracking and recursion—can make it difficult to quantify its computational complexity in traditional terms. Despite this, Prolog’s ability to manage such complexity with a relatively concise syntax underscores its unique role in logic processing, particularly in domains where precision and depth are crucial.

Prolog’s deterministic nature is another key strength. Its execution model is designed to produce predictable, precise outcomes by following specific logical rules. Prolog uses a process known as backtracking to explore different possibilities and find solutions to logical queries. This makes it particularly well-suited for applications that require exact reasoning, such as decision-making systems, expert systems, and certain types of AI algorithms where precise control over the logic flow is essential.

Knowledge Graph Strengths

Where Prolog excels in logic, Knowledge Graphs excel in the structuring and management of data, particularly in terms of ontology. KGs provide a framework for organizing data into a web of interconnected entities, each with defined relationships and attributes. This ontological approach allows KGs to represent complex domains in a way that is both scalable and easily navigable. KGs enable the modeling of rich, semantic relationships between data points, which is particularly valuable in contexts where understanding the interconnections between entities is key, such as in search engines, recommendation systems, and knowledge management systems.

Another significant advantage of KGs is their scalability and adherence to standardized formats, such as RDF and OWL. These standards ensure that KGs can be extended, integrated, and queried at scale, making them ideal for large, interconnected data systems. The use of standardized formats also facilitates interoperability between different systems and datasets, allowing for the seamless integration of information from multiple sources. This scalability and standardization make KGs particularly well-suited for enterprise-level applications, where the ability to manage vast amounts of interconnected data is essential.

Example of Complicated Logic Expressed as Prolog and RDF/OWL (Turtle)

To illustrate how Prolog handles logic more elegantly than contorting RDF/OWL’s ability to express structure, here’s an example of Prolog’s encapsulation of a simple rule compared to expressing the same logic in RDF/OWL.

In the realm of supply chain management, imagine you have a network of suppliers, each providing components that are interdependent—certain components can only be shipped after others have been delivered. The dependencies between these components are complex, involving multiple conditions like availability, priority, and shipping constraints.

In Prolog, you could express this complex logic succinctly:

can_ship(Component) :-
   depends_on(Component, Dependency),
   in_stock(Dependency),
   priority(Component, High).

This simple rule checks if a component can be shipped based on its dependencies, stock availability, and priority. You can easily add more rules for different scenarios, and Prolog will automatically infer the possible outcomes.

The Prolog rule is “simple” in that it’s a compound Boolean statement (depends on AND in stock AND priority). There are no recursions, iteration, or nested terms. But even at this level, the Semantic Web RDF version is much more verbose and less intuitively easy to understand:

@prefix : http://example.org/supplychain# .
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .

:Component rdf:type owl:Class .
:Dependency rdf:type owl:Class .
:Priority rdf:type owl:Class .
:HighPriority rdf:type :Priority .

:dependsOn rdf:type owl:ObjectProperty ;
   rdfs:domain :Component ;
   rdfs:range :Dependency .

:inStock rdf:type owl:ObjectProperty ;
   rdfs:domain :Dependency .

:hasPriority rdf:type owl:ObjectProperty ;
   rdfs:domain :Component ;
   rdfs:range :Priority .

:canShip rdf:type owl:Class ;
   owl:equivalentClass [
   rdf:type owl:Restriction ;
   owl:onProperty :dependsOn ;
   owl:someValuesFrom :Dependency
] .

:canShip rdf:type owl:Class ;
owl:equivalentClass [
   rdf:type owl:Restriction ;
   owl:onProperty :hasPriority ;
   owl:hasValue :HighPriority
] .

:canShip rdf:type owl:Class ;
   owl:equivalentClass [
   rdf:type owl:Restriction ;
   owl:onProperty :inStock ;
   owl:allValuesFrom :Dependency
] .

Semantic Web Rule Language (SWRL)

To extend the capabilities of RDF and OWL, the Semantic Web Rule Language (SWRL) was developed, combining OWL with RuleML (Rule Markup Language) to enable the definition of rules that infer new knowledge from existing ontologies. Here’s how you might express the same logic in SWRL:

swrlCopy codecan_ship(?Component) ^ 
   depends_on(?Component, ?Dependency) ^ 
   in_stock(?Dependency) ^ 
   hasPriority(?Component, HighPriority) 
   -> can_ship(?Component).

Gee, that looks almost exactly like Prolog! So what’s the big deal?

Well, this is a simple case. It will much more challenging for the RDF side with significantly more complicated logic.

While SWRL is a powerful tool within RDF/OWL environments, it lacks the expressive power and efficiency of Prolog, especially in handling recursive queries or complex logical structures. This limitation is why Prolog remains preferable for scenarios that require deep logical reasoning.

Prolog vs. RDF/OWL and SWRL: Comparison

In RDF/OWL, each component and dependency must be defined as triples, requiring rules and reasoning engines to simulate logical processes. This approach often leads to a verbose and cumbersome setup, especially as the complexity of the logic increases. Mapping out each condition explicitly in RDF/OWL quickly becomes a detailed and less intuitive task.

Prolog, on the other hand, allows for a more direct expression of logic. It uses rules that closely resemble natural language, making it an elegant solution for scenarios involving complex, conditional dependencies. While KGs can encode logical rules using technologies like SPARQL, OWL, and SWRL, the process is generally more verbose and less intuitive, particularly for tasks involving recursion, backtracking, and nested logical conditions. This highlights why Prolog maintains a unique position despite the capabilities of KGs.

This is the current state of Semantic Web technologies, which, like SQL’s evolution with OLAP extensions, may see future advancements to address these complexities. However, adding Prolog’s expressiveness to RDF, OWL, SPARQL, and SWRL would be a significant challenge for graph database vendors. It’s one thing to specify standards, but implementing them without affecting current performance is quite another—just as it took time for OLAP extensions to be effectively integrated into SQL-based systems.

Summary of the Comparison

The main point is that logic and ontology are two sides of the same coin. While implementations like Prolog and KGs can overlap in function, each excels in its domain—Prolog in logic and reasoning, KGs in structuring and connecting data.

I mentioned towards the beginning of this blog that it’s not Prolog itself I’m advocating for, rather, the niche of logic that Prolog fills. So, it mostly doesn’t matter where the logic capability is implemented. However, attempting to merge the unique features of one into the other can be cumbersome and counterproductive. By keeping logic and ontology as distinct components, each can evolve more efficiently and with less friction, allowing them to be optimized for their specific roles within an AI system. This is a very common pattern in software development and life in general—specialization enables deeper capabilities.

The Hybrid Approach: Leveraging the Best of Both Worlds

Prolog and KGs shouldn’t be seen as mutually exclusive choices, redundant candidates for the system 1 role. Instead, they can complement each other, leveraging the unique strengths of both technologies to create a more robust and versatile AI framework.

In fact, in Enterprise Intelligence, I describe building an expert system for handling novel solutions for novel SQL Server performance issues. I called it the “Trade-Off/Semantic Network”— the Trade-Off side were relationships of how configuration and metric values affected things and the Semantic Network side was an ontology of the world of SQL Server. It was essentially a KG of how SQL Server works. Long story short, to make it work well, I needed to partition ontological characteristics from “cause and effect” relationships into two distinct but linked structures:

  1. An ontology of SQL Server concepts such as:
    • Hierarchies describing servers, instances, databases, tables, columns.
    • Components of the SQL Server software and machine.
    • Performance metrics and what parts they affect
  2. The rules describing the expected result of the interaction of parts under whatever conditions.

Eventually, I did learn of systems that rely on a combination of KGs for structuring knowledge and Prolog for reasoning over that knowledge. A notable example is the application of Prolog in combination with OWL ontologies in some academic and research settings for reasoning over semantic data. Prolog has been used historically in highly complicated expert systems for legal reasoning and medical diagnostics, often in conjunction with structured data. KGs in modern implementations could enhance these systems by providing richer context and more flexible data relationships.

So although the idea of combining the ontology strength of KGs and the logical prowess of Prolog is recognized, today it’s still mostly known in advanced academic settings and high-end expert system applications. However, with ChatGPT having burst onto the awareness of the general public, other such arms of AI have still yet to find its way into the public consciousness. It all will as we push LLMs to their limits and discover and re-discover symbiotic partnerships with other components of intelligence.

Complementary Integration

In the context of Enterprise Intelligence, although I don’t talk much about Prolog, it plays a complementary role to KGs, offering precise logic processing where KGs provide structure and ontology. KGs are exceptional at organizing and connecting data, creating a comprehensive map of relationships and entities within a domain. However, when it comes to defining the logic that governs these relationships—particularly complex, rule-based logic—Prolog is ideally suited to the task.

By combining KGs with Prolog, we can create a system where the KG handles the broad, semantic structure while Prolog manages the precise logic that operates within that structure. This integration allows for the best of both worlds: the scalability and relational power of KGs, coupled with the deterministic, rule-based processing capabilities of Prolog.

Modular Prolog Snippets

One of Prolog’s key characteristics is its ability to be partitioned into modular components, allowing for the expression of sets of rules as self-contained snippets. This modularity enables Prolog to be used flexibly, with each component acting independently yet contributing to a larger system. These “lots of little Prolog snippets” can be used to measure relationships within a KG, evaluate conditions, or implement decision-making logic.

In contrast, LLMs are fundamentally unpartitionable in that way. LLMs rely on a vast, interconnected web of learned relationships that emerge from training on massive datasets. This foundational component of LLMs is what gives rise to their broad, generalized reasoning capabilities. While fine-tuning and advanced techniques like mixture of experts can introduce specialized capabilities, the core structure of an LLM remains a monolithic entity. The emergent properties of LLMs—where their reasoning ability comes from the entirety of their massive training—mean that they cannot be broken down into modular components without losing their effectiveness. This is why, despite their power, LLMs lack the flexibility and targeted precision that Prolog can offer in specific contexts.

However, to maintain controllable performance levels in a production environment, these Prolog snippets must be carefully constrained. Each snippet should be designed to act like a function in the strict sense—self-contained, with no external imports beyond the parameters provided at runtime. Additionally, Prolog rules should be limited in terms of recursion and nesting to avoid unpredictably excessive computational complexity. This ensures that the logic remains manageable, predictable, and scalable within the broader system.

Production Considerations

To scale Prolog effectively, especially in a system as comprehensive as an enterprise knowledge graph (EKG), the star of my book, each Prolog file must be treated with the same discipline as a function in traditional programming. This means keeping each file self-contained, limiting recursion and iteration to avoid unnecessary complexity, and ensuring that the logic can be efficiently cached and reused. By treating Prolog snippets as modular, reusable components, we can maintain the performance and reliability of the system while still leveraging Prolog’s powerful logic-processing capabilities.

Prolog’s modular nature allows individuals to express their own rules—what I envision as “lots of little Prolog snippets.” For example, Prolog could be employed to measure the strength of relationships within the KG, as we’ve discussed previously. However, for Prolog to operate effectively in a production environment, it must be constrained: each Prolog file should be treated like a function, meaning that aside from parameter facts, it cannot import additional resources at query time. Furthermore, recursion and iteration should be limited to ensure that each Prolog snippet can be efficiently cached and reused.

In practice, this means that there could be multiple Prolog files for each relationship in the KG, named systematically. For example, the Prolog file could be named in the format of relationshipid_userid.pl, where relationshipid is the unique id of a KG relationship and userid is the id of the author of the Prolog. Each version of a Prolog file, along with its parameter-value responses, could then be cached, enabling a scalable, efficient system that leverages the strengths of both knowledge graphs and Prolog.

Implementation Strategy

In practical terms, this hybrid approach could involve multiple Prolog files existing for each relationship within the KG, each systematically named and organized. These files could be cached based on their parameter-value responses, allowing the system to efficiently retrieve and apply the necessary logic without having to reprocess the rules from scratch each time. This strategy not only improves scalability but also ensures that the logic remains flexible and adaptable, capable of evolving alongside the underlying knowledge graph as new data and relationships are introduced.

Abstracted Thoughts

As we linked ML to Prolog in Part 4 and BI to Prolog in Part 5, we’ll now link KGs to Prolog.

I think of a Prolog snippet as a thought, the encoding of the way we think about something. For example, in Part 3, I used an example of Prolog of encoded reasoning behind drink selection at a restaurant:

businessmeal(true) :- companion(boss).
businessmeal(true) :- companion(client).
drinkorder(dietcoke) :- context(lunch), person(eugene).
drinkorder(dietcoke) :- context(dinner), businessmeal(true), person(eugene).
drinkorder(redwine) :- context(dinner), companion(wife), person(eugene).
drinkorder(beer) :- context(dinner), companion(friend), person(eugene).

The reasoning behind my drink order is straightforward. However, the challenge lies in the fact that there are no universally utilized terms. All predicates (e.g., businessmeal, companion, context, drinkorder) and values (e.g., boss, client, lunch) are just symbols that could be expressed in numerous ways. Despite these variations, most people would grasp the general meaning, thanks to semantic transformations that link pairs of synonyms in our minds.

This is where the complementary strengths of KGs and LLMs come into play. KGs (Prolog’s system 1 ally) and LLMs (Prolog’s system 2 ally) help soften the rigidity of symbols in Prolog by enabling semantic generalization.

Since I envision Prolog as a means to incorporate custom rules across billions of people and countless domains, it’s crucial that the AI analyzing Prolog can abstract or generalize the terms—just as we do in everyday conversation. Towards generalization and abstraction, Prolog’s predicates, values, and variables can:

  • Link to KGs, which can associate them with semantically similar symbols.
  • Leverage LLMs to translate a Prolog snippet into abstract, generalized terms with broader meanings.

As an example, consider the Prolog that encodes my drink preferences just above. Now, let’s say we have a small KG that contains information about drinks and relationships. This KG includes synonyms and categories for “dietcoke” and “wife.” Here’s a simplified view of what this KG might look like in RDF/Turtle format:

@prefix ex: http://example.org# .

% Reasonable alternatives for dietcoke include dietpepsi and icedtea
ex:dietcoke a ex:Drink ;
   ex:hasSynonym ex:dietpepsi, ex:icedtea ;
   ex:belongsTo ex:dietsoda .

% dietcode and dietpepsi are dietsoda
ex:dietsoda a ex:DrinkCategory ;
   ex:includes ex:dietcoke, ex:dietpepsi .

% Synonym for wife could be spouse and partner.
ex:wife a ex:PersonRole ;
   ex:hasSynonym ex:spouse, ex:partner .

% wife is a spouse.
ex:spouse a ex:PersonRole ;
   ex:includes ex:wife .

The following two SPARQL queries are issued to the KG above to find synonyms:

SELECT ?synonym WHERE {
?drink a ex:Drink ;
ex:hasSynonym ?synonym ;
ex:includes ex:dietcoke .
}

SELECT ?synonym WHERE {ex:wife ex:hasSynonym ?synonym .}

The results from those SPARQL queries are translated to Prolog using the predicate, synonym:

% Define Synonyms in Prolog - this is from KG.
synonym(spouse, wife).
synonym(partner, wife).
synonym(dietpepsi, dietcoke).

We’ll also need to add a bit of “meta Prolog” to utilize the synonyms:

% Translate synonyms to original terms used in the rules
translate_term(Term, TranslatedTerm) :-
   synonym(Term, TranslatedTerm), !.
   translate_term(Term, Term). % If no synonym exists, use the original term.

% Set context with translation applied
set_context_with_translation(Companion, Context) :-
    translate_term(Companion, TranslatedCompanion),
    assert(companion(TranslatedCompanion)),
    assert(context(Context)).

The following shows my drink Prolog with the translations asserted into it:

% Define Synonyms in Prolog - this is from KG.
synonym(spouse, wife).
synonym(partner, wife).
synonym(dietpepsi, dietcoke).

% Create a Translation Predicate
translate_term(Term, TranslatedTerm) :- 
    synonym(Term, TranslatedTerm), !.
translate_term(Term, Term). % If no synonym exists, use the original term.

% Set context with translation applied
set_context_with_translation(Companion, Context) :-
    translate_term(Companion, TranslatedCompanion),
    assert(companion(TranslatedCompanion)),
    assert(context(Context)).

% My original rules for drinks.
businessmeal(true) :- companion(boss).
businessmeal(true) :- companion(client).
drinkorder(dietcoke) :- context(lunch), person(eugene).
drinkorder(dietcoke) :- context(dinner), businessmeal(true), person(eugene).
drinkorder(redwine) :- context(dinner), companion(wife), person(eugene).
drinkorder(beer) :- context(dinner), companion(friend), person(eugene).

This is how we can query this abstracted version of my drinks Prolog. Using the “synonym mechanism” we just added, the call is a little different:

?- set_context_with_translation(spouse, dinner), drinkorder(Drink)

Without the capacity to generalize/abstract, Prolog would be as inflexible as conventional programming code, intolerant of ambiguity. In a complex world, that would certainly diminish its utility. What would our human intelligence be without abstraction, generalization, and metaphor? In a nutshell, our brains would be the equivalent of an over-trained ML model. As I mentioned in Part 1:

  • Me: “What’s the best thing about computers?”
  • Class: “They do exactly what you tell them to do.”
  • Me: “What’s the worst thing about computers?”
  • Class: “They do exactly what you tell them to do.”

Conclusion

Integrating structured logic with expansive, intuitive capabilities is not just a niche interest—it’s central to the continued progress of AI. Prolog and KGs each bring unique strengths that, when combined with the expansive capabilities of LLMs, create systems that are closer to deep reasoning, vast knowledge management, and broad contextual understanding. These technologies are not just tools for specialized problems; they are the pillars for the coming Slope of Enlightenment of AI systems (assuming there might be an AI Winter for the LLM era), capable of meeting the complex challenges we face.

The interplay between Prolog’s structured logic and the broad, intuitive capabilities of LLMs and KGs harnesses the best of both worlds. Prolog’s ability to handle complex, rule-based logic is invaluable in contexts where precise decision-making is required, while KGs provide the structural framework needed to organize and relate vast amounts of data. LLMs, with their capacity for generalization and context-driven insights, add an additional layer of understanding, making AI systems more versatile and adaptive.

The conclusion of this exploration is a strong advocacy for hybrid systems—where KGs manage the expansive, large-scale data relationships, and Prolog is employed to handle specific logical evaluations that require precision and deterministic outcomes. This approach ensures that AI systems are not only creative and expansive in their understanding but also precise and reliable in their reasoning. By integrating these technologies, we can build the next generation of intelligent systems that are capable of both deep, logical reasoning and broad, contextual understanding.

In essence, the future of AI doesn’t lie in choosing one technology over another but in finding ways to integrate them effectively. By leveraging the complementary strengths of Prolog, KGs, and LLMs, we can create systems that are greater than the sum of their parts—systems that are both intuitive and logical, expansive and precise, creative and reliable. This balanced integration is not just an advantage but a necessity for building AI systems that can meet the complex challenges of tomorrow.

Annoying plug for my book:

Post Credits Teaser

The logic and taxonomy aspects of the system 1 side of thinking along with the flexible and robust system 2 LLM side of thinking is powerful. But it isn’t all there is to intelligence. We still don’t know all of what’s involved.

Another major component of intelligence is motivation. Without desires, fear, and our adversaries who keep us on our toes (see Part 6) propelling us along the evolutionary paths, I don’t think our intelligence would have emerged. Why would we invent, communicate, or learn without motivation? Not just our motivation but the motivation of others (theory of mind?) which helps us predict and understand their reactions.

This subject will be part of my follow-up book. But for now, here are a few of my blogs on the topic:

Unknown's avatar

Published by Eugene

Azure Data Engineer/Architect

Published

Leave a comment