Thanks for a post that raises some interesting and important questions.
I’ll start first, though, with your item 5. Every now and then I see a comment that hierarchical structure in organizing things, whether documents or boxes of screws on a hardware store shelf, is ‘bad’, perhaps with a note that this isn’t the way the universe “is”.
You mentioned the MESE Principle, which basically states that, when organizing things into groups the groups should be divided into subgroups that “comprehensively represent that group (no gaps) without overlapping. This is desirable for the purpose of analysis, because it avoids both the problem of double counting and the risk of overlooking information.” (Quote from WikiPedia.)
The MESE Principle has been adapted into management analysis from another discipline, mathematical logic (set theory), where it completely makes sense. It has become something of a fad in management theory, in my opinion, and when applied in that discipline can easily lead to results that make little or no sense. I happen to be critical of another management “principle” — the “Towers” concept in analyzing organizational structure in terms of functions — and of the “Precautionary Principle” in environmental management of technologies.
DEVONthink allows the user to cluster items into groups, or not. It’s optional. DEVONthink allows the user to create subgroups within groups, subgroups within subgroups, and so on; its optional. The user may create a completely flat (non-hierarchical) database, mix flat and and grouped items in a database or use any degree of hierarchical structure desired. It’s optional. If desired, replicants allow filing an item in multiple groups.
I’m not al all bound by the MESE Principle in classifying information in my databases, and if DEVONthink were to require that, I would consider that a silly waste of time and effort with little if any practical return. If, however, I were cataloging metal screws in a database, I would find it useful to group (or tag) items by screw size, and in subgroups by composition — brass, stainless steel, etc.
The reality is that in interacting with the universe we often find it useful to classify some things as related (groups) and to view some of those groups hierarchically (animals > mammals > canines > dogs). For some purposes we may be satisfied with rough “clusters” of similar items, and for other purposes we may need more detailed classification of similar items.
I work with topically designed DT Pro Office databases. My decision as to which database will contain a new item is a form of classification or grouping. My main database contains at any time thousands of unclassified items, and a mixture of ‘flat’ groups and groups that contain subgroups. Often, when working on a project, I will add more detailed structure to some of my documents, and perhaps remove that added structure after completion of the project. For my own convenience in thinking about the content, most items end up in groups.
Because searches and See Also do not look at my organization of documents within a database, and these are among my most useful tools in finding and evaluating information content, I spend only so much time and effort in grouping and subgrouping content as I find useful for other reasons. Yes, for some topics I’ll spend time creating a hierarchical structure, as that may help me understand the relationships of information — even though a search or See Also operation would find those items anyway. Once I’ve created a group and populated it, Classify becomes useful to file new content into that group.
I view tagging similarly. I think all tagging systems are logically unsatisfying and operationally inconsistent and inefficient, so I never bother tagging content a priori (as it is added to a database). In the course of working on a project I will sometimes add tags to project-related items, but often remove those tags when the project is completed (I sosmetimes find that previously assigned tags may be an impediment in trying to take a different perspective for a new project).