Wikipedia talk:Category math feature

message: There is a new proposal, called "Category intersection" that is very much like this "Category math" proposal.  It addresses some of the concerns noted on this talk page, and has mockups and descriptions for how it might be implemented.  Please take a look.  Thanks. -- Samuel Wantman 23:45, 30 August 2006 (UTC)
replies: text: Okay, but straw polls are just to gauge opinions (Wikipedia:Straw polls). -- Zondor 15:41, 5 February 2006 (UTC)

text: I see the appeal (of "category and all its subcategories), and would like to see that too, but those kinds of joins in SQL (unknown quantity of joins as you don't know how many subcategories there are) are not fun.  Creating a new structure is a possibility, where a page is linked to its category, and then records referenceing higher level categories are also created, but this creates a whole other set of problems... I think a fixed depth list is the most pragmatic solution (pages in this category and all its subcategories).  I'd very much love to hear any other ideas...--Aerik 05:10, 30 March 2006 (UTC)
thread_title:  Update 

message: :This is a straw poll only to gauge opinions, not consensus decision making. Sign your vote below.
* Support. Categories then need not be so specific, awkwardly long and esoteric, making the organisation so much better. -- Zondor 15:04, 5 February 2006 (UTC)
thread_title: Straw poll

message: While in principle this is a good idea, we'd have to think carefully about exactly how it would work....
One issue that occurs to me is who we handle subcategories. Suppose we take two categories X and Y, then we define category Z = X intersect Y. What you'd expect this to do is that Z would hold all pages in both X and Y. Since subcategories are special types of pages, one would then expect that it would hold all categories that are subcategories of both X and Y.
However, that is often not what you'd expect. Suppose we have the following (concocted) categories:
*Scientists, with subcategories: Physicists, Chemists, etc.
*European people, with subcategories: French, German, etc.
Now suppose I want to make a European Scientists = European people * Scientists. You'd expect it to have subcategories "European Physicists", "European Chemists", "French Scientists", "German Scientists", etc., etc. However, in actual fact it has none of those; indeed, if Scientists and European people directly have no pages, chances are the intersection would be empty. It would only have pages directly in both categories or subcategories with both categories as immediate parents.
Someone has already suggested some sort of "subtree" operator. Firstly, as any programmer will tell you, dealing with hierarchial relationships in SQL is a big PITA. Secondly, it has the chance to turn a small reasonable sized category into something absolutely massive. Thirdly, it loses the useful internal structure of the categories.
Let me propose a solution:
* We use for intersection the syntax Category:A/Category:B. Thus, you can intersect any set of categories you choose just by typing in the address bar "/wiki/Category:A/Category:B". You can also link to any category intersection with :Category:A/Category:B. My reason for choosing the / is so it works fine in URLs.
* When intersecting categories, we pick up all pages in both categories, plus all subcategories of either subcategory. However, when we pick up the subcategories of A, we intersect those categories with B, and vice versa. i.e. if Category:C is a subcategory of Category:A, then Category:C/Category:B is a subcategory of Category:A/Category:B
* Say you want to give the name (X) to Category:A/Category:B. You can edit Category:X and add some markup (similar to #REDIRECT</nowiki) to redirect the X category to the A/B category
* The system should ignore as invalid any links from a page to an intersection category or a category that redirects to an intersection category
* You can mark Category:A/Category:B page with a title (say using syntax like <nowiki>X -- thus is not a conflict with anything else  since we have already forbidden intersection categories from getting members) which will be used in any lists. So, if Category:C/Category:B gives itself the name P this way, Category:A/Category:B page will output a link named P to Category:C/Category:B page
* I think intersection is the main requirement, and supporting anything else might make it too complex than needed. But, if you really want other operators, you can extend the syntax like this: Category:A/union/Category:B, Category:A/minus/Category:B, etc.
* If we abandon the idea of other operators, we could simply Category:A/Category:B to Category:A/B, assuming no "/" are already in category names.... (OS/2?)
* Another alternative to the / could be :, e.g. Category:A:B. This is less likely to conflict with OS/2 and friends.
* Also, this could work for as many terms in the intersection as you like, e.g. Category:A/Category:B/Category:C, etc., although for performance reasons we'd want some limit (2? 3?)
* Implementation detail: we need to define a cannonical form, e.g. split on the / and sort in ASCIIbetical order, before we store in the database. This is so that when we want to find that Category:C/Category:B has name P, we just need to search on one orderring (B/C) and not on two (B/C,C/B). Also, any category intersection not in cannonical form, it should treat as if it is in cannonical form. Thus if you put text in Category:A/Category:B, and then go to Category:B/Category:A, you'll get the exact same page.
anyway, that's my proposal.
Although in a perfect world something like this is a good idea, I fear that:
# it would be easy to do in a way which wasn't really that useful
# it would be a fair bit of work to do it properly (in a way that was really useful), and its not clear to me that the extra programmer effort and complexity in the code (which then has to be maintained) would be worth the benefits
--SJK 10:58, 25 March 2006 (UTC)
thread_title:  Handling sub-categories 

message: Isn't this similiar to DPLs? Bawolff 01:18, 27 March 2006 (UTC)
replies: text: Yes, in fact, it is. Thanks. -- Zondor 04:36, 27 March 2006 (UTC)
replies: text: It's worth noting that the end result of DPLs is similar, the implementation and use are different.  This is an alternative, imho more powerful, way of viewing all the categorized or tagged information in a wiki - DPLs do somethign very similar to dynamically create a list of fixed parameters.  I think this approach implies  more general (like "not as specific" not like quantitiy) categories, and finding information where they intersect.  The subcategories are the most significant hurdle of this endeaver, again imho.  BTW, I wrote the implementation mentioned on meta, and would be happy to re-write it for mediawiki 1.5/1.6.  I'm sure it could stand some scrubbing by a more knowledgeable PHP guy than I, but the SQL I'm using is pretty solid and more efficient that what is (or was when I checked) being used for DPLs.  --Aerik 03:44, 29 March 2006 (UTC)
replies: text: DPL could do much of what I'd like to do.  It would help if it was extended to the point that one could express (A or B or C) AND (D).  Some way to deal with subcategories would help, too.  But DPL is a good first step. --John Nagle 21:44, 27 April 2006 (UTC)
thread_title:  this vs DPL 

message: This proposal seems to completely misunderstand what categories are for. It is not the case that people only use Wikipedia to search for things they know they want. The present category has immense value as a means of facilitating unplanned browsing, and it would be an unmitigated disaster to wipe out all the detailed categories as proposed. Chicheley 21:46, 13 July 2006 (UTC)
thread_title: The main value of categories is being completely ignored here