I think the question boils down to something like “For this data set, is there information captured by a tree representation that’s not captured by a list of categories?” Trees, or graphs in general, can capture path-based relationships. Categories are based of course on set theory.
I think both have their place, and like anything within mathematics or programming it comes down to which metaphor more naturally and easily expresses what you’re trying to do. I find trees and graphs easy to think about and represent visually, but it all depends on the problem space and the approach.
Note: This is assuming the kind of “tree” we implement permits multiple inheritance if needed.
Hierarchical tags is also possible. In fact Gmail has it, so you can for example create a work tag and then subtags for each company you worked at, and do similar things with hobby tags, and apply multiple tags
I have a bachelor’s degree in maths so I get where you’re coming from. I’m asking, what specific functionality would nested tags provide that unnested tags do not. What is the return on investment for implementing this feature? Describe how this might improve your user experience with collections of objects? What actions in a user interface could you perform or would be made easier with nested tags that are not possible or are more cumbersome using only unnested tags?
Consider a data set that is naturally hierarchical and path related relationships are the central purpose of the data. Let’s say a genealogical database like some services run.
I can see a way of doing it with tags but mostly what I’m picturing has to add additional metadata to the tags that essentially represents the graph and has to add extra logic for resolving all of it.
If stored as nodes and edges you also have the capacity to add additional features to the relationships easily and naturally. That allows you do induce various subnetworks by edge flavor pretty easily. Network metrics such as centrality and clustering also fall out naturally.
Again, you can do it in tags because you can represent the network data as a table, which would in turn be translatable into possibly some long and complex tags. Or maybe there’s a more natural way, but for me the graph is easier to think about and write interesting algorithms for.
Mostly when you have multiple events where you could have made few tags and sub tags to capture the data instead now you have make multiple tags with parent and children as a tag
I think the question boils down to something like “For this data set, is there information captured by a tree representation that’s not captured by a list of categories?” Trees, or graphs in general, can capture path-based relationships. Categories are based of course on set theory.
I think both have their place, and like anything within mathematics or programming it comes down to which metaphor more naturally and easily expresses what you’re trying to do. I find trees and graphs easy to think about and represent visually, but it all depends on the problem space and the approach.
Note: This is assuming the kind of “tree” we implement permits multiple inheritance if needed.
Hierarchical tags is also possible. In fact Gmail has it, so you can for example create a work tag and then subtags for each company you worked at, and do similar things with hobby tags, and apply multiple tags
I have a bachelor’s degree in maths so I get where you’re coming from. I’m asking, what specific functionality would nested tags provide that unnested tags do not. What is the return on investment for implementing this feature? Describe how this might improve your user experience with collections of objects? What actions in a user interface could you perform or would be made easier with nested tags that are not possible or are more cumbersome using only unnested tags?
Consider a data set that is naturally hierarchical and path related relationships are the central purpose of the data. Let’s say a genealogical database like some services run.
I can see a way of doing it with tags but mostly what I’m picturing has to add additional metadata to the tags that essentially represents the graph and has to add extra logic for resolving all of it.
If stored as nodes and edges you also have the capacity to add additional features to the relationships easily and naturally. That allows you do induce various subnetworks by edge flavor pretty easily. Network metrics such as centrality and clustering also fall out naturally.
Again, you can do it in tags because you can represent the network data as a table, which would in turn be translatable into possibly some long and complex tags. Or maybe there’s a more natural way, but for me the graph is easier to think about and write interesting algorithms for.
Check this use case I mentioned here: https://lemmy.world/comment/6114731
Mostly when you have multiple events where you could have made few tags and sub tags to capture the data instead now you have make multiple tags with parent and children as a tag