|
From: Ali A. <ali...@au...> - 2000-11-25 11:30:08
|
* Rich Morin (rd...@cf...) wrote at 01:50 on 25/11/00: > The "Tree of Knowledge Fallacy" has to do with the mistaken belief > that you can put all of knowledge into a single hierarchy. Anyone > who has ever tried to sort miscellaneous items has run into it: > Lessee now; I seem to have a lot of screws here. Do I put all of > the Phillips-head screws together, sort by length, or what? > > The problem clearly manifests itself in the area of Open Source > software packages. With FileWatcher tracking some 10K packages, > it is totally unreasonable to believe that any categorization > scheme will fit all packages for all needs. Politics aside > (my tree's better than your tree...), different sorting schemes > will always be better or poorer for different searching needs. Heh, I think you're right. I think Help files SHOULD be able to have multiple categories! This really does make sense (although potentially confusing for the user). Should the OMF files though have the ability to have "endless" amounts of categories for a file, or should we impose a limit (i.e. can specify a max of 3 categories, in order from "most appropriate" to "less appropriate" (e.g. for Nautilus we would have 1) Desktop/File Manager 2) Internet/Web Browser 3) Audio/MP3 Player (it does play MP3s!!)) > So, I suggest that we concentrate on things we _can_ control: > > * unique identifiers > > Each package (and each variant and version of same) > should have a unique identifier, so that we can be > clear and unambiguous in referring to it. This is > really the same issue as the database folks have... Yeah, I agree - I disagree with your other mail specifying how to do it. If we want truly unique id's then we just use the 'uuid-gen' utility found on most machines. > * characteristics > > A package can have any number of characteristics (e.g., > keywords) that someone might use to look it up. One > form of keyword is the package's position in a given > hierarchy (e.g., freebsd-ports/devel/pmake). I'm not sure about this. I don't think we should just add in any features that might possibly be useful somehow, so we may as well throw it in now. The OMF file should already have all the metadata necessary for indexing documents - I don't see why we need a generic "characteristics" or "keywords" section > By explicitly allowing for the presence of multiple category > trees, this method is able to incorporate (or even dynamically > add) any number of categorization methods at the same time. I don't think we should have a strict "category" tree. We can just allow people to give each doc multiple categories, but ScrollKeeper should not enforce it! Regards, Ali |