In serialization, `parent` is inverse of either `children` or `annotations`

[enikao]

Considerations

• Repo API: Do we need model partitions? #29 establishes that every node is part of exactly one partition. We can reach the partition by moving up in the tree until we find the root.
• See also Annotation instances are stored under nodes #164, Are annotations part of "descendants" axis? #185

Alternative A: Have fields parent and annotatedNode in serialization

If a node is a concept instance, it has a parent field pointing to the id of its parent.
If a node is an annotation instance, it has a annotatedNode field pointing to the id of the annotated node.

Pro:

• Can distinguish concept instances and annotation instances on serialization level
• Perfect symmetry of parent / children and annotatedNode / annotations

Con:

• We don't gain much from distinguishing concept instances vs. annotation instances on serialization level. As soon as we know the metamodel (common case), we can separate them.
• To reach the partition of a node, we might need to traverse "upwards" through both of them.
• An annotation can contain other non-annotation concepts. Then the "upwards" traversal changes several times between both of the fields.

Alternative B: Have only one field parent

parent MUST be the inverse of either children or annotations.

Pro:

• Uniform node serialization format
• Traversing the tree is generic

Con:

• Skewed symmetry
• Not in line with common semantics: "parent" of a node in a tree is well understood; "annotations" are semantically not always members of the tree (see Are annotations part of "descendants" axis? #185). However, on serialization level, annotations are ordinary tree members.

On 2023-09-29, we decided for alternative B: only one field parent.

[joswarmer]

Should close this