From: Jean Louis <bugs@gnu.support>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Texas Cyberthal <texas.cyberthal@gmail.com>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: One vs many directories
Date: Sat, 21 Nov 2020 10:56:36 +0300 [thread overview]
Message-ID: <X7jINIi1tmzcC2yj@protected.rcdrun.com> (raw)
In-Reply-To: <87y2ive1i4.fsf@localhost>
* Ihor Radchenko <yantar92@gmail.com> [2020-11-21 08:15]:
> > Having a tall directory tree with many leaves and branches is against
> > Org's philosophy.
>
> I am wondering what you mean by Org's philosophy. Why would it have
> anything to do with directories?
Texas will answer on that.
I am just intruding in the conversation.
From Org manual:
"Org keeps simple things simple."
I do think that Org does more than keeping things simple. When it
comes to seriously complex things Org is not there for such.
When there are more than 2000 people related notes, tasks,
calculations, questions arise if such better be kept in one Org file
or multiple Org files in one directory or multiple directories for
multiple Org files?!
With increasing complexities one can see that Org as such is good for
those purposes as written in the manual.
Org mode is not appropriate for meta-level organizing.
The Org paradigm is good for meta-level organizing.
That is where directories come into play.
In my opinion directories should never bother user. User should just
pre-define sets of directories such as: People, Groups, you name it,
and files should be accessible in such directories automatically.
I want Joe Doe's information, I do not need to know where it is stored
to browse to his information. I should be able to say to computer:
"Give me files of Joe Doe" and I would get it. It is 21st century and
we are not closely organized to how it should be.
Org mode paradigm shows that hierarchical tree is useful.
File system is a hierarchical tree.
But people who start working with Org mode will have better
hierarchical system on their file system, then those who don't work
with hierarchical tree of notes and other things.
It means Org mode and its paradigm is teaching people to organize
hierarchically.
But it does not offer meta-level of organization. Where such Org files
should be located? Again we think of hierarchical system, but when
things becomes really complex Org is not there for user as Org keeps
simple things simple. It does not keep complex things simple.
That is where systems of 10 Bins come in. For me it is type of
meta-level paradigm that keeps things organized.
My desire is that base Org package stops its development.
It should define itself and stop being developed due to its achieved
perfection as base system.
The idea is analogous to TeX and LaTeX where I consider TeX being
compact, perfect, finalized system without bugs (author awards people
to find bugs) and LaTeX and others are considered extensions.
TeX - typesetting system
https://www.tug.org/svn/texlive/
In the same way extensions could be added to Org but without base
system being each in a while tackled, changed, modified or
"upgraded".
> If you wanted feedback on this, I believe that Karl Voit's article below
> is relevant. I guess you can even directly contact him if you wish - he
> knows a lot about theory of classification.
>
> https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/
Thank you for the reference, that is subject of my current
research.
Personally I do not find complex folder hierarchies as main
problem. Not at all.
I find that main problem is when each individual is faced with the
problem of organizing and cannot handle complex thing of
organizing. The trouble is exponential to the number of computer users
on the planet.
If we look at not complex organizing then file system organizing can
be easily left to the user for the user to decide on each filing how
and where files are organized. That is what majority of people on the
planet do.
When we come to somewhat raised or complex level of organizing then
one can see that if such organizing is left to the user is that file
system mostly becomes mess. That is where system as 10 Bins come into
play or any such similar organizing system.
For the simple organizing it is better that users is prepared for
complex organizing as time and number of files on the system
inevitably lead there. So it is generally better for population and
computing to switch to better paradigms of organizing
information. Those paradigms have been already designed by Doug
Engelbart and are followed by various software and concepts of
computing.
Doug Engelbart Institute - Boosting mankind's capability for coping with complex, urgent problems
https://www.dougengelbart.org/
On that meta-level of organizing user should rather define some groups
or subjects such as people, lists, groups, plans, movies, etc. Then
user should define various possible relations between each other. And
template for such relational file system would be given onto each
computer and could be configurable by every user.
Then when it comes to filing of the files user could say:
$ file-file this-file.org
User would answer few questions, like if to file by person, or by some
list, or movie subject, user could select to which movie genre that
movie belong. File would be filed and WHERE it is filed would be
irrelevant for the user. User could find the real path to the file,
but because it is not relevant for the user it would not be of much
importance.
When user wish to access the file, one would find it as:
$ find-file
in the next step user could decide:
- to search for file by using its name
- to search for file by subject, such as movie
- to search for file by genre or sub-group(s) of the subject
- to search by people, groups, lists, etc.
Then file would be found and it would not be relevant if the file is
located in x/x/x/x/x/x/x structure on the file system.
In general when user is searching for the file, when such file is
located file could be launched, edited, viewed or played, or shared to
other people.
How the file system is organized would be left to the algorithm on
computer.
There would be no need for user to browse the file system but in
exceptional cases.
Reference:
https://www.dougengelbart.org/content/view/110/460/#2b1a1
" Every object that someone might validly want/need to cite or
otherwise access should have an unambiguous address, capable of
being portrayed in a human readable and interpretable manner. Most
common existing spreadsheet programs have provisions similar to
this for cell addressibility." 2b1a1
The referenced link demonstrates itself: 110/460/#2b1a1 is the
unambiguous address capable of being cited or referenced.
Both filing and finding of files would be kept as history. This is for
hyperlinking and referencing purposes.
After filing of a file, the history items can be used as a reference
for immediate classification. I have filed the file, but did not
designate the name of the file and other attributes. I need those
attributes for later referencing and searching.
$ file-file this-file.org
would automatically create a hyperlink to that file and hyperlink
could be kept in history. If there is some central dynamical knowledge
repository such hyperlink could be automatically inserted into the
database (DKR).
About Dynamic Knowledge Repositories (DKR)
https://www.dougengelbart.org/content/view/190/163/
Side note: Org file is one type of dynamic knowledge repository.
Then that same hyperlink could be reused in many various Org files. Or
hyperlink in the Org file could just point to the DKR hyperlink, this
way the eventual change of location of the file would not affect many
Org files. All Org files would be hyperlinking to meta-hyperlink that
tells where the file is really located.
When searching for files by any manner, I should also be able to
quickly obtain hyperlinks, as maybe I wish to place such in the list
without me having to search for same file again.
After:
$ file-find
I would find the file but have hyperlink to the file ready in memory
or history to place it in Org file or any other file or database
collection. Or I should be able to share it with people.
I rather expect Org mode to have similar form as OPML so that every
atom or object in the Org file may get its reference.
Example is that I can easily hyperlink to headings but I cannot easily
hyperlink to specific list items under headings. And I cannot easily
link to paragraphs. This is because Org file structure is not finely
grained. I wish it could be so, but it isn't.
For this reason I am considering to convert some Org files that are
useful for referencing to personal structured meta-level dynamic
knowledge repository. org-id tries to handle these problems of
complexities but also makes Org files less readable.
Now back to reading Karl Voit's work.
next prev parent reply other threads:[~2020-11-21 7:57 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-21 0:33 One vs many directories Texas Cyberthal
2020-11-21 5:13 ` Ihor Radchenko
2020-11-21 7:56 ` Jean Louis [this message]
2020-11-21 8:31 ` Texas Cyberthal
2020-11-21 9:29 ` Marvin ‘quintus’ Gülker
2020-11-21 10:21 ` Jean Louis
2020-11-21 15:00 ` Texas Cyberthal
2020-11-21 16:08 ` Jean Louis
2020-11-21 15:03 ` Dr. Arne Babenhauserheide
2020-11-21 15:45 ` Texas Cyberthal
2020-11-21 17:12 ` Jean Louis
2020-11-21 18:01 ` Texas Cyberthal
2020-11-21 18:57 ` Jean Louis
2020-11-22 6:36 ` Ihor Radchenko
2020-11-22 7:20 ` Jean Louis
2020-11-22 8:32 ` Ihor Radchenko
2020-11-22 8:56 ` Jean Louis
2020-11-21 22:36 ` Dr. Arne Babenhauserheide
[not found] ` <CAMUm491Psp0u5JKyGROP6M=UfAcvOLTtOKAD1rOearV+KxgYdQ@mail.gmail.com>
[not found] ` <87r1olfvh4.fsf@web.de>
2020-11-23 9:50 ` Texas Cyberthal
2020-11-23 13:17 ` Jean Louis
2020-11-23 14:16 ` Ihor Radchenko
2020-11-23 18:08 ` Is Org really so simple? Jean Louis
2020-11-23 20:41 ` Tom Gillespie
2020-11-24 5:06 ` Jean Louis
2020-11-26 3:08 ` Ihor Radchenko
2020-11-26 8:57 ` Jean Louis
2020-11-29 7:20 ` Ihor Radchenko
2020-11-29 16:22 ` Jean Louis
2020-11-26 18:07 ` Dr. Arne Babenhauserheide
2020-11-26 23:09 ` David Rogers
2020-11-27 0:43 ` Tim Cross
2020-11-27 2:56 ` Jean Louis
2020-11-23 16:07 ` One vs many directories Texas Cyberthal
2020-11-23 19:20 ` Jean Louis
2020-11-24 7:55 ` Ihor Radchenko
2020-11-28 16:16 ` Jean Louis
2020-11-28 16:33 ` Christopher Dimech
2020-11-25 6:57 ` Texas Cyberthal
2020-11-25 9:51 ` Jean Louis
2020-11-25 10:39 ` Texas Cyberthal
2020-11-25 11:02 ` Jean Louis
2020-11-26 16:04 ` Texas Cyberthal
2020-11-26 17:31 ` Jean Louis
2020-11-27 9:00 ` Texas Cyberthal
2020-11-27 10:45 ` Jean Louis
2020-11-28 8:18 ` Texas Cyberthal
2020-11-28 10:09 ` Jean Louis
2020-11-29 6:18 ` Texas Cyberthal
2020-11-29 6:53 ` Jean Louis
2020-11-30 7:35 ` Texas Cyberthal
2020-11-30 7:50 ` Ihor Radchenko
2020-11-30 10:25 ` Texas Cyberthal
2020-11-30 10:57 ` Jean Louis
2020-11-30 12:27 ` Ihor Radchenko
2020-11-30 12:28 ` Ihor Radchenko
2020-11-30 19:00 ` Jean Louis
2020-12-02 2:56 ` Ihor Radchenko
2020-12-02 6:14 ` Jean Louis
2020-12-02 7:23 ` Ihor Radchenko
2020-11-21 16:55 ` Jean Louis
2020-11-21 22:48 ` Dr. Arne Babenhauserheide
2020-11-22 0:48 ` Jean Louis
2020-11-22 2:47 ` briangpowell
2020-11-22 17:55 ` Jean Louis
2020-11-21 6:12 ` Palak Mathur
2020-11-21 9:04 ` Jean Louis
2020-11-21 6:36 ` Jean Louis
2020-11-21 7:17 ` Texas Cyberthal
2020-11-21 9:53 ` Jean Louis
2020-11-21 10:15 ` Tim Cross
2020-11-21 11:18 ` Jean Louis
2020-11-21 14:44 ` Texas Cyberthal
2020-11-21 15:45 ` Jean Louis
2020-11-23 5:40 ` Ihor Radchenko
2020-11-24 9:00 ` Jean Louis
2020-11-24 9:45 ` Eric S Fraga
2020-11-24 9:51 ` Jean Louis
2020-11-24 11:42 ` Eric S Fraga
2020-11-24 13:13 ` Diego Zamboni
2020-11-24 13:49 ` Jean Louis
2020-11-24 17:02 ` Jean Louis
2020-11-24 18:50 ` Dr. Arne Babenhauserheide
2020-11-24 18:58 ` Jean Louis
2020-11-25 6:39 ` Tim Cross
2020-11-25 12:38 ` Local variables insecurities - " Jean Louis
2020-11-25 13:05 ` Eric S Fraga
2020-11-25 13:13 ` Jean Louis
2020-11-25 13:58 ` Eric S Fraga
2020-11-25 14:07 ` Jean Louis
2020-11-25 20:54 ` Tim Cross
2020-11-25 22:09 ` Jean Louis
2020-11-26 2:06 ` Tom Gillespie
2020-11-26 5:06 ` Jean Louis
2020-11-26 5:31 ` Jean Louis
2020-11-26 6:18 ` Tom Gillespie
2020-11-26 9:10 ` Jean Louis
2020-11-26 11:44 ` Detlef Steuer
2020-11-26 12:06 ` Jean Louis
2020-11-26 5:34 ` Greg Minshall
2020-11-26 5:49 ` Jean Louis
2020-11-26 8:39 ` Christian Moe
2020-11-25 8:10 ` Dr. Arne Babenhauserheide
2020-11-25 8:36 ` Local variables liberties Jean Louis
2020-11-24 20:11 ` One vs many directories Tom Gillespie
2020-11-24 20:39 ` Tim Cross
2020-11-25 4:54 ` Jean Louis
2020-11-25 5:54 ` Tim Cross
2020-11-25 7:01 ` Local variables issue - " Jean Louis
2020-11-25 5:06 ` Jean Louis
2020-11-25 7:00 ` Tim Cross
2020-11-25 8:23 ` Security issues in Emacs packages Jean Louis
2020-11-25 9:07 ` tomas
2020-11-25 9:26 ` Jean Louis
2020-11-25 10:41 ` tomas
2020-11-25 22:46 ` Tim Cross
2020-11-25 23:07 ` Jean Louis
2020-11-25 23:39 ` Tim Cross
2020-11-26 5:24 ` Jean Louis
2020-11-26 6:46 ` Tim Cross
2020-11-26 5:29 ` Greg Minshall
2020-11-26 5:53 ` Jean Louis
2020-11-26 6:35 ` Tim Cross
2020-11-26 12:27 ` Greg Minshall
2020-11-26 22:20 ` Tim Cross
2020-11-27 2:19 ` Jean Louis
2020-11-27 4:42 ` Greg Minshall
2020-11-25 4:44 ` One vs many directories Jean Louis
2020-11-25 10:19 ` org-sbe to automate some source block executions Jean Louis
2020-11-25 11:39 ` Ihor Radchenko
2020-11-25 15:06 ` Jean Louis
2020-11-25 11:46 ` One vs many directories Jean Louis
2020-11-25 13:07 ` Eric S Fraga
2020-11-25 13:14 ` Jean Louis
2020-11-25 13:12 ` Ihor Radchenko
2020-11-25 13:32 ` Jean Louis
2020-11-24 18:47 ` Dr. Arne Babenhauserheide
2020-11-24 18:54 ` Jean Louis
2020-11-25 8:14 ` Dr. Arne Babenhauserheide
2020-11-25 8:46 ` Jean Louis
2020-11-25 11:46 ` Ihor Radchenko
2020-11-26 12:47 ` Jean Louis
2020-11-26 13:27 ` Ihor Radchenko
2020-12-02 10:12 ` Jean Louis
2020-12-02 9:49 ` Jean Louis
2020-11-26 3:47 ` Ihor Radchenko
2020-11-26 3:32 ` Ihor Radchenko
2020-11-26 11:58 ` Jean Louis
2020-11-29 7:56 ` Ihor Radchenko
2020-11-29 17:57 ` Jean Louis
2020-11-21 13:41 ` Jonathan McHugh
2020-11-21 14:04 ` Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X7jINIi1tmzcC2yj@protected.rcdrun.com \
--to=bugs@gnu.support \
--cc=emacs-orgmode@gnu.org \
--cc=texas.cyberthal@gmail.com \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).