Can there be support for multiple inheritance please? While even languages like Java & C# support for multiple inheritance via Interfaces, it will be a powerful & necessary feature for a knowledge graph.
We have actually been going back and forth on this one for a while. The conclusion we keep hitting is that we will implement it only when we truly need it because while it is a powerful feature it does add some complexity to the model.
What’s been stopping us from diving into this is that we can’t think of an example that cannot be modeled with the current single inheritance constraint. Do you have such an example in mind? If so that would probably expedite the feature.
Correct me if I’m wrong, but using Grakn’s model this could be achieve by assigning multiple roles to the same entity right ? if you define it in a hierarchical way, (with
car sub vehicle;), is it possible to inherit from multiple entities?
Yes that is 100% correct! and thank you for clarifying the issue. Grakn allows multiple inheritance as long as its from the same “branch”. In other words this works:
insert vehicle sub entity; car sub vehicle; smaller-car sub car;
However, this does not:
insert vehicle sub entity; car sub entity; smaller-car sub vehicle; smaller-car sub car;
In the latter case
smaller-car will not inherit from both but will first be a
vehicle and then be changed to a
Note that multiple inheritance is fundamental to many/most ontologies, and lack of support may make GRAKN a non-starter for most ontology-based work. Eg. most biomedical ontologies (GO, HPO, UBERON, PATO, Cell ontology, etc.). One can work-around this limitation by defining a relationship as ‘subclass’ and use that in lieu of the native ‘sub’, but that is a hack around one of the main selling-points of GRAKN: that it supports ontologies.
Actually, we can still represent them in Grakn. The problem with multiple-inheritance, is that every time someone comes up with a problem that needs to be modelled with multiple-inheritance, it’s often an abuse of the construct.
government can employ a
company can employ a
person. Then users often think there should be an entity that inherits both
company entity that can employ a
person - e.g. they end up with a
employer entity that subclasses both.
This is an example of an abuse of inheritance, as it is used in the wrong place. This problem is solved by the notion of a
role in Grakn.
roles are part of
relationships that contextualises a how a
thing s are involved in a
The correct way, as we model it in Grakn, is to have
employer as a role in an
employment relationship, where
company plays the role of an
Here’s an example schema of it:
company sub entity, has name, plays employer; government sub entity, has name, plays employer; employment sub relationship, relates employee, relates employer;
Let me know if that makes sense. And do share if you there are problems that are critical to be modelled with multiple-inheritance that cannot be modelled with
Hi @haikal, yes, in ontologies it is important to distinguish which properties of a class ought to be considered truly inheritable, and which should not. In your example, a state-government, and indeed any government that is a smaller entity, might still be reasonably considered to be an employer, so we would want that role to be inherited by any subclasses without having to explicitly restate it.
If roles, when assigned to entities, are already heritable in GRAKN, then the problem is solved - and basically, GRAKN is (nearly) supporting multiple-inheritance by another name.
If not, there is a truth-maintenance issue introduced, since we’d need to indicate the inherited roles explicitly on each subclass.
Consider the example
cancer sub entity; liver_disease sub entity; liver_cancer sub cancer; liver_cancer sub liver_disease;
In a case where we do not want to (or can’t) arbitrarily select “cancer” or “liver disease” to be represented via a “role”, how would we model the above w/o multiple inheritance?
First, yes, the
roles are inherited when type subclasses another.
Regarding your example, I see two potential problems with the suggested model.
- It uses multiple-inheritance to “group” things, rather than to subclass “types”, where each type is a definition of something else. In this case,
canceris probably a group of diseases? Which is not the same as a type. If we quickly look at wikipedia:
- It represents an
typein the schema, rather than as an
instanceof fact in the graph. In this case,
liver-canceris probably an instance of a disease? More specifically, an instance of a liver disease?
Thus, I would probably model this problem like the following:
define disease sub entity, has name, plays member; liver-disease sub entity; disease-group sub entity, has name; plays owner; grouping sub relationship, relates member, relates owner;
And insert data instances (i.e. facts) to the graph such as the following:
insert $x isa liver-disease, has name "liver cancer"; $y isa disease-group, has name "cancer"; (member: $x, owner: $y) isa grouping;
You can then query the graph like:
match $x isa disease, has name $xn; ($x, $y); $y isa disease-group, has name "cancer"; get $x;
Which will return a
$x as a
liver-disease with name “liver cancer”.
What do you think? Would that make sense?
Hierarchies can be malformed if incorrect superclasses are used, but multiple, semantically-correct direct-superclasses are common in many ontologies. It is true that one can tease apart properties and roles reflected in a logical superclass and model those associations to a subclass independently, but one should be able to model the superclass entity that encompasses those and relate it to all logical subclasses.
Consider a multiple-inheritance example common on Protege pages from Stanford: Red_wine, Dessert_wine, and Port_wine. Consider some biological processes in the GeneOntology, eg. http://amigo.geneontology.org/amigo/term/GO:0006663. Consider some phenotypes in HPO, eg. https://hpo.jax.org/app/browse/term/HP:0001043. Consider an extension of the example above: vehicle, car, small-vehicle, small-car. In OWL, a class can have as many superclasses as are named or logical identified by DL reasoning.
I have seen many assertions that ‘most ontologies support multiple inheritance’, and that has been my experience, but I haven’t computed the fraction that do. Since multiple inheritance is reflected in many reference ontologies that might be data sources for users of a graph database, it would help greatly to enable direct representation of those ontologies in GRAKN without working around the n=1 superclass limitation.
What would the Grakn way look like for something I’m inclined to model in the following fashion?
define software sub entity, has name, … ; service sub entity, has name, … ; saas sub software, sub service, has url … ; insert $fb isa saas, has name "Facebook", has url "https://facebook.com" … ;