[Catalog-sig] Category suggestions

[Ian Bicking]

On Jun 18, 2004, at 8:26 PM, Richard Jones wrote:
>> Maybe the properties should also be removed and turned into normal
>> fields.
>
> Yes, this has come up before. I think it's a good idea, but I'm unsure 
> about
> how to go about it. Someone has also pointed out that the license 
> field could
> be used to include the entire license text. I'm not sure whether that's
> useful though.

I think the hierarchy that the trove categories use are useful, 
specifically the OSI hierarchy, and classifying some of the different 
proprietary licenses.  At the same time, belonging to multiple license 
categories doesn't make sense, and at least one should be required 
(even if they just choose "other").

> For your list, I've implicitly agree to changes you proposed unless I 
> note
> below:
>
> + Environment :: Embedded
>
>
>> Natural Language :: English (?)
>
> For non i18n, it's good to be explicit.

The difficulty to me is that there's a lot of libraries, and this 
shouldn't apply to libraries (unless they are not English).  For 
applications this is more interesting, but this is the obvious default 
for almost all libraries.

>> Operating System :: OS Independent
>>    (generally, the OS categories seem excessive for Python)
>
> They can be important though.

Again, they shouldn't apply to most libraries.  But I suppose OS 
Independent is good enough for most.  A "pure python" category might be 
nice.

>> Programming Language :: Python
>>    (well duh it uses Python)
>
> Yeah, this section does seem silly. I guess the only important 
> selections here
> are Python, C, C++ and Java. Perhaps C# too?

Kind of... I can imagine other things meant to integrate between 
languages -- e.g., Fortran and Python.  Or source code generation, or 
build environments, etc.  But that doesn't mean that each language 
needs its own category, maybe Programming Language :: Other is enough.

>> Topic :: Communications :: Email :: Address Book
>> Topic :: Communications :: Email :: Email Clients (MUA)
>> Topic :: Communications :: Email :: Filters
>> Topic :: Communications :: Email :: Mail Transport Agents
>> Topic :: Communications :: Email :: Mailing List Servers
>> Topic :: Communications :: Email :: Post-Office
>> Topic :: Communications :: Email :: Post-Office :: IMAP
>> Topic :: Communications :: Email :: Post-Office :: POP3
>> + Topic :: Communications :: Email :: Client
>> + Topic :: Communications :: Email :: Server
>
> We'd want to heelp Filters - for things like spambayes, etc.

Yes, there are a bunch of those.

>> Topic :: Communications :: Internet Phone
>> Topic :: Communications :: Telephony
>>    (both?)
>
> Technically they are separate things, but I'm not sure there's going 
> to be
> enough packages to warrant two categories. Let's just go with 
> Telephony.
>
>
>> + Topic :: Database :: RDBMS wrappers
>
> IMO this could be confused with the DB-API wrapper. Perhaps 
> Object-Relational
> wrappers?

There's a lot that aren't ORMs, like SQLDict or things like that.

>> Topic :: Internet :: WWW/HTTP :: Dynamic Content
>
> Hrm - I'm not sure why you prefer Frameworks over

"Dynamic Content" seems very vague to me.  Any web application could 
qualify.  Hmm... there should be some category to distinguish actual 
web applications from libraries.

>> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI 
>> Tools/Libraries
>> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Message Boards
>> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: News/Diary
>> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Page Counters
>> + Topic :: Internet :: WWW/HTTP :: Frameworks
>> + Topic :: Internet :: WWW/HTTP :: Frameworks :: CGI
>> + Topic :: Internet :: WWW/HTTP :: Frameworks :: mod_python
>> + Topic :: Internet :: WWW/HTTP :: Twisted
>> + Topic :: Internet :: WWW/HTTP :: Zope 2
>> + Topic :: Internet :: WWW/HTTP :: Zope 2 :: Products
>> + Topic :: Internet :: WWW/HTTP :: Zope 3
>> + Topic :: Internet :: WWW/HTTP :: Zope 3 :: Products
>> + Topic :: Internet :: WWW/HTTP :: Content Management
>>    (Actually, I'd rather rethink all of Internet)
>
> Yes, given that Twisted and the Zopes are both more than just 
> WWW/HTTP. I'd be
> happy to knock them back a notch:
>
> + Topic :: Internet :: Twisted
> + Topic :: Internet :: Zope 2
> + Topic :: Internet :: Zope 2 :: Products
> + Topic :: Internet :: Zope 3
> + Topic :: Internet :: Zope 3 :: Products

Sure.

>> Topic :: Office/Business :: News/Diary
>>    (It's not clearn why this is Office/Business)
>
> Yeah. I think most of the Office/Business topics could be relabelled
> "Organisational" or some similar Adjective.
>
>
>> Re: Topic :: Scientific/Engineering
>>    (It might be good to get input from someone who cares about this
>>    area)
>
> I can actually have a good crack at this - I'm doing a review of Field 
> Of
> Knowledge classification systems for work. Off the top of my head, the 
> set
> here is pretty good.
>
>
>> Topic :: Software Development :: Disassemblers
>
> decompyle?
>
>
>> Topic :: Software Development :: Documentation
>
> docutils, et al?

That's true, I was thinking of actual documentation, but documentation 
tools makes sense.

>
>> Topic :: Software Development :: Object Brokering
>> Topic :: Software Development :: Object Brokering :: CORBA
>>    ("Object Brokering" a loaded term)
>
> Yes, but there's a number of schemes in Python that do it.

I feel like there should be some better term, though -- one which 
doesn't feel so specific to CORBA and that era.

>> Topic :: Software Development :: Version Control :: RCS
>> Topic :: Software Development :: Version Control :: SCCS
>> + Topic :: Software Development :: Version Control :: Subversion
>
> Do we need sub-topics?

I think it would make sense -- there's a number of tools and 
applications built on Subversion and CVS, and they are pretty tied to 
that backend.

>> Topic :: Software Development :: Widget Sets
>
> There's a number of Python GUI implementations. I'm not sure where 
> else they'd
> go. Perhaps we need
>
> + Topic :: User Interface

Hmm... "User Interface" maybe sounds too vague, but you're right there 
should be something.  Maybe GUI would be clearer.

>
>> Topic :: System :: Systems Administration
>>    (Audience, not Topic)
>
> I agree the subcategories could go away, but the category is useful. 
> Audience
> and Topic are separate concepts (a package may be for system 
> administrators,
> or it might implement system admin tools for use by other people)
>
>
>> Topic :: Text Editors :: Text Processing
>
> docutils et al?

But in Text Editors?  Maybe moved somewhere else.  Also I can't 
remember if there's good categories for HTML and XML (where HTML is 
separate).  There's a lot of tools specific to that.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org