On Monday 12 June 2006 12:02, Morten Blaabjerg wrote:
<original snipped>
At first I tried to develop a useredited
sitemap/index, which clearly has
the advantage of providing additional information on the pages linked to.
In effect though, this is clearly often not updated effectively enough,
especially on a smaller wiki.
That does not surprise me. First people will have their own perception of what
is a "good" organization. In my experience, either you make the site map be
automatic or you have someone manage it or a combination of both
You always need an owner who takes responsibility for things. The way we have
it organized is that for each area there is a "expert" and a backup. The
expert either fills the KB or ensure that it gets done for his/her area.
He/she is also responsible for reviewing the material. Even on projects as
big as the Wikipedia, there are people who review articles. Potentially you
could have a TOC for aspecific area which are created by the owner/expert and
them simply include automatically into the larger site map.
So, I decided to have a go at using categories more
efficiently. I edited
the text at "Special:Categories" to contain our top-level categories - as
well as all categories in the wiki (which are included automatically on
this special-page).
Sounds responsable.
Our top-level categories are "Cultural
Networks" (which covers everything
from rockbands and periodicals to global media institutions and broadcast
networks), "Persons" (all pages on individual artists, theorists, directors
etc.), "Cultural Productions" (which covers every single publication, song
or film in the wiki)... etc. My idea is that all pages belonging to a
subcategory will also belong to one of these top-level categories, so
effectively all pages in the wiki is in a category.
Why can't these be real categories?
We also employ more
subject-oriented indexing categories, which are much more diverse,
spreading over several namespaces and across other categories. These are
completely non-hierarchical. It is of course also possible for pages to
coexist, say in both a "network" category and a "cultural works"
category -
in the case of a periodical for instance, which is a publication, yet also
an editorial institution.
That's very similar to the way we are setting up things. However, we are
planning to "force" a little hierarchy into the structure because that is
what a lot of people expect and to ensure standardization. A good example
would be Database_Troubleshooting exists in both the database and
troubleshooting categories. However, we have *defined* database to be at a
higher level than troubleshooting. Therefore the main page is
Database_Troubleshooting and if someone wants to create the page
Troubleshooting_Databases it is *required* to redirect to
Database_Troubleshooting. The customers are even higher, so the main page
would be CustomerName_Database_Troubleshooting and so on.
This ensures that on Special:Allpages things are automatically organized
hierarchically. At least to some extent.
The top-level categories are very vague, yet
deliberately cut out to describe the different kinds of content we have and
want in the wiki. They also have the purpose to simply display the mass of,
as well as what kind of information is in the wiki, for users and
visitors(which can otherwise be difficult to get an overview of).
That seems to be similar to the way the Wikipedia Portal works.
The only (minor) problem with using
"Special:Categories" as a sitemap is,
that since our top-level categories aren't themselves in any category, they
won't automatically give a link back to the Special:Categories (our
sitemap) page (as all pages or categories in a category do). This is a
minor issue, really, one which I expect could be solved comparatively easy
(if by no other way, then just by inserting this link manually).
Look into sub-categories:
http://meta.wikimedia.org/wiki/Category#Subcategories
That might provide a different solution. I am not saying your's is wrong, just
offering up an alternative.
What would be vastly more interesting, is to have more
customizable
category pages - for instance, entries in a category being able to display
data on the pages in the category at a glance (say the first two lines of
wikitext on a page, latest author, page views), as well as sorting the
pages in the category for display after userchosen criteria. "Show me the
latest edited pages in this category" - "Show me the most popular pages in
this
category" - "Show me only pages from this namespace, this date interval"
etc... What I guess I am talking about is combining the very efficient
cross-non-hierarchical category system with the MySQL requests of what is
now hidden in very "blocky" and "not-so-flexible" Specialpages (which
only
is used for the wiki as a whole, and for the primary namespace in
particular). Ideally I want all the functionality of the specialpages to be
enabled for each category, each namespace and for all files in the wiki.
This could be implemented with an expanded dropdown menu system, which is
already in place for several Specialpages.
Well, you've gone beyond my experience with MediaWiki. Naturally, you could
create a hack yourself to give you the functionality.
There is already the ability to create dynamic article lists:
http://meta.wikimedia.org/wiki/Dynamic_Article_List
One parameters is which is the "Name of category where (including its
children) all articles reside". This might be what you are looking for. If
you sort by hits, you get the most popular articles in the category.
This kind of expanded functionality would make
MediaWiki ultimately the
most powerful indexing tool you could find ever.
I think it is getting there. As more people like us add their ideas about how
to acces information and potentially our own hacks and add-ons, I see it
coming. The only thing I see blocking it is some people's perception that it
should stay a tool to create KBs like the Wikipedia. That is more or less
"random" information. In my job, the information is much more
"directed." I
might even be tempted to say "solution oriented".
I know this kind of functionality will probably not
find its way into
Wikipedia at present, because it will constitute too great server loads
etc. But in the long run, I am not so worried about server load issues. On
smaller wikis the load times will probably be less of a problem, and you
could make this kind of indexing functionality optional, to be dis/enabled
in the localsettings.
Personally, I think the load would be minimal with the right indexes.
--
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:
http://www.linux-tutorial.info