Difference between revisions of "subwikis"
Jump to navigation
Jump to search
(→Notes on First Attempt: notes for hierarchically-oriented wiki) |
m (about to move a page) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[ | + | [[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. |
| − | + | ==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.) | |
| − | + | ||
| − | *'' | + | This leads to a few minor awkwardnesses: |
| − | * | + | |
| − | + | * Articles may have to be carefully named to indicate the context in which they belong, e.g. several neighborhood groups sharing a wiki might want to have articles entitled "Crime Watch", but only one of them can actually use that name; the others, at least, will need to add some clarifying context to the title, e.g. "Pinecrest Area Crime Watch". Ideally, ''all'' the articles should have this clarifying context, since each such article is primarily of interest to its respective neighborhood. | |
| − | ** | + | * Navigational and look-and-feel issues: |
| − | + | ** The "main article" for the special interest doesn't serve well as a home page: | |
| − | + | *** The logo is the main wiki's logo, and is not specific to the special interest | |
| − | * | + | *** There is no way to customize the stylesheet or skin for articles in the special interest area |
| − | ** | + | *** The navigation bar points to articles relating to the main wiki, rather than to articles relating to the special interest |
| − | + | ** The special interest user may tend to wander out of the pages related to their special interest and get lost, as all the navbar links will point (as they do for the special interest "main article") to articles relating more to the main wiki than to their special interest | |
| − | + | ** 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. | |
| − | ** | + | ** '''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. | |
| − | + | ==Alternatives== | |
| − | + | In addition to the specific alternatives above (which solve only one issue), the other obvious alternative which solves all of the above problems is simply to create separate wikis for each special interest. The disadvantages to this are as follows: | |
| − | + | * '''Requires webmaster intervention''': a new database must be added to [[MySQL]] for each new wiki, or at the very least the wiki creator has to have the ability to add new tables and must take care to choose a non-conflicting prefix | |
| − | + | * '''No searching across subwikis''': Some users may be interested in several related special interest areas. For example, a user searching for information about setting up scanners under Linux might want to search the "Linux" and "Computer Hardware" areas for articles | |
| − | the | + | * '''No sharing of users''': Requiring users to create accounts for each area of interest makes it less rewarding to create an account in any of them (since the benefit of registration is limited to the wiki in which you registered) and thus encourages users to maintain a narrow focus and generally puts unwanted barriers between interests and reduces overall interaction. ('''Note''': the MediaWiki development team are working on solutions to [http://meta.wikimedia.org/wiki/Single_login share users between wikis], which would address this one issue.) |
| − | + | * '''No easy way to move articles between special interests''': sometimes a special interest area starts as a single article, or a group of articles which are later seen to be related. Moving articles between wikis while preserving their histories and their links to other articles is doable but tedious. | |
| − | + | ==Proposal== | |
| − | + | ''Some proposed modifications to the existing MediaWiki standard'' | |
| − | + | ||
| − | " | + | The prime area of concern is that users should 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 of this functionality). | |
| − | + | ||
| − | + | Given the extent of the modifications, it may actually be a better idea to start from scratch than to attempt to shoehorn MediaWiki into a role for which it was perhaps never intended. Nonetheless, it may be easier to start out by ''thinking'' of the design in terms of modifications to a known model. | |
| − | + | ||
| − | + | 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. | |
| − | |||
| − | |||
| − | |||
| − | " | ||
| − | |||
| − | that | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | the | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | to | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | a | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | ''' | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | ||
| − | |||
| − | |||
| − | 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=== | ===Modification 1=== | ||
| − | '''Automatic hierarchical topic-spaces''' with magic delimiter | + | '''Automatic hierarchical topic-spaces''' with magic delimiter character (we'll use "/" so that to avoid conflict with MW |
| − | character (we'll use "/" so that to avoid conflict with MW | ||
"namespaces") | "namespaces") | ||
| − | * An article with the URI "whatever/example/something/stuff" is shown | + | |
| − | with the title "stuff" but shown as belonging to the category | + | ''Note: this should probably be modified to take into account MediaWiki's subpage syntax, where <nowiki>[[/subpage]] is equivalent to [[current page/subpage]]</nowiki>.'' |
| − | "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 | + | * Internal links on the "whatever/example/something/stuff" page are relative to the current URI -- a syntax suggestion (others are possible): |
| − | relative to the current URI -- a syntax suggestion (others are | + | ** <nowiki>[[things]]</nowiki> refers to the URI "whatever/example/something/stuff/things", i.e. a sub-article |
| − | possible): | + | ** <nowiki>[[/things]]</nowiki> refers to "whatever/example/something/things", i.e. an article at the same level |
| − | ** <nowiki>[[things]]</nowiki> refers to the URI | + | ** <nowiki>[[//things]]</nowiki> refers to "whatever/example/things", i.e. a parent-level article (aunt/uncle) |
| − | "whatever/example/something/stuff/things", i.e. a sub-article | + | ** <nowiki>[[////things]]</nowiki> refers to "things", i.e. a root-level article |
| − | ** <nowiki>[[/things]]</nowiki> refers to | + | * 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" |
| − | "whatever/example/something/things", i.e. an article at the same level | + | |
| − | + | 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) | |
| − | "whatever/example/things", i.e. a parent-level article (aunt/uncle) | + | -- 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. |
| − | + | ||
| − | i.e. a root-level article | + | 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). |
| − | * 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=== | ===Modification 1a=== | ||
| − | The [[wikipedia:Hierarchy|hierarchy]] need not even be a | + | The [[wikipedia:Hierarchy|hierarchy]] need not even be a [[wikipedia:Tree (graph theory)|tree]] or even necessarily |
| − | [[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 [[The Triangle, NC|NC Triangle Area]] and part of [[Durham County, NC]] -- 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). |
| − | [[wikipedia:Directed acyclic graph|acyclic]] in order for this to work. | + | |
| − | For instance, if we have an article about Durham, NC -- which is part | + | The main change here, then, would be the addition of "parent"-declaration syntax and corresponding changes in the database |
| − | of North Carolina, but also part of the NC Triangle Area and part of | + | (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). |
| − | 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/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=== | ===Modification 2=== | ||
| − | '''Primary linking by article ID''' Although I think we should continue | + | '''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. |
| − | to support linking by article name – as this makes it easier | + | |
| − | to "request" articles, to create requested articles, and to keep track | + | 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 |
| − | of article requests – perhaps the primary means of | + | 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"). |
| − | referencing other articles should be by using their ID in the database. | + | |
| − | This would largely negate the need for internal "redirects" and link | + | 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>. |
| − | updates when an article's name changes. It would not remove the need | + | ==Related Articles== |
| − | for | + | * [[MediaWiki/archive/subwikis]]: mainly of historical interest at this point |
| − | 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>. | ||
Latest revision as of 00:31, 15 December 2017
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.
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.)
This leads to a few minor awkwardnesses:
- Articles may have to be carefully named to indicate the context in which they belong, e.g. several neighborhood groups sharing a wiki might want to have articles entitled "Crime Watch", but only one of them can actually use that name; the others, at least, will need to add some clarifying context to the title, e.g. "Pinecrest Area Crime Watch". Ideally, all the articles should have this clarifying context, since each such article is primarily of interest to its respective neighborhood.
- Navigational and look-and-feel issues:
- The "main article" for the special interest doesn't serve well as a home page:
- The logo is the main wiki's logo, and is not specific to the special interest
- There is no way to customize the stylesheet or skin for articles in the special interest area
- The navigation bar points to articles relating to the main wiki, rather than to articles relating to the special interest
- The special interest user may tend to wander out of the pages related to their special interest and get lost, as all the navbar links will point (as they do for the special interest "main article") to articles relating more to the main wiki than to their special interest
- 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.
- The "main article" for the special interest doesn't serve well as a home page:
- 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 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.
Alternatives
In addition to the specific alternatives above (which solve only one issue), the other obvious alternative which solves all of the above problems is simply to create separate wikis for each special interest. The disadvantages to this are as follows:
- Requires webmaster intervention: a new database must be added to MySQL for each new wiki, or at the very least the wiki creator has to have the ability to add new tables and must take care to choose a non-conflicting prefix
- No searching across subwikis: Some users may be interested in several related special interest areas. For example, a user searching for information about setting up scanners under Linux might want to search the "Linux" and "Computer Hardware" areas for articles
- No sharing of users: Requiring users to create accounts for each area of interest makes it less rewarding to create an account in any of them (since the benefit of registration is limited to the wiki in which you registered) and thus encourages users to maintain a narrow focus and generally puts unwanted barriers between interests and reduces overall interaction. (Note: the MediaWiki development team are working on solutions to share users between wikis, which would address this one issue.)
- No easy way to move articles between special interests: sometimes a special interest area starts as a single article, or a group of articles which are later seen to be related. Moving articles between wikis while preserving their histories and their links to other articles is doable but tedious.
Proposal
Some proposed modifications to the existing MediaWiki standard
The prime area of concern is that users should 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 of this functionality).
Given the extent of the modifications, it may actually be a better idea to start from scratch than to attempt to shoehorn MediaWiki into a role for which it was perhaps never intended. Nonetheless, it may be easier to start out by thinking of the design in terms of modifications to a known model.
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")
Note: this should probably be modified to take into account MediaWiki's subpage syntax, where [[/subpage]] is equivalent to [[current page/subpage]].
- 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):
- [[things]] refers to the URI "whatever/example/something/stuff/things", i.e. a sub-article
- [[/things]] refers to "whatever/example/something/things", i.e. an article at the same level
- [[//things]] refers to "whatever/example/things", i.e. a parent-level article (aunt/uncle)
- [[////things]] 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 hierarchy need not even be a tree or even necessarily 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, NC -- we could have the URI "earth/us/nc/durham", but also "earth/us/nc/triangle/" which contains a link to [[durham]] (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. "[[parent:earth/us/nc]]" -- 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 [[article name|link text]] or [[0000|link text]]. Perhaps the wiki software would even expand the latter form to include the article name, for human reference: [[3415 Article Name|link text]] .
Related Articles
- MediaWiki/archive/subwikis: mainly of historical interest at this point