Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Texas Cyberthal <texas.cyberthal@gmail.com> [2020-11-21 10:19]:
  :PROPERTIES:
  :CREATED:  [2020-11-21 Sat 12:53]
  :ID:       913ca9e4-17b4-4366-9a35-45838cace538
  :END:
> ***** Hi Ihor Radchenko,
> 
> > I am wondering what you mean by Org's philosophy. Why would it have anything to do with directories?
> 
> Org's philosophy is to have one or a handful of directories without
> nesting of directories.  Users are not expected to have their Org
> files in a deeply nested tree.  Org also prefers big files with large
> trees rather than lots of little files.

Is it? I did not know that. But it is definitely tedious to keep all
Org files in one directory or few sub-directories. That is where 10
Bins paradigm becomes useful or other similar filing software. It is
just good to file it into fixed place with fixed hyperlink that is
easily captured somewhere.

What I mean is when file is filed into

ABC/STRUCT/XYZ/001/2020/11/20/2020-11-20/

is that such link can quickly be captured in some main file like:

* ABC
  :PROPERTIES:
  :CREATED:  [2020-11-21 Sat 12:53]
  :ID:       8459366d-e95e-4a2f-9eac-c093375d733c
  :END:
** STRUCT
   :PROPERTIES:
   :CREATED:  [2020-11-21 Sat 12:53]
   :ID:       5d3b208f-dfec-4916-af7e-be784641d3f8
   :END:
*** XYZ
    :PROPERTIES:
    :CREATED:  [2020-11-21 Sat 12:53]
    :ID:       19705797-19b5-46d4-ab7d-2414589a5e68
    :END:
**** 001
     :PROPERTIES:
     :CREATED:  [2020-11-21 Sat 12:53]
     :ID:       ddf01399-3b6a-40d5-9a8c-55cadd2d08b2
     :END:
***** 2020
      :PROPERTIES:
      :CREATED:  [2020-11-21 Sat 12:53]
      :ID:       5faef432-0abc-4953-bd81-2ffae69ecec1
      :END:

[[file:ABC/STRUCT/XYZ/001/2020/11/20/2020-11-20/file.org][File.org is filed file]]

When such capture is done automatically upon filing then the link may
be reused in other files. 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.

> The rules are written to be straightforward at filing time.  One need
> only consider one object at a time.  Cascade filing means one need
> only compare the object with one directory at a time.  The first match
> wins.  I should emphasize that in the docs.
> 
> Having all your headings jumbled into three huge files sounds like a
> state of permanent intractable overwhelm to me.

That overwhelm I felt myself and found similar way like you Texas to
file the files and I am still expanding into meta-level of organizing
things.

> You are using Hyperscope as your primary PIM but integrating it with
> Org, and it sounds like you're using PostGreSQL and the directory tree
> together somehow.  I don't fully understand it.

My primary PIM is on higher level than HyperScope as HyperScope is
part of PIM which I call CRM or Customer Relationship Management as it
does not manage only my personal information. In the practical sense
it is more or less same thing only that allows work in group. It is
just so similar to various other CRM software around.

HyperScope is not file system. It is dynamical knowledge repository of
hyperdocuments, any kinds of documents. Other similar projects are:

Semantic Synchrony
https://github.com/synchrony/smsn

Hypothes.is Annotate the web, with anyone, anywhere.
https://web.hypothes.is/

GNOWSYS: A Kernel for Semantic Computing!
https://www.gnu.org/software/gnowsys

gstudio
https://gitlab.com/gnowledge/gstudio

Project Xanadu
https://en.wikipedia.org/wiki/Project_Xanadu

Those links I am quickly inserting into buffer exactly by using
Hyperscope. I am just pressing one key W and hyperlink from HyperScope
buffer is creating those hyperlinks above.

In general it is a tree based database that hyperlinks to all kinds of
hyperdocuments. Hyperdocument is also a note in the database
itself. But it can be Org file or any other file regardless where it
is located, be it on the WWW or file system. It can be video that I
have to watch or specific part of video.

Then subtrees or the whole HyperScope database can be expanded into
one Meta Org File if I wish. It is not "export" in the sense but one
could say it is similar to export.

> Clearly a database can do more than a directory tree alone.  The cost
> is that a database is more complex to use and maintain.  So that which
> can be handled by directory tree alone, should be.

File system is database. What I keep in the PostgreSQL database it can
be kept directly in the file system while program can manage various
other relations. There is also EIEIO in Emacs which I found recently
that also may be used as a database and there is GNU Emacs database.

EDB or GNU Emacs database
https://www.gnuvola.org/software/edb/

and various other interfaces to databases.

Database need not be complex. It carries only the structure. I find
it much easier and less complex to define the database table then to
work with program that has to replicate all those algorithms that
databases have built-in.

Database is like storage for custom variables. You have already
defined 10 Bins, the database in that sense could just define more
complexities while program can handle such complexities automatically.

Database does not store files for file system, that is not my
preferred way. It just keeps the structure for filing. Same structure
could be kept with EIEIO or even with defcustom or simple lists. But
when it becomes more complex that is where database becomes useful.

I can keep 100 or 500 people in lists, but searching, indexing, unique
IDs, all those stuff can be handled by the database without me
thinking about it.

Example is with unique Org IDs in the package `org-id`. I do use such
unique IDs. But I have to have the package, somebody has to program
the package and those unique IDs may not be so unique. For example if
I copy the substree I need to take care to change the unique IDs to
something else. If Org file is copied I need to take care that unique
IDs get updated. There is human error involved.

Database can have defined field such as `TABLE_ID SERIAL NOT NULL
PRIMARY KEY` and that is is where I stop thinking about unique ID. It
is unique and it is enforced over all table of items.

If I wish to delete item, fine. If I wish to copy item from one
subtree to other, there will be new unique ID, if I just change the
parent of the item, the unique ID still remains there.

Org development does try to accommodate this principle but it is text
and files are everywhere so I see Org programs try to track the files,
some are not tracked and so on, at some point of time it becomes not
manageable.

In general beyond thinking how a table should be defined there is
nothing so much complex with databases. And that design and planning
is usually programmed so users do not even think about database and
tables.

Your link `template' on the page:
https://treefactor-docs.nfshost.com/

under:

"Here is a template you can use to start your own Textmind. "

is not working, it is asking me to sign up on the third site.

These are all very useful and logical options:

https://treefactor-docs.nfshost.com/2-commands/1-throw/

Myself I write Org files for planning and projects which are then
executed by printing them and carrying such projects in the field. In
that sense the TODO items are always repeated and I do not refile
things, almost never if ever I did so. I do not remember.

Often there are tasks related to people so each person has its Org
file here, I do not mix information pertaining to various people in
Org files. This way I can send whole file to the person for review and
modifications. RCS versioning is enough to keep things simple and to
see differences between the files.

One subject is kept in one Org file. If something is done and not
necessary to be visible it can be archived. More than that I do not
re-file things from one file to other as I simply keep right Org file
for right thing.

Concept of refiling in Treefactor is fine concept regardless of my
personal preferences.

> opinions.  10 Bins is an opinionated directory tree template.

You gave me idea to expand my personal organization into file system
that I can forget about it. 

> Neither requires the other, but they're both part of Cyborganize, my
> overall PIM and publishing system.

Definitely I need to read more about it on your website.


Jean