Please review and test the inheritance mechanisms based on the algorithm I explained in the description.

[ImanYZ]

• Please check the following rules are applied to the inheritance:
  • One can define new properties that are not inherited for the new object.
  • One can delete any of the objects' properties, including the inherited ones.
  • If the new object had pre-existing properties that are not found in the generalization, it will retain those properties along with their corresponding values.
  • If the new object had pre-existing properties that also exist in the generalization, it will retain those properties. However, the user who added this object under this generalization is responsible for determining whether the value of each property should remain unchanged or be inherited from the corresponding property in the generalization.
  • If we follow the chain of generalizations for an object, moving from the object’s immediate generalization to its generalization’s generalization (i.e., the grand-generalization), and continue this process until reaching a generalization that has no further generalization, that node is referred to as the “Root” of the object.
  • The specialization and generalization relationship is acyclic, meaning:
    • If node A is a specialization of node B, then node B (its generalization) cannot be defined as a specialization of node A.
    • If node A is a specialization of node B, and node B is a specialization of node C, continuing this chain up to node N, then node N cannot be defined as a specialization of node A.
  • When an object is being deleted:
  • We are not allowed to delete an object that is the only generalization of another object, so we should first delete its specializations or move them to other generalizations because “no object can exist without having at least one generalization,” for two reasons:
    • Having a node with no generalizations means it's a completely new type independent of Activity/Actor/Incentive/Reward/Evaluation Dimension. The proposer should rethink through this.
    • This node would not be accessible in the knowledge graph anymore.
  • The object should be automatically removed from the specializations and generalizations of the other objects.
  • A Root can never be deleted.
  • Please add a tab after comments in the right sidebar with the title "Inheritance" where we would specify the following types of inheritance per property of the object. When a change is made to a property of an object that already has specializations:
  • We assume that all properties in all objects have an “inheritance type.” This value determines what happens automatically when changes are made in this property in the parent of the current object (i.e., when the changes in an ancestor would ordinarily be inherited here).
  • For each specialization, If the inheritance type of the changed property is:
    • Never inherit – then the change is not made
    • Always inherit – then the change is always made
    • Inherit unless already over-ridden – then
      • If the property that is about to inherit a change from its parent has already over-ridden the value of this property, then no change is made
      • Otherwise, the inherited change is made
    • Inherit after review – then
      • The user who changed the value of the property in the generalization would determine whether to inherit that change to the corresponding property in any of the specializations or descendants of the object. You can implement this by opening a model with:
        • A message on top saying "Choose which of the following specializations that have inherited this property should inherit the same change in the value of the property:"
        • List all the specializations or descendants of the object that have inherited this property, as a tree-view with all the branches expanded by default, with a checkmark for each so that the user can check every specialization in which the corresponding property should get the new inherited value.
          • If the user does not select some specializations or descendants, their properties would not be modified due to the change made to this property in the generalization. However, they are still considered inherited and not overridden, meaning that the next time the value of this property gets changed in the generalization, we should still list this specialization in the modal asking whether to inherit the change to its value.
          • So, it is likely that we end up with specializations in which the values of some properties are inherited, but the values differ from what is assigned to the corresponding properties in the generalizations.
        • A submit button to click after the user selected all the specializations or descendants in which the change in the value of the corresponding property should be inherited.
  • The value of the inheritance type of each property of an object should be inherited to the corresponding properties in its specializations, so that if the values of these properties get overridden, the inherited inheritance types would be used for these properties unless altered by the user.
  • If the inheritance type of a property in an object changes, it's as if the property is overridden and its specializations would not inherit that property from their grand-generalization anymore. Instead, they would inherit that property from this object because it has overridden the property.
  • When an object loses one of its generalizations:
  • Any properties that were inherited from the removed generalization will also be removed from the object, unless:
    • The property has been explicitly overridden within the object and has not inherited its value from the former generalization.
    • The property also exists in another generalization of the object. In this case, after losing the former generalization, the object would inherit the value of this property from its other generalization.
  • As a result, an object’s only generalization cannot be removed.
  • To replace an existing generalization, a new generalization must be added to the object before the former one is removed. This ensures the object maintains the required minimum of one generalization.
  • When an object (together with all its specializations) is moved from one generalization to another:
  • All differences between the old generalization and the new one are treated as changes, and the previous rules are applied to these changes:
    • If there are properties that exist in the new generalization but did not exist in the old one, the specialization would inherit these new fields and values.
    • If there are properties that exist in both the new and the old generalizations, the specialization should get their values from the new generalization.
    • If there are properties that exist in the old generalization, but not the new one, the specialization would lose those properties unless one of those properties are overridden in the specialization and do not inherit their values from the old generalization.
    • If there are new properties in the specialization that do not exist in either the old or new generalization, we should keep them as is.
    • If there are new properties in the specialization that do not exist in the old generalization, but exist in the new generalization, we should give the user the choice to use either the value previously assigned to property in the specialization or the value newly inherited from the new generalization.
    • These would perpetuate to all the grand specializations and descendants.
  • When object B is a specialization of object A (A → B), and you want to insert a new object C between A and B (A → C → B):
  • First, add C as a new specialization of A
  • Then, move B to be a specialization of C.
  • Multiple inheritance. All objects have a primary generalization as described above. However, it is also possible for objects to have one or more additional generalizations.
  • Each property of the object has a “generalization type.”
  • The generalization type of a property determines which generalization the value of this property is inherited from.
  • The default value of “generalization type” is the primary generalization (i.e., the one under which this object was originally created or to which it was explicitly moved).
  • But the editor of this object can select any of the additional generalizations for this property, if desired.
  • The value of the generalization type of each property of an object should NOT be inherited to the corresponding properties in its specializations.
  • When the specializations of an object are grouped into “Categories”:
  • Categories are used to group specializations that vary on a single dimension.
    • For example, “Decide” could have specialization categories such as:
      • {Decide by whom?} – for specializations involving different actors making the decision
      • {Decide how?} – for specializations involving different activities to make the decision
      • {Decide what?} – for specializations involving different things being decided
  • IGNORE THIS PLEASE: Virtual specializations (Automated Proposals). Objects inherit as virtual specializations all the specializations in categories that are different from the categories in their own ancestral chain
    • For example, suppose we have the following “family tree” of specializations:
      • Decide
        • {Decide what?]
          • Choose among alternatives
          • Choose a quantity
        • {Decide by whom?}
          • Decide by human
          • Decide by computer
        • {Decide how?}
          • Decide by hierarchy
          • Decide by democracy
    • Then the activity “Choose among alternatives” would automatically inherit, as virtual specializations, the specializations in {Decide by whom?} and {Decide how?}
      • That is “Choose among alternatives” would automatically inherit the following virtual specializations (with the virtual specializations shown in italics):
        • Choose among alternatives
          • {Choose among alternatives by whom?}
            • Choose among alternatives by human
            • Choose among alternatives by computer
          • {Choose among alternatives how?}
            • Choose among alternatives by hierarchy
            • Choose among alternatives by democracy
      • Notes:
        • Note that “Choose among alternatives” doesn’t inherit the category {Decide what?} because that category is already in its own ancestral chain
        • The examples above assume that the system can automatically create new names for categories and specializations by combining linguistic elements from different places (e.g., “Choose among alternatives by human” includes the phrase “Choose among alternatives” from its direct parent and “by human” from its “uncle” “Decide by human.”
    • These virtual specializations would have, as additional generalizations, the direct generalizations from which they are inherited. For example, "Choose among alternatives by human" would get the two generalizations "Choose among alternatives" and "Decide by human".
    • These virtual specializations (automated proposals) should be automatically created “on the fly” by the system and shown to users to suggest new possible objects. But they should not be permanently stored unless an editor reviews them and accepts them as “regular” rather than “virtual” (proposal) specializations.
    • When an editor accepts a virtual specialization as regular (by just clicking a button, we don't need any voting here), they may often also make changes such as revising the name or specifying which properties are inherited from the additional generalizations.
      • For example, “Choose among alternatives by human” could inherit the following:
        • From its generalization (“Choose among alternatives”): A representation of the decision being made as a selection from an enumerated set of choices
        • From its additional parent (“Decide by human”): A representation of the human making the choice