Re: One vs many directories

[Jean Louis]

* 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.