[Rubygems-developers] Suggestions: categories and querying
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 :-(
> 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