body:
On Thu, 3 Jan 2002, Magnus Manske wrote:

> Larry, I was just working my way through a "feature request" list I
> keep for myself, and "categories" was one of them. So, I'm sure it was
> in discussion somewhere. The only mention of it I can find right now
> is at
>
> http://wikipedia.com/wiki/Feature_requests/Really_ambitious_and_fanciful_fea
> ture_requests
>
> where you already "answered" that request, as I see now.

OK.  :-)

> Anyway, the
> feature isn't meant to *reduce* anything - it is just for making
> certain things easier.

Of course!

> As I said, it is only implemented as a
> "minimal" version right now.

That's interesting--I'm wondering what the full version would do!

> There's no pressure to use it.

Right, but there was no pressure to use subpages either; it was just a
feature that happened to be included in the wiki software that we happened
to adopt, and people thought it was nifty and started using it anyway.

> Yes, it
> has some drive into the "old-fashioned" categories. But, even in the
> "web structure" of wikipedia, noone would put a "DNA" article under
> "fiddle traditions"...

Of course not; that's not what I'm concerned about.  I'm mainly concerned
about adding unnecessary complications, and imposing useless category
schemes--when the content *is* the category scheme--when the information
in articles (if well done) provides its own structure in as detailed and
precise a way as one could possibly hope for.

> I just thought it would make things easier, so *later*, you could
> restrict your "Recent Changes" to display only articles * without any
> category information (=not categorized at all) and * those with
> Biology as a category There's no point in choosing a category at every
> edit, right?

Well, in fact, there is.  Rather than categorizing articles--which, I
think, opens up a huge can of worms that is best left in the depths of the
pantry--we categorize edits.  The *edit* category information for each
article is saved with each article, and can be changed by each user (a
philosophical addition to [[God]] is filed under the philosophy category,
whereas one that gives details about the Muslim conception of God wouldn't
be).  And that info is used *just* to solve one clear problem, viz., that
edits in all sorts of different fields are jumbled together in the present
Recent Changes page.  (Some people would like that, and they could just
choose to view all edits.  I'd probably view things that way myself, but
I'd like the option of just looking at the philosophy edits too.)

> Also, this could be a way to use categories for the "approval"
> mechanism we didn't decide on yet...

I'm not sure I understand...?

Anyway, I thought I made it pretty clear that you've got a dilemma, and
I'm curious what you think about it.  On the one hand, you might want the
categories to proliferate freely.  Then you've just recreated subpages
with all their problems.  On the other hand, you might want the categories
to be of a limited set.  In that case, we should have a drop-down box that
lists the categories we (somehow) decide on (to prevent misspelling and
the proliferation of new categories).  Also in that case, it's still just
not clear what the *purpose* of the feature is.  So far, I can see only
*one* purpose that is important enough to warrant all the trouble, namely,
categorizing edits (or articles) for purposes of the overgrown [[Recent
Changes]] page.  If that's the purpose of the feature, the feature, in my
opinion, should probably be redesigned so as to include a drop-down box
rather than in-the-text data; the data in any case should probably be used
just for [[Recent Changes]] categorization, not to inform readers of what
category an article belongs to.

If designed with enough flexibility, then, *if* we found some clear
advantage or use for categorizing articles (i.e., if we spelled out what
article categorization would be used for, such that that would be a clear
advantage over the presents system), we could use the same data to
categorize articles.

> As for the categories, I suggest we use all "HomePage" categories,
> and, additionally, more specific ones, like "Biochemistry".

Well, I don't know.  That would be something that is up to all of us to
opine about and hash out.  It depends, again, entirely on what the purpose
of the feature is!  If the purpose is *just* to sort [[Recent Changes]]
neatly, I imagine it might depend on how narrowly we can expect people's
interests in Wikipedia article edits to be delineated.

> Of course, most of that *could* be done with simple [[links]] (treat a
> link to [[Biology]] as a category, for example), this is just more -
> well, visible.
>
> If you don't want it, just say so, it'll be gone in a minute...
> (Remember, I just implement the stuff, I don't think about what it is
> good for;)

In the interests of simplicity and general lack of headaches, I'd say at
least scrap *this* version of it; but save the code, of course, since we
might think of a very good use for it.

Larry

> > -----Original Message-----
> > From: wikipedia-l-admin at nupedia.com
> > [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Larry Sanger
> > Sent: Thursday, January 03, 2002 8:10 PM
> > To: Wikipedia-L at Nupedia. Com
> > Subject: Re: [Wikipedia-l] Categories in the PHP script
> >
> >
> > Magnus, can you give me an example of a post or just some point that
> > someone has made, that constituted a feature requirement such that this
> > feature in particular is supposed to fulfill it?  There's so much that has
> > been said on the topic of categories that I can't remember.  I mean, I'd
> > like to see the feature requirements at the same time we see the feature,
> > so that we can compare the two.
> >
> > I do remember one feature that I asked for, along with Jimbo (in at least
> > one form--the feature, not Jimbo), and perhaps some other people, that
> > this might help with.  Namely, "Recent Changes" has gotten perhaps so
> > large as to have too much noise and not enough signal for someone who is
> > interested only in a few topics.  In that case, my suggestion was that we
> > categorize edits (not articles) in one of the front-page categories, by
> > selecting them from a multiple selection box.  (Future edits could be
> > automatically categorized the same way, or changed by the user as they
> > become relevant to different areas.)  This is a specific, delimited
> > solution to a specific, delimited problem, and it would make Wikipedia
> > more attractive to specialists, which is important.
> >
> > The category feature you've created could be used in all sorts of ways,
> > and (sorry!) I'm not sure I like all of those ways.  First of all, it
> > appears to be a way to get the notion of subpages in through the back
> > door, by distinguishing a "category" category of articles and an "articles
> > in this category" category.  So, if used indiscriminately, I'd largely be
> > opposed to this new feature on much the same grounds that I was opposed to
> > subpages in the first place.
> >
> > If, on the other hand, we as a community were to decide that only a
> > *limited, pre-designated* set of pages could be "category" pages, then
> > this would be, obviously, different from the old main page-subpage scheme.
> > In that case, though, I should think it would be better to select the
> > category for any given page from a drop-down box, so people couldn't mess
> > up the spelling, attempt to add categories that shouldn't be categories,
> > etc.  Moreover, while my misgivings with subpages would not apply, for the
> > most part, I'd still wonder--just because I like to be clear about this
> > sort of thing--what the feature, used this way, would accomplish.  I
> > imagine that after the philosophy of language article, we'd have the
> > "philosophy" and "language" (and/or "linguistics") categories listed.  In
> > doing this, we would *highlight* the fact that the article belongs to a
> > number of traditional academic categories.  And we would invite the reader
> > to begin their exploration of Wikipedia with those traditional academic
> > categories.  And you know, I agree with the interdisciplinary advocates: I
> > just don't think the traditional academic categories are *important
> > enough*, per se, for us to take this trouble to *highlight* them for the
> > reader.  The reader can easily and will naturally deduce the general
> > subjects, at many different levels (not just the broadest-traditional-
> > academic-category level), just by reading the article and following the
> > links in the text.  The beauty of a well-written, complete, well-linked
> > article is that one can specifically place its location in the web of
> > knowledge by reading the article itself.
> >
> > Of course, I could be just failing to remember or realize some other clear
> > benefit of having articles sorted into a limited number of various
> > official categories.
> >
> > Now, if we *simply* wanted to use this as a standard "see also" section,
> > some modified version of this might work well.  But it does too much for
> > just tha right nowt...
> >
> > Awaiting further enlightenment!
> >
> > Larry
> >
> > On Thu, 3 Jan 2002, Magnus Manske wrote:
> >
> > > Hi all!
> > >
> > > I finally got to implement the often-demanded categories in the
> > PHP script
> > > (http://wikipedia.sourceforge.net/fpw/wiki.phtml).
> > >
> > > It works like this:
> > > - Add "{{CATEGORY A category,Another category}}" to the text of
> > an article.
> > > Separate the categories by ",".
> > > - Everything between {{ and }} will *not* be displayed within
> > the text, but
> > > as a category list at the bottom of the page, as well as in the
> > sidebar, if
> > > you have turned it on.
> > > - In an article that *is* a category, write "{{THISCATEGORY}}"
> > somewhere.
> > > This will be replaced with a list of all articles which *at that very
> > > moment* have a "{{CATEGORY xyz}}" for that category.
> > >
> > > See it for yourself at the above site. I put "Gene" and "DNA" into both
> > > "Biology" and "Genetics" category. "Genetics" itself is in the "Biology"
> > > Category. On the "Genetics" and "Biology" pages, at the bottom,
> > you'll find
> > > a grey box, listing all the pages that are within that category.
> > >
> > > OK, I know this screams "problems" all over, but it's just the
> > "hooray, it's
> > > running!" version. There's much more to be done, starting with a sorted
> > > article output to limiting "Search" and "Recent Changes" to certain
> > > categories, and so on. But hey, it's a start...
> > >
> > >
> > >
> > > A more technical note: I also put all the "fixed" text displayed on the
> > > 'pedia into variables and collected them in one single file. So, for
> > > international versions, only one file has to be changed, the
> > other files can
> > > get "technical" updates without having to translate/merge the
> > whole thing
> > > again.
> > >
> > > That's all for now,
> > > Magnus
> > >
> > > [Wikipedia-l]
> > > To manage your subscription to this list, please go here:
> > > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> > >
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


list: wikipedia-l

source: pipermail-mbox

from_name: Magnus Manske

subject: [Wikipedia-l] Categories in the PHP script

body:
Hi all!

I finally got to implement the often-demanded categories in the PHP script
(http://wikipedia.sourceforge.net/fpw/wiki.phtml).

It works like this:
- Add "{{CATEGORY A category,Another category}}" to the text of an article.
Separate the categories by ",".
- Everything between {{ and }} will *not* be displayed within the text, but
as a category list at the bottom of the page, as well as in the sidebar, if
you have turned it on.
- In an article that *is* a category, write "{{THISCATEGORY}}" somewhere.
This will be replaced with a list of all articles which *at that very
moment* have a "{{CATEGORY xyz}}" for that category.

See it for yourself at the above site. I put "Gene" and "DNA" into both
"Biology" and "Genetics" category. "Genetics" itself is in the "Biology"
Category. On the "Genetics" and "Biology" pages, at the bottom, you'll find
a grey box, listing all the pages that are within that category.

OK, I know this screams "problems" all over, but it's just the "hooray, it's
running!" version. There's much more to be done, starting with a sorted
article output to limiting "Search" and "Recent Changes" to certain
categories, and so on. But hey, it's a start...

A more technical note: I also put all the "fixed" text displayed on the
'pedia into variables and collected them in one single file. So, for
international versions, only one file has to be changed, the other files can
get "technical" updates without having to translate/merge the whole thing
again.

That's all for now,
Magnus


body:
Larry, I was just working my way through a "feature request" list I keep for
myself, and "categories" was one of them. So, I'm sure it was in discussion
somewhere. The only mention of it I can find right now is at

http://wikipedia.com/wiki/Feature_requests/Really_ambitious_and_fanciful_fea
ture_requests

where you already "answered" that request, as I see now. Anyway, the feature
isn't meant to *reduce* anything - it is just for making certain things
easier. As I said, it is only implemented as a "minimal" version right now.
There's no pressure to use it. Yes, it has some drive into the
"old-fashioned" categories. But, even in the "web structure" of wikipedia,
noone would put a "DNA" article under "fiddle traditions"...

I just thought it would make things easier, so *later*, you could restrict
your "Recent Changes" to display only articles
* without any category information (=not categorized at all) and
* those with Biology as a category
There's no point in choosing a category at every edit, right?

Also, this could be a way to use categories for the "approval" mechanism we
didn't decide on yet...

As for the categories, I suggest we use all "HomePage" categories, and,
additionally, more specific ones, like "Biochemistry".

Of course, most of that *could* be done with simple [[links]] (treat a link
to [[Biology]] as a category, for example), this is just more - well,
visible.

If you don't want it, just say so, it'll be gone in a minute...
(Remember, I just implement the stuff, I don't think about what it is good
for;)

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Larry Sanger
> Sent: Thursday, January 03, 2002 8:10 PM
> To: Wikipedia-L at Nupedia. Com
> Subject: Re: [Wikipedia-l] Categories in the PHP script
>
>
> Magnus, can you give me an example of a post or just some point that
> someone has made, that constituted a feature requirement such that this
> feature in particular is supposed to fulfill it?  There's so much that has
> been said on the topic of categories that I can't remember.  I mean, I'd
> like to see the feature requirements at the same time we see the feature,
> so that we can compare the two.
>
> I do remember one feature that I asked for, along with Jimbo (in at least
> one form--the feature, not Jimbo), and perhaps some other people, that
> this might help with.  Namely, "Recent Changes" has gotten perhaps so
> large as to have too much noise and not enough signal for someone who is
> interested only in a few topics.  In that case, my suggestion was that we
> categorize edits (not articles) in one of the front-page categories, by
> selecting them from a multiple selection box.  (Future edits could be
> automatically categorized the same way, or changed by the user as they
> become relevant to different areas.)  This is a specific, delimited
> solution to a specific, delimited problem, and it would make Wikipedia
> more attractive to specialists, which is important.
>
> The category feature you've created could be used in all sorts of ways,
> and (sorry!) I'm not sure I like all of those ways.  First of all, it
> appears to be a way to get the notion of subpages in through the back
> door, by distinguishing a "category" category of articles and an "articles
> in this category" category.  So, if used indiscriminately, I'd largely be
> opposed to this new feature on much the same grounds that I was opposed to
> subpages in the first place.
>
> If, on the other hand, we as a community were to decide that only a
> *limited, pre-designated* set of pages could be "category" pages, then
> this would be, obviously, different from the old main page-subpage scheme.
> In that case, though, I should think it would be better to select the
> category for any given page from a drop-down box, so people couldn't mess
> up the spelling, attempt to add categories that shouldn't be categories,
> etc.  Moreover, while my misgivings with subpages would not apply, for the
> most part, I'd still wonder--just because I like to be clear about this
> sort of thing--what the feature, used this way, would accomplish.  I
> imagine that after the philosophy of language article, we'd have the
> "philosophy" and "language" (and/or "linguistics") categories listed.  In
> doing this, we would *highlight* the fact that the article belongs to a
> number of traditional academic categories.  And we would invite the reader
> to begin their exploration of Wikipedia with those traditional academic
> categories.  And you know, I agree with the interdisciplinary advocates: I
> just don't think the traditional academic categories are *important
> enough*, per se, for us to take this trouble to *highlight* them for the
> reader.  The reader can easily and will naturally deduce the general
> subjects, at many different levels (not just the broadest-traditional-
> academic-category level), just by reading the article and following the
> links in the text.  The beauty of a well-written, complete, well-linked
> article is that one can specifically place its location in the web of
> knowledge by reading the article itself.
>
> Of course, I could be just failing to remember or realize some other clear
> benefit of having articles sorted into a limited number of various
> official categories.
>
> Now, if we *simply* wanted to use this as a standard "see also" section,
> some modified version of this might work well.  But it does too much for
> just tha right nowt...
>
> Awaiting further enlightenment!
>
> Larry
>
> On Thu, 3 Jan 2002, Magnus Manske wrote:
>
> > Hi all!
> >
> > I finally got to implement the often-demanded categories in the
> PHP script
> > (http://wikipedia.sourceforge.net/fpw/wiki.phtml).
> >
> > It works like this:
> > - Add "{{CATEGORY A category,Another category}}" to the text of
> an article.
> > Separate the categories by ",".
> > - Everything between {{ and }} will *not* be displayed within
> the text, but
> > as a category list at the bottom of the page, as well as in the
> sidebar, if
> > you have turned it on.
> > - In an article that *is* a category, write "{{THISCATEGORY}}"
> somewhere.
> > This will be replaced with a list of all articles which *at that very
> > moment* have a "{{CATEGORY xyz}}" for that category.
> >
> > See it for yourself at the above site. I put "Gene" and "DNA" into both
> > "Biology" and "Genetics" category. "Genetics" itself is in the "Biology"
> > Category. On the "Genetics" and "Biology" pages, at the bottom,
> you'll find
> > a grey box, listing all the pages that are within that category.
> >
> > OK, I know this screams "problems" all over, but it's just the
> "hooray, it's
> > running!" version. There's much more to be done, starting with a sorted
> > article output to limiting "Search" and "Recent Changes" to certain
> > categories, and so on. But hey, it's a start...
> >
> >
> >
> > A more technical note: I also put all the "fixed" text displayed on the
> > 'pedia into variables and collected them in one single file. So, for
> > international versions, only one file has to be changed, the
> other files can
> > get "technical" updates without having to translate/merge the
> whole thing
> > again.
> >
> > That's all for now,
> > Magnus
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> >
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Larry Sanger

subject: [Wikipedia-l] press release

body:
I don't see why we shouldn't post a draft, sure!  But I and Jimbo are
going to decide on the final shape of it.  Actually, I guess *Jimbo* will
be the one to make the absolute final decisions.  :-)

It will, in any event, be a *Wikipedia* press release.  :-)

Larry

On Fri, 4 Jan 2002, wojtek pobratyn wrote:

> hi all.
>
> regarding the press release (1st anniversary & co.): are we going to
> put up a draft on the meta site? Or is it going to be a /Bomis/ press
> release?
>
> regards, wojpob
>
>
>


subject: [Wikipedia-l] Very interesting article

body:
http://www.nytimes.com/2001/01/18/technology/18SELF.html

Notice, this is from almost one year ago, and was written just three days
after Wikipedia began.

Two websites, however, are mentioned that I would think would be of
interest to Wikipedians: http://www.thevines.com/ and
http://www.themestream.com/ I'd heard of these before but never knew very
much about them.  Now, thevines.com seems to be password only, and
themestream.com seems to be down.  Anyone know what's up with them?

Larry


subject: [Wikipedia-l] This explains themestream...

body:
It died last April:

http://www.freesticky.com/stickyweb/articles/themestreamcloses.asp


subject: [Wikipedia-l] Very interesting article

body:
And this

http://www.writersweekly.com/warnings/thevines.html

explains what happened to thevines.com.  Very interesting.

Larry


from_name: Jimmy Wales

subject: [Wikipedia-l] press release

body:
Yes, by all means, let's post a draft.  But yes, since I'm paying for
it to be sent out, I'll have to approve the final version.  :-)
Still, I'm all for letting the community speak through the press
release and the wiki process.

Larry Sanger wrote:

> I don't see why we shouldn't post a draft, sure!  But I and Jimbo are
> going to decide on the final shape of it.  Actually, I guess *Jimbo* will
> be the one to make the absolute final decisions.  :-)
>
> It will, in any event, be a *Wikipedia* press release.  :-)
>
> Larry
>
> On Fri, 4 Jan 2002, wojtek pobratyn wrote:
>
> > hi all.
> >
> > regarding the press release (1st anniversary & co.): are we going to
> > put up a draft on the meta site? Or is it going to be a /Bomis/ press
> > release?
> >
> > regards, wojpob
> >
> >
> >
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*********************************************************************
*"The rifle itself has no moral stature, since it has no will of its*
* own. Naturally, it may be used by evil men for evil purposes, but *
* there are more good men than evil, and while the latter cannot be *
*  pursuaded to the path of righteousness by propaganda, they can   *
*  certainly be corrected by good men with rifles." -Jeff Cooper    *
********************************************************************


from_name: wojtek pobratyn

subject: [Wikipedia-l] press release

body:
hi all.

regarding the press release (1st anniversary & co.): are we going to put up a draft on the meta site? Or is it going to be a /Bomis/ press release?

regards,
wojpob

--

Tego nie znajdziesz w zadnym sklepie!
[ http://oferty.onet.pl ]


subject: [Wikipedia-l] press release

body:
Jimmy Wales <jwales at bomis.com> napisa?:

>Yes, by all means, let's post a draft.  But yes, since I'm paying for
> it to be sent out, I'll have to approve the final version.  :-)

never has any disrespect been meant. we all know that bomis pays for the 'pedia.

> Still, I'm all for letting the community speak through the press
> release and the wiki process.

that was my point. if it is going to be a community release let the community speak. bomis can release statements anytime it wants to do so.

regards,
+wojpob

--

Tego nie znajdziesz w zadnym sklepie!
[ http://oferty.onet.pl ]


from_name: Taral

subject: [Wikipedia-l] Re: Incorrect HTML encoding--something new?

body:
On Tue, Jan 01, 2002 at 05:50:24PM +1300, Carey Evans wrote:
> lcrocker at nupedia.com writes:
>
> > I'm not sure when it happened, but somewhere the main Wikipedia site
> > started putting out HTML with:
> >
> >   ?xml version="1.0" encoding="utf-8"?
> >   ...
> >   !DOCTYPE html
> >   PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
> >   ...
>
> I believe this changed just a few days to a week before I added my bug
> report to http://www.wikipedia.com/wiki/Wikipedia_bugs on 17 November.
> It's rather obvious in Mozilla and Netscape 6, because the DOCTYPE
> triggers strict parsing mode and the tag soup method of nested <DL>
> elements for indents stops working.

Well, it says HTML 4 Transitional now, but it's still not right. There's
an <hr> inside a <font> tag and the nested <dl> stuff still isn't
considered valid. (Mozilla ignores it)

--
Taral <taral at taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose


from_name: Simon Kissane

body:
I like Magnus' idea a lot. Yes, we could just use
ordinary old links. But I like this better for a
couple of reasons:
1. Software can understand the {{CATEGORY ...}}
notation much better than it can understand plain old
links. What if I want to extract all the articles on
linguistics from Wikipedia? With categories like this,
I could have a script that could do it easily. But
with just plain old links, writing a script to do it
would be difficult.
2. We can easily find "loose" pages, that don't belong
to a category. (On the other hand, we could mark the
category pages as category pages, and then search for
pages aren't linked from a page marked as a category
page.)

Larry suggested having a drop-down box, to limit the
categories the users could choose from. I think
Wikipedia should support multiple category schemes,
and should allow anyone to add their own categories.
That way we can experiment, and see what works best.
People with alternative views of how to categorise
things can create their own category schemes (and
categorising things is one area where there are often
as many views as there are people, probably because
there is no one right answer.)

I think it would be nice if we could have different
"category namespaces", to support multiple category
schemes. There should also be a way to lock cateogy
namespaces: so I can have my own category namespace,
and only I am allowed to assign pages to categories
within it; or so (like Larry seems to be suggesting)
people can't create their own categories, but they can
assign pages to pre-existing ones.

I also think that information on "what pages this
category belongs to" belongs in the category, not in
the page (although I don't know how you were actually
installing this.)

Finally, even if we don't want this sort of feature
for Wikipedia, why not keep the code, but make it an
administrator configurable option? So if Larry & Jimbo
don't want to use it on the Wikipedia.com server, they
can switch it off, but if other people want to take
PHP Wikipedia's code to use for some other purpose
they can turn it on if they want to?

Simon Kissane

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


body:
First, let me say that, despite all appearances, I'm not trying to
criticize Magnus (surely no one should be criticized for doing work for
Wikipedia ;-) ).  Or Simon!  I just think we need to think harder about
all of these issues.

Maybe Simon can answer the question Magnus couldn't (or, not very well as
far as I could tell): what is the *purpose* of this feature?  What is it
supposed to accomplish?

On Sun, 6 Jan 2002, Simon Kissane wrote:

> I like Magnus' idea a lot. Yes, we could just use
> ordinary old links. But I like this better for a
> couple of reasons:
> 1. Software can understand the {{CATEGORY ...}}
> notation much better than it can understand plain old
> links. What if I want to extract all the articles on
> linguistics from Wikipedia? With categories like this,
> I could have a script that could do it easily. But
> with just plain old links, writing a script to do it
> would be difficult.

OK, this is helpful: categories could be used to sort articles into broad
compilations (associated with academic fields like linguistics) that, for
whatever reason (and who can predict what reasons they would be?), people
might like to have.

I can see a use for that, but I think it needs to be clarified further: is
the claim that it would be useful to have articles sorted only at the
top-level categories (those on the HomePage, just for example) or at some
expanded level?  If at some expanded level, depending on *how* expanded,
the purpose(s) of the feature might change considerably.

Moreover, it is *not* at all clear to me (particularly given, as Simon
says, we might want to support multiple category schemes--though this too
I might doubt, as I'll have to explain) that this particular
implementation is the best.  What *would* be the best way to sort articles
into broad categories?  Why not, for example, have special pages that
simply list article titles, so that, e.g., [[linguistics category]] would
contain nothing but links to articles that someone asserts belong to the
category of linguistics?  We could just as easily autogenerate lists of
uncategorized pages, and for each article page we could have the script
look at the category: pages to see whether the article is in a category.
I'm not saying that this is a better idea; I'm just saying that there are
multiple ways of going about doing something, and it would be a mistake
not to consider them.

> 2. We can easily find "loose" pages, that don't belong
> to a category. (On the other hand, we could mark the
> category pages as category pages, and then search for
> pages aren't linked from a page marked as a category
> page.)
>
> Larry suggested having a drop-down box, to limit the
> categories the users could choose from. I think
> Wikipedia should support multiple category schemes,
> and should allow anyone to add their own categories.

Well, we could have multiple drop-down boxes, eh?  How else would we
individuate our multiple category schemes?  The whole point of a drop-down
box is to disallow a category scheme from metastasizing for frivolous
reasons (such as that somebody didn't know that an article that goes under
XYZ really belongs under XYZ, and so creates its own category--just an
example).

> That way we can experiment, and see what works best.

How exactly would we experiment?  What would we be seeing "works best"?

I think at this point we need to be very clear on what we mean by
"category scheme."  On the one hand, there are schemes of the sort we have
on the Home Page, or the Library of Congress catalog scheme.  Those
schemes (1) list subjects, (2) arrange those subjects under larger
headings ("supercategories"), and even (3) provide an ordering of some
sort within the "supercategories."  So when you say we can experiment and
see what works best, which of these (or what combination) do you mean?
We already do experiment with multiple category schemes in the sense of a
combination of (1) and (2).  But this doesn't list all articles, of
course.

But when Magnus proposes to allow us to list the category, or categories,
of a particular article on an article's page itself (even within the body
of the article itself), he provides us no particular category scheme in
*any* of the senses in (1), (2), or (3) (which is fine).  What Simon
asserts now is that Magnus' feature allows is "multiple category schemes."
I don't see this, though.  What it allows us, rather, is multiple
*categories*, at the whim of the user: so we could expand the list
mentioned in (1) at will.  That's the only sense in which I can see how
Magnus's feature allows us "multiple category schemes."

By contrast, there's nothing about Magnus' feature that allows us to
produce multiple category schemes in the sense in which we've *usually*
talked about them on Wikipedia (and Nupedia), viz., the *combination* of
(1) (a specific, delimited set of subject categories) and (2) (an
arrangement of that delimited set into supercategories).  As far as I can
tell, Magnus' feature at present would give us *a single* infinitely
expandable set of categories.

> People with alternative views of how to categorise
> things can create their own category schemes (and
> categorising things is one area where there are often
> as many views as there are people, probably because
> there is no one right answer.)

Wouldn't that make categorization particularly pointless?  No one person
is going to categorize all our articles, I imagine--no one person is
competent to do so, probably.  That means we have to work together on
this.  Now, I can see multiple competing category schemes (maybe--but I'd
like to know what the purpose of *that* would be).  Say, two or three.
More than that, and, again, we've got a veritable babel; in that case, I
doubt any one scheme would succeed in categorizing all the articles.  Even
two or three is a little confusing: won't "philosophy" be a category in
any plausible scheme?  Similar with other traditional subjects.  So how
will the competing category lists (not schemes, really) be distinguished?

On the other hand, if we can agree in advance on one set of categories,
then, *for the purpose of sorting articles into broad academic fields*
(which, as I said, seems like a clear, reasonably useful purpose), we can
*work together* on sorting all the articles.  That would be a good thing:
it could be a useful, accurate piece of metadata.

> I think it would be nice if we could have different
> "category namespaces", to support multiple category
> schemes. There should also be a way to lock cateogy
> namespaces: so I can have my own category namespace,
> and only I am allowed to assign pages to categories
> within it; or so (like Larry seems to be suggesting)
> people can't create their own categories, but they can
> assign pages to pre-existing ones.

I'm not sure I understand, exactly, but is the idea here somewhat like the
one I suggested above?  Viz., we put the metainformation about categories
not on article pages but on special categorization pages?

> I also think that information on "what pages this
> category belongs to" belongs in the category, not in
> the page (although I don't know how you were actually
> installing this.)

Aha, yes.  Might be better, yes.

> Finally, even if we don't want this sort of feature
> for Wikipedia, why not keep the code, but make it an
> administrator configurable option? So if Larry & Jimbo
> don't want to use it on the Wikipedia.com server, they
> can switch it off, but if other people want to take
> PHP Wikipedia's code to use for some other purpose
> they can turn it on if they want to?

I'd be 100% in favor of something like that.

I really don't like to sound contrary (really, I don't!), but I think that
whenever we propose new features that could potentially complicate the
process of building Wikipedia, and that could be abused or misused
(resulting in confusion if nothing else), we should think more carefully
about what we are doing and why we're doing it, exactly.

So far, along these lines, there are *two* actual reasons that I have
spotted for why we might want to do *one specific* thing, viz., list
(somewhere) the metadata about what *general categories* articles are
classed under.  To wit:

(1) It would help sort the Recent Changes page nicely, so that specialists
can, if they want, focus just on articles in their areas.  (Others could
view all categories at once.)  If this were all we needed to accomplish,
then we might as well sort *edits* into categories, not *articles*.

(2) It would allow us to produce a list of all the articles in one broad
area of study, which would no doubt be useful for a variety of purposes.
For this, of course, we need to sort articles, not edits.

Now, there are a variety of ways we could accomplish both of these
purposes.  The best I think we've heard so far would work like this:

On each article page, there is a multiple-selection box that allows us to
place articles into one or more categories from among a set of categories
that is previously decided upon by Wikipedia members and probably Nupedia
as well (it would be nice if the categories corresponded to Nupedia review
groups).  This particular datum is editable like anything else in the
article.  There is *also* a set of pages sorting existing articles into
these categories based on the metadata found on the articles; these might
or might not be editable.  There is, as well, a page or several of
unsorted articles; from that page one could visit different pages and sort
them quickly.

The latter proposal would accomplish purposes (1) and (2) as follows: the
metadata would allow us to sort the Recent Changes page so we can view
only those categories of articles we're interested in; it would also allow
us to generate (and further organize, perhaps) broad categories of
articles.  One can see an autogenerated Wikipedia Encyclopedia of
Mathematics, for example!

Larry


from_name: Lars Aronsson

body:
Taral wrote:
> Well, it says HTML 4 Transitional now, but it's still not right. There's
> an <hr> inside a <font> tag and the nested <dl> stuff still isn't
> considered valid. (Mozilla ignores it)

"HTML 4 Transitional" is the standard that I use on my websites, and I
think it could be a good idea for Wikipedia aswell.  You use W3C's
validator to check your web pages, and when they pass, you receive
instructions for how to include a logotype-link at the bottom of each
page.  See e.g. the yellow W3C logo at the bottom of these pages:

    http://aronsson.se/
    http://elektrosmog.nu/
    http://www.lysator.liu.se/runeberg/
    http://susning.nu/

The latter is a UseModWiki, just like Wikipedia, so it is indeed
possible.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Link?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] ODBASE 2002 -- Call for Papers

body:
Wikipedia,

The following is a "call for papers" for a conference to be held in
Irvine, California, this fall.  Wikipedia might fit as a topic for a
paper.  Any takers?  Can a paper be coauthored as a wiki page?  :-)

Paper Submission Deadline:  May 31, 2002

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/

------- Start of forwarded message -------
Date:         Sat, 5 Jan 2002 17:48:16 -0500
Sender: Digital Libraries Research mailing list
    <DIGLIB at INFOSERV.NLC-BNC.CA>
From: Ugur Cetintemel <ugur at CS.BROWN.EDU>
Subject:      ODBASE 2002 -- Call for Papers
To: DIGLIB at INFOSERV.NLC-BNC.CA

                       C A L L   F O R   P A P E R S
                       =============================

                        International Conference on
                Ontology's, DataBases, and Applications of
           Semantics for Large Scale Information Systems (ODBASE)

               October 29 - November 1, Irvine, California
             http://www.cs.rmit.edu.au/fedconf/odbase/2002

               Proceedings to be published by IEEE Press

A key challenge in making the Internet and the Web a more friendly and
productive place is to fill more meaning to the vast and continuously
growing amount of data on the Net. This is a vision that is shared
both by the Worl Wide Web community, incarnated by the notion of the
?Semantic Web? coined by Tim Berners Lee, and researchers from a
number of areas including data and knowledge engineering, databases,
intelligent agent systems, information retrieval, information sciences
and linguistics. The claim is that the emergence of meaning that is
associated with data and documents found on the Internet will boost
diverse applications such as e-commerce, enterprise and information
integration, knowledge engineering, geographic information systems,
digital libraries, ubiquitous computing, and intelligent information
access. Data semantics and ontologies for large-scale information
systems have become an important topic in research communities across
several displines, research funding agencies, as well as various
industries.

The international conference on Ontology's, DataBases, and
Applications of Semantics intends to create a forum to exchange views,
ideas and experiences on ontologies and data semantics from different
disciplines. A goal of the ODBASE conference is to bring researchers
from databases, Semantic Web, and knowledge management together to
discuss specific problems and promising approaches to providing more
meaning for the growing amount of data on the Internet and in
ubiquitous computing. A unique character of the ODBASE conferences is
its specialization on data semantic issues for very large ontology and
Internet systems, and its strong emphasis on interdisciplinarity and
practical applicability of systems, tools and methods for supporting
semantics in large-scale information systems. The program committee of
ODBASE 2002 consists of leading experts from diverse discplines
including formal ontology, databases, geographic information systems,
library science, logic, and knowledge management.  We have special
interest in papers that bridge traditionally separated areas such as
databases, intelligent systems, and knowledge engineering, and papers
that address issues of scalability in data semantics on the Internet
and ubiquitous computing systems.

ODBASE'02 is part of the Federated Symposium Event that is organized
within the global theme "On the Move to Meaningful Internet Systems
and Ubiquitous Computing 2002". This federated event co-locates three
related and complementary successful conferences in the areas of
Intelligent Networked Information Systems, covering key issues in Data
and Web Semantics (ODBASE'02), Distributed Objects, Infrastructure and
Enabling Technology and Internet Computing (DOA'02), and Workflow,
Cooperation, and Interoperability (CoopIS'02), as required for the
deployment of Internet- and Intranet-based systems in organizations
and for e-business. More details about this federated event can be
found at http://www.cs.rmit.edu.au/fedconf.

Areas of interest of ODBASE'02 include but are not limited to:

   * Representation and Storage:
     Information, Data and Knowledge Modeling
     Ontology Languages
     Hypertext and Hypermedia
     Semi-Structured Data
     Multimedia Data and Metadata
     Semantics of E-Services
     Management of Large Knowledge Repositories
     Management and Integration of Large Ontology Bases
     Metadata Repositories
     Semantic Middleware

   * Construction and Methodologies:
     Database Integration
     E-Service Integration
     Searching and Managing Dynamic Contents
     Data and Web Mining
     Intelligent Information Agents
     Information Retrieval
     Filtering and Summarization
     Multimedia Metadata Annotation
     Ontology Extraction and Learning
     Self-organization in Information Systems

   * Applications and Evaluation:
     Semantic Web
     Domain/Application Ontology
     Ontology of Information Processing
     Electronic Commerce
     Digital Libraries
     Media Archives
     Enterprise-wide Information Systems
     Web-based Information Systems
     Location-dependent information services
     Web Services and Service Interoperability
     Information Dissemination
     Ubiquitous and Mobile Information Systems

IMPORTANT DATES

     Paper Submission Deadline:  May 31, 2002
     Acceptance Notification:    July 15, 2002
     Final Version Due:          August 20, 2002
     Conference:                 October 30 - November 1, 2002

SUBMISSION GUIDELINES

     All submitted papers will be carefully evaluated based on originality,
     significance, technical soundness, and clarity of expression.  Papers
     that bridge two or more areas should be marked as BRIDGE papers. They
     will be reviewed jointly by the appropriate PC sub-areas. All
     submissions must be in English. Research submissions must not exceed
     8,000 words. Submissions can either be in Postscript, MS Word, or Pdf
     format and should be done through the following URL

              http://www.cs.rmit.edu.au/fedconf/submit.html

     The final proceedings will be published by IEEE Press. Failure to
     commit to presentation at the conference automatically excludes a
     paper from the proceedings.

ORGANIZATION COMMITTEE

General Co-Chairs

           Robert Meersman       Zahir Tari            Mike Papazoglou
           STARLab               RMIT University       Tilburg University
           Free University of    Department of         Infolab
           Brussels              Computer Science      PO Box 90153
           Building F-G 10,      City Campus, GPO Box  NL-5000 LE TILBURG
           Pleinlaan 2           2476V                 The Netherlands
           B-1050 Brussels       Melbourne, VIC 3001   mikep at kub.nl
           Belgium               Australia
           meersman at vub.ac.be    zahirt at cs.rmit.edu.au

Program Committee Co-Chairs

           Karl Aberer           Ling Liu               Robert A. Meersman
           LSIR  (Distributed    College of             VUB (Vrije
           Information Systems   Computing,             Universiteit
           Laboratory)           Georgia Tech           Brussel)
           EPFL, CH-1015         801 Atlantic Dr.       Department of
           Lausanne,             Atlanta, GA            Computer Science
           Switzerland           30332-0280, USA         STARlab, Building
           karl.aberer at epfl.ch   lingliu at cc.gatech.edu  F-G/10
                                                        Pleinlaan 2 B-1050
                                                        Brussels Belgium
                                                        meersman at vub.ac.be

Tutorial Chair

          Vipul Kashyap
          Telcordia, USA

Organising Chair

          Douglas Schmit
          University of
          California, Irvine

Publicity Chair

           Ugur Cetintemel
           Department of
           Computer Science
           Brown University,
           USA
           ugur at cs.brown.edu

Program Committee Members (TBA)

------- End of forwarded message -------


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] ODBASE Call for Papers

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020107/431f40df/attachment.diff


from_name: Tuxisuau

subject: [Wikipedia-l] I use another method

body:
I use another method to know the number of pages.
i do:
http://es.wikipedia.com/wiki.cgi?action=index
(for example, with the spanish version)

By the way, i truly need help with the catalan wikipedia... see
meta.wikipedia.com. Now i have trolls too writing stupid jokes instead
of articles :(.
--
tuxisuau. tuxisuau at 7a69ezine.org
http://tuxisuau.7a69ezine.org
"How I need a drink, alcoholic of course, after the heavy chapters involving quantum mechanics"
George Polya
"Esto son 31338 hax0rs y se cae el del medio"
Tahum
Wikipedia, la enciclopedia libre. http://es.wikipedia.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020108/4b4d6908/attachment.pgp


subject: [Wikipedia-l] Press release draft posted

body:
Hi all,

Please read and comment and/or edit:

http://meta.wikipedia.com/wiki.phtml?title=Wikipedia's_first_press_release--draft_for_comment

Note that the draft presently calls for an appropriate quotation from one
of our resident academics.  :-)

Larry


body:
--- Larry Sanger <lsanger at nupedia.com> wrote:
> First, let me say that, despite all appearances, I'm
> not trying to criticize Magnus (surely no one
> should be criticized for doing work for
> Wikipedia ;-) ).  Or Simon!  I just think we need to
> think harder about all of these issues.
>
> Maybe Simon can answer the question Magnus couldn't
> (or, not very well as far as I could tell): what is
> the *purpose* of this feature?  What is it supposed
> to accomplish?
Well, as I see it, the purpose is to make the
administration of lists of pages easier -- these lists
could be categories (such as Philosophy, or
Mathematics, or so on) -- but I also think other lists
such as Biographies, Mathematics, U.S. Presidents,
International Intergovernmental Organizations, and so
on.

Consider for example if I was to put the article on
Bill Clinton in the Biography listing, and the U.S.
Presidents listing. At the moment I have to edit two
or three pages -- the Biography and the U.S.
Presidents listing to add a link to the article, and
the article to add a backlink to the lists (if so
desired). With Magnus proposal, as I understand it,
I'd just have to insert "{{{CATEGORY Biography,
US_Presidents}}}" into the article and I'd be done.

Also, with these categories, its easier to
automatically extract the articles in Wikipedia on
that category, since software can parse "{{{CATEGORY
...}}}" more easily than links on a category page
(since it can't tell which links point to pages within
the category, and which links point elsewhere --
unless it has AI, of course).

And supposing we want to divide articles up by
traditional academic discipline, using this lets us
easily see which articles have not yet been assigned.
(We'd simply have to do a query to see which articles
are not in one of the categories which make up our
category scheme.)

[snip]
> OK, this is helpful: categories could be used to
> sort articles into broad compilations (associated
> with academic fields like linguistics) that, for
> whatever reason (and who can predict what reasons
> they would be?), people might like to have.
>
> I can see a use for that, but I think it needs to be
> clarified further: is the claim that it would be
> useful to have articles sorted only at the
> top-level categories (those on the HomePage, just
> for example) or at some expanded level?  If at some
> expanded level, depending on *how* expanded,
> the purpose(s) of the feature might change
> considerably.
Well, I see two uses for this. Firstly, putting
articles into broad categorisations, such as those
used on the home page. Second, is maintaining lists
like U.S. President, and so on.

I'm not proposing we try to design a complex
hierarchial classification scheme. For starters, we
can put all the Maths pages into a "Mathematics"
category. But, if someone wants to go to the trouble
of creating additional categories,
"Mathematics--Analysis" and "Mathematics--Topology"
and "Mathematics--Geometry" and so on, why not let
them? Lets create a basic category scheme to start
with, and let it grow finer over time as (and if)
people see the need.

We should also allow people to create low-level
categories without fitting them into a hierarchy -- I
should be able to go ahead and create the category
U.S. Presidents, without having to decide whether it
belongs under History or Politics or what, or where it
should belong in some finer subclassification of those
topics. Later on, if we feel the need, and once the
category system is sufficently evolved, we can worry
about how to fit these standalone low-level categories
into broader ones.

> Moreover, it is *not* at all clear to me
> (particularly given, as Simon says, we might want to

> support multiple category schemes--though this too
> I might doubt, as I'll have to explain) that this
> particular implementation is the best.  What *would*

> be the best way to sort articles into broad
> categories?  Why not, for example, have special
> pages that simply list article titles, so that,
e.g.,
> [[linguistics category]] would contain nothing but
> links to articles that someone asserts belong to the
> category of linguistics?  We could just as easily
> autogenerate lists of uncategorized pages, and for
> each article page we could have the script look at
> the category: pages to see whether the article is in

> a category.
> I'm not saying that this is a better idea; I'm just
> saying that there are multiple ways of going about
> doing something, and it would be a mistake not to
> consider them.
I think the approach you suggest would be inferior to
Magnus' for a number of reasons. Firstly, when looking
at an article, you would not be able to see which
categories it belonged to, unless someone added a
backlink to that category. Secondly, if I want to add
an article to three different categories, I have three
different pages I have to edit -- four if I want to
include a backlink in the article. Thirdly, by using
the "{{{CATEGORY ...}}}" notation, we can store the
categories directly in the database, if we want, as a
CATEGORY table -- which will mean faster access.

[snip]
> > Larry suggested having a drop-down box, to limit
> > the categories the users could choose from. I
think
> > Wikipedia should support multiple category
schemes,
> > and should allow anyone to add their own
> > categories.
>
> Well, we could have multiple drop-down boxes, eh?
> How else would we individuate our multiple category
> schemes?  The whole point of a drop-down box is to
> disallow a category scheme from metastasizing for
> frivolous reasons (such as that somebody didn't know

> that an article that goes under XYZ really belongs
> under XYZ, and so creates its own category--just an
> example).
I agree that we need to find a way to stop frivolous
or accidental creation of categories. But at the same
time, I think we should create tools that can be used
for a wide variety of purposes, rather than putting
things in a straightjacket.

The main point behind having multiple category schemes
is that I can ask the software the question "Does this
page belong to any category in this scheme?" Suppose
we decide we want to place every Wikipedia article in
certain broad categories (Mathematics, Physics,
Chemistry, Biology, Philosophy, History, etc.), then
we want a list of all articles which do not currently
belong to one of those categories. Suppose "Bill
Clinton" belongs to the category "U.S. Presidents" --
that article should still come up in our list, since
although it belongs to a category, it does not belong
to the broad category scheme. So at the least, we'd
want a way of distinguishing subject categories (such
as History, Philosophy, etc.) from other categories
(like U.S. Presidents, Treaties, Roman Emperors,
Popes, etc.).

Secondly, suppose someone wants to create a
subclassification of a pre-existing category. Say
create categories "History--Ancient",
"History--Medieveal" and "History--Modern", or
"History--Europe", "History--North America",
"History--Asia" and so on. Then they'd want to ask
"show me all the articles in category History which
haven't been assigned to categories History--Ancient,
History--Modern or History--Europe". This would
involve some way of marking categories as
subcategories of a larger category. However, these
aren't just simple subcategories within the same
category scheme -- these are two orthogonal
categorisations. We want to be able to generate
separate "not yet assigned" lists for each.

To stop people accidentally or frivolousy creating
categories, we could make it so that people have to
execute some special procedure (e.g. a create_category
action on the script) to create a category (so they
don't accidentally automatically create one, by
mispelling it say.) That procedure should show them
what categories already exist, warn them against
creating them needlessly, explain Wikipedia policy on
categories, and so on.

We should also enable for categories to be deleted if
they are created in error. Only admins should do that
after consultation -- but we could permit anyone to
delete them, if we had an "undelete" feature (i.e. the
category disappears from the list of categories, but
its data is retained, so it can be undeleted.)

As to drop down boxes, they have their advantages and
disadvantages. The advantage is that they are easier
to use than {{{CATEGORY ...}}}. The disadvantage is
that if we ended up with a lot of categories, they'd
become unwieldly. They should be multiple selection
combo-boxes, not drop-down boxes, if we are going to
allow the one article to belong to multiple
categories. Finally, the problem with combo boxes is
that its easy to accidentally add or remove an article
from a category -- one misplaced click is all it
takes. At least with "{{{CATEGORY ...}}}", they have
to type or delete something.

But whatever user interface we choose, we can still
provide the same backend implementation.

> > That way we can experiment, and see what works
> > best.
>
> How exactly would we experiment?  What would we be
> seeing "works best"?
Well, as I said, create little categories for things
like "U.S. Presidents", "Kings of France", "Bible"...
and if someone wants to subcategorize a broader
category (i.e. create "History--Asia" and
"History--United States"), let them. Let the system
evolve (just like how we let Wikipedia articles
evolve). Remove categories that are unneccesary or
stupid. Every now and then, look back over what is
there, and try to move things into a more coherent
system.

> I think at this point we need to be very clear on
> what we mean by "category scheme."  On the one hand,

> there are schemes of the sort we have on the Home
> Page, or the Library of Congress catalog scheme.
> Those schemes (1) list subjects, (2) arrange those
> subjects under large headings ("supercategories"),
> and even (3) provide an ordering of some
> sort within the "supercategories."  So when you say
> we can experiment and see what works best, which of
> these (or what combination) do you mean?
Well, now I thought about it more, what I'm really
talking about is groups of categories which fit
together -- e.g. all different subdivisions of the one
broader subject along one aspect. (Kind of like a
faceted library classification, ala the Colon
Classification of S. R. Ranganathan.) So we'd really
only have one category scheme, it would just be, in
part, hierarchial and faceted.

> We already do experiment with multiple category
> schemes in the sense of a combination of (1) and
> (2).  But this doesn't list all articles, of
> course.
>
> But when Magnus proposes to allow us to list the
> category, or categories, of a particular article on
> an article's page itself (even within the body
> of the article itself), he provides us no particular
> category scheme in *any* of the senses in (1), (2),
> or (3) (which is fine).  What Simon asserts now is
> that Magnus' feature allows is "multiple category
> schemes."
Well, it doesn't at the moment allow that, but it
could be extended to do so, which is I suppose what I
am proposing.

[snip]
> > People with alternative views of how to categorise
> > things can create their own category schemes (and
> > categorising things is one area where there are
> > often as many views as there are people, probably
> > because there is no one right answer.)
>
> Wouldn't that make categorization particularly
> pointless?  No one person is going to categorize all

> our articles, I imagine--no one person is
> competent to do so, probably.  That means we have to
> work together on this.  Now, I can see multiple
> competing category schemes (maybe--but I'd
> like to know what the purpose of *that* would be).
> Say, two or three.
> More than that, and, again, we've got a veritable
> babel; in that case, I doubt any one scheme would
> succeed in categorizing all the articles.  Even
> two or three is a little confusing: won't
> "philosophy" be a category in any plausible scheme?

> Similar with other traditional subjects.  So how
> will the competing category lists (not schemes,
> really) be distinguished?
Now I think about it, I agree with you, so I withdraw
that aspect of what I'm proposing.

> On the other hand, if we can agree in advance on one
> set of categories, then, *for the purpose of sorting

> articles into broad academic fields*
> (which, as I said, seems like a clear, reasonably
> useful purpose), we can *work together* on sorting
> all the articles.  That would be a good thing:
> it could be a useful, accurate piece of metadata.
I think that would be useful also. But I also think we
should permit the creation of many finer categories,
such as U.S. Presidents, or Kings of England, or
Treaties, or Thailand, or 12th century... and also
subdivisions of subjects, so we can have
"Philosophy--Philosophy of Religion" and
"Mathematics--Analysis" and "Law--criminal law"... I'm
not suggesting we design a whole detailed category
scheme from the top-down, but rather let one grow from
the bottom up...

> > I think it would be nice if we could have
> > different "category namespaces", to support
> > multiple category schemes. There should also be a
> > way to lock category namespaces: so I can have my
> > own category namespace, and only I am allowed to
> > assign pages to categories within it; or so (like
> > Larry seems to be suggesting) people can't create
> > their own categories, but they can assign pages to

> > pre-existing ones.
>
> I'm not sure I understand, exactly, but is the idea
> here somewhat like the one I suggested above?  Viz.,

> we put the metainformation about categories
> not on article pages but on special categorization
> pages?
It was a badly thought out suggestion, so I withdraw
it.

[snip]
> I really don't like to sound contrary (really, I
> don't!), but I think that whenever we propose new
> features that could potentially complicate the
> process of building Wikipedia, and that could be
> abused or misused (resulting in confusion if nothing

> else), we should think more carefully about what we
> are doing and why we're doing it, exactly.
My attitude is different -- build versatile tools,
that can be used for many things, and then see what
useful things people can do with them. I agree though
we should be careful to avoid abuse or misuse, or
having some wizzy new software feature get in the way
of the primary purpose of Wikipedia, which is writing
articles (categorising them is only secondary).

[snip]
> (1) It would help sort the Recent Changes page
> nicely, so that specialists can, if they want, focus

> just on articles in their areas.  (Others could
> view all categories at once.)  If this were all we
> needed to accomplish, then we might as well sort
> *edits* into categories, not *articles*.
>
> (2) It would allow us to produce a list of all the
> articles in one broad area of study, which would no
> doubt be useful for a variety of purposes. For this,

> of course, we need to sort articles, not
> edits.

Let me add:
(3) We need a heap of categories to make it easier to
maintain and manipulate lists of Presidents,
Philosophers, Mathematicians, Countries, International
Organizations, and so on. (One category per a list.)

(4) We need categories to group articles on some broad
topic, such as all the articles on the Bible, or
articles on Hinduism, or all articles on the U.S.
Government, or so on. When dealing with a broad topic
like these, it would be nice to see a list of all the
articles on the topic, to help improve the coherency
between the different articles on the topic. However,
although these are broad topics, they are a lot
narrower than the disciplines you suggest.

(5) We need categories to help progressively develop a
more structured category scheme for Wikipedia. (The
bigger we get, the more essential organizing is going
to be, or else everything will just turn into a
mess...)

> Now, there are a variety of ways we could accomplish
> both of these purposes.  The best I think we've
> heard so far would work like this:
>
> On each article page, there is a multiple-selection
> box that allows us to place articles into one or
> more categories from among a set of categories
> that is previously decided upon by Wikipedia members
> and probably Nupedia as well (it would be nice if
> the categories corresponded to Nupedia review
> groups).  This particular datum is editable like
> anything else in the article.  There is *also* a set

> of pages sorting existing articles into
> these categories based on the metadata found on the
> articles; these might or might not be editable.
> There is, as well, a page or several of
> unsorted articles; from that page one could visit
> different pages and sort them quickly.
>
> The latter proposal would accomplish purposes (1)
> and (2) as follows: the metadata would allow us to
> sort the Recent Changes page so we can view
> only those categories of articles we're interested
> in; it would also allow us to generate (and further
> organize, perhaps) broad categories of
> articles.  One can see an autogenerated Wikipedia
> Encyclopedia of Mathematics, for example!
We could have both your proposal and mine. We have a
fixed set of broad categories for your purposes (1)
and (2). And we have an expandable list of independent
categories or subcategories for my purposes (3)-(5).

> Larry
Simon.

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


from_name: Gareth Owen

subject: [Wikipedia-l] Search engine bug report

body:
Searching for 'blues' or 'the blues' (without the quotes) doesn't return the
page http://wikipedia.com/wiki/Blues, which it probably should :(

(Especially since I received many music reference books I wish to precis as
Christmas gifts...)


from_name: Greg Carter

subject: [Wikipedia-l] McKean's Law

body:
This seems applicable to the Wikipedia universe.

McKean's Law: Any correction of the speech or writing of others will contain
at least one grammatical, spelling, or typographical error.

-- Erin McKean, American lexicographer, "VERBATIM", 2001


from_name: Robert Bihlmeyer

subject: [Wikipedia-l] Re: Categories in the PHP script

body:
  "Umgekehrt wird ein Stiefel d'raus"

I'll propose somewhat the reverse of what Magnus envisoned. In detail:

Categorised pages contain no special markup. Contrariwise, the
category pages contain special links (syntactically different from
normal ones) to pages considered in that category.

* Why is this scheme better than we do now (plain old links from a
  category to categorised pages)?

Scripts can tell that e.g. {{Compilers}} is in category [[Computer
science]] but [[Mathematics]] or [[1950s]] is not. It's possible to
automatically show (e.g. on the article bottom) links to the
categories a page is in, to restrict searches to pages in category X,
etc.

* Why is this scheme better than Magnus's (noting on a page itself
  that it belongs to categories X, Y, Z)?

Almost no good category list is just a random jumble of links. For
example [[Prime ministers of Great Britain]] should probably be sorted
in chronological order. "Proper" categories like [[Computer science]]
are best represented by dividing the listing into subfields (as done
in the current page). Magnus's scheme could support this via more
complicated syntax (e.g. {{{CATEGORY P.M. of Great Britain;1985}}}, or
{{{CATEGORY Comuter science;Algorithms}}}), but that reeks a bit of
overengineering. Plus writers would have to coordinate their efforts
(choose the same subcategorisation, and/or sort order) -- coordination
is easier done on a single page (the category) than across a number of
pages.

So the promise of "just editing one page instead of two or more" is a
fallacy IMO. Even with the extended synatx above, you'd first have to
check out the category page(s) to see the existing layout before you
could sensibly write the correct category link(s).

If one doesn't want to put too much work into categorisation, and
really wants to only let the link show up on the category page in a
random location, my scheme could support this as well. Imagine a "put
this page into this categories" box separate from the normal text edit
box. Putting one or more categories there will add special links back
to this topic onto the end of these pages. They'd be put into a
distinct section, e.g. named "unsorted links". People tending to the
category page can take and move these to a more proper position. I'm
not sure whether we /want/ to support this kind of laziness by the
original authors, though.

Concerns were raised that links from a categorised page to a category
are more easily processed automatically than the other way around. My
response is that this is an implementation detail -- one can always
keep a seperate "backlink" index seperate from the main page texts for
optimisation.

--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020111/a9f429eb/attachment.pgp


subject: [Wikipedia-l] Wikipedia T-Shirt

body:
hi all.

voting on the looks of the Wikipedia T-Shirt has already started. If you're interested please see:
http://meta.wikipedia.com/wiki.phtml?title=Wikipedia_T-shirts

regards,
wojpob

--

Dni odlotowych Cen - promocja biletow lotniczych
[ http://samoloty.onet.pl/ ]


subject: [Wikipedia-l] Search engine bug report

in_reply_to: <r5izo3m71bf.fsf@gill.maths.keele.ac.uk>; from wiki@gwowen.freeserve.co.uk on Thu, Jan 10, 2002 at 02:00:52PM +0000

body:
I think I need to re-run the search engine database update script.

Gareth Owen wrote:

> Searching for 'blues' or 'the blues' (without the quotes) doesn't return the
> page http://wikipedia.com/wiki/Blues, which it probably should :(
>
> (Especially since I received many music reference books I wish to precis as
> Christmas gifts...)
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*********************************************************************
*"The rifle itself has no moral stature, since it has no will of its*
* own. Naturally, it may be used by evil men for evil purposes, but *
* there are more good men than evil, and while the latter cannot be *
*  pursuaded to the path of righteousness by propaganda, they can   *
*  certainly be corrected by good men with rifles." -Jeff Cooper    *
********************************************************************


subject: [Wikipedia-l] Polish Wikipedia and the new software

body:
There were some questions raised about the new software that I'd like to
answer:

Jimbo: I designed the software with international versions in mind, so
there's *no* hardcoded English at all in my current version. There's a
single file (wikiText.php) which contains all the language-specific
functions and texts as PHP variables (all starting with "$wiki"). It also
contains the name of the database for that language, the location of the
logo etc.

Larry: The script will be the same for all wikipedias, except for the file
mentioned above.

Tomasz: Jimbo is right, I didn't worry much about the copyright notice on
the upload page. This will be changed.

Pawel: The PHP code is open for you to study (at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wikipedia/phpwiki/fpw/). I'd
give you write access, but IMO it would be better to wait until the English
Wikipedia is changed to the software and Jimbo set up the CVS repository at
bomis. There'll be an upload page for everybody (like meta.wikipedia.com),
and I'll include a page counter directly into the database soon. The
alphabetically grouped article lists would be nice, too. For the style
differences, I'd suggest we create a "Rozeta" skin (like the Star Trek skin
in the test versions). That way, everyone can choose his/her own favourite
layout. I'm looking forward to work with you on this!

I hope I could clarify most issues. Let's get to work!

Magnus


from_name: David Merrill

subject: [Wikipedia-l] wiki source cvs

body:
The LDP is talking about whether to set up our own Wiki project for
working on HOWTOs. There seems to be quite a bit of interest. I don't
know what will come of it yet. I asked whether they're interested in
using Wikipedia, but I suspect we need real-time updates and stuff
like that, so it wouldn't work very well. Let me know how you feel
about this though. We're still discussing it ourselves.

If we were to do that, we would need the licensing situation finally
established in concrete terms, as well as attribution requirements.
Any really big attribution would be an annoyance, but we'd want to
make sure Wikipedia got a mention in all HOWTOs worked on that way.
The big table would be overkill imho.

But if we do, I would like to use the Wikipedia software. We want to
use the current editing capabilities to output DocBook format, as in:

=Title=

Foo

Bar

becomes:

<sect1><title>Title</title>

<para>Foo</para>

<para>Bar</para>

</sect1>

and so on. How is the software licensed, and can I get access to the
cvs? I don't think I'll need commit rights. I'll fix any bugs I run
into and send a patch if that happens.

Thanks,

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

By the Earth that is Her body
By the Air that is Her breath
By the Fire of Her bright spirit
By the Waters of Her living Womb,
The circle is cast.
		-- Traditional Circle Casting


subject: [Wikipedia-l] wiki source cvs

in_reply_to: <20020112185836.GB29139@lupercalia.net>; from david@lupercalia.net on Sat, Jan 12, 2002 at 01:58:36PM -0500

body:
The software is GPL, and if you use it, you could make the data be any
license you want.  I'm happy to volunteer to host it, but I guess you
guys have plenty of resources in that department already.

I think that your using wikipedia software (the new version) would be good
for everyone.

David Merrill wrote:

> The LDP is talking about whether to set up our own Wiki project for
> working on HOWTOs. There seems to be quite a bit of interest. I don't
> know what will come of it yet. I asked whether they're interested in
> using Wikipedia, but I suspect we need real-time updates and stuff
> like that, so it wouldn't work very well. Let me know how you feel
> about this though. We're still discussing it ourselves.
>
> If we were to do that, we would need the licensing situation finally
> established in concrete terms, as well as attribution requirements.
> Any really big attribution would be an annoyance, but we'd want to
> make sure Wikipedia got a mention in all HOWTOs worked on that way.
> The big table would be overkill imho.
>
> But if we do, I would like to use the Wikipedia software. We want to
> use the current editing capabilities to output DocBook format, as in:
>
> =Title=
>
> Foo
>
> Bar
>
> becomes:
>
> <sect1><title>Title</title>
>
> <para>Foo</para>
>
> <para>Bar</para>
>
> </sect1>
>
> and so on. How is the software licensed, and can I get access to the
> cvs? I don't think I'll need commit rights. I'll fix any bugs I run
> into and send a patch if that happens.
>
> Thanks,
>
> --
> David C. Merrill                         http://www.lupercalia.net
> Linux Documentation Project                   david at lupercalia.net
> Collection Editor & Coordinator            http://www.linuxdoc.org
>
> By the Earth that is Her body
> By the Air that is Her breath
> By the Fire of Her bright spirit
> By the Waters of Her living Womb,
> The circle is cast.
> 		-- Traditional Circle Casting
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*********************************************************************
*"The rifle itself has no moral stature, since it has no will of its*
* own. Naturally, it may be used by evil men for evil purposes, but *
* there are more good men than evil, and while the latter cannot be *
*  pursuaded to the path of righteousness by propaganda, they can   *
*  certainly be corrected by good men with rifles." -Jeff Cooper    *
********************************************************************


body:
I have no _particular_ opinions.  All I want is for our pages to work
in all browsers.  What should I do?

Obviously, there's no way for us to pass all the webpages through a
validator (or, is there?) since end users might well write invalid or
at least not-perfect html.

Lars Aronsson wrote:

> Taral wrote:
> > Well, it says HTML 4 Transitional now, but it's still not right. There's
> > an <hr> inside a <font> tag and the nested <dl> stuff still isn't
> > considered valid. (Mozilla ignores it)
>
> "HTML 4 Transitional" is the standard that I use on my websites, and I
> think it could be a good idea for Wikipedia aswell.  You use W3C's
> validator to check your web pages, and when they pass, you receive
> instructions for how to include a logotype-link at the bottom of each
> page.  See e.g. the yellow W3C logo at the bottom of these pages:
>
>     http://aronsson.se/
>     http://elektrosmog.nu/
>     http://www.lysator.liu.se/runeberg/
>     http://susning.nu/
>
> The latter is a UseModWiki, just like Wikipedia, so it is indeed
> possible.
>
>
> --
>   Lars Aronsson (lars at aronsson.se)
>   Aronsson Datateknik
>   Teknikringen 1e, SE-583 30 Link?ping, Sweden
>   tel +46-70-7891609
>   http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*********************************************************************
*"The rifle itself has no moral stature, since it has no will of its*
* own. Naturally, it may be used by evil men for evil purposes, but *
* there are more good men than evil, and while the latter cannot be *
*  pursuaded to the path of righteousness by propaganda, they can   *
*  certainly be corrected by good men with rifles." -Jeff Cooper    *
********************************************************************


subject: [Wikipedia-l] wiki source cvs

body:
On Sat, Jan 12, 2002 at 06:11:43PM -0600, Jimmy Wales wrote:
> The software is GPL, and if you use it, you could make the data be any
> license you want.  I'm happy to volunteer to host it, but I guess you
> guys have plenty of resources in that department already.
>
> I think that your using wikipedia software (the new version) would be good
> for everyone.

Thanks very much.

If we do in fact go with Wiki (and we're not sure of that) rather than
a simpler "edit this page" we roll ourselves, we will be adding to it
the ability to convert the tags into DocBook. So:

*item
*item
*item

becomes

<simplelist>
<listitem>item</listitem>
<listitem>item</listitem>
<listitem>item</listitem>
</simplelist>

and so on. Might be of use to you someday if you want to publish
something out of Wikipedia in DocBook XML format. Just keep it in
mind.

I've already started such a script, 'cause we'll need it regardless.

> David Merrill wrote:
>
> > The LDP is talking about whether to set up our own Wiki project for
> > working on HOWTOs. There seems to be quite a bit of interest. I don't
> > know what will come of it yet. I asked whether they're interested in
> > using Wikipedia, but I suspect we need real-time updates and stuff
> > like that, so it wouldn't work very well. Let me know how you feel
> > about this though. We're still discussing it ourselves.
> >
> > If we were to do that, we would need the licensing situation finally
> > established in concrete terms, as well as attribution requirements.
> > Any really big attribution would be an annoyance, but we'd want to
> > make sure Wikipedia got a mention in all HOWTOs worked on that way.
> > The big table would be overkill imho.
> >
> > But if we do, I would like to use the Wikipedia software. We want to
> > use the current editing capabilities to output DocBook format, as in:
> >
> > =Title=
> >
> > Foo
> >
> > Bar
> >
> > becomes:
> >
> > <sect1><title>Title</title>
> >
> > <para>Foo</para>
> >
> > <para>Bar</para>
> >
> > </sect1>
> >
> > and so on. How is the software licensed, and can I get access to the
> > cvs? I don't think I'll need commit rights. I'll fix any bugs I run
> > into and send a patch if that happens.
> >
> > Thanks,
> >
> > --
> > David C. Merrill                         http://www.lupercalia.net
> > Linux Documentation Project                   david at lupercalia.net
> > Collection Editor & Coordinator            http://www.linuxdoc.org
> >
> > By the Earth that is Her body
> > By the Air that is Her breath
> > By the Fire of Her bright spirit
> > By the Waters of Her living Womb,
> > The circle is cast.
> > 		-- Traditional Circle Casting
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> --
> *********************************************************************
> *"The rifle itself has no moral stature, since it has no will of its*
> * own. Naturally, it may be used by evil men for evil purposes, but *
> * there are more good men than evil, and while the latter cannot be *
> *  pursuaded to the path of righteousness by propaganda, they can   *
> *  certainly be corrected by good men with rifles." -Jeff Cooper    *
> ********************************************************************
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

Depending on a single company for all future OS innovation and on another
for all future CPU innovation would be tragic for an industry driven by
technology.
	--Tom R. Halfhill, former Byte Magazine Senior Editor


in_reply_to:
<87lmf5vw5v.fsf@orcus.priv.at> (message from Robert Bihlmeyer on
	11 Jan 2002 14:45:16 +0100)

body:
Robert Bilhmeyer wrote:
> "Proper" categories like [[Computer science]]
> are best represented by dividing the listing into subfields (as done
> in the current page). Magnus's scheme could support this via more
> complicated syntax (e.g. {{{CATEGORY P.M. of Great Britain;1985}}}, or
> {{{CATEGORY Comuter science;Algorithms}}}), but that reeks a bit of
> overengineering.

My experience from various wiki shorthand notations is that they
should be easy-to-write.  The major difference between an old style
website and a wiki is that the wiki is written by all, and that this
broadening of the authorship must be met by a simplification in
format.  For example, the choice between plural and singular in
article headings is guided by which is easier to use as a link from
another text, and that most often turns out to be a singular, thus
[[Car]] rather than [[Cars]].

The indicated sort of overengineering should be avoided, not because I
say so, but because it will not be used.  You can try to introduce it,
and then collect statistics on its use, and draw conclusions from the
numbers.  Keep it simple, make it successful.  Even the use of special
{{}} braces seems overly complicated to me.  This is not a programming
language designed for programmers, but a text format intended for
someone who is specializing in entomology or woodcarving.

For a real simple category system, see
http://www.c2.com/cgi/wiki?CategoryCategory

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


in_reply_to:
<20020112181429.C22576@aristotle.bomis.com> (message from Jimmy
	Wales on Sat, 12 Jan 2002 18:14:30 -0600)

body:
Jimmy wrote:
> Obviously, there's no way for us to pass all the webpages through a
> validator (or, is there?) since end users might well write invalid or
> at least not-perfect html.

When I first thought of this, I thought it will never work because you
allow HTML markup inside the user-edited wiki text.  Then I found out
that this is wrong.  Think again!  Each user can run her favorite page
through the validator and fix the HTML code in the user-edited wiki
text until it passes.  All that the system programmers have to do is
to make sure the system-generated HTML code passes through the
validator.  Testing a few pages without user-edited HTML code should
be sufficient for this.  After this, your users will help you find the
remaining bugs.

In the UseModWiki, this code adds a logotype-link to the W3C validator:

sub GetMinimumFooter {
  my $w3c = "";
  if ($FooterNote ne '') {
    return T($FooterNote) . $w3c . $q->end_html;  # Allow local translations
  }
  return $w3c . $q->end_html;
}

You will want to download the valid-html40.png to your own site from
http://www.w3.org/Icons/valid-html40.png

I made a quick test for the German Wikipedia through the validator
(http://validator.w3.org/check?uri=http%3A%2F%2Fde.wikipedia.com%2F&charset=%28detect+automatically%29&doctype=Inline).
The validator assumed the contents was HTML 2.0 (!), because of
the insufficient DTD declaration at the top of the HTML code.

The beginning of the page:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<TITLE>Wikipedia: HomePage</TITLE>

Should look something like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
 "http://www.w3.org/TR/REC-html40/loose.dtd">
<TITLE>Wikipedia: HomePage</TITLE>

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


body:
--- Lars Aronsson <lars at aronsson.se> wrote:
[snip]
> My experience from various wiki shorthand notations
> is that they should be easy-to-write.  The major
> difference between an old style website and a wiki
> is that the wiki is written by all, and that this
> broadening of the authorship must be met by a
> simplification in format.  For example, the choice
> between plural and singular in article headings is
> guided by which is easier to use as a link from
> another text, and that most often turns out to be a
> singular, thus [[Car]] rather than [[Cars]].
>
> The indicated sort of overengineering should be
> avoided, not because I say so, but because it will
> not be used.  You can try to introduce it,
> and then collect statistics on its use, and draw
> conclusions from the numbers.  Keep it simple, make
> it successful.  Even the use of special
> {{}} braces seems overly complicated to me.  This is
> not a programming language designed for programmers,

> but a text format intended for someone who is
> specializing in entomology or woodcarving.
I don't think its that big a problem if the category
syntax is a tad bit complicated. Its not
content-creation, its metadata. The entomologist or
woodcarver who can't understand the category system
can just write their article anyway, and let other
people worry about the category system.

And, how is "{{{CATEGORY ...}}}" any more complicated
than "#REDIRECT"? Not much. Maybe, if we want to make
the syntax more coherent, we could use syntax
"#CATEGORY" instead?

So instead of writing (Bill Clinton article):
{{{CATEGORY Biography, US_Presidents}}
We could write, on a line by itself anywhere in the
article:
#CATEGORY [[Biography]], [[US Presidents]]
In fact, this syntax is probably easier to write than
Magnus', so maybe we could use this one instead?

> For a real simple category system, see
> http://www.c2.com/cgi/wiki?CategoryCategory
When I read this, I had what seemed like a good idea
at first. Why not just adopt Categories as in the
original WikiWiki?

I would suggest though that rather than use CamelCase
to mark categories, lets use a namespace "category:"
or "cat:". Then, a page containing a link to a
category page is in that category.

There is one problem here: what if I want to link to
category X page from page Y, without thereby adding
page Y to category X? We'd need to introduce two
different syntaxes -- one for adding the page to the
category, and one for referring to it. For example, we
could have "[[cat:Dog Breeds]]" to put the current
page in the category "Dog Breeds", and "[[catref:Dog
Breeds]]" to link to the "Dog Breeds" category without
putting the page in it. But how is that any simpler
than Magnus' proposed syntax? If anything it seems
harder, and unless you know the difference between
cat: and catref: one might get them confused, and
accidentally add an article to a category, or just
link to the category when you meant to add to it.

If you look at
http://www.c2.com/cgi/wiki?DiscussionOfCategories,
you'll find that this problem has been discussed
already on WikiWiki. They suggest three solutions: a
link prefix, a separate linking syntax, and do
nothing. A link prefix is what I suggested above, cat:
and catref:. A different linking syntax is basically
the {{{CATEGORY}} syntax Magnus proposed, or the
#CATEGORY syntax I propose above. Doing nothing is not
making a distinction, and including pages which link
to a category in the category. The last is what
WikiWiki does at present. While that might be
acceptable for WikiWiki, I don't think it is
acceptable for Wikipedia.

[snip]
Simon J Kissane

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


body:
--- Lars Aronsson <lars at aronsson.se> wrote:
> Jimmy wrote:
> > Obviously, there's no way for us to pass all the
> > webpages through a validator (or, is there?) since

> > end users might well write invalid or
> > at least not-perfect html.
>
> When I first thought of this, I thought it will
> never work because you allow HTML markup inside the
> user-edited wiki text.
> Then I found out that this is wrong.  Think again!
> Each user can run her favorite page through the
> validator and fix the HTML code in the user-edited
> wiki text until it passes.
[snip]
I can think of another possibility. Since we only
allow a limited subset of HTML tags, and we only
interpret it as a HTML tag if its properly formed
(right?), we are already on the way to producing valid
HTML output. Basically, if the user types invalid HTML
into the wiki page, the software should either
automatically correct it on display, or display it
raw. Thus e.g. "<nonexistenttag>" will be outtputted
to the browser as "<nonexistenttag>", "
"
will automatically have a closing "
" added to it,
and "" will have the
"attributeimadeup" dropped from it.

That way, the output of the script on display will
always be valid HTML, even if the user types bad HTML
in to begin with.

Of course, this will make the parser in the script
more complicated...

In fact, if we wanted to, we could even produce XHTML
output to the browser, and yet take HTML in the page
source.

Simon J Kissane

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


body:
--- Robert Bihlmeyer <robbe+wiki at orcus.priv.at> wrote:
[snip]
> * Why is this scheme better than Magnus's (noting on
> a page itself that it belongs to categories X, Y,
Z)?
>
> Almost no good category list is just a random jumble
> of links.
I both agree and disagree. An organized collection of
links can be useful. But an alphabetical list of
articles in the category can still be quite useful.

I know it might sound like a bit of an overkill, but
we could have both -- we could have organized and
unorganized category pages, the unorganized ones
automatically generated, the organized ones made by
hand. Since we'd only have to maintain one (the
organized one), its really no more work than we have
at the moment.

I think generating category pages to display to the
user is only one use for categories -- there are uses
for software-understood categories as well, like siome
of the uses I and Larry have mentioned in our
respective posts. So a categorisation that doesn't
automatically feed into the category page might still
be useful.

> For example [[Prime ministers of Great Britain]]
> should probably be sorted in chronological
> order.
Ideally, I'd like to have the software understand
objects like "Incumbent", with little fields of data
like "Office, Name, Start Date, End Date"... That way
we could produce little databases of office holders,
etc... They could be used to generate a category,
sorted whichever way you wish. And, since they'd be
databases, the information in them would be easily
available to dumb software (exactly what you'd do with
it though, I don't know.) I've been thinking about
doing this, although its not really a priority at the
moment.

> "Proper" categories like [[Computer science]]
> are best represented by dividing the listing into
> subfields (as done in the current page).
Well, my suggestion was that they would be
subcategories, or independent categories in their own
life... so an algorithm could go in the category
[[Computer Science/Algorithms]], or alternatively in
both the [[Computer Science]] category and the
[[Algorithms]] category. Using a modification of
Magnus' proposal you could display the contents of
multiple categories on the one page.

> Magnus's scheme could support this via more
> complicated syntax (e.g. {{{CATEGORY P.M. of Great
> Britain;1985}}}, or
> {{{CATEGORY Computer science;Algorithms}}}), but
that
> reeks a bit of overengineering.
I think in the case of Algorithms, it makes sense.
Most category systems permit subcategories, so why not
have a "Computer Science/Algorithms" category?

As to the P.M, well, I agree with you that seems a bit
overengineered.

> Plus writers would have to coordinate their efforts
> (choose the same subcategorisation, and/or sort
> order) -- coordination is easier done on a single
> page (the category) than across a number of pages.
I don't envision the primary responsibility for
categorisation necessarily being with the writer of
the page. Writing articles, and categorising them, are
different tasks, and don't need to be done by the same
people. (One is like an author, the other like a
librarian.)

> So the promise of "just editing one page instead of
> two or more" is a fallacy IMO. Even with the
> extended synatx above, you'd first have to
> check out the category page(s) to see the existing
> layout before you could sensibly write the correct
> category link(s).
Well, it depends on how well you know the category,
and how it is organized. If you are thinking of just
assigning things to major categories, like "Physics",
or "Philosophy" and "History", and we are in the
process of assigning 20,000 articles to these major
categories, then just being able to click "Edit this
page", add "{{CATEGORY}}}" and save is a lot simpler.

Simon J Kissane

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


from_name: Laura T.

subject: [Wikipedia-l] another copyright issue

references:
<003e01c16eb4$8b4e07c0$1d7558d9@maximilian>
 <ILENJBCFHGHELEBFPPBGKEFGCEAA.Magnus.Manske@epost.de>
 <003e01c16eb4$8b4e07c0$1d7558d9@maximilian>

body:
Hi everyone,

I haven't been doing much more than skimming the list but I do have a
question about copyrights and Wikipedia. What if someone posts their own
article as a Wikipedia topic? I posted one of my articles which I also gave
to a garden site and posted in my own column at BackWash. I'm the only one
who has a copyright to the article. Was that ok to do?

Hope 2002 is working out great for you,

Laura

PS- Are there no other women taking part in this? I feel a bit like I've
snuck into the boys room. ;)

   ,
  "\",
  "=\=",     http://wz.com/business/ASCIIart.html
   "=\=",
    "=\=",
     "-\-"     ,---,
        \     _)   (_    Now Open...
  ldb    `   [__INK__]  http://www.hercorner.com


subject: [Wikipedia-l] New York Times Magazine writeup

body:
Would it be ok for someone to cut and paste that article into here? I don't
have a subscription to the NY Times Magazine. I'd really like to read the
article.

Laura

>Axel Boldt wrote:
>
> > Today's New York Times Magazine has a long list of ideas which they
> > call "The Year in Ideas". One of those ideas is "Populist Editing",
> > which , you guessed it, is about Wikis in general and Wikipedia in
> > particular. Very positive writeup.
> >
> > http://www.nytimes.com/2001/12/09/magazine/09POPULIST.html
> >

   ,
  "\",
  "=\=",     http://wz.com/business/ASCIIart.html
   "=\=",
    "=\=",
     "-\-"     ,---,
        \     _)   (_    Now Open...
  ldb    `   [__INK__]  http://www.hercorner.com