hdelva
commented
3 years ago There is a special case to this reasoning over constraints; if we know a node is a root node, e.g. because it was the object of a tree:view, there can be no constraints on that node. So if a lead node points back to the root node, the tree node's constraints do not carry over to the root node. This adds a small amount of complexity, but we should mention it in the specification somewhere.
pietercolpaert
The spec currently says that these MUST be ignored, while we interpret these as 'more of the same' in https://github.com/treecg/treemunica. If you reached the current node, you probably know which value constraints were on this node anyway -- so those can be applied to the object of a hydra:next as well.
Theoretically, I think every subsequent relation a client follows adds more constraints. So if you have a multi-dimensional fragmentation, you can have a couple of layers of geospatial relations, and then some temporal relations. Once you get to the temporal ones, you just add temporal constraints while the geospatial ones remain as they were. A hydra:next in that case just doesn't add anything.