On Sunday 28 July 2002 03:00 am, The Cunctator wrote:
> What are the articles this person has been changing?
For 66.108.155.126:
20:08 Jul 27, 2002 Computer
20:07 Jul 27, 2002 Exploit
20:07 Jul 27, 2002 AOL
20:05 Jul 27, 2002 Hacker
20:05 Jul 27, 2002 Leet
20:03 Jul 27, 2002 Root
20:02 Jul 27, 2002 Hacker
19:59 Jul 27, 2002 Hacker
19:58 Jul 27, 2002 Hacker
19:54 Jul 27, 2002 Principle of least astonishment
19:54 Jul 27, 2002 Hacker
19:52 Jul 27, 2002 Trance music
19:51 Jul 27, 2002 Trance music
For 208.24.115.6:
20:20 Jul 27, 2002 Hacker
For 141.157.232.26:
20:19 Jul 27, 2002 Hacker
Most of these were complete replacements with discoherent statements.
Such as "TAP IS THE ABSOLUTE DEFINITION OF THE NOUN HACKER" for Hacker.
For the specifics follow http://www.wikipedia.com/wiki/Special:Ipblocklist
and look at the contribs.
--mav
So, it seems (if I interpret Jimbo's mail on wikitech and the discussion
here correctly) that most of us would like *some kind* of category
scheme in wikipedia. I do, too! But, we seem to differ on the details
(shocked silence!).
So far, I saw three concepts:
1. Simple categories like "Person", "Event", etc.; about a dozen total.
2. Categories and subcategories, like
"Science/Biology/Biochemistry/Proteomics", which can be "scaled down" to
#1 as well ("Humankind/Person" or something)
3. Complex object structures with machine-readable meta-knowledge
encoded into the articles, which would allow for quite complex
queries/summaries, like "biologists born after 1860".
Pros:
1. Easy to edit (the wiki way!)
2. Still easy to edit, but making wikipedia browseable by category,
fine-tune Recent Changes, etc.
3. Strong improvement in search functions, meta-knowledge available for
data-mining.
Cons:
1. Not much of a help...
2. We'd need to agree on a category scheme, and maintenance might get a
*little* complicated.
3. Quite complex to edit (e.g., "<category type='person'
occupation='biologist' birth_month='5' birth_day='24' birth_year='1874'
birth_place='London' death_month=.....>")
For a wikipedia I'd have to write myself, I'd choose #3, but with
respect to the wiki way, #2 seems more likely to achieve consensus (if
there is such a thing;-)
Magnus
At Mon, 31 Mar 2003 12:40:12 +0100,
tarquin (tarquin(a)planetunreal.com) wrote:
>
>
> Gary Curtis wrote:
>
> >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.
> >
>
> Well we sort of already have this...
> Maintenance page -> disambiguation pages with links
>
> :-)
>
> The other mechanism we have for this is Plain Old Brainpower -- if
> you
> write in a certain area of the Wikipedia for some time, you come
> to know
> which pages are disambiguation and which aren't.
Frankly, this proposed mod is not for users of the skill level
of tarquin (or say mav or zoe). They don't need "software
assistance", but would probably use it ;-).
It is for Jack or Jill Average, who adds a link to [[mercury]]
with little thought that there are so many mercury's. I want
the software to "protect" the database from this user's well-
intentioned edit. Not that the user is going to do any real
damage here, but if the user resolves the link then someone
doesn't have to do it later.
Gaz
--------------------------------------------------------
Looking for a free email account?
Get one now at http://www.freemail.com.au/
--------------------------------------------------------
Hi people.
This is my first post to wikipedia-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
--------------------------------------------------------
Looking for a free email account?
Get one now at http://www.freemail.com.au/
--------------------------------------------------------
--------------------------------------------------------
Looking for a free email account?
Get one now at http://www.freemail.com.au/
--------------------------------------------------------
I have made the ANNOUNCE-L list stop advertising itself on
http://www.wikipedia.org/mailman/listinfo. Also, I have added
wikitech-l and wikipedia-l as subscribers to the list.
To my knowledge (and from looking at the archives), this list has
never been used, except to discuss whether or not it should be used
for announcements. This being the case, I was getting tired of having
to discard the spam messages that come in on it. I'm hoping that
removing the list from those advertised on the listinfo pag, I will
reduce the amount of junk that comes in on the list.
This list was originally meant as THE place for wikipedia
announcements (software changes, policy changes, etc.). So, it only
makes sense that all lists that might be interested in such
information should be on the memberlist. Of course, none of this
matters unless poeple start using it.
I'm happy either way.
--
"Jason C. Richey" <jasonr(a)bomis.com>
_______________________________________________
Announce-l mailing list
Announce-l(a)wikipedia.org
http://www.wikipedia.org/mailman/listinfo/announce-l
Hi,
I was very keen to know whether the guys at wiki have plans to start a project to produce e-books/textbooks out of wiki articles. There was another similar request on the group also, so will the guys at wiki please respond back and tell us if they're interested on starting something like this. I have a whole lot of ideas that I was hoping to share on this sort of a project.
I've put down all these ideas on my website, its at http://www.geocities.com/abioommen
I've put a name to it -- gdocs.org -- but thats just for the heck of it and I don't have the resources or time to do it alone. Its a idea that I believe that Wiki can really bring to reality and it can kick off some sort of a revolution in open-content, if wiki seriously does something like this.
So I was hoping if the guys at wiki would start something like this!!
--abhishek
> > I did have another idea for what to do in this case. Perhaps all
> > the links
> > to the old page could remain pointing to what is now an automated
> > disambiguation page. Readers (not necessarily editors) could be
> > prompted to
> > select the right link. Their choice is reflected by updating the
> > referring
> > page. Of course the link could be manually fixed later, if
> > something goes
> > wrong.
> >
> > -- Tim Starling.
>
>I understand what you are getting at here Tim, but I don't think
>it is reasonable to push an editting task on a reader. Now, if
>they show any editting interest in the page that is a different
>matter. Then you could (perhaps) ask them to fix a few links
>while they are there. You would have to give them a means to
>chicken out though.
>
>The optimum would go a little like this...
>
>1. Reader clicks on some link
>2. Oops, what am I doing at this disambig page
>3. Correct destination is radio button 1, or 2, or 17
>4. Wiki software fixes calling link AND...
>5 Reader transparently moves to desired destination.
>6. Gaz wins Lotto next day and retires ;-)
>
>But then what do you do if THAT reader got it all wrong?
The reader doesn't think they're editing, the reader is just trying to get
to the information they're interested in. If a reader views [[Roman
mythology]] then [[Mercury]] then [[Mercury (mythology)]], we can surmise
that it's more likely than not [[Roman mythology]] should link to [[Mercury
(mythology)]]. If the user is distracted, suddenly realising how interesting
the element mercury is, the link will be set incorrectly. Readers following
the same path later click on the "other uses for the word 'mercury'" header
in [[Mercury (element)]] (after a moment of confusion). Editors following
that link will fix it.
I don't know what the right way to do it is. I'm just contributing a couple
of ideas.
-- Tim Starling.
_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
At Mon, 31 Mar 2003 22:27:19 +1000,
Tim Starling (ts4294967296(a)hotmail.com) wrote:
> > > * 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.
> >
> >Sounds like a bad idea - any pages that previously referred to
> the old
> >page _wrongly_ would now be even more wrong. There will be rare
> cases where
> >one disambiguation subject would be the only one that had links,
> but more
> >commonly there are a few links that go to other disambiguation
> subjects. So
> >I would very much prefer to have disambiguation done by hand, or
> at least
> >under human control.
>
> I did have another idea for what to do in this case. Perhaps all
> the links
> to the old page could remain pointing to what is now an automated
> disambiguation page. Readers (not necessarily editors) could be
> prompted to
> select the right link. Their choice is reflected by updating the
> referring
> page. Of course the link could be manually fixed later, if
> something goes
> wrong.
>
> -- Tim Starling.
I understand what you are getting at here Tim, but I don't think
it is reasonable to push an editting task on a reader. Now, if
they show any editting interest in the page that is a different
matter. Then you could (perhaps) ask them to fix a few links
while they are there. You would have to give them a means to
chicken out though.
The optimum would go a little like this...
1. Reader clicks on some link
2. Oops, what am I doing at this disambig page
3. Correct destination is radio button 1, or 2, or 17
4. Wiki software fixes calling link AND...
5 Reader transparently moves to desired destination.
6. Gaz wins Lotto next day and retires ;-)
But then what do you do if THAT reader got it all wrong?
Gaz
--------------------------------------------------------
Looking for a free email account?
Get one now at http://www.freemail.com.au/
--------------------------------------------------------
> > * 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.
>
>Sounds like a bad idea - any pages that previously referred to the old
>page _wrongly_ would now be even more wrong. There will be rare cases where
>one disambiguation subject would be the only one that had links, but more
>commonly there are a few links that go to other disambiguation subjects. So
>I would very much prefer to have disambiguation done by hand, or at least
>under human control.
I did have another idea for what to do in this case. Perhaps all the links
to the old page could remain pointing to what is now an automated
disambiguation page. Readers (not necessarily editors) could be prompted to
select the right link. Their choice is reflected by updating the referring
page. Of course the link could be manually fixed later, if something goes
wrong.
-- Tim Starling.
_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
At Mon, 31 Mar 2003 12:28:59 +0200 (CEST),
Andre Engels (engels(a)uni-koblenz.de) wrote:
> On Mon, 31 Mar 2003, Tim Starling wrote:
>
> > 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.
>
> Sounds like a bad idea - any pages that previously referred to the
> old
> page _wrongly_ would now be even more wrong. There will be rare
> cases where
> one disambiguation subject would be the only one that had links,
> but more
> commonly there are a few links that go to other disambiguation
> subjects. So
> I would very much prefer to have disambiguation done by hand, or
> at least
> under human control.
>
> Andre Engels
My original idea is for the human to control the disambiguation
process. The software just facilitates the process.
Gary Curtis
--------------------------------------------------------
Looking for a free email account?
Get one now at http://www.freemail.com.au/
--------------------------------------------------------