Wikipedia talk:Category intersection/Rick's mockup/African-American actors/Archive 1

message: Rick, I don't see how the Broader/finer feature will work:
* The broder categories are not primary categories so they would not have any articles that would likely lead to anything being in the intersection set.  A few of the finer categories are also not primary categories.
* Christian actors, Actor-singers, Actor politicians and Actor sportspeople would not exist in your system (if I'm understanding your most recent comments correctly) because these would replaced by intersections.  So how would they be linked to this intersection set?
::-- Samuel Wantman 10:47, 14 August 2006 (UTC)
replies: text: For the "broader" list I simply listed the current parent categories of the categories that are intersected here while the "finer" list is (some) of the current subcategories that aren't in the intersection set.  Is this useful?  In some cases I think it might be.  For example, if instead of "Actors" this were "Film actors" or "Academy award winning actors", this "parent" list would include a larger superset category.  Even as it is, it might be useful for traversal purposes.  To get from here (African-American actors) to African-American directors, you might click People by occupation (which would unclick Actors because Actors is directly in People by occupation), recompute which would probably lead to a null intersection but from this intersection the "finer" list would include all subcats of People by occupation, and from there click Directors (which should probably automatically unclick People by occupation) and finally "recompute".  This is 4 physical clicks, two "browser local" clicks to select the categories being intersected and two web page fetches.  Currently, from :Category:African-American actors you can get to :Category:African-American/Black film directors with two clicks (both web page fetches) through :Category:African Americans.  However, you can't currently get to :Category:African-American dancers at all (because it has not been populated or created, even though Alvin Ailey is categorized in both :category:African Americans and :category:American dancers).  -- Rick Block (talk) 14:00, 14 August 2006 (UTC)
thread_title:  Comments 

message: :I think I confused you by starting the paragraph above with The bottom line is.  I meant only that one sentence, i.e. that keeping these concepts orthogonal is very powerful.  I added the other stuff in that paragraph (about the links) on a read-through of what I'd written (bad editing on my part).
:About the links (more bad editing), the issue is what happens if someone "adds" an article or a category to an intersection.  With what you're proposing I think this will happen all the time (and I think you agree), and so for articles you've suggested the software automatically "do the right thing" (recategorize into the primary categories).  On the other hand, adding categories to intersections is fine (in fact, necessary for what you're suggesting) so the software simply allows this.  I see this as a significant issue, both in terms of the user mental model of what's happening as well as in the software.  If a user adds category:African-American actors to an article, hits save, and this "category" does not show up in the category list, I think the user will think it's a bug.  By mostly hiding intersections behind what look like categories I think you're ensuring not only that this will happen but that it will confuse users (because in your scheme intersections look so much like regular categories that most users won't know the difference – by doing this, you're preventing users from developing a mental model that matches what is really going on).  Even if users do catch on that these interesection categories are different (and shouldn't be added to articles), they then have to realize that as far as the categorization structure is concerned these categories aren't different!  Borrowing some of your words, I didn't understand this at first and have been a software designer, programmer, and system engineer (for Bell Labs and its offshoots) for 25 years.
:Contrast the above with what I'm suggesting.  Categories are categories, completely unchanged from current operation.  Intersections are new and different.  No confusion.  More complex mental model, but the inherent difference is completely visible which allows users to learn the difference.
:On the named/unnamed vs. preexist/not naming issue, I think this reflects your model of how this works.  I believe you're thinking of intersections as intrinsically the same as categories, so "on the fly" intersections are categories that don't have a name yet.  With what I'm proposing, intersections don't need a "category" name since they're fundamentally different from categories.   The difference I mean to be highlighting is really whether there's an existing database record or not, mirroring the difference between a redlinked or "blue linked" article.   I could try to use named/unnamed when talking about your scheme, but I'd rather use something different when talking about my scheme (since named/unnamed doesn't apply).
:You're thinking about casual users and a mature structure where categories (and I think you mean intersections) have been created (named?), and you meant the #5 question to be a navigation question.  If we assume the structure is mature, I don't think there has to be a huge navigational difference.  In your scheme, if a user is at :Category:African-American actors to get to :Category:African-American actors by state they click a "subcategory" link and from there, to get to a specific state, they click another "subcategory" link to get to, for example, :Category:African-American actors from California.   In my scheme, (assuming equal maturity in the structure) there's a "see also" link from :Intersection:African-American actors to :Intersection:African-American actors by state and from there they'd click a (previously manually created) link to the intersection for the state of interest, probably by state name.  Assuming a fully populated category/intersection structure, I don't see this as much different.
:However, the scheme I'm suggesting works almost as well whether the category/intersection structure is fully populated or not, and I don't think yours does.  In your scheme, navigation to an intersection (from the category structure) is possible only if the intersection has been both named and added as a member of one or more "parent" categories/intersections.  In my scheme, the navigation can be "on the fly" by picking categories to intersect using the selection table displayed at the bottom of an intersection.  From an article, we both start with picking a set of categories to intersect.  In your scheme, there is no parallel operation available once the user gets to "category" space, and navigation within category space only functions between "categories" (which are either primary categories, or named intersections).  I don't think we want, or need, to "name" most intersections.  In this example, I wouldn't expect there to be named intersections for each state like :Category:African-American actors from California, and if there aren't, then there's not much point in :Category:African-American actors by state existing either.  I think this means in your scheme these intersections would not be accessible from "above" in the category structure.  A user might get to :Category:African-American actors from Georgia from the Laurence Fishbourne article, but it won't be named, won't be "linked in" to the category structure (except to the primary categories), won't have an obvious parent category that exists, and, I'd claim, we don't want it to.  If we don't name these intersections we don't have to manage them (at all).  We don't have to CFD the ones that don't make sense.  We don't have to worry about their names.  I'm not thinking about the system at day one, seeing the categories empty and uncreated – I'm thinking about a fully functional system that works without the overhead of manually creating 100s of thousands (if not millions) of named intersections.
:Jumping ahead a bit, your summary is the following (I'll switch to italics):
So for your scheme:
* The intersections are separate from the categories,
* There may be a way to give them English names.
*: No.  My proposal is intersections exist only in "intersection space".  Their name consists of the names of the intersected categories separated with some punctuation characters.  Links can have arbitrary (English) names through piping, but these are not intersection "names".
* It can list the sub-intersections and intersection categories automatically (like I've done above or by using a checkbox interface).
*:I'm not so sure I buy anything other than a checkbox sort of interface.  It seems like there are likely to be too many possibilities to enumerate them all, and I don't see a reasonable way for an automated system to limit the choices since we don't know what "dimension" the user is interested in.
* "See also" links to connect up additional useful categories,
* Perhaps intersections get put into regular categories, (but only if they have 2 categories intersecting?)
*:I think if you add category:whatever to an intersection, the intersection is added to the "regular" category.  The category tag can include a piped name (which for articles is used only for sort order, not appearance).  I think it would be reasonable to use a piped intersection name in a category listing.  Note that I think adding intersections to categories would be rare, since (in my proposal) all categories are primary categories.
Here's the disadvantages I see:
*  It looks like a category, but it isn't.  People will try to put articles into categories that have the names of intersections.
*:Now wait, this is a disadvantage I see of your scheme.  In my scheme, intersections DO NOT look like categories.  The page title says Intersection:blah blah blah, not Category: blah blah blah.  The page listing looks superficially like a category listing, but it's obviously, noticeably, different.  I don't think people will try to put articles into "categories" that have the same name as intersections.  They're two entirely different concepts.  I think people will understand them as different concepts.
*  The hierarchies are not part of an edited structure so every intersection is just as important as any other even though one might be very significant and another might be meaningless.  There will be a huge number of meaningless intersections that people will be able to navigate through easily.  It seems like it will be a maze that might be difficult to get out of.
*:I'd rephrase this as the hierarchies don't have to be part of an edited structure.  Any intersection will be easy to navigate to, whether some previous editor thought it was "useful" or not.  This is the primary difference between Google and the earlier "hierarchically organized" web indices.  Google makes no attempt to "preselect" what you might find interesting. 
For my scheme:
* The intersections look and behave like categories,
*:This only applies to named intersections, and only within "category space".  I'd call this a disadvantage and word it as "A named intersection look like a category, but it isn't.  People will try to put articles into these categories and will be confused when they can't.
* There is a way to give them English names.
*:More specifically, there is a way to give them a category name.  Rather than repeat myself, let's just say I don't see this as a particular advantage.
* Intersections are added to the categorization scheme one at a time, but there might be a good way to find intersections with a checkbox interface or some other system.
*:I see this as a huge disadvantage.  Consider the recent split of Serbia-Montenegro into two countries.  With my scheme, as soon as the countries exist in the appropriate parent categories, all intersections involving the new countries are immediately accessible through the "normal" intersection selection mechanisms.  With your scheme, no intersection involving these countries appears in any "x by country" index category (and there are a LOT of these, even considering only the ones involving one other category) until the intersection is named and manually included in the appropriate parent category.  Yes, a sufficiently knowledgeable user could get to these intersections but presenting intersections as categories and primarily using the category navigation mechanisms to get to them makes the maintenance of the category structure a never-ending, and not especially small, task.  I personally dislike all the "x by y" index categories we have and would very much like to find a way to get rid of them.
* Same "See also" links.
* Articles miscategorized get fixed.
*:I'm not sure what this refers to.
* Only meaningful intersections make it into the hierarchy.
*:Which means the arguments at CFD about what is and is not "meaningful" continue ad nauseum.  My scheme provides a mechanism to drastically simplify "the hierarchy" (reduces it to "primary" categories, with the rest created "on the fly" reflecting the particular user's interests).
: I get the sense that you are quite attached to your intersection=category idea.  The more I think about this, the more I think we should keep categories and intersections separate.  Would it be useful for me to put together a more complete user interface mockup?  Perhaps multiple screens, how you'd navigate, etc.?  Is there more talking we can do?   Maybe split into two pages, one where you throw rocks at my scheme which I try to address and one where I throw rocks at your scheme which you try to address?  Is it time to bring in more people?   It doesn't seem like long essays are helping that much.  -- Rick Block (talk) 02:52, 22 August 2006 (UTC)
thread_title:  Rick's August 22 reply 

message: Well these essays are helping me stay up too late.  Yes it certainly would help very much if I saw your proposal worked out some more.  Some of my resistance may be from not seeing the entire picture.  I hope you take what I've written as encouragement to develop the ideas.  When you went on your wikibreak and I started putting together the proposal it forced me to work out the details of how everything would work.  It is now very hard for me to figure out if your version is acceptable because I'm not sure exactly what it is. So take the proposal, and copy it to a new page and edit away.
As we discuss, I've been modifying my mock-ups and they are moving in your direction.  You've been addressing my concerns (like piping in English) and working out navigation.  I think we will meet.  I don't think we are really that different.  The only real difference that I see is the transclusion of intersections.  I'd be happy to part with that if everything else comes together.  I realize, looking over the history of all this, that my very first message about this on your talk page sounded more like what you are now proposing than I am.  I don't think we are at odds.  I'm going to put some effort into your way of doing things...
I think a good deal of your resistance to my version (and vice versa) may be in the way things are presented.  For example, you say "If a user adds category:African-American actors to an article, hits save, and this "category" does not show up in the category list, I think the user will think it's a bug."  But in my imagining the same events the user adds category:African-American actors to an article, hits save, and :Category:Actors, :Category:American people and :Category:People of African descent appears, the user will think "Wow, the software is smart!"
The presentation can integrate or divide the category and intersection namespaces as much or as little as needed to help people understand what is going on.  I think the presentation of your system can probably be made clearer and I think the presentation of my system can probably be made clearer.  The intersection used in a category could be linked where it is displayed or at the bottom of category pages just as templates that are used are now linked when editing. Some people will go to them, hopefully everyone who understands what an intersection is.  I don't think I have introduced any new paradigms.  There is already plenty of transclusion.
So lets get some commonality out of this.  Things we both want:
* An easy to use interface for navigating down through category space, make a smooth transition to intersection space and then navigate through intersection space.
* A way to reference an intersection (this we agree on, it is just :Intersection:xxx::yyy::zzz or something similar.  The links could be piped (just like links to articles are) so that they appear as Zee-Wyian exes.
So here are some things that would get me to like your system more:
* A system of having an English headings for intersections.  For example at the top of the page it could say:
;Intersection::Actors::American people::People of African descent
::"African-American actors"
----
The top line would be the page name just as you have it in your mockup, but the second line could be a name that can be user-edited  (I won't call it a category!) Here's an idea, what if the second name is added to the url when it is called by the piped link?  That way, whatever the piping is, it will appear the same way when it is viewed as an intersection, and nothing else has to be done to make it appear.  It might be named differently from different links "Poets from England" from one place, and "English poets" from another.
* A clearer way to get around intersection space.  I wouldn't mind seeing something like this:
Recompute intersection:
----
----
----
----
This reads like the lists of categories for actors and visually has higher and lower categories, emphasizes where we are, seperates the groups, and can grow to whatever size is needed to display everything.  I kinda like this, I'm going to put it in my mockup.
So now I am trying to understand how these two spaces will interact in your system.  I can imagine that people will decide to put intersections into categories and if they did, I think they should end up in section of their own like this:
;Intersections
----
There are 5 intersections shown below (more may be shown on subsequent pages).
:Female African-American actors
:Male African-American actors
etc...
I'd be happy if they used the page tag name instead of the URL name.  It would take up much less space and be more readable than having:
:Actors::American people::Female people::People of African descent
:Actors::American people::Male people::People of African descent
So my question to you is, would you like to control the proliferation of categories for intersections?  I gather you would.  If so, how?  I suspect that very quickly there will be lots of categories for intersection pages such as :Category:African-American actors by U.S. state which would be a category filled with 50 intersections.
So I'm thinking this way of presenting your proposal would look pretty similar to what I was proposing and I could probably grow to like this way of doing it.  It is possible to design this with the constraint that intersections cannot be categorized.  All the fooian fooer categories would disappear and the only way to navigate down the category structure to :Category:American writers would be to manually add a "see also" link to Intersection:People by nationality::Writers piped and tagged as "Writers by nationality" or Intersection:American people::People by occupation piped and tagged as "Americans by occupation" and all you would see is an empty intersection with the ability to pick new categories.
So this removes my problems with naming and navigating, but I still have an unanswered question, which perhaps is not answerable by the two of us without more input:
*Does it help people to make the line between intersection and category so clear?  I think to programmer types and wikiholics the answer is probably "yes".  But to the average Jane or Joe, it might be daunting and confusing.  This is certainly a distinction that is never made in printed media.  How many poets are going to think of English poetry as the intersection of English people and poets and because English poetry is an intersection it is no longer a category.  This is contrary to the spoken language understanding of what a category is.
*Will people find it easy and natural to find the English poets by checking off the box for English people and then clicking "recompute intersection"?  It seems easier to just click on "English poets".
So, lets ask others. -- Samuel Wantman 11:03, 22 August 2006 (UTC)
thread_title:  Sam's August 22 response 

message: This is getting entirely too unwieldy.  I've extracted the questions and some other comments from your latest (above) and addressed them here.  Your words in italics.
It certainly would help very much if I saw your proposal worked out some more.
:I'm not sure when I might get to this, but I'll work on it at some point.  I'm thinking about writing a simulator to show what my idea of an arbitrary intersection page might look like (based on actual data fetched from wikipedia).   I've written several scripts that do various things – I think it would not be terribly different to write a simulator that would take an arbitrary intersection URI and produce a simulated page.  The simulated pages are kind of a drag to make by hand, and if there are going to be more than one or two of them I think it might be easier just to write a simulator.
[I'd like] A system of having an English heading for intersections.
:If you're willing to live with a manual method, each intersection page has an "edit" link (similar to categories).  You can add anything you want to the "body" of an intersection page, so just add the "English" name as the top line in the body.  (I don't like inferring this name from a piped link name.)
A clearer way to get around intersection space.
:I'm not crazy about the horizontal presentation (vertical seems more "natural" to me).  Either way, there will only be a limited number of subcats displayed.  Maybe more examples might help clarify which way is better.
I can imagine that people will decide to put intersections into categories and if they did, I think they should end up in section of their own like this:
:I agree people might, but I don't know how common this will be.  The presentation you show seems reasonable.  In my August 22 reply, I suggested the "piped" name be used for presentation in addition to sort order (even though this is NOT how piped category additions currently work for articles or categories).
So my question to you is, would you like to control the proliferation of categories for intersections?  If so, how? 
:Yes, I'd like to control the proliferation of "categories for intersections", and I'd like to replace essentially all of the "fooian fooers", and "fooians by foo" categories with intersections.  If we can create a traversal mechanism in intersection space that's easy enough to use, then I don't think anyone will miss these categories (and I think using intersections instead of categories would eliminate a large maintenance burden).   In the discussion above about :Category:African-American actors by state, I propose this category not exist (as a category) but rather as Intersection:People of African descent::Actors::American people by state.  This isn't an intersection intended to show articles, but an intersection intended to let the user traverse to a different intersection.  If we can make this work (easily and intuitively), I think we can use the same technique for all the "fooians by foo" categories.  What I'm envisioning is a mechanism allowing a user to get to any intersection, using other intersections as "indices".
All the fooian fooer categories would disappear and the only way to navigate down the category structure to :Category:American writers would be to manually add a "see also" link to Intersection:People by nationality::Writers piped and tagged as "Writers by nationality" or Intersection:American people::People by occupation piped and tagged as "Americans by occupation" and all you would see is an empty intersection with the ability to pick new categories.
:I think there are a couple of ways this could work.  The primary categories are :category:American people and :category:Writers (right?).  If primary categories are the only ones that show up on articles, how does a user ever get to "Writers by nationality" (whether it's a category or an intersection)?  Certainly not from an article.  If we assume "Writers by nationality" is an intersection (see mockup), then let's say it's a precreated (we're talking about my scheme, right?) intersection, and this intersection is added to :category:Writers and :category:People by nationality perhaps with a piped name of "Writers by nationality".  This would let a user traversing from either :category:Writers or :category:People by nationality to get to this intersection.  There almost certainly aren't any articles in this intersection, so what you see when you get there is a page that pretty much only has an "intersection selection table" (which may be vertically or horizontally organized).  The "current" intersection is :category:Writers and :Category:People by nationality, so the immediately available "recompute" intersections would include any type of writer (subcats of :category:Writers) and any nationality (subcats of :Category:People by nationality).  This intersection has been "precreated" (since it was in the approriate parent categories), so it could have manually created links to various other intersections (perhaps in nice compact tables).  Even if no one has provided these, the basic "intersection selection table" will allow a user to get to any "writers by <country>" intersection (as well as any "poets by <country>", or "screenwriters by <country>", or ... ).  There are 248 subcats of :Category:People by nationality and 27 subcats of :Category:Writers (although many of these are currently "writers by X" index categories, which I think should become intersections), which leads to to 6696 "fooian fooers" intersections (and 275 "x by y" index intersections).  I'm thinking all of these would be traversable from this intersection selection table.  Creating an intuitive intersection mechanism that applies to categories in addition to articles makes all of these able to be automatically generated (requiring none of them to be "precreated").  Two links, one from :category:Writers and one from :Category:People by nationality are all that's needed to get any of these (nearly 7000) intersections.
:My guess is that if we make this traversal easy enough, no one will want to "create" these intersections.  They'll simply be automatically available, to anyone who wants to use them.
Does it help people to make the line between intersection and category so clear?  I think to programmer types and wikiholics the answer is probably "yes".  But to the average Jane or Joe, it might be daunting and confusing.  This is certainly a distinction that is never made in printed media.  How many poets are going to think of English poetry as the intersection of English people and poets and because English poetry is an intersection it is no longer a category.  This is contrary to the spoken language understanding of what a category is.
:Most definitely yes.  Categories are primary characteristics.  The intersection feature provides a way for anyone to search by any combination of these primary characteristics.  I'd expect "English language poets", defined as the intersection of "poets" and "English language writers" to be exactly how poets would think of it.  The categories are the primary characteristics.  Intersections of these aren't categories.   Forcing intersections onto the category structure is an unnatural artifice, required by the current software.  "African-American physicists" is not a category.  It's the intersection of "African-Amercans" (which is itself an intersection) with "Physicists".  The categories involved in this are "African", "American", and "Physicist".
Will people find it easy and natural to find the English poets by checking off the box for English people and then clicking "recompute intersection"?  It seems easier to just click on "English poets".
:Easier in this one example, but if we can train people how to to navigate "intersection space" they can get to so much more than anyone can possibly guide them to that I think it's worth the tradeoff.  The trick is making it easy enough, and intuitive enough, for most people to understand.
-- Rick Block (talk) 04:16, 23 August 2006 (UTC)
thread_title:  Rick's August 23 reply