comments on tags

[Ivan Avramovic]

On 01/19/2007 03:59:48 PM, Enrico Zini wrote:
> 
> We started collecting some editing tips at
> http://debtags.alioth.debian.org/edit-tips.html
> it's hard however to come up with general rules and suggestions, and
> often in tagging one has to creatively apply common sense rather than
> following existing advice.

Those editing tips would be useful to include in the FAQ.   
Additionally, it would be nice to see recommendations for what one  
would expect to see, of the following form (please correct if there are  
inaccuracies):

* Exactly one tag from the "role" facet.
* For a program, exactly one tag from the "scope" facet, and at least  
one tag from the "interface" facet.
* For a program with a UI, at least one tag from the "uitoolkit" facet.
* For a program, one or more tags from the "implemented-in" facet,  
describing the language(s) that the program was written in.
* For a data package, one or more tags from the "made-of" facet.
* For an x11 data package, a tag from the "x11" facet to indicate the  
type of data.
* For a package relevant to a particular field (scientific or  
otherwise), possibly one or more tags from the "field" facet.
* For children's/educational software, one tag from the "junior" facet.
* For a package intended specifically for a certain culture/language,  
an appropriate tag from the "culture" facet.
* For software, one or more tags indicating the basic type of program,  
from the "accessibility", "admin", "devel", "game", "hardware", "mail",  
"network", "office", "security", "sound", "web", and "x11" facets.
* For software, one or more tags from the "use" facet, indicating what  
context the program is used.
* For data manipulation software, any number of tags from the  
"works-with-format" facet, to indicate supported data types.
* For any software that performs a function, any number of tags from  
the "works-with" facet, to indicate what the software functions on.
* For software which uses the network, one or more tags from the  
"network" facet to indicate role, and one or more tags from the  
"protocol" facet. [should a program using a high-level protocol, ie  
http, include the "protocol::tcp" tag?]
* For network software that performs some sort of file transfer, one or  
more tags from the "filetransfer" facet.
* For a package used in software development, one or more tags from the  
"devel" facet to indicate the supported development language.
* For a package that supports, or is part of, a specific major  
application, all applicable tags from the "suite" facet.  In  
particular, note "suite::debian", "suite::gnome", "suite::gnu", and  
"suite::kde".
* Each applicable tag from the "special" facet.

> I normally find it useful to associate a use case to a tag and ask
> myself "would the user want to have this package among the results?"
> 
> In the case of flashplugin-nonfree and the tags use::playing and
> works-with::video, an obvious use case is "Alice downloaded a flash
> video file and is looking for packages that could play it."  In that
> case, flashplugin-nonfree should definitely appear among the results,
> and I tag it.
> 
> Conversely, in the case of supertux-data and the game::arcade tag, I
> cannot see any common enough use case where a use would like to see
> supertux-data appear as an arcade game, so I would probably only tag
> it
> role::app-data.
> 
> (this previous bit should probably go in the FAQ.  I could use some
> help
> with improving the FAQ: the current format is not very readable)

> I'm afraid x11::applet is the best we have now.  Does it make sense,
> now
> that we have scope, to use scope::applet?

I think that would make sense, and is more general than x11::applet.

> > * It would be good to have a tag to indicate that a package is only
> the
> > installer for software or data not included in the package itself
> (ie
> > flashplugin-nonfree).
> 
> Indeed this one is missing.  special::installer ?

Sounds good to me.

> > * A tag could be used to indicate that the package contains some
> form
> > of executable data, such as java or some other form of
> > interpereted/emulated bytecode.  There are a number of tags already
> in
> > the "implemented-in" facet, but I'm talking about a generic tag to
> > indicate a datafile which can be executed as a program.
> 
> I am not able to see a use for it: can you think of a reasonable use
> case where someone would be looking especially for software that are
> byte-compiled?

It's not an important point, but I had the idea in conjunction with the  
idea of packaging interactive fiction games.  The same idea is  
relevant, for instance, with packaging demo roms for emulators.  I'm  
not sure if either of these are currently represented in any debian  
packages, however.

> Good point.  The idea has popped up in the past[1] to list supported
> mime types among the package metadata, so that one could point to a
> file
> and get a list of all the packages that can work with it.
> 
> I'm not sure it's a good idea to encode mime types in debtags and I'd
> like to see something ad-hoc for it.  In the meantime
> works-with-format
> is the best we can do, but we should limit it to the most common
> formats.

Maybe, then, push to have supported mime-types as a standard package  
header, instead of supporting it with debtags?  That's how I read what  
you are suggesting.  This would obsolete "works-with-format", which  
would make it easier to maintain the tag vocabulary.

> Indeed gif and mpg are common enough to be in works-with-format, and
> they should be.
> 
> I've added works-with-format::gif, but what should I do for mpg?  I
> get
> confused with it meaing lots of things like video (mpeg4), music
> (mp3),
> dvd (mpeg2) and possibly variations of this all.

Since audio/mpg is already represented by the mp3 tag, I would only add  
a tag for the video/mpeg mime type.  Maybe also for video/mp4.

> [1] http://deb-usability.alioth.debian.org/lca-bof-notes.html

> > [code maturity tags]
> 
> It would be useful but it would be very difficult to assess, and
> possibly subjective: many software developers always think that their
> software is not ready but almost, and you see lots of version numbers
> like 0.9.1.  Other people may consider the same software to be very
> stable and use it in production since quite some time.
> 
> When we have attributes that can be controversial, I prefer not to
> have
> them in the main debtags database and to have them instead provided
> externally, like in the case of iterating.org [1]
> 
> [1] http://www.enricozini.org/2006/debtags/iterating-org.html

Ok.  But I wouldn't dismiss the potential usefulness of such a tag,  
even if not official.

> > * It would be useful to have tags to be able to distinguish
> supporting
> > software from a primary application.  This would probably best be
> > accomplished with "scope" tags.  Also, the "scope::utility" tag is
> > ambiguous because the description indicates that it is unlikely
> that
> a
> > user will need the program.  Would this be true of, for instance,
> bzip2?
> 
> About distinguishing software from a primary application, I think that
> the Enhances: field should do it[1]; however, there is still no tool
> support for it.

Good.

> About utility being ambiguous: yes, it is.  Is bzip2 an utility?  I
> tend
> to think so: compression is normally part of the task to fulfill a
> goal
> (say, archiving old data, or transmitting information), but is rarely
> the goal itself.

bzip2 is, I think, uncontroversially a utility.  The description of a  
utility in the vocabulary does not represent it well, however.

> But indeed most people here are troubled[2] by the application/utility
> tags.  We feel they are very important, and still we don't see a clear
> line telling them apart.

My intuitive distinction is that, if a program is meant to be executed  
to completion, then it is a utility, whereas if user-interface is  
relevant, then it is an application.  The distinction may become  
ambiguous again with gui wrappers for utilities, but nevertheless, this  
is how I see it.

> The main point of those tags is probably to put firefox on one side
> and
> moreutils on the other side, and the inbetween cases are likely not to
> be relevant in common search scenarios.

I agree.

> [1] http://lists.debian.org/debian-devel/2005/11/msg01129.html
> [2]  
> http://lists.alioth.debian.org/pipermail/debtags-devel/2005-December/001131.html
> 

> It's becoming an established practice to propose tags together with a
> list of at least 5 or 6 packages that would use the tag, so that we
> make
> sure it's a significant tag and we add the tag with a non-empty
> initial
> package list.

Ok, sound reasonable.

> > Tag: game::adventure:text
> > Description: Interactive Fiction
> >  Text-based adventure games (interactive fiction).
> 
> It can currently be approximated with game::adventure and
> interface::shell
> 
> How many interactive fiction games do we have in Debian?

frotz, xzip, jzip, scottfree, qtads, tads2, tads3.  I don't know if  
there are any that I missed.  Each of those is an interpreter, not a  
game itself.  And not all use a shell interface.

> > Tag: game::action
> > Description: Action
> >
> > Tag: game::action:arcade
> > Description: Arcade
> >  Games derived of arcade games.
> >
> > Tag: game::action:fighting
> > Description: Fighting
> >  Fighting games.
> >
> > Tag: game::action:fps
> > Description: First person shooter
> >
> > Tag: game::action:platform
> > Description: Platform
> >  Platform-jumping games.
> 
> You can find some discussion here about not subdividing 'games' too
> much, and the risk of using currently trendy names:
> http://lists.alioth.debian.org/pipermail/debtags-devel/2006-November/001397.html
> 
> In this particular case, I'm not sure 'action' is very clear: there
> are
> role playing games that I would consider to be action games and often
> cross the border with fighting games or first person shooters.
> 
> Sport games could also be 'action'.

I suggested "action" and "arcade", because the HappyPenguin database  
(happypenguin.org) has both as major sections.  As for the other tags  
in this section, most were already in the vocabulary, and I'm merely  
recommending renaming for better hierarchical organization.  I only  
added "game::action:fighting", which may be superfluous.

> > Tag: game::emu
> > Description: Emulation
> >  Emulators for different game systems.
> 
> This risks ending up redundant with hardware::emulation

Specifically in the case of a "hardware::emulation" tag, the hardware  
involved is completely virtual, so it doesn't hurt to additionally  
represent the package with tags outside of the "hardware" facet.  In  
the specific case of game system emulators, there should be at least on  
"game::*" type tag to represent the package.

> > Tag: game::puzzle:word
> > Description: Word games
> 
> Can you give an example of word games?

I had in mind some of the games from the bsdgames package, such as  
hangman.  However, looking over the package list now, I don't see this  
category being represented like I had imagined.

> > Tag: game::related
> > Description: Game-related
> >
> > Tag: game::related:demo
> > Description: Demos
> >
> > Tag: game::related:toys
> > Description: Toys or Gimmick
> >  Toys, gimmicks, and similar amusements.
> >
> > Tag: game::related:util
> > Description: Game-related utilities
> >  Game-related utilities (dice rollers, server browsers, and the
> like).
> 
> I'm now thinking that game::related could be 'scope::utility &&
> use::entertaining'.

It would make sense, but it would defeat attempts to locate something  
like xpenguins, or an "eyes" app with a "game::* scope::applet" type  
search.

> Someone pointed me that demo scene people wouldn't consider their
> creations to be games but rather forms of art, and this makes
> game::demos a wobbly tag.

> > Tag: game::rpg:mmo
> > Description: Massively Multiplayer Online RPG
> >  Graphical multiplayer online RPGs (does not include MUDs and the
> like)
> 
> What do we have in Debian that fits this one?

Right now, crossfire (crossfire-* packages) and cyphesis (cyphesis-*  
packages).  I suggest this tag with foresight, however, since there are  
several relatively new, but playable GPL games in this category which  
are not yet packaged.


> It looks good, however many tags are redundant with existing tag
> combinations: graphics::video:editor is really 'use::editing &&
> works-with::video'.
> 
> I still haven't figured out if it's better to have redundancy of tags,
> or if it's better to have only one tag per concept.  The problem is
> that
> too many tags will mean that it's hard to maintain a good quality tag
> database and users will have to face a confusingly large choice of
> tags.

My personal leanings are towards tag redundancy, so that a user isn't  
responsible for knowing the "right way" to do searches.  I agree,  
however, that one should not sacrifice the manageability of the tag  
database.

-Ivan Avramovic