Re: Misclassification of packages; "libs" and "doc" sections

[Thomas Hood <thood@excite.com>]

(quoted text below)

I think it would be a bad idea to conflate different "modes"
of classification together in one graph.  There are two 
issues here that have to be kept separate.

(1) The first issue is that there are different modes of
classification: viz., classification by function, technology,
license, etc.  (See below.)

(2) The second issue is that for one kind of classification,
a package may fall into more than one class.  If "editor"
and "newsreader" are two different function classes then some
programs with be one, some the other, some neither and
some both.  This is why it would be appropriate to *list* the
functions of the contents of a certain package.  If the items
listed are defined by their location on a graph then so
much the better.

However I do not immediately think that it's a good idea
to have one big graph embracing all the different modes of
classification.  You have editors, music players, music
editors that play, and programs that do neither.  Okay;
that's classification by function.  But do we want to define
"nodes" for GPL editors, BSD music players with web interface,
GPL-BSD-combo music editor players for science, etc., etc.?
I don't think so.  Classification modes are (as I'm using
the term "mode" here) orthogonal to each other and should
not be conflated.  Perhaps I'm misunderstanding the proposal.

Thomas Hood


Eray (exa) Ozkural wrote:
> > Function          - editor, MUA, MTA, multimedia players, newsreaders,...
> > Field             - Science, Games, Web, Networking, ...
> > Technology        - X11, Gnome, KDE, Hurd, Linux, Perl, Python, C++, ...
> > Author/Foundry    - FSF, Adobe, MIT, Apache, BSD, Individual, ...
> > License           - GPL, PD, BSD-like, MIT-like, Free, Non-Free
> > Distributor       - Debian  (other source might be Storm, Corel, ...)
>
> In fact, this may be a prototype of a "top-level software ontology"
> in Debian. That is, these are the most general categories that one can
> possibly think of. Since these are top-level categories, any package
> would fall into a top-level ontology like this.
> 
> The graph-based hiearchical categorization I suggested plays nicely with
> the idea of merging multiple classification schemes. Each of "function,
> field, technology, foundry, license, distributor" simply becomes a supercategory
> in my proposal. Though the actual top-level ontology has still to be
> figured out. The most general superclasses in an ontology are those
> that divide all items into broad classes.