Current PIM state
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Jan 17, 2022 at 02:33 PM
This is a spin-off of Lucas’s
“Posted by Lucas
Jan 15, 2022 at 02:31 PM
Interesting. For what it’s worth, now that I had my onboarding session, I’d like to retract my earlier critical comment about Heptabase. I was highly impressed both by the developer and the software. The only issue is that, for the software to really be useful to me, I would need more flexibility with engaging with individual blocks, rather than just engaging with individual “cards”. But the general concept of cards that can appear on multiple boards is interesting and seems to be well executed.”
= https://www.outlinersoftware.com/topics/viewt/9273/30 (on top of page 5 in that thread):
Almost 100 p.c. of “contributors” to this forum are “bac+4” (as they say in France), at the VERY least, and though…
And then, then and again, there’s some SMART intervention from just ONE of the “contributors”; yours’s one-of-those, rare “gems” here.
While more than 90 p.c. of people here don’t even understand my - particular, but very evident though - sense of humour, some of the “contributors” are even outright mean, and above all, I’ll always remember the “contribution” of some U.S. lawyer - he didn’t “contribute” for some time now, and he might being approaching his 80 years -, almost 10 years ago, and who asked for me, after I had contributed - without quotes this time - some quite deep analysis of IM, conceptionally-wise-only, that’s true, not yet presenting functional SW, who asked for me then… to be silenced.
And indeed, and that’s an idea I’ve had cherished for many years now, in-between, the all-time “link problem” has never ever been resolved, since, according to the prevailing circumstances of the situation - and which even could change anytime after! -, not only single “items” should be able to be “linked” (in any, 1-, 2-way…, and of subordination, as equal, as parent…), and not only SET groups-of-items, i.e. “parent-items” of wherever, and “as-they-currently-are”, but, all our “IM” being forever plastic, for new needs, and even for changing “old” ones:
We’d also need, and in any situation, “links” to “plastic sets” of “information-already-there”, and obviously, such things can, and will, be realized by some elaborate AI, but whenever we try to code IM nowadays - and I speak for ALL of the relevant, pertinent “PIM” developers here -, we’re, very unfortunately, at an almost total loss how that could be done…
and yes, technically, it would be possible to devise db tables, and the necessary routines, which would then allow for just (manually) selecting a sub-group of some “linked” sub-set” (i.e. some “sub-tree”), at any other “position” within the (alleged) “tree”
(which, in fact, as soon as “clones” appear in it, will become a net, technically speaking, albeit the simili- “tree” representation tries to preserve it in some “manageable” state for us humble humans; cf. my comments, in this forum, on TB’s so far completely unfruitful tries to overcome this brain-vs.-graphics problem),
... but what then, whenever the needs on your “target position” will vary, even quite imperceptibly, and/or if the add-ons - or even retreats?! - on the “original position” will change the situation?
But on the other hand, if there occur factual (e.g. legal?!) changes upon (parts of/in the “original” dataset, should they be propagated automatically, and if yes, very probably accompanied with some “update-and-previous-state” info indeed? (And for legal info “updates”: which one of them would then to be applied, which other ones would be irrelevant though for “pending” cases?)
Hence, we’re in the focus of IM’s deeper but real problem here, and yes, it all could, even currently, technically done with databases, but the - “manual”, “visual” maintenance of it all would ask for extreme efforts on the side of the “maintenance personnel”, which, currently and on its turn, would need to be quite outrageously qualified in order to do-it-all quite-only-right, so…
And here’s the short version: Yeah, the core of IM is how to “manage” non-standardizeable subsets, both “here-and-there”, i.e. on any “target” (i.e. “project”, “case”) position within the global dataset, as, and especially, within the “source” material, i.e. some sort of - equally, already, “perfectly”, i.e. optimally-by-any-standards (and incl. “cloning”), organized “original”, overall “take-it-all-from” taxonomy.
And that’s why I had alleged, in this forum, and even years ago, that without AI, and which would only be available to the “big players”, the question of “ideal PIM”, or then, IM for “workgroups” or other multi-person identities (i.e. “corporations”, “administrations”), can’t be resolved anymore…
And then, there’s always the problem that those “big players” are “politically biased” - as has become obvious, even for any “retarded”, during the last 24 months or so…
not even speaking of the even more predominant problem that those “big players” do not have any interest whatsoever in empowering lesser “players” to become “smart”, too.
I, personally, had been already aware of all this, or at least had become aware of it within the very next months, when and after that U.S. lawyer, very early in the “Tenths” of our millennium, asked for - mine or any other’s - conceptual contributions within this forum not being allowed anymore.
And no, I don’t follow any non-full-equality-for-anybody “agenda” whatsoever, but your common-and-hilarious over-reaction to my hint at iPad being originally a female, sanitary product had been so over-the-top that I simply couldn’t refrain from then also tickling the Middle-East way of, even today, treating women… which I judge, and have ever, in 70 years, judged… appalling.
But as for iPad and consorts, well, the fact (sic!) that that “corpse-of Cupertino”‘s heird really LOVE to “get” - avoiding the term of “stealing” here - data, and, especially, to CENSOR data… well, that’s proven now… whilst I had told you so, in this forum and elsewhere, even around ten or more years ago.
And yes, I understand the “need” for subscriptions WHEN, and only when, it’s about some tool you’ll do all your work in, 12 or more hours a day (as I currently do within UR, with the - necessary! - help of thousands of lines of AHK code indeed, without which I would be at complete loss even there-in), AND when that tool is really in so-called “active development”, but beyond that, very special and very rare, situation, you’d be a fool to rent sw, instead of buying it, but that’s just my, very humble, opinion again.
And then and after all, TIME is a big, very big, factor, before - reliable?! - AI could step in: creating clones takes some time in most - well: all-I-know-of - tools, so any try to “do-it-manually-but-as-it’s-at-least-currently-needed” remains to be a so-called “nightmare”.
But then, in order to not only “serve stones”: Try to use “tree formatting”, within your “sources”, in order to at least speed up your - original or later-on - “finds” in-there… and you can also do it similarly, in most of today’s file managers, for your NTFS stuff: “hidden” = bold, “system” = blue, “hidden&system;” = bold-‘n-‘blue… that’ll help you a lot, out of your current sea-of-data (of course, you should first write the necessary macros in order to toggle your files “hidden” (1-key) and “system” (2-key, i.e. some key with modifier)).
Posted by 22111
Jan 17, 2022 at 03:05 PM
Correction, on top of page 7 (not:5) of that thread. And I had inadvertently left out an important precision:
For the time being, whenever your PIM or whatever allows for “life cloning” (i.e. the replication of sub-trees, incl. the automatic update of “updates” within the “original” sub-tree), try to re-format the items / sub-trees in that cloned sub-set, differently from their original formatting; some PIM might come with the technical prerogatives necessary for that (i.e. with formatting attributes for cloned sets, different from their original formatting); that way, you could manually maintain a “pertinent here” subset at any “target” position in your data net.
Posted by Skywatcher
Jan 18, 2022 at 09:24 PM
Ok