Date: Sun, 04 May 2008 22:20:22 -0400 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> To: "Jason C. Wells" <jcw@highperformance.net> Cc: fbsd_chat <freebsd-chat@FreeBSD.org> Subject: Re: Tired of Hierarchies Message-ID: <481E6EE6.4090404@gmail.com> In-Reply-To: <481E61CB.5060504@highperformance.net> References: <481CE0E7.7070900@highperformance.net> <20080504123719.GJ92161@amilo.cenkes.org> <481E57FC.9030804@gmail.com> <481E61CB.5060504@highperformance.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason C. Wells wrote: | 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. | One issue you would need to consider in such a system is how to ensure that the "address" in one hierachy doesn't interfere with the address in an other hierachyy (the two are allowed to vary independantly). Two examples pop to mind immediatly URL's and Email addresses. Specifically both refer to a resource that theortically has nothing to do with it's physical location but only on it's conceptual location. For example I should give a damn what machine someone uses to receive mail on in order to send them mail, namely how many times I switch ISP's my address would stay "aryeh.m.friedman" (for example) [notice no @dns]. Back in the late 90's I offered a service like this http://web.archive.org/web/*/http://www.atless.net but sadly not enough demand to keep it going. The URL issue is the same. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgebuYACgkQk8GFzCrQm4CgFQCfUBDce8iqlJnGcRban3OIaWLW l5AAoNI9KVWNSnQ+9DJA/aKd/zPGyNar =MnXY -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481E6EE6.4090404>