This category does not exist on CommunityWiki. Use the SiteMap as a ForwardIndex: List all categories on the SiteMap. Similarly, use the category pages as a ForwardIndex as well: List all pages in the category with a short summary (if possible) on the category page.

This doesn't need to be perfect; the backlink search via the page title is always a good last resort.

Why not have CategoryCategory? Is the idea to force maintainance of the ForwardIndex on SiteMap? I don't think the ForwardIndex is important; I'd rather be able to create categories quickly and then let someone else who cares about the ForwardIndex update it if they'd like.

Incidentally, I think if there is going to be a comprehensive FowardIndex? of categories, it should be separate from SiteMap. The SiteMap should be concise. Only the most "important" categories should go on the SiteMap. For example, CategoryWikiTechnology would, but not CategoryUncommonWikiFeature?, because the latter is a narrow subcategory.

And, I really don't like the idea of making each Category page a ForwardIndex. It needlessly adds a lot of work to page creation, and violates OnceAndOnlyOnce (the page descriptions on the category page, as well as the list itself will fall out of sync). And, I feel the same way about the forward indices on Category pages as I do about the SiteMap; there needs to be some place which lists only the most recommended pages in the category, not all of them. This is an application of SimpleView in order to FilterMore.

-- BayleShanks

To the extent that the ForwardIndex is just a way to get oriented, on a wiki a forward index on a category page could be automatically generated by the software, providing the orientation benefit without the maintenance. But a list of all pages in a category is usually pretty overwhelming and hence serves only as an index, not as a point of orientation. However, forward indices can provide additional value if a human picks only a small subset of important pages in the category, summarizes them, and relates them to each other. In this case, each list is more like a TableOfContents for the category rather than an index.

This is why I think category pages should not have forward links to all pages in the category, but rather should be a short "recommended starting points for this category" list. If you want to just have a comprehensive index, instead add a software feature to include the BackLinks on the page explicitly (PhpWiki has a directive to do this, for example). I don't really think this is needed, since we have BackLinks already. The only thing that is needed is the short list of recommended starting points per category.

-- BayleShanks

It works very well on the Emacs Wiki. [1] I have yet to find an "overwhelming" category page. If the category page is overwhelming, then maybe you need to introduce more categories -- after all, if the category page is overwhelming, the search for backlinks will be even more overwhelming (no summaries, no grouping, no recommendations). And if the backlink search is not usable, then there's no point in having categories in the first place.

-- AlexSchroeder

Baaah Humbug! I want WikiFeatures:BuiltInCategories! I want categorization built right into the engine!

Seriously. I think categorization is important, and the solutions that exist so far (CategoryCategory, SiteMap) are both deficient.

I agree with the criticism of BackLink (found on the same page.) But the SiteMap also forgets about what hasn't been listed.

This is an instance where I want the engine to take some of the structure work over for me.

You know that our processes will go into our engines. Futures:OffloadWorkOntoTechnology. It is our fate, our destiny, in the world of wiki. You can resist it, but only for so long. :) -- LionKimbro

Blah. Mysticism won't help you argue your case! Let us move all discussion to this page, though. And answer this: What exact benefits will there be to categories built right into the engine? Can you describe it on a NarrativeLevel (provide a UseCase)? Let me argue my case: If don't like adding information to two pages (child and parent, implementing the bidirectional link as two explicit forward links), then you must be wanting to add the information on only one page. Therefore, you must be wanting something like RdfForWikis. Whether RDF makes it easier to structure the site is still open to debate. I claim that organizing the pages in a category is more difficult if all you can do is edit the pages themselves. You will enter a "edit child, reload parent" debug cycle until you get it right. That's not good. I'd rather edit one parent page, putting the child pages into relation to each other. -- AlexSchroeder

Whereas for the most part, the information that I'd put in the summary on the TableOfContents-like ForwardIndex is just the same one-sentence summary that I'd put on the category page itself. Maintaining it in both places is just an exercise in copy-and-paste. If I had an RdfForWiki system, I'd just write that sentence once, on the page itself, in an RDF field. After doing this 2 or three times, I would trust that the information would appear correctly on the ForwardIndex page, and would not longer feel the need to "reload parent" to check.

So, for me, it is either write the stuff once, or write it once and copy-and-paste.

-- BayleShanks

Hm, does that mean we want something like RDF for wiki pages, where we can provide enough meta information such that a category page can be built automatically? As I said, I'm not too motivated, since it seems to work fine as it is on the EmacsWiki. -- AlexSchroeder

Define external redirect: CategoryUncommonWikiFeature FowardIndex

EditNearLinks: PhpWiki EmacsWiki TableOfContents RdfForWikis


The same page elsewhere: