I've made an observation about user interface patterns involving complex relationships. Trees are much more grokkable to the average user than SetTheory, but not as powerful as SetTheory (see LimitsOfHierarchies). 

The best way to '''leverage the benefits of both''' seems to be to have a "standard tree view", but also allow secondary "set" views. Every "object" in the system would fit in one and only one place on the standard tree view to provide a standard reference point. However, cross-references, such as key-words and aliases, are also permitted and available so that one can use the power of sets to get more complex or more dynamic views of content.

Examples:

* Menus: have the standard hierarchical menus, but also GooglifyDeepMenus.

* File systems: have the standard tree (path), but also shortcuts (cross-links or bookmarks) and aliases (such as Windows mapped drive letters, but better). And perhaps a Google-like search engine.

* WWW: Domains and URL's are the "tree view", but search engines and dynamic content query techniques (per site) give a more set-oriented approach.

* Relational Databases: Typically they are not presented hierarchically[1], but could be with "paths" such as databaseX.tableX.data.rowX.fieldX. "rowX" would be the primary key(s), although this can get messy with compound keys. The "data" element is used because schema info can also be delivered with paths such as databaseX.tableX.indexes.indexNameX. There are alternative ways to arrange these.

Over time, aliases are generally preferred, at least at the lower levels of the tree, because the actual tree can get shuffled around during system migrations etc. such that organizations will often end up preferring aliases to avoid problems with "tree migrations".

--top

--------
Footnotes

[1] Microsoft Sql Server Management Studio generally presents a tree view of the database, but it's not organized very well in my opinion.
----
What you are getting to is the complexity of data, given an incomplete view of the world.  People have their own personal ontogenies, but most often, others have different ideas, and therefore different roots for the "tree".  Given that, if you were to contain it within a UnifiedDataModel, you would have to allow multiple views into the constellations of data within an n-dimensional space, where n is arbitrarily large. --MarkJanssen

''"Custom" trees should probably be "local" to the user or specific group, in my experience. Having multiple "global" trees can be a pain to maintain and a central maintainer often doesn't have the branch-level domain knowledge to do it right. Categories (sets) can help make some updates propagate semi-automatically to custom trees, but ultimately a local tree-maintainer will need to keep an eye on it.''