[WikiEN-l] Types of categories

Ray Saintonge saintonge at telus.net
Wed Jun 7 18:29:32 UTC 2006


Anthony DiPierro wrote:

>On 6/4/06, Roger Luethi <collector at hellgate.ch> wrote:
>  
>
>>On Sat, 03 Jun 2006 17:27:59 -0400, Anthony DiPierro wrote:
>>    
>>
>>>>Categories based on such intersections of attributes are conceptually bad.
>>>>Look at the categories for an article like [[Marie Curie]]: She's French
>>>>three times, female four times, Polish four times (not counting "Natives of
>>>>Warsaw"), etc. Why not create [[Category:Polish women who were born in
>>>>1867 and died in 1934 and won a Nobel Prize in Chemistry and in Physics]]?
>>>>        
>>>>
>>>Because there would only be one person in that category.
>>>      
>>>
>>That's why nobody made it, but not why it shouldn't be done.
>>    
>>
>I'd say it's both.  There shouldn't be categories with only one
>article in them.  IMO that's just common sense.
>
They should be avoided, but I would not proscribe them.  If you are 
sub-categorizing mammals you still need to deal with the ones that are 
so different (like the platypus) that they will end up in a one article 
category.

>In the current system categories should have a fair number of articles
>in them.  If there are too many, they should be broken up.  If there
>are too few, they should be combined.  There isn't a crystal clear
>line what constitutes too many and what constitutes too few, but a
>category with only one article in it clearly has too few.
>
>The problem of categories having too many articles in them wouldn't
>really be a problem if the software allowed you to automatically
>compute category intersections.  But the software doesn't do this, so
>people make do with what they've got.
>
Exactly

>>For instance, how do you connect the districts of Paris to the category
>>Paris? What is a subset of the parent attribute "Paris": "Districts of
>>Paris", or "Quartier Latin", or neither? Does it bother you if the article
>>on a French district is now in a subcategory of "Capitals in Europe"?
>>    
>>
>[[Category:Paris]] is a theme, not an attribute, so [[Category:Paris]]
>should not be a subcategory of [[Category:Capitals in Europe]].
>
Is it practical to have people debating whether something is a theme or 
an attribute?

>>Or going back to [[Category:Women]]: You could declare that only articles
>>on instances of women (i.e.  biographies) can ever be under that category,
>>and that only sets of such articles can ever be subcategories of the
>>category women. -- You could even create a separate [[Category:Woman]],
>>subcategories like "female reproductive organs" containing articles like
>>uterus. -- But how would you express the undisputed relationship between
>>female human beings and your example [[Category:Feminine hygiene]]? How
>>about [[Category:Women's rights]]? Add an umbrella cat "Somehow related to
>>women" maybe?
>>
>>Roger
>>    
>>
>[[Category:Women]] could be a subcategory of [[Category:Woman]].
>Making an attribute a subcategory of a theme is allowed, it is the
>reverse that is not allowed.
>
Avoid distinctions that will have to be re-explained every time another 
newbie joins.

>In any event, things wouldn't be perfect.  Ultimately the best
>solution would involve fixing the category system itself, a process
>which should be approached carefully so as to avoid making the same
>mistakes all over again.  The advantage of my proposal to not allow
>themes as subcategories of attributes is that it can be implemented
>today, without much disruption, and without modifying any code.  Plus,
>it allows for a relatively straightforward upgrade path when the
>category system is fixed.  The proposal itself is not the fix, it's a
>temporary workaround.
>
>As an alternative, it would probably be possible to do all of this
>even without enforcing the subcategory rule.  But all purely attribute
>categories would have to be identified as such.  I'll have to think
>about that.
>
One can work towards this, but any enforcement is a bit like passing a 
law that requires everybody to think logically.

Ec




More information about the WikiEN-l mailing list