[Mediawiki-l] Examples of Namespace vs. Category vs Sub-page?

[Monahon, Peter B.]

> Peter Blaise wrote: [paraphrasing: in 
> what ways are the wiki "namespace" 
> and "category" and "sub-page" features 
> useful, specifically in being able to 
> search, sort and select groups of wiki 
> contents for printing, viewing, 
> exporting ... and do any auto 
> features respect them, such as auto 
> table of contents?  I've read about 'em
> all but if and how they work together is
> still foggy.  Any clarifying links?  
> Thanks!]

> Brianna wrote: [paraphrasing and 
> translating: a significant mind dump, 
> or Vulcan mind meld, a veritable 
> stream of wiki-consciousness about wiki 
> page structure and architecture.]

Peter Blaise responds:  Thank you!  It's wonderful to see so much
careful, conscientious thought go into the integration of wiki elements
in one discussion.

To continue the exploration:

I'm concerned about how and why to put any data IN to a wiki in the
first place.  I know that any automation system can only answer
questions it was pre-told how to answer.  For example, one goal is to be
able to print a group of pages as a book, but edit them as separate
pages.  I think you are saying that the MediaWiki print feature does not
assist in doing that grouping for printing in one-step.  And, neither do
any of the other features - namespace, category, sub-page - assist in
grouping the wiki's contents for one-step collected output.

Standing back and revisiting what MediaWiki is all about, the
Wikipedia.org implementation or MediaWiki seems definitive: a bunch of
separate pages that are somewhat findable with basic word searches.  The
Wikipedia's goal is to present one page at a time on screen for the
visiting user of the wiki software.  Also, in order to facilitate (not
automate) sequential (not one-step) editing or printing, there are
"gathering" features (such as namespace, category, sub-page, and
special:pages) that allow a user to cycle through a series of tasks to
execute them over a group of individual pages, but still manually
executing whatever they are doing one page at a time.  (This is why
editing and system administration are so time consuming, right?)  

And I didn't even mention global search and replace!

In other words, the native skills of MediaWiki (I'm supporting v1.9.3
through v1.10 so far) are page oriented, and any desire to
search/sort/select groups of pages and treat them as an entity for
printing or exporting would require supplemental PHP/SQL programming
outside MediaWiki.  Have I got it?

> Brianna wrote: ... There are several open 
> source tools on the toolserver you 
> could adopt if you really wanted to....

Peter Blaise asks: Toolserver?

Waaa#1: One frustration is typing any vocabulary word into the search
bar at MediaWiki.org and getting ... nothing!  However, within the
wording of a few page links, I found
http://meta.wikimedia.org/wiki/Toolserver - yes, that's at
wikimedia.org, not at mediawiki.org!

Waaa#2: Of course, then, another frustration is having so much stuff
that's supporting  MediaWiki.org (the software) being hosted at
Wikimedia.org (the Foundation).  This splits the community in two.
Actually, there's great MediaWiki support stuff exclusively at
Wikipedia.org (the project), so the MediaWiki (the software) support
community is at least divided in three!

Waaa#3: Another frustration is hidden links that do not show on screen,
or for cut and paste, and often do not show when printing (I read
copious printouts and highlight links on paper to search later).  That
page link (above) says: "Please see Toolserver/Projects for a list of
available tools and other content." ... but there is no clue that the
word "Toolserver/Projects" is a link.  Same on the subsequent
Toolserver/Projects page, er, on the
http://meta.wikimedia.org/wiki/Toolserver/Projects page which offers the
words "Toolserver/TStoc" and "TSTOC".  Both are invisible links, namely
to http://meta.wikimedia.org/wiki/Toolserver/TStoc and
http://tools.wikimedia.de/~interiot/cgi-bin/tstoc    I appreciate we all
have different preferences in response to "ugly" http links.  But, I
find it very frustrating to not have them fully displayed and printed or
at least underlined so I know there's a link there.

Waaaaaa!

I will not calm down!  Okay, okay, back to the discussion.

(Please see http://www.webworksite.com/articles/article4.php before
responding to my "complaints", PLEASE!)

> Brianna wrote: ... sensible category 
> structure Design ... is a difficult 
> process in a wiki ... (Waaa#4?)

Peter Blaise responds: This is why I mentioned Quicken for DOS, that o'l
relational database software I've been using, same copy, since the
1980s.  It's nothing but a relational database with incredible powers in
it's "category" and "class" structure for transaction
searching/sorting/selecting for output.  Analogy wise, a wiki page is
like a Quicken transaction; a namespace is like a Quicken register/bank
account.  Why with a modern SQL database, excuse me, an "RDBMS", are
wiki categories so powerless?  If anyone doing development for MediaWiki
has no experience with this 20-year old Quicken for DOS, I'm happy to
send you a copy (it fits on a single floppy) for demonstration and
education purposes.  I'm serious.  I'm so used to the incredible
sophistication of this 20-year old DOS program that it heightens my
frustration when a modern wiki is way naive in comparison.

(Again, please see http://www.webworksite.com/articles/article4.php
before responding to my "complaints", PLEASE!)

> Brianna wrote: ... An extension 
> DynamicPageList allows for very 
> powerful listing and sorting.  If your 
> wiki is not too big (ie, not Wikipedia), 
> it should be useful ... 

Peter Blaise responds: Wow - I've got some more reading to do!  Thank
you very much.  With all these extensions to study, I feel like I'm
shopping with a small shopping basket in a big store - like figuring out
which Firefox extensions to get and keep, and which to ignore or delete
(~2,250 at last count).

> Brianna wrote: ... 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 ...

Peter Blaise responds: I know this first hand.  But, my wikis are
starting life being fully populated from legacy documents.  Immediately,
end users are asking, "How can I do this, and how can I do that, and
..." ...and so on.  All they are asking for is the same tasks they are
used to doing with their information using other software.  I'm stymied
when it comes to the wiki features and benefits in comparison.  "Great
question!" is all I can say to the end user ... then start a new round
of research and development.

Here's a sample challenge (simplified example).  Say I have an in-house
wiki and an ... out house wiki, for lack of a better term.  RDBMS wise,
they both may need access to zip codes, but otherwise, their data may
need to be separate from each other.  I could have them both look at the
same zip code namespace, but keep each other out of each other's
namespaces (I think).  (Or is this better handles with separate wikis
using the same MySQL?)

Or, a computer "data elements dictionary" wiki.  I've got multiple
databases to document.  Each database to be documented may have similar
table-names and element/column-names.  I could make each database a
separate page.  Then I could make each element a sub-page of that
database.  That way I can have, say, 2 elements both called "Name_last".
One is under Database_inhouse/Name_last.  The other is under
Database_outhouse/Name_last.  Over time, the authors of those commonly
named documents might diverge on the meaning and criteria of the data
elements in their own databases.  One database may even be shut down and
be retired, deleted from the wiki, with all sub-pages included.  In one
fell swoop?  No.  That doesn't work!  The sub-pages hang around, as
orphans of a non-page, don't they?  (Also, I don't see any links from
the master page to it's sub-pages, nor from sub-pages to the master
page.  How to make them appear like at the top like
http://meta.wikimedia.org/wiki/Toolserver/Projects  that shows a "<
Toolserver" link at the top of the Projects page to go "up" one page?!?)

Or, should the different databases go into separate namespaces?  I
wouldn't want "Name_last" as a single page in the root common to both
databases since their uses in each database might diverge, and the
authors may have different instructions for each different use.

Ahh.  Endless, eh?

Anyway, the above is why I'm trying to find or build the answers.  No
analogy is perfect.  It's not simply a "how to drive a car" manual I'm
after.  Nor "how to tune up your car" nor "how to design a car".  But,
perhaps a wise combination of all these, plus "why travel" and
"transportation for personal pleasure", as well as "transporting goods
and services" thrown in as introductory and overriding themes
throughout.

I can't imagine that's very difficult to do.  Not with everybody
pitching in on a wiki-based environment.

;-)

Thanks for your insights, Brianna and everyone.  Very stimulating and
challenging.  I look forward to having as much to give back as I'm
getting.

-- Peter Blaise