On May 19, 2005, at 11:58 AM, Micah Anderson wrote:
On Wed, 18 May 2005, Alexander Schmehl wrote: This is the beauty of this method, you do not have to be all-knowing, you can make a package-maintainer's educated guess about the appropriate tags for your package, and then others will provide you the corrections, additions, removals. You then harness the brain-power of your user-base for "knowing" these things.
I've been watching this thread with considerable interest, as this is one topic I care a lot about. Up 'till now, it's been very steeped in OWL and formal ontologies - Micah gives me the perfect opportunity here to present my idea. He hits the problem right on the head - tagging isn't about what one person thinks, it's most useful in terms of communities, and the existence of *shared* tags. I'm sure you're all familiar with del.icio.us [1], so that's what I'm thinking.
The complexity of all the systems that have been described thus far is a primary concern - if we want to have maintainers adopt tagging, it needs to be done in as simple a way as possible, with the possibility for growth later.
I would propose the following: - Phase 1 -1. Configure a simple del.icio.us clone [2], available on the web somewhere. 2. Use the fact that every debian package has an unique URI to enable tagging by anyone. 3. Create a couple of simple scripts that interact with a simple web API [3] to support tagging on the command line. The critical scripts would be:
a. "debtag <package> <tag>*" to enable user-tagging, and
b. "fetch-debtags <package>" to assist maintainers in adding
debtags to their packages (to enable local apt-cache searches on tags).
4. That maintainers have ultimate control over which tags are
included, but encouraged to include all tags added to the system. The
idea behind this is that (1) the people who use the package are most
likely to know what they use it for [4], and which language is most
appropriate, and (2) creating disputes about tagging nomenclature is
not really productive, since tags are definitely one area where more-
is-better [5]
- Phase 2 -It is clearly desirable to be able to have "canonical" tags - that is, tags that "mean" something special. For example, "cdd:skolelinux" should be afforded some "special" status - I can imagine a system where "apt-get install tag/cdd:skolelinux" does some awesome things, and there is a good reason to allow for some process in determining which packages are "allowed" to be tagged in certain ways. However, this adds a great deal of complexity to the tag-management system, and therefore should be carefully planned and generally avoided until the software to enable such tasks is present.
Does this all make sense? I can definitely provide background material that supports this argument. I'm *not* suggesting that we should abandon all hope of creating a structured ontology for packages - I believe the package-space is small enough that this could be accomplished to some degree, but I'm also willing to bet that with a rich del.icio.us-like tag infrastructure, and adoption by users, some smart RDF or infosys hackers could automatically build it based on popularity.
Another point to consider is that the formal ontology largely eschews internationalization - freeform tagging means that different linguistic communities can determine their own most-appropriate tags, rather than having a worker group dedicated to translating tags (usually badly).
[1] http://del.icio.us/[2] Some research would need to be done to choose the best clone - there are many available. del.icio.us itself could be used with a "debtag" meta-tag.
[3] http://del.icio.us/doc/api[4] See http://tbray.org/ongoing/When/200x/2005/05/19/XML-Atom for an example of why this is important to keep in mind. [5] Consider that the advantage that tagging lends is that it allows better-than-fulltext search with minimal investment. If you tag a package with "to:install", what does it matter? Anyone who searches for the "to:install" tag knows what they're getting themselves into.
Attachment:
PGP.sig
Description: This is a digitally signed message part