Re: Misclassification of packages; "libs" and "doc" sections
Thomas Hood wrote:
>
> I think that all we really need is some new fields
> in the package description---one field for each
> mode of classification that might be of interest
> to users. It would then be up to some keen programmer
> to write a package browser that would offer different
> views of packages according to their properties so defined.
The problem is, which modes of classification are useful?
I think we should be conservative about fields in the package
description simply because it's a big change and hard to retire.
I'm in favor of a single new field for packages,
Category:
This will have to be handled at separate levels as pointed out,
(override, etc.) so introducing *only one* new field seems to
be the right way.
> If the function words chosen are specific enough then with
> the aid of the other classification modes it should be fairly
> easy for a user to zero in on the packages that interest him.
> If he asks for a GNOME editor, that handful of packages will
> be listed.
>
[snip]
nice, but you see those are all possible in the more general systems
we have been discussing, too.
> Question: What happens if we later want to split up a class,
> e.g., a UI class such as "X", into subclasses
> such as "X-only", "GNOME" and "KDE"?
>
> Answer: Then we add the names of the new subclasses to our
> list of legal UI designators, encourage maintainers to
> update their packages to contain the more specific designators,
> but in the meantime code into our package browser the
> knowledge that "X-only", "GNOME" and "KDE" are subclasses
> of "X" so that the former will be displayed beneath the
> latter in any hierarchical views of the archive and all
> of them will turn up when the user asks for "all the UI:X11 apps".
>
So each classification mode represents a tree hierachy.
> In a similar way new designators could be defined as
> conjunctions or disjunctions of existing designators.
> All these relations would be known to the package browser,
> but not, of course, encoded in the packages themselves.
> (The browser would display the conjunctive class A&B as
> the B subclass of A and as the A subclass of B. It would
> display the disjunctive class AvB as the immediate
> superclass of A and of B.)
>
category expressions in this manner are possible in the
single category hierarchy also. I had the same idea, as well.
> The job ahead of us, then, is twofold.
>
> First, to decide which classification modes are of interest.
> Second, to come up with a list of values for each mode---a
> list of package types, of UIs, of functions, etc. As has
> been suggested before, the way to go about this is to work
> up an initial system and then go through all the packages we
> have and classify them according to it, adapting the system
> as we go until we have something that's nice. Once this is
> done the classification info can be entered into an overrides
> file for the information of the package browser; new or modified
> packages would be required to include the info in the package
> itself so that it could be queried using dpkg.
>
> So, to begin with, what are the ways in which users would
> like to see packages classified? The following have all
> been suggested:
>
> Type:
> Function:
> User-interface:
> Domain:
> Code-level:
> Project:
> Author:
> License:
> Distributor:
> Currency:
Well, these all look very intuitive. But we can't know if these
are really top-level categories until we put every package
in the hieararchy. 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. 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. 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.
Note that a category is *not* eligible unless there are a
sufficient number of packages that are members of that category.
That is, there is no category in Debian called Violent_Penguin_Slaughter_Game
there are just not enough programs that would be in that category.
> Which of these, or which others, should be adopt?
>
> Function and UI are obviously two of the useful ones.
> So, what should our (initial) list of functions and user
> interfaces be?
Well, I myself suggested type and ui in the progeny-debian
discussion along with a tree for the two. But I'm saying here
that ours can be better. ;)
Thanks,
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo
Reply to: