Re: [emacs-humanities] Paper Zettelkasten safety [was: Why Emacs-humanities?]

[Jean Louis]

* Christian Tietze <me@christiantietze.de> [2021-06-10 10:54]:
> Jean Louis <bugs@gnu.support> writes:
> > Thining about unique ID is not there. There is unique ID automatically
> > assigned by the database, there is automatically assigned "date
> > created", at any modification there is "date modified", at any
> > creation or modification there is "user that created it" and "user
> > that modified it" as in a collaborative system multiple users can work
> > on the same object.
> 
> Sascha and I at zettelkasten.de may sound like we insist a bit too
> much on the unique ID. If you model your knowledge database in a
> relational SQL database, that's a perfectly fine implementation as
> you just described: the fact that you can work with it is the
> ultimate test. SQL row ID references are a natural match.

> But with databases it is like it is with backups: you should be
> testing the worst case some day. It might be advisable to look into
> ways to export the SQL database into another format and retain the
> cross-connections. It's all baked into the text of a paper note or a
> plain text note, so this is unique to digital database
> systems. (Betting on SQL to not go away isn't a very risky bet,
> though :))

Unique ID in any form is definitely very helpful. Relational SQL
databases are inherently similar or same to Zettelkasten method. I had
no problems understanding it. 

The unique ID is assigned at run time, later it remains as a value of
ID column and unless user change it (it is possible) they are more or
less static. Permissions in the PostgreSQL database could define that
user cannot change the ID.

Thus exporting it as SQL backup always retains the unique ID as well.

Design of database tables is not automatically assigning unique ID to
each entry. I have been following the GeDaFe design and GeDaFe is
inherently same to Zettelkasten methods as it asks for each table to
have a column named TABLE_id with the unique ID as that allows easy
referencing to other tables. My design is same for last 15 years or
more, as it follows principles given by GeDaFe.

GeDaFe - PostgreSQL Generic Database Interface
http://gedafe.github.io/doc/gedafe-sql.en.html 

There can be many database tables, like people, accounts, sms,
etc. and each such table must have people_id, accounts_id, sms_id,
etc. That allows easy referencing including the usage of completion
functions in Emacs. 

Here is the example. This is editing form #1

- table: hyvoices
- hyvoices_id = 4

The view is following:

                           ID   4
                 Date created   "2021-06-02 16:28:01.847349"
                Date modified   "2021-06-08 21:22:24.412268"
                 User created   "maddox"
                User modified   "maddox"
                  Voice theme   "Default"
                         Name   "Welcome to Hyperscope"
                         File   
"~/Programming/emacs-lisp/Hyperscope/voices/theme-01/2cc34472-9318-4004-8473-8f791b3f3c63.wav"
                  Description   nil


Now some columns like "Voice theme" above are references to foreign
table, in this case to table `hyvoicethemes'.

If I press J for jump on that line `                 Voice theme
"Default"' I am moving straight to table `hyvoicethemes' with the
referenced ID number 1. The ID is not visible in the above editing
form, it is stored invisible. 

The form #2
                           ID   1
                 Date created   "2021-06-02 15:11:06.643546"
                Date modified   nil
                 User created   "maddox"
                User modified   "maddox"
                         Name   "Default"
                  Description   nil
                    Directory   nil

and if I would press C-u J for jump in the form #2 I would go to the
list of items in the referenced field of the form #1, which looks
like:

------------------
 ID         Name
------------------
 1          Default
 2          Something else, etc.

The Zettelkasten method asks for references to rather be listed on
the bottom of the entry. In the above example the references are in
the entry itself, intertwined with column values. If reporting is
required it is not hard to put references on the bottom, as there may
be unlimited number of number of reports.

Exporting SQL results from a PostgreSQL is easy as many good formats
are built in, so there is: asciidoc, csv, html, latex,
latex-longtable, troff-ms; thus converting to paper or PDF is very
easy and references to other related objects could be as well printed
on the paper. IMHO, the system I am working on is most similar to
Zettelkasten method.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/