[Rubygems-developers] Suggestions: categories and querying

Gavin Sinclair gsinclair at soyabean.com.au
Thu Sep 16 10:42:35 EDT 2004

On Thursday, September 16, 2004, 7:48:10 PM, Mauricio wrote:

> Well the code is there, but the ontology is yet to be created...

Do you know of one ripe for the stealing?

> I'm not sure it does what you want though: it handles hierarchical
> classification, not a keyword-based one, and it is self-validating in
> the sense that unknown classifications are rejected.

I like the thought of a small set of categories, and limiting gems to
those.  The aim is to assist casual browsing.  I do believe that the
responsibility for finely categorising gems lies with higher-level
tools, like websites.  I don't know what Chad has in mind for
rubygems.org, but having reviews of packages, etc., as well as
categorisation/keywords, sounds like fair game.

>   In general, the categorization in RAA is horrible :-(

Damn right...

> In the past you ("the RubyGems team") have expressed your concerns about
> classifications being too rigid, etc. I believe that the hierarchical
> classification should be managed carefully (look at RAA...), but you
> can give quite a lot of free room for developers by:
> * allowing multiple categorization
> * providing a keyword-based system in a addition to the hierarchical approach.
>   You'd have to find a way to encourage reuse of existent keywords,
>   while making it possible to introduce new ones. 

Yeah, I'm really starting to think that gem-level classification
should be very limited and strict.  Keywords are too wishy washy and,
like I say, belong at a higher level.  And if you need more than one
category, then the scheme is too fine-grained for this purpose.


Heck, I don't know! :)  All I do know is that "classification" is the
correct term, not "category".

>> Speaking of summary and description, there's confusion in the community
>> (OK, in my head) about how best to use these fields.  

> These are some of the informal rules I'm following for the descriptions
> in RPA:
> * first line should contain a brief synopsis. Better not repeat the
>   name, e.g. "Simple templating library" is better than "Foo is a simple
>   templating library."

That reminds me: there could be a 'project_name' attribute.  E.g. the
gem named sqlite-ruby may have a project name of Ruby/SQLite; diff-lcs
might be Diff::LCS, etc.

> * a longer description follows after a blank line. This must contain
>   enough information to be able to decide whether it's worth installing
>   or not, but shouldn't provide usage info, etc.
> [...]

Thanks for the references and examples (that I snipped).

>> I'm tempted to advise people to give a brief summary (they already
>> do) and this:
>>   spec.description = File.read('README')

> Ouch better not IMHO, the README normally contains *far* more information
> than needed, and its format is not appropriate for the description in general.

OK.  What about a 'readme' attribute?  On first thought, that could
seem to be taking it too far, but Curt suggested it a while ago.  The
context was GUI frontends.  In such an application, I'd like to be
able to read the README of a package in a convenient manner.  If
that's agreed as a good feature, there are three possible
 1. A 'readme' attribute containing the text
 2. Downloading the gem and extracting the README
 3. Serving it directly from the server as a separate request

The last two options imply a 'readme' attribute is needed anyway, but
it would contain a filename, not the content.  Option 2 is bad for
large binary gems.  Option 3 is perhaps more complicated than we'd
like.  Might as well go for option 1, if any.  Heck, it's probably
only me who wants to see the README anyway :)

>> Some agreement on this would be good, leading to some documentation, and
>> ensuring that the implementation is good, regarding formatting, etc.

> And you also have to find ways to encourage good practices without
> hindering the freedom of those who really know what they are doing. This
> is pretty hard...

Yeah, so it's best to be conservative at the low level.  Even just
'library' vs 'application' is troublesome; some packages contain


More information about the Rubygems-developers mailing list