From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id KDrrL27IuF+jYgAA0tVLHw (envelope-from ) for ; Sat, 21 Nov 2020 07:57:34 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 8C66K27IuF/pCgAA1q6Kng (envelope-from ) for ; Sat, 21 Nov 2020 07:57:34 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F090B94042B for ; Sat, 21 Nov 2020 07:57:33 +0000 (UTC) Received: from localhost ([::1]:41680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgNlz-0006z8-Li for larch@yhetil.org; Sat, 21 Nov 2020 02:57:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgNlL-0006yz-Vv for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 02:56:52 -0500 Received: from static.rcdrun.com ([95.85.24.50]:57931) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgNlJ-0008G3-8H for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 02:56:51 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0013.000000005FB8C83E.00001CD4; Sat, 21 Nov 2020 07:56:45 +0000 Date: Sat, 21 Nov 2020 10:56:36 +0300 From: Jean Louis To: Ihor Radchenko Subject: Re: One vs many directories Message-ID: References: <87y2ive1i4.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87y2ive1i4.fsf@localhost> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Texas Cyberthal , "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.51 X-TUID: IcOZgVTa/Ogt * Ihor Radchenko [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.