In the TREE specification, we can define relations between the nodes (a fragment in the context of a fragmented database).
In the current specification, the basic logical operators (=,>,>=,<,<=) are defined but the not equal operator (!=) is missing. It is true that this operator might not be the most useful in the context of fragmentation because in the main specifying the positive is more powerful (you know exactly what is inside the fragment instead of knowing that everything except one thing is inside) and simpler to understand than specifying the negative. But for all the other operators we have a "redundant" (in the perceptive of defining the less amount of operator possible) reverse operator, hence for the sake of completeness and because there might be some use cases where fragmenting based on a negation might be useful (in relation to the domain of the data published) I propose to introduce the not equal Relation subclass in the specification.
We have discussed this during the TREE Community Group meeting of 29th of November 2023:
Use cases the we see are for instance type fragmentations in which you want to point to on the one hand everything of a certain type, and have a “rest”-fragment of everything that is not of that type
This issue has been accepted in order to move on and have a PR opened
Considering the use case being a kind of type-index, we will also need to proof-read the spec text on comparing named nodes
In the TREE specification, we can define relations between the nodes (a fragment in the context of a fragmented database). In the current specification, the basic logical operators (
=,>,>=,<,<=
) are defined but the not equal operator (!=
) is missing. It is true that this operator might not be the most useful in the context of fragmentation because in the main specifying the positive is more powerful (you know exactly what is inside the fragment instead of knowing that everything except one thing is inside) and simpler to understand than specifying the negative. But for all the other operators we have a "redundant" (in the perceptive of defining the less amount of operator possible) reverse operator, hence for the sake of completeness and because there might be some use cases where fragmenting based on a negation might be useful (in relation to the domain of the data published) I propose to introduce the not equal Relation subclass in the specification.