Hi! The relations UI currently only visualises one level of spans – you're already able to connect every token to every other token or span, so including overlapping and nested spans in the same interface can easily get very messy and you'd lose a lot of the advantage of visualising relationships as arrows like this.
If your data includes this level of complexity, one option could be to focus on connecting one concept a a time, for example, relationships of Task spans to each other, or relationships between Metric and Material. This also lets you narrow the scope and only allow annotations that are actually valid/useful: Is it possible for tasks to by hyponyms of materials? If not, you probably don't want to even include this option. If tasks can only be hyponyms of tasks, you also know that this is not an option to consider for examples that only contain a single Task. All of these are decisions that can make the annotation process a lot fasster and more efficient.
In this specific case, another thing to think about is whether the relations view is actually the right conceptual model for this. For example, if your goal is to detect hyponyms based on pre-annotated phrases (that you already know), directional relationships aren't necessarily the best way to express this idea. What you're annotating here is "one or more instances of the existing spans relate to the same concept". So you could frame the same thing as a binary/multiple choice question about task A and B.