tags instead of categories (was Re: [SVN] New info.plist keys for description etc.)

[Chris Thomas]

You are, of course, proving my statement that the simple category  
approach is simpler. :)

On Feb 16, 2007, at 12:47 PM, Allan Odgaard wrote:

> build       -- some sort of build system (Makefile, SCons, …)
> framework   -- a framework (OpenGL, Rails, Django, Qt, …)
> gtd         -- some sort of GTD (GTD, GTDAlt, TODO, …)
> mac         -- mac-specific (AppleScript, Xcode, …)
> mail        -- related to emails (Mail, …)
> markup      -- markup language (XML, Textile, reST, …)
> programming -- programming language (Ruby, C, …)
> prose       -- structured text (LaTeX, Markdown, …)
> scm         -- revision control system (Subversion, CVS, …)
> utility     -- stuff which is useful tools (Math, Remind, …)
> web         -- web related (HTML, Symfoni, PHP, …)

For broad categories, for use as the root of a displayed bundle  
hierarchy, the list should be somewhat smaller (and, I think, more  
specific):

applications   -- interfaces to the outside (blogging, web search,  
Terminal, Mail? …)
build          -- some sort of build system (Makefile, SCons, …)
file formats   -- data files, not 'markup' (plist, iCalendar, sshd,  
Tabular, …)
framework      -- a framework (OpenGL, Rails, Django, Qt, …)
markup         -- markup language (XML, Textile, LaTeX, Markdown,  
tablature, …)
productivity   -- (GTD, GTDAlt, TODO, Remind …)
source code    -- programming language (Ruby, C, …)
scm            -- revision control system (Subversion, CVS, …)
tools          -- generic commands for text manipulation (Math, …)

That gives you three more categories than you originally listed, by  
breaking out the utilities category into applications, file formats,  
productivity, and tools. I don't think there's value in distinguishing  
marked-up prose languages from markup languages, the overlap is too  
wide.

> Do we want to tag for compiled, script / interpreted? Probably not…
> Do we want to tag for procedural, OO, functional, …? Might be  
> useful. E.g. how many functional languages do we have support for?  
> etc.

I would say not. You can end up in a debate over, for example, the  
features required for a true OO language, or for a true functional  
language. Does Ruby get the 'functional' tag? Does C++ get the 'OO' tag?

> Also, each language should be tagged with its own name, so that  
> supporting bundles can be tagged with it as well. So for example  
> seeing all bundles tagged ‘python’ will show all bundles which are  
> somehow related to Python.

The app could also add the name of the bundle to the tag list  
internally.

> Question: what about bundles containing multiple things? Do we just  
> add multiple tags, do we split the bundle (nah…), or do we maybe tag  
> individual commands (confusing)? For example the Ruby bundle has a  
> command for running rake, does that mean it should be tagged  
> ‘build’ (to indicate that the bundle is for a build system)?

Tag for the user of the bundle. Ruby is for Ruby programming. Rake is  
still Ruby code.

>> It's possible this is better implemented through an external  
>> mechanism rather than directly in bundles.
>
> I don’t follow that. What do you mean?

Instead of tags in the bundle, use a file listing bundles needed for  
one particular task, the "Rails Development" file would include Ruby,  
Rails, HTML. This would probably be simpler for user customization in  
a dynamically-switched-subset scenario.

I don't know. It does get complicated. Maybe it's better to hold off  
until the need is clear.

Chris