comments on tags

Fri Jan 19 21:59:48 CET 2007

On Wed, Dec 27, 2006 at 01:39:00AM -0500, Ivan Avramovic wrote:

[I'm overquoting to provide context for the list]

> In browsing the debtags documentation, it appears as though debtags are  
> currently very much open to open to comment.  Since I'm rather  
> interested in seeing well-organized package browsing, I thought it  
> might be useful to offer up some of the suggestions which I've come up  
> with.  I'm also proposing some tag updates, which I've attached below.
> 
> * I would love to see some specific documentation on how to select  
> tags.  I believe that debtags is only as useful as package maintainers  
> make it, and as such, I don't think that one should be required to  
> become a tagging expert in order to be able to use debtags effectively.
> 
> I think it would be useful to describe which facets a maintainer is  
> responsible for.  For instance, one "role" is required, and selecting  
> at least one tag which describes function from  
> "admin"/"games"/"mail"/etc. is pretty intuitive.  However, it is easy  
> to miss tagging something like "field", "scope", or "special".
> 
> Finally, it would be useful to document what to do in unintuitive  
> situations.  I'm sure that someone who's worked closely with tags has  
> run into more of those than me, but I can think of several examples.   
> Does a plugin carry the same type tag as the app itself (for instance,  
> an audio plugin isn't actually a "sound::player" itself, but it is part  
> of one)?  If a program supports a particular data type, but only  
> through a separately packaged plugin, how should it be tagged?  Should  
> the tags for an installer program (ie flashplugin-nonfree) be based on  
> the software that is downloaded?

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.

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)

> * It would be good to have a tag to indicate that a program is some  
> sort of applet, for instance, a window manager applet, desktop applet,  
> or webbrowser applet.  The tag x11::applet already exists, but it is  
> not general enough.

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

> * A tag should exist to indicate that a library is compiled with  
> debugging symbols.

After you wrote this mail, there has been a thread about it:
http://lists.alioth.debian.org/pipermail/debtags-devel/2007-January/001535.html

> * 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 ?

> * 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 would be very useful if the means for indicating the supported  
> data formats was more comprehensive.  This could mean a lot of  
> expanding in the "works-with-format" section of the vocabulary, which  
> doesn't even include formats such as gif or mpg at the moment.  I don't  
> know how feasible it is to alter underlying debtags functionality, but  
> perhaps it would be the easiest to make "works-with-format" a special  
> case tag which allows for formats not listed in the vocabulary.

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.

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.

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

> * The Debian software base has software that ranges from mature  
> applications to beta software which happens to function.  It would be  
> useful if there were package tags to indicate the developmental state  
> of the underlying software.

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

> * 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.

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.

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.

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.

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

> * There are no tags in the "hardware" facet for network, wireless,  
> sound, or drawing tablets.

Indeed, proposals are welcome.

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.

> I'm attaching a file which I've written with some proposed updates to  
> the current tag list, regarding the "game", "sound", and completely  
> lacking "graphics" facets.  There were enough changes that I figured  
> that it would be easier to make a vocabulary-formatted file than to  
> point out all of the suggested changes.  As such, it includes some of  
> the tags already present in the vocabulary.

I would prefer not to see the tags already present in the vocabulary so
that I see right away what are the new things.

> 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?

> 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'.

> Tag: game::devel
> Description: Game Development
>  Game engines and game development libraries.

This one is missing.  However: game::devel or devel::games?  Or maybe
both, as game::devel would be like wesnoth-editor and devel::games would
be like liballegro-dev

Anyone against adding both?

> Tag: game::edu
> Description: Children's/Educational
>  Educational software and games for children.
> 
> Tag: game::edu:typing
> Description: Typing Tutor
>  Games that assist in teaching typing.

Yes.  We should also see what to do with the junior facet.

> Tag: game::emu
> Description: Emulation
>  Emulators for different game systems.

This risks ending up redundant with hardware::emulation

> Tag: game::puzzle
> Description: Puzzle
> 
> Tag: game::puzzle:tetris
> Description: Tetris-like
>  Games that are based on or similar to tetris.
> 
> Tag: game::puzzle:word
> Description: Word games

Can you give an example of word games?

> 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'.

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
> Description: Role-playing
> 
> 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?

> Tag: game::rpg:mud
> Description: Multiplayer RPG
>  MUDs, MOOs, and other text-based multiplayer RPGs.
> 
> Tag: game::rpg:rogue
> Description: Rogue-Like RPG
>  Games derived of Rogue, like Nethack, Angband etc.

> Tag: game::sport
> Description: Sport games
> 
> Tag: game::sport:racing
> Description: Racing
>  Driving and racing games.
> 
> Tag: game::strategy
> Description: Strategy
> 
> Tag: game::strategy:rts
> Description: Real-time strategy
>  Real-time strategy games.

> Facet: graphics
> Description: Graphics
> Nature: energy
> Status: needing-review
> 
> Tag: graphics::TODO
> Description: Need an extra tag
>  The package can be categorised along this facet, but the right tag for it is
>  missing.
>  .
>  Mark a package with this tag to signal the vocabulary maintainers of cases
>  where the current tag set is lacking.
> 
> Tag: graphics::3d
> Description: 3D Graphics
> 
> Tag: graphics::3d:cad
> Description: Computer Aided Drafting
> 
> Tag: graphics::3d:modeller
> Description: 3D Modelling
> 
> Tag: graphics::3d:renderer
> Description: 3D Rendering
> 
> Tag: graphics::3d:viewer
> Description: 3D Viewing
> 
> Tag: graphics::ascii
> Description: ASCII art
> 
> Tag: graphics::conversion
> Description: Conversion
> 
> Tag: graphics::camera
> Description: Digital camera
> 
> Tag: graphics::capture
> Description: Image and Video Capture
> 
> Tag: graphics::editor
> Description: Image editor
> 
> Tag: graphics::font
> Description: Font 
>  Font manipulation and viewing.
> 
> Tag: graphics::process
> Description: Image processing
> 
> Tag: graphics::scanner
> Description: Image scanning
> 
> Tag: graphics::scanner:ocr
> Description: Optical Character Recognition
> 
> Tag: graphics::special:not-applicable
> Description: Facet is not applicable
>  The package cannot be categorised using this facet.
> 
> Tag: graphics::special:not-yet-tagged
> Description: Not yet tagged
>  This facet of the package has not yet been categorised.
> 
> Tag: graphics::special:todo
> Description: Need an extra tag
>  The package can be categorised along this facet, but the right tag for it is
>  missing.
>  .
>  Mark a package with this tag to signal the vocabulary maintainers of cases
>  where the current tag set is lacking.
> 
> Tag: graphics::video
> Description: Video
> 
> Tag: graphics::video:dvd
> Description: DVD Video
> 
> Tag: graphics::video:conversion
> Description: Video conversion
> 
> Tag: graphics::video:editor
> Description: Video editor
> 
> Tag: graphics::video:player
> Description: Video player
> 
> Tag: graphics::video:streaming
> Description: Streaming video
>  Videoconferencing and other video from realtime sources.
> 
> Tag: graphics::video:tv
> Description: Television
> 
> Tag: graphics::viewer
> Description: Image viewer

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.

> Facet: sound
> Description: Sound and Music
> Nature: energy
> Responsible: free at agnula.org
> Status: needing-review
> 
> Tag: sound::TODO
> Description: Need an extra tag
>  The package can be categorised along this facet, but the right tag for it is
>  missing.
>  .
>  Mark a package with this tag to signal the vocabulary maintainers of cases
>  where the current tag set is lacking.
> 
> Tag: sound::cd
> Description: CD Audio
> Implies: sound
> 
> Tag: sound::compression
> Description: Compression
> Implies: sound
> 
> Tag: sound::conversion
> Description: Conversion
> Implies: sound
> 
> Tag: sound::dsp
> Description: Audio processing
> Implies: sound
> 
> Tag: sound::dsp:speech
> Description: Speech Synthesis
> Implies: sound
> 
> Tag: sound::editor
> Description: Audio editing
> Implies: sound
> 
> Tag: sound::editor:sequencer
> Description: MIDI Sequencing
> Implies: sound
> 
> Tag: sound::midi
> Description: MIDI Software
> Implies: sound
> 
> Tag: sound::mixer
> Description: Mixing
> Implies: sound
> 
> Tag: sound::notation
> Description: Music notation
> Implies: sound
> 
> Tag: sound::player
> Description: Playback
> Equates: use::playing && works-with::audio
> 
> Tag: sound::player:radio
> Description: Radio
>  Radio tuners.
> Equates: use::playing && works-with::audio
> 
> Tag: sound::recorder
> Description: Recording
> Implies: sound
> 
> Tag: sound::server
> Description: Soundserver
> Implies: sound
> 
> Tag: sound::special:not-applicable
> Description: Facet is not applicable
>  The package cannot be categorised using this facet.
> 
> Tag: sound::special:not-yet-tagged
> Description: Not yet tagged
>  This facet of the package has not yet been categorised.
> 
> Tag: sound::special:todo
> Description: Need an extra tag
>  The package can be categorised along this facet, but the right tag for it is
>  missing.
>  .
>  Mark a package with this tag to signal the vocabulary maintainers of cases
>  where the current tag set is lacking.
> 
> Tag: sound::streaming
> Description: Streamed audio
>  Audio with realtime data sources, such as webphones.
> Implies: Sound
> 
> Tag: sound::visualization
> Description: Audio visualization
> Implies: sound

Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20070119/01de7f47/attachment.pgp