Forum Posts Feed
The Function Beyond
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Jul 30, 2022 at 02:37 PM
(And oh so sorry if the “22111 should be silenced” fraction’s not able to recognize specific 22111 threads from their specific titles…)
First, the intro for the self-declared “authors” fraction here; other readers can continue after the ___ ...
Yesterday, I happened to view, just by chance, some in parts and for some aspects at least, quite wonderful movie, Die Stropers, a 2017 Afrikaans movie to be looked up in imdb by “The Harvesters” (title à double entendre, mind you…), and whilst most of the imdb “comments” were sub-par - I read reviews after having made up my own mind, mind you -, it’s on https://www.allocine.fr/film/fichefilm-264015/critiques/spectateurs/ that you will read some smart observations, and especially from “poet75” there, who not only confirmed my - yeah, obvious! - observation that there’s lots of Malick’s “Days of Heaven”‘s photography and mood in this one, but who - him alone! - also confirmed my own observation that there’s “Teorema” in it, from Terence Stamp to “Pieter” now, it’s not only obvious but much more, and you should become aware of that indeed if ever - that’s the conditione sine qua non - you will have viewed the Pasolini flick, even if that has been 50 years ago (as I did).
On the other hand, even “poet75” missed the Hanno-Janno “parallel”, and then, I got curious if some “third party” “got” it, but no, my google searches just showed false hits, since “hanno” is an Italian term, and even my search “thomas mann harvesters” just brought another false hit, to an otherwise very commendable book and pdf (I’m not entirely sure that the pdf might be legit?!), named “1001 books you must read before you die”, and which of course, for one, mentions Hanno re “Buddenbrooks”, but then “The Harvesters” as Pavese’s “Paesi tuoi”, and the “top hit” for that title is of course Bruegel the elder’s painting.
Whatever, you should know about “Buddenbrooks”, we’re not in elementary school here, and thus, you should know about Hanno…
and then, Etienne (or is it Étienne ?) Kallos mused, there’s “something”, i.e. some person, BEYOND, and that’s my subject here, and yes, I’ve been writing for some time now upon some quite similar “thing”, some idea of some, now “classic”, author, and then thinking beyond, so Kallos hasn’t given me that idea indeed, but it would have been, and was, a brilliant idea indeed, even I hadn’t had the same idea on my own, for my own stuff… and btw, Die Stropers being from 2017, I obviously have developed my “Beyond” idea after he did it, and, be assured, mine’s about something “totally different”...
But then, it’s about developing your own ideas where others’ had come to a halt, and Kallos even named his “primal hero” after Mann’s… and though, even 5 years later, nobody cared…
This being said, Mann’s novel is a masterpiece (which got him the Nobel Prize), and Kallos’ work is breathtaking by at least some aspects, and yes, some situations / scenes make you think of their obvious (i.e. subliminal?) model, and make you thinking ‘bout Kallos’ not going beyond Pasolini in there, and I’m not speaking of sex scenes, but of denied outbreaks: you literally expect’em, but those en-têtes fall flat, and so, and for other reasons, reviewers summarize, “festival circuit”, and they’re obviously right, since the-numbers.com (to be searched over there by “Die Stropers” again) doesn’t give any (i.e. box-office or other) “numbers”).
Whatever, and whilst arrogant-elitist-not-worth-much Cahiers du Cinéma say, “Cahiers du Cinéma - par Quentin Papapietro - Baignant dans une lumière orangée, parcouru de nappes de sons entendues mille fois, ce pur produit de la (ré)écriture festivalière et de la coproduction internationale semble multiplier les pistes narratives sans jamais en privilégier une seule, pour accoucher d’un scénario doloriste et convenu.” (citation by allocine.fr again), I’d rather say Mr. Papapietro’s secretely crying he’s got the right first name indeed, but then not also the right second one - weep, weep, or rather weep-n-hate? (cognoscienti cf. Feyder’s “Visages d’enfants” (1923), imdb: “Mother”), now back to work, and let’s have a look at OUTLINERS and the like, and of which most also ride the ME-TOO train (which Kallos, notwithstanding Mr. Papapietro’s opinion, does not), and with just VERY minor variations. - My next post here then, very technical again.
(And yes, “The Harvesters” could have become a b.o. hit, with Oscars and all, since it’s a thriller anyway - it’s just another missed opportunity of real greatness -, and yes, Hollywood and Art, with a major “A”, isn’t a dichotomy, and there has been proof galore in our - in everybody’s, even your toddlers’ - lifetime.)
Posted by 22111
Jul 30, 2022 at 06:41 PM
Thus, Pieter being the “function beyond” Hanno/Janno - and yes, some thriller’s a tragedy, too, and at the end of the day, every good thriller will be also a tragedy and foremost indeed -, outliners all are ONE SINGLE outline, up to this day, and that’s obviously nuts - it’s just that technical, and even more so, conceptual difficulties (i.e. intellectual limitations) have prevented that “function beyond”.
(NO politics here, just technical stuff:)
Here - https://www.outlinersoftware.com/messages/viewm/41841 (“Who are you? I’m next” - citation from the extended version of “Apocalypse Now”) - I described somewhat my problems with multiple dimensions in an outliner, with the example of my Covid/Corona press clippings of all sorts, and I described, or rather implied, my personal problem that for some 15,000 press clippings, the number valid some months ago, I had not been able anymore to correctly “file” those clippings, but had “filed” most of them just by “country”, not by “subject” (e.g. “disease”, “possible origin”, “vaccination, medical aspects”, “vaccination as a measure”, “other measures”, etc., etc.) - I had been simply overwhelmed by sheer numbers, and by the difficulties, not only to apply multiple “copies’ links” “in time”, but then also, and especially, to stay “on top of things” while perusing my “savings” - I also described my “need” - which would be technically, but just technically, solvable - to have all of the other dimensions “available”, for any originally “taxonomic” category; - and not even speaking of the fact that for those press clipping, or at the very least, for the most blatantly biased of them, I would have liked to also have entries in “Politics - Press”... whilst my “Politics” UR db is quite another UR db, with again more than 15,000 “items”, and with again more than 1 GB of (squeezed) data, so (re-) combining the two DBs would not really help, since both DBs, even individually, clearly show signs of “SQLite (or then, is it “SQLite in its UR outlining flavor”?) not really being fit for big data”...
I then shared my observations with SQLite’s FTS (see there), in “Tags, and Export” = https://www.outlinersoftware.com/topics/viewt/9828/0/tags-and-export-cave-canem-or-whatever-you-might-be-in-awe-of where I listed many of SQLite FTS’s exceptions, whilst also listing four non-exceptions, i.e. °, §, ¦ and ¢, all four of them easily available on my keyboard, whilst not having checked all of similar “special chars” indeed.
This way, in UR at least, but very probably in some other “outliners”, too, and which also rely on SQLite’s FTS functionality, you’ll be able to LEAVE OUT one of the - important, but troublesome - dimensions: out of your - just one-dimensional - “outline”, whilst putting it back “into the game” by e.g. “°cd”, or whatever your individual “tag” my be, written into, e.g., the very first line of the “content” of your “item”, or even at the end of your “item”‘s title, in order to get that important dimension which would otherwise much too much complicate your tree, “°cd” meaning, in the example above, “country: Germany”, ditto for cc = China, cu = U.S., e = Spain, etc., etc., with, in the case of need, some “°cos” for “Countries - Other European countries - Sweden” or “°cas” for “Countries - Asia - South Corea” - you’ll have gotten the denominational system, I suppose.
(And for press clippings, you could introduce a similar system for the origin of the press clipping in question, e.g. “°sf” for “Source country: France”, and the like…)
Then, what will you get by that? You will be able to “filter” by that “tag” (i.e. in UR at least, and in several other “outliners”), i.e., if you will have set the “columns”-to-be-displayed (and their “order” order) accordingsly, you will get a “hit table”, i.e. a list of research results, by “tree order”, of all those “items” which will apply (°c…) to, or come from (°s…) some country, i.e. you will have a geographical filter set now, but you will get the tree as-it-is…
Except that your new “tree” will (and in “tree” order, but without the respective item indentations) be in some search results window, which is quite awful indeed (but better than “nothing”; in UR you then can even edit the “hits”, without the “results lists” vanishing, IF you de-select “highlight the hits within the text”...)...
Some developers tried to do this better, among them the ones of “Maple” (by “Crystal Office”, very different from the much more known “Maple” maths app), and which then, i.e. upon search / “filter”, open another “tab” within the “tree” pane; unfortunately, with “Maple” 8, as well as with “MyInfo” 6, I got to crash the programs within minutes, and on very simple tasks, but then, “Maple” is currently in version 9 (and “MyInfo” in version 7), so I cannot pretend these respective deal breaker prevail (UR is perfectly stable though, and, ironically, MyInfo’s (versions 5 and 6; as said, 7 is the current one) crashes systematically occurred when I tried to use, just some, and very basic, data within MI’s “columns”, which can (i.e. could, in 5 and 6, I don’t have trialed 7) be systematically displayed there, as in a spreadsheet, which is not the case with UR, unfortunately).
Then, lately, I made a very important observation: In most fields, that “other, almost-tree-breaking, at the very least tree-(building-)highly-complicating”, alternative view / dimension” isn’t necessary but for just some items, in special situations, and thus, the above-described tagging seems “ideal” for it, albeit “filtering within the tree pane, instead of within some additional pane” should always be at the users’ fingertips (i.e. by 1-key-toggle) indeed.
On the other hand, the above-mentioned Corona example, and also, in a broader sense, the “Politics” example (almost 20,000 items, classified by countries since otherwise I simply would not have been able “to do” it, within UR’s, or then with any other current “outliner” of my knowledge) are core examples of “use cases”, i.e. areas in which “just apply the additional dimension by tag” simply “isn’t enough”: There, you will need real “pivoting”, as there is, for “data crunchers”, available in MS Excel.
Then, obviously, the software developer will encounter a big problem: They will not know, beforehand, which sub-trees (i.e. parenting for their own sub-tree of multiple sub-trees, that is) the user will need to have “pivot(e)able”, and where such functionality will not be asked for, so they will have to implement it everywhere, which will tend to multiply the tabular data to be maintained by the “outliner” software, even wherever the additional functionality will not be called for.
And that’s obviously that “functionality beyond” in this thread’s title: Nobody, to my knowledge, ever cared for implementing it…
except for, ironically, askSam’s developers, before those, obviously, left the room, and thus left the owner, an old aviation hero at the time, and the marketing chief, some Mr. Goodman, but who obviously wasn’t able to do the (necessary amount of re-) coding by himself, alone with their obvious “mess of code”; considering that they claim to have sold 350,000 (or more) of licenses (and most of them without intermediaries, obviously), that makes 50 million bucks, at the very least, probably much more and even about 100 million, of which I’d very much like to know the whereabouts, since I could change the (IT) world (at the very least), with 100 million…
Now, let’s speak about a fallacy: Most “outliners” - whilst not all of them, but then, the ones that don’t do it, don’t take advantage of it, obviously - don’t differentiate between “folders” and “items”, and “correctly” so, since our file systems’ differentiation between the two concepts more often than not seems arbitrary.
On the other hand, in our “outliners” - and I personally speak of about 350,000 or near 400,000 “items”, spread over some 30 SQLite DBs - since SQLite isn’t “good enough” to “hold it all in just one file” (and that may be, in part, UR’s way of implementing it, but then, other SQLite-backed “outliners” also show quick, sometimes even very early, lack of means for administering large data sets, even way “before” UR stumbles somewhat, so 350,000 divided by 30 does NOT mean that UR just “takes” 10,000, but then, it doesn’t “take” 350,000 either, and much, much less indeed, unfortunately…) - - in our “outliners” then, even most “parent” items are just that, parent items of some sub-items, “siblings”, that would never ever have to be considered as some “pivoted group”, whilst on the other hand, many such “groups” exist indeed, and even every single item might be considered within, not only multiple contexts, but multiple pivotal data representations.
The answer of this enigma - but not the solution to it, too - lies in, from our, nowaday’s point of view now, “early” works of those, not only in their time, “brilliant”, no: genial!, askSam developers’ developments, and which didn’t come thru b/o askSam’s incredibly awful “forms” concept: any new “field” wasn’t possible but within a form for new (sic!) items, and that’s the “detail” that killed askSam.
In fact, as soon as you differentiate between an item’s title’s “field”‘s (i.e. “column”‘s) name (i.e. the name of the table column), the title of the record…
AND THEN ALSO THE CATEGORY NAME IN-BETWEEN THE TWO
- i.e. you just need, in any SQL system, another, intermediate table, with which you can render ANY sql “outliner” as “pivotable” as MS Excel is, for its cell data…
the same unfortunately not being also true for NTFS file system folders and files, since NTFS and other (but not necessarily all) file systems do not assign ID numbers to their elements, neither to their folders nor to their files (so that it lacks the necessary indexing facility).
HENCE
We need, in “outliners”, a new category, call it “category” or whatever pleases you, and which may not necessarily be, but can be, in cases, a specially-formatted, intermediary tree entry, or just, that’s just as good, a specially-formatted, otherwise ordinary, “parent” entry, but of which the special formatting indicates it’s also (i.e. additionally) retrieved and indexed in the special “categories” table…
And then, you just need the necessary pre-sets (i.e. “stored views” for those sub-trees of the global (hopefully Postgres- instead of SQLite) tree, and the necessary pivotal code, and then, pivotal views are nothing more than pre-set views, as any common, today’s “stored search” is, any current “filter” is.
“Outlining” is its own, inherent fallacy, by pretending, by having pretended to us, for some 40 years now, that “outlining” is ONE hierarchy (amended or not, i.e. with some sub-trees “cloned” elsewhere or not), and askSam’s developments around 2000, or even at the expiry of the 20th Century, have amply proven that to every (sub-) “outline” there is, there may be multiple alternative (sub-) “outlines”, you just pre-set, and store, preferably in short, abbreviational “codes”, as I have amply described here in this forum, the respective hierarchy to be displayed.
It goes without saying that if you work in “folders”, you can preserve some manual “order” (within the groups) wherever that makes sense, whilst if you apply such a system just with tags, you will just get (multiple possible) ways of automatic ordering of the elements, but the core message is, you “file”, “work” in some - whichever! - “outline” representation… and next time, you pursue your “filing”, your whatever “work” in whatever alternative “outline” “view”, and then again, you’ll “switch back” to any of the previous “outline views”, or you create new ones which will fit into your “workflow” as well.
As for the “special formatting” mentioned above, and since I amply discussed the necessity of user-specific “tree entry formatting”, I suggest, for “category formatting”, a special symbol, so that “bolding”, “coloring”, “italicizing” and the like will remain available for the individual user’s means (cf. my comments on the awful “factory formats” in Devonthink…).
Then, the user, wary of creating the necessary “categories” for tree-building - and even the term of “pivoting” would then be misleading, since it implies a “natural”, “base” “outline-form”, whilst there is none, taxonomies in themselves being the fundamental fallacy, see? Be it “natural phenomenons”, be it “measures”, be it “consequences”, be it “actors” (in that “scene”), be “countries”, be it “anything”, any relevant dimension in any area:
Software, at the end of the day, should provide you with that functionality beyond, which opens up your range of doing things, by first viewing them differently.
So that you’ll need “°somethingsomething” tags just for “special cases”, in order then to better “weigh” possible FTS (see above) “search results”, before AI steps in and takes over.
In practice, all “dividing”, (“sub-)titling”, “categorizing” “parent(ing)” items should be (more or less automatically, certainly by 1-key attribution in case) also become “categories” (in waiting), the secret here being that their “category name” is NOT also their title, but within your tree, you would have those entries (whenever the “category” is not distinct, as a pure “folder”, and as implied above, that’s not even necessary, whilst in NTFS, it currently is indeed), in the form
SpecialIcon space TitleAsFormattedByUserE.G.France space (and in () and in grey: Category, e.g. Country)
(= 1 line)
And then your preset “tree-building” would create, from “Categories” in/on ANY indentation-level, “totally mixed-up”, “top-down”, “bottom-up” and every which way of combining such concepts, category by category, ANY “outline”, not only from any, alternative “global” pov (e.g. “geographical vs. systematic”), but then also with any “in-between” “alternative detailing / ordering” as you might need in any specific “use case” - those “use cases” differing by the individual “sub-trees”’ requirements or by those of individual DBs… but then, believe me, here again: Some one-and-only Postgres db, even spread over several physical devices, would be oh so much more welcome than multiple SQLite DBs…
“Outlining”‘s (and now 40 years’) fallacy consisted in not distinguishing between the tree’s sub-titles’ NAMES and their possible CATEGORY NAMES, and that’s why - whilst askSam should have been our teacher, in its final version 7’s help file it’s all written down IF you’re able to read between the lines -, even today, we (? I!) know of no “outliner” with “alternative trees”: with the (sub-) titles (and their IDs) you can’t do it indeed, you can’t do it indeed, but with their - “implied” category names, i.e. with ___which category’s individual value then___ they represent, it’ll all become easy, technically AND conceptually… including “cloning” of sub-trees, their “clones” just being included within those new “meta categories” or whatever we could call them, “here” and wherever they belong, too:
From the “taxonomy” pov, your car assurances belong within “assurances”, but you will create the clone of that “group” or whatever we call it, in “our cars”, which will in turn be a (cloned) sub-group (or whatever you call it) of (“natural”, taxonomy-wise) “group” “transport(s)”.
And yes, the above doesn’t deal with ease-and-speed of “multiple-filing”, and it’s obvious that the latter problem should be resolved by - before AI takes over - “individualized” “selections to click” of allegedly appropriate secondary filing targets, individualized in the sense of you first, in your “general inbox”, typing some char, e.g. “p” for “politics”, you getting a list of countries, with your “standard” countries all 1-char = 1-key, and other countries 2-key, in the above-described “(en)coding”, even multiple entries being allowed, e.g. df meaning “Germany” AND “France”, and then you type a comma, which will aim your subsequent entries to another part of the displayed info list, and in which you will, again by 1-, 2- or 3-char “codes”, either memorized, for your standard “filings”, or then read from = looked up in the lists displayed, determine further, “systematic” filing targets (with commata in-between, for your kb entries), and another comma will get you to more filing tables, non-standard within your current situation, and any “return” will process your “filing” entries; for my UR filings and for “standard” filing situations, I have even realized, within AHK, such half-automated ways… (It’s obvious though that any distribution of your filing targets upon more than just one db unnecessarily and awfully complicates things…)
Of course, “consumers” of this forum - to call them “contributors” would be a blatant lie for most of them - are free to shout, “Zettelkasten, Zettelkasten, Zettelkasten”, just as totally incompetent politicians here all over Western Europe constantly claim their minimum of competence to political thingies, defending their 300,000 bucks-and-more p.a. emoluments, by uttering the “necessary” “key terms”, but at the end of the day, software development should not be about facilitating paradigms of the past, considering that yes, searching for ID numbers’s faster on a pc or a Mac than it was in the card box and drawers age, but be about delivering THAT FUNCTION BEYOND.
“Die Stropers” is a tragedy: It’s about a human being which, with all toil, will never be able to cope with the expectations of some “environment”, dying anyway, just not as quickly as their outcast, literally sacrified victim who gives up.
When I said, in the one link above, with “°something”, you can (I left out, sorry: “in a way”), replace XML elements, that wasn’t entirely correct, since both askSam “fields” (just not for outline building, as explained before: then just the very first one), and XML elements, allow you to then even search for one of several elements, whilst in UR and other SQLite-backed “outliners”, you would have to write °ar, °av, for being then able to retrieve different, “r” OR “v”, values for attribute “a”, there’s no “r or v in a” then…
But that’s details; as for their “real possibilities”, current software developers fail, the ones who dare charge “subscriptions” as well as the much more modest ones.
They lack inspiration, and that to the point of not even being able to steal the core from genial ancestors. They seriously think that me-too’s good enough, even when it’s sub-standard.
And, with all due respect, “standard” is, at any time, what exists, be it Twain or Faulkner quality for modern writing, or then askSam for “outlining” in the 21st Century: stepping behind, and wanting to be paid? Become honorable: open a fries stall!
(And then, Die Stropers is a tragedy because they discarded the wrong boy.)
Posted by 22111
Jul 31, 2022 at 07:52 AM
Some better but concise explanations for both subjects:
The movie: Kallos gives credentials, Hanno>Janno, how better could he said it, he just didn’t foresee the educational lacks of most contemporary critics. And the Boer family’s “life expectancy”, with the iron bars on their windows - the perfect (arson) fire trap, wouldn’t you say? - is, by probability, less than Janno’s individual life span would have been, even if he hadn’t had any children, and why should he not have had any, with a little comfort from his family, and the same way “his” generation in that family (either predominantly or all of them) was put together ( - the movie suggests most of all of the kids, incl. Janno, were adopted) - instead, the replace him, in order to get, in Pieter, that function that Janno, in their eyes, will not be able to fulfill. That’s not Christianity, that’s bigotry, and prayings, even quite fervent forms of praying, are shown throughout the movie, going onto most reviewers’ nerves (Bergman did that better, in “Fanny…”); btw, Pieter shooting his dog himself is, but exactly, Snyder’s “Save the Cat”, just turned white-to-black, i.e. into the negative. - oh, and speaking of Twain, just after writing here, I viewed, by chance, “Mud”, another movie with some lengths, but one you’ll be happy to have seen if you do - and so it worked at the box-office, too. Back to Pieter, ‘course he tries to establish for himself some “position” in life, and he isn’t even mean, just the “Cahiers du Cinéma” guy is, but then, the family situation being “now” as it is, by the mother’s suconscious atrocity, Janno just PRECEDES the family’s waiting stroll into fire. And there’s misogyny in the parents, too: The three little sisters are young, but the parents are young, too, and will there not be any chance in any of these kids then, and without sacrificing their son, at that early age he isn’t able yet to make “alternative plans” for his life, to some “stranger”? From a writer’s perspective, Kallos’ introducing Pieter as that “spin on”, “beyond Hanno”, is highly interesting, even when then some girl on imdb said, after viewing the film, she had to get a chocolate bar to regulate back her mood into normal.
The introduction of the third dimensionality, vulgo “pivoting”: We would need something like the thing I described above, as a “starting point” to then refine the concept; we must see that today’s “parent” relationships, by which (alone!) then even the tree form is built up in many such “outliners” (and definitely in UR, see Codd / early Oracle and the “Adjacency List Model for Trees”) are just technical: When you build up the hierarchy geographically, you will probably have a parenting item “Europe”, with several “child” items, “France, “Netherlands”, and so on, and here, the parent-child relationship is not only technical, but also “organic” (those countries are “natural children” of “mother Europe”, and so on), but that’s just by chance; further down, you will then have the respective politics, measures, even scandals (politicians filling up their or their families’ / friends’ pockets, etc.), and thus, there is NO such “organic” relationship anymore between those “children” and their respective “parent” items (except perhaps, and debatably, in rare cases where you pretended that, in this very last example, “political corruption is / has now become quite natural for country x”, hehe).
And most of the time, it stays that way even if you do turn round the construction, by some sort of “pivoting”: Whilst in the example above, the “higher-up” “parent-child” relationships seem “natural” indeed (continent > countries > even counties and such, e.g. Bundesländer in Germany or Austria, or regions, then départements, in France, even (big) towns then, in case), the “break” occurring “further down”; now when you “build” by politics, measures, etc., again you will have some “natural parenting” higher up, and then again, the break will occur further down, at the level where you split up every (or just some) policies, etc. into their geographic variations or implementations:
Thus, whilst in theory, technically, you could “mix it all up”, in most real life use cases, and not only, it seems to me, if there is geographic sub-ordering present in the “tree”, the “pivoting” will be wanted along some “standard lines” but which might occur, at different positions within the “tree”, at different indentation levels indeed, since in some sub-trees, you will have inserted additional subdivisions which, e.g. for “quantity” reasons, were deemed not necessary between similar element “classes” in other “tree” positions, so a simple, technically easy, “mechanical” “pivot by (tree/indentation) level n” would not be feasible, and that’s obviously the reason currently no “pivoting” in “outliners” seem to exist.
Instead, we have to identify the “breaking points”, by their “natural character” if I may say so, and which, see above, is NOT determined by their (systematically indefinite, “systematically aleatoric”) current “parentage”; on the other hand, it’s obvious that even “before pivoting”, and in most real-world use cases, most parent-child relationships in the “tree” can be “left alone”, i.e. they probably need not be also determined by their “systemic character” or whatever you might call it.
This again is not entirely true, unfortunately, whenever you might want to obtain aggregation, e.g. whilst in one view, you would want to clearly discern between (to remain in the above example) regions, or between measures, in another, “pivoted” view, and with scarcity, or even absence of items in some sub-groups, you would like to aggregate further-down, all the more so since in this view, your objective lies in observations elsewhere, and it’s obvious that a “pivot function” for outlining can not also accomplish such additional wishes, except with quite some additional code for obtaining, then storing such additional “view” particulars.
But back to our “pivot!” task: I always said we need 3 panes, not only 2 (see in this respect the individual means “robbed” Devonthink users now employ in order to at least “replace” a little bit that third pane DT developers took away from them), and it goes without saying, considering what I have said in my previous post here, that whenever I say “tree” above, I mean that “main subtree” which should be listed as being self-contained within that very first, “additional”, “project” pane (in a powerful contains-it-all db), and instead of being one of multiple, distinct DBs, in other words, I always speak of the transformations, the “pivoting” of self-contained datasets, even though technically, within the global db, their “source” element and all it “contains” further down, is a “subtree” for its own part; technically, within the global db then, those “DBs within the db”, i.e. all of their items = records, should get their own special (and also indexed) “db ID”, additionally to their regular “item/record ID”. (Such a concept would NOT interfere with interlinking between (single or even parenting) elements of different such “DBs within the db”.)
Then, when preparing the “pivoting”, the user interface should, within its (then not needed) very first, “project(s)” pane, display the “tree” (again, of that “db within the DB” currently “pivoted”) in its current, non-“really” updated state, before the “pivoting” takes effect, whilst in its intermediate, the “tree” pane, it continuously updates the “result”, according to the changes the user makes in the aforementioned, then “(transformation) work” pane, and which is just updated by, i.e. displays the changes the user makes there, with respect to the additional, or even renames of, “systemic poles” (described in my previous post here) still needed (since the “target”, the “tree” pane continuously displays the intermediate results), whilst in / on the screen position of the currently-not-needed “content” pane there is room for the necessary, concise “target” / result tree construct to be obtained, and which will be stored to get back to that additional view later on: it’s the “code” then, and behind the scenes, the tool will store not the current presentation of the tree in that view, but the framework described in my previous post; it’s obvious that the “work pane” here could greatly assist the user’s transformational work by (always temporary) greying out elements, reformatting others, and even highlighting (parent) elements for which the necessary “system(ic) tag” has not yet been added, i.e. guide the user to possible “leftovers”, to be treated yet for their allegedly wanted “result”, and in order to facilitate this “system tagging”, prerequisite for those transformations, it’s easy to imagine that whenever the user creates obvious “parent” items (just do TWO “new sibling” commands, identical otherwise, but with e.g. return = “just sibling”, and with control-return = “also retrieve, and put into the “system” column, the name of the current “parent” item, as (preliminary) “pole” (or whatever might be a better denomination), and thus, when you create a specific measure, within a measure group, you’ll do it by ^enter/^return, ditto for a region creation within a country, and the special field will automatically be filled with the parent’s name, but whenever you create just a technical, not systematic / taxonomic “child” item, you’ll do it by simple enter/return, being willing to fill it up whenever possible necessity later on will present itself.
And at the end of the day, why not speak of the
TAX
of an item / page / element / whatever you call the records, TAX being short for the record’s “taxonomical identifier”. Once you have those, necessary for your core elements only, your tree(s) being organized by the quite primitive “Adjacency List Model” or by something better (and which would probably not that much show the alleged “limits” of SQLite, or the other way round: even backed by Postgres, “outliners” with the ALM would be as bad as they now are!): Once you have TAX, “outlines” will get their third dimension… and remember, the tax entry would be (just visually) identical to the parent title (since technically, it would be a _tax_ID number, and be then (only) identical to the _record_ID number of its parent, if and when that parent is, also taxonomically, its “natural” parent, and if not, not, but then, in case (and if needed or at least filled-up that way), the title / _record_ID number of its “tax parent”, wherever that one might currently be positioned within the tree. - And between what the user sees and those _tax_IDs, a simple (again indexed) table will make the connection.
So much for some additional details and explanations, as concise as possible for the “message” becoming comprehensible.
Posted by 22111
Jul 31, 2022 at 09:15 AM
In the explanations before, I think a grey zone subsists, it’s what the user would do, in order to transform, i.e. what they would do in their then “work” pane. For one, they would add (or in some cases even change) core items’ “taxes”, i.e. they would change the name, whilst behind the scene, the _tax_ID would be changed, and here and elsewhere, the tax name entering would be “guided”, as “tags” in general would be, by automatic completion for already existing (and equally “taxed”, in case to the “db within the DB”‘s source item) “tax parents” = “tax names”, and of course, here and everywhere, those “taxed” elements being listed in that already mentioned table, any item, or tax renamings (that’s two different things, obviously) would be “transferred” to (better: be visible at) any other “occurrence” (since the IDs remain unchanged anyway).
Then, in this (then) “work pane”, the user would indicate (by shortcuts, making appear special symbols) the “new hierarchy” in which they would want their dataset now to appear, and if in-between, and from the “result pane”‘s visual rendering of the (intermediate) “results”, they see they want it displayed in some other order (at start, deep down or anywhere in-between), they might, within the third, the “construction result” pane, just click on the two elements (ditto with selection and kb) in their now “new”, preferred order, or they could even do this within the result pane.
I’m not entirely sure if the third pane here is really necessary, except perhaps - and even that appears debatable - for indicating what’s finally stored, for a then immediate rebuild of this “view”; since the tool cannot foresee to which “level” deep-down the user wants to transform, it will need, in the then “work” pane, to display the whole (sub-) tree, in order to enable the user to designate even elements deep-down as “relevant for the transformation” (vs. “these blocks / sub-trees are just bulk to be carried along”), but it’s evident that in the “result” pane, the tool could possibly just display a quite “stripped-down”, representation of the result, but then NOT “frame-only” yet since while “working” on it, the user will also need to check where the “non-frame” elements will “end up” then, and if their respective position is accordingly to their wishes.
But then, “when it’s all done here”, for that specific view, the “result” pane could display the “frame-only” view, i.e. just the “taxed” elements, for checking and confirming, “frame-only” meaning “just the taxed elements needed in this specific view”; it’s foreseeable that in some other views, “core” elements in/of this view here will be relegated down into the above-mentioned “bulk”, “beneath” the view construct.
At least I think so, tentatively, and that’s why I said above we would need something “half-way complete already”, in order to have some “working model” from which we can then further refine; I just jotted down the above concept yesterday and this morning, without scribbling trial trees or something, and my spatial imagination / representation isn’t that much developed. But I think two panes, the left (!) one just for the “status quo”, with possible renames and selections-to-trigger, i.e. as sort of a “keyboard to play on”, but otherwise stable, and where you know thus where the notes are!, and the right (!) one (since Western hemisphere, do>result = left>right; probably inversed in some language versions then), equally “playable” for (as said above, especially hierarchy re-ordering triggers), but showing some, simplified, “result”, and then, after check-n-confirm, the result as sparse as it can get, and just the (relevant for this view) _tax_name hierarchy, before that hierarchy, _tax_ID-wise, is then stored, should suffice.
Concurrent working in both panes seems necessary since the user needs a tree they already know, and in which thus they know how to find elements, whilst re-arrangements within the “result” should be possible within the “result” pane - “error corrections” if you want -, since there, again for “spatial representation” reasons, they will be way easier for most users, than within the (at least visual) “source” construct… where on the other hand the user is free to also select additional elements (together with their possible “bulk behind”), in order for them to then be correctly represented within the new construct, within the “result” pane, so in that latter one, the attention should not be turned again on completeness but on clarity, and real use cases will then guide further coding.
Also, the storage of these alternative views is not only of interest for then immediate general access, but it’s also evident that for any further transformation, the user will “load”, into the “source” pane for that transformation, the “appropriate”, already existent view, and from which then the transformation they have in mind, will be rather easy, compared to the possible use of some quite “inappropriate” “source” view.
It’s obvious, too, that most users will very early set out to have two “parallel” “views” to work on, a taxonomic one and a “functional” one, and in the latter one, the question of subsets arises, e.g. for just some legal resources for some legal case, but then to be chosen from the complete available set of resources, and so on - I wrote about this aspect earlier in this forum -, i.e. you can “complicate” the functionality of such a tool almost ad libitum, while it’s necessary to held it as simple as gets, interaction-wise, and my “pane condensation” within my writings here in this thread is a good example of how to do it: think of what is needed, technically, then simplify the user’s work to get to it, to the core, and yes, I said this earlier, too, that means quite some code behind the scenes, so that it gets as simple as gets, for the user. (And the other way round: If the appropriate code isn’t there, it’s up to the user to append, by then even more, external macros, at least some bits of the missing functionality.)
Oh, and above, for Christianity vs. bigotry, I should have mentioned the term of “irony”, but you will have filled up that gap of mine on your own. ;-)
Posted by 22111
Jul 31, 2022 at 09:37 AM
Oh, and it’s not necessary that those multiple DBs within the db system have a common source item, it’s just a convention many “outliner” developers have adopted, and concurrent maintenance of multiple, equally construed “DBs” / tree-forms with the same db system are without problems and will not prevent interlinking, cloning between those different datasets, etc., so with the right “backend”, it would be absolutely natural to have a very first, additional pane (i.e. two tree panes instead of just one), or even more than that, by option (and according to your current use case); just imagine “concurrent hoisting”, i.e. not behind tabs but those tab “contents” visible at the same time, and on a big screen.
This is just a detail and which in no way affects anything I wrote above; I just wanted to clarify since above I presented the common source item as sort of a prerequisite whilst in fact it’s nothing more than a (bad) “standard”, born off developers’ wish to save some lines of code and a single additional, again indexed, column.