subject: [WikiEN-l] Double checking

body:
Are you sure?  You're on my piece of paper here as being on the
arbitration list.

Sean Barrett wrote:

> Jimmy Wales wrote:
> >If I overlooked anyone in my appointments, don't be insulted and don't
> >hesitate to ask about it.  It was unintentional.  I tried to appoint
> >everyone who volunteered.  Anyone who is left over and would still
> >like to be appointed will be appointed to mediation.
>
> I volunteer but have not been appointed.  Is there something we need to
> talk about?
>
> the Epopt, aka
>
> --
>  Sean Barrett     | Hostes alienigeni me abdxerunt.
>  sean at epoptic.com | Qui annus est?
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: wikitech-l

source: pipermail-mbox

from_name: Stan Shebs

subject: [Wikitech-l] I never metadata I didn't like

body:
Evan Prodromou wrote:

>So, when I was weeding through the RFEs on SourceForge last week, I
>noted quite a few having to do with metadata, including:
>
>      579758 Consider keyword meta tags
>      629323 Simple article categorisation system
>      766213 Provide Standardized Subject Search
>      839394 Meta ICBM tags when appropriate
>
>I think I must have closed like 5 other RFEs and referred them to
>#629323. There's lots of people who want category metadata.
>
>Anyways, I wanted to float a design idea for inclusion of metadata in
>MediaWiki articles. None of this is particularly new, and it seems
>like most has been suggested at one point or another.
>
All seems very reasonable; the tags will be invaluable in maintaining
indexes
like [[list of people]], which is missing thousands of bios that are
scattered all
over WP now. I thought Magnus or somebody had implemented it already?

Syntaxwise, I like [[meta:name:value]], with a general inclination to create
new names that are recognized specially, so I can say [[category:person]]
or even [[cat:person]] to be really brief, since nearly all articles
will have one
or more category tags.

Stan


list: wikien-l

from_name: Jimmy Wales

subject: [WikiEN-l] Wikiquette committee appointments

body:
Erik Moeller wrote:
> Cunctator has been an ardent advocate of using message
> boards. I have some reservations about boards, but perhaps this would be
> an opportunity to try them, especially as this will be a "use once, then
> forget" kind of system (i.e. people will not want to subscribe/unsubscribe
> for a single debate). phpBB allows posting without registration, and
> the admins could be registered users who are also moderators on the board.

I think that's a good idea, it is an opportunity to try something new,
yes.

--Jimbo


subject: Search engine. Was: [Wikitech-l] Fast

body:
Brion Vibber wrote:
> So why are we talking about this? Google isn't going to vanish from the
> web because we get the internal search back online.

Obviously, Brion, you must have missed the last Cabal memo in the next step
in world domination, bwah ha ha ha!  ;-)

--Jimbo


from_name: Ray Saintonge

subject: [WikiEN-l] contributions of User:Mr-Natural-Health

body:
Jimmy Wales wrote:

>Ray Saintonge wrote:
>
>>>From his user page:
>>
>>>under "modified pages"
>>>"Alternative medicine - I cleaned up this article. I removed the anti-bias
>>>and made it pro-alternative medicine."
>>>
>>>under "Interests"
>>>"To get important natural health related information and definitions in an
>>>Internet accessible encyclopedia / dictionary."
>>>
>>>It is clear that /his/her/its purpose is to inject their POV and remove
>>>that of others.
>>>
>>So he's trying to put his own spin on things.  How is that so different
>>from what most Wikipedians are trying to accomplish?  Announcing areas
>>of interest is pretty normal.
>>
>
>But doesn't that first one go pretty far beyond announcing an area of
>interest?  We don't want articles to be "pro-alternative medicine" or
>"anti-alternative medicine".
>
>Certainly, if he came across an anti-biased article, and made it more
>neutral, that's wonderful, not a problem at all.  But if his intention is
>to make it pro-, hmmm, not really right, eh?
>
How precise are people when writing to their own user pages?  I don't
pay much attention to mine, while others seem diligent in trying to take
credit for every contribution they make.  He might have said "made it
*more* pro-alternative medicine" and it would have seemed less absolute
by adding just one word.  What I found remarkable about the articles was
(at least a couple days ago) the lack of activity on the talk pages.

There are serious difficulties in dealing with any kind of alternative
science topic.  There is a tendency for the supporters of mainstream
science to believe that there way is the only right way even when there
is no evidence to that effect.  Often there is no convincing evidence at
all.  This does not mean that every weird and wonderful idea that comes
along should be treated as serious science, just that critics of the
mainstream view should be accorded their fair share of respect.

Ec


from_name: Dave Caroline

subject: [Wikitech-l] Alphabetical list of entries

body:
At 18:08 04/12/2003 +0100, you wrote:
>Would it be possible to automatically create an alphabetical list of
>wikipedia entries/articles? This is available in many electronic
>encyclopedia and would make searching easier.
>
>Cheers,
>
>Jurriaan

I am just writing a search index and had also thought of something similar
so will add something.
Please add comments / what you would like to my user page on
http://meta.wikipedia.org/wiki/User:Archivist

Dave Caroline

aka archivist

>IWikitech-l mailing list
>Wikitech-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Poor, Edmund W

subject: [WikiEN-l] User: TittoAssini

body:
I forget our policy on offensive usernames.

Is "TittoAssini" perfectly okay, or obviously NOT okay, or what?

Call me dirty-minded, but I can't help thinking of feminine fleshy parts
when I read that name...

Ed Poor


from_name: Evan Prodromou

subject: [Wikitech-l] Going stable

body:
So, are there any high-profile bugs that need to be squashed before
doing another stable release?

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [WikiEN-l] User: TittoAssini

body:
Once again, I am saved from an embarassing mistake by my hard-working
and sharp-eyed co-workers!

<<See

http://www.kamus.it/titto/

It might be him.>>

Sheepishly,

Ed "Little Lamb" Poor


from_name: Jurriaan Schulman

body:
Would it be possible to automatically create an alphabetical list of
wikipedia entries/articles? This is available in many electronic
encyclopedia and would make searching easier.

Cheers,

Jurriaan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031204/baf572d0/attachment.html>


subject: [WikiEN-l] User: TittoAssini

body:
After dealing with the Dan Savage / Rick Santorum thing, I would be
suspicious even of Francis of Assisi. I'm having trouble assessing
things without slipping on my own mental froth.

Uncle Ed


from_name: Carl Witty

subject: Search engine. Was: [Wikitech-l] Fast

body:
On Thu, 2003-12-04 at 01:47, Andrew Alder wrote:
> G'day Peter and the Group
>
> At 07:39 AM 4/12/03 +0000, Peter Bartlett wrote:
>
> >  >. The not being realtime may be a plus or minus, this is the very
> > thing we tossed around a little in the Pump.
> >  >Certainly for Wikipedia contributors, realtime is best. But
> > perhaps not so for readers, who are after stable content.
> >
> >
> >         As was pointed out on the pump, there is no reason to
> >         suppose that the pedia was any more "stable" when Google
> >         took its snapshot than it is at any other time..
>
>
> True. No argument at all with this.
>
> But the probability that Google indexes a particular version is
> roughly proportional to the time for which that version is the current
> version. Therefore, the version presented by Google is on average more
> stable than the "current" version. I tried to point this out, but I'm
> afraid I didn't do it very clearly.

No, it's not; it's exactly the same.  Consider (for ease of exposition)
an article in the middle of an edit war.  Three-quarters of the time it
has version "A" (the "stable" version); one-quarter of the time it has
version "B" (the "unstable" version).  Then, three-quarters of the time,
when the Google spider grabs and indexes this article, it will get
version "A".  Three-quarters of the time, if somebody did a full-text
search on the "current" wikipedia database, they would get version "A".
Exactly the same.

There's also the effect that Brion mentioned: even if Google happened to
index a "stable" version when the current version was "unstable", the
person would (by default) still end up reading the current, unstable
version.

Carl Witty


body:
So, when I was weeding through the RFEs on SourceForge last week, I
noted quite a few having to do with metadata, including:

      579758 Consider keyword meta tags
      629323 Simple article categorisation system
      766213 Provide Standardized Subject Search
      839394 Meta ICBM tags when appropriate

I think I must have closed like 5 other RFEs and referred them to
#629323. There's lots of people who want category metadata.

Anyways, I wanted to float a design idea for inclusion of metadata in
MediaWiki articles. None of this is particularly new, and it seems
like most has been suggested at one point or another.

---8<---

WHAT IS METADATA?
-----------------

Metadata is data about data. For example, the filename and count of
bytes of a file on a filesystem is metadata: not part of the data, but
_about_ the data. Metadata can arise naturally from the data (byte
count) or can be added from outside the data (file name).

Metadata helps us sort data, find data, and make decisions about
data. For example, you can sort files in a directory alphabetically by
filename to find a file you want. Or you can sort them by size to find
the biggest or smallest. You can delete a file called "TEMPFILE.$$$"
because you know it's a temporary file.

We use metadata so often, we sometimes forget that it's "meta". But it
is: changing the name of a file, or moving it to another folder,
doesn't change the contents of the file. It just changes how we find
and access the file.

METADATA IN MEDIAWIKI
---------------------

We use a lot of metadata for MediaWiki articles: page sizes, page
histories, new pages page, recent changes page, etc. etc. Some of the
metadata we use is calculated from the data itself -- sizes -- and
some of it is not -- timestamps, who made changes, etc. It would
probably be fair to say that article titles and redirects are
metadata.

One form of metadata that we now use is interlanguage
links. Interlanguage links are metadata that say: "There is an article
in the language XX Wikipedia (or other installation) that covers this
same topic." That's pretty cool metadata to have.

What I propose it that MediaWiki expand this metadata format to cover
other types of metadata, such as:

      * categorization -- saying that particle physics is in the
        physics category, or that Lord of the Rings is in the fantasy
        books category
      * relationships between articles -- break up a single page into
        multiple chapters or sections, and note that they're all part
        of the same article
      * synopses -- providing a synopsis or description of an article
      * geography -- marking up pages to specify that they cover
        a particular geographical location
      * customizable per-installation metadata -- metadata that may
        make sense for different installations.

I'm particularly interested in this last one, since it would help us
with Wikitravel.

METADATA IN THE DATABASE
------------------------

I think it's pretty reasonable to just think of metadata as name-value
pairs, where the name key is not necessarily unique. For example, we
could have a table like this for the article on David Brinkley:

      article id   metadata_name        metadata_value
      ------------------------------------------------
      1            category             journalists
      1            category             American people
      1            see_also             CBS
      1            see_also             CBS News

It should be relatively easy to slurp up the metadata on an article
when rendering the article, and to pluck out the metadata from an
article when saving it. We do this with links, broken_links, and
image_links now.

METADATA IN WIKITEXT
--------------------

One way to do metadata is to have a different entry format for
metadata than for the text and markup of an article. I'm going to
reject that, since we already have a winning mechanism for marking up
some metadata -- interlanguage links -- within the Wiki
markup. Whether this would make it _really_ data instead of metadata
is left as an exercise to the reader.

There's a couple of ways we could do this in wikitext:

        <<name=value>>
        <<name:value>>
        [[meta:name=value]]
        [[meta:name:value]]
        [[name:value]]

The first couple are kinda radical, and don't really jibe with
interlinks, anyways. The last one has the potential to clash with
other namespaces.

I prefer [[meta:name=value]], just because it's kinda easy. I realize
that the name "meta" clashes with "metawikipedia", so maybe another
work would work.

It's not particularly important what format we use; what's important
is that we have a way to enter arbitrary name-value pairs into the
text of articles.

RENDERING METADATA
------------------

I think there are a couple of ways we can deal with metadata in an
article when rendering it:

        * Add it as a <meta> tag to the HTML <head>
        * Add it as a <link> tag to the HTML <head>
        * Add it as an out-of-page link, like Interlanguage links work
          now
        * Render it in the text of the document (I can't see why this
          would be useful, but)
        * Ignore it

I think we could have several pre-defined names, with predefined
rendering, and other names with possible renderings configurable
per-installation.

OTHER USES OF METADATA
----------------------

There are some other uses of metadata, of course. One would be
automatically-built directories, by category.

---8<---

So, my second big proposal of the day.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Fantasy

subject: [Wikitech-l] We need 10000 to 20000 USD per year?

body:
Hi Jimbo, or whoever can help me on this,

I was just having a look on the wikimedia donation page, and found out,
that we need 10000 to 20000 USD per year... (posted on 6.Oct.03 by
Eloquence:
http://meta.wikipedia.org/w/wiki.phtml?title=Wikimedia_Fundraising_page&oldid=18443
)

I tried to find the discussion about it on the mailinglist. Can some one
please tell me where I find more infos on this numbers or where they
come from?

Would be interresting to know, how much we will (probably) spend in 2004 on:
- bandwith
- HW
- People (server admin - is this a real plan, or just an idea?)
- Domain registrations
- ...

Thanks a lot,
Fantasy :-)


list: wikipedia-l

from_name: Daniel Mayer

subject: [Wikipedia-l] FDL used to stifle distribution of articles

body:
tc wrote:
>They're obviously skeptical of doing so, but as statistically
>the only website to use the GFDL, our opinions and needs
>have validity.

No - we aren't the only website to use the GFDL, but we are almost certainly
the largest content-creating website to use that license.

Perhaps that is what you meant?

-- Daniel Mayer (aka mav)


subject: [Wikipedia-l] NPOV again. [was Re: Non-English Wikipedias]

body:
tc wrote:
>What we can do, what we can measure, is what is the
>direction of Wikipedia's coverage of a subject. If the
>coverage is becoming more comprehensive, more
>grounded in references, more based on detail and
>reportage and fact, then we can say that the coverage
>is approaching a neutral point of view.

Yep. I view NPOV like I view my pragmatic perfectionism: It is not as a
destination, it is a journey.

--mav


subject: [Wikipedia-l] non-English Wikipedias

body:
Tomasz Wegrzanowski wrote:
>But the English Wikipedia isn't NPOV at all !
>Especially on anything related to Middle East
>conflict, it almost invariantly has Israeli bias,
>probably because of relatively large number
>of American Jewish contributors, compared to
>hardly any Arab contributors.

This is more of a side-effect of the fact that our continued overwhelming
reliance only on informal methods of conflict resolution results in the
selection of POV by people who are very motivated about certain subjects and
the selecting out or marginalizing of the POV of people who are less
motivated.

We could handle that when we were small (everybody could help with the handful
of slow-moving disputes we used to have), but it is much more difficult to do
this now that we are large (there seems to be dozens of disputes at any
moment now and people are generally less civil and more quick to revert than
they were when all the heavy users knew each other).

Thus we need to set-up mediation and arbitration procedures to deal with the
caseload.

Growing pains, that's all.

-- Daniel Mayer (aka mav)


subject: [Wikitech-l] Search engine.

body:
Brion wrote:
>So why are we talking about this? Google isn't going to
>vanish from the web because we get the internal search
>back online.

Yeah but the link to the Google search form may disappear from Wikipedia once
the in-house search is re-enabled. I find the Wikipedia Google search to be
rather powerful for serious data mining where up to the minute article data
is not needed. So I guess I'm advocating for a "Search {ProjectName} from
Google" radio button right under the MediaWiki search form. The default of
the toggle would be to use MediaWiki's own search functionality so long as
the database server isn't bogged down.

Giving people the option of live database search and Googlesearch should
reduce database server load as well (I always felt guilty using the Wikipedia
search before but was still too lazy to visit my user page to click on my own
link to the Wikipedia search form on Google. ).

-- Daniel Mayer (aka mav)


body:
Stan wrote:
>Syntaxwise, I like [[meta:name:value]], with a general inclination
>to create new names that are recognized specially, so I can say
>[[category:person]] or even [[cat:person]] to be really brief, since
>nearly all articles will have one or more category tags.

"meta:" is already used as an interwiki link syntax to get to Meta-Wikimedia.
However a metadata:namepace would be a great place to put category tags and
inter-language links. For example [[metadata:United Kingdom]] would be where
all the category tags and language links for [[United Kingdom]] would go.

As it is, all these metadata are (or will be in the case of category tags)
placed in the article itself resulting in cluttered harder to edit wiki text.
It might also be easier to do relations between articles and even make it
possible to place interlanguage links in once and have all the corresponding
metadata pages on other language wikis update at the same time.

Just brainstorming....

-- Daniel Mayer (aka mav)


from_name: Thomas R. Koll

subject: [Wikipedia-l] non-English Wikipedias

references:
<8z5fYlFxpVB@erik_moeller> <shsmk1jg0n.fsf@tux.gnu.franken.de>
	<3FCECBB7.3000000@rufus.d2g.com>
	<46206.160.53.250.101.1070538006.squirrel@ssl.ouvaton.coop>
	<3FCF8804.4090009@rufus.d2g.com>

body:
On Thu, Dec 04, 2003 at 11:16:20AM -0800, Delirium wrote:
> To get decently towards NPOV, I think a Wikipedia needs contributors
> from as many countries and backgrounds as possible.  To my knowledge,
> the English Wikipedia has contributors from:
> the United States, the UK, Germany, France, the Netherlands, Denmark,
> Norway, Sweden, Finland, Belgium, Poland, Serbia, Croatia, Romania,
> Greece, Italy, Russia, the Ukraine, Spain, Mexico, Israel, Brazil,
> Australia, India, China (incl. Hong Kong), Japan, South Korea, Ireland,
> Nepal, Slovenia, the Czech Republic, Portugal, and likely a lot of
> others I've forgotten to list.
>
> I'm skeptical that any other Wikipedias come even close to this, and I'm
> also skeptical that many of them ever will: what are the chances that
> people from each of the above countries will ever participate in, say,
> the Hindi Wikipedia?

I bet that Esperanto speaker are more wide-spread on the globe than English.
Also Esperanto seems to have a strong community open for new idea like
Wikipedia.

ciao, tom
--
http://www.tomk32.de - just a geek trying to change the world
   -.-       http://de.wikipedia.org/wiki/Benutzer:TomK32
   /|>	           http://tomk32.bookcrossing.com
   / \                 http://tinyurl.com/u6de


from_name: Andrew Alder

subject: Search engine. Was: [Wikitech-l] Fast

body:
G'day Peter and the Group

At 07:39 AM 4/12/03 +0000, Peter Bartlett wrote:

>  > . The not being realtime may be a plus or minus, this is the very
> thing we tossed around a little in the Pump.
>  > Certainly for Wikipedia contributors, realtime is best. But perhaps
> not so for readers, who are after stable content.
>
>As was pointed out on the pump, there is no reason to suppose that the
>pedia was any more "stable" when Google took its snapshot than it is at
>any other time..

True. No argument at all with this.

But the probability that Google indexes a particular version is roughly
proportional to the time for which that version is the current version.
Therefore, the version presented by Google is on average more stable than
the "current" version. I tried to point this out, but I'm afraid I didn't
do it very clearly.

These two effects tend to cancel each other out. The version presented by
Google is not necessarily better than the current version, but for readers
it's probably no worse and may even be better. That was my point.

Andrew A

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031204/429386a1/attachment.html>
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03


subject: [Wikipedia-l] non-English Wikipedias

body:
G'day All

(especially Delirium, Mav, and Jake and Erik whose posts crossed this one)

Yes. D'acord. Let's take it to the Meta. This is important.

A language is IMO inseperable from its culture. And so IMO, exactly what
constitutes NPOV will also reflect that culture.

There's a lot to wrangle about here...!

Andrew A

At 12:46 AM 4/12/03 -0800, Daniel Mayer wrote:

>Delirium wrote:
> >So I guess my question is: do people think it is likely that
> >Wikipedias in languages that are spoken almost exclusively
> >by people of one particular national background can ever
> >hope to achieve anything even remotely resembling the
> >NPOV on the Wikipedias in languages that are spoken by a
> >wide range of people?  Is having contributors from a wide
> >range of backgrounds a necessary prerequisite for NPOV
> >(as I suggest)?
>
>Very interesting insight! But since you touch on philosophical issues, I
>recommend you copy your post and put in on meta (otherwise this thread will
>get lost in the mailing list archives).
>
>I'll respond there.
>
>--- Daniel Mayer (aka mav)
>
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at Wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031204/cc8a117f/attachment.htm
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03


from_name: Erik Moeller

body:
Jimmy-

thanks for the nomination, but I have to decline at this point because of
time constraints and for philosophical reasons. Given that I'm frequently
a person *involved* in disputes, it would only seem too likely that I
would have to recuse myself much of the time. I prefer to get involved in
a non-formal manner and only request the intervention of formal authority
when necessary.

I will be very interested in seeing how these two committees make their
decisions, and offer my comments along the way. Re: mailing lists - not
sure about that. Cunctator has been an ardent advocate of using message
boards. I have some reservations about boards, but perhaps this would be
an opportunity to try them, especially as this will be a "use once, then
forget" kind of system (i.e. people will not want to subscribe/unsubscribe
for a single debate). phpBB allows posting without registration, and
the admins could be registered users who are also moderators on the board.

An alternative option would be Phorum, which can be interfaced with
mailing lists using a script called Phorummail. But phpBB would be faster
to set up. I would volunteer as a board admin (technical only) in case we
go with phpBB.

Regards,

Erik


subject: [Wikitech-l] Server-side File Caching Using a 404 Handler

body:
At 15:29 04/12/2003 -0500, you wrote:
> >>>>> "BV" == Brion Vibber <brion at pobox.com> writes:
>
>     Me> * On saving an edit of a page, the software simply *deletes*
>     Me> the cached HTML file. This will trigger the 404 handler on the
>     Me> next hit for the page, which will regenerate the cached file.
>
>     BV> This limits us to a single web server per wiki or a networked
>     BV> filesystem shared between them.
>
>Yeah, I think you're right. I'm not coming up with a better way to
>invalidate caches across multiple servers -- except maybe some kind of
>RPC, which would be real real losey.
>
>     Me> * Of course, logged-in users want to get their pages rendered
>     Me> _just_so_, with question marks and [edit] links, etc. They
>     Me> should also have all their "My page" and other links working.
>
>     BV> We have talk pages and notification for IP addresses, too.
>
>Thanks! I thought about this, but forgot to put it in. I don't have a
>clever idea for how to do notifications for non-logged-in users with
>static files.
>
>It's definitely a trade-off -- whether the performance advantage of
>serving static files would outweigh the loss of functionality from
>always generating dynamic pages.
>
>~ESP
In the long term when the system will get very busy should we generate a
static page for apache to "include" with a module for the dynamic. So that
it can be part cached and part live. Just thinking aloud :)

Dave Caroline

>Wikitech-l mailing list
>Wikitech-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l


body:
>>>>> "LA" == Lars Aronsson <lars at aronsson.se> writes:

    LA> In the wiki world, the article on Angola does not contain any
    LA> formalized, hierarchical metadata markup such as [[part
    LA> of:Africa]] or [[borders:Namibia]], but instead the plain
    LA> English phrase "Angola is a country in southwestern
    LA> [[Africa]], bordering [[Namibia]]".  That's what wiki
    LA> contributors can learn and be made to use.  It doesn't require
    LA> more complex parsing, it doesn't require any special database
    LA> tables, and it doesn't require hours of user training.

Some responses off the top of my head:

     * I think it might have be useful to back away from the
       politically-loaded use of metadata and just concentrate on the
       definition I gave. Metadata doesn't have to be for the Semantic
       Web or some remote librarians; it can be useful for inhouse
       stuff.

       I'm not particularly interested in the Semantic Web. I think
       Dublin Core is cool, but I think most of the Dublin Core data
       tags could be determined from the metadata (contributors,
       timestamps, license, etc.) we have now. So, this isn't really a
       Semantic Web/Dublin Core/yadda yadda issue.

     * There _are_, in fact, systems using <meta> tags, although
       Wikitext metadata doesn't need to be rendered as <meta>. For
       example, GeoURL (http://geourl.org/) uses ICBM <meta> tags,
       which is pretty cool.

     * Full-text search -- the Google approach -- is fine, but it sure
       does whack Wikipedia hard. It's disabled now. Some
       metadata-based navigation could be useful to offload some of
       the burden from full-text search.

     * Wikipedia contributors do metadata markup now -- with
       Interlanguage tags. It's not unprecedented. It's not
       particularly hard.

     * It should be obvious from the high number of [[list of X]]
       pages in Wikipedia that Wikipedia contributors think about
       categories and other metadata.

     * Providing metadata makes our data more useful to downstream
       users. For example, consider if someone wanted to take
       Wikipedia's prodigious collection of information about science
       fiction and fantasy and produce an encyclopedia out of
       it. Metadata could help them do it.

I guess my point is that metadata isn't necessarily bad,
authoritarian, or evil. It can make projects using MediaWiki more
useful.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [WikiEN-l] Re: Polling (was: Wikiquette committee appointments)

body:
I wrote:
> phpBB allows posting without registration, and
> the admins could be registered users who are also moderators on the board.
      ^^^^^^ mediators/arbitrators

I should also add that phpBB, and some other forum systems, include built-
in poll systems. This way, we could have an open discussion, but the poll
could be closed to mediators/arbitrators and would be easy to use (polling
via email is a PITA).

Regards,

Erik


in_reply_to:
<3FCFDAA7.9040301@apple.com> (Stan Shebs's message of "Thu, 04
	Dec 2003 17:08:55 -0800")

body:
>>>>> "SS" == Stan Shebs <shebs at apple.com> writes:

    SS> All seems very reasonable; the tags will be invaluable in
    SS> maintaining indexes like [[list of people]], which is missing
    SS> thousands of bios that are scattered all over WP now. I
    SS> thought Magnus or somebody had implemented it already?

There is some code to do categorization, which appears to be mostly
commented-out. It finds all the links in a page that start with a
language-specific prefix -- most of the languages, including English,
don't have the prefix defined -- and collects them into something
called "category links". It doesn't do anything with them, though.

There's also a special page for listing categories.

I think this was code that got started and never got finished.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Tomasz Wegrzanowski

subject: [Wikipedia-l] non-English Wikipedias

references:
<8z5fYlFxpVB@erik_moeller> <shsmk1jg0n.fsf@tux.gnu.franken.de>
	<3FCECBB7.3000000@rufus.d2g.com>

body:
On Wed, Dec 03, 2003 at 09:52:55PM -0800, Delirium wrote:
[...]
> So I guess my question is: do people think it is likely that Wikipedias
> in languages that are spoken almost exclusively by people of one
> particular national background can ever hope to achieve anything even
> remotely resembling the NPOV on the Wikipedias in languages that are
> spoken by a wide range of people?  Is having contributors from a wide
> range of backgrounds a necessary prerequisite for NPOV (as I suggest)?

But the English Wikipedia isn't NPOV at all !
Especially on anything related to Middle East conflict, it almost
invariantly has Israeli bias, probably because of relatively large number
of American Jewish contributors, compared to hardly any Arab contributors.


body:
>>>>> "LA" == Lars Aronsson <lars at aronsson.se> writes:

    LA> On the contrary, the "meta" HTML tag is most often used for
    LA> dishonest "spamdexing".

One other thought: I don't think this is a big issue in a Wiki
context. I doubt that metadata spamming in Wikipedia is really worth
the effort (say, putting a page in every single possible category).

It would probably just end up being reverted like other abuse or NPOV
behavior.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Yann Forget

subject: [Wikipedia-l] non-English Wikipedias

references:
<8z5fYlFxpVB@erik_moeller> <3FCECBB7.3000000@rufus.d2g.com>
	<20031204205027.GA18937@tavaiah>

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le Thursday 04 December 2003 21:50, Tomasz Wegrzanowski a ?crit :

> > So I guess my question is: do people think it is likely that Wikipedias
> > in languages that are spoken almost exclusively by people of one
> > particular national background can ever hope to achieve anything even
> > remotely resembling the NPOV on the Wikipedias in languages that are
> > spoken by a wide range of people?  Is having contributors from a wide
> > range of backgrounds a necessary prerequisite for NPOV (as I suggest)?
>
> But the English Wikipedia isn't NPOV at all !
> Especially on anything related to Middle East conflict, it almost
> invariantly has Israeli bias, probably because of relatively large number
> of American Jewish contributors, compared to hardly any Arab contributors.

Yes, that what I mean. And there are other subjects with the same situation.

Yann

- --
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/z6b6m4KYjQo0y9oRAsRAAJ477w/HqvEl0vQbnJhV481XybeloACffGIy
bZaGg8M0FvJaYCltuCF+Bfo=
=+9Jv
-----END PGP SIGNATURE-----


from_name: Pedro Fortuny

subject: [WikiEN-l] User: TittoAssini

body:
* Poor, Edmund W <Edmund.W.Poor at abc.com> [2003-12-04]:
> I forget our policy on offensive usernames.
>
> Is "TittoAssini" perfectly okay, or obviously NOT okay, or what?

See

http://www.kamus.it/titto/

It might be him.

--
Pedro Fortuny Ayuso: http://pfortuny.sdf-eu.org
Colegio Mayor Pe?afiel, Universidad de Valladolid
C/ Estudios 6, 47005 Valladolid, Spain -->        www.cmpenafiel.org
pfortuny at sdf-eu.org                         Tfn. Nr. 34  983  298277


from_name: Brion Vibber

subject: [Wikitech-l] Crashy MySQL

body:
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1289395.
InnoDB: You may have to recover from a backup.
031205  7:15:02  InnoDB: Page dump in ascii and hex (16384 bytes):
  len 16384; hex
d40044c50013acb30013acb10013acb400000006f5bb4a7745bf00000000000000000000
00000002380500070
[snip some dumped data showing various snippets of wiki pages]
93.170.250.70]] 11:06,.t.e.0....Jw;InnoDB: End of page dump
031205  7:15:02  InnoDB: Page checksum 1585856272, prior-to-4.0.14-form
checksum 2519793357
InnoDB: stored checksum 3556787397, prior-to-4.0.14-form stored
checksum 2519793357
InnoDB: Page lsn 6 4122692215, low 4 bytes of lsn at page end 4122692215
InnoDB: Page may be an update undo log page
InnoDB: Page may be an index page where index id is 0 47
InnoDB: and table enwiki/cur index cur_id
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1289395.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: Look also at section 6.1 of
InnoDB: http://www.innodb.com/ibman.html about
InnoDB: forcing recovery.
InnoDB: Ending processing because of a corrupt database page.

It tried to restart itself several times with the same error, then gave
up. A manual restart of mysql got it back on its feet, at least
mostly...?

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031204/899210cc/attachment.pgp>


subject: [WikiEN-l] User: TittoAssini

body:
Happy to help. I'm more familiar with Titto's and Assini's (which could
well mean donkeys but I dunno) than you, probably.
:)
Pedro
--
Pedro Fortuny Ayuso: http://pfortuny.sdf-eu.org
Colegio Mayor Pe?afiel, Universidad de Valladolid
C/ Estudios 6, 47005 Valladolid, Spain -->        www.cmpenafiel.org
pfortuny at sdf-eu.org                         Tfn. Nr. 34  983  298277


subject: [Wikitech-l] Crashy MySQL

body:
On Dec 4, 2003, at 23:55, Brion Vibber wrote:
> InnoDB: Database page corruption on disk or a failed
> InnoDB: file read of page 1289395.
> InnoDB: You may have to recover from a backup.

I'm still fighting with this. Docs recommend rebooting the machine to
try to see if the operating system's buffer caches are corrupted and
the file itself is fine; I haven't tried that (I don't even know for
sure if the machine will come back if I try it, and we have no way to
power cycle this machine remotely yet). I did try reading a huge
portion of the innodb data file through memory to see if it would clear
out the particular page, and this had no affect.

I tried the 'max' and 'standard' AMD64 binary builds of MySQL 4.0.16,
and then compiled it from source. Switching these has no affect.

The DB will croak spontaneously from time to time, and I can
consistently provoke it by running "check table cur" on enwiki.

I tried to see if I could pull together a fresh copy of everything by
rebuilding the databases from the binlog, but this doesn't seem to
include the statements to create databases...? or something? and I'm
not sure what exactly is required to make such a rebuild happen
cleanly.

However, every query that updated any data in the last three days _is_
in the binlog, so in the worst case it should be possible to rebuild
it...

I'm going to try to bang on this for a whille longer...

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031205/4883c4e2/attachment.pgp>


from_name: Lars Aronsson

body:
Evan Prodromou wrote:
> Anyways, I wanted to float a design idea for inclusion of metadata in
> MediaWiki articles. None of this is particularly new, and it seems
> like most has been suggested at one point or another.

While your definition of metadata is correct, and in full
correspondence with every other definition, you fail to mention that
there is also a "metadata movement" that has sprung up in the last ten
years, as a reaction against the Internet, primarily among librarians.
Today this movement is centered around Stu Weibel's "Dublin Core"
metadata initiative at the Online Computer Library Center (OCLC) in
Dublin, Ohio, http://www.dublincore.org/

The background was that librarians thought highly about themselves and
considered the freedom of the Internet as a dirty "chaos" and a threat
to their professionalism as information specialists.  The Internet
(i.e. the World Wide Web) was characterized as "the world's biggest
library with a drunken librarian after an earthquake", or something
like this.  In this community, hierarchical web indexes such as the
commercial Yahoo or the non-commercial Dmoz were welcomed, but
considered insufficient.  Full text search engines such as Altavista
and Google were considered as barbaric failures.  The library catalog
was the ideal, and "metadata" was the promised solution.  If they
could only teach all website creators to become librarians and "mark"
their web pages with "metadata" corresponding to what's found on a
library catalog card, order would form out of the previous chaos.

Ten years later, of course, we know that non-hierarchical solutions
such as Google and Wikipedia are the winners.  Data and metadata are
presented in-line, without separation.  This is what works, and what
people tend to use.  There are no useful global metadata search
engines, and website maintainers don't include structured (Dublin
Core) and honest metadata in their web pages.  On the contrary, the
"meta" HTML tag is most often used for dishonest "spamdexing".

In the wiki world, the article on Angola does not contain any
formalized, hierarchical metadata markup such as [[part of:Africa]]
or [[borders:Namibia]], but instead the plain English phrase "Angola
is a country in southwestern [[Africa]], bordering [[Namibia]]".
That's what wiki contributors can learn and be made to use.  It
doesn't require more complex parsing, it doesn't require any special
database tables, and it doesn't require hours of user training.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


from_name: Anthere

subject: [Wikipedia-l] double checking and case

body:
>If I overlooked anyone in my appointments, don't be insulted and don't
>hesitate to ask about it.  It was unintentional.  I tried to appoint
>everyone who volunteered.  Anyone who is left over and would still
>like to be appointed will be appointed to mediation.

Yes. I volunteered for mediation over conflict involving non-english speaking people, as I think my lack in english culture may help me understand the seeds of some conflicts :-)
(I thank those who understand that I do not understand everything, whatever my capacity to handle humour :-))

In particular should there be any issues with french users of course, such as "the one who must not be named" (because he requested to have his name and contributions disappear on all wikipedias, english included), or our famous chaterring box, Papotages (who is banned on fr, but not banned on en:) or perhaps JacquesD (who is perhaps a user ban on en:, but not on fr: )
:-)

-------

For information, I recently exchanged many private emails with a user called HeKeIsDa (and likely Sayeya as well), over posting little understandable articles on meta and fr: (and I saw recently on en: as well). The user was also trying to set up a new wikipedia on meta itself.

Though this was not a conflict really, it could have become one. If the user had insisted in going on setting his wikipedia on meta, he could have ended banned :-)
I am half seriously mentionning this, because a spanish person told me privately that if there was discussion over banning this user on meta, likely no spanish user would oppose the ban => that means he considered it an option. The user is a problematic user on the es: wikipedia. But no banned as spanish people wish to solve the issues they have with HeKeIsDa amicably. He is however, banned on the spanish encyclopedia fork.

HeKeIsDa and I do not share a common language (to say the least :-)), so that was a bit tough.
Actually, it is not even obvious he shares a language with spanish people.

I was embarassed because HeKeIsDa was only communicating through private emails, and I felt I should not take a decision alone on the topic. I felt I had no right to do so alone.
For this reason, I posted copies of some of his mails on meta so that other people could give me their opinion over those. I also found myself embarassed to do so, as these were private mails, but felt any decision over this should be public. I blanked the content for less visibility. I also talked about this to other people by private mail, on fr and on irc. Several people volunteered to bring very valuable information to help understand what it was all about, and some indicated their unfavorable opinion over the creation of the wild spanish wikipedia.
Practically, it was a sort of mediation commitee, where some users were providing input in a semi-public semi-private way (but not on meta itself, so these discussions were *invisible* to HeKeIsDa himself, while most discussions between HeKeIsDa and I were private as well).

However, no public opinion but mine was offered to him on meta itself.
Since no one made any comment, I boldly deleted HeKeIsDa articles
(Incidentally, I noticed that recently I am getting perhaps too bold in deletion on meta these days, if some people think I am being so, please do tell me).

I tried to explain HeKeIsDa the decision. Fortunately, he has stopped insisting, and limits himself to posting google-translated articles on fr: now (this will also have to be adressed...).

If HeKeIsDa had decided to go on in creating a wild spanish wikipedia on meta, I would have routinely deleted his articles (and talked to him again), in practice considering his posting vandalism, as he was told not to do it.
Though this would not have been a hard ban pronounced by Jimbo, it would have in effect sort of a ban that would have decided somehow on HeKeIsDa, for not respecting the goal of meta.

My point is : I feel like I did not do anything alone. I asked people opinion, and either they were neutral, or they were unfavorable to that new wikipedia.
But to HeKeIsDa or any external viewer, it certainly does look as if I took the decision myself alone. It does look as if I deleted his stuff on my own opinion. And if he post again articles, and I delete them again, it will look like I act as an arbitration commitee, and decided to out the guy myself.

Did I do well ? I think I did. In effect, I think I was honest and fair, and I do not think I offended the guy.

The important points I will keep from that case, are
: how will people feel if they find me routinely deleting articles with seemingly no discussion ?
: what will happen if someone feel like saying I abused my sysop powers in deleting unilaterally HeKeIsDa articles :-) ?
: how could I support my case given that a good deal of the discussion took place on volatile support (irc) ?
: do I have the right to make it appear that I took a decision myself, that was not mine to take as I am not representing community decision ?
: is that ok that I copied some private mails on meta, which is a breach in etiquette, in order to easily share the information with other people ?
: Should I delete that page ? Since that is a user page, on which the user has never written anything, may I do so ?
: How can we deal with similar matters on meta, which are likely to occur more and more often, given that there are a limited number of users for each language but english ?

To me, these questions are important; Is it to you ?

---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031205/11642233/attachment.htm


subject: [WikiEN-l] double checking and case

body:
Cross posting to wikipedia-l

In effect I messed my "To".

In practice, I do not think mediation and arbitration entirely limit themselves to english wikipedia;
they at least also relate to meta, which is shared by all wikipedia, though under the benevolent dictactorship on Jimbo.
They also relate to users who cross wikipedias.
A user problematic on one wikipedia, is generally problematic on the other wikipedias he contribute to as well. And conflicts sometimes jump language barriers.

That is why I expressed my interest for mediation. Not to mediate issues between english users, where I am unlikely to help.

>If I overlooked anyone in my appointments, don't be insulted and don't
>hesitate to ask about it.  It was unintentional.  I tried to appoint
>everyone who volunteered.  Anyone who is left over and would still
>like to be appointed will be appointed to mediation.

Yes. I volunteered for mediation over conflict involving non-english speaking people, as I think my lack in english culture may help me understand the seeds of some conflicts :-)
(I thank those who understand that I do not understand everything, whatever my capacity to handle humour :-))

In particular should there be any issues with french users of course, such as "the one who must not be named" (because he requested to have his name and contributions disappear on all wikipedias, english included), or our famous chaterring box, Papotages (who is banned on fr, but not banned on en:) or perhaps JacquesD (who is perhaps a user ban on en:, but not on fr: )
:-)

-------

For information, I recently exchanged many private emails with a user called HeKeIsDa (and likely Sayeya as well), over posting little understandable articles on meta and fr: (and I saw recently on en: as well). The user was also trying to set up a new wikipedia on meta itself.

Though this was not a conflict really, it could have become one. If the user had insisted in going on setting his wikipedia on meta, he could have ended banned :-)
I am half seriously mentionning this, because a spanish person told me privately that if there was discussion over banning this user on meta, likely no spanish user would oppose the ban => that means he considered it an option. The user is a problematic user on the es: wikipedia. But no banned as spanish people wish to solve the issues they have with HeKeIsDa amicably. He is however, banned on the spanish encyclopedia fork.

HeKeIsDa and I do not share a common language (to say the least :-)), so that was a bit tough.
Actually, it is not even obvious he shares a language with spanish people.

I was embarassed because HeKeIsDa was only communicating through private emails, and I felt I should not take a decision alone on the topic. I felt I had no right to do so alone.
For this reason, I posted copies of some of his mails on meta so that other people could give me their opinion over those. I also found myself embarassed to do so, as these were private mails, but felt any decision over this should be public. I blanked the content for less visibility. I also talked about this to other people by private mail, on fr and on irc. Several people volunteered to bring very valuable information to help understand what it was all about, and some indicated their unfavorable opinion over the creation of the wild spanish wikipedia.
Practically, it was a sort of mediation commitee, where some users were providing input in a semi-public semi-private way (but not on meta itself, so these discussions were *invisible* to HeKeIsDa himself, while most discussions between HeKeIsDa and I were private as well).

However, no public opinion but mine was offered to him on meta itself.
Since no one made any comment, I boldly deleted HeKeIsDa articles
(Incidentally, I noticed that recently I am getting perhaps too bold in deletion on meta these days, if some people think I am being so, please do tell me).

I tried to explain HeKeIsDa the decision. Fortunately, he has stopped insisting, and limits himself to posting google-translated articles on fr: now (this will also have to be adressed...).

If HeKeIsDa had decided to go on in creating a wild spanish wikipedia on meta, I would have routinely deleted his articles (and talked to him again), in practice considering his posting vandalism, as he was told not to do it.
Though this would not have been a hard ban pronounced by Jimbo, it would have in effect sort of a ban that would have decided somehow on HeKeIsDa, for not respecting the goal of meta.

My point is : I feel like I did not do anything alone. I asked people opinion, and either they were neutral, or they were unfavorable to that new wikipedia.
But to HeKeIsDa or any external viewer, it certainly does look as if I took the decision myself alone. It does look as if I deleted his stuff on my own opinion. And if he post again articles, and I delete them again, it will look like I act as an arbitration commitee, and decided to out the guy myself.

Did I do well ? I think I did. In effect, I think I was honest and fair, and I do not think I offended the guy.

The important points I will keep from that case, are
: how will people feel if they find me routinely deleting articles with seemingly no discussion ?
: what will happen if someone feel like saying I abused my sysop powers in deleting unilaterally HeKeIsDa articles :-) ?
: how could I support my case given that a good deal of the discussion took place on volatile support (irc) ?
: do I have the right to make it appear that I took a decision myself, that was not mine to take as I am not representing community decision ?
: is that ok that I copied some private mails on meta, which is a breach in etiquette, in order to easily share the information with other people ?
: Should I delete that page ? Since that is a user page, on which the user has never written anything, may I do so ?
: How can we deal with similar matters on meta, which are likely to occur more and more often, given that there are a limited number of users for each language but english ?

To me, these questions are important; Is it to you ?

---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20031205/0b0dfc44/attachment.htm


body:
Lars Aronsson lars-at-aronsson.se |wikipedia| wrote:

>Evan Prodromou wrote:
>
>
>>Anyways, I wanted to float a design idea for inclusion of metadata in
>>MediaWiki articles. None of this is particularly new, and it seems
>>like most has been suggested at one point or another.
>>
>>
>
>In the wiki world, the article on Angola does not contain any
>formalized, hierarchical metadata markup such as [[part of:Africa]]
>or [[borders:Namibia]], but instead the plain English phrase "Angola
>is a country in southwestern [[Africa]], bordering [[Namibia]]".
>
>
That is not very surprising, since meta tags are yet to be implemented.

>That's what wiki contributors can learn and be made to use.
>
Many articles contain complicated and advanced usages of HTML, and that
seem to work out fine.
Editors who don't know HTML simply leaves it for someone else to
maintain. Meta tags would be
much simpler to understand, probably not much harder than the interwiki
links. There is the risk of
scaring away newcomers if the first impression of wiki-text is too
frightening, but meta tags could
easily be hidden by default, if that is found to be a problem. (Or just
hidden at the bottom of the
article).

>It doesn't require more complex parsing, it doesn't require any special
>database tables, and it doesn't require hours of user training.
>
>
It also doesn't have the possibilites of metadata.

// E23


subject: [Wikitech-l] Crashy MySQL

body:
On Dec 5, 2003, at 02:21, Brion Vibber wrote:
> I'm going to try to bang on this for a whille longer...

The corrupted page -- at least the one that I was always seeing ref'd
in the log -- seems to have included only bits of enwiki.cur and
dewiki.old. I restarted the server with innodb_force_recovery=1 set so
it would skip over any corrupted rows, dumped both tables, then
restarted again and read them back in. So far, so good.

I'm checking alll the tables and taking wikis out of read-only lock as
they pass.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031205/2f577637/attachment.pgp>


from_name: The Cunctator

subject: Search engine. Was: [Wikitech-l] Fast

body:
> From: Magnus Manske
>
> Jimmy Wales wrote:
>
> >Brion Vibber wrote:
> >
> >
> >>So why are we talking about this? Google isn't going to vanish from
the
> >>web because we get the internal search back online.
> >>
> >>
> >
> >Obviously, Brion, you must have missed the last Cabal memo in the
next
> step
> >in world domination, bwah ha ha ha!  ;-)
> >
> >
> On cabal-l at wikipedia.org ? :-)
>
You mean cabal-tinc-l at wikipedia.org.


from_name: Jimmy Wales

subject: [Wikipedia-l] Arbitration/mediation on en

body:
(Note: intlwiki-l is supposed to be about issues relating specifically
to internationalization, but I know that some people on intlwiki-l may
not read wikipedia-l.  I've set the reply-to on this message to
wikipedia-l, because this is really a global policy issue that should
be discussed there, but I've included intlwiki-l, because I want to
reach those people as well.)

To the present day, we have been operating under a 'benevolent
dictator' model as regards governance issues generally, and in
particular issues relating to suspension of editing privileges for
those who can't seem to co-operate with others.

This has worked reasonably well (depending on who you ask, I guess) on
the English wikipedia, because I have spent a lot of time doing
investigations into controversial people, and have been willing to
"take the heat" for the few bans that we've had to implement.

But that model doesn't work nearly so well for other languages,
primarily because I'm not able to read the direct controversies, and
so I have to rely on testimony from people who are arguing, and what
actually ends up happening is that whoever is most fluent in English
ends up carrying the day by presenting their side of the dispute.

We have just begun a process on en of formalizing the decision
procedures for banning people, through the use of two committees of
volunteers.  The first "line of defense" is a mediation committee,
which attempts to work with parties to find a mutually agreeable
solution to a problem.  This committee has no power to ban or to do
anything other than act as an outside recommendation for a solution.

The second "line of defense" is the arbitration committee, which will
be tasked with the difficult and painful and regrettable task of
banning someone from editing.

This is mainly an experiment, and we shall see over time how it works
out.  I hope it works well.

I would like to encourage a similar setup on the larger non-English
wikipedias, perhaps customized to some extent to fit localized needs.
But the overall concept is to have in place clear methods for group
decision making that are respectful of our overall ideals.

On the English wikipedia, this was not necessary until now, but on the
other wikipedias I think that it is necessary sooner because there is
no real way for me to be an effective benevolent dictator.

So, let's discuss this.

--Jimbo


subject: [Wikipedia-l] non-English Wikipedias

body:
> From: Daniel Mayer Thursday, December 04, 2003 10:50 PM
> Tomasz Wegrzanowski wrote:
> >But the English Wikipedia isn't NPOV at all !
> >Especially on anything related to Middle East
> >conflict, it almost invariantly has Israeli bias,
> >probably because of relatively large number
> >of American Jewish contributors, compared to
> >hardly any Arab contributors.
>
> This is more of a side-effect of the fact that our continued
overwhelming
> reliance only on informal methods of conflict resolution results in
the
> selection of POV by people who are very motivated about certain
subjects
> and
> the selecting out or marginalizing of the POV of people who are less
> motivated.
>
> We could handle that when we were small (everybody could help with the
> handful of slow-moving disputes we used to have), but it is much more
> difficult to do
> this now that we are large (there seems to be dozens of disputes at
any
> moment now and people are generally less civil and more quick to
revert
> than they were when all the heavy users knew each other).

Hmm. I don't really see Wikipedia being less civil/more quick to revert
than it was in the past. I'd say it's still pretty much the same, where
99% of what happens is uninterestingly fine. Since there's more
participation, that 1% is larger in an absolute sense, but not in a
relative sense.

For example, even though deletion and merging has gotten out of hand,
those problems are only affecting a small portion of the entire
Wikipedia.

> Thus we need to set-up mediation and arbitration procedures to deal
with
> the caseload.

That's one opinion, not a necessary conclusion. There are other, and
better tactics.


body:
> From: Daniel Mayer Thursday, December 04, 2003 10:29 PM
>
> tc wrote:
> >They're obviously skeptical of doing so, but as statistically
> >the only website to use the GFDL, our opinions and needs
> >have validity.
>
> No - we aren't the only website to use the GFDL, but we are almost
> certainly
> the largest content-creating website to use that license.
>
> Perhaps that is what you meant?
>
I didn't say we are the only website to use the GFDL, I said
*statistically* the only website.

It's essentially a math-joke way of saying what you said in your reply.

E.g. if you step on and kill a hundred ants, you've killed statistically
zero ants, from the perspective of the ant colony.

--tc


body:
> From: Magnus Manske Friday, December 05, 2003 4:23 AM
> Well, the code *I* wrote (which I assume is what you're talking about)
> is finished, in the sense of "it works, but it ain't too pretty".
>
<snip>

> You'll have to enable categories in LocalSettings, but I forgot how
:-(

Please, please do not turn on this feature. Human-inserted metadata is
basically unwiki. There are better approaches to dealing with the
problem of categorization/computer comprehension of data. The right
approaches act like magic.

Moreover, this isn't really (only) a discussion for wikitech-l.


body:
The Cunctator wrote:
> If it is to be an experiment, we should try to figure out beforehand
> what our metric of success is. Total success would be if neither
> committee ever needs to act. But the gradations in between are more
> complicated.

I think it's unrealistic to expect that the mediation committee would
never need to act.  Many times people do have real disputes, and if
they'll agree to mediation, and that resolves the dispute by just
getting the two parties to agree, then all the better.

I don't think it's unrealistic to expect that the arbitration
committee should have to act only rarely.

> For example, which is better: if a high or low percentage of cases
> reviewed by the arbitration committee end in sanction or banning?

Oh, I hope a very low percentage.  I'm hopeful that a good system for
mediation will reduce the number of cases where problems get to the
point that banning is necessary.  It's long been said, and I agree to
some extent, that Wikipedia tends to turn our problem users into
monsters.

> Which is better: if the arbitration committee agrees or disagrees with
> the mediators' actions?

Hmmm, I'm not really sure about that.  I suppose it's better if both
committees behave in a kind, loving, friendly, benevolent, and
rational manner, so that disagreements are rare, and that if
disagreements do happen, they happen under circumstances where
everyone agrees that the issue was complex and that both positions had
some merit.

> I think using bulletin boards for this is good, because I think it will
> be very important to establish a reviewable case history.

Unless someone objects strongly, I think that this is a very good
idea.

> The nearly immutable law of government is that while over the short term
> dangers to the health of society come from individual actors, over the
> long term the dangers come from the system.

I absolutely agree with this one.

> A good real world example of that is drugs; because it is a criminal act
> to use illegal drugs, millions of dollars and manhours and lives are
> spent in combatting drug use (the "war on drugs"). But if the drugs
> (such as marijuana) are decriminalized, a host of downstream costs to
> society disappear. There *are* different complications and needs
> (tobacco is a good example of the potential problems of having drugs be
> legal to use) but it's a lot easier to deal with drugs as a health issue
> than a crime issue.

Well, you're obviously using the right language to speak to me, a very
hardcore "libertarian" politically.  :-)

--Jimbo


subject: [WikiEN-l] New policy on edit conficts (Re:Martin)

body:
A [name omitted for privacy reasons] wrote:
> *By the powers vested in me by the Wikipedia power structure, I
> *hereby declare those changes to be de facto official, subject of
> *course to overruling by other sysops *Is this implying that sysops
> *have special powers in regards to the formulation of policy, I
> *thought they were no better than the rest of us...

Adam is right of course.  I don't know who he is quoting, and maybe
that was only a joke, but sysop is always and everywhere supposed to
be a purely technical matter, not a position of authority and power of
any kind.

I think maybe I need to say that a lot more often, eh?

And maybe we need to focus on what technical changes could be made to reduce
the differences between sysops and ordinary signed-in-users.

--Jimbo


body:
E23 wrote:
> That is not very surprising, since meta tags are yet to be implemented.

Not only are they "not yet" implemented in MediaWiki, but they are not
implemented in any wiki software anywhere, as far as I know.  And this
is not because the problem hasn't been considered, but because those
who have considered the problem have chosen to leave out this feature.

> Many articles contain complicated and advanced usages of HTML, and that
> seem to work out fine.

I don't think anybody is happy with the need for HTML markup in wiki
pages.

> It also doesn't have the possibilites of metadata.

You can of course implement this in the wiki parser and store the
harvested metadata in a database table.  But how will that database
table be used?  Will it be useful enough to motivate users to input
the necessary metadata in Wikipedia pages?  Go ahead and show me. I'll
believe it when I see it.  The measure of your success is the number
of Wikipedia pages that contain such metadata.  Today it is zero.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


body:
Evan Prodromou wrote:
>      * Providing metadata makes our data more useful to downstream
>        users. For example, consider if someone wanted to take
>        Wikipedia's prodigious collection of information about science
>        fiction and fantasy and produce an encyclopedia out of
>        it. Metadata could help them do it.

You have to provide some incentive for the editor of an article to
input the metadata.  This is where Dublin Core utterly fails to
attract followers among website maintainers.  How are you going to
succeed in attracting wikipedia article editors?

If I edit [[Jules Verne]] and input [[fr:Jules Verne]] I get the
instant reward of a working link to the French article about the same
person, which is sufficient motivation for my adding this markup.

But what immediate reward do I get for inputing something like
[[genre:science fiction]]?  If all I get is a link to the page
[[science fiction]], then I already got that from mentioning in plain
text that "Jules Verne was an early writer of [[science fiction]]".
So what extra benefit is entering the metadata going to give me?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


subject: [Wikipedia-l] The Defendent

body:
G'day Ray, Delirium, and Fred

At 02:03 AM 2/12/03 -0800, Ray Saintonge wrote:

>Delirium wrote:
>
>>Fred Bauder wrote:
>>
>>>I think Flexicon is the logical defendent with Wikipedia as a the plaintiff
>>>should we chose to not accept repeated violations of our copyright, if
>>>contact with them requesting compliance proves unproductive. Ulrich Fuchs is
>>>right to point this out but throwing in the "five author" question is not
>>>productive as we do want people, including commercial sites, to reuse our
>>>material without onerous requirements.
>>>
>>
>>I'm not sure how Wikipedia could be the plaintiff, as it doesn't hold
>>copyright to the material.  The material I've submitted to Wikipedia, for
>>example, is copyrighted by me.  I have licensed it under the GFDL, so
>>Wikipedia, as well as anyone else willing to abide by the terms of the
>>GFDL, is free to use my text.  But they have no more rights to it than
>>any other random person or entity does.
>
>So if Wikipedia can't be plaintiff, and you as an individual author are
>not willing to be plaintiff, then GFDL is no more than a paper tiger since
>violators may copy things with impunity.

That's not the purpose of the GFDL and copyleft in general. Its purpose is
*not* to *stop* people using the content outside the GFDL, in any way. It
leaves the way open for the copyright owners to control this themselves if
they wish, but no more.

What the GFDL *does* seek to do is to guarantee that everyone *can* use the
material, provided their usage stays within the GFDL. So, if one of these
violators was to attempt to attempt to prevent Wikipedia or any other user
from using this material within the GFDL, hopefully this attempt would be
laughed out of court. Those are the teeth the GFDL seeks to have.

So are the cases cited violations of the GFDL at all? Probably not, IANAL.
They seem to be violations of copyright, not copyleft. That is, these sites
aren't using the material under the GFDL, true, but they don't claim to be.
If they claim to be using is "courtesy of Wikipedia" but are outside the
GFDL, probably we could make them take that notice off, as Wikipedia hasn't
given any such permission and probably doesn't have any right to give it
anyway. But we can't make them stop using the material, or to put on a GFDL
notice or any other notice, as Wikimedia doesn't own the copyright.

Even if they are copyright violations I suspect it would be very hard for
anyone to prosecute such violations with regard to anything done on a Wiki.
There's both the practical problem of getting the plaintifs together and
the theoretical one of what permission is implicit whenever you participate
in a Wiki. Mind you, US law is 'way ahead of Australian law in class
actions and the like, and so there may even be a way around the practical
problems.

Is that any clearer? IANAL as I said.

Andrew A

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031205/dc9214f5/attachment.htm
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03


from_name: Fred Bauder

subject: [Wikipedia-l] Comments on Cunctator's Points

body:
> From: "The Cunctator" <cunctator at kband.com>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Fri, 5 Dec 2003 08:06:24 -0500
> To: <wikipedia-l at wikipedia.org>, <wikipedia-l at Wikimedia.org>
> Subject: RE: [Wikipedia-l] Arbitration/mediation on en
>
>> From: Jimmy Wales Friday, December 05, 2003 7:26 AM
> <snip>
>> We have just begun a process on en of formalizing the decision
>> procedures for banning people, through the use of two committees of
>> volunteers.  The first "line of defense" is a mediation committee,
>> which attempts to work with parties to find a mutually agreeable
>> solution to a problem.  This committee has no power to ban or to do
>> anything other than act as an outside recommendation for a solution.
>>
>> The second "line of defense" is the arbitration committee, which will
>> be tasked with the difficult and painful and regrettable task of
>> banning someone from editing.
>>
>> This is mainly an experiment, and we shall see over time how it works
>> out.  I hope it works well.
>
> If it is to be an experiment, we should try to figure out beforehand
> what our metric of success is. Total success would be if neither
> committee ever needs to act. But the gradations in between are more
> complicated.
>
> For example, which is better: if a high or low percentage of cases
> reviewed by the arbitration committee end in sanction or banning?

This must depend on the facts of the cases we get and the response of users
to our decisions.
>
> Which is better: if the arbitration committee agrees or disagrees with
> the mediators' actions?

We will know that mediation failed, but a useful legal convention, that we
would probably wish to use, is that the details of negotiations and of what
goes on in mediation are inadmissible as evidence in later proceedings. This
frees up the parties to make concessions during negotiations and mediation
without ruining their "case" for arbitration purposes.
>
> That second relates to an important point: if a case is presented to the
> arbitration committee, what is being judged is not just the actions of
> the user(s) that resulted in mediation, but the entire process that led
> to arbitration, including what the mediators did.

We don't want to use this information because it makes mediation less
effective. While the arbitration committee might from time to time comment
on the total process and how it might have affected a particular case
decisions regarding wikipedia process must remain here on the mailing lists
and other discussion and decision making forums and Jimbo.
>
> I think using bulletin boards for this is good, because I think it will
> be very important to establish a reviewable case history.

To review Jimbo needs to know what facts were considered and the basis for
any decision.
>
> The nearly immutable law of government is that while over the short term
> dangers to the health of society come from individual actors, over the
> long term the dangers come from the system.
>
> It should be everyone's goal to figure out ways to eliminate potential
> problems before they can happen.

Before anyone can complain that someone has violated a policy that policy
must both be set forth and make sense. Policies need to serve in some way
the goals of delivering information and providing ways to add and refine
information. However the arbitration committee is not a court of review of
Wikipedia policies. We must work with existing policies. Breakdowns can
occur if we can't understand them or how someone could comply with them, and
perhaps in some cases we may be unable to render a decision, or at least a
good decision.
>
> A good real world example of that is drugs; because it is a criminal act
> to use illegal drugs, millions of dollars and manhours and lives are
> spent in combatting drug use (the "war on drugs"). But if the drugs
> (such as marijuana) are decriminalized, a host of downstream costs to
> society disappear. There *are* different complications and needs
> (tobacco is a good example of the potential problems of having drugs be
> legal to use) but it's a lot easier to deal with drugs as a health issue
> than a crime issue.

Well substitute persistant insistence on making articles reflect some
particular point of view (including repeated reversions of any other point
of view) and we have what kind of an issue? (although perhaps this is not
actually our most important problem--experience will tell much)
>
> Yours,
> --tc

Fred


body:
> From: Jimmy Wales Friday, December 05, 2003 7:26 AM
<snip>
> We have just begun a process on en of formalizing the decision
> procedures for banning people, through the use of two committees of
> volunteers.  The first "line of defense" is a mediation committee,
> which attempts to work with parties to find a mutually agreeable
> solution to a problem.  This committee has no power to ban or to do
> anything other than act as an outside recommendation for a solution.
>
> The second "line of defense" is the arbitration committee, which will
> be tasked with the difficult and painful and regrettable task of
> banning someone from editing.
>
> This is mainly an experiment, and we shall see over time how it works
> out.  I hope it works well.

If it is to be an experiment, we should try to figure out beforehand
what our metric of success is. Total success would be if neither
committee ever needs to act. But the gradations in between are more
complicated.

For example, which is better: if a high or low percentage of cases
reviewed by the arbitration committee end in sanction or banning?

Which is better: if the arbitration committee agrees or disagrees with
the mediators' actions?

That second relates to an important point: if a case is presented to the
arbitration committee, what is being judged is not just the actions of
the user(s) that resulted in mediation, but the entire process that led
to arbitration, including what the mediators did.

I think using bulletin boards for this is good, because I think it will
be very important to establish a reviewable case history.

The nearly immutable law of government is that while over the short term
dangers to the health of society come from individual actors, over the
long term the dangers come from the system.

It should be everyone's goal to figure out ways to eliminate potential
problems before they can happen.

A good real world example of that is drugs; because it is a criminal act
to use illegal drugs, millions of dollars and manhours and lives are
spent in combatting drug use (the "war on drugs"). But if the drugs
(such as marijuana) are decriminalized, a host of downstream costs to
society disappear. There *are* different complications and needs
(tobacco is a good example of the potential problems of having drugs be
legal to use) but it's a lot easier to deal with drugs as a health issue
than a crime issue.

Yours,
--tc


subject: [Wikitech-l] Search engine.

body:
Daniel-
> Giving people the option of live database search and Googlesearch should
> reduce database server load as well (I always felt guilty using the
> Wikipedia search before

A properly implemented search should not make anyone feel guilty. If the
search doesn't scale, we can't re-enable it, big ass server or not. In the
current implementation, the search causes massive locking problems with
high concurrent access, probably due to some unresolved deadlock. But the
search index itself is fast - in the range of milliseconds. So once we
resolve the locking issue, the additional load caused by the search should
be negligible.

As for Google, I'm all for it if it doesn't overload the user interface.
It would be nice to have an "Advanced Search" link anyway so that you
don't have to run a normal search to get to the advanced search form. That
advanced form could include the Google search box. But Google is not and
cannot be a replacement for realtime searching.

Regards,

Erik


from_name: Magnus Manske

subject: Search engine. Was: [Wikitech-l] Fast

body:
Jimmy Wales wrote:

>Brion Vibber wrote:
>
>
>>So why are we talking about this? Google isn't going to vanish from the
>>web because we get the internal search back online.
>>
>>
>
>Obviously, Brion, you must have missed the last Cabal memo in the next step
>in world domination, bwah ha ha ha!  ;-)
>
>
On cabal-l at wikipedia.org ? :-)

Magnus


from_name: Sheldon Rampton

subject: [WikiEN-l] Re: User: TittoAssini

body:
Ed Poor wrote:

>I forget our policy on offensive usernames.
>
>Is "TittoAssini" perfectly okay, or obviously NOT okay, or what?

It's a good thing, I guess, that George Bush and Philip K. Dick
aren't Wikipedians. ;-)
--
--------------------------------
|  Sheldon Rampton
|  Editor, PR Watch (www.prwatch.org)
|  Author of books including:
|     Friends In Deed: The Story of US-Nicaragua Sister Cities
|     Toxic Sludge Is Good For You
|     Mad Cow USA
|     Trust Us, We're Experts
|     Weapons of Mass Deception
--------------------------------


from_name: Ray Saintonge

body:
Magnus Manske wrote:

> The Cunctator wrote:
>
>> Please, please do not turn on this feature. Human-inserted metadata is
>> basically unwiki. There are better approaches to dealing with the
>> problem of categorization/computer comprehension of data. The right
>> approaches act like magic.
>
> Would be great to have one of those. But, AFAIK, there's no way to
> implement a category scheme purely by code. That mean, there *has* to
> be some interface for humans changing categories around. That can be
> either some "Add/remove/change category" construct on every page;
> ugly, and a bitch to write, as one would have to re-implement "old
> version", delete/undelete, and the like *for the category system
> alone*. OTOH, we can use the way of language links; while I'd prefer a
> centralized language link facility (one for all wikipedias), it could
> work better for the category scheme, as that information stays within
> that 'pedia.
>
> And since when is editing an article unwiki? :-)
>
>> Moreover, this isn't really (only) a discussion for wikitech-l.
>
> The original question was a technical one, IIRC. I also vaguely
> remember support for that category scheme when I had it running at the
> test site.
>
> But if we need Yet Another Discussion (TM) on wikipoedia-l about the
> nature of the category system (I *know* we kinda decided to use one!),
> so be it.

I agree that there seemed to be much support fro some kind of category
scheme.  It's hard to see it as anything other than human inserted;  the
alternative of leaving it to some bot horrifies me.  I still think that
some kind of category box that would leave room for any number of
categories would be superior; these could have a comma or other
appropriate delimiter.  It seems more user friendly if the user does not
have to learn more mark-up and can simply type in the category that he
wants.

If we're speaking of something being more wiki we should not prejudge
what the categories themselves would be, but let them evolve naturally.
 Some types of categories may be obvious, but we have a lot of
imaginative participants out there in Wikiland.  Some will be just plain
strange, but they are worth trying.  If they are not used by others they
can be removed at a much later time.

A categorization scheme could be especially welcome at Wiktionary where
there has been a trend to give a long list of translations for any given
word.  A number of cross indexes have been devised which in principle
would be useful if anybody bothered to keep them up to date.  It is not
enough to give the Finnish or Guaran? word for "dog"; the cross-indexes
for those languages need to be adjusted as well.  That's what hasn't
happened.  I'm also looking at what might evolve at Wikisource, and
perhaps Wikibooks.

Ec


subject: [Wikitech-l] Re: I never metadata I didn't like

body:
> From: Ashar Voultoiz Friday, December 05, 2003 8:45 AM
>
> On Fri, 5 Dec 2003 06:15:22 +0100 (CET), Lars Aronsson wrote:
> >> Many articles contain complicated and advanced usages of HTML, and
that
> >> seem to work out fine.
> >
> > I don't think anybody is happy with the need for HTML markup in wiki
> > pages.
>
> Hello,
>
> I personally like being able to code html in wikipedia articles.
That's
> the
> frist descriptive langage I learned.  I don't see why we should
relearn a
> new langage (wiki) when there is already one working well.
>
> I mean  to bold a text is not THAT difficult to learn :)
>
The reason is that wiki markup is designed to be more comfortably
human-readable than is HTML markup.

== Big heading ==
[[Link]] has ''many'' ways of going:
# One,
# Two,
# Three.

How about that!

is much terser and easier to parse than

Big heading

Link has many ways of going:

One,

Two,

Three.

How about that!

And we operate on the general assumption that the majority of people are
familiar with neither.


body:
Evan Prodromou wrote:

>>>>>>"SS" == Stan Shebs <shebs at apple.com> writes:
>>>>>>
>>>>>>
>
>    SS> All seems very reasonable; the tags will be invaluable in
>    SS> maintaining indexes like [[list of people]], which is missing
>    SS> thousands of bios that are scattered all over WP now. I
>    SS> thought Magnus or somebody had implemented it already?
>
>There is some code to do categorization, which appears to be mostly
>commented-out. It finds all the links in a page that start with a
>language-specific prefix -- most of the languages, including English,
>don't have the prefix defined -- and collects them into something
>called "category links". It doesn't do anything with them, though.
>
>There's also a special page for listing categories.
>
>I think this was code that got started and never got finished.
>
>
Well, the code *I* wrote (which I assume is what you're talking about)
is finished, in the sense of "it works, but it ain't too pretty".

Example: "[[Category:Stuff]]" somewhere in the article will show a link
above (similar to language links), leading to the category page
("Category:Stuff"). That will automagically list all pages in that
category (meaning, that link there via category link). A category page
can be edited like a normal page (the article list is automatically
shown below), and can include "super-categories" (e.g.,
"[[Category:Biology]]" on "Category:Zoology"). Any page can, of course,
have many categories.

You'll have to enable categories in LocalSettings, but I forgot how :-(

Magnus


from_name: Toby Bartels

body:
E23 wrote:

>Many articles contain complicated and advanced usages of HTML, and that
>seem to work out fine.

I don't think that it works out fine!
Most of this is for tables and image display,
which is why people work on simplifying wiki editing of these.

>Editors who don't know HTML simply leaves it for someone else to
>maintain.

And that's whats not fine about it -- most editors ignore it.

This is not too relevant to the discussion /so long as/
we agree that any new metadata markup must be simple.
Magnus' [[Category:foo]] markup is simple like that.

>(Or just hidden at the bottom of the article).

I'm already one of the people that places interwiki links at the bottom.

-- Toby


subject: [Wikitech-l] Search engine.

body:
Daniel Mayer wrote:

>So I guess I'm advocating for a "Search {ProjectName} from
>Google" radio button right under the MediaWiki search form. The default of
>the toggle would be to use MediaWiki's own search functionality so long as
>the database server isn't bogged down.

This seems obviously correct to me.
/Given/ that some people want to use Google, that is
(I would prefer the in-house search in almost all cases myself).

-- Toby


subject: [Wikipedia-l] RE: [Wikitech-l] I never metadata I didn't like

body:
> From: Magnus Manske
>
> The Cunctator wrote:
>
> >Please, please do not turn on this feature. Human-inserted metadata
is
> >basically unwiki. There are better approaches to dealing with the
> >problem of categorization/computer comprehension of data. The right
> >approaches act like magic.
> >
> Would be great to have one of those. But, AFAIK, there's no way to
> implement a category scheme purely by code. That mean, there *has* to
be
> some interface for humans changing categories around.

I didn't say we should implement a category scheme purely by code. I can
think of several better methods to providing the utility of categories
than inserting hidden metadata tags.

I should have more time in the coming weeks to make some explicit
suggestions--that is, mock up examples, etc.

I think that having a categorization project (a la dmoz for Wikipedia)
would be a fine idea, as long as the work, and the data, are separate
from the root Wikipedia.

In fact, the best thing would be to work on developing ways for outside
projects to hook easily into the Wikipedia content without having to be
a Bomis-hosted project, prolly by having an XML hook.

If we did so, I could imagine a group at the MIT Media Lab or the Cyc
project figuring out some bad-ass way of navigating Wikipedia content,
etc.

> And since when is editing an article unwiki? :-)

Adding hidden content is unwiki.

What I'd like to see is an explicit wiki-statement of what is the
desired functionality--that is, what is the utility missing--that a
category scheme would provide.

Then we can discuss particular implementations separately--for example,
is it better to use a system which has a single ontology or a system
which allows for dynamic ontologies?


body:
The Cunctator wrote:

>The reason is that wiki markup is designed to be more comfortably
>human-readable than is HTML markup.

>== Big heading ==
>[[Link]] has ''many'' ways of going:
># One,
># Two,
># Three.

>How about that!

>is much terser and easier to parse than

>
Big heading

>Link has many ways of going:
>

>
One,
>
Two,
>
Three.
>

>

>How about that!
>

>And we operate on the general assumption that the majority of people are
>familiar with neither.

Also, our own wiki markup gives us a better chance of producing
the /correct/ HTML -- which in this case is , not  at all.
^_^

-- Toby


body:
Evan Prodromou wrote:

[about Magnus' category scheme]

>So, I think that this is a nice piece of work. Since it's not in use
>in production -- couldn't be, with all that commented-out stuff -- how
>would you feel about me generalizing it to just another kind of
>metadata? That is, instead of trying to find [[Category:Foo]], use
>[[metadata:category:foo]] instead?

I think that you should work out the integration of Magnus' own scheme
with the present code, recreating what we had on [[test:]] back then.
The reason is that this [[test:]] appearance had a great deal of support;
there were just a few kinks to work out when people lost interest
(because there were /other/ things to test at the same time).
With fresh blood (you), we can get it straightened out this time,
get it running on a big wiki (like [[en:]]) and working for real;
then we'll all be in a good position to say ?What's still missing??
and decide if we want more extended metadata.

-- Toby


subject: [WikiEN-l] User: TittoAssini

body:
Ed Poor wrote in part:

>Is "TittoAssini" perfectly okay, or obviously NOT okay, or what?

Perfectly okay until such time as somebody is /actually/ offended
(and then it can come for discussion).

Potential offence does not count.

-- Toby


subject: [Wikitech-l] RE: Search engine (reply to Carl).

body:
G'day Carl and the Group

At 10:06 AM 4/12/03 -0800, Carl Witty wrote:

>On Thu, 2003-12-04 at 01:47, Andrew Alder wrote:
> > G'day Peter and the Group
> >
> > At 07:39 AM 4/12/03 +0000, Peter Bartlett wrote:
> >
> > >  >. The not being realtime may be a plus or minus, this is the very
> > > thing we tossed around a little in the Pump.
> > >  >Certainly for Wikipedia contributors, realtime is best. But
> > > perhaps not so for readers, who are after stable content.
> > >
> > >
> > >         As was pointed out on the pump, there is no reason to
> > >         suppose that the pedia was any more "stable" when Google
> > >         took its snapshot than it is at any other time..
> >
> >
> > True. No argument at all with this.
> >
> > But the probability that Google indexes a particular version is
> > roughly proportional to the time for which that version is the current
> > version. Therefore, the version presented by Google is on average more
> > stable than the "current" version. I tried to point this out, but I'm
> > afraid I didn't do it very clearly.
>
>No, it's not; it's exactly the same.  Consider (for ease of exposition)
>an article in the middle of an edit war.  Three-quarters of the time it
>has version "A" (the "stable" version); one-quarter of the time it has
>version "B" (the "unstable" version).  Then, three-quarters of the time,
>when the Google spider grabs and indexes this article, it will get
>version "A".  Three-quarters of the time, if somebody did a full-text
>search on the "current" wikipedia database, they would get version "A".
>Exactly the same.
>
>There's also the effect that Brion mentioned: even if Google happened to
>index a "stable" version when the current version was "unstable", the
>person would (by default) still end up reading the current, unstable
>version.

I think you're right. I said my Math Stats were 20 years ago!

But, if you are right, it means that there's neither an advantage nor a
disadvantage in the delay Google gives.

Andrew A

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031205/590eab5a/attachment.html>
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03


subject: [Wikitech-l] Re: Search engine (reply to Magnus).

body:
G'day Magnus, Brion and the Group

At 02:26 PM 4/12/03 +0100, Magnus Manske wrote:

>Brion Vibber wrote:
>
>>On Dec 4, 2003, at 01:47, Andrew Alder wrote:
>>
>>>But the probability that Google indexes a particular version is roughly
>>>proportional to the time for which that version is the current version.
>>>Therefore, the version presented by Google is on average more stable
>>>than the "current" version. I tried to point this out, but I'm afraid I
>>>didn't do it very clearly.
>>
>>
>>When somebody clicks the link in the Google search results they see the
>>*current* version, not Google's crawl-time cached copy (unless they
>>happen to know what the Google cache is, how to use it, and prefer to do
>>so instead of clicking through to the page itself, which is sure to be a
>>vanishingly small proportion of visitors). The key words in the search
>>are likely to be in the title itself or general description, and will
>>probably be fairly stable across revisions.
>>
>>Google is how people get _to_ Wikipedia and does a good job at it; as an
>>internal navigation mechanism it's wholly unsatisfactory for contributors
>>who need to be able to check the current state of things in detail.
>Why not offer all:
>Search box - search button - radio button "Go" (preselected) - radio
>button "fulltext" - radio button "Google"

That's a very good suggestion IMO.

Andrew A

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031205/9d83cf67/attachment.html>
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03


subject: Search engine. Was: [Wikitech-l] Fast

body:
G'day Brion and the Group

Hmmm...

At 02:10 AM 4/12/03 -0800, Brion Vibber wrote:

>On Dec 4, 2003, at 01:47, Andrew Alder wrote:
>>But the probability that Google indexes a particular version is roughly
>>proportional to the time for which that version is the current version.
>>Therefore, the version presented by Google is on average more stable than
>>the "current" version. I tried to point this out, but I'm afraid I didn't
>>do it very clearly.
>
>When somebody clicks the link in the Google search results they see the
>*current* version, not Google's crawl-time cached copy (unless they happen
>to know what the Google cache is, how to use it, and prefer to do so
>instead of clicking through to the page itself, which is sure to be a
>vanishingly small proportion of visitors). The key words in the search are
>likely to be in the title itself or general description, and will probably
>be fairly stable across revisions.

No argument at all with any of this. Again, perhaps I haven't expressed
myself very well.

Assuming also that our meta data or whatever their bots follow keeps the
spider out of the history (a good assumption I hope), the link from the
Google search results will point to the current version, regardless of
which version was retrieved by the crawler. The only difference is in the
searching that produces the result list. So, as far as which version is
presented (=targeted) by the *link* is concerned, Google is realtime.

But surely this supports the idea that, for a *reader*, Google is *no
worse* than an in-house search?

>Google is how people get _to_ Wikipedia and does a good job at it; as an
>internal navigation mechanism it's wholly unsatisfactory for contributors
>who need to be able to check the current state of things in detail.

Again, agree. I've now been through this both on the list and on the Pump.
My comments relate to *readers*, not *contributors*.

Contributors certainly need fully realtime tools, which means in-house. I
said that before.

Andrew A

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031205/5788233e/attachment.html>
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03


subject: [Wikitech-l] Re: Wikitech-l google

body:
G'day Anthere, Brion and the Group

At 11:42 AM 4/12/03 -0800, Anthere wrote:

> > Google is how people get _to_ Wikipedia and does a
> > good job at it; as
> > an internal navigation mechanism it's wholly
> > unsatisfactory for
> > contributors who need to be able to check the
> > current state of things
> > in detail.
>
>secunded wholeheartedly
>sometimes it takes many days for google to index a
>page. If you look for it, and do not exactly remember
>the title, you are doomed.

I agree with Brion's statement.

But my experience with Google has been that it's very good for finding old
pages. It's especially good at finding mispelled ones. For finding new
ones, "many days" is generous... several weeks is my experience.

Andrew A

****
andrewa @ alder . ws
http://www.zeta.org.au/~andrewa
Phone 9441 4476
Mobile 04 2525 4476
****

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031205/823c0718/attachment.html>
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/03