subwikis - Revision history

Woozle: about to move a page

2017-12-15T00:31:56Z

about to move a page

← Older revision		Revision as of 00:31, 15 December 2017
Line 66:		Line 66:
	Thus, links to existing articles could be of the form <nowiki>[[article name\|link text]]</nowiki> or <nowiki>[[0000\|link text]]</nowiki>. Perhaps the wiki software would even expand the latter form to include the article name, for human reference: <nowiki>[[3415 Article Name\|link text]] </nowiki>.		Thus, links to existing articles could be of the form <nowiki>[[article name\|link text]]</nowiki> or <nowiki>[[0000\|link text]]</nowiki>. Perhaps the wiki software would even expand the latter form to include the article name, for human reference: <nowiki>[[3415 Article Name\|link text]] </nowiki>.
	==Related Articles==		==Related Articles==
	* [[~~Subwikifying~~ MediaWiki]]		* [[MediaWiki/archive/subwikis]]: mainly of historical interest at this point

Woozle: /* Modification 1 */ MW does have subpage syntax; need to figure out if it can be used in this scheme

2008-07-27T14:20:25Z

Modification 1: MW does have subpage syntax; need to figure out if it can be used in this scheme

← Older revision		Revision as of 14:20, 27 July 2008
Line 36:		Line 36:
	'''Automatic hierarchical topic-spaces''' with magic delimiter character (we'll use "/" so that to avoid conflict with MW		'''Automatic hierarchical topic-spaces''' with magic delimiter character (we'll use "/" so that to avoid conflict with MW
	"namespaces")		"namespaces")

			''Note: this should probably be modified to take into account MediaWiki's subpage syntax, where <nowiki>[[/subpage]] is equivalent to [[current page/subpage]]</nowiki>.''

	* An article with the URI "whatever/example/something/stuff" is shown with the title "stuff" but shown as belonging to the category "something" (e.g. with a linkback, though this should probably be definable by skin/stylesheet) which belongs to "example" etc.		* An article with the URI "whatever/example/something/stuff" is shown with the title "stuff" but shown as belonging to the category "something" (e.g. with a linkback, though this should probably be definable by skin/stylesheet) which belongs to "example" etc.
	* Internal links on the "whatever/example/something/stuff" page are relative to the current URI -- a syntax suggestion (others are possible):		* Internal links on the "whatever/example/something/stuff" page are relative to the current URI -- a syntax suggestion (others are possible):
Line 48:		Line 51:

	This would probably also largely remove the need for the "category" system, though there should be some way of displaying all sub-articles. A navbar at the left is what comes to my mind, showing at least the current topic (e.g. "Linux") and a list of short-URI sub-article names, with links, and maybe an "expand" link to show the full tree back to the root (perhaps a "root wiki" link for subwikis, to show the current subwiki's location within the master wiki as well). Other automatic links that might be helpful would be "full tree" (all articles under this one, shown as a tree) and "index" (alphabetic index of all articles at any level under the current context).		This would probably also largely remove the need for the "category" system, though there should be some way of displaying all sub-articles. A navbar at the left is what comes to my mind, showing at least the current topic (e.g. "Linux") and a list of short-URI sub-article names, with links, and maybe an "expand" link to show the full tree back to the root (perhaps a "root wiki" link for subwikis, to show the current subwiki's location within the master wiki as well). Other automatic links that might be helpful would be "full tree" (all articles under this one, shown as a tree) and "index" (alphabetic index of all articles at any level under the current context).

	===Modification 1a===		===Modification 1a===
	The [[wikipedia:Hierarchy\|hierarchy]] need not even be a [[wikipedia:Tree (graph theory)\|tree]] or even necessarily		The [[wikipedia:Hierarchy\|hierarchy]] need not even be a [[wikipedia:Tree (graph theory)\|tree]] or even necessarily

Woozle: updated header

2006-05-24T18:43:34Z

updated header

← Older revision		Revision as of 18:43, 24 May 2006
Line 1:		Line 1:
	[[~~Computing~~]]: [[~~Software~~]]: [[~~Software Ideas~~]]: [[~~Subwikis~~]]		[[computing]]: [[software]]: [[wiki]]: [[subwikis]]
			==Overview==
	"Subwiki" is kind of a working label used to describe a set of features for which there seems to be a need in wiki software but which, as of yet, does not seem to exist.		"Subwiki" is kind of a working label used to describe a set of features for which there seems to be a need in [[wiki]] software but which, as of yet, does not seem to exist.
	==The Problem==		==The Problem==
	One limitation which keeps showing up when attempting to use [[wiki]] software as a general content-management tool is that you often end up with areas of the wiki that are of particular interest to certain people but of relatively low interest to others — and, likewise, the people interested in a particular area may have relatively low interest in the rest of the wiki. (Let's call these people who are interested only in a certain area "special interest users", because they come up often.)		One limitation which keeps showing up when attempting to use [[wiki]] software as a general content-management tool is that you often end up with areas of the wiki that are of particular interest to certain people but of relatively low interest to others — and, likewise, the people interested in a particular area may have relatively low interest in the rest of the wiki. (Let's call these people who are interested only in a certain area "special interest users", because they come up often.)
Line 16:		Line 16:
	** Extra effort has to be expended to provide any kind of aid to navigation within the special interest area, or indeed even minimal links "back home" to the special interest "main article". Although this can be done reasonably well with templates, it adds an extra layer of effort required in order to maintain the special interest area and it adds extra clutter to pages within the special interest area.		** Extra effort has to be expended to provide any kind of aid to navigation within the special interest area, or indeed even minimal links "back home" to the special interest "main article". Although this can be done reasonably well with templates, it adds an extra layer of effort required in order to maintain the special interest area and it adds extra clutter to pages within the special interest area.
	* Special interest users entering the wiki from the main site may be puzzled as to how to find the set of articles which interests them, unless they have been given the URL of the main article for that interest-area (e.g. http://htyp.org/index.php/Pinecrest_Road_Neighborhood) — which itself is an awkwardness, as long URLs are not only difficult to remember and type, but also difficult to fit conveniently onto tear-off sheets or business cards.		* Special interest users entering the wiki from the main site may be puzzled as to how to find the set of articles which interests them, unless they have been given the URL of the main article for that interest-area (e.g. http://htyp.org/index.php/Pinecrest_Road_Neighborhood) — which itself is an awkwardness, as long URLs are not only difficult to remember and type, but also difficult to fit conveniently onto tear-off sheets or business cards.
	** '''URL Alternative 1''': use ~~[http://tinyurl~~.com~~/ TinyURL]~~ to generate a short URL, and publish that. '''Disadvantage''': The URL gives no clue as to the nature of the site; people do look at things like the domain name to get an idea of whether the site is worth visiting or not.		** '''URL Alternative 1''': use TinyURL.com to generate a short URL, and publish that. '''Disadvantage''': The URL gives no clue as to the nature of the site; people do look at things like the domain name to get an idea of whether the site is worth visiting or not.
	** '''URL Alternative 2''': create a subdomain (e.g. pinecrest.htyp.org), and have traffic redirected from there to the actual URL of the special interest homepage. '''Disadvantage''': Although this does solve the URL issue, it does not address the other issues.		** '''URL Alternative 2''': create a subdomain (e.g. pinecrest.htyp.org), and have traffic redirected from there to the actual URL of the special interest homepage. '''Disadvantage''': Although this does solve the URL issue, it does not address the other issues.
	==Alternatives==		==Alternatives==

Woozle: Subwikis moved to subwikis

2006-05-24T18:40:53Z

Subwikis moved to subwikis

← Older revision	Revision as of 18:40, 24 May 2006
(No difference)

Woozle: header

2005-10-13T16:52:32Z

header

← Older revision		Revision as of 16:52, 13 October 2005
Line 1:		Line 1:
	[[Computing]]: [[Software]]: [[Ideas]]: [[Subwikis]]		[[Computing]]: [[Software]]: [[Software Ideas]]: [[Subwikis]]

	"Subwiki" is kind of a working label used to describe a set of features for which there seems to be a need in wiki software but which, as of yet, does not seem to exist.		"Subwiki" is kind of a working label used to describe a set of features for which there seems to be a need in wiki software but which, as of yet, does not seem to exist.

Woozle: significant rework; bits moved elsewhere

2005-10-13T16:51:16Z

significant rework; bits moved elsewhere

Show changes

Woozle: MediaWikiDoc:Subwikis moved to Subwikis

2005-10-13T14:32:03Z

MediaWikiDoc:Subwikis moved to Subwikis

← Older revision	Revision as of 14:32, 13 October 2005
(No difference)

Woozle: /* Notes on First Attempt */ notes for hierarchically-oriented wiki

2005-09-26T12:56:24Z

Notes on First Attempt: notes for hierarchically-oriented wiki

← Older revision		Revision as of 12:56, 26 September 2005
Line 102:		Line 102:
	many browsers (including FireFox) will ignore CSS if it isn't sent with		many browsers (including FireFox) will ignore CSS if it isn't sent with
	the right mime type. --[[User:Woozle\|Woozle]] 15:04, 11 Jun 2005 (CDT)		the right mime type. --[[User:Woozle\|Woozle]] 15:04, 11 Jun 2005 (CDT)
			==2005-09-26 A little more clarity==
			A little more clarity on how wiki software should work, to make it
			easier to implement subwikis &ndash or, more to the point, to be
			able to dive into specific subject areas on a wiki without worrying
			about naming conflicts or contextual miscues (subwikis being more or
			less an automatic by-product)
			For all the following modifications, I am proposing unlinking the URI
			from the article name; in other words the URI will be stored separately
			from the article's displayed title, so they don't need to be the same.
			===Modification 1===
			'''Automatic hierarchical topic-spaces''' with magic delimiter
			character (we'll use "/" so that to avoid conflict with MW
			"namespaces")
			* An article with the URI "whatever/example/something/stuff" is shown
			with the title "stuff" but shown as belonging to the category
			"something" (e.g. with a linkback, though this should probably be
			definable by skin/stylesheet) which belongs to "example" etc.
			* Internal links on the "whatever/example/something/stuff" page are
			relative to the current URI -- a syntax suggestion (others are
			possible):
			** <nowiki>[[things]]</nowiki> refers to the URI
			"whatever/example/something/stuff/things", i.e. a sub-article
			** <nowiki>[[/things]]</nowiki> refers to
			"whatever/example/something/things", i.e. an article at the same level
			*** <nowiki>[[//things]]</nowiki> refers to
			"whatever/example/things", i.e. a parent-level article (aunt/uncle)
			*** <nowiki>[[////things]]</nowiki> refers to "things",
			i.e. a root-level article
			* The root wiki is treated as another wiki named "@", with an automatic
			interwiki link in the format "@:URI", e.g. "@:whatever/example" would
			link to "whatever/example"
			For longer article titles, the article's URI-name should probably be a
			shortened version of the title, taking the URI context into account.
			For instance, "Linux setup and configuration" could have the URI
			"tech/linux/setup".
			Under this scheme, a "sub wiki" becomes almost trivial in that you
			could have a separate domain (e.g. linux.tech.hypertwiki.org)
			-- go straight to a given URI (e.g. tech/linux) and it would appear
			more or less as if the "Linux" page were the homepage of a completely
			separate wiki. Links to Linux-relevant articles would not have to be
			carefully named so as to include "Linux" in the title, as they would
			now.
			This would probably also largely remove the need for the "category"
			system, though there should be some way of displaying all sub-articles.
			A navbar at the left is what comes to my mind, showing at least the
			current topic (e.g. "Linux") and a list of short-URI sub-article names,
			with links, and maybe an "expand" link to show the full tree back to
			the root (perhaps a "root wiki" link for subwikis, to show the current
			subwiki's location within the master wiki as well). Other automatic
			links that might be helpful would be "full tree" (all articles under
			this one, shown as a tree) and "index" (alphabetic index of all
			articles at any level under the current context).
			===Modification 1a===
			The [[wikipedia:Hierarchy\|hierarchy]] need not even be a
			[[wikipedia:Tree (graph theory)\|tree]] or even necessarily
			[[wikipedia:Directed acyclic graph\|acyclic]] in order for this to work.
			For instance, if we have an article about Durham, NC -- which is part
			of North Carolina, but also part of the NC Triangle Area and part of
			Durham County -- we could have the URI "earth/us/nc/durham", but also
			"earth/us/nc/triangle/" which contains a link to
			<nowiki>[[durham]]</nowiki> (URI
			"earth/us/nc/triangle/durham") and "earth/us/nc/durham county/durham"
			(same). The Durham NC article itself would declare its parents (via a
			category-like syntax) to be "earth/us/nc", "earth/us/nc/triangle", and
			"earth/us/nc/durham county" (e.g.
			<nowiki>"[[parent:earth/us/nc]]"</nowiki> -- though this
			might actually work better using the article ID scheme in option 2).
			The main change here, then, would be the addition of
			"parent"-declaration syntax and corresponding changes in the database
			(i.e. any article may have an arbitrary number of children ''and'' an
			arbitrary number of parents, as opposed to an arbitrary number of
			children and only one parent).
			===Modification 2===
			'''Primary linking by article ID''' Although I think we should continue
			to support linking by article name – as this makes it easier
			to "request" articles, to create requested articles, and to keep track
			of article requests – perhaps the primary means of
			referencing other articles should be by using their ID in the database.
			This would largely negate the need for internal "redirects" and link
			updates when an article's name changes. It would not remove the need
			for "disambiguation" pages, but it would reduce the number of times
			when a disambiguation page was arrived at instead of the intended
			article.
			I would also propose that an article's URI could make use of either the
			article's ID ''or'' title; whether these were kept in separate URI
			folders (e.g. "sitename.com/a/article_name" vs. "sitename.com/n/3415")
			would be up to the administrator of each wiki site, in much the same
			way it is currently their decision to have the wiki located under
			(e.g.) "/wiki" or "w/" or to just put it in the root folder (as in this
			wiki). Having them in the same folder would mean that an article's URI
			could not be just a number (e.g. "2005") because there might be an
			article ID with the same number, but with the hierarchical naming as
			discussed in Modification 1 above, this is less likely to be a problem
			(e.g. "2005" could have the URI "dates/2005", which would not
			conflict). Additionally, a site admin might decide to have a rigid
			format for article ID URIs, e.g. "at least 6 digits, leading zeros if
			needed" would eliminate the conflict with year-named articles even if
			they were in the "root", as would having a short prefix such as "n" in
			front of all article-ID URIs ("sitename.com/n3415").
			Thus, links to existing articles could be of the form
			<nowiki>[[article name\|link text]]</nowiki> or
			<nowiki>[[0000\|link text]]</nowiki>. Perhaps the wiki
			software would even expand the latter form to include the article name,
			for human reference: <nowiki>[[3415 Article Name\|link text]]
			</nowiki>.

Woozle at 16:15, 16 June 2005

2005-06-16T16:15:19Z

New page

[[Techniques]]:
Software: [[MediaWiki]]: [[MediaWikiDoc:Subwikis|Subwikis]]
==Benefits of Subwikis==
The basic question is this: Is there any need for the idea of subwikis?
I've been experimenting around with loading the same wiki data from
different files on the same server, so that I could have:
*'''Definitely Needed'''
** A different logo, different CSS styles (different default and maybe
different styles available)
** Different links on the sidebar (or same links, but they bring up
text appropriate to the project)
** A different default page ([[Main Page]])
*'''Would be a big help'''
** A different default namespace, so that new articles were
automatically prefixed with the subwiki's project name, and articles
prefixed with that name were automatically shown without it in the
title
** Articles written for the main wiki or for other subwikis would show
up with their logo & CSS
I originally started out with the idea of just creating a separate wiki
for each project. At some point, squeakymewmew seemed to be unhappy
with this idea -- she seemed to want (though it was never 100% clear to
me) for all my wiki projects to mingle together indistinguishably in
the squadwiki.
I can understand the idea of wanting all those pages to be sociable and
mingle with their peers, so as to better enhance the value of the main
wiki -- but when each project has its own purpose and vocabulary, this
gets very confusing. For example, if you see an article called
"shipping", is it an issuepedia article about ethical issues involved
in the shipping industry? Or is it a page about vbz.net's shipping
policies, or some information about where to ship Sluggite Exchange
items? If you have entirely separate wikis for issuepedia and vbzwiki,
or at least separate *sections* where it's clear what the context of
any article is, there's no ambiguity.
I've pretty much convinced myself, then, that each wikiproject does
need to have its own context, where people can safely post an article
with a name like "groups" and know that it refers to, say, the Linux
"groups" command, because you're in the LinuxWiki.
Furthermore, it looks pretty easy to set up a group of wiki projects so
that they can all link transparently to each other -- e.g. with the
default config of MediaWiki, you can just say
<nowiki>[[WikiPedia:Article Name]]</nowiki> and it will
create a link to the appropriate [[WikiPedia:Wikipedia|wikipedia]]
article (in English) formatted as an intra-wiki link (as opposed to an
external link with the little boxes after).
So the big question then is: what ''are'' the advantages, if any, of
sharing data between wiki projects? And is it worth the bother of
trying to do so? So far, here's what I've come up with:
# '''Commonality of users''': create an account on one wiki, and you
have an account on all of them. Log in to one, you're logged in to all
(this may be difficult due to the nature of cookies, but it's still a
nice idea.) Even nicer would be if
<nowiki>[[User:Yourname]]</nowiki> pointed to the same
page, or at least pulled up the same text, across all wikis. Perhaps
there's some way to share ''just'' the userbase between wikis? I think
I've even seen discussion of this in the mailing lists. (Some of the
issues regarding this are discussed
[http://meta.wikimedia.org/wiki/Single_login/IMSoP2 here].)
# '''Interwiki searching''': The "main" wiki would let you search all
the subwikis, whereas searching one of the subwikis would just search
within that context. (Perhaps there would be a "[x] search all wikis"
option.) Is this useful? Not sure.
# '''Interwiki article movement''': In a masterwiki-subwiki arrangement
like this, articles which are arguably "interdisciplinary" could be
posted in the main wiki, and perhaps later moved to a subwiki if their
focus resolved into something more appropriate for one or the other.
This would not work as well with separate wikis; the article would have
to be replaced with a "forwarding" link on one side, requiring an extra
click-through from the user. This could be solved with a little
custom-coding to return an
http forward instead of a link, but much code would have to be written
to allow forwarded pages to be maintained. Also, it often happens that
a topic-area starts out small and it only later becomes apparent (after
many, many articles have been written) that a separate wiki would be
useful -- and while moving a large number of articles from regular
space into a namespace isn't exactly quick, it's a lot easier than
copying-and-pasting them into the new wiki while leaving forwarding
links in the old locations.
So we have two things which might be accomplished in other ways, and
one which might not be useful. Suggestions? Thoughts?
That's all from me for now.
--[[User:Woozle|Woozle]] 21:16, 10 Jun 2005 (CDT)
==Notes on First Attempt==
I was able to get as far as having the front page and other pages of
the Hypertwiki to load from a different URL, utilizing a different
directory and index.php file on the same server, but I was not able to
get it to display nicely (i.e. with the proper stylesheet). Instead, it
displayed in the format usually used for printing. I was unable to
figure out why it was not displaying correctly; the correct stylesheet
data appeared to be loading, the stylesheet's contents appeared
correct, and the Page Info tool shows all the images.
In order to get this far, the following changes were needed (some were
only to change the wiki's home dir from /wiki to /):
* modifications to localSettings.php -- several fairly obvious changes
* one modification to includes/DefaultSettings.php: "$wgServer =
<nowiki>''</nowiki>;"
I hate to give up when it seems so close... but I just don't have the
time to come to a deeper understanding of MediaWiki at the moment.
'''Update:''' It seems very likely that the entire problem with my
earlier attempt was that [[.htaccess]] needed to contain a line to tell
Apache to deliver .css files as CSS rather than plaintext. Apparently
many browsers (including FireFox) will ignore CSS if it isn't sent with
the right mime type. --[[User:Woozle|Woozle]] 15:04, 11 Jun 2005 (CDT)