The World's Ontology Ecosystem

Last week, Barry Smith and I taught The World’s Ontology Ecosystem, an intensive five-day summer school co-sponsored by the University at Buffalo and the National Center for Ontological Research (NCOR). We held the in-person portion in Washington, DC, while also opening the course to online participation and recording the entire week.

The goal was ambitious: start with the philosophical foundations of ontology, move through the practical tradecraft of ontology engineering, and end by asking what the field should become as ontologies increasingly intersect with knowledge graphs, formal methods, artificial intelligence, and large-scale information systems.

What emerged over the five days was less a single picture of ontology engineering than a set of competing—but increasingly complementary—visions of its future.

The full recordings are available in the World’s Ontology Ecosystem YouTube playlist, and NCOR has published a more detailed five-part account of the event.

Ontology engineering as a tradecraft

We began with a deceptively basic question: What kind of field is applied ontology?

Ontology began as a branch of philosophy concerned with questions about what exists and how different kinds of entities are related. Applied ontology inherits those questions but adds an engineering requirement: the distinctions we make have to support actual information systems.

An ambiguous distinction in a philosophical discussion may remain an ambiguity. An ambiguous distinction encoded in an ontology can propagate into databases, knowledge graphs, queries, analytics, integrations, and eventually AI systems.

So I argued on the first day that ontology engineering should increasingly be understood as a tradecraft. Its goals are not simply to construct class hierarchies or produce OWL files. The work is aimed jointly at information quality and interoperability, and its central method is systematic disambiguation.

Barry situated that tradecraft within the longer history of ontology, while the rest of the day widened the perspective to ontology foundries, governance, standards, BFO, and the larger ecosystem in which independently developed ontologies have to coexist.

The Day 1 NCOR report develops this theme in more detail, and the Day 1 recording is available on YouTube.

Modeling becomes interesting when the easy answers stop working

It is easy to teach ontology using examples such as person, vehicle, and organization. The interesting methodological questions emerge when the domain resists straightforward modeling.

We therefore worked through problems involving fictional and unreal entities, law, systems, definitions, ontology design patterns, OWL, and automated reasoning.

What do we mean when we talk about Superman if a realist ontology does not posit Superman as an existing individual? How should an ontology distinguish a contract from the document in which the contract is recorded? What exactly makes something a system rather than an aggregate of components?

These examples reinforced an important point: ontology engineering is not a mechanical process of converting nouns into classes and verbs into relations.

It requires explicit ontological commitments, careful definitions, reusable modeling patterns, and tests of the consequences of those commitments.

Formal reasoning is crucial here, but it has a specific role. A reasoner can tell us what follows from the axioms we supplied. It cannot tell us that we made the right claims about the world in the first place.

The Day 2 report covers these modeling problems, and the full Day 2 session is also online.

AI should support ontology engineering—not replace it

By Day 3, we were ready to introduce the issue that now hangs over almost every technical discipline: generative AI.

The question was not whether an LLM can generate something that looks like an ontology. It clearly can.

The harder question is whether the result is correct, reusable, logically adequate, governed, and defensible.

Jobst Landgrebe and Barry began with a critical examination of contemporary AI and the limitations of statistical models. Sydney Cohen later approached the question from the other direction, showing where LLMs are already useful in day-to-day ontology engineering.

My own conclusion from these discussions is that we should avoid both extremes. “Never use an LLM” is increasingly impractical. “Let the LLM build the ontology” confuses syntactically plausible output with ontology engineering.

Let AI generate candidate mappings, definitions, queries, axioms, or other artifacts where it can accelerate the work. Use deterministic and formal tools to test whatever can actually be tested. Then require ontology engineers and domain experts to adjudicate the semantic questions that remain.

If SPARQL can answer the question, use SPARQL. If a reasoner can establish the consequence, use the reasoner. If SHACL can reject an invalid structure, use SHACL.

Use probabilistic systems where the problem is genuinely probabilistic.

That distinction is central to the Day 3 NCOR report, and the Day 3 recording contains the full discussion.

From AI critique to AI architecture

Day 4 took that argument one step further.

Rather than asking whether AI systems are trustworthy in the abstract, we asked what an architecture would look like if we deliberately engineered it to make probabilistic components more constrained and inspectable.

Neil Otte began with an important qualification: not every information problem requires an ontology. Ontology is a technical choice, and it has to earn its place in the architecture.

But when systems need persistent semantics, reusable standards, formal consistency, heterogeneous data integration, or explicit class-level knowledge, ontology can provide something difficult to reproduce through application code alone.

Jeremy Ravenel then connected these issues to agentic AI. Agents may be able to retrieve information, call tools, execute code, delegate tasks, and act in an environment. But adding agency does not make the semantic problem disappear.

We used the Zebra Puzzle as a deliberately controlled environment for comparing approaches. Under incomplete information, LLM-based agents could generate plausible hypotheses abductively. As additional formal constraints were supplied, an OWL reasoner could increasingly establish answers deductively.

The lesson was straightforward:

Do not ask probabilistic AI to guess what a deterministic method can establish.

Or, stated another way:

Minimize the space in which abduction is required.

The Day 4 report develops this architecture in more detail.

Competing visions of where the field goes next

Students presented capstone work drawing together the lessons of the previous four days, after which we turned to several competing visions for what ontology engineering should become.

My own view is that the next generation of ontology engineering will focus much more heavily on mapping and transformation between semantic systems.

Different organizations and communities are not going to converge on one ontology for everything. Even communities committed to interoperability will sometimes make different ontological commitments for legitimate reasons.

Historically, this has too often produced ontology wars: which upper ontology is correct, which hierarchy should become authoritative, which vocabulary everyone else should adopt.

I think better tooling gives us another possibility.

We can increasingly place alternative hierarchies into formal relationship with one another and use reasoning to discover exactly where they agree, where they conflict, and which commitments would need to be weakened or surrendered to make a transformation possible.

That makes disagreement an engineering problem rather than only a philosophical or political one.

It also suggests that ontology engineering needs a much closer relationship with the broader world of formal verification: proof checking, satisfiability, model synthesis, model checking, constraint validation, and other methods for asking precise questions about formally represented systems.

Barry presented an overlapping but importantly different vision focused on the continuing development of BFO and shared foundational ontology.

That creates a productive tension.

Will future interoperability come primarily through stronger convergence on common foundational commitments?

Or will it increasingly come through sophisticated mappings between systems that do not share all of those commitments?

I suspect the answer will involve both.

The field also needs a new generation of tools. Protégé and TopBraid helped define the first generation of practical ontology engineering. The next generation should make continuous validation, mapping, transformation, entity resolution, collaboration, provenance, and AI assistance ordinary parts of the workflow.

And we will need to train far more people to use those tools. If ontologies are going to become part of the semantic infrastructure underlying AI, science, industry, government, and national security, ontology engineering cannot remain a niche expertise learned largely through apprenticeship.

The Day 5 NCOR report goes into much greater detail on these competing visions.

We ended the week with one final unresolved question: Can AI merely accelerate normal science, or could it eventually participate in the kind of revolutionary science that changes the conceptual framework of a field?

What I took away from the week

The most important lesson for me was that ontology engineering is broadening.

The field is no longer principally about constructing ontologies in an editor.

It increasingly involves:

• governing shared semantic infrastructure;

• mapping between independently developed conceptual systems;

• connecting semantics to data and knowledge graphs;

• combining deductive, inductive, and abductive reasoning;

• formally validating models and their consequences;

• designing AI systems in which stochastic and deterministic components have clearly defined responsibilities; and

• developing the tools and workforce necessary to make all of this operational.

The philosophical questions have not gone away. If anything, they become more important as the systems built on top of our conceptual distinctions become more powerful.

But applied ontology is also becoming a mature engineering discipline.

The question is no longer simply how do we build a good ontology?

It is becoming:

How do we build, connect, test, govern, and evolve semantic systems at the scale at which modern information systems—and increasingly AI systems—actually operate?

That is the ecosystem we were trying to explore.

And it is the one I think ontology engineering now has to build.

Watch and read more

The complete event recordings are available in the World’s Ontology Ecosystem YouTube playlist.

NCOR's five-part event report:

Day 1: From Philosophy to Tradecraft
Day 2: Careful Modeling Is the Point
Day 3: AI Should Support Ontology Engineering, Not Replace It
Day 4: Building AI Workflows You Can Actually Validate
Day 5: Where Ontology Engineering Goes Next

UB to Offer the World’s First Doctorate in Applied Ontology

“This program reflects UB’s long-standing leadership in ontology and its commitment to preparing students for the next generation of AI, data integration and knowledge engineering challenges.”

See full announcement here.

Ontology Engineering Tradecraft: This Is Ours, Own It

Ontology engineering has been around long enough that we should no longer be satisfied with vague answers about what it is.

We should not say, “Ontology engineers use OWL.” Lots of people use OWL. We should not say, “Ontology engineers use the Semantic Web stack.” So do other fields. We should not retreat into the familiar claim that ontology engineers are concerned with universals, or types, or formal representations of reality. We are not philosophers.

The question before our community is this:

What distinguishes ontology engineering from nearby disciplines, where one finds, for examples, taxonomies, concept maps, data models, database management, coding, and machine learning?

If we cannot answer that question, we do not have a distinct discipline. A discipline requires shared methods, shared success conditions, shared training, and shared standards of evaluation. It requires a way to say, with some seriousness: this is what counts as good work, this is what counts as bad work, and this is why.

Here is the proposal:

Ontology engineering is the discipline concerned with constructing machine-interpretable artifacts designed to systematically disambiguate information, improve information quality, and facilitate information interoperability.

The Promise and the Confusion

Ontologies are formally well-defined, machine-interpretable controlled vocabularies designed to represent entities and the logical relations among them. They are designed to make explicit the meanings buried in datasets. They provide a semantic layer across information silos. They allow people, machines, and systems to coordinate around shared representations of the world.

This promise is often muddled because ontology engineers conflate different kinds of interoperability. We talk about “interoperability” as if it were one thing, but there are at least three axes:

1. Human-human interoperability
2. Human-machine interoperability
3. Machine-machine interoperability

These axes are related, but they are not the same. They have different success conditions, and ontology engineers routinely confuse them.

Human-Human Interoperability

Human-human interoperability concerns whether people understand one another. It is the work of aligning meanings across stakeholders, communities, organizations, and domains.

This is where we elicit knowledge from experts, formulate competency questions, clarify key terms, and build consensus.

Ask three economists to define “GDP” and you may receive three answers. Ask three intelligence analysts to define “threat,” “risk,” “actor,” “source,” “capability,” or “event,” and watch the same thing happen.

Human-human interoperability is not trivial. It is not “just definitions.” It is the work of making disagreement visible enough that it can be addressed.

Ontology engineers operate on this axis when they extract key terms from domain experts, evaluate how those experts use language, and identify the points at which apparent agreement conceals real ambiguity.

But ontology engineers are not alone here. Dictionaries, thesauri, taxonomies, Wikipedia pages, standards documents, training materials, and institutional practices all operate, in different ways, along the human-human axis.

So this cannot be what uniquely distinguishes ontology engineering.

Human-Machine Interoperability

Human-machine interoperability concerns whether computational systems can interpret and act upon human-understandable descriptions of the world.

Here we translate expert knowledge into formal representations that machines can reason over. We use OWL, first-order logic, RDF, SPARQL, SHACL, reasoning engines, graph databases, and related tools.

This is the point at which a definition stops being a sentence in a document and starts becoming part of a computational artifact.

Ontology engineers operate on this axis when they formalize domain knowledge into machine-readable languages, build logical models, create class hierarchies, specify relations, add axioms, and test whether machines can infer what humans intended them to infer.

Progress here is evaluated by faithfulness of representation, human-machine integration, and the extent to which machines can extract useful explicit and implicit information from human-defined structures.

But again, ontology engineers are not alone here. Logicians, knowledge representation researchers, data modelers, software engineers, and AI researchers also work on this axis.

Machine-Machine Interoperability

Machine-machine interoperability concerns whether independent systems can exchange, interpret, and process data without humans in the middle.

This requires robust data structures, shared semantics, exchange protocols, APIs, query endpoints, and syntactic standards such as RDF, JSON-LD, OWL, REST, and SPARQL.

Success conditions include syntactic coherence, semantic alignment, computational feasibility, and the ability to query or reason across distinct datasets locally or over web protocols.

As should be obvious, ontology engineers are not alone here either; addressing interoperablity challenges along this axis is not what makes our discipline unique.

Interoperability Is Not Enough

Ontology engineering is often sold as a solution to interoperability. Taking all three axes as within scope of ontology engineering does not make the discipline unique. For one thing, it does not really explain why one would want to address interoperability problems. For that we turn attention to the fitness of information for its purpose, or information quality.

Interoperability and improving information quality must be pursued together.

Too much emphasis on interoperability leads to thin semantic artifacts that connect systems but lack the axiomatic richness needed to support serious validation, reasoning, and quality improvement.

Too much emphasis on information quality leads to isolated models that are locally impressive and globally useless.

We have all seen the patchwork quilts. An organization stitches together databases. Then it discovers inconsistencies. It stitches together more datasets to repair those inconsistencies. Then it re-checks the previous stitching. Then it updates the mappings. Then it prays the whole thing holds together long enough for the application to work.

Ontology engineering aims at addressing interoperability and information quality simultaneously. That means we need shared best practices: top-level ontologies, modularization, disciplined reuse, clear release strategies, explicit mappings, automated quality control, and governance mechanisms that treat ontology artifacts as serious infrastructure.

The Open Biological and Biomedical Ontology Foundry, the Industrial Ontologies Foundry, and related efforts exist because communities eventually learn the same lesson: if everyone builds their own conceptual universe from scratch, the result is not innovation. It is fragmentation with nicer tooling.

Each adopts a top-level ontology which gives ontology engineers a shared starting point. It provides a common architecture for distinguishing material entities, processes, qualities, realizable entities, spatial regions, temporal regions, and information entities. This in turn provides a foundation on which to avoid and uncover subtle ambiguities...

Systematic Disambiguation

Which leads to the final piece of our characterization of ontology engineering as a distinct discipline. At its heart heart is systematic disambiguation.

To disambiguate is not to find the one true interpretation of a phenomenon and declare victory. It is to identify and represent the logical space of relevant interpretations. It is to make distinctions explicit where data, language, systems, and human practices collapse them. For example:

• Type versus instance: Algeria as a particular country versus country as a type.
• Information versus what the information is about: an occupation code versus the person who holds an occupation.
• Material versus immaterial entities: a river versus the site where a river used to flow.
• Process versus product: ontology engineering versus the ontology produced through that engineering.

These distinctions sound simple; that is exactly why people overlook them. Let me say this more clearly.

These distinctions are so obvious you will forget to include them in your data.

Use a top-level ontology so you don't have to rely on some clever person to remember to disambiguate information from what it is about. Aim to disambiguate by design for the same reason. We should releae ourselves from reliance on genius; we should democratize access to meaningful inferences currently hidden in our data.

This Is Ours

There is no other discipline focused on systematically disambiguating data in this manner. It is what we do and what we do best.

Own it.

Systematic disambiguation is what allows ontology engineering to address both interoperability and information quality. It allows us to build representations that are clear enough for humans, formal enough for machines, and stable enough for systems to exchange and reuse.

For example, a complete representation of any serious use case will eventually touch every major region of BFO. It will involve material entities, processes, qualities, realizable entities, temporal regions, spatial regions, and information entities.

You cannot address deep interoperability challenges if you only model one sliver of reality and pretend the rest does not matter.

But this does not mean every application needs the full graph.

The Full Semantic Cloth

The semantic layer and the operational layer are not the same thing.

The full semantic representation is the cloth; the operational release is the cut.

Different applications need different subsets, different views, different modules, and different interfaces.

You should cut your operational release from the whole semantic cloth.

Do not confuse the fact that users need simplicity with the idea that the underlying representation should be simplistic. Users need useful views. Machines need coherent structure. Organizations need release strategies. Ontology engineers need to understand all three.

Toward a Discipline

The new era of ontology engineering will be built by method.

But it will only become a discipline if we insist on the methods that distinguish it.

So let us stop hiding behind tool names. Let us stop defining ontology engineering by whatever syntax we happen to use this year. Let us stop pretending that a taxonomy becomes an ontology because someone exported it in RDF.

Ontology engineering is not taxonomizing. It is not concept mapping. It is not data modeling. It is not coding. It is not database management. It is not machine learning. It may use all of these. It may collaborate with all of these.

But it is not reducible to any of them.

Ontology engineering is the systematic construction of machine-interpretable artifacts that disambiguate information, improve information quality, and facilitate interoperability.

That is the tradecraft.

And if we are serious about the future of the field, that is where we begin.

Fully Online Applied Ontology MS

“Beginning with the spring 2026 semester, UB will launch a fully online Master of Science degree (MS) in applied ontology. Housed within the university’s Department of Philosophy in the College of Arts and Sciences, the applied ontology degree will prepare students from around the world for work in this rapidly growing interdisciplinary branch of information science.“

See full story here.

Novotný - Philosophical Perspectives on AI Risks

Daniel D. Novotný, an NCOR affiliate in the Center for Applied Philosophy, University of South Bohemia, recently gave a presentation on AI risk at the Philosophy of AI 2025 Conference held in the Czech Academy of Sciences, Jilská, Prague.

Check out the bridge between AI risk and ontology engineering from a philosophical perspective. Enjoy Daniel’s slides here.

Ninja Death

You may be surprised to know, I have a bit of a silly side. As example of this is a game that my friends and I play called “Ninja Death”. The premise of this game is that you are a ninja, an expert at sneaking up on and attacking individuals and warding off attacks from others. You are, however, being targeted by other ninjas. They will be attacking you in a special way, namely, by tricking you into reading “Ninja Death” in some way . You should be on guard of such attacks. You will, on the other hand, be aiming to attack them in the same way, by tricking them into reading “Ninja Death”.

If you are tricked into reading “Ninja Death” then you are out for the day, and will be back in action the next morning. If you trick someone else, they are out for the day and will be back the next morning.

To win a day, you need to survive. The best way to survive, is to trick everyone else playing into reading “Ninja Death”.

Now you know what I know. Let’s play.

As a corollary, if I’ve written this cleverly enough, the following ninjas should be taken out today:

1. Denise

2. David

3. Mark

4. Brian

5. Jake

6. Lewis

C-FORS Summer School Foundational Ontologies

At this year’s C-FOR Oslo tutorial, I had the opportunity to guide participants through the foundational principles of Basic Formal Ontology (BFO), with an emphasis on concrete modeling exercises tied to real-world datasets. The tutorial was designed for professionals and researchers seeking to deepen their technical mastery of ontological modeling using BFO as a semantic backbone.

We began by reviewing the fundamental structure of BFO, distinguishing between continuants and occurrents, and exploring key upper-level categories like independent continuant, specifically dependent continuant, process, and quality. I emphasized that good ontological modeling must track not just the static entities in a domain but also their evolution and realization across time—a theme that recurred in all four case-based exercises.

The hands-on portion of the tutorial consisted of four exercises, each paired with worked-out solutions that participants could study in parallel. You can find my slides for the tutorial, background reading, exercises, and solutions on the National Center for Ontological Research (NCOR) Academy github page.

Many thanks to Salvatore Florio, Guendalina Righetti, and Øystein Linnebo for being gracious hosts.

What follow is brief discussion the the solutions provided.

Case 1: Jet Specification

We modeled an aircraft (Airbus A320 Neo) using a design pattern grounded in BFO axioms. The task was to represent how technical specifications—like engine model and dimensions—are linked via roles and qualities to a material artifact and its manufacturer. Participants learned how to use is about, has continuant part, and rdf:type only to capture class-level constraints.

Case 2: Aircraft Performance Measurement

This scenario modeled a deviation between expected and observed approach speeds of an Airbus A321-111. We illustrated how to construct a BFO-conformant pattern that ties together design specification, test process, and measurement data, using temporal parts and process aggregation. The exercise culminated in a SPARQL query designed to compute the average measured approach speed over several trials.

Case 3: SOC Role Definitions

Here, we modeled the U.S. Standard Occupational Classification roles for aerospace engineers, capturing how job descriptions such as “Adaptability Evaluation” and “Equipment Testing” relate to outputs and realizable entities like reports and aircraft specs. This showed how to handle granular roles in applied ontology work.

Case 4: Employment Data Modeling

The final case involved linking employment statistics to SOC role definitions using publicly available wage data. Participants mapped employment totals as qualities inhering in object aggregates, which were in turn outputs of measurement processes, all conforming to BFO’s realist ontology commitments.

LLMs and Ontology Engineering at JOWO 2025

The rapid development and deployment of Large-Language Models (LLMs) has led to growing interest in leveraging ontologies and knowledge graphs to enhance LLM capabilities and address limitations. Combining the semantically rich architectures provided by ontologies and knowledge graphs with the generative strengths of LLMs promises to provide a path towards more explainable artificial intelligence systems, more trustworthy output, and a deeper understanding of vulnerabilities arising from integrated architectures.

This workshop is dedicated to exploring the convergence of knowledge representation and LLM strategies, design patterns, models, and benchmarks. We aim to bring together researchers, practitioners, and enthusiasts from industry, academia, and government in the interest of exploring possible convergence points and advancing each field.

The deadline has been extended for submissions to June 1.

We invite submissions for our workshop focusing on the intersection of Applied Ontology and Large Language Models as part of Joint Ontologies Workshop (JOWO) episode XI, affiliated with FOIS 2025.

Post on linkedin here.

More importantly, post to the Call for Papers here.

AI's Role in Law: Assistance, Not Replacement

Full Baldy Center Blog Post here: https://www.buffalo.edu/baldycenter/multimedia/blog/24-25-blog.html#50  
Danielle Limbaugh and John Beverley 

Leveraging sophisticated chatbots seems in many ways foreign to the creative, trusted, and impactful work done by legal professionals. A question of growing importance is:

How do we promote trust among legal professionals with respect to platforms and tools leveraging modern advances in AI?

There is reason to be hopeful: ontology engineering, a discipline which focuses on the creation of structured vocabularies and relationships within data. Techniques from the field of ontology engineering have long been leveraged for promoting explainability, as they aim to make explicit the implicit formal structure of data. When AI systems are built on well-structured ontologies, they:

1. Provide clear reasoning paths for their conclusions;

2. Make explicit the relationships between different legal concepts;

3. Help identify relevant precedents and principles more accurately; and

4. Maintain consistency in legal interpretation.

As we move forward, the legal profession should embrace ontology engineering as a crucial component of AI implementation. It's not just about making AI systems more accurate; it is about making them more trustworthy and aligned with the fundamental principles of legal practice.

Promoting Healthy Aging at JOWO 2025

I want to live forever. Not metaphorically; I literally want to be immortal. I have no idea what research should be prioritized to make this a reality, but I suspect facilitating the generation of novel hypotheses and research avenues out of the vast amount of biomedical, psychological, and health-related data we have been storing for decades, will be key.

Now, I don't just want to be immortal, I want to be immortal and healthy. Aging in a healthy manner is perhaps an easier problem to tackle. Baby steps, I suppose.

With this in mind, I encourage you to submit to the Promoting Healthy Aging through Semantic Enrichment of Solitude Research (PHASES) workshop, the deadline for which has been extended to June 1st.

Maybe being immortal isn't your goal; but don't let that stop you from helping me live my best (unending) life.

As if you need any more enticement, PHASES will be part of the 2025 Joint Ontology Workshops (JOWO), which will be co-located with FOIS 2025, and held on 8-9 September, in Catania, Italy.

See linked in post here.

More importantly, see Call for Papers here.

Finding Meaning

View fullsize

“This research supports the idea
that late midlife is a time of possible positive change and that one has the power to work toward personal growth, fulfillment, understanding and acceptance. ”
Hollen Reischer, Visiting Assistant Professor
University at Buffalo, Department of Psychology

Late midlife often brings more than gray hair and regret. As Hollen Reischer’s recent study shows, many people begin to reinterpret their lives, weaving hardship and success into a richer, more coherent story (Reischer, 2025). This process — narrative self-transcendence — isn't about denying pain, but finding meaning in it. The events themselves don't change. The way we see them does.

Ontology engineering faces a similar task. Ontologies don't just store facts; they impose structure on complexity. They decide what distinctions matter and what patterns endure. In building ontologies for solitude and gerotranscendence, we aren’t simply cataloging experiences — we’re formalizing interpretations that, until now, have lived in scattered fields and shifting vocabularies.

Reischer’s work reminds us that growth is not about acquiring more, but interpreting better. Solitude, too, plays its role: not as mere isolation, but as space for re-narration. Quiet moments allow us to redraw the map of ourselves, connecting disparate experiences into something comprehensible.

Good ontology work mirrors this quiet architecture. It clarifies without flattening. It allows reinterpretation without erasing complexity. It is, in its way, a technical act of transcendence — aligning data points into a form that admits not just coherence, but growth.

There is something surprisingly human here: the same instinct that drives a solitary reflection at midlife drives the best efforts to structure knowledge. In both cases, we aren't chasing precision for its own sake. We are looking for meaning.

Towards an Ontology of Loving

Love is deeply personal and philosophically complex; it is also surprisingly underdeveloped in ontology engineering. Given the amount of research on this topic, it is worth moving beyond vague definitions towards a rigorous ontological model.

My favored starting point is what I call the Concatenation View (CV), which defines love as the combination of a passive sensation (e.g., emotional arousal) and an active evaluative judgment (e.g., perceiving the beloved as valuable). This model reconcile love’s felt immediacy with its rational accountability—addressing the philosophical puzzle of why love seems both involuntary and yet subject to justification. Among other benefits, this view explains the irrationality of love, namely, that we tend to want better for those we love than what we believe they deserve.

There are, of course, objections worth handling, such as how love can be causally linked to judgments about a beloved rather than merely being a regular co-occurrence of feelings and thoughts. To find out more, you’ll simply have to wait for me to finish the current paper I’m writing.

Stay tuned.

Man with the Golden Arm

Imitation is the sincerest form of flattery that vice can pay to virtue.

John Harrison - the man with the golden arm - died February 17th 2025. Mr. Harrison was inspiring, both morally and intellectually, which dovetailed in my research on epistemic and moral responsibility. His blood plasma was used to synthesize a cure for Rhesus disease, and in donating is estimated to have saved the lives of over 2 million infants worldwide. Remarkable.

Mr. Harrison has been a staple example in my work on responsibility, e.g. Ties that Undermine, Judgments of Moral Responsibility in Tissue Donation Cases, and Speak No Evil. I leave you with a passage from the last of these works:

“…Rhesus disease kills millions of infants around the world, and there is – at present – not a cure that can be synthesized in a lab without the blood plasma of John Harrison. Harrison’s donations have saved the lives of approximately 2.4 million infants worldwide. It seems plausible he has a responsibility to donate. But it also seems Harrison is uniquely positioned to help, and carries great responsibility to do so. To see this, consider if each of us knew we were able to provide blood plasma that could be used to synthesize a vaccine for Rhesus disease, but none of us donated, then we would have all done something morally wrong, but none of us would have obviously done anything worse than anyone else in this context. In contrast, in our context where John Harrison is uniquely able to provide this aid and is aware of that fact, John refraining from donating blood plasma seems morally worse than it would be in the context where everyone – himself included – could donate but decided not to. Perceived rarity to provide aid influences judgments of moral responsibility...”

Mapping PROV to BFO

The Provenance Ontology (PROV-O) is a World Wide Web Consortium (W3C) recommended ontology used to structure data about provenance across a wide variety of domains. Basic Formal Ontology (BFO) is a top-level ontology ISO/IEC standard used to structure a wide variety of ontologies, such as the OBO Foundry ontologies and the Common Core Ontologies (CCO). To enhance interoperability between these two ontologies, their extensions, and data organized by them, an alignment is presented according to a specific mapping criteria and methodology which prioritizes structural and semantic considerations. The ontology alignment is evaluated by checking its logical consistency with canonical examples of PROV-O instances and querying terms that do not satisfy the mapping criteria as formalized in SPARQL. A variety of semantic web technologies are used in support of FAIR (Findable, Accessible, Interoperable, Reusable) principles.

Full paper open access in Scientific Data.

bCLEARer & Ontologization Space →

Check out the recent arxiv preprint “Extending the design space of ontologization practices: Using bCLEARer as an example” co-authored by Chris Partridge, Andrew Mitchell, Sergio de Cesare, and myself.

We outline how the design space for the ontologization process is richer than current practice would suggest. We investigate the possibility of designing a range of radically new practices, providing examples of the new practices from Chris’s work over the last three decades with an outlier methodology: bCLEARer. We also suggest that setting an evolutionary context for ontologization helps one to better understand the nature of these new practices by positioning digitalization (the evolutionary emergence of computing technologies) as the latest step in a long evolutionary trail of information transitions.

Fourfold Pathogen Reference Ontology Suite →

The Fourfold Pathogen Reference Ontology Suite includes four pathogen-specific extensions. The Virus Infectious Disease Ontology (VIDO) focuses on viruses such as SARS-CoV-2, offering detailed representations of viral taxonomy, replication mechanisms, and disease manifestations. The Bacteria Infectious Disease Ontology (BIDO) provides a structured framework for bacterial pathogenesis, taxonomy, and diseases, emphasizing key mechanisms like bacterial adhesion and toxin production. The Mycosis Infectious Disease Ontology (MIDO) tackles fungal infectious diseases, addressing fungal taxonomy, antifungal resistance, and host-pathogen interactions. The Parasite Infectious Disease Ontology (PIDO) models parasitic life cycles, pathogenesis, and host-parasite relationships. These modular ontologies follow a hub-and-spoke methodology, with the Infectious Disease Ontology (IDO) serving as the central hub to ensure semantic consistency and modularity while minimizing redundancy.

More details here: https://arxiv.org/pdf/2501.01454

Barry Smith and John Beverley on Applied Ontology Jobs

If you are interested in the philosophical history of applied ontology, MS and PhD programs being established in the University at Buffalo for this field, or the - to my mind - ethical motivations that drive many ontology engineers to work with US government agencies, then by all means enjoy this American Philosophy Association interview.

Applied Ontology in 1998: Birth of a New Discipline

Applied Ontology - University at Buffalo

BFO-CCO Office Hours

BFO-CCO Office Hours

Given the growing importance of Basic Formal Ontology and the Common Core Ontologies suite, in defense and intelligence, biology and medicine, as well as service and manufacturing, there is a need for transparency concerning the development and maintenance of these artifacts.

With this in mind, the lead developers of BFO and CCO will hold biweekly "office hours" for stakeholders with questions, concerns, comments, or compliments regarding these standards. These office hours will be stakeholder-led, in that discussion during these one hour sessions will be driven by stakeholders attending the meetings.

Logistics

• When: Biweekly on Fridays, starting May 31st 2024, 11am - 12pm

• Where: Virtual Meetings on Teams

If you are interested in joining one or more office hours, please contact John Beverley at johnbeve[@]buffalo.edu. You will be provided a Teams invite for the scheduled time.

In addition to the biweekly office hours, there is an associated Slack channel for the group where stakeholders may continue conversation with the BFO and CCO leads. As above, please contact John Beverley at johnbeve[@]buffalo.edu to be added to the BFO-CCO Office House Slack channel.

As stakeholder questions are addressed, we will also establish an "FAQ" where stakeholders will be directed for vetted answers to commonly posed questions.