Some specification, party and place relationships are so dense that we don't want them in the graph as edges it is just clutter. For instance a consumer party RSP would 'own' an enormous number of instances, same with a provider party, it would own them all/
A neo4j 'rule of thumb' is that a node is dense when it has ~50 edges.
The specification relationship could be easily handle with a change to AshNeo4j such that the relationship/relate pair indicates that the relationship is indirect rather than a particular edge label and direction. This means it can only be traversed in a single direction, either belongs_to or has_one or has_many. However for parties and places we may want a mix of indirect and direct, so flagging to the datalayer is impossible since it works on attribute typing not runtime data typing, so the entire relationship collection must be indirect or not. A potential here is to have two collections, one direct and one indirect on the BasePlace or Party, and use them accordingly. The json would just list in order direct then indirect in the one collection. Sorting would be within each one. Nice but requires datalayer support.
Another much poorer approach is to attempt to handle this in diffo, leaving the database backed collection for involvedPlaces/Parties and adding on new attributes to handle keys/collection of keys for indirection, subsequent loads and the like. These indirect parties would be more limited in terms of behaviour as wouldn't actually be 1st class ash for expressions, calculations and the like. This makes it very hard for other behaviours to use these results which basically renders them cosmetic.
Some specification, party and place relationships are so dense that we don't want them in the graph as edges it is just clutter. For instance a consumer party RSP would 'own' an enormous number of instances, same with a provider party, it would own them all/
A neo4j 'rule of thumb' is that a node is dense when it has ~50 edges.
The specification relationship could be easily handle with a change to AshNeo4j such that the relationship/relate pair indicates that the relationship is indirect rather than a particular edge label and direction. This means it can only be traversed in a single direction, either belongs_to or has_one or has_many. However for parties and places we may want a mix of indirect and direct, so flagging to the datalayer is impossible since it works on attribute typing not runtime data typing, so the entire relationship collection must be indirect or not. A potential here is to have two collections, one direct and one indirect on the BasePlace or Party, and use them accordingly. The json would just list in order direct then indirect in the one collection. Sorting would be within each one. Nice but requires datalayer support.
Another much poorer approach is to attempt to handle this in diffo, leaving the database backed collection for involvedPlaces/Parties and adding on new attributes to handle keys/collection of keys for indirection, subsequent loads and the like. These indirect parties would be more limited in terms of behaviour as wouldn't actually be 1st class ash for expressions, calculations and the like. This makes it very hard for other behaviours to use these results which basically renders them cosmetic.