why does every company have a parent company?

[micheldumontier]

The class Company includes a subclass axiom "hasParentCompany some Company", but what makes this universally true? There's no description to guide the usage. I can imagine this is more relevant in the context of some transaction, but I don't think it holds true for any company.

[kodymoodley]

@micheldumontier : Yes, this is a good point. But there may be compelling reasons for keeping this axiom. While it may not be universally true, it may be advantageous for reasoning purposes to draw this inference for our dataset of companies. In the case where a company does not have a parent company, another perspective can be that the company is a parent company of itself :) I.e. as long as we don't force the "hasParentCompany" relation to be irreflexive, a specific instance of this relation can be reflexive.

[micheldumontier]

If it is the case that a company does not necessarily have a parent company, then you must not use an existential restriction on the class company, because then there surely is some parent company for every company.

If it is the case that every company has itself as a parent company, then isn't it better to
i) add company as the domain and range of the hasParentCompany relation
ii) make hasParentCompany reflexive
this way you get that entailment.

[kodymoodley]

You're right that it is a correct reflection of the domain to exclude this axiom. Right now, while I don't have a concrete use case why we may need it, I am thinking along the lines of this example scenario: suppose we build a software agent to crawl our KG and it notices a node which is of type company, it will conclude from our axiom that this company has a parent company. It may then notice there is no outgoing "hasParentCompany" edge from this node in the graph and it could proactively conclude that the graph is incomplete and prompt the user: "is this a missing data point in the graph?". If we don't have this axiom, it will not occur to the agent to even ask this question.

The ideal situation is if OWL allowed us to say things like "A company usually has a parent company or a company may have a parent company", but we can't say this in standard OWL. I actually investigated this topic in my PhD and it was quite interesting. I created a reasoner and extension to Protege which could express and reason logically with usually type statements (https://github.com/kodymoodley/defeasibleinferenceplatform/wiki). However, I am uncertain about the scalability of performance for large ontologies. So that is basically the motivation for this admittedly contentious modeling choice.

The solution of enforcing reflexivity as you propose above is semantically slightly different to what we intend. It will enforce that every instance of Company will be a parent company of itself. If you leave this out, the standard DL semantics still allow the reasoner to infer that a specific company is a parent of itself (if there is no parent company specified). If there is a parent company specified, it will not infer that it is a parent of itself.

[micheldumontier]

You can manage the situation in 2 other ways.
First, you could use a universal quantifier to indicate that the only individuals for the hasParentCompany relation held by a Company, is a Company (e.g. Company subClassOf hasParentCompany only Company).

Second, you could use SHACL/SHEX to specify the structure of the underlying graph, in which there may be 0 or more hasParentCompany relations to a Company for a Company Shape. Then there is no ontological commitment required, but that the shape graph can be parsed for possible or required relations.

I'm also going to argue that hasParentCompany is irreflexive ; that there is no company that has itself as a parent company. this way you can focus on those parent company that result from mergers and acquisitions.

[kodymoodley]

...good point. I think adding a constraint layer using SHACL/SHEX would probably be a better approach to deal with this. Then we have a nice decoupling of the ontology from the specific use cases. Keeps the model leaner and hopefully more interoperable / reusable. Thanks!

[micheldumontier]

you're welcome!