Practice: Concept Hierarchies as Ordered Structures

1. Problem 1: the missing join. Upper bounds of Tablet and BusinessDevice are the concepts subsuming both. Tablet is subsumed by Computer, Portable and Device; BusinessDevice is subsumed by Device only. The single common upper bound is therefore Device, and since it is the only one it is trivially the least, so a join does exist here, and it is Device. The tool getting nothing is the more interesting finding, and it points at the query rather than the ontology: asking for "the most specific category containing both" presumably excluded the top-level Device as uninformative, or asked for a common subclass rather than a superclass. I would establish which before changing anything. The general point still holds and is worth recording for the team: subsumption is a partial order, Computer and Portable and BusinessDevice are pairwise incomparable, and pairs with no join do occur. Here Tablet and BusinessDevice are not such a pair. 2. Problem 2: the derived subsumption is correct. PortableBundle $\equiv$ Portable $\sqcap$ $\mathrm{\exists }$hasAccessory.Charger. Anything in it has a hasAccessory value, so it satisfies $\mathrm{\exists }$hasAccessory.Thing, which defines AccessorisedItem. The conjunct $\mathrm{\exists }$hasAccessory.Charger is subsumed by $\mathrm{\exists }$hasAccessory.Thing by monotonicity of the existential restriction, and adding the Portable conjunct only narrows it further. So PortableBundle $⊑$ AccessorisedItem is entailed and cannot be removed without removing what entails it. I would tell the reviewer the edge is a consequence of their own definitions, not an error: a classified hierarchy routinely contains edges nobody drew, and this is the mechanism working. If they do not want it, the definitions have to change, and the change would make PortableBundle not require an accessory, which is presumably not intended. 3. Problem 3: the open-world reading. The reasoner returns nothing because the absence of a hasAccessory assertion does not entail that a device has no accessory. Under the open-world assumption the ontology entails neither AccessorisedItem(x) nor its negation for such an individual, so there are no individuals known not to be accessorised. Three ways to get the report they want: - Query for individuals not known to be accessorised, which is a question about the knowledge base rather than the world, and is answerable directly.
- Close the property for the individuals concerned, asserting for each that it has at most zero hasAccessory values, which is laborious and rarely what is wanted.
- Use a closed-world validation mechanism such as SHACL for the data-quality report and leave the reasoner to entailment. This is the right answer for a data-quality report, whose entire purpose is to find missing information. 4. The unreported risk: the domain declaration. hasAccessory with domain Device is an axiom, not a constraint. It says everything with a hasAccessory value is a Device. When an accessory is recorded against something that is not a device, a warranty, a gift card, a bundle placeholder, the reasoner will not reject it; it will infer that the thing is a Device. That inference then propagates: the misclassified individual joins every query over Device, and if it is also asserted to be something disjoint from Device, the individual becomes unsatisfiable and the whole ontology may be reported inconsistent. Either outcome is worse than a rejected import, and neither is visible until it happens. This is the most serious item in the audit and the team has not listed it. 5. What I would change. - Not a problem: the derived PortableBundle $⊑$ AccessorisedItem. Leave it; explain it.
- Not an ontology problem: the missing join in problem 1. Device is the join; investigate the merchandising query.
- Not a reasoner problem: problem 3. Move the data-quality check to a closed-world validator, and rewrite the report's wording so "not accessorised" becomes "no accessory recorded", which is what the data actually supports.
- Change before shipping: decide whether the hasAccessory domain is meant as an inference or a constraint. If a constraint, remove the domain axiom and enforce it in validation. If an inference, add disjointness axioms between Device and the other top-level types so a bad import produces an inconsistency that is caught, rather than a silent misclassification.
- Add for clarity: disjointness between Computer and any sibling categories that genuinely cannot overlap. Without it the classifier cannot detect contradictory data, and most of the value of running a reasoner over a catalogue is exactly that detection.