Pursuit of Curiosity - A Journey Through Knowledge, Ontologies, and Logic

Photo by Anna Mould on Unsplash

People often contemplate their achievements over the past year as New Year’s Eve approaches. Honestly, I have never consciously done this exercise before. This year, I want to give it a try — especially because, in July, I began a year-long commitment. With six months already behind me, it feels like the right time to reflect on what I have achieved and summarize my efforts and learnings so far.

It Started with Paul Graham

On July 1, 2024, I decided to start my own research journey. The decision was inspired by Paul Graham’s essay, “How to Do Great Work”. I read it several times, letting its ideas resonate with me, before finally deciding to act on his advice.

My hypothesis was simple: if I commit to working on one area of interest for an entire year without major deviations, I will:

• Learn to concentrate on a single topic over a long period (a year feels like an eternity to me).
• Explore the chosen area deeply, perhaps even reaching its frontier — where few or none have ventured before.
• Develop the skill of prioritization (or, more accurately, deprioritization), which has always been a challenge for me.
• Build confidence in my ability to tackle complex topics without giving up.
• Learn to enjoy the process itself and treat results as secondary.

Knowledge as My Research Topic

I chose a rather broad subject: Knowledge Engineering, or simply Knowledge. To determine the focus of my exploration, I reflected on my past experiences, my preferences, and the tasks that brought me the most satisfaction. I realized two recurring themes:

1. I have always been drawn to clarifying concepts and formalizing ideas as much as possible.
2. In every job, I gravitated toward working with hypotheses, data, and metrics.

These insights led me to a broad starting point: Knowledge. I resolved to approach it with a curious yet disciplined mindset, letting my interests guide me while setting boundaries:

• Avoid straying too far from the core topic.
• Always justify why a particular avenue is worth pursuing.
• Return to the central theme if my current exploration loses its appeal.

Almost immediately I encountered the concept of knowledge graphs, which are claimed to represent the knowledge extracted by AI from documents. This seemed like an excellent starting point. My familiarity with AI — particularly my work with LLMs — gave me a foundation to build on. Moreover, the idea of AI constructing knowledge graphs intrigued me. Could these graphs indeed encapsulate “knowledge”? If so, they might hold the key to what I was searching for.

Knowledge Graphs and Databases

My first task was to explore knowledge graphs. I began by delving into various resources, technologies, and tools. It didn’t take long to realize that the idea of AI effortlessly extracting “golden knowledge” from any document was more hype than reality. The process turned out to be far more nuanced.

The primary challenge was this: before any meaningful extraction could happen, a clear goal needed to be defined. This goal would inform the creation of a schema — a structured framework of knowledge, also known as an ontology. Only after defining this ontology could AI extract information in alignment with it. The realization shifted my focus to understanding what an ontology truly means.

I stumbled upon an excellent introductory video series, Going Meta by Neo4j. It covered key concepts like graph databases, knowledge graphs, ontologies, semantics, and useful tools and technologies in this domain. The series was engaging, and the exercises helped me improve my understanding.

Inspired, I decided to create something on my own. Since I had experience with the beautifully designed ReBAC system, OpenFGA, which is based on an entity-relations model, I chose to build a more generic system using a knowledge database. The result of this exploration is documented in my article. This project deepened my understanding of knowledge graphs and ontologies, and I picked up a wide array of tools and techniques along the way.

Ontology

With a growing interest in ontologies, my next goal was to build one myself. However, I wanted to avoid starting from scratch. Instead, I sought a foundational ontology that could serve as a basis for my work.

A year ago, I came across the book Business Objects by Chris Partridge. While it didn’t explicitly use the term “ontology,” it introduced a foundational framework for modeling specific domain ontologies and systems within those domains. At the time, I didn’t fully appreciate the connection to ontologies, but the concepts stayed with me.

Building on this, I searched for modern resources on creating ontologies and found the book Building Ontologies with Basic Formal Ontology. It seemed like exactly what I needed. After reading enough to grasp the fundamentals, I decided to apply my newfound knowledge to create an ontology for swimming — a topic close to me.

However, I quickly ran into challenges. I realized that I lacked sufficient knowledge of the swimming process to construct a meaningful ontology. This led to another important insight: before building an ontology for a domain, it’s essential to model the domain itself. The process of creating a domain model surfaces new concepts, relationships, and constraints, which are vital inputs for ontology development.

Modeling

I found an excellent book on modeling, Simulation and Similarity: Using Models to Understand the World, which provided valuable insights into the topic. Inspired by this, I began building a model of the freestyle swimming process. I detailed the results of this exercise in an article.

The main takeaway is that building a physical model, while challenging, is relatively straightforward. Modeling a swimmer at the level of body mechanics — arms, legs, and other physical components — can yield a basic conceptualization and valuable insights, especially when paired with real-world measurements.

However, when it comes to modeling complex systems that do not yet exist, involving people, goals, and unclear cause-effect relationships, the task becomes far more difficult and unpredictable. I realized that I needed a framework — not for modeling itself, but for creating a swimmer, including aspects like workout plans, scheduling, selecting coaches, and tools.

This led me to systems engineering, a multidisciplinary approach that provides a comprehensive set of practices, tools, and ways of thinking required to create a successful system. Whether building an airplane or crafting a better swimmer, systems engineering focuses on ensuring the system fulfills its intended purpose.

Systems Engineering

Driven by this realization, I started learning about Systems Engineering and even passed the INCOSE certification exam. I then decided to apply this knowledge to my personal goal: transforming myself into a better swimmer.

The most challenging stage of any system creation lifecycle is business or mission analysis. This phase involves:

• Understanding new (and potentially non-existent) domains.
• Defining the problem space and constraining the solution space.
• Deciding how the target system (in this case, “a better swimmer”) will be used.
• Determining how the organization or individual will operate to build it.
• Testing critical hypotheses.

Effectively, it is the phase where 50% of the work is done — the most crucial 50%, which defines the remaining effort.

I began by analyzing why I wanted to become a better swimmer, what that goal meant, how I would measure success, and who the stakeholders were. For instance, stakeholders could include myself (as the primary beneficiary), my coach, or even my family, as they might be impacted by the time and effort I devote to training. This exercise was incredibly enlightening and gave me a much clearer understanding of my objectives and how to achieve them. I documented this process in an article.

Despite its utility, I encountered a significant limitation: there is no formalized method for describing the process of analysis and the resulting conceptualization of a domain.

In systems engineering, there is a relatively new technique called Model-Based Systems Engineering (MBSE). MBSE provides tools and frameworks for creating formal descriptions at each stage of the system creation lifecycle. Unfortunately, it largely neglects the “business or mission analysis” phase, which I found to be a major shortcoming.

To address this gap, I sought ways to formally describe the conceptualization of a new domain. In my swimming analysis article, I defined new concepts and created conceptual diagrams with relationships between those concepts. However, this process was entirely intuitive, lacking the rigor of a formal framework or language.

What I needed was a theory or framework — including formal languages and tools — that could help express the conceptualization of new domains systematically. My search led me to a fascinating article. It described conceptualization in two ways and linked it to the concept of ontology. This connection was encouraging — it signaled that I was still aligned with my initial goal and hadn’t deviated significantly.

Conceptualization

Inspired by the article on conceptualization and ontology, I decided to dig deeper into Nicola Guarino’s definition of domain conceptualization. This exploration revealed its connections to formal logic and knowledge representation.

To build a solid foundation, I came across a highly regarded book on knowledge representation by John F. Sowa. However, as I began reading, it became clear that my understanding of basic propositional and relational logic — essential to fully grasp the book — was insufficient.

Logic

Realizing this gap, I decided to take a detour and focus on learning logic. I found an excellent introductory course from Stanford, based on Michael Genesereth’s book Introduction to Logic. This course offers about 90% of the book’s content, along with exceptional exercises that provide hands-on practice.

One highlight of the course is its emphasis on propositional proofs using Fitch notation. The integrated proof checker made the learning process both interactive and engaging. I spent significant time mastering these proofs, finding the structured approach immensely rewarding.

Present Time

This is where I am now — still immersed in learning logic to build the foundation required to understand Sowa’s book on knowledge representation. My goal remains to revisit the swimming conceptualization project and formalize it using what I’ve learned, with the eventual aim of generalizing the approach.

The entire process reminds me of a function call stack: I’m diving deeper and deeper into nested tasks, accumulating a stack of unfinished objectives. However, just as in programming, I plan to return to the surface, unwinding the stack and completing each task in turn.

Results and Learnings

I mapped out my journey in the form of a diagram. While the links in the image aren’t functional, I have included all the references in the text above.

The entire journey spanned six months and involved 250 hours of focused work — about 10 hours per week. I didn’t rush through it but took the time to enjoy the process, listen to myself, and explore various small detours, such as reading additional articles or diving deeper into related topics.

Reflecting on this experience, I revisited my initial hypotheses to evaluate my progress:

1. Learn to concentrate on one topic for an extended period

While I occasionally deviated from the primary focus, I always returned to my core goal. This consistency suggests that I made the right choice in selecting a topic I genuinely found interesting. The most rewarding realization was that I could sustain concentration on a single topic for six months without external motivators like money.

2. Explore one area deeply and potentially reach its edge or gaps

I haven’t yet reached a true “gap” where no prior work exists. However, I’ve developed a hypothesis: formalizing the conceptualization process for new domains could significantly assist analysts in unfamiliar areas. Developing a framework or tooling for this process might fill a meaningful gap, though this remains an idea at this stage.

3. Learn to prioritize or deprioritize effectively

I made significant progress here. Throughout the six months, I faced numerous tempting distractions — such as ideas for side projects, offers for part-time work with friends in an AI startup, and more. Knowing my weekly time budget (15–18 hours beyond work) and the decision to invest 10–13 hours weekly in this research I refused all the opportunities and feel good about having stayed true to my priorities. (Okay, I admit, I sometimes question these decisions — but the doubts pass quickly.)

4. Build confidence in my ability to tackle complex topics without giving up

I’ve refined this hypothesis: I now feel confident that complex topics can be genuinely interesting for me, and I can engage with them out of curiosity, not obligation. This distinction is key — I’m driven by interest rather than external pressures like university deadlines or job requirements.

5. Learn to enjoy the process and treat results as secondary

This is still a work in progress. I’ve realized that publishing results and sharing them is important — not only to demonstrate tangible outcomes but also to foster accountability (skin in a game) and a sense of connection with others (even if only a handful of people read my work). At the same time, I’ve truly enjoyed the process. The autonomy to explore, dive deeper, and spend as much time as I want on any given topic has been incredibly liberating.

I have another six months ahead of me, and rather than feeling tired or less curious, I am filled with calm energy, unwavering motivation, and the confidence that I can — and will — continue this journey.