Ontology Inheritance

This page details the implementation of inheritance in DeepLynx for ontologies. Inheritance is supported for classes/metatypes (e.g. class "B" is a child of class "A"), and a child class inherits all keys/properties and relationship pairs from its parent. Additionally, inheritance is captured and implemented when importing an OWL file to create or update an ontology. More details are provided below.

Inheritance of Keys (properties)

• When a new metatype is created, the bulkSave and save methods in the MetatypeRepository look for the “parent_id” field on each metatype. If this field is supplied (a property on the Metatype types in both DL and the GUI), a mapper function is run to add the child (self) and parent metatype ID pairs to the metatypes_inheritance table.
• The metatypes_full_keys view contains a flattened structure of keys, where inherited keys are found individually on each child class that inherits them. This view is regularly updated through a refresh statement on the metatype mapper. This refresh statement is used by the “metatype_keys_refresh” job, which allows DL to regulary refresh the cache of metatype keys (default interval is 1 minute).
• The get_metatype_keys function is referenced in the metatype key mapper list() function, and the metatype key mapper listKeysStatement() has essentially the same structure as that function except that it can retrieve the keys for a list of metatypes. This function is recursive and grabs the keys for a given metatype or metatypes using metatypes_view.
• The metatypes_view view contains the latest version of each metatype and also contains the metatype’s parent_id if they have one. This id is taken from the metatypes_inheritance lookup table. This view is the primary source from which metatype data is queried, therefore having the child and parent link established in the metatypes_inheritance table and therefore this view is the primary way in which this relationship is established.
• The check_metatype_inheritance trigger (and referenced function) ensure that inheritance remains logical (e.g. parent cannot become a child of one of its children) and runs before insert or update to metatypes_inheritance.
• When a new ontology version is created (e.g. changelist), the clone_ontology database function now ensures that the parent and child metatype IDs are properly inserted to metatypes_inheritance using the newly created metatypes for the new ontology version.

Inheritance of Relationships

• Relationship inheritance is done for relationship pairs, not relationships (or “relationship types”). This is how relationship inheritance is supported by web ontology language (OWL). For example, if I define the relationship “decomposedBy”, I cannot create a child relationship for it like I can for classes. However, if I have the classes “A”, “B”, and “C” and C is a child of B and a relationship pair exists on B: “B decomposedBy A”, then C should inherit that relationship such that C has the relationship pair “C decomposedBy A”. Note that inheritance should apply only for the origin class, in this case C. Children classes of A will not inherit this relationship pair, and relationship pairs should be viewed from and associated with the origin class. When inspecting the class A, the relationship pairs where it is a target (the two previous examples) are not directly associated with it as they are the B and C classes.
• The inclusion of keys (data properties) on relationships is not directly supported by OWL. DeepLynx however does allow for users to specify keys on relationships (types), and these keys apply to all usages of that relationship by relationship pairs. Therefore, relationship pairs should not allow for the editing of keys, but rather the keys available to a relationship pair (and its instantiation as an edge) may be viewed by referring to the relationship that the relationship pair uses.
• Relationship pairs work nearly identical to keys. A view is created with a refresh job for expanding the metatype_relationship_pairs table into the metatype_full_relationship_pairs view. The view contains the extrapolated relationship pairs that occur through inheritance. Of note is the metatype_id column of the view which indicates who the owner of the relationship pair is (or where the pair is inherited from).
• Names of relationship pairs are set automatically by DeepLynx. Upon insert to the metatype_relationship_pairs table, a name is autogenerated from the origin metatype, relationship name, and destination metatype. Names are also automatically generated upon creation or refresh of the relationship pairs view.
• Relationship pairs can be found directly associated with metatypes as a direct property of the metatype class, just like keys. In addition, the relationship pair view (or equivalent query) is used for most read operations. Refresh of the view and cache invalidation (for relationship pairs as well as metatypes) is regularly applied for create, update, and delete operations.
• When a relationship pair is going to be inserted, the check_relationship_pair_inheritance trigger (function) ensures that the proposed relationship pair is not already one that is inherited by the metatype. This check will return errors whether the relationship pair is created via the API, ontology importer, or some other way. The ontology importer will log the errors and return them, but will otherwise continue and return success.

The Ontology Importer

• The ontology importer now imports the owl file more directly, and no longer is required to create an artificial inheritance relationship and apply this to all inheritance relationships. Instead, after metatypes have been created, the parent and child id pairs are acquired and bulk inserted into the inheritances_metatypes table. Note that the check_metatype_inheritance trigger makes this a very long process and is disabled before the bulk insert and afterwards reenabled.
• Additionally, keys and relationship pairs do not need to be flattened out across classes/metatypes. When looking for updates, the keys or relationship pairs owned by the given class or metatype should be examined, not any inherited keys.
• As keys and relationship pairs are bulk inserted, it’s important that any triggers or refresh of views are avoided. The ontology importer disables these entities or uses separate create statements to ensure performance.