RelationshipDescriptors describe uni-directional relationships between two Holon Types. Each descriptor defines a relationship in one direction only. Reciprocal relationships can be denoted via references between their two descriptors. There are some consistency management concerns that arise with this design, but the conceptual simplicity and intuitive nature of uni-directional relationships seems worth it.
It is hoped that by adding support for RelationshipDescriptors to the prototype we can eliminate the need for CompositePropertyDescriptors. RelationshipDescriptors essentially serve the same role, but in a much more general purpose way.
This story is focused on adding RelationshipDescriptor to the set of supported EntryTypes within Metaspaces. This involves
RelationshipDescriptor Struct Definition
pub enum DeletionSemantic {
Allow, // deleting from_holon has no impact on the to_holon(s)
Block, // prevent deletion of from_holon if any to_holons are related
Propagate, // if from_holon is deleted, then also delete any related to_holons
}
pub enum RelationshipSemantic {
Composite,
Aggregate,
Association,
}
For the moment, I've decided to include the above enum as part of the RelationshipDescriptor, but with mixed feelings. Strictly speaking, I think it is unnecessary as the precise semantics implied by these options is already covered by the combination of:
- Composite,
from_cardinality = 1, to_cardinality >0, deletion_semantic = Propagate
- Aggregation,
from_cardinality = 1, to_cardinality >=0, deletion_semantic = Propagate | Block
- Association,
from_cardinality = 0, to_cardinality >=0, deletion_semantic = Allow
pub enum DataType {
DirectReference, // only applies to relationships whose to_cardinality = 0 or 1
Set, // un-ordered, duplicates allowed
Map, // a.k.a., Dictionary, <Key,Value> pairs.
List, // a.k.a., a Vector or array
}
pub struct RelationshipDescriptor {
header: TypeHeader, // the type_name property within the header serves as the role_name for this direction of the relationship
from_holon_type: HolonReference,
to_holon_type: HolonReference,
from_cardinality: Integer,
to_cardinality: Integer,
relationship_semantic: RelationshipSemantic,
deletion_semantic: DeletionSemantic,
affinity: Integer, // how strong is the affinity of the from_holon to the to_holon (affects embedding)
to_data_type:
}
NOTE: we probably want to update the definition of HolonReference to include a HolonType property. This will allow (run-time) type-checking. For example, requests to add a Holon as the target for a HolonReference can check that the type of the Holon matches the intended target type specified in the HolonReference.
RelationshipDescriptors describe uni-directional relationships between two Holon Types. Each descriptor defines a relationship in one direction only. Reciprocal relationships can be denoted via references between their two descriptors. There are some consistency management concerns that arise with this design, but the conceptual simplicity and intuitive nature of uni-directional relationships seems worth it.
It is hoped that by adding support for
RelationshipDescriptorsto the prototype we can eliminate the need forCompositePropertyDescriptors.RelationshipDescriptorsessentially serve the same role, but in a much more general purpose way.This story is focused on adding
RelationshipDescriptorto the set of supportedEntryTypeswithinMetaspaces. This involvesRelationshipDescriptoras a newEntryTypewithin thedescriptors_integrityanddescriptorszomesRelationshipDescriptorin shared_typesRelationshipDescriptorsRelationshipDescriptor Struct Definition
For the moment, I've decided to include the above enum as part of the RelationshipDescriptor, but with mixed feelings. Strictly speaking, I think it is unnecessary as the precise semantics implied by these options is already covered by the combination of:
from_cardinality= 1,to_cardinality>0,deletion_semantic= Propagatefrom_cardinality= 1,to_cardinality>=0,deletion_semantic= Propagate | Blockfrom_cardinality= 0,to_cardinality>=0,deletion_semantic= AllowNOTE: we probably want to update the definition of HolonReference to include a HolonType property. This will allow (run-time) type-checking. For example, requests to add a Holon as the target for a HolonReference can check that the type of the Holon matches the intended target type specified in the HolonReference.