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
Dec 21, 2013 at 05:12 PM

I need to explain two things:

1) Recursion

I did not put entirely correctly above. When I wrote my IMS 15 years ago (I’ve said this before, I didn’t knew then how to construct a tree “component”, today I would buy one, but again not for building up a “complete tree”), I did “cascading siblings lists”, and fields/record fields for “natural parents” (= main parents) and “adoptive parents” (=any other parent = “clone heading”), and of course, any such adoptive parent had its “natural”, but also its “adoptive” children, as children. To this (theoretically infinitely) cascading set of children, I added a “build up tree” function, for printing, and for exporting into Word (97), and here, clones were NOT followed, in order to avoid recursion; this is far from a perfect way of doing it, but a “working way” at least: Whenever a “child” (of any indentation level) occured somewhere, it had to be an “original child” in order for its descendants to be included in the tree the routine built up, and a prerequesite for all this functioning without fault, I had checking routines for item moves which intervened whenever I tried to move an item “under” a new (“natural”) parent, and whenever this would have caused recursion, i.e. even in my whole body of items, possible recursion was avoided early on: Such moves then weren’t possible but under the condition to get a new “natural” parent for that item (and again, checking for that one), whilst the previous “natural” parent was to become an adoptive parent “only”, then.

As said above, most “outliners with clones” do not do anything like this, so it would be of interest to see HOW they avoid recursion, and/or “infinite trees”...! Btw, early versions of MyInfo, after its introducing the cloning feature, did not get the clone’s children with it, to begin with, which is another, quite radical way of avoiding recursion; then they amended this (and put its cloning feature on par with Ultra Recall’s one also for the “user experience”), but it would remain to see which way they “did” it.

Now, my concept of “independent trees” does not entirely avoid recursion, since it would allow “cross-referencing”, which implies introduction of external trees of parts of those into the tree-at-hand, and those parts could contain other references, and so on… and even if you have some checking routine, ulterior changes in referred-to parts of external trees could THEN create recursion: At least for printing / exporting ( to Word, html, pdf…), this must be avoided, i.e. whenever you “physically combine” those references, instead of just refer to them. Of course, you could insert “stoppers” instead: Not integrating the respective children/external subtree, but a single ref item saying”, here, refer to parts xzy of item number 1.4.3 above which would be reproduced here again” (and which would contain itself some more referential parts creating recursion perhaps).

2) The above-described “automatic fetching of relevant files” for your outliner items

I left out how to do this automatically, since within the corresponding tree, there are not even links (that would have to be synched then). In fact, imagine a traditional “file plan” of a big corporation, like in the Fifties, i.e. for physical files. Traditionally, such file plans were numerical, e.g. containing “folders” (file groups) like 1.5.3.2.4. Now I devised a more modern system, ABE, FDGH, but where individual (physical or electronic) files would be named “ABE - blahblah1” and “FDGH - blablablah24894”, whatever. Now, the software/script just considers the “non-comment part” of all this, the “ABE” or “FDGH”, respectively (and since we’re speaking about an abc here, not about digits, most corporations would do perfectly fine with up to 4-character codes, not more: 1 “level” is at least 26 sub-directories, not just 10, and now multiply 26x26x26 and compare with 10x10x10, and you can even have lots of mnemonics here, at least for the “really important stuff”), and for every thing you have in your system, you are free to rename the “comment part”, the part between the code and the file extension, as often as you want (which introduces the possibility to insert ToDo/delegation/etc. codes here) - the whole system is held together by the coding part, those “ABE” and “FDGH” where, of course, “ABE” is a sub-group of “AB”, which is a sub-group of “A”.

And that’s the core part of my system, since it allows for automatic “adjoining relevant documents here”, from anywhere: physical files, special folders, e.g. Outlook folders, ditto for IBM (formerly Lotus) Notes, modern MS mail (Exchange), whatever, and whenever there is no such “totally correct” FDGH” folder there, the corresponding “FDG” folder is “looked up” and displayed, or in an ulterior system, just its content would be displayed within your IMS - and if there is a “FDG” folder in this folder sub-system, and just a “FD” folder in that folder sub-system, those “differently indented” contents will be automatically retrieved from those sources and then combined, and this means, you will have some folders very fine-grained, and others less so, according to your respective needs: no necessity, but always the possibility, to have a folder “FDGH” for just one file, and another folder “FDGK” for another single, or then, you could have 5 files instead in a folder “FDG”.

As said, you can integrate such a system into one IMS, you can prototype it beforehand with a combination of IMS, file commander (a free one like FC will perfectly do here), and with other programs of which you directly access the relevant internal folders by script, e.g. Outlook, but perhaps also for TheBat! or such, and since data is spread over applications, it’s all perfectly scalable, whilst at the same, access rights M and all this can be done within the central, the core application, and then there would a “display component” to visually gather all this - even what today is your “outliner items” could/would come from an external application/db, and just be “fed in” into this visual component, which only “lives by” lists of links and the necessary viewer components. As said, such a system would work for 1 man/woman, or for an administration like the NSA.

And that’s why I don’t advocate “internal search”, but here again, just “internal decision” WHAT is searched, and then an external search component would search anything relevant / provide the results for anything relevant from its central index, and would trigger the routines which “feed” those results to the viewer part. Such a system would also be perfectly safe, since the “clients” would “own nothing”, just make demands, and if the central compound says “yes”, get the results which are deemed to be “deliverable to that destination”.

So what I have in mind is a very “slim”, elegant architecture, in which there are man central “agents” that combine relevant elements, and in a second step, AI should allow for automatic combinations and/or automatic add-ons of further elements to “manual” combinations, too. It goes without saying that the different “seats” in such a system would have quite different “access rights”, and I’m aware there might be corporate sw that “does all this” even today; but since it’s not known you can buy such sw even for 5-seats corporations, at 500$ per seat, there seems to be a market for this. And yes, scanning of documents should be easy, together with easy (automatic/half-automatic) “tagging” of such additions, i.e. the manual entry of the respective “IGHR” code for each such document should not take more than about 5 sec., by selecting them from some restrained list, pre-restrained by sw already.

All this is easy to design and to code; proper collaboration/versioning (which is also needed in such a system) is intellectually much more demanding.