Ask Lemmy

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

I’m not sure how much legacy code is written for contact apps in smartphones. But given the amount of tweaks and changes apple and Google make in each of their releases I would expect they wouldn’t have any problem integrating this feature.

Also you mentioned legacy code, but why T9 dialing isn’t a thing anymore coz that would be available if they were simply extending from legacy codebase.

Alright I’ll provide a use case scenario. I wanted to this functionality when I was in uni where a lot of my contacts had more than one role to play and I had trouble remembering all the roles my contact would have. Let’s say one of my contact was my coursemate but also worked in organizing committee of an event. I knew other members of the organizing comittee as well. So in the event that I needed to share an information with the entire organizing committee, I needed to remember committee list members instead of software helping me. And what about another contact who also part of the event but was on a different team like Public Relations. You could say just another tag would suffice no need for nested ones. But this kind of events happens multiple times and I would have to create multiple tags for multiple events (instead of nesting) and it becomes cumbersome managing the list.