Re: RFC: Keywords instead of Section
> > That is correct, but with multiple keywords this works just fine, select
> > keywords "X11" and "client", or "x11" and "server", and there you go.
>
> "x11" & "client" might match, e.g., client tracking programs that
> have X11 interfaces. The benefit of defined typing is that
incorrect. this is NOT a Full-Text-Search, and the keyword "client" is
for "client applications in a client-server model", not for things such
as client tracking (i'd suggest "customer management" or a keyword like
that for this)
Remember: the keywords are EDITED, not automatically generated!
> type that may be used. Once we adopt the "ui:" type, it is
> natural to adopt "ui:x11", "ui:console", "ui:none" descriptors.
that's just cosmetic, too. Of course we can call the keywords any way we
want. I like the way "ui:x11", too. But i would not restrict the
implementation to treating this specially.
> Perhaps you mean that the type name need not be part of
> the descriptor. True, but including the type name has
> benefits. You do it yourself in some of your examples.
I'm talking about implementation, not about using them. I see no need at
all to treat this specially.
> What a classification system has the opportunity to do better
> than a text search is to define the meanings of the keywords
> very strictly. This is what typing does. Making the type
> name part of the descriptor is optional, but I think it is a
> good idea because it makes the sense of the keyword obvious.
> It also allows the same keyword to be used in different senses:
> e.g., "ui:x11" vs. "server:x11"; "license:gpl" vs. "topic:gpl";
> etc.
All this does NOT belong into the implenation. I do not want to change a
single line of code if someone want's to redo all classification and
implement another sceme.
All this is a decicion of the "Keyword Commitee", and they are - as i
wrote before - to definie the keywords and their meaning.
So if they define "gpl" as keyword for Applications unter GPL Licence,
that is just what i was thinking of. But this is the Commitee's Choice
and has to be kept out of the implementation, so it can easily be
changed (think of a company doing a Debian-Based Distro not caring at
all about Licence's - they might want to leave that away completely.
Other's might want to do a completely different categoriation!).
> As a description, 'special' or 'other' is too vague to be
> useful. One might as well omit it entirely.
So the packages not fitting into a category are not found by novices?
> If one is resorting to classifying a package as "special", it
> means that the classification scheme needs to be enhanced.
No. It means "there are to few packages fitting in here to add a new
class".
> Freshmeat/SourceForge types are: Development-Status, Environment,
> Intended-Audience, License, Programming-Language, Topic.
Which are basically all equal in the database and are assigned Integer
Numbers from the same namespace. This Categorization of Keywords is
purely cosmetic in the user interface (i think).
> I agree that this is not a good set of types. The "Topic"
> type is too broad, for example.
That is exactly why i do not want to implement such an hierarchy in the
package system itself, this belongs into the user interface, where
people can have multiple, differing implementations.
> What's the problem? Lots of other fields are lists too.
> (Depends:, etc.)
But "Depends:" is well defined, where your way requirez _dozens_ of
different additional fields, making parsing much more difficult.
p.E. package managers not knowing what your "Licence:" Field is will not
provide this way of selecting Packages to their users.
So if we decide to add another Field (like Intended-Audience:) ALL
Package Managers will have to be modified! Thats EVIL.
> > Which is basically my proposal.
> > "Keywords: client, stable, X11, console, audience-user, gpl, devel-c,
> > devel-python, cooking, sex"
> >
> > Without treating any keyword special, unless the user prefers to do so.
>
> Our proposals are different. To search for all "License:GPL"
> packages is much more specific than to search for all packages
> that have something to do with the GPL. The latter group may
You didn't understand my proposal.
I'm NOT talking about a full-text-search (which is already provided by
apt-cache search and most package managers) and which would indeed find
all Packages having to do anything with gpl.
The keywords are to be edited and well defined by a "Keyword Commitee",
and it's their job to make good keywords, not the software's.
> include documentation packages having to do with GPL, or
> programs used to ensure GPL compliance, or whatnot. You
> suggest that this can be remedied by combining keywords,
It can, of course.
> but no conjunction of keywords will allow you to search for
> all and only those packages whose license _is_ the GPL.
If the keyword is defined to be "gpl-licenced programs only", this is
exactly what you want, if it's about "anything to do with the gpl"
(which might not be too useful, use full-text-search for that!)
blame the keyword commitee.
> Unless you have a "license-gpl" keyword, of course. In which
> case it makes sense to have a "license-bsd" keyword, and ...
Correct. And a licence-nonfree keyword of course, so i can easily
drop all non-free software from my selection.
> lo and behold, you have developed a typed keyword classification
> scheme! But ad hoc, instead of systematically.
I havn't developed ANY keyword classification scheme at all. I provided
some idea's of good keywords and called for a Keyword Commitee to do a
proper selection and definition of keywords.
Greetings,
Erich
Reply to: