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
On 22/06/07, Monahon, Peter B. Peter.Monahon@uspto.gov wrote:
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!
This is because the Toolserver is bugger-all to do with MediaWiki; it's a Wikimedia project.
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!
This is an ongoing problem that's well noted; all documentation used to be bundled together on Meta wiki and a lot of it's still stuck there. A lot of it can't just be imported to MediaWiki.org because, to be brutal, it's crap.
Rob Church
On 23/06/07, Rob Church robchur@gmail.com wrote:
On 22/06/07, Monahon, Peter B. Peter.Monahon@uspto.gov wrote:
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!
This is because the Toolserver is bugger-all to do with MediaWiki; it's a Wikimedia project.
"Bugger-all"? I think that's overstating it. Many of the functions performed by Toolserver tools could be more usefully performed by MediaWiki itself.
* In category since (lists "old" pages in a certain category) * Catmembers (lists members of category + subcats) * categorycount (number of items in a category!!!) * Catgraph (draws a graph of category structure) * CatCroiseur (category intersection) * CatLadder (produces something like breadcrumbs) * MediaSearch (category based search focused on images) * Neue Seiten nach Kategorie (new pages of a category + subcats) * CoCat (another kind of category intersection tool) * Category Tree (shows tree structure of categories - now native MW) * CatScan (category intersection)
These are just the ones that relate to categories. Mostly they fulfill functionality that should be present in MW natively. If you use a wiki with a detailed category structure, some of these tools are definitely going to be useful. Aren't they just like another type of "extension"? I mean they are open source.
Perhaps these tools should in fact be marketed on mediawiki.org?
cheers Brianna
On 23/06/07, Monahon, Peter B. Peter.Monahon@uspto.gov wrote:
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.
Not that I know of. I think you should talk to the English Wikibooks project. They WRITE books. That's all they do. I'm sure they have tools or at least suggestions for how to manage this.
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?)
I don't think namespace, category, subpage features faciliate editing or printing. They faciliate BROWSING. All those features help people browsing, reading.
Automated tools, created by Wikipedia etc editors, exist to faciliate editing. e.g. they allow you to do something like "edit each page in this category". The most well known one that I know of is called the AutoWikiBrowser. http://en.wikipedia.org/wiki/WP:AWB
Also, people use bots to do fully-automated editing. There is a bot framework which has scripts for many common activities. http://pywikipediabot.sourceforge.net/
And I didn't even mention global search and replace!
See bots. :)
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). [...] 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.
Good grief... use your own print stylesheet then? I don't really think this is a MediaWiki issue.
(Please see http://www.webworksite.com/articles/article4.php before responding to my "complaints", PLEASE!)
The volunteer world doesn't work like the paid world. If anyone here was being paid for customer support then that article would be relevant.
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?
different tools for different tasks. Do you ask on the Quicken mailing list, "Why is it so difficult for 20,000 users to simultaneously edit my file?"
At any rate, my point about sensible category structure design being difficult in a wiki was relating to the fact that you have many users trying to impose their own vision on a single structure. It was a point about users, not the software. If one single person designs a category structure they will be able to implement it just fine.
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.
Maybe you should be looking at something from http://en.wikipedia.org/wiki/Category:Open_source_database_management_system... . Notice there are no wiki engines listed there.
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?)
How is this better handled using a wiki rather than a RDBMS anyway?
Why do you want to use a wiki??
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?
Correct, deleting a page does not automatically delete its subpages.
(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?!?)
You probably haven't enabled subpages in that namespace. In namespaces that don't have subpages enabled, a slash in a page title is just a slash, like "AC/DC" is just one page, not "DC" is a subpage of "AC".
Enable subpages: http://www.mediawiki.org/wiki/Manual:%24wgNamespacesWithSubpages
For "auto TOCs" or links from master page to subpages, try using something like http://en.wikibooks.org/wiki/Template:AutoTOC (copy the code from this page into the same name on your wiki). On any page where you want an auto TOC, put "{{Auto TOC}}".
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.
Well to me it seems like you want "How to drive a car using a boat". :)
regards Brianna
-- They've just been waiting in a mountain for the right moment: http://modernthings.org/
mediawiki-l@lists.wikimedia.org