Date: Sun, 04 May 2008 18:24:27 -0700 From: "Jason C. Wells" <jcw@highperformance.net> To: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> Cc: fbsd_chat <freebsd-chat@FreeBSD.org> Subject: Re: Tired of Hierarchies Message-ID: <481E61CB.5060504@highperformance.net> In-Reply-To: <481E57FC.9030804@gmail.com> References: <481CE0E7.7070900@highperformance.net> <20080504123719.GJ92161@amilo.cenkes.org> <481E57FC.9030804@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Aryeh M. Friedman wrote: > ~ 5. If the system didn't plan for some major catagory it will be > crunched into a sub catagory(s) that do not make very much sense for > example under Library of Congress computer science is under math > (QA76.XXXX) but electronics is under TK510[456].XXXX In this example the call number performs a dual function of identifier and grouping. The ability to lookup the address in a computerized card catalog database mostly negates the weakness of the poor grouping. Because a computer can manage location and grouping in some other fashion, all we really need is a unique identifier. > A very good example all the items above is the current ports system. > In short the more finally cut we make our categories the harder it is > guess/generate the "search key" (either a real key or metaphorically a > mental picture of one). For all the above reasons I would argue for > flatter hieracies with metahierachies overlayed for different purposes > then one typically sees today. The idea of an overlay I think is a very powerful one. The file system hierarchy could simply be one overlay that might be applied by a hypothetical storage manager. An author might use an author's overlay suitable to the author's task. All user's would have to be careful to divorce that idea of "what" they are looking at from "where" they found it. There would multiple disjoint locations in an overlay system that all refer to precisely the same resource. Later, Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481E61CB.5060504>