[Mediawiki-l] Content subspaces (was: Should I be doing this??)

[Felix Andrews]

I have also been trying to squeeze a hierarchical system into MW.
Actually, it is not a full heirarchy, there are only two levels, so
you could call it "Content subspaces" -- distinct groups of pages that
have a mostly distinct group of users.

== Outline of problem ==

The wiki I am setting up is for local communities, so they will mostly
only be interested in the subspace of pages that relates to their
local region. A distinct group of people will want to maintain that
subspace: look for recent changes, check out new pages, and possibly
search within it. The wiki will use a specific content framework such
that there would never be more than about 30 pages within one region
(excluding Talk pages).

I guess the same problem would be faced by cities.wikia.com if one
city grew to more than a few pages.

I am trying to decide between two options:

1. Use separate mediawikis for each local region. This would be a
setup similar to wikia.com, with some shared templates, help pages and
navigation.
__Pros__
* "Recent changes" applies to only one region, as most people would want it to.
* [[Links]] go to pages within the subspace.
* No need to to use naming conventions or disambiguation pages to
avoid name conflicts.
__Cons__
* There is not much interaction between regions, since they are on
different wikis with different logins, one cannot look at "recent
changes" or "requests for comment" over the whole site, so lose the
benefit of experienced users from one region helping small/emerging
communities in another.
* Software setup would be difficult, particularly for things like
shared templates.

2. Using subpages to organise content. There would be a main page for
each region, as a normal article. All other pages relating to that
region would be subpages of it.
__Pros__
* All on one wiki, so all well integrated and allows interaction
across communities.
* Pages within the subspace have an automatic link back to the main
page, so new pages aren't "dead ends".
* No need to use disambiguation pages to avoid name conflicts (using
subpages is essentially a naming convention).
__Cons__
* Can't easily see "recent changes" just within a subspace.
* New pages for the subspace must be subpages, e.g.
"Region_name/Some_page", and anyone who creates a page must remember
that.
* To link to a page in the subspace you have to type
[[Region_name/Some_page|Some_page]] (is there a shortcut way to do
this?).

The usual solution (as in Wikipedia etc) of having everything in one
namespace, using categories and disambiguation pages, I think would
not work well in this case. There will be many pages within each
subspace that have a common name, such as "Erosion", "Population",
"Water quality". So the disambiguation pages could be very large, and
naming conventions confusing.

As for namespaces, there are too many local regions to set up a
namespace for each.

== Technical challenges ==

I prefer option 2 (above): using subpages to organise content. I have
set up a prototype in that way. As an interim method for seeing
"recent changes" within a subspace, I have put links to all subpages
on their main (parent) page, and then used "related changes". However,
this is not ideal:
* it does not include changes to the parent page itself;
* it breaks if links are removed from the main page, pages are moved, etc.
* it does not include talk pages unless they are also linked from the main page.

So, to see "recent changes" within a subspace (i.e. all subpages of a
specified page, including the parent page itself), I think a new
special page would be required. Also, a special page to see a list of
all subpages would be useful (a subset of Special:Allpages).

Does this sound sensible and feasible?

Thanks
Felix

On 8/26/06, Morten Blaabjerg <morten at crewscut.com> wrote:
> Yusuf, it sounds to me like you're trying to squeeze a hierarchical system
> into MW. A scheme like the one you describe may work, but it is with the
> risk of restraining yourself and your users too much, and not really taking
> advantage of the freedom a wiki can give you. There basically is no
> "correct" way of organizing information in a wiki - it is up to you and your
> users to organize the content, as you see fit.
>
> If you want a more hierarchical organization of content, you may be better
> off with another CMS or wiki engine which is better set up for this kind of
> thing. If you want your site to be a wiki, I'd suggest you simpy throw
> everything together in the main namespace, and use categories like Java, C,
> C+ etc to tie related pages together. This will be the least restrained
> option, leaving you and your users with the greatest freedom to organize
> things as you go.
>
> You may use custom namespaces as you suggest, but namespaces are not an
> ideal way of organizing content, they are primarily meant to differentiate
> between different types of content and functionality, i.e. between content
> and userpages, discussionpages, system pages etc.
>
> Best wishes,
> Morten :-)
>


-- 
Felix Andrews / 安福立
Beijing Bag, Locked Bag 40, Kingston ACT 2604
Building 48A, Linnaeus Way, The Australian National University ACT 0200
Australia
http://www.neurofractal.org/felix/
mailto:felix at nfrac.org
voice:+86_1051404394 (in China)
mobile:+86_13439575331 (in China)
mobile:+61_410400963 (in Australia)
xmpp:foolish.android at gmail.com
#xmpp:floybix at jabber.cn (in China)
#xmpp:foolish at jabber.org.au (in Australia)
3358 543D AAC6 22C2 D336  80D9 360B 72DD 3E4C F5D8