Type inheritance

Type inheritance is not part of the classical PRM formalism, thus we present here insights on how it works and how aGrUM manages such concepts.

Creating subtypes is not a difficult task and the constructor's gum::prm::Type::Type(const Type&, const std::vector<Idx>&, const DiscreteVariable&) documentation should give you enough information.

Things become more tricky when adding an Attribute (or a ClassElement representing a random variable) which Type is a subtype. In this case it is necessary to add what we call "casting descendants", i.e. deterministic nodes which can be used to cast the random variable in the desired super type.

Suppose we have 3 Type t_1, t_2 and t_3 with t_2 being a descendant of t_1 and t_3 of t_2. If we add an Attribute named foo of Type t_3 to a Class C, then 3 Attribute are added to C, each named foo, with types t_1, t_2 and t_3. However only the Attribute of Type t_3 is associated to the name foo in C's name map. To retrieve the other Attribute you must use safe type names.

The syntax of a safe type name is "\<type\>name" they guaranty the Type of the Attribute you asked for. In our example even if there is 3 Attribute named foo, only the one with Type t_3 can be retrieved using foo. The others are only accessible using safe type names: <t_1>foo and <t_2>foo. If you really want to be sure what you are doing, you can always use safe type names for Attributes since <t_3>foo is also added to C's name map.

The last point is how we add casting descendants in a Class. As we said casting descendants are deterministic nodes, they simple cast a random variable of one Type to another. Each Attribute which Type is a subtype has a child of it's Type super type added. We do that to any Attribute which type is a subtype (this include Attributes added as casting descendants). In our example adding foo will also add the arcs: <t_3>foo -> <t_2>foo and <t_2>foo -> <t_1>foo.

ReferenceSlots and SlotChains

ReferenceSlot are the equivalent of reference in the PRM formalism. They represent a relation between two Class which can be instantiated as a one-to-one or a one-to-many relation. SlotChains are the equivalent of slot chain (or reference chain) in the PRM formalism. Both SlotChains and ReferenceSlot are tightly related: a SlotChain is a sequence of ReferenceSlot ending by an Attribute or Aggregate.

Reference in a PRM follows the "pull" paradigm: a ClassElement in a Class requiring information defined in a different Class uses SlotChains to reference such ClassElement. This implies that parent-to-child dependencies are not known from the parent since it is its children whom pull the information toward them. This can be problematic while inferring in a PRM. To deal with this lack of information we use the notion of inverse reference and introduce a new one: inverse slotchain.

Inverse reference are implemented as ReferenceSlot representing the inverse relation defined by a ReferenceSlot. When adding a ReferenceSlot named ref with slot type B to Class A, the Class A automatically adds a ReferenceSlot named <A>ref with slot type A to B. We call ref the declared ReferenceSlot and <A>ref the inverse ReferenceSlot. Such inverse ReferenceSlot are created each time a declared ReferenceSlot is added, even if it is inherited or implemented. Such inverse ReferenceSlot can then be used to know which Instance are related with one another.

If an inverse ReferenceSlot is added to a Class or Interface then all sub-Class, sub-Interface and implementation receive the same inverse ReferenceSlot. However the referenced inverse of a declared ReferenceSlot will always be the inverse ReferenceSlot of the root Class in the inheritance tree.

Inverse SlotChain represent the reverse path defined by a SlotChain: if a SlotChain rho = ref_1.ref_2.foo then its inverse is inv_rho = <B>ref_2.<A>ref_1.bar where bar is the ClassElement depending on foo, A the domain of ref_1 and B the domain of ref_2. Inverse SlotChain are not added when a declared SlotChain is added but when a child is added to declared SlotChain. Thus there is as many inverse SlotChain of a declared SlotChain as the number of his children.

The name of a SlotChain is its reference chain ended by the ClassElement it points to. Since for each ClassElementContainer ClassElement name are unique, the uniqueness of SlotChain name is guaranteed.

Inverse ReferenceSlot and SlotChain are always multiple and when adding a ReferenceSlot to an Interface no inverse ReferenceSlot are added since implementing Class will take care of it.

Exceptions semantics

Exceptions in PRM have specific significations:

gum::NotFound: raised if an identifier (usually a string or a gum::NodeId) does not match any gum::prm::ClassElement in a given gum::prm::ClassElementContainer or gum::prm::Instance.
gum::TypeError: raised if an gum::prm::PRMObject is not a valid type when using it in some context. For example assigning an gum::prm::Instance to gum::prm::ReferenceSlot where the gum::prm::Instance type is not a subtype of the gum::prm::ReferenceSlot slot type will raise a gum::TypeError exception.
gum::WrongClassElement: raised if a gum::prm::ClassElement is used where it should not be. For example adding an gum::prm::Attribute as a parent of a gum::prm::ReferenceSlot in a gum::prm::Class will raise a gum::WrongClassElement.
gum::OutOfUpperBound: raised if a bound is not respected. For example if more than one gum::prm::Instance is assigned to a gum::prm::ReferenceSlot which is not an array a gum::OutOfUpperBound will be raised.