Namespaces: any page belongs to exactly one namespace. Namespaces are "flat": all namespaces are conceptually on the same "level", but divide up different focuses. Some namespaces in MW have special functions but I think you're more interested in custom namespaces.
Categories: any page can belong to 0 or more categories. Categories can form a hierarchy.
Subpage: any page can be a subpage of 0 or 1 other pages. Subpages form a natural hierarchy.
- How to export or print all articles in a namespace or group of namespaces?
MW doesn't do this natively. There may be extensions.
- How to control who can see or edit the articles in a particular namespace or group of namespaces?
Again, this is access control which is covered by extensions.
- How to restrict search to include or exclude a particular namespace or group of namespaces?
There are tick boxes at the bottom of Special:Search.
- How to auto-build a table of contents for all articles in a namespace or group of namespaces?
Special:Allpages has a namespace selector that lets you choose a namespace to see pages from. You could also use Special:Prefixindex for this.
In other words, what are the features and benefits of using the "namespace" function, and how (examples and or links, please) can a wiki admin or wiki user take advantage of those features and benefits?
Special:Newpages and Special:Recentchanges can be restricted to only show results over a specific namespace. For example English Wikibooks has a namespace "Cookbook", so all the pages in the Cookbook namespace are recipes. People interested in working on the cookbook can look at the recent changes that have been made only to that namespace.
Versus Category?
Categories can also be used in this way, somewhat. There are two ways of using categories: 1- add all categories that apply. 2-add only the most specific categories that apply.
So for an article "Sydney", if we follow 1, we might add [[category:Cities in New South Wales]] [[Category:New South Wales]] [[category:cities in Australia]] [[Category:Australia]] [[Category:Cities]] [[category:capital cities in Australia]] [[Category:Capital cities]] [[category:Olympic Games host cities]]
if we follow 2, we would only add [[category:cities in New South Wales]] [[category:Capital cities in Australia]] [[Category:Olympic Games host cities]]
All the other categories would be considered "implicit", because the categories that we DID add, would be descendants of the other categories, somewhere along the way.
There are advantages and disadvantages to both systems. It depends on what you want to do. The problem is that there are no good native MW tools for "working with" categories. There are several open source tools on the toolserver you could adopt if you really wanted to.
If we use system 1, the disadvantage is that -articles can get a LOT of categories - can make the screen look crowded -the "higher up" categories (like "Cities") quickly "fill up" and become unuseable. (Category pages display 200 items by default. Subcategories are not paged separately, so if there are more than 200 items in the category, some subcategories might not appear on the first page of the category. This is a nasty unexpected surprise. Known bug.)
If we use system 2, the disadvantage is that - MW doesn't have a native way of "collapsing" categories, i.e. looking in a category AND all its subcategories at the same time. At the moment you have to check all the subcategories separately. Say I am in [[Category:Cities in Australia]]. I just want to see a list of all the (articles on ) cities in Australia. But instead, I will have to separately check in [[Category:Cities in Victoria]], [[Category:Cities in Tasmania]], etc etc. This reduces the usefulness of the category as a "catch-all". - it can lead, in large wikis, to inappropriate category intersecting. Taken to the extreme, you get categories like [[Category:French feminist female singer-songwriters born after 1920 who write their own lyrics]].
Both of these can somewhat be mediated by sensible category structure design. Which is a difficult process in a wiki.
Versus Sub-page?
Subpages are only useful for that topics that are naturally hierarchically organised. Each page can only have ONE parent. If you think a page has two parents, you shouldn't use subpages -- you should use categories.
Use of subpages allows neat linking: [[../../friends/Jake/Foo]] but I think it actually rarely gets used.
Practical example: Wikipedia used to use subpages, but quickly abandoned it because of this problem of multiple parents. (E.g. "Politics in Algeria" has two parents: Politics, and Algeria.) Wikibooks uses subpages to arrange the contents of books [aside from the cookbook which I mentioned previously.] This works very well. So a book on learning Spanish might be like this:
[[Spanish]] (a page in the main namespace) [[Spanish/TOC]] [[Spanish/Introduction]] [[Spanish/Lesson 1]] [[Spanish/Lesson 1/Dialogue]] [[Spanish/Lession 1/Vocabulary]] [[Spanish/Lesson 1/Test]] [[Spanish/Lesson 2]] ...
Special:Prefixindex is useful to create "auto TOCs" for subpages arranged like this.
An example: say I have a wiki with job descriptions, and each job description has a series of tasks. I may want to see or print, say, all job descriptions, with no sub-tasks. Or, I may want to see and print only one entire job description and all it's tasks, but no other job descriptions. How would I organize that information best using Namespace vs. Category vs. Sub-page (or other)? Each job description goes on it's own page (I presume). Should I create a separate namespace for each job?
Definitely not.
Should I create sub-pages for each job's tasks?
That would be one way of doing it, but why not just put everything on one page to start with?
Would categories be helpful?
Maybe...or they might be overkill. Depends if your wiki is just about job descriptions, or if it's about lots of stuff and only has a handful of job descriptions.
I guess what I'm asking in a backwards way is, how powerful are the search, sort, select, report, print features, and also any auto-features such as auto table of contents or auto index features in MediaWiki? How would anyone using a MediaWiki database say, "show me and print all and only ... such and such"?
I don't know that MW is the best tool to do what you want to do. It sounds like you want something to manage a bunch of documents. Documents are not exactly equal to wiki pages. There will be ways to do it, if you really want to, but they might not suit exactly your purposes, but I guess you know that already.
An extension DynamicPageList allows for very powerful listing and sorting. If your wiki is not too big (ie, not Wikipedia), it should be useful.
BTW: many wikis are used without ever even knowing about namespaces, categories or subpages. It might be overkill to introduce too many features at the start of your wiki's life.
cheers Brianna