Fitting Horn DL Ontologies to ABox and Query Examples: A Tale of Simulation Quantifiers and Finite Models
This paper investigates the computational complexity of fitting Horn DL ontologies (specifically EL and ELI with or without the bottom concept) to ABox and Boolean query examples, characterizing the existence of fitting ontologies via simulations and establishing that the problem ranges from PTime for atomic queries to -complete or ExpTime-complete for conjunctive and union queries, respectively.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are a master architect trying to design a set of building rules (an ontology) for a city. You don't have a blank slate; instead, you have a collection of examples given to you by a client.
- Positive Examples: "Here is a house that must be built according to my rules."
- Negative Examples: "Here is a house that must not be built according to my rules."
Your job is to write the rulebook so that it perfectly fits all the "yes" houses and rejects all the "no" houses. If you can't do it, you have to tell the client, "No such rulebook exists."
This paper is about how hard this job is when the rules are written in specific, simplified languages called Horn Description Logics (specifically EL and ELI). These languages are like "Lego" sets: they are very efficient and fast to use, but they have strict limits on what you can build (you can't use certain complex "negative" or "inverse" tricks that more powerful languages allow).
Here is the breakdown of their findings, using some everyday analogies:
1. The Core Challenge: The "Look-Alike" Problem
In the past, researchers studied this problem using very powerful, complex languages (like ALC). They found that if a "no" house looks like a "yes" house in a very specific way (via a homomorphism, which is like a direct, one-to-one map), you can't separate them.
However, this paper focuses on the simpler EL/ELI languages. Here, the "look-alike" test is different. Instead of a strict map, we use Simulations.
- The Analogy: Imagine a Homomorphism is like a strict photocopy. If the original has a red door, the copy must have a red door in the exact same spot.
- The Analogy: A Simulation is more like a shadow or a simulation in a video game. A simple loop in the real world might be simulated by a long, winding path in the shadow world. The shadow doesn't have to match the shape exactly, but it must be able to "mimic" the behavior of the original.
The authors found that because simulations are more flexible (and sometimes "infinite" in nature), fitting rules for these simpler languages is actually technically harder than for the complex ones, even though the languages themselves are simpler. It's like trying to fit a square peg into a round hole, but the hole is made of water—it's harder to pin down.
2. The Three Types of Questions
The researchers tested how hard it is to find these rules based on the type of question the client asks:
- Atomic Queries (AQs): "Is this specific person a 'Manager'?"
- Result: Easy (PTIME). You can solve this quickly, like checking a grocery list. Whether you use the basic language (EL) or the one with inverse roles (ELI), it's fast.
- Conjunctive Queries (CQs): "Is there a person who is a Manager and has a child who is a Doctor?"
- Result: Harder.
- For basic EL: It's -complete. Think of this as a game of "Guess the Rule" where you have to make a guess, and then someone else tries to prove you wrong. It's a two-step mental gymnastics routine.
- For ELI (with inverse roles): It gets even harder (EXPTIME). This is like trying to solve a puzzle where the number of possibilities grows so fast that even a supercomputer would take a long time to check every single possibility.
- Result: Harder.
- Unions of Queries (UCQs): "Is the person a Manager OR a Doctor?"
- Result: Same complexity as CQs.
3. The "Bottom" Concept (The "Nothing" Concept)
The paper also looked at adding a "Bottom" concept (⊥), which represents "Nothing" or "Impossible."
- The Finding: Adding this "Nothing" concept didn't change the difficulty at all. It's like adding a "Do Not Enter" sign to your rulebook; it doesn't make the math of fitting the rules any harder or easier.
4. The Size of the Rulebook
The authors also asked: "If a solution exists, how big will the rulebook be?"
- For Simple Questions (AQs): You can write a rulebook that is reasonably small (polynomial size).
- For Complex Questions (CQs/UCQs):
- If you are allowed to use new, made-up names (auxiliary symbols) in your rules, the rulebook stays manageable (polynomial size).
- If you are forbidden from using new names and must only use the names from the examples, the rulebook can explode in size (exponential).
- The Exception: For the ELI language with complex queries, they couldn't even find a limit on how big the rulebook might get. It might be infinitely large or just too huge to calculate.
5. The "Finite" vs. "Infinite" Trap
One of the most interesting technical discoveries is about finite models (worlds with a limited number of things) vs. infinite models.
- In the complex languages (ALC), you can usually assume the world is finite without losing anything.
- In ELI, the "simulation" nature of the rules allows for infinite paths (like a hallway that goes on forever). The paper shows that for ELI, you must consider these infinite possibilities to get the right answer. If you try to force the world to be finite, you might miss the solution or get the wrong one. It's like trying to predict the weather by only looking at the next hour; sometimes you need to look at the whole season to get it right.
Summary
This paper is a "stress test" for a specific type of logical rulebook.
- Good News: If your questions are simple ("Is X a Y?"), the computer can find the rules very fast.
- Bad News: If your questions are complex ("Is there a chain of connections between X and Y?"), the problem becomes computationally heavy, especially when you allow "inverse" relationships (looking backward as well as forward).
- Surprise: Using the simpler, faster languages (EL/ELI) doesn't necessarily make the "fitting" problem easier; in fact, the mathematical tools needed to solve it (simulations) introduce new, tricky complications that the more complex languages didn't have.
The authors provide the exact mathematical "recipes" (algorithms) to decide if a solution exists and how hard it will be to compute, giving engineers a clear map of what is possible and what is computationally too expensive.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.