Re: Misclassification of packages; "libs" and "doc" sections
Thomas Hood wrote:
>
> In the graph you give below, I take it that "User_Interface"
> is the class of packages whose contents have some user interface.
Yes. User_Interface is a top-level supercategory.
> In this one example at least, the orthogonality of human-interactivity
> classification to functional classification is exhibited in the
> fact that the two graphs are separate right down to the package.
Well, yes. That's why we don't have a
"BSD music players with web interface" node. But note that this is
a conjunct category and is as well valid. I haven't yet figured out
how this should be handled.
> So I don't think there is much need to have both on the same graph.
> (If you think the graph should cover both UI and function, then
> shouldn't it cover every classification mode from "Priority:" to
> "Depends:"?)
>
The idea is not that the graph should cover both UI and function, the
goal is that we find a categorization model that covers _every_ possible
category. We don't decide about UI and function (as you call it) in
the beginning, if it turns out that there's indeed need for a super
category like that, it will hopefully emerge some time in the development
of package ontology.
On the contrary to what you suggest, the two should absolutely be
on the same graph because it is a uniform representation. The other
way would seem to me ad hoc. Plus, it would possibly imply hardwiring
those super-categories in implementation; essentially making our
system not any better than that of freshmeat. [A good ontology would
capture the "essence" and leave out arbitrary choices]
> I have a suggestion for the *function* class names: they should all
> be participles. Even though the result is sometimes a bit stilted,
> requiring them to be participles forces one to think about the
> *function* of the package. It was a help to me in coming up with
> the following graph (with example packages marked with an asterisk):
>
The suggested function class names are okay and intuitive. Categorization
by function is okay, too, as more users would look for functionality
rather than an implementation detail.
A rule of thumb here though : no more than 7-10 subclasses for any
class. Second, it seemed to me a single-inheritance tree which isn't
adequate for large category hierarchies.
Example I gave Dan previously:
X11_Client Development_Tool
\ /
\ /
Graphical_Debugger
/ \
/ \
[DDD] [xxgdb]
The typical multiple-inheritance diamond is required here (arcs upward)
The more concise a representation, the better it goes for the user.
That's why we have things like Demeter's Law in OOP. The end result
of this hierarchy will be a UI, which should be more meaningful and
easier to navigate than the current section hierarchy.
[snip]
Once we decide on the correct formal model for the category hierarchy,
we'll work together to make this come true. :)
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: