By all means I agree with the principle presented by Karl Voit while not with the integration. IMHO, the principles could help many people: file tagging, using dates, additional designations (appendfilename).
Your integration is useful for you and people who learn about it. But it is not necessarily well usable or accessible.
Comment on: https://karl-voit.at/2020/05/19/RelFS/
My side I am using since almost 2 decades a database for all kinds of notes. Since few months, I have been integrating the principles of Doug Engelbart.
One of elementary objects in a dynamic knowledge repository system may be a file (or parts of the file or anything else).
When reading of Nayuki idea on tag based file system it reminds me of the dynamic knowledge repository where all things may be indexed, stored, related to each other. Instead of a new file system, the dynamic knowledge repository may, in case of files, represent a layer where relations as described by Nayuki may be stored.
One of principles of the dynamic knowledge repository is that object should be rather static, once placed, it need not move anywhere. What is more important is that meta data are related, described, easily found.
In my example I am using PostgreSQL database. A file has to be indexed, let us say with tags, or other attributes. I need not ever change the filename, it may be named as one wishes.
-
Press key on a filed in Dired or multiple files marked in Dired. Same could be done from command line, or form file manager.
-
All files are indexed into the database, and I can choose under which set (parent) they are indexed.
-
Each set or parent and each file has its ID number. Once indexed, they stay on the file system.
-
The file attributes are not stored in the file name but in the layer I spoke about, in the PostgreSQL database. There can be date created, modified, there can be name of curator, name of author, expiry date, tags without limit, any kind of attributes in lisp hashes or PostgreSQL arrays. Any type like mime type could be stored there, there is name for the file which is rather like a title, human readable name. The file path is stored as well, any kind of arguments, description, text that goes along with the file, its parent node ID, permissions, revision, number of pages, its language, time length, width and height for media, hash, PGP signature, any account (entity, company, organization, financial account) to which file is related (like Graz Opera, there can be contact assigned to file, any business as subset of activities from account (one company can have multiple businesses), opportunity, it has priority, it can have publisher, it can be related to a group of people, group of accounts, or groups of anything, it may be assigned to a group as a TODO, assigned to single individual, it may be active or not, actionable or not, it may have related files, template, website where it should be published, it can have license assigned, its website slug, it can have a report, and internally it has the full text tokens for quick PostgreSQL text search.
-
By using Emacs tabulated list mode it is quite easy to tag all of the files by particular tag, add or remove tags, or add or remove any of the mentioned relations.
Process of indexing files into the dynamic knowledge repository is nothing more complex, rather less complex then using numerous scripts from a file manager combined with the terminal as described on https://karl-voit.at/demo-filetags-intro/
It is not a file system, but it helps with quick location of information.
When using a system like RelFS, one of the biggest benefits would be a smooth file retrieval process. Having the advantage of multi-classification, the user doesn’t need to remember storage paths. Instead, she would be able to retrieve information by filtering using tags.
In this dynamic knowledge repository implementation, I do not need to know where are files located, as they are indexed and computer is helping me locate.
It is interesting that PostgreSQL is collaborative multi user database, thus any remote users with permission could locate the same file, it magnifies the knowledge access exponentially, and personal well indexed file system on computer becomes collaborative group enhancement tool.
How am I retrieving files? I can search for them or I can look into lists.
Searching is done by key binding, and I can equally search from a console or terminal or from Emacs, and from WWW browser or other GUI in future. It does not need much of adaptations as those are SQL queries.
Example is that I just clicked C-c r h (my search key binding) and I looked up for your name Karl Voit. I really forgot if I have ever put your name in the system, but there it is. And I can find 2 entries, of the WWW type:
-
Memacs: https://github.com/novoid/Memacs
-
My Folder Hierarchy https://karl-voit.at/folder-hierarchy/
Would there be an entry with "File" type, I would equally find it (provided it was indexed).
I can search or list for files or any other types in the dynamic knowledge repository by using any kind of above explained relations.
Here is something I would like to disagree with:
If the proposed file system only supported simple tags, then tag queries are baked into the API. But with complex and custom tags, how do we express queries regarding files, field values, and references? It is likely that the full power of the relational database model is required to express useful queries.
I, too, agree to this statement. If there are only tags and no storage paths, I’d need a sophisticated search functionality. At least when navigation using my TagTrees is not an additional retrieval option.
From my experience with many different levels of computer users, I don’t think that using SQL would be acceptable to the large majority of people. And what use is a nice tag-based system when retrieval tasks require advanced technological skills?
To me, your statement contradicts your own technical solution on how to tag files, as you have already provided pretty complex tools, and you had to program it. So it is with any SQL based program, somebody has to program it. Users need not know about the SQL. That is why I strongly disagree to that statement.
And I also strongly disagree that SQL is more difficult to learn for complex queries. Users of the dynamic knowledge repository need not however, know nothing about the SQL, but they can. What is important is that they learn how to insert files, tag them, related them and so on.
Here is my function for full text PostgreSQL search, bound on the key
C-c r h:
(defun hyperscope-search-ts-query (query)
(interactive "sText search query: ")
(let* ((query (split-string query))
(query (string-join query " & "))
(sql (format "SELECT hlinks_id FROM hlinks WHERE hlinks_tokens @@ to_tsquery('%s')" query))
(id-list (rcd-sql sql hs-db)))
(hyperscope nil nil nil nil nil id-list)))This function probably does not handle well string escaping, that is something to do yet. But what it really does well is to locate files by whatever terms entered. You may see the screenshot how I found those 2 items related to your name. I could launch the WWW hyperlink by a key.
What is the program code is rather concern of programmer, and not the final user who only needs to quickly access information. Thus using SQL in this type of information building processes is nothing more complex or difficult then using Python in your explained file tagging methods.
This page published on: https://hyperscope.link/3/7/1/2/7/Comment-on-https-karl-voit-at-2020-05-19-RelFS-37127.html
Thanks,
Jean Louis
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
Related hyperdocument tags
GNU Free Documentation License
Copyright © 2021-05-01 17:54:37.904992+02 by Jean Louis. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License"