Yeah totally! I have done a couple different LTREE label columns on the same table before but that was for separating named entity recognition from other things

Yeah totally! I have done a couple different LTREE label columns on the same table before but that was for separating named entity recognition from other things, so still just different kinds of class membership (e.g. people, places, things). It is possible to join these across tables, and therefore treat the matching nodes as having the same meaning for classification. However, it doesn't make sense to concatenate trees with different roots because it would just look like regular nesting. Even if I make it clear at the column level like resource_table.node_label::ltree and predicate_table.edge_label::ltree, there would still be no obvious way to parse where in the forest we traverse over nodes and edges, since they all look and function the same. I feel like this calls for a well thought-out naming convention using the only thing LTREE allows, alphanumeric and underscore characters. Something like root0.__node__name0.__edge__name0.__node__name1. This "merged" forest could be a "projection" within queries/views. Thanks again, happy topologizing :)