Jimbo asked if he should create meta.wikipedia.com and I said "yes." I
don't know when it will be created, but it should be fairly soon.
This will help us test both the installation and the operability of the
new software in a live situation, not just a "test" situation. If we
like, we can always move the stuff back to a "discussion:" or
"commentary:" namespace on www.wikipedia.com. But it might turn out that
we'll like it just fine as it is.
When the wiki is up, we'll let you know.
Larry
I don't really think the idea of moving commentary out
of Wikipedia will work. The problem is that no hard
line can be drawn between "policy discussion" and
"discussion about the articles". It is easy for a
discussion about "what belongs in this article" to
degenerate into "what is wikipedia's policy on this
matter" to "is wikipedia's policy a good idea".
Again, if you propose to keep "official policy pages"
in Wikipedia, then people will want to comment on them
-- suggest additions or clarifications, or disagree
with the policies themselves. The most natural place
for them to do so would be [[Wikipedia
policy/Talk]]... And you wouldn't want to get rid of
[[Wikipedia policy/Talk]], because what if they are
only asking questions like "can anyone think of a way
of making the third paragraph clearer... i have
trouble understanding it", which really do belong in
[[Wikipedia policy/Talk]], not on "metawikipedia"...
With all due respect, I think Larry is overeacting to
some recent disputes. Cutting all commentary out of
Wikipedia is IMHO too radical a response. I think the
solution here isn't structural change to Wikipedia,
its trying to resolve the disputes at issue. (Which I
don't think any of those involved, myself included,
have done good enough a job of trying to resolve.)
Simon J Kissane
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
> Are ther compelling reasons why software shouldn't convert
> [[algebra]]ic into a link, exactly like [[algebra|algebraic]]...
I could go either way on that one too. It's a bit "automagical",
but it doesn't seem too dangerous.
I would at least implement it this way: rather than munging the
source text on save (not generally a good idea), just render it
at display time. That's basically just moving the /A tag to the
end of a full word (or beginning, in the case of prefixes).
There ought to be some way to force the old behavior, though.
For example, there's a page "ism" and page "phage". You might
want to have creation[[ism]] link to the "ism" page describing
such systems of belief in general (or similarly, bacterio[[phage]]),
but highlighting the whole word would be wrong in that case.
0
Jimmy Wales <jwales(a)bomis.com> writes:
> Currently:
> [[work]] shows _work_ (underlined, see?) and links to [[work]].
>
> [[work|working]] shows _working_, and links to [[work]]
>
> [[work]]ing shows _work_ing and links to [[work]]
>
> Your objection seems to be that #2 is more commonly what we want, but
> more typing, and #3 is easier, but not often wanted.
Yes, thats exactly right.
Heres how Gaz's Perfect Wiki would work...
[[work]]ing shows _working_, links to [[work]]
[[work|working]] shows _working_, links to [[work]] (backwards compatible)
[[work|]]ing shows _work_ing, links to [[work]]]
^
|-- Any uncommon ASCII character will do. `|' seems reasonable since it
already has a special meaning, but one that makes no little or no
sense in this context
--
Gareth Owen
"Wikipedia does rock. By the count on the "brilliant prose" page, there
are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)
<lsanger(a)nupedia.com> writes:
> And let me apologize for making a decision when there were still plenty of
> people wanting to talk.
>
> But the decision has been made.
Fair enough Doesn't really bother me.
So when subpages disappear, whats going to happen to all the subpages with
worthwhile content on?
--
Gareth Owen
"Wikipedia does rock. By the count on the "brilliant prose" page, there
are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)
The #PARENT and #CHILD discussion is making my system designer's
skin crawl. I already said this once at
http://www.nupedia.com/pipermail/wikipedia-l/2001-November/000764.html,
but indulge me as I me repeat it again:
I would like to see wiki software that allows for enumeration
of generic terms that would trigger navigation links to
appear on article pages automatically. It's a natural
consequence of [[Wikipedia is not paper|Wikipedia not being
paper]]. Using the baseball articles as examples, "baseball"
should be tagged as one of those generic terms. Then any page
with "baseball" in the title would get a link to the
[[Baseball]] article, and the [[Baseball]] article would list
links to all the other baseball articles.
Now, allow me to elaborate.
Let's create a page in the new wiki called [[special:generic
terms]]. Then we simply edit that page and add generic terms to
the list -- a simple enumeration of [[free links]] like this:
[[World War II]]
[[Baseball]]
[[Afghanistan]]
[[Colorado]]
etc.
This effectively defines the set of articles that are "parent"
articles.
So all pages listed on this special page are handled specially by the
wiki software. If you edit [[Baseball]], the software looks up all
articles that have the generic term "baseball" in the
title. (Encyclopedias are distinguished by their meaningful titles, so
this shouldn't be a problem -- regardless of whether the page is
[[History of Baseball]] or [[Baseball History]].) Back to the
example. The software finds all articles whose titles include
"baseball," and the [[Baseball]] article gets an automatic link to
them. Job done. Similarly, the [[History of Baseball]] page gets an
automatic
link to [[Baseball]] ''because'' we put [[Baseball]] on the
[[special:generic terms]] page. No one has to remember to add #PARENT
and (aack) #CHILD links. It's all associated automatically by
''title'' with the simple addition to a list of generic terms--terms which
have so far tempted people to create subpages.
This works nicely for [[Colorado Springs]] (by an accident of
naming) but also for [[Denver, Colorado]]. Because both have
"Colorado" in their title, they are flagged as "children" of
[[Colorado]], and [[Colorado]] would automatically be updated to
link to them when these new "child" page titles are defined.
Ah, but it breaks down when you want to write an article called
[[Battle of Britain]] or [[D Day]], doesn't it? No World War II
to be found in those titles. (Both are better encyclopedia titles
than [[World War II/Battle of Britain]] and [[World War II/D
Day]] IMHO.) So let's add another intuitive feature to the wiki
software: a "see also" section. Let's say the convention is that
in any article, all [[free links]] that appear between the words
"see also:" on themselves on a line (the Perl regexp is /^see
also:$/i) and a horizontal line will be indexed sort of like
children as well.
So [[Battle of Britain]] would look this:
The '''Battle of Britain''' began on August [[1940]]. [sic]
After the [[France|French]] collapsed under the [[Blitzkrieg]]...
...
See also:
[[World War II]]
----
Then any article mentioned in any other article's "see also"
section would receive preferential treatment in the backlink
feature that I mentioned in
http://www.nupedia.com/pipermail/wikipedia-l/2001-November/000751.html.
The backlink on each article page could have a very intuitive
name, like "Show all articles that mention this one." Then you
get the list in two sections. If you clicked on it for [[World
War II]], the first section would be intuitively titled, "All
Articles that Refer to "World War II" In the See Also Section"),
and the second section would be titled, "All Articles that Refer
to "World War II" Anywhere in the Body of the Article").
These two techniques are both intuitive and relatively easy to
implement in wiki software.
<>< [[tbc]]
Simon suggests some sort of integration between plantemath.org and
Nupedia/Wikipedia.
All three projects are GFDL'd, so collaboration is easy (planetmath
requires no invariant sections). No work is ever lost. I don't see a
need for tight integration, and as Simon pointed out, the projects
differ in several respects. Whatever good content they produce at
planetmath we will use; whatever good content we produced at wikipedia
they can use. Everybody wins it seems.
Planetmath has however vastly superior math typesetting support since they
integrate LaTeX. I am pretty sure that eventually a feature like that
will be available on Wikipedia as well: you type
$$ \sum_{i=1}^n i^2 $$
into a wiki article and TeX will convert the formula behind the scenes
into a graphic to be included in the page. That would also be useful
for chemical structure formulas and drawings. Such a system, called
mathwiki, is running at http://www.mathcircle.org/cgi-bin/mathwiki.pl.
The code is based on Cunningham's wiki.
Axel
You Wrote:
>OK, so we have a bit of overlap. That's a lot better than having a
lot of
>incendiary debate cluttering up the Recent Changes page.
By far. The Recent Changes page has been a disheartening mess lately.
After being away awhile and coming back to check Recent Changes, I
saw mostly bickering and suddenly didn't miss wikipedia at all.
[snip]
>away from the main wiki. What's radical about that? Commentary is not
>what Wikipedia is about. We are not here to talk about writing an
>encyclopedia; we're here to write one.
Preach on, brotherman. ;-)
kq
0
>[[Saturday_Night_Live/Generalissimo_Francisco_Franco_is_still_dead]]
>...
> In the second case, the main page serves to set the context of the
> subpage in a really nice way. Anyone stumbling into the subpage
> would probably be interested in visiting the main page.
Yes, that's the one use that subpages really make sense for: small
topics that _only_ make sense in the context of a larger topic.
But sacrificing that small utility to avoid more serious problems
isn't that drastic, I think. My personal preference would be to live
with longer articles (just include those short things within the main
article). Accidental links aren't an issue here, precisely because
these topics are context-dependent.
>> As soon as we move to Magnus' software, the obvious solution
>> will be [[Nirvana (rock band)]], etc.
>But how, exactly, is this really different from, let's say
>[[Nirvana/Rock band]]?
Because "Nirvana/Rock band" forcibly encodes an association between
the rock band and the concept "Nirvana" that's not appropriate. If
there were some relationship, we could still link back to it; if there
is no relationship at all, we remove the author's choice.
> I think it makes them easy to *guess*, though. And that's pretty
> important. [[History of Baseball]] or [[Baseball History]]? Hard
> to guess which it might be. But [[Baseball/History]] -- at least
> it is a system.
But Larry's right here--allowing subpages just makes three things
you have to guess among rather than two. Personally, "History
of Baseball" is the first thing I'd assume, because that's what it
would be in a paper encyclopedia.
> You might suggest: [[Baseball (History)]], but then I would respond
No, parentheses are for context to disambiguate the main term,
not for sub-domains. Again, there's already a standard body of
knowledge for how to do this: real encyclopedias. I'm the first
to point out that we aren't constrained by paper here, but there's
no reason we can't learn from the existing scholarship about how
to organize and title knowledge. This has been going on for a
long time, and they're very good at it.
> what's the difference? And shouldn't this page link to the main
> [[Baseball]] page, automatically? One would think so.
"Automatic" things are great when they are things that a stupid
computer can figure out. Associations between ideas are at the
bottom of that list. Human beings should determine those.
> Won't any convention "force" or "direct" us to think in certain
> ways? I hardly see this as an objection against this _particular_
> convention.
Conventions are chosen freely; yes, they force you to think
certain ways, because we have chosen them to do just that. We
need more conventions. But we can also break them if we choose.
Hard-coding things in software is harder to rebel against.
Sure, subpages are handy for some things (I use a lot of them).
But they don't really do much that we can't do anyway, and they
have at least one serious problem: that they enforce inappropriate
conceptual relationships. I think that's 10 times as important
to get rid of than any mere convenience they might have.0
>I do not support this call for a vote; however, we ''do'' need enough
>Wikipedians to unequivocally get behind a course of action (or to say
>they want to take no action) so that the whole community can see that
>consensus has been reached.
>
>And so here's my declaration. I am in favor of creating a wiki based
>on Magnus' PHP software at http://meta.wikipedia.com/ that hosts all
>meta-discussions (commentary, personal pages, etc.).
>
>When the metapedia comes online, I will do my part to move commentary
>from www.wikipedia.com to meta.wikipedia.com and to keep it there.
I'm all for this as well. I have already moved my commentary to
my personal site (where I'm building my own Wiki), and I'll make
pointers to it or whatever is appropriate on the new system.
0