Best of Both Worlds, Twice - I think this was the missing element to a perfect system: The "one db, one tree" nexus is dead.

Posted by 22111
Jan 29, 2014 at 02:40 PM

Hello Pierre Paul,

Your web page example is instructive, since it backs MY point I verbalized in DC: Of course, sub-pages have LINKS to the main page (as you write), or to some other “important” pages in the page set (hierarchy most of the time, but not necessarily so), but that’s exactly why I mentioned Warnier and what his system does NOT do, and the need for add-ons to a strict hierarchical system, as the Warnier system is: Recursion yes, but WITHIN the elements, not BETWEEN elements, and these “links” then must NOT be followed for building up the hierarchy (or then, be CUT, with some automatic commentary (“here follows again subhierarchy xyz”). That’s what I said: You do a STRICT hierarchy, but within that, you do LINKS / clones, but which are “sterile”, and this avoids recursion.

More expletive: You have a link to the main page, but if you follow that link, you LEAVE by that the respective sub-hierarchy of that page deep-down from which go went back to the main page, you will NOT want to “combine” the main page (or some other “important” page to which a link from deep-down there brought you), with that page deep-down, you will NOT want to “see” / “declare” that main page or other as a “virtual child” (and then with its children there) of the page deep-down we mentioned first: Such a construct is obviously NOT recursion, but “linking to something other”, or in your parable, that granddaughter will NOT “make children” with her grandpa, she will just kiss him on the cheek and present him to some school comrade of hers. “Sterile”, as said, NOT bringing the respective children (which in the case of the main page would be the whole tree again, and again… - endless recursion, but even recursion “just one run” is neither wanted nor acceptable), as now common descendance of our item deep-down and the linked main (or other) page.

So you call this linking “A nice convenience”, but we totally convene here, it’s just “going to something else then”, not “integrating” that “different info body, again” into a more precise sub-body of it: Again, I cannot imagine any example where this would be useful, but any such example I could image, I would consider it harmful:

“Why prevent this for the sole reason that somewhere up the hierarchy chain, that item is also present ?” - For reasons of clarity, as said there; for the simple reason that the human mind has to think in various, complex ways, but that for it in order to produce reutilizable results, that thinking has to be put in sensible groups of provisional results (which might then re-group otherwise, further on,

or even re-group otherwise, not instead, but for additional contexts, and as I said, I did not yet resolve that architectural prob (and no other seem to have down either, cf. those 3-dimensional graphic data representations that overload the human mind and thus never “made it”; cf. the conceptual primitiveness of “mind managers” which try to overcome that prob, and which would become of high “trial” interest the moment one of them did introduce trans-file cloning);

we’re speaking of CLUSTERING (info or thought, and of course, these categories then partly mix up) elements here (or of multiple clustering for different task contexts, as mentioned in the previous, the “prob” paragraph), and this clustering has to be done in some way, whatever the “thinker” / IM wants that way to have: He simply has to decide about “stronger vs. lighter relationships” (as in human parentage, and considering, too, that sentimental relationships often overcome parentage, i.e. somebody “from the outside” would draw that net strictly by level of parentage, whilst somebody “knowing what’s going on” in that family would draw the net quite differently - but he would have to draw it in a neat way nevertheless, even if his net neglected the pure technical parentage level and replaced with “mental vicinity” instead).

This is necessary to not overload the human brain, and here again, I dare to remind us it cannot “hold” more than just SOME elements at the same time, hence this need of clustering, in order to empower the human mind to get “some out of it”, of your repository of data. Here, recursion is countering clustering and tries to reinstall chaos of too many elements - you simply cannot distribute thoughts/info in too dispersed a way and then hope for being it useful all the same.

Btw, I can “prove” this to some degree by simply reminding us that if I was wrong, ALL our “outlining” and “information collecting” (which is none other than establishing clusters of that info out there we would like to group together, in order to become useful for us, and hopefully get some “new meaning” for us) would be dispensable if our mind was able to “hold it all together”, without such clustering: We are free HOW we cluster (and what elements we include there), but we need to do it, for one in order to “have it here”, and then, to “have it SHAPED” into a form from which then we can start to “think”.

“(1) The hierarchy is deep” - well, why do you think I developed, in length, my considerations about cutting up your “big tree” into (in my case) hundreds of independent sub-trees, which are TAKEN OUT of a common hierarchy? Because data hierarchies are so good (as I explained here in length, too), BUT for “self-contained” clusters only, and yes, I’m aware this “self-containment” must be a little artificial here and here, in order to become realizable. And then, “putting multiple such hierarchies side-by-side”, in again clustering them, but NOT by trying to do “spaghetti IM” - which is exactly what you advocate here. My tree hierarchies rarely (or never) exceed 3 indentation levels, but then, for one “project”/“context”, I often need 4, 6 or 15 such trees at the same time - but, as said, these are independent of each other, and as I had developed in length here, such a tree could just have 20 items or so - if it’s self-contained, splendid, make it a tree of its own… and then, that same tree for some special aspect would appear in perhaps dozens of such “clusters of a higher level”,

i.e. I strictly cut down info into the “least common denominator”, and then I take these “atomized clusters of the level deeper down” and regroup them, to these “clusters of higher level” - by this I totally avoid all your possible recursion probs, or rather, all those probs your IM concept (and an Ultra Recall big tree concept of 100,000 or more “interwoven” items (= all levels mixed up, “thanks to” the cloning=ubiquitous recursion)) will cause to the USER (’ thinking and organizational capabilities).

Btw - and this is the highly interesting part in your concept-as-you-seem-to-have-done-it (but not as you present it here, from your pov that recursion is a gift, not a prob) -, your technical realization (as far as I see it “from the outside”) also had wanted to decidedly BREAK UP the “total hierarchy” concept, by my “next step” then seems to be quite superior (since it guarantees total clarity), whilst you did not yet have made that second step of grasping that your “hierarchy isn’t mandatory and shouldn’t be total” (as though it is in solutions like UR and such) gives “you” (= the user of your system) the chance to REGAIN that same clarity of info organization, and of thought, as mine does (mine of probably best, but I’m open to any criticism of it, and let’s remind ourselves that ConnectedText also tries to do some real breakthrough to LEAVE that tree concept, which at the end of the day, is unsuitable to big data, as current realizations show as well as your argumentation on recursion, in direct comparison of what I have presented in my developments here…

and which in part convene with yours and with CT’s, the big difference of my concept and these two others being that I don’t want “orphaned items”, but want “folders”/“clusters” (be them in tree form, or in file folder form, for external files) as an intermediate grouping entity, because here again, I want to reduce clutter, I want, in my personal case, some 1,000 or 1,500 such “trees” and the respective file sub-folders, instead of having to copy with 300,000 single files and outliner entries (= some “plain text advocates” ask for cutting up even info I put in trees because it narrowly belongs together, in thousands and thousands of single .txt files, see below).

Of course, single .txt files advocates hereby resolve the prob of how to access individual, deep-down, much more atomized info from anywhere else, but create the prob of how to group these, i.e. they would probably put 300 such .txt files into some “digl” or “384620” subfolder, where I would do a tree with 300 items

(cf. my developments on ORDERED context of every such item, and also the ease of having some about 3 “parentage” = indentation levels for these 300 items: the first aspect cannot be realized within a folder system, the second aspect would create multiple-sub-folders chaos within such a “digl” sub-folder (creating perhaps some 30 more subfolders there - ok, you could try to realize some of these with hierarchical tagging there: OMG, what a mess: I really think my solution is the very best there is, just compare!)),

and then a corresponding “digl” sub-folder (containing the “digl” tree file or not, no matter if you split it up or not), containing any special (internal or external) file (or a “clone” = link) belonging to that “digl” context/“project”.

Of course, in my system, there is also a need for accessing just single items, from other contexts, and not only these “trees” (even if they are cut to their bare bones), and that’s why I spoke, in my developments, of db’s with just references, and then a technical realization where such items are NOT included into tree files, as a next (and then, perfectly scalable) step, but would be technically independent, as items in db’s - all these trees then would be virtual BUT independent nethertheless.

It’s all about “preserving” info in a “manageable”, “usable” “format”, and I think that within a big corporation, some 20,000 or 30,000 INDEPENDENT “compounds”, as described by me in this forum, are much more “apt to be handled”, than are 10,000,000 single, atomized items; and yes, as said, I acknowledge the task of just “integrating” ONE such item, from perhaps a tree of 100, into another tree/project/context, instead of giving that one a sibling of 99 unwanted items, for 1 that is needed there.

“you don’t automatically die with him.” - No, but in my IM world, that “orphan”, be it 3 years old or 85, would have to get a new father, before we let the former father die ;-) - in order to not produce an informational chaos with millions of disparate elements (which is also the prob in the CT concept, if we “blow it up” to corporations, and at the end of the day, you won’t be able to cope, as an individual, with 10,000 disparate elements, exactly the same way as as a corp would be incapable of coping with 10 million).

“(2) To bring a parent close to an item.” - That’s exactly what my system delivers, in the utmost possible, neatest way, without mixing up things for that, as your “system” does (= as said, your realization seems to bring good possibilities, whilst it’s just your argumentation here that’s not on par ;-) - and of course, users of your system would have to be careful, whilst in mine, the system itself would prevent them from making recursion mistakes ).

Also, bear in mind that my system, by splitting “content” into multiple (but, and that’s the keyword here, independent) trees, makes any such info, even WITH the respective children, available everywhere, by just “sidecar-ing” that tree wherever it’s needed, without it becoming necessary, for that, to create chaos with “not just referencing, but cloning here, together with all its children”:

At the end of the day, you could put it this way: My system automatically “cuts” any tree from any child tree, conceptually; let me explain:

Of course, the “ciou - computer - IM - outliners - Ultra Recall” tree is a “child” from the “cio - computer - IM - outliners” tree, but these “trees” with c, then ci, then cio, then ciou, are just “virtual container trees”, just LISTING contexts; they do NOT represent “strict hierarchy”, as the corresponding headings would do in e.g. a UR tree; they are just “nagivation aids for multiple contexts”; wherever the “cio” tree is referenced to (which is NOT “cloned there”, just referenced, in its entirety, with all its links it might have, becoming “sterile” links here). The same would be true for “projects”, for project trees, and conceptually they do NOT need to be differentiated from any other context tree, since they function entirely similar - of course, you would have project trees listed elsewhere than “reference material” trees in your “trees of trees”, for better navigation, and perhaps even put a project tree, after completion of the project, and just-as-it-is, into the respective “reference section”, without any functional difference, neither before, nor after it having become “reference material”.

In fact, my system has broken up the big tree structure in two “halfes”, if you want to see it that way: Instead of having 6 or 8 indentation levels for things, I introduced 3 or 4 such levels JUST FOR TREES, and then, every such tree will perfectly do with just the remaining 3 or 4 indentation levels that are necessary there, any level “above” having been just “cut off”

( “Why prevent this for the sole reason that somewhere up the hierarchy chain, that item is also present ?” - the trick is, it will NOT be present there anymore, but will have been “side-car-ed”, as everything else, nor cluttering your data repository anymore, neither impeding your thinking )

, and anything else you ever need here,

IS REFERENCED, BUT REMAINS REFERENCE

- and will not become “father” or anything for anything in your current tree, conceptually, even if for micro-navigational reasons, you present it like such - But that’s another reason why I advocate, “hold it flat”: this will prevent, more or less, such misleading representations - btw, you could perfectly prevent, technically, any such link to some other tree, from having any “child”, even “just visually”, and as said, even in the “tree’s trees”, we’re just speaking of links in lists.

I’m perfectly aware of all the limitations of Warnier’s system, and my system overcomes any of his, but his system was the total breakthrough all the same, it was a beginning, a start, but before him, programming had become “unserviceable” and “un-further-developpable”, and see what we’ve got since, in programming / sw architecture, with the foundations he laid out for this. So, I’m certainly not arguing “extra” against your saying, “I believe that IM software should not constrain users” - I think I’ve refuted it. The origins of Warnier’s concept put too many constraints on programming, but he had very well to start somewhere! And speaking of origins, it was all about output then (cf. the numerous Kenneth Orr papers on that (far too) special subject) - today, user constrains are far less strict, but constrains there are, and Warnier (and his American counterparts) saved programming from early death. I very much hope it can be seen that for IM, similar principles apply. Btw, big data, information overload, how to copy with the fact that every day now, “they” produce as much “info” (or false info) as is contained in print in the whole Library of Congress, etc., etc., blah, blah - it’s all about introducing (and perfecting!) constrains.

“IQ support hierarchy equations” - here again, we convene perfectly (my legacy sw had a “sum-it-up” function, too), but here again, let’s not mix up “inclusion” and “recursion”; why not prevent (useless, troublemaking) recursion to begin with, at a very early stage, and then for inclusion tasks, no such additional, special recursion prevention will ever be necessary. Btw, I didn’t ask for real-life examples of “where to prevent recursion”, I asked for such examples where recursion would be useful (and that means present usefulness my “recursion-less” would be less useful). ;-)

“Inheritance” - a special form of inclusion, here again, recursion would be the ultimate mistake; so you named a second example of where you are aware that recursion has to be avoided, instead of “delivering” ;-)

Again, recursion is a very useful concept for programming at the micro, but not on the macro level, and I honestly don’t see any use for it in IM - not even at the micro level. ;-)

_________________

Permit me to repeat my core sentence, and which is the “secret” here:

IS REFERENCED, BUT REMAINS REFERENCE

Or in other words, in IM, the rule goes, have sex, but contracept, and this’ll avoid any possible oedipian offspring that might then ruin their mismatched-(as)-parents life.