Questions on facets

[Jonathan Nieder]

Hello all,

I have been trying to tag those of my installed packages which are
either untagged or tagged incorrectly. It's been great fun. In the
process, a number of questions arose.

The DebTagsFacets Page

Is DebTagsFacets on wiki.debian.org the right place to look for the
meaning of each facet? I found it very helpful, but
http://wiki.debian.org/DebTags did not provide a strong "information
scent" for it. At first, I thought it was going to be a page on the
concept of faceted classification and so I skipped over it completely.

The works-with Facet

How is the works-with facet meant to be used? I understand that if a
program groks some format as input, then a
works-with-format::that-format tag is warranted. If a program is used
to read image files, then we put works-with::image. But how would you
tag a program that converts text files to image files? Would this be
"use::converting, works-with::text", "use::converting,
works-with::text, works-with::image, works-with-format::image:jpeg",
or something else?

What about a program that does not work directly with an object but
makes use of it indirectly by means of another program? For example,
pristine-tar does not directly work with git repositories, but its
very purpose involves maintaining a branch in a git repository
containing the information needed to reconstruct published release
tarballs. It does this by invoking git. Should pristine-tar have a
works-with::rcs tag? (Such a works-with tag for source control does
not currently exist, but from the presence of works-with::db I infer
that it probably should.)

Documentation packages and the use facet

How are documentation packages meant to be tagged? (I know this
question is addressed on the DebTaggingGuidelines wiki page,  but I
did not understand the answer.) On the DebTaggingGuidelines page, it
is implied that if a libgetopt-doc package existed, it would have to
include an interface::commandline tag because it is helpful in
creating commandline interfaces. This seems wrong to me, because
interface:: is a facet of a package's personality (meaning interface),
but in this use it would be describing energy (purpose). I think I
understand the idea: the point is that if a package has
role::documentation, then it is impossible that the package itself
provides a program with a commandline interface; so it is most useful,
or so the logic goes, to reuse these tags for another purpose.

Well, that's crazy, in my not so humble opinion. Let me backtrack and
say that for use:: and other facets of energy, maybe that logic would
be almost appropriate.

An idea I could almost be persuaded to agree with would be as follows:
Suppose that package foo is really meant for fooing, but that after
some contortions, by combining it with other scripts or by carefully
interfering with its operation, we can make use of it for bazzing.
Suppose that the foo-doc package explains how to use foo to baz. Then,
one could argue, package foo should have use::fooing and not have
use::bazzing, and package foo-doc ought to have use::bazzing.

This is such a rare situation as to not warrant its own rule, I think.
Also, it would be very hard to tell in a given situation whether the
rule applies, and if a rule is not straightforward to apply in each
case then it is likely to end up being applied inconsistently so that
for our purposes it would be useless. So even though I could almost be
persuaded to adopt this idea, I am not persuaded yet.

To summarize: I think documentation packages should not have any tags
in the use:: facet at all, except for use::configuring if they include
sample configuration files, use:: tags reflecting the use of included
example scripts, and use::learning if they are especially helpful to
those unfamiliar with some subject (maybe). Similarly, unless included
scripts, sample code, or pen-and-paper game instructions warrant it,
documentation packages should not include tags under the
accessibility, admin, devel, game, hardware, office, security, sound,
works-with, or works-with-format facets, except for devel::doc. This
goes against some existing practice of putting use::browsing,
works-with-format::pdf, etc. for documentation. Documentation should
instead have role::documentation and made-of::data:pdf, etc. Am I
interpreting the tags correctly here?

The scope facet

I was unable to figure out what tags for the scope facet, if any,
packages should get. The DebTaggingGuidelines wiki page says in its
description of scope::application that scope::application should be
used for user-friendly programs and scope::utility should be used for
programs that might be run in a pipeline. In its description of
scope::utility, it says that scope::utility should be used for
non-interactive programs. The current vocabulary file says that
scope::application should be used for programs that do that 80% of the
things you want to do 80% of the time towards a particular task (i.e.,
programs that feel somewhat complete in themselves --- see
<http://www.mozilla.org/unity-of-interface.html> for this idea taken
to an extreme), while scope::utility should be used for more marginal
programs that do more marginal things (but when you need them, you
need them...). So here are three distinct ideas of what scope:: means,
and all of them are vague.

I don't have any real thoughts on which one is most useful, except
that you can tell an interactive program by its interface:: tags
already. I just mention it because it left me confused.

Apologies for sending such a long message. I have still more
questions, but I think these are enough for now.

Thanks in advance for your help,

Jonathan Nieder