Each Entity in a Vocabulary can be mapped to a Java Class or Java Interface. Java Classes may have one ancestor. Java Interfaces may have multiple ancestors. A Java Class may implement one or more Interfaces. Say a Java Class A inherits from Java Class B and implements Java Interfaces C & G. Say Java Interface C has as its ancestors' Java Interfaces D & F. Say these Classes and Interfaces are mapped to Entities EA, EB, EC, ED, EF & EG in the Vocabulary. The relationships amongst the Java Classes shall be reflected in the Vocabulary using multiple inheritance. Entity EA shall have as its ancestors Entities EB, EC & EG. Entity EC shall have as its ancestors entities ED & EF as shown below:

Figure 1. How the Vocabulary Incorporates Inheritance from a Java Object Model

When a collection of Java objects are passed into the engine through the JOM API, the Java translator determines how to map them to the internal Entities using the following algorithm:

For each E:

  • If there is a JO whose JC or JI is mapped to E then
    • Instantiate a CDO for E and link to JO
    • Put CDO in E bucket
  • Traverse E's inheritance hierarchy one level up
    • For each AE discovered in current level:
      • Put CDO in AE bucket
  • If E has another level of inheritance hierarchy, repeat last step

Naming conventions used in the algorithm above:

  • JO = Java Object in input collection
  • JC = Java Class for the JO and any of its direct or indirect ancestors
  • JI = Java Interfaces implemented directly or indirectly by JO
  • E = A Vocabulary Entity with no descendants found in DS context
  • AE = An Ancestor Entity (one with descendants) found in DS context
  • CDO = In memory Java Data Object created by Corticon for use in rule execution

This design effectively attempts to instantiate the minimum number of CDOs possible and morphs them into playing multiple Entity roles. Ideally, no duplicate copies of input data exists in the engine's working memory thus avoid data synchronization issues.