Wikipedia talk:Category intersection/Archive 1

message: I haven't read all of this, but shouldn't the Laurence Fishburne article in your example end up with categories such as "MASH", and not "MASH Actors", "Miami Vice", and not "Miami Vice Actors"?  If someone wants to know the actors in Miami Vice, they should be able to check the intersection of those two.  Just a thought. --Kbdank71 11:01, 30 August 2006 (UTC)
replies: text: I think the counter-example here is an actor who later becomes associated with Miami Vice, but not in an acting role. For example, if a famous actor produced or directed Miami Vice. Looking at the "American people" example, you might similarly ask why you can't intersect "American" and "people". I think these sort of cases will make it difficult to pin down the concept of a primary category, but I do like this proposal. I just haven't had time to read it again and decide which bits I like best. Carcharoth 11:09, 30 August 2006 (UTC)
replies: text: It is possible to have the category "Actors" and the category "MASH".  People would just need to realize that the intersection is not necessarily "people who acted in MASH", but is instead "People involved with MASH who also are Actors".      I suspect this will get to be a commonly understood distinction.  CFD will probably have discussions about whether a category should be replaced with an intersection or vice versa. -- Samuel Wantman 19:54, 30 August 2006 (UTC)
thread_title:  Laurence Fishburne 

message: Some of these may have been mentioned already, but just in case....
Existing software that's good to be aware of:
# The intersection mediawiki extension - aka DynamicPageList2.
#: This extension now (February 2007) has some new features. See the new homepage at mediawiki.org and the special DPL demo website.  I (mw:User:Algorithmix) continued the work of Unendlich, Dangerman, Haykinson and Amgine. I am interested in making DynamicPageList even more powerful and eventually positioning it as an official part of Mediawiki software.-- mw:User:Algorithmix 14:03, 17 February 2007 
#:: I don't have experience with this...  you can try pinging the contributors (n:en:User:IlyaHaykinson, n:en:User:Amgine, w:de:Benutzer:Unendlich, m:User:Dangerman) and seeing if they have comments about real-world use (eg. is it slow?  what sort of categorization schemes do they find work well?)
#::Pong. Two comments:
#::#Real world, server load and speed. Logical operations on categories generate complex database requests. We tried to keep the SQL queries to a minimum in DPL2 and I am not aware of any complaint on speed or load. But it doesn't mean there may be issues with big wiki communities like Wikipedia. However, for comparison, the DPL (not yet DPL2...but they have the same load and speed concerns) seems to be used successfully on Wikinews (see n:Wikinews:DynamicPageList). For other real-world info, there is a stub list of DPL2-powered wikis on the extension page. I hope this helps a little bit.
#::#User interface. I don't think the user interface - or I'd say the way users would do category intersection as mentioned in the proposal - is very flexible, the separate Intersection space in particular. One day, users may want the same thing for Union (you mix up articles from 2 categories together - different from showing articles in category 1, and then in category 2) or Negation (articles not in a category) or all operations together. That's why, on the long term, offering the user syntax of Category_math_feature seems like a more logical and flexible solution. --(m:User:Dangerman) Dangerville 13:21, 3 September 2006 (UTC)
replies: text: This proposal calls for reworking most of the categorization system.  I wanted to note that at least some reworking is required to make categories useful for automated tools, because the current categorization system is set up to only support human use.  Automated use of current categories (eg. CatScan) can work up to a point, but currently, if you try to search as far as possible in an effort to get complete results, you get increasingly unrelated results the deeper you go.  --Interiot 12:08, 30 August 2006 (UTC)
replies: text: Thanks for the link to the Category Ladder tool. I'd been looking for something like that for ages! I was having to manually construct category trees, and this does it for you! Carcharoth 19:37, 30 August 2006 (UTC)

text: Yes, this proposal calls for reworking the categorization system.  The German language Wikipedia has already repopulated primary categories and has removed intersection categories.  I think it would be a difficult battle to get that to happen here before category intersection is implemented.  Once implemented, more and people will climb on board, and categories can be quickly depopulated, repopulated and redefined. -- Samuel Wantman 20:07, 30 August 2006 (UTC)
thread_title:  Already existing extensions or tools 

message: I need time to think about it, but it looks like a great extension to the category functionality (with possible caveats of "people could be resistant to change" and "I wonder what the processor load would be?"). Syrthiss 12:13, 30 August 2006 (UTC)
replies: text: Categories are currently implemented with a database, and the "large category" performance issue was addressed by limiting the search result.  The intersection search results would be similarly limited, so I think the question boils down to how efficiently the underlying database can do intersection queries and how much such a feature might be used.  In a real time sense, I think an intersection query could be quite fast (google seems to do OK, for example).  It might be interesting to know what percentage of database queries are currently category related.  I don't know, but I'd guess not much (I'd guess there are way more history, watchlist, and previous version related queries than category queries). -- Rick Block (talk) 13:55, 30 August 2006 (UTC)
thread_title:  This is very interesting 

message: I will have to check the implementation, but I wholeheartedly support this concept.  Subcategorization constitutes, I dare say, 50% of the controversy at WP:CFD ... and boolean categories constitute the other 50%.  But more importantly than making CFD easier, this will actually make categories useful to researchers -- which must be the guiding purpose of any project on Wikipedia.  Right now, our category system is barely an improvement over traditional text searches. --M@rēino 14:03, 30 August 2006 (UTC)
replies: text: I add my full support! -- SatyrTN (talk | contribs) 15:28, 30 August 2006 (UTC)

text: I want this as soon as possible. please implement Chendy 21:38, 2 November 2007 (UTC)
thread_title:  Support 

message: You have in your Laurence Fishbourne example the categories "People from Georgia (US State)" and "People from Augusta, Georgia".  Now forgive me if my US geography is wrong, but isn't it possible to extrapolate the former from the latter?  If we put someone into "People from Augusta, Georgia", shouldn't it be possible to make the database populate Laurence Fishbourne into "People from Georgia (US State)", and even "American people"?
Other than that, yes, it looks like a good idea, and would solve a lot of issues with categorisation.  Be interested in a developer's comments.  Well done! Hiding Talk 21:55, 30 August 2006 (UTC)
replies: text: The issue about these categories, "People from Georgia (US State)" and "People from Augusta, Georgia" is how they are defined, and how they will be used.  We're assuming that people will want to find "Actors from Georgia" or "Politicians from Augusta" etc...  So you need to have an intersection that arrives with the correct population of articles.  The intersection will depend upon how the categories are defined.  Right now, the subcategories of "American people" have people who are American citizens, but the "People from Georgia" are not necessarily citizens.  Politicians from Augusta may be people who are neither citizens nor people originally from Georgia.  The distinctions between these categories can and should be made clearer, and they might change when category intersection is implemented.  It would be possible to categorize any person closely associated with a location with the location.  So ex-mayor Willie Brown could be put in :category:San Francisco not because he was born there, but because he is a person very much connected with the city.  He might also be put in the categories "People born in Texas" and "American people".  There are other ways to do this as well.  These sorts of conversations need to happen with quite a few categories.  The criteria for making decisions about this should be, "What will be people be looking for?" and "What are the primary distinctions?". -- Samuel Wantman 23:38, 30 August 2006 (UTC)
replies: text: Hmm.  How would you stop Willie Brown showing up as a mayor of Texas?  And I'm still unclear as to why it wouldn't be possible for the database to extrapolate back and see someone categorised as a mayor of san fransisco as being categorised as a mayor. Hiding Talk 00:00, 31 August 2006 (UTC)
replies: text: The extrapolation is much more involved.  We have not put that into this proposal.  I'm thinking Willie might be categorized as "Mayors of San Francisco", (perhaps duplicated in "Mayors"), "People born in Texas", "San Francisco", "California Assemblyman", "American people", "Mineola, Texas", "Members of the California State Assembly", "People of African descent", "Politicians", "San Francisco State University alumni", "Alpha Phi Alpha brothers", "Freemasons", "1934 births", "Living people".  This is more categories than currently (my mistake using an undercategorized article as an example!)  I don't think you can say that "San Francisco mayors" is the intersection of "San Francisco" and "Mayor", He is a San Franciscan and a Mineola, Texan who was a mayor.  That doesn't make him mayor of both places.  So "San Francisco Mayors" is not an intersection and would be a primary category.  The value in this proposal is not that it is going to lower the number of categories of all articles.  For many articles, like this example, there will be more categories.  The value is that you will be able to find the intersection of these categories.  "San Franciscan African-American members of the CA State Assembly", "Freemasons from Texas", "San Francisco St. Univ. alumni born in 1934", "Politician Alpha Phi Alpha brothers", etc...  It might be possible to add "Category unions" as the next step in the process.   Unions would remove the need for duplications.  I don't think duplication between parent and children primary categories will be a big problem.  Perhaps only 2 or 3 levels in the hierarchy if at all.  To make this work, categories must be fully populated.  The first option describes methods of keeping categories fully populated that are the union of other categories.  This system could be used in the other options as well. -- Samuel Wantman 02:08, 31 August 2006 (UTC)

text: It might be possible to automatically "upward populate", but I think this would be a little tricky to get right.  The focus of this proposal is intersections, and basically doesn't address the issue of primary categories that are subsets of other primary categories (e.g. mayors of San Francisco and mayors, or people from Augusta, Georgia and People from Georgia).  It's fairly clear for intersections to work, these categories have to be fully populated.  This proposal just doesn't include a solution.   -- Rick Block (talk) 02:14, 31 August 2006 (UTC)
replies: text: Okay, so you're proposing that only specific categories become union level categories, for example category:born in foo.  It seems like this is mostly going to work for geographic categories and top level occupation categories.  I can see a use in this, yes.  It's going to be interesting working out the union level cats, it would certainly allow the cat system to develop a better structure.  It's a shame we can't also work on getting the database to extrapolate, since this would reduce the number of categories that would need to be on a page at any given time.  My hope for the structure was that we could see Willie in Mayors of San Fransisco and this would automatically place him and display in Mayors of U.S. places and Mayors.  Hiding Talk 09:12, 31 August 2006 (UTC)
replies: text: It is possible to have software or bots take care of this.  This is from the first option, but something similar could be added to any of the options.  I'm not sure it is as tricky as Rick thinks. -- Samuel Wantman 09:58, 31 August 2006 (UTC)

text: I'm not saying we can't do this, just that I'd prefer to consider it to be outside the scope of the current proposal.  If we decide on an approach that results in some namespace having permanently protected "metadata" content about categories, it likely makes sense to keep this in the back of our minds as another use of such metadata.  And, BTW, I think it's tricky because any time the software automatically does something in addition to what you've specifically asked there's an issue of whether the automatic thing should be undone if you undo what you originally did.  For example, if (through metadata or any other mechanism) adding an article to "Mayors of San Francisco" causes the article to automatically be added to "Mayors" (and, probably, "Mayors in the U.S." and "Mayors of California cities"), what happens if the article is removed from "Mayors".  Do we automatically populate but not automatically remove?  How many upward lines do we allow, only one or multiple?  Isn't anyone who's a mayor also a politician?  What happens if we introduce a new level of hierarchy affecting existing articles?  Again, I'm not saying this can't be done but there are a fair number of issues that would need to be resolved and I'd rather not have this discussion sidetracked.  -- Rick Block (talk) 14:33, 31 August 2006 (UTC)
replies: text: Sorry, I don't mean to sidetrack the discussion. I'm happy to support the proposal. Hiding Talk 15:05, 31 August 2006 (UTC)
thread_title:  Query on intersecting 

message: Have you seen Wikipedia:Category math feature?  Not sure how similar this is, but there's a good consensus on the talk page Wikipedia talk:Category math feature#Straw poll, although drawn from a small pool which has grown over time. Hiding Talk 22:38, 30 August 2006 (UTC)
thread_title:  Wikipedia:Category math feature 

message: Having just scanned the (seemingly very well-prepared) proposal, I think I'd support its development; the Laurence Fishburne examples suggest it might be very useful. I've printed it out and will read more carefully anon. One question for now, with apologies if I've scanned past the answer: Is there an intention to provide folk with (say) an option on their preference page to use or ignore the system...?
Looks like some sterling work!  Best wishes, David Kernow 01:12, 31 August 2006 (UTC)
replies: text: We're not thinking of a user preference setting to use or ignore the system.  The basic point is to replace manually updated "intersection" categories with automatically dynamically generated ones.   -- Rick Block (talk) 01:58, 31 August 2006 (UTC)
replies: text:  Ah, okay; thanks for clarification. Regards, David 02:45, 31 August 2006 (UTC)
thread_title:  Prima facie support with question 

message: In the dark ages when xml was first coming out, it was proposed by some as a way to search and get good hits.  So you could search for say duck as recipe=duck to only get hits on duck when it was in a recipe.  I always thought that was a needed improvement.  So I see this proposal as a step in the right direction.  It would be nice if it was dynamic rather then something generated.  But I guess that will depend on performance and something is better then nothing.  Vegaswikian 03:02, 31 August 2006 (UTC)
replies: text: I'm not sure I understand the distinction you're making between dynamic vs. generated.  The intent is that these intersections reflect a database query executed at the time the page is requested to be viewed, i.e. the list of matching articles is generated dynamically from the current contents of the intersected categories.  -- Rick Block (talk) 04:14, 31 August 2006 (UTC)
replies: text: We are both looking for the same result then.  I was a little worried by the use of automatically generated above.  As far as I'm concerned, the result is dynamic. Vegaswikian 04:17, 31 August 2006 (UTC)
thread_title:  automatic generation vs the old hype for xml 

message: Good work. I hope people won't bicker too long about the details of this proposal because such a feature is way overdue. I think it makes sense to fast-track this as soon as possible and then reflect in a few months on how well the proposed interface works so that we can make improvements on it. In that spirit, I support the proposal as is. Pascal.Tesson 07:53, 31 August 2006 (UTC)
thread_title:  Can't wait... 

message: So I visit a category this afternoon and there's a new toggle for "Show as tree | Show as list".  Is this new?  Any info, anyone? -- SatyrTN (talk | contribs) 00:29, 2 September 2006 (UTC)
replies: text: See Category Tree !   Regards, David Kernow 03:01, 2 September 2006 (UTC)
replies: text: Or maybe the next link along: Meta:CategoryTree extension. Carcharoth 02:17, 3 September 2006 (UTC)
replies: text: See also Special:CategoryTree! Carcharoth 02:20, 3 September 2006 (UTC)
thread_title:  What's up with... 

message: Where do we go from here?  I've put requests on the talk pages of several developers, including the author of meta:DynamicPageList2 and Brion Vibber.  I put a copy of the proposal in Jimmy Wales hand when I saw him at a meet up two weeks ago. His response (via e-mail) was:
:I read it.  I support it, it seems really powerful.  It brings up a lot of interesting questions, but one of the things I realized while reading it is that too much "a priori" thinking is not needed.  The value of it is clear, and the actual day to day epistemic questions that I start having really will have to be sorted out in the old fashioned wiki style of negotiation and compromise.
So what is the next step to make this happen?  Rick and I have not publicized this widely.  It seems premature to do so before we can get confirmation that this is not going to cause problems with the server load.  Any suggestions as to how to proceed? -- Samuel Wantman 08:35, 2 September 2006 (UTC)
replies: text: I think the next logical step is to make more people aware of it.  It is going to need to have many more questions asked/answered before it is adopted.  Having Jimbo's support is certainly a good start.  The technical feasibility questions need to be evaluated by the MetaWiki Developers before getting too far along.  Cacophony 09:43, 2 September 2006 (UTC)

text: That might be contentious to do (as it is quite philosophical) unless the implementation is about to be done, and done for sure. I think intersecting categories would be very cool and would really like to see it, though... I forsee a lot of the category reshuffling as amenable to bots (put everything in a sub cat in both supers seems automatable to me), but probably not all. The bots should take notes on what they did, I suspect (more than just their contribs log, notes on why they moved something from X to Y) so humans can check their work easily. ++Lar: t/c 14:33, 5 September 2006 (UTC)
replies: text: This is exactly the reason why Rich and I have not been posting links to this page from large community forums.  We first wanted to see if the people who spend a bit of time working with categories would approve of the proposal, then we need to get developers on board.  At that point we can present this as the new software feature that is on the way.  Does anyone read German?  It might be useful to know the history of categorization at German Wikipedia.  Jimmy mentioned that they had already made the decision to move articles into primary categories and deleted intersection categories.  I'm wondering how the decision making process went. --Samuel Wantman 17:38, 5 September 2006 (UTC)
thread_title:  So what's next? 

message: Many ideas in the proposal sound great to me, but much of it sounds too complicated.  I think that adding new pages to the wiki namespace seems unnecessary. "User created category intersection" (the Flickr-like checkboxes) hits the nail on the head.  This could be a very powerful tool for browsing categories.  The user would just select the desired categories, then click a "go" button to open a new search that displays all articles that are contained within all the selected categories.  This would require less work to implement, lead to less categories being required, and it wouldn't have "holes" (any category could be cross referenced with any other category (or multiple categories) without editors having to create intersection pages for every possible combination).  
The other big issue here is fully populated "Primary" categories. The real trick is to make (some/all?) subcategories appear automatically in supercategories.  For example, Lawerence Fishburn should not need to be included in both Cat:People from Agusta, Georgia and Cat:American people.  Being a member of Cat:People from Georgia should automatically include him in Cat:American people.  Ok, I guess that is where it starts getting complicated.  What would be really cool would be to have a simplified category tree appear when scrolling over the category name and then be able to broaden/narrow the intersection "search" that way.  Cacophony 09:29, 2 September 2006 (UTC)
replies: text: It's not quite as easy as that because as I understand it, the People from Agusta is loosely based residency, and American people is more based on nationality.  I think there may need to be some sort of tag on the parent that says what kind of relationship is implied. -- ProveIt (talk) 02:08, 8 September 2006 (UTC)
replies: text: I came across the User:Duesentrieb/CatScan tool which does basically what I was talking about.  It looks like this has been around since the beginning of this year.  I've had limited sucess with it, but it is there.  Cacophony 05:32, 14 September 2006 (UTC)
thread_title:  Simplification 

message: Page is too long and has too much extra prose and too many options. Trim it down a bit? --Brion 14:01, 4 September 2006 (UTC)
replies: text: I think it's important for it to be long enough to expose the various possible options. The idea is not for this to become a policy (in which case conciseness would be an issue) but rather a proposal for major changes in the way categories are handled. Once the talk page has generated a consensus on what options are prefered by users and developers it will be possible to cut it down. Pascal.Tesson 17:00, 4 September 2006 (UTC)
replies: text: It's nine pages printed. That's really too long for a feature request. :) --Brion 10:06, 6 September 2006 (UTC)

text: The interface could certainly use special pages for intersections, it is not currently in the proposal.  Until we know what is possible from the developers, we don't need to make decisions about specifics. -- Samuel Wantman 20:12, 5 September 2006 (UTC)

text: *(unthreading) I saw that, but a namespace implies (1) being able to write things in it, and (2) having to create pages for all conceivable combination. Neither, imho, is true. The intent seems closer to a query like Special:Shortpages. But yeah, technical details are less important than the idea. >Radiant< 20:43, 5 September 2006 (UTC)
replies: text: If the intent is to replace a largish number of existing categories, using a namespace is convenient since it allows things to be written into it but does not require creating pages for all conceivable combinations.  You can't edit a special: to annotate it or put it in a category.  Per my response to Dangerman (above), we could make it more general by using a namespace that does not imply the operation (perhaps "operation" or "catquery"), but I do think it would be useful to use a (writable) namespace. -- Rick Block (talk) 14:14, 6 September 2006 (UTC)

text: That's all very nice, but doesn't this just not say anything new? Everybody loves the idea of category intersections; implementation details are what need to be proposed if you want to get anything done. --Brion 10:07, 6 September 2006 (UTC)
replies: text: I'm confused.  Is it too long or not detailed enough?  Or is it just too many words without enough code? -- Rick Block (talk) 14:14, 6 September 2006 (UTC)

text: Technical advice about the "implementation details" was what I was hoping you (Brion) would bring to the discussion.  From what I'm reading on the wikitech list, it seems that the technical issue is speed.  Is there any other technical considerations we should be concerned about?  I'm assuming that the technical issue can be solved, either with cleaver code, or advancing technologies.  Flickr seems to be able to do what we are talking about, so it seems just a matter of time before this is doable.  As we are a group of people who spend quite a bit of time dealing with categorization issues, it seemed reasonable to start envisioning the type of interface we would find useful and helpful.  If we have a sense of where we are going, we can start moving the masses and categorization policy in that direction.  I began work on this proposal out of the frustration of trying to facilitate categorization policies that would make sense, be useful and reduce conflicts.  As the project grows this becomes more and more difficult if not impossible.  What do you suggest we do to help fix things? -- Samuel Wantman 18:15, 6 September 2006 (UTC)
replies: text: The question I'd like to ask Brion, is what are the cost in terms of database query, for an example how expensive would it be to find the intersection of all mathematicians (aprox 2300 entries, :Category:Mathematicians and its sub cat) with :category:living people? How would the cost change if the intersection of three categories was used? Is it feasiable to have live queries (uncached, allowing a general search) or will they need to be cached beforehand? Or basically would wikipedia grind to a halt if this was implemented? --Salix alba (talk) 20:02, 6 September 2006 (UTC)
thread_title:  Too long 

message: Hello.  I already posed this question on the stub project page.  The question was, in order to see which philosophy articles need expert attention, i.e. to search articles BOTH in the category 'Philosophy' and 'Needs Expert Attention'.  I'm gathering from this page that it may not be possible.  If not, add my name to the list of people who would like it.  You can see the enormous power of this for those of us trying to make this place better. Dbuckner 15:49, 4 September 2006 (UTC)
replies: text: Amen to that. I often try to cleanup the backlog of articles with unclear importance and I often would love to be able to group articles together. This would help for instance when asking help, say, to the Wikiproject chemistry for the numerous chemical compound pages tagged as unimportant. Pascal.Tesson 17:03, 4 September 2006 (UTC)
replies: text: CatScan may be sufficient for purposes like this (and I believe it is well used by a variety of folks at the stub sorting project).  My real intent for this proposal is to replace many (all?) of the existing manually maintained "intersection categories" with dynamically generated content.  I'd prefer if a side effect were that many of these categories completely ceased to exist as well. -- Rick Block (talk) 19:35, 4 September 2006 (UTC)
thread_title:  Question 

message: From: Simetrical 
:On 9/4/06, Samuel Wantman wrote:
:I'm writing to ask a developer to take a look at a proposal being developed at English Wikipedia at:
::http://en.wikipedia.org/wiki/Wikipedia:Category_intersection...
See http://bugs.wikimedia.org/show_bug.cgi?id=5244 and the various
things duped to it.  I'm pretty sure performance would be a major
issue here; for instance, finding the first 200 pages in a category is
limited to iterating over 200 members of the category, and likewise
for all other operations currently supported by categories (as well as
unions), but finding the first 200 pages in the intersection of two
categories has no upper bound on the number of iterations required:
you have to go through every page in each category in the event that
they have fewer than 200 shared pages and neither is a subset of the
other.
Has anyone written code that can handle this efficiently?  Is such
code even possible?  Storing and updating expensive and often-used
intersections as sort of "virtual" categories would probably be a good
idea to begin with, but I'm not exactly knowledgeable on either
databases or caching.  When I mentioned it on IRC, Domas (database
person, works for MySQL) was pessimistic.  In addition to what I noted
above about an unbounded number of checks, he also pointed out that
intersection tends to make categories larger, which also affects
performance.
So, as someone who has little personal knowledge of the issue, I'd
hazard a guess that if one of the few devs who are knowledgeable
enough about efficiency and databases and the MediaWiki schema (most
likely Tim, I'd imagine) were willing to write the code, it could
maybe be good enough to be acceptable, but otherwise I doubt this will
be implemented.
:::(copied from e-mail -- Samuel Wantman 01:37, 5 September 2006 (UTC)
replies: text: I think this all depends on how the database works.  SQL syntax certainly supports "AND" queries, but  MySQL might not have a tremendously efficient intersection algorithm.  I think a "perfect" algorithm for a x2 intersection results in at most 2N database fetches where N is the number of elements to be displayed in the intersection.  The database fetches are likely of blocks of some number of consecutive elements, so fetching N consecutive elements results in N/blocksize fetches.  I think this means an intersection might be considerably more expensive, potentially involving a factor of (blocksize*2) more fetches than a simple list of N members of a category.  Assuming a reasonable blocksize (maybe 4K bytes), this factor might total anywere from 20 to something like 1000.  Note that this is worst case, but assuming a perfect intersection algorithm.  Less than perfect and it gets worse. Worst case is no overlap at all, and all database records for each category being intersected must be fetched.  Consider intersection:even numbers::odd numbers.  On the other hand, my guess is that "intersection categories" are accessed infrequently enough that this factor really doesn't matter unless it makes it perceptably slow. -- Rick Block (talk) 04:05, 5 September 2006 (UTC)

text: Of course efficient implementation is a big problem but isn't there some hope that the structure of the categories and the fact that the same intersection queries will likely be asked over and over can be exploited here? Pascal.Tesson 13:58, 5 September 2006 (UTC)
replies: text: It might be possible to cache the results of intersection queries and before executing the query again check if any of the categories being intersected have changed.  In general, this doesn't help the worst case analysis because there must always be a first time any given query is executed.  Caching the database records (in memory) in the Apache servers would help offload the database and, in practice, might be sufficient.  I think there's some caching of database records that is already done, but I don't know the details of this. -- Rick Block (talk) 17:36, 5 September 2006 (UTC)
thread_title:  Simetrical's response from Wikitech-1 mailing list 

message: I've given it a cursory glance, and I like what I see. I'll write a detailed opinion later. Dread Lord CyberSkull ✎☠ 03:38, 5 September 2006 (UTC)
thread_title:  Looks nice 

message: So what we could well be looking at is a complete overhaul of categories, for example having categories that are defined as born in fooand  naturalised citizen of foo, which sit inside nationality people and would also be top level categories?  I'm not sure how to catch the overlap though. What sort of definition doe we place on our nationality categories? Are we going to have to completely overhaul the category structure?  Are we going to have to be more rigid in our categorisation policy? Hiding Talk 09:11, 8 September 2006 (UTC)
replies: text: I'm not sure we need to plan every detail about categorization policy before implementing this.  There will be a natural desire to make categories that create useful and meaningful intersections.  Perhaps "useful and meaningful" is all we need to have as a policy.  Things can evolve.  I do wonder about the issue about the "x is a y" and "x is related to y" duality to our categorization structure.  Clearly, "x is a y" is not a problem when creating intersections.  I don't think "x is related to y" would be a problem either.  For example, if you take :Category:George W. Bush which is a "related to" category and intersect it with :Category:Children's books you end up with an intersection that contains The Pet Goat.  If the categories are "related to" the intersections will be as well.  But as this is a source of confusion and conflict with our current system, it will remain so with an intersection system. -- Samuel Wantman 09:56, 9 September 2006 (UTC)
thread_title:  Tossing some thoughts out 

message: I find this proposal the right approach to solve supercategorization and long discussions about where and how put an article. On italian Wikipedia, I have made a simple SVG that can be useful to explain the differences in this two categorization approaches in Anime and Manga case ( read the discussion), where genres are the same for both and things like shounen anime and shounen manga are redundant, confusing and create an huge amount of subcategories. Since I've put that SVG in Public Domain, you can copy and modify it without restriction (using an SVG editor like Inkscape) to represent other supercategorization cases. --Dzag 10:03, 4 November 2006 (UTC)
thread_title:  Anime and Manga case 

message: Much of what you (and I) are looking for is described as Faceted classification, which is fundamentally about intersections of semantically orthogonal facets. 
Of course, we could have lots of arguments about what constitutes a "proper" facet as well as whether a "faceted approach" should include multiple picks from the same facet. -- PhilMurray46 16:44, 14 November 2006 (UTC)
thread_title:  Also check out Faceted classification 

message: I see it mentioned a few times on this page. Is there a reason why meta:DynamicPageList or meta:DynamicPageList2 are not turned on in en-wikipedia? It seems like it would be very useful. Carcharoth 10:41, 12 January 2007 (UTC)
thread_title:  DynamicPageList 

message: I like the proposal at Wikipedia:Category_intersection#Category_viewed_as_an_outline. I was vaguely aware of this, and there is currently a way to rather kludgingly do this in a manual and non-updateable way. See what I did at :Category:Earthquakes, :Category:School massacres and :Category:Anti-communists. What I want is category union. Intersection seems to talk about category A AND category B, when I am also interested in category A OR category B, with tweaks to allow simple union to a specified depth (ie. specify a depth of 3 go down three levels into the subcats, and unify and list all the articles in the subcats and the original parent category), as opposed to, say, unifying two unrelated categories. What I really want is feedback on whether the linking to page history that I did is acceptable, and whether such lists of all articles in a set of categories are useful. Carcharoth 10:53, 12 January 2007 (UTC)
thread_title:  Temporary flat category solution? 

message: I have a page up for testing some code which does category intersections using a boolean search on a MySQL fulltext index of a table containing all the categories for each page.  My database is copied from November and only has the tables I needed to test this code.  
http://aerik.com/wikintersections.php
I know the interface is no good, but I am trying to collect statistics about query performance.  Please take a look and run some intersection queries.  Thanks, --Aerik 18:37, 16 January 2007 (UTC)
replies: text: Looks good. Would you be able to comment on the above two sections as well? I would dearly love to unify any number of categories I selected and create alphabetical indices for large numbers of fragmented categories. Would your system do that as well as intersection (ie. would it do OR as well as AND)? Carcharoth 11:48, 17 January 2007 (UTC)

text: Just to try some worst case queries, I intersected :category:Living people with :category:album covers (no intersection, query took 4.8575 seconds) and :category:Living people with :category:Disambiguation (one intersection, query took 7.2953 seconds).  I don't know if these are elapsed or CPU times (seem to be elapsed).  My understanding is that in at least some cases MySQL processes queries serially, so while one of these is running other queries would wait.  Running some more tests, specifically intersecting :category:Unassessed_Tolkien_articles with :category:Top-importance_Tolkien_articles at the same time as one of the long running queries, it appears reads involving different specific database records are not serialized (and, with this interface there's no way to try simultaneous writes, so I have no idea how writes would interact with these long running reads).  The smaller intersection finished quite quickly when starting it during a long query, but repeating the same long running query while one is already active seems to slow down both (implying multiple reads using the same index record are processed concurrently).  Intersecting :category:Living people with :category:Living people (!) takes 15 seconds or so of elapsed time, but the query result says 0.0045 seconds.  I think the bottom line is that with read-only access it seems to not be too bad but we should have considerably more benchmarking involving simultaneous read and write operations before imagining we might be able to deploy anything like this to the live en database server(s).  It seems like it might be worth getting a MySQL performance expert to comment about this. -- Rick Block (talk) 18:02, 21 January 2007 (UTC)
replies: text: Thanks for the comments. Over here someone asked when Category Intersection is likely to happen. I said it was anyone's guess, really, but if anyone here can say something more informative, that would be great. Carcharoth 12:51, 23 January 2007 (UTC)

text: Great. Thanks for the update. Let us know what is happening and if we can do anything to help, like run more tests. I'll try and keep an eye on this page. Carcharoth 23:29, 23 January 2007 (UTC)
replies: text:  Carcharoth, thank you!  More tests would be great!  I'll post more as soon as I have any data/updates.  --Aerik 19:57, 24 January 2007 (UTC)
thread_title:  Some test code for intersections implmented in a fulltext index 

message: look for octogenarians, for example. Just search for an intersection between :category:living people and :category:1918 births until :category:1927 births. --Wirosableng 20:33, 24 February 2007 (UTC)
replies: text: Yes I agree, I think we should start a voting process for this proposal and if the majority agrees, the developers could begin the work. --Drgerard 17:06, 25 February 2007 (UTC)
thread_title:  If this is implemented it would make it a lot easier to 

message: This system misunderstands what categories primarily for, which is browsing, not searching. If implemented people might now and again find it useful as a search function, but they would miss out on  all the detailed connections that one comes across serendipitiously with the current detailed system. Therefore it should be abandoned. Casperonline 15:26, 27 March 2007 (UTC)
replies: text: I think it would make it easier to browse, which was part of the inspiration for writing the proposal.  All the current categories would still exist in some form, and many more would be possible using intersections.  Every topic would have fully populated categories and you could navigate to fully populated sub-topics or intersections.  Of the three ways we mocked this up, the first would look almost identical to what we already have, so why is the serendipity lost? -- Samuel Wantman 09:03, 28 March 2007 (UTC)
replies: text: After a lot of problems in WP Films categorization and taking in consideration all views presented, I also think this system would help rather than wreck browsing. Actually it doesn't wreck at all the browsing of articles, it just involves having the primary category additionally populated, offering multiple possibilities, whereas our present conventions limit them. I was also scarred when I first learned about it, but as problems continue to accumulate unanswered, I start seeing its huge merits. Hoverfish Talk 14:22, 10 April 2007 (UTC)
replies: text: I agree as well it would help browsing. For example, recently I was browsing :Category:FA-Class biography (arts and entertainment) articles. But I didn't just want them all, I specifically wanted the subset that were also BLPs. Many subcategories are so large that browsing them may not be of interest. However browsing a subset may very well be. Nil Einne (talk) 19:13, 31 March 2008 (UTC)
thread_title:  This proposal would wreck the utility of the categories for browsing articles 

message: "American film directors" can be interpreted as "Film directors who are American" or as "Directors of films first published in America". Is this important? --Damian Yerrick (talk | stalk) 22:33, 26 November 2007 (UTC)
replies: text: The former is the only correct interpretation. UnitedStatesian (talk) 22:35, 26 November 2007 (UTC)
thread_title:  Is "American film directors" a good example? 

message: I am excited by the potential of this extension. I understand this fancy features load servers, complicate wikipedia editing, but these will take wikipedia to the next level. This feature is very scalable. We could initially only give it a limited scope, say dates or birth dates; why have category: 1976 births when just as easily we could have semantic data: "birth::27 may 1976" meaning the semantic tag which goes beyond generic category info - it understands the birthday in question is 27 may 1976. This could be applied to lots of things, and i feel it will (after an adjustment period) enhance and even simplify the categorization element of wikipedia. Chendy (talk) 14:38, 1 February 2008 (UTC)
replies: text: I certainly think we should be working towards implementing SMW somehow on Wikipedia. It would be useful for categorization and much more besides. In fact I would like to see an SMW database developed somehow outside any specific language version of Wikipedia (something like commons), to enable the sharing of key information between Wikipedias. (People might like to check out my partially-formed idea at User:Kotniski/wdb, which I wrote before I discovered SMW - I believe SMW would be a perfect way to implement something like this.)--Kotniski (talk) 07:45, 16 April 2008 (UTC)
thread_title:  Semantic MediaWiki extension 

message: I would like to use it now.  People are creating manual intersection categories all over the place.  Perhaps the overhead of the dynamic processing will be offset by dramatically reducing the number of manual intersction categories . . . ? Pee Tern (talk) 00:23, 22 February 2008 (UTC)
replies: text: I would also be curious to know what exactly is going on. It seems that every few months there's a clamor, we're given a quick update and told it should be around shortly, and then suddenly...nothing for months. At the very least, it would be nice to have some regular biweekly or monthly updates as to the progress being made. This would also increase involvement with this page and (hopefully) editorial advocacy for prioritizing this development work. Thanks, Girolamo Savonarola (talk) 06:06, 22 February 2008 (UTC)
replies: text: I am thinking of just starting to create semantically primitive categories anyway, and try to get some momentum up.  For example, instead of (actually as well as for the being) having a category for law enforcement agency the article would have three semantic primitive categories, law, enforcement, and organisation . . . Pee Tern (talk) 21:22, 24 February 2008 (UTC)
thread_title:  When can we get ? 

message: Rather than trying to go for the whole solution immediately, perhaps we go for in stage 1 only binary intersections, with a not and groupby clause.  In stage 2 we go for nested binaries . . . Pee Tern (talk) 21:53, 24 February 2008 (UTC)
thread_title:  Initial implementation option 

message: It seems important to note that this idea is important beyond the particular wiki implementation that we call wikipedia, and would be incredibly useful to anyone using the underlying software. A case in point is a project that I'm working on now. We are using MediaWiki to organize and categorize all of the projects that my organization is working on. We want to browse by multiple categories, and also by the interersection of those categories. Example: show me all the present projects. show me all the future projects. Show me all the projects in the IT department. Show me all the past IT department projects. We chose a wiki over a formal database since it was so easy to use and flexible; it would be really wonderful if it could also provide more powerful reporting functions. Consider this a vote in favor of devising a scheme for allowing for union and intersection functions that will make browsing much more powerful.  -- mike roy, kenyon college, gambier, OH, USA  —Preceding unsigned comment added by 76.181.107.71 (talk) 04:54, 27 February 2008 (UTC)
replies: text: The main branch of MediaWiki development is typically focused on the needs of wikipedia.org, however (as you note) MediaWiki is actually separate from Wikipedia and there are extensions that can be deployed on sites other than wikipedia.org.  I think category intersection isn't being pursued by the developers basically because of potential performance impacts at wikipedia.org (I think several of the suggestions here could clearly be implemented).  If I ever end up with a significant amount of time to devote to this (not likely in the short term), I may actually implement one of these.  I'd invite anyone with development skills to consider implementing one of these suggestions. -- Rick Block (talk) 05:37, 27 February 2008 (UTC)
replies: text: I know zip about the "backend"s of wiki*, either from technical perspective or a protocol perspective.  If no one gets to this in the next few months, I might have some time after midyear to do a bit more than just muse about it.  Where would I start?  Pee Tern (talk) 10:08, 27 February 2008 (UTC)
replies: text: Start at the MediaWiki homepage, http://www.mediawiki.org/wiki/MediaWiki (it's written in PHP, with an SQL database backend). -- Rick Block (talk) 14:48, 27 February 2008 (UTC)
thread_title:  A non-wikipedia example 

message: I posted this to the Wikitech list...
With the advent of __HIDDENCAT__,  I've been wondering about using 
hidden categories to create indexes.  My initial hope with Wikipedia was 
that we could reorganize categories so that categories could function as 
broad indexes of single attributes such as "People", "Films", "Bridges", 
etc... and hide all the intersection categories of parents.  Later, if 
and when category intersection was implemented, all the hidden 
categories would no longer be needed.  However, implementing major 
changes seems to be near impossible in a project as large and set in its 
ways as Wikipedia.  There is just too much resistance to change.  If 
category intersection was implemented there would be an technical 
compelling reason to make the change, but short of that upgrade, it 
seems like a very difficult -- if not impossible -- sell.
It really bothers me (and others, especially librarians), that Wikipedia 
is not indexed.  You cannot find a master index of People, places, 
books, films, etc...  To find anything you have to know in advance, 
where it is subcategorized.  This only works if you know where to 
browse, and it is your desire to only browse in a small well-defined 
place.  One of the big joys of libraries is the ability of finding 
things you didn't know about in broad swaths of knowledge.  This ability 
is often lacking in Wikipedia because of categories being constantly 
broken into smaller pieces.  For example, If I want to browse through 
the bridges in Europe, I have to look at a category for each country 
separately, and in some countries (like the UK) I have look at one for 
each county.  It is just too difficult and time consuming a task to be a 
pleasurable leisurely browse.
So I've been thinking of alternative approaches.  One possibility is to 
use hidden categories to create index categories.  For instance, 
:Category:Index-Films could contain all films, 
:Category:Index-People could contain all people, etc...  However, 
this would be difficult to maintain because the categories would be 
hidden, and it would take a tremendous amount of work to populate these 
categories. It seems crazy to have people doing all the mindless 
busywork necessary to create categories like these.  That is why we have 
computers.
This is where developers come in...
I'm wondering about creating a new namespace, called (you guessed it) 
INDEX.  Any category of people could be put in an index by adding 
Index:People on the category page.  The "People" INDEX page, into 
which the category get put, would have links to all the articles and 
subcategories  from the categories in the INDEX.  The contents of the 
subcategories of those categories would NOT be added automatically.  
Each would have to be manually added to the index if appropriate.  Just 
like a category there would be text that could be edited for each INDEX 
page.  So in essence, an INDEX is a way to do category unions.  This 
would be much, much easier than trying to create and maintain these 
indexes manually using categories.
It would be great if an INDEX page could be viewed two different ways 
(and easily switched).  The first way would look similar to current 
categories, showing a category tree at the top, and all the articles 
below arranged alphabetically.  It would also be great to see categories 
viewed hierarchically, like an index in a book.  So the categories would 
be listed alphabetically and then all the subcategories and articles in 
the categories would be listed together alphabetically and indented.  
The categories could be differentiated by either making them bold, 
italic, or by labeling them as categories.  If the subcategories have 
also been included in the index, their contents would also appear 
indented in one more level (this could be closed at first and opened 
using a "+, the same way category trees look.  Users might also be able 
to set the default number of levels that appear -- perhaps two?).
I don't think there is any need to be able to add anything but 
categories to an INDEX.  Adding anything else would probably make it 
harder to maintain the INDEX, and would probably confuse newbies.  Of 
course, you should be able to create a link to an index page by typing 
Index of people.
If you think this idea has merit and is a possibility, would it be 
difficult to implement?  It has long been my understanding that category 
unions would be much less server intensive than category intersections.  
Perhaps each INDEX display process could be done dynamically?
Thanks, -- ☑ SamuelWantman 08:38, 29 February 2008 (UTC)
replies: text: From the initial response from Symetrical, it looks like this has mySQL limitation problems as well... -- ☑ SamuelWantman 08:38, 29 February 2008 (UTC)
thread_title:  Category Union 

message: : I've noticed an occasional convention on English wikipedia that :Category:Cities (plural) is for things that are cities, while :Category:City (singular) is for stuff about the topic "City".  -- Skierpage (talk) 05:18, 16 April 2008 (UTC)
thread_title:  Property categories and other thoughts 

message: I've read most of the project page about the category intersection project; but I 
see it lacks a mid-term for the project. It was listed an example that included
'American People' then 'Film Directors'. I've noticed this could be a bit overwhelming
to do 'on the fly' as the page mentioned; as both categories are relatively large,
being 'American People' especially huge. This kind of approach maximizes memory use
for the category pages, as it would spare 1 category as you would just 'request' a
fusion of categories while navigating. But maybe wouldnt this case be a little 
extremist? A more convienient solution, imo, would be to keep the biggest intersective
categories (saving performance), while having small categories only to be possible
to be subject of intersection. Like this we would, over a transition time, keep
categories as they are. No changes; no massive relocating in Wikipedia's core
structure and lots of work for users; instead, just one possibility: intersect (possibly
like a system mentioned on proj page) two or more categories from request. BUT (and heres
the change), you may only intersect categories with under X articles. Like this we would
keep major intersections (they could work as normal intersections, only they would be alredy
stored in the DB), while removing smaller unnecessary ones (many were removed lacking notability,
which wouldnt happen anymore). Let me list one example. Someone is looking for some real-time strategy game.
But he is looking for platform ones, especifically PS2. Also, he wants the ones released in 2006.
So, acording to what was proposed at project page, we should have this:
  Real-time Strategy games - PS2 games - Games realeased in 2006
You may notice that all categories are huge, so for the server to make such
an intersection would take time; server load. Now look at my proposal:
  Real-time strategy games - Ps2 games released in 2006 (1) OR
  Real-time strategy games - Ps2 games - US Platform Games realeased in 2006(2)
Notice that categories mentioned in suggestion 1 alredy exist, and they have both medium sizes.
So here intersection comes as a very useful and not much server-expensive feature, excluding
the necessity of categories of uncertain notability (ps2 real-time strat games of 2006, in  the example),
while keeping most categories we have now with a gradual detetion of the alredy existant lesser intersections.
(And by doing so decreasing a bit database memory use, while having ocasionally-used intersection tool.)
Frequent intersections could be saved as a category by the server, but they would still be seen as a regular
intersection.
Feel free to add anything as you please; or to disagree. --Almighty11 (talk) 02:20, 4 March 2008 (UTC)
replies: text: The main benefit of category intersection is that it allow users to intersect categories in ways that just are not possible in the current system.  For example, intersecting Disasters, Events in China, and Events in 1935, or Films from 1963 and Comedy films. -- ☑ SamuelWantman 19:51, 8 March 2008 (UTC)

text: Forget about performance. Category intersection is a fast operation. There's a sort-based algorithm where you can do category intersection in 'n log(n)' operations or better, where n is the number of articles in the biggest category. This is what google does all the time, when you type in a search term, you're searching for the intersection of those search terms.- (User) Wolfkeeper (Talk) 23:36, 8 August 2009 (UTC)
thread_title:  Database memory X Server performance/ Wait time Trade-off 

message: The more I think about this, the more I don't like it.  Above, you say that in many cases redundancy of categories would be necessary (Child actors and Actors) to allow for better intersection selections.  Although in a few cases (which I disagree with) it may be preferred to have both the child and parent categories, it can really get out of hand.  
For example, Warren Buffett.  If Laurence Fishburne should be in both Child actors and Actors and in both People from Augusta, Georgia and People from Georgia (US State), then what about a little further.  For the most possible intersections available on one article, shouldn't Warren Buffett be categorized in People from Omaha, Nebraska, People from Harrison County, Iowa, People from Iowa, American people, North American people, AND People?  If the redundancy of two lower-level cats is advocated, why not all of them?  North American people DOES apply to Warren Buffet, and someone may want to intersect that.  What about listing him in 1930 births, 1930s births, 20th century births, AND Births of the last 123 years?  They all apply, and someone may want to intersect them, but that's just too much redundancy on the article.
Here's a better idea: Rather than having checkboxes on every pages next to every category with an intersection button, why not have a special page with the tool?  It could be Special:Category intersection, and it would simply have spaces for the categories to be intersected.  It is much simpler than effecting every page, and is is surely no harder to implement.  Reywas92Talk 20:23, 10 March 2008 (UTC)
replies: text: What I'd really like to see is some well defined hierarchies that are integrated into how we do category intersection.  So for example, if as you say -- Warren Buffett can be categorized in People from Omaha, Nebraska, People from Harrison County, Iowa, People from Iowa, American people, North American people, and People -- Perhaps only one of these categories is displayed on his page (probably People from Omaha) but there'd be a pull down list that would have all the other layers of the hierarchy.  Currently, hierarchy, intersection, and related attributes are all combined into the categorization system and all look the same -- they are all subcategories. -- ☑ SamuelWantman 23:40, 11 March 2008 (UTC)
replies: text: I actually like the pull-down idea, though only if it was small.  My biggest problem is big categories.  Some say that large categories are okay and make searchability easier, but when there are more than 200 members, it gets rediculous.  Also, as some categories are sub-cats of many others, which one would go in the box?  Many categories are not for articles, anyway.  Reywas92Talk 23:47, 11 March 2008 (UTC)
thread_title:  Problem with redundancy and better proposal 

message: I made a simple overview of diffusion in some high level categories at Wikipedia talk:Categorization#Category diffusion overview a few days ago. Then I found this proposal which more clearly explains the benefits I was trying to express, and goes further in helping the user browse articles. Therefore I added a link from Wikipedia:Village pump (policy)#Category diffusion overview to this Wikipedia talk:Category intersection, as I believe the more editors read it the more may understand what categories can be used for ("Categories help users browse through similar articles."). -84user (talk) 03:31, 11 July 2008 (UTC)
thread_title:  Category diffusion overview 

message: I hope this is not dead yet, I just created a proof of concept implementation at
* http://toolserver.org/~dschwen/intersection
This actually does both, Category intersection and Link intersection, plus it allows specifying unions of categories and/or links prior to intersecting. Feedback welcome! --Dschwen 19:58, 11 July 2008 (UTC)
replies: text: It works for me. I like it. It is even more up to date than the Wikimedia search (which takes time before it sees newly categorised articles). Let us hope the social barriers are not too high. (I mean the required changes in the mindsets of editors) -84user (talk) 14:01, 15 July 2008 (UTC)

text: I also did an implementation on my wiki (wikidweb.com), where there are links on every article that go to a special page showing either pages at that intersection, or "related categories".  It's rough still, but a start.  Roan (I think it was Roan) as some code for the current Mediawiki version that I intend to start working into something similar, and seeing how it's received. --Aerik (talk) 07:19, 12 December 2008 (UTC)
replies: text: This does not work for finding "Talk:..." pages.  I.e. B-class... | Unknown-importance... Tavatar (talk) 18:01, 16 September 2009 (UTC)
thread_title:  Proof of concept implementation 

message: If anyone's seen it on imageboards hosted on the Danbooru CMS, looking on a gallery of images/content filed under at least one tag shows a list (on the lower left side) of other tags which are found on those images; each "related tag" then comes with links to add or subtract such tags to narrow down the number of images.
I don't know if Danbooru-like category intersection lists, which are potentially large, can fit within category pages on MediaWiki sites like this, but finding a way to narrow such intersection lists to fit within the side of any category page could help with exposing the benefits of category intersections to a much wider audience.
Furthermore, like Danbooru's tags and tag intersections, I think that web feeds of recent changes to articles linked to the intersections should be provided for. At least, I think that such would be a suitable complement. --Toussaint (talk) 19:06, 11 April 2009 (UTC)
thread_title:  I like how Danbooru does tag intersections 

message: I would really like to be able to harness the power of categories to search for something like atheism activists born from 1940 to 1985. For this we'd need to have a new class of category, something like OrderedCategory which could handle and sort a category of categories based on dates for starters but also anything else that can be sorted/ordered. A flippant example: find me all the South Park episodes from season 3 to season 12. Basically it is one big enormous intersection of categories that would rely on sorted indexes in the underlying database to execute in a reasonable amount of time. Any thoughts on this? I couldn't find mention of the concept anywhere else yet. Donama (talk) 12:26, 30 June 2010 (UTC)
thread_title:  intersection sequences of sortable category groups 

message: I'm not sure if I'm doing something wrong or if this feature isn't able to find articles that have categories added through templates, such as the stub-templates. An example is incategory:"1995 films" incategory:"Film stubs" should find for instance Sahara (1995 film) but doesn't. If I'm doing something wrong please let me know, and if this type of search isn't possible (yet) then perhaps it should state so on the Project page. GameOn (talk) 18:23, 4 May 2011 (UTC)
thread_title:  Categories added by templates