[Debtags-devel] Updating tags on svn

[Thaddeus H. Black]

[Topics: facet philosophy and vocabulary design.  Uninterested readers
can safely skip this long message.  There is nothing critical here.]

Justin wrote:

> The role:: facet isn't well-suited to the task of describing what
> users are going to do with an application; instead it deals with the
> way packages relate to one another, and "package that provides
> independent executables" is only one role.  There's some trace of a
> difference between role::sw:utility and role::sw:application in
> terms of *how* independent they are... not necessarily enough of a
> difference to have any practical value in searches. 

It is difficult to draw an objective distinction between the two, isn't
it?  The line separating applications from utilities is somewhat blurry.
Nevertheless I feel that the subjective distinction remains quite
important and---unless you can see a more logical way to indicate
it---should probably be retained.  (Personally as a user, I am usually
much more interested in utilities than in applications, so at least
users like me need to be able to draw this difference.)

> Well, to be honest, getting those two to be merged is very low on my
> wishlist.  But I really would prefer to have fewer rather than more
> role:: tags.  Take for instance role:sw::applet.  Is it really a
> useful category?

Yes, I think that it is.

There are two kinds of dock-apps: 
> a) ordinary X applications that are only called dock-apps because
>    they're small and square and look nice arranged along the edge of
>    your desktop - which if anything sounds like a subcategory of
>    interface::x11.

I thought that these dockapps obeyed some specific kind of WindowMaker
software interface standard.

> b) things that only work in (say) the GNOME panel, which is indeed a
>    role in the same sense as the other role::sw: categories, but one
>    that as far as I can see is perfectly well covered by tagging
>    them as role::sw:plugin, suite::gnome. 
> Some of those role::content: types might be candidates for a cull
> too - if we're going to distinguish them on the basis of what kind
> of data they're made of, we can do that more effectively by way of
> the made-of:: facet. 
>  
> It's not the "bloat" that I worry about, exactly; I wouldn't object
> to extra role:: tags that genuinely belonged under that facet.  But
> category erosion is a problem, because it makes the system less of a
> system...

Good point.

> > I mean, I think that games, window-managers and terminals are special
> > kinds of software no less than 'driver', 'input-method' or 'utility'
> > are, and I can indeed see a value in providing categories for them.
> 
> Actually I don't see understand why it is that we have
> role::sw:driver or role::sw:input-method.  Drivers are simply
> role::aux:shlib packages associated with a specific kind of
> hardware::, aren't they?  And as for input-methods... they might
> deserve to be specially handled under accessibility:: somewhere, but
> surely they're just servers?

Well, yes, but the Chinese users need them.  To them, an input method is
almost as basic as console-tools is to us.  Tagging input-method
packages lets the Chinese users find them and---just as
importantly---lets you and me filter them out.

Culture::chinese doesn't work here, either, because although input
methods are not very interesting to users of Latin, Cyrillic and Greek
scripts, they are interesting to Japanese, Koreans and some others who
speak languages wholly strange to me.

> They don't relate to other packages in
> any particularly interesting way.  (Or if they do, why aren't you
> also suggesting role::sw:x-server and role::sw:getty?)

One sees your point.  In practice however, I admit that I do not think
that it is the same thing.

> > So, question: if we think that adding them to role::sw is bloating,
> > where can we put them instead?
> 
> If users want to search for a window-manager, they already can -
> there's an x11::window-manager tag entirely dedicated to the purpose
> of marking out window-managers.  If people want to search for a
> terminal-emulator, they already can - there's an
> x11::terminal-emulator tag entirely dedicated to the purpose of 
> marking out terminal-emulators.

Yes, but, still...  a window manager is a distinct kind of thing.  For
example, there is something called Berlin or Fresco, which (if I
understand correctly) very roughly serves as a non-X11 window manager
for GGI.

Actually, Justin, I see your point.  I am not sure that you are wrong.
After all, one should not draw a distinction between real packages in
the real Debian archive, unless there is a real qualitative difference
between them.  Especially, one should not use the wrong facet.  But we
need to think about this.  One of the things we are discovering is that
we cannot apply the facets with quite as neat, geometrical an edge as
one might like.  We do the best we can, but...  Okay, let me ask this.
If we reduced the vocabulary in the way you suggest, how would one tag
the `fluxbox' binary, for example?

(This is not a challenge.  I accept the principle underlying your point.
This is just a question.  If the question seems relevant to you, then
when you have some time, try tagging `fluxbox' with a hypothetically
simplified vocabulary; and then show us what you have come up with.  It
would be interesting to see the result.)

> If we start duplicating the distinctions we've already got into the
> role:: facet, there's no end to the list of things we could add.
> Why not role::sw:text-editor? 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050808/b2237080/attachment.pgp