5 ms·
That's an awesome application that I was totally unaware of! To encode more edge types, you would have to be able to devise a way to 'hash' them into a unique e
by Topolomancer 6y ago
That's an awesome application that I was totally unaware of! To encode more edge types, you would have to be able to devise a way to 'hash' them into a unique edge label. There's a variant of WL that collects edge labels instead of node labels; the rest of the algorithm remains unchanged.
Is this roughly what you were looking for?
- chartpath 6y agoYeah 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 :)