This is also on wikitech-l, forwarded on to wikipedia-l at Cunctator's
request.
I've already briefly discussed this with Gary on his user talk page. A few
observations:
In his proposal below, Gary does not explicitly deal with what happens when
a previously unambiguous name is given a second meaning. Here's what I
suggest:
* The original page is moved to a disambiguated name. This name is selected
by the user who creates the second page.
* All existing links are updated via the pipe trick to point to the
newly-disambiguated primary article.
Gary's "resolve links" page, in my opinion, could be made easier to use by
making it a list of links, each one followed by a combo box, rather than a
clone of the full article.
As I said on [[User talk:Gaz]], this kind of software disambiguation, if
implemented properly, could satisfy both camps in the city names preemptive
disambiguation debate (see wikiEN-L). Pre-emptive disambiguation would be
(IMHO) unnecessary, and since manual links to [[Perth]] instead of [[Perth,
Australia]] are encouraged, I would see no reason to push primary-topic
disambiguation.
Gary, are you offering to code this?
-- Tim Starling.
>From: Gary Curtis <wikiman(a)freemail.com.au>
>Reply-To: wikitech-l(a)wikipedia.org
>To: wikitech-l(a)wikipedia.org
>Subject: [Wikitech-l] Software Assisted Context Resolution
>Date: Mon, 31 Mar 2003 05:08:12 GMT
>
>Hi people.
>This is my first post to wikitech-l, and its a biggun. I've
>been mulling over this idea for a while now and have finally
>gotten the electrons moving...
>
>I propose a number of changes to the Wikipedia software to
>enable "software assisted context resolution", or if you
>prefer "software assisted disambiguation". The primary purpose
>of these changes is to allow users to more easily resolve
>ambiguous links at the time they are created, or if necessary,
>at some later stage. I stress that this is not "automatic"
>link resolution, although the process will be invoked
>automatically in many cases.
>
>The process, detailed below, is invoked in two ways. The
>first would be manually and explicitly by the user. The
>secound would be automatic when an article with new or
>modified links it saved.
>
>To enable this process to be invoked manually I propose that
>a new meta-link be added to the footer of every page that
>contains at least one link (most pages). IMHO, an appropriate
>position would be between "Edit this page" and "Discuss this
>page". It would read "Resolve links", and invoke a page titled
>"Resolving links from (real title)". This new page would look
>identical to the original except that the destination of each
>link is changed to a "context selection" page as detailed below.
>Note that it is entirely possible (and probable) that many links
>will point to UNambiguous pages. "Context selection" pages will
>still be generated for these links as the user may have found
>the first instance of ambiguity and will need to deal with it.
>
>The "context resolution" process would also be invoked when an
>article is saved, and the article contains new or modified
>links. In this case the "context resolution" page would not be
>a mimic of the real page. Rather, a short list of new or modified
>links would be generated in the form of an alphabetized list.
>
>The "context selection" pages are generated from the articles
>currently known as "disambiguation pages". The bulleted list
>found in these articles is transformed into a set of radio
>buttons. In addition, a radio button is generated that basically
>means "unresolved". At the bottom of this list is a small form
>to allow new links and associated context descriptions to be
>added. Whichever option is selected from this page, the link in
>the calling page is adjusted to point to the selected destination
>article, with the original text preserved by using the pipe trick.
>
>A by-product of these changes will be that the "context selection"
>pages will, in the main, be updated by the wiki software (as
>opposed to hand editted). This should make it possible to more
>tightly control the layout of these pages, perhaps with the
>addition of subheadings like "People", "Places", "Things".
>Further, when the "Edit this page" link is clicked on a "context
>selection" page, the normal edit page is replaced by a purpose-
>built form for editing such pages.
>
>I understand that there are probably a millions reasons why some
>aspect(s) of the above will be difficult or impracticable. I hope
>that the general concept is possible and feasible.
>
>Gary Curtis
>[[User:Gaz]] on Wiki
><wikiman.at.freemail.dot.com.dot.au> for all Wiki email
_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
Below is the start of a thread on the possibility of having a syndicated
article a day queue (sorry, I didn't have much time to write a real proposal
for this but just wanted to float the idea by everyone):
Yo. could you bring up on wikipedia-L the idea of re-establishing something
like "article a day queue," but with an rss feed that allows syndication,
sending the first paragraph of 1 - 5 articles a day? maybe setting up
voting/submission system to work out which articles to send, and making it
multilingual? just some ideas. thanks, Koyaanis Qatsi
Seconded, that's a great idea. --Brion
be much easier for wiktionaries word of teh dya too. -fonzy
We already have an article a day - A new day page is automatically displayed
each day which in turn has many articles linked from it. I also add at least
three new historical anniversaries onto the Main Page daily (and then there
are the updates to the other parts of ==Selected Articles==). But the
syndication idea would be most useful at promoting Wikipedia. Perhaps we
could syndicate the whole ==Selected Articles== section? --mav
-- Daniel Mayer (aka mav)
WikiKarma
The usual at [[March 24]]
wikipedia has been down for a few hours. I'm not
subscribed to wikipedia-L, so could someone pass this
on if the moderator doesn't see it and if the
powers-that-be don't know about the problem?
thanks,
kq
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
> The official vote results were to count pages in
> article space that are:
> * not completely empty (size greater than 0 bytes)
> * contain at least one link (search for "[[" should
> do)
Is it me or isn't it true that all pages that contain
at least one link would not be completely empty?
Thus, saying both of the above statements is a bit
redundant. :)
Chuck
=====
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
> Message: 5
> From: "Pedro M.V." <macv(a)interlap.com.ar>
> To: <wikipedia-l(a)wikipedia.org>
> Subject: Re: [Wikipedia-l] is it possible?
> Date: Fri, 28 Mar 2003 12:43:55 +0100
> Reply-To: wikipedia-l(a)wikipedia.org
>
> When typing this page, you recieve like result:
>
> (There is currently no text in this page)
>
> So, you can edit it and include text.
>
> If your goal relating this page is look for another
> pages related with schengen ( this is, search topic
> related pages ), it´s very interesting the system
> would include automatically the text "schengen" in
> the search box, so you only have to click in the
> search button.
>
> This would be a very interesting and usefull
> utility.
>
> Regards.
This sounds most excellent!
Chuck
=====
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Is it possible if someone types the name of an article
which doesn't yet have any text that that person could
be sent to a search page for that topic. Thus, if I
type http://www.wikipedia.org/wiki/Schengen, instead
of getting a page saying that this page doesn't exist,
I would instead get the search results page? Would
anyone else want this?
Chuck
=====
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
> > I would not like it. I use this method (creating
> the URL of the page by
> > hand) sometimes when I want to create a page and
> there are no links to it,
> > or I am not sure.
>
> I do this too and I would find the proposed change
> frustrating.
I think it would also be possible to create a link
from that search page where you could write the
non-existant article. But perhaps that makes things
too complicated...
Chuck
=====
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Opps! I sent this message to WikiEN-l by mistake. Sorry.
>Is there any way that non-English Wikipedias could be
>on a seperate server than the English one, so we
>wouldn't have to feel the effects of the massive
>English-language traffic killing us?
>
>Chuck
But the current slowdown was caused by a fr.wiki sysop running a, uh, less
than optimized sql command. ;-) If there were such a separation then only
en.wiki would have been up during that time and we would probably have a
flood of angry emails in a variety of languages complaining about being
"singled-out". It is far better to keep the databases together, have the
webserver on its own powerful box, and then have the mailing lists on a
cheapo 500 MHz Linux box (which I can borg together and donate if needed -
but I'm sure somebody else could donate an even better box).
Another server is going to be up soon but this is only a short term solution
given how fast we are growing. Mid to long term we need to set-up the
Wikimedia Foundation so that we'll have a legal entity to accept
tax-deductable donations and receive grants.
Then we can start to build a really fast server cluster with 1GB Ethernet and
if needed even start to pay Jimbo his cost for bandwidth. I hear bandwidth is
pretty cheap for ISPs who buy it in bulk (like Jimbo) but is kinda expensive
for ISP customers - the last thing we want is to be just another ISP customer
so we shouldn't expect Jimbo to pay all our bills in full forever (we need to
prevent taking Jimbo for granted - paying him back his monthly out-of-pocket
cost only seems fair once we have the money to do so). But if he insists on
providing unlimited bandwidth to us for free indefinitely we shouldn't
complain about that either. ;-)
-- Daniel Mayer (aka mav)
WikiKarma
The usual at [[March 20]]