Re: Misclassification of packages; "libs" and "doc" sections
On Wed, 18 Oct 2000 16:23:22 +0300, erayo@cs.bilkent.edu.tr wrote:
> My only objection is an implementation detail,
> let's say. Let's not introduce many new fields into package control
> files.
>
> Category: Type:Application, Function:Editor&Devel&Lisp_Interpreter,
> , UI:X11, Author:FSF
>
> would be more reasonable.
This seems okay to me. I can see the advantage of having only
one or at least a very limited number of new fields. I think
that "Package-type:" should still be separate because it
classifies the package rather than the package contents. And
I'd prefer the term 'Class' since 'Category' has a particular
meaning in philosophy (viz., "ontologically fundamental class":
this is Aristotle's use of the word). Thus, perhaps:
Package-type: meta|doc|code
Class: fn:editing, fn:developing, fn:interpreting, ui:X11, au:FSF, ...
> of course in my proposal this goes something like
> Category: Application, Editor, Devel, Lisp_Interpreter, X11, FSF
> Since all node names are unique in the hierarchy.
It's true that you don't need the classification-mode prefix
in order to make the classifying term unique, but IMHO the prefix
should be there to indicate the *way* in which the term is
classifying the package. I think it is neglect of classification
modes that leads to the haphazard schemes that we find in Debian
and in most of the software archive sites. Desktop menus are also
afflicted. Why, for example, do I have "Utilities", "System"
and "Settings" all under "Programs" on the GNOME foot menu?
Aren't there utilities that adjust system settings? If one
were more strict about using a single classification mode at
each level of hierarchy then this problem wouldn't arise.
We'd have, perhaps,
programs
working
developing
gaming
administering
hardware
users
settings
monitoring
...
> Top level categories
> don't have to be mentioned. And of course, you can *change* the category
> hieararchy above this package. That is you can redefine the ontology
> of Lisp_Interpreter.. Say it used to be
>
> Devel
> \
> \
> Lisp_Interpreter
>
> But during the development of the hierarchy we observed that
> there are other kinds of interpreters, too. We also noticed
> that a Lisp_Interpreter is a functional programming language
> (perhaps that's not an is-a relation, but it is indeed a
> special form of a functional programming language, in that
> it implements one with a communication interface in the
> same language)
>
> Devel Programming_Language
> \ / \
> \ / \
> Interpreter Functional_PL Imperative_PL
> / \ /
> / \ /
> Calculator Lisp_Interpreter
>
> The categories here are imaginery, but I wanted to show
> what sort of use the system (Daniel and I have been discussing)
> can have. As we did these changes to Lisp_Interpreter category,
> we didn't touch the packages which claimed to be Lisp_Interpreter.
We should allow for this sort of change to the hierarchy
of classes. However we shouldn't allow a term defined as
a classifier in a given mode to be redefined as a classifier
in another mode.
Before
------
Package: foo
Class: fn:interpreter, lang:lisp
After
-----
Package: foo
Class: fn:interpreter, lang:lisp
Package browser modified so that "lang:lisp" and "lang:prolog"
appear under the superclass "lang:functional", a
new keyword defined as the disjunction of "lang:lisp" and
"lang:prolog" for the purposes of package searching (perhaps).
Thomas
Reply to: