Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Texas Cyberthal <texas.cyberthal@gmail.com> [2020-11-21 17:45]:
> Hi Jean,
> 
> > By using the Meta Org File user automatically creates an index of
> > filed files and can search for the file in the Org file itself and
> > open the file from the Meta Org File without knowing where the
> > file is really located.

> Such a set of links could easily grow out of date if paths change, and
> I wouldn't want to maintain it.  If the paths never change, then I
> would memorize the paths and linking them would be slower than Dired
> walking to them.

By principles of Doug Engelbart, once file is filed, it should be
there and nowhere else, it becomes more or less static. Then you have
some kind of DKR or dynamic knowledge repository that tracks where
such files are. Let us say that DKR provides you with the hyperlink
"K12A". This link is is then referenced from all other files.

If the underlying location of the file changes, but it should not, all
the hyperlinks remain always the same.

> I do have a method called "Zinks" for managing UID links.  It permits
> paths to change without breaking anything, both target and source.
> However, in the vast majority of cases I find it much easier to just
> walk the directory tree.  I doubt one can appreciate how useful a tree
> synced to one's mind is until one has experienced it.  The tree adapts
> to the mind and vice versa.

That is good and useful.

While I do order things in a tree it is not that I think of those
tree in hierarchical sense. By habit I could maybe remember but
because it is not necessary to remember, it is not useful, then I
don't.

What I remember is the sub-tree name. For example Emacs or Emacs Lisp,
then I just do the helm or ivy or other completion and find the
subtree. From there on I browse for information, file it, open up or
launch hyperlinks. It is not browsing the tree, it is more direct jump
to the relevant part of the three.

And if hyperlinks are represented as (hyperscope 123) then regardless
if such link moves from subtree to subtree or underlying information
changes somehow the reference to that link remains always same (as
long as ID is always same).

> There's no need to know the exact locations of files; walking there
> is informative and useful.  Or, for the trivial paths, walking is so
> quick that it is faster than searching.

That is good and isn't it general way of sorting things? I guess that
general computer users may not be aware that they could make nice
hierarchical tree of directories. System that users are offered are
file managers and such are way to abstract for today's users. Back in
time we did not have that many files, today we have loads and loads of
files. Those programes named file manager do not manage anything by
themselves. And they should.

User should choose to file a file, and by any type of paradigm, user
would maybe answer just 1-3 questions and file would be filed into
appropriate place. It could be retrieved as fast as filed. That would
be semi-automatic file management.

If all files would have its meta-data then automatic file managemet
could be possible. Then it would be known who is author, what is
subject or tag of the file, what is its title, date of writing it,
permissions (not file permissions but access permissions) and
similar. Then program could file those files automatically.

For images named IMG_2020111012345.jpg is possible to parse image
names and if not image names then the built-in EXIF data and file all
images by their dates automatically. Bunch of images coming from
camera and they need to be sorted by date so in that case it can be
automatic.

Text files do not have its meta data. Org files could be said to have
as there is TITLE and AUTHOR, DATE. But there is no rule for meta
data. Good set of principles or rules when creating files could create
meta data and by meta data files could be automatically filed and
easily retrieved.

> Search spawns distracting mismatches to read, whereas walking the
> tree progressively narrows scope in a mentally comfortable way that
> focuses the mind while error-checking each step.  It's very
> comfortable to reach the destination and be confident from the
> process that I'm in the right place.

That is exactly same mental concept that I use. It becomes pleasure as
well. I could watch videos of other similar creators as you and I can
feel the pleasure in their voices and I can understand the piece of
mind when files are sorted. Unsorted files do bring mental mess in the
person's mind.

> > File system is database.
> 
> Barely.  Databaseness is a gradient with file system at one end and
> PostGres at the other.
> 
> Plain text and file system are the computing foundation.  The largest
> and best set of tools apply.  Departing from them loses much.

I know in computing we say "database" for those more sophisticated
databases. By definition from Wordnet:

* Overview of noun database

The noun database has 1 sense (no senses from tagged texts)
1. database -- (an organized body of related information)

Thus database can be in any form. It need not be special so much
special software. It need not be software and digital data at all, it
can be paper database.

Simple text file can be excellent database for contacts for as long as
editor provides search capabilities and there is some kind of
organized way of putting data inside.

> I do intend to integrate databases into Cyborganize with Dbmind, but
> have barely thought about it yet.  Cyborganize should run fine without
> any database, but of course database is extremely useful for business
> etc.

Maybe complex database is not needed. As I said there are various
approaches and it can be all simple.

A database can be also simple LISP data structure, it could be list of
hashes securely saved on the file system with possibility to add,
modify, delete records. Multiple databases can be made this way for
multiple subjects, let us say PEOPLE, GROUPS, LISTS, etc. Then
underlying file system can follow the defined structure.

> I just don't think paths need to be input into the database.  The
> strength of the database is freedom from the file system.  It should
> focus on the things a file system can't do.  For example, querying all
> the people who work at X company, or who live in Y country.

File system can be used for the same:

- symlink `People/Joe Doe` to Countries/USA/FL/Miami
- symlink `People/Joe Doe` to Groups/Emacs Users/
- symlink `People/Joe Doe` to Companies/USA/PROGRAMMING INC/

To find the information:

locate -A "Joe Doe" PROGRAMMING

or

locate -A "Joe Doe" Miami

or just

locate FL/Miami

By symlinking into various attributes you can get selections easily.

> Duplicate Org IDs aren't a problem in my experience.  Noticing their
> existence is a good way to reconcile the split after the dust of
> execution has settled.  An Org workflow shouldn't generate lots of
> duplicate links.

It should not but it does.

Projects are repeatable sometimes. Need not be single person
projects. Project that I do may have unique IDs and I have to assign
same project to ABC number of people. Then I copy the subtree into the
file of that person. Unique IDs are also copied. Of course it is
manageable if I create some functions to delete and regenerate unique
IDs.

What is handy with unique IDs is that emails and threads with tasks
assigned by email, containing the unique ID, can easily be located.

> One that does probably indicates overuse of both links and heading
> duplication.  If one really does need lots of unique IDs, it's
> probably a sign to move to a heavier database than Org.
> 
> I'll fix that link.  The correct URL is
> https://github.com/cyberthal/Textmind-template

I have cloned it and I see it is something familiar to you, not that I
can understand your mind flow. In general I find any such system of
organization useful for people to learn from, to adopt it or develop
their way of thinking and managing files.