Who are you? I'm next. (Uly App, Devonthink, Export, Variants, Tags...)

Posted by 22111
Jul 3, 2022 at 02:58 PM

Re multiple-tagging (also touches the atomization problem and the usefulness of one, or even more than one, intermediate “tree” pane; this is obviously about information management, not about “writing”):

You know tag clouds, tag lists, tag trees; the latter present the very same, unwanted characteristic of our “outliners” ‘s: the tree is built just in one specific way then (see above for askSam, etc., to overcome this, also see MS Excel’s and other’s “pivot” functions).

Let’s have an example, a compound of press clippings for “Corona” facts & policies in and from several countries (mid-5-digit number of items for this alone), within a compound of “politics” press clippings. (And no, no “politics” here, you’re safe!)

We have multiple countries, more than 10 even when we “consolidate” most countries into continents, so let’s take u for U.S., e for E.U. (not the set of countries, by the organization and its policy), d for Germany (D is their car plate code), f for France, c for China, and r for all the rest (which is obviously greatly oversimplified already) = 6 values for the geographic dimension.

Then, “national policy” for each of the above? Problematic, since they have distinct policies / applied “measures” with regards to (l = little “L”) “lock down”, to (t) “testing”, to (v) “vaccination in general / recommended vaccination”, to (c) “compulsory vaccination”, etc., and you will also have one (p) “press” category for articles by the press of those countries / regions from above, but which do apply to facts outside of those countries (e.g. German press article re French “corona” policy: geographic code f for France, but policy code d for “from Germany”) - or you even make that an independent dimension, with the consequence that you will multiply “all the rest” (I’ll explain this below) with the number of this dimension (again multiple countries and regions…).

Then, the non-policy but disease and vaccination facts or assumptions, problems or alleged problems with the disease, ditto with the several vaccinations (since they come from 3, 4, 5… different manufacturers, so you will have to differentiate, and will have combinations, i.e. articles which treat some kind of vaccination, but for 2 manufacturers) - besides problems and alleged problems, you will have benefits and alleged benefits, and you will have articles that treat benefits as fake news, and articles that treat problems or alleged problems as fake news, correctly so or incorrectly, who knows, i.e. for each “value”, you have to indicate “pro here” or “contra here” or “balanced” (which is a purely technical “value”, since if later on, a “balanced” article may in fact have been “pro” or “contra”, be that having been on purpose or accidentally)...

Then you have “comparison” articles, which e.g. compare just some aspect, or several aspects of national policy in two or more countries, e.g. “lock-downs” in Germany vs. similar in France, so they are region-wise tagged d and f, and measure-wise (i.e. in the “measures/policies” dimension) l for lock-down, but is it a real (i.e. weighted, commented) comparison, or does it just mention those measures in those countries? The former should get its own additional tag, since otherwise, you would find yourself with too many, indistinct “hits”.

Also, here again, you have the problem to distinguish between application of the measures, and their possible outcome / results, etc., not only “at the end of the day”, i.e. long-term, but you also would need a category “police-related repression”, e.g. of demonstrations against specific measures.

Now, if you try to build up a “tree-form” for this, you’ll get lost, since your main, i.e. “parent”, and for practical reasons, geographic list or sub-tree (regions, “flat” for main regions as list, and then with sub-trees in there for other continents e.g.) will hide all the other dimensions, more or less, or, when “extended”, those will hide all those for any other region, i.e. the switch between the (current) main dimension’s “values” (i.e. categories, but “category” is a term that could mislead, by being mixed up with “dimension” or “sub-dimension”) will not be immediate(ly available), and will “kill” your current “tree” display.

Thus it becomes obvious that you should have available multiple, standard (i.e. stored) (in fact, sub-) “tree displays”, for filing situations, for looking-up situations, with 1-key switching between the different values of the “main dimension” (i.e. you would change by just u, d, f between U.S., Germany, and France e.g.), and it’s evident, too, that these “standards sub-trees” should be created on-the-fly, again and again (and not up-front, by yourself and manually, by copy-and-paste), but only as far as they make sense, e.g. (sub-) dimensions which only apply to specific “parent-” dimensions, should not be automatically replicated where obviously not needed.

Technically, you could implement that in the way that there would be (similar to menu systems) a “full-view” - specific for those “sub-trees”, i.e. for the full tag set - upon request (toggle), and a “rational view”, the latter only displaying those sub-dimensions which you will have either designed (in the full-view) as “standard”, i.e. “show anyway” (because you want this, e.g. while expecting possible entries for those, to come), or, of course, which already have entries, and if ever you have to process an item / document / whatever which will need a non-standard and non-yet-displayed “sub”-dimension, you activate the toggle, so that that dimension will become visible, and henceforward, it will stay visible there (even without being “standard”), since then it’ll have “content”.

When I say “parent” and “sub”, that’s not conceptionally correct, since those dimensions are independent from each other, but “parent” and “child”, and “sub-item”, etc. are traditional terminology of outlining “trees”, independently of the fact that for example, level 2 in your tree or “tree” is a geographic dimension, and level 3 is not another, finer-grained geographic one, but “something completely different”.

And now for endless “pivoting”: Any dimension, or even just “value” within a dimension (e.g. “France”, within the geographic one), should be able to become “tree parent” of any other dimension, and so on, for some “indentation”, “situational parenting” levels, e.g. a tree
- geographic (with the sub-dimensions)
—measures (with the sub-dimensions)
—- reception and evaluation (with the sub-dimensions),

or then, the “same” tree, content-wise, but
- measures (as before)
—reception and evaluation
—- geographic

or
- reception and evaluation
—measures
—- geographic

or even
- measures
—geographic
——reception and evaluation
etc.

And then, attribute- or manually sorted “-”, “—” and “—-”, whatever they may currently be, i.e. we present, and store, “views”, and their elements can be automatically sorted, or then sorted by some “standard but manual” way, e.g. you want countries, or measures, always or in most “contexts” be displayed in some way “of your own” (which is stored as “standard” for some “standard” situations, or even in a “special sort”, in some particular “context”: here again, to store this sort should be possible for the user (and is technically no problem with sql), ditto then for the sorting of the “items”, i.e. those items which do not serve as “dimension values”...

And of course, the latter, as well as the former, should also be user-formattable, not only user-sortable, specific to their respective “context” (situation)...

In other words: Current software just presents you one fixed, prefigured tree display, the different dimensions being captured within their respective indentation level: our “outliners” are 2-, not 3-dimensional.

Then, the developers try to overcome this very noticeable technical limitation (of their code, not of the sql concept), but adding “tagging” and / or “stored searches”, and / or they do “tagging” up-front, i.e. no (fixed) tree-building; in all those escape situations (from the unique, fixed tree or simili-tree, i.e. with cloning, but which doesn’t change the fixed character of your “taxonomy” = top-down, one-way only), the “result” is a more or less flat, and automatically ordered list, not an ephemeral (but in case storable), additional tree.

(Please note that in most situations, it would NOT be necessary to build the whole “tree”, again and again, but just those parts of it which are pertinent to the task at hand, and diminished even by all the items and dimension “values” (“sub-categories”, see above) which don’t correspond to the current, stored “standard” you’re after.)

When, for the tags, I say, ” just automatically ordered”, I had commented on that above, and when I say, “almost flat”, it’s because I don’t know if out there, there’s at least one tool that will somewhat indent the list, which would be technically very simple indeed - I just haven’t seen it yet:

1 tag > you get a flat list of all the items which are tagged that way

2 or 3 tags, etc. > you currently (i.e. from most or all??? tools) get a flat list of the items which are tagged with both / all terms

Instead, tools could factor in the order and combination of the tags in your “search”, and then, build an ephemeral hierarchy (but stored tag-search, obviously, upon request) accordingly, e.g.
france(f)/germany(d) - measure1/measure4 - follow-upA
> - title f
—title m1A then all f1A hits
—title m4A then all f4A hits
- title d
—title m1A then all d1A hits
—title m4A then all d4A hits
and so on (further and/or deeper);

obviously, you could enter the 5 tags in my example above in different order and/or different combinations, to obtain the same results, but in a totally different “tree”, and please note that in my example, the three different “AND” “groups” are, for clarity reasons, from different dimensions, whilst the two “OR” “combinations” combine tags from the same dimension each, but that you could mix them up freely, the former as well as the latter.

Please also note that for such a system, there would not be any technical enhancements necessary on the tag-store side, just some additional code in the tag-search routine -

you will want to find, and find quickly, any pertinent item, without excluding wanted hits, but excluding unwanted ones indeed, and with current tagging systems, given enough items, you will either end up with unmanageable list, or then with pertinent items being left out because you will not have “tagged extensively enough”... perhaps because of the comparatively bad “availability” of one or some of the necessary tags…

the usual “tag trees” (do not confound the traditional tag tree with my above example of tree-building for tag search results!) often not presenting (all of) the “necessary” tags in the vicinity of the others, and then, the above-detailed “climbing up and down within a too large visible, and mostly containing not currently pertinent (here: for finding the relevant tags to click) part of the tree” problem shows up again: For people who abhor folder trees, and then continuously fight with very similar problems in tag trees…

And you will remember that one of our honoured contributors, just months ago, gratefully informed us that e.g. (his previously beloved tool) CintaNotes didn’t scale that well after all - in fact, its tag tree system is considered to be one of the best out there in the market… but then, traditional tag trees become practically unmanageable by growing (as just explained), and necessarily and in most use cases, your tag needs will accrue with the growing number of your items, and thus, at the end of the day, why should a tag-only based system then be that robust, input-wise, since in that case, the “natural” (not technical but interactional) limitations of the traditional tag (be it tree, be it cloud) concepts (i.e. administration and especially assignment management) would show.

Whichever limit is attained first, as they sometimes say for cloud services of all sorts… ;-)