-
Notifications
You must be signed in to change notification settings - Fork 0
MAP Relationship Descriptors
RelationshipDescriptors describe uni-directional relationships between a source_holon_type
and a target_holon_type
. In general, relationships can be navigated in either direction (from-source-to-target or from-target-to-source). Each navigable direction requires its own RelationshipDescriptor. An inverse_of
reference in both descriptors allows them to reference each other.
An alternative design based on bi-directional RelationshipDescriptors was considered and discarded as described in Design Spike: Descriptor Re-Factor (Issue #37).
Cardinality constraints are defined from the perspective of a single source-holon.
-
min_target_cardinality
specifies a constraint on the minimum number of instances of the "target-holon" that are allowed for a single source-holon. -
max_target_cardinality
specifies a constraint on the maximum number of instances of the "target-holon" that are allowed for a single source-holon.
A role's deletion_semantic
specifies how to handle requests to delete (more precisely, mark as deleted) a source-holon.
pub enum DeletionSemantic {
Allow, // deleting source_holon has no impact on the target_holon(s)
Block, // prevent deletion of source_holon if any target_holons are related
Propagate, // if source_holon is deleted, then also delete any related target_holons
}
Those familiar with UML may be accustomed to using the terms, Composition, Aggregation, or Association to describe relationship semantics. To avoid ambiguity about the semantics implied by these options, the semantics are spelled out more precisely in terms of cardinalities and deletion_semantic:
- Composite,
min_target_cardinality
>0,deletion_semantic
= Propagate - Aggregation,
min_target_cardinality
>=0,deletion_semantic
= Propagate | Block - Association,
min_target_cardinality
>=0,deletion_semantic
= Allow
Beyond the relationship semantics which are dictated by the settings of the properties described above, an affinity
value can be assigned for the relationship. This value is intended to expressed a relative strength of the relationship that can be used to dynamically drive various run-time behaviors. For example, whether to retrieve (and cache) related objects when source-holons are retrieved and whether to embed target_holons within source-holon NodeVisualizers. It's value an be adjusted over time based on observed behaviors (e.g., how often do users navigate to the target-holon when they have retrieved the source-holon. This supports the adaptive nature of the MAP.
In the persistence tier (i.e., integrity zome), all holon relationships are represented using SmartLinks (see MAP Holons Integrity Zome). In the behavioral tier (i.e., coordinator zome), relationship instances are materialized as SmartReferences within SmartCollections as described in .