Mailing List Archive

Whoa,

now that's a surprise -- a guy whose work I like to reference on Wikipedia
and elsewhere shows up on, of all places, the Wikipedia tech mailing list.
Welcome, Sheldon, and thanks for your excellent work with John Stauber on
exposing the corporate PR machinery.

I've often wanted to have more online material of yours that I could point
people to, and perhaps Disinfopedia can become that. Of course, I would
also appreciate it if you could contribute info, when you find the time,
to the "real" Wikipedia. Have you thought about the license you want to
use for your project yet? It's hard to operate a wiki under traditional
copyright, and more beneficial to society not to.

As for your namespace links: It's possible - I would try to reduce the
number of topical namespaces to 3 or 4 to avoid ambigiousness ("where do I
need to go to get information X? case studies? issues? hmm .."). Also, try
to think about good names. People:George W. Bush? Is that a page about
George Bush or a page with links to people related to George Bush? (IMHO
only the latter makes sense, as the page about George Bush should not have
its own namespace, but this is not intuitively clear.)

You will probably also get some redundancy and occasionally irrelevant
links, but that's probably acceptable. Make clever use of redirects to
avoid redundancy. I recommend creating Talk namespaces for every
namespace -- if pages are not large enough to discuss them separately, it
makes no sense to separate them in the first place.

One other way to get the functionality would be to implement HTML anchors
in wiki syntax. That way you could link to [[George W. Bush#people]] to
get to the specific article section. You could also implement page
templates to get a default structure for articles.

On Wikipedia, we have tried to avoid too mechanical categorization
schemes, and so far that works well, too - you just have to structure your
site consistently. Linking is easy on a wiki. With "What links here" and
"Related changes" you can easily get more context for a specific page.

Let me know if you decide to implement the namespace idea and I can
hopefully provide some more detailed recommendations.

All best,

Erik

PS: "Toxic Sludge is Good for You" should really be available as a GNU FDL
e-book. We need to get this book into schools :-)

>now that's a surprise -- a guy whose work I like to reference on Wikipedia
>and elsewhere shows up on, of all places, the Wikipedia tech mailing list.
>Welcome, Sheldon, and thanks for your excellent work with John Stauber on
>exposing the corporate PR machinery.

Tehehe, me too, actually! I was pretty impressed for wikitech-l when
Sheldon appeared. You's a pseudo-celebrity amongst radicals, Sheldon.

>I recommend creating Talk namespaces for every namespace -- if pages are
>not large enough to discuss them separately, it makes no sense to separate
>them in the first place.

I just thought I'd bring up something about talk pages that I've always
thought was kinda stupid. Now, I don't know how this works for the internal
code, and why you guys decided to implement talk namespaces the way you did.
Maybe there's a technical reason of some sort. But anyways...

Why isn't the talk namespace just namespace-aware? Then you'd only have one
talk namespace instead of having to create a talk namespace for every normal
namespace, and then a talk page could be automagically inherent in every
article, without having to explicitly create a talk namespace first. For
example, instead of

[[user_talk:jizzbug]]

if talk were namespace-aware, it would be much more straight forward to
allow

[[talk:user:jizzbug]]

or instead of

[[Wikipedia_talk:Copyrights]]

it'd be

[[talk:Wikipedia:Copyrights]]

I would think that this would actually make the program logic much simpler.
Am I wrong? Then what gives?

Peace out,

Derek

_________________________________________________________________
MSN 8 with e-mail virus protection service: 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf

Eric Moeller wrote:

>Whoa,
>
>now that's a surprise -- a guy whose work I like to reference on Wikipedia
>and elsewhere shows up on, of all places, the Wikipedia tech mailing list.
>Welcome, Sheldon, and thanks for your excellent work with John Stauber on
>exposing the corporate PR machinery.

Thanks! (I'm blushing.)

>I've often wanted to have more online material of yours that I could point
>people to, and perhaps Disinfopedia can become that.

I'm assuming that you've seen the PR Watch web site. We have a fair
amount of material there, including archives of PR Watch dating back
almost to its founding, plus our "Spin of the Day" feature (which
typically includes 10-15 new items each week).

I'm envisioning the "Disinfopedia" as an open source extension of our
"Impropaganda Review" section, which you can find at the following
URL:
http://www.prwatch.org/improp/

Once I have the wiki software tweaked and functioning the way I want,
I'll seed the Disinfopedia with our existing articles from the
Impropaganda Review plus some other similar information, and offer it
under the GNU General Public License. At some future point, we may
choose to do the same thing with other parts of our web site.

> Of course, I would
>also appreciate it if you could contribute info, when you find the time,
>to the "real" Wikipedia. Have you thought about the license you want to
>use for your project yet? It's hard to operate a wiki under traditional
>copyright, and more beneficial to society not to.

I've already made a few minor contributions to the "real" Wikipedia,
and I plan to continue doing so. You've touched here on one of the
questions that I've been wondering about: Should we set up a separate
"Disinfopedia," or just use the "real" Wikipedia as a repository for
the knowledge base I'm trying to develop?

On balance, I think setting up a separate "Disinfopedia" is the way
to go, for the following reasons:

(1) A "Disinfopedia" is likely to be more controversial and contested
than Wikipedia, and the differences are significant enough to raise
compatibility questions. (For example, Wikipedia's ethos regarding a
"neutral point of view" may be harder to maintain in a
"Disinfopedia.")

(2) There isn't a good way to clearly mark off a "Disinfopedia" as a
subset of Wikipedia, and simply posting our material there would
dilute and diffuse its specific focus.

(3) Having a separate Disinfopedia makes it easier for us to offer
guidance on article format and content. For example, I want to
encourage contributors to the Disinfopedia to follow the model we
used in the Impropaganda Review, where each organizational profile
consists of the following sections:
* A general description
* Personnel
* History
* Funding
* Case studies
* Contact information
* Related information resources

>As for your namespace links: It's possible - I would try to reduce the
>number of topical namespaces to 3 or 4 to avoid ambigiousness ("where do I
>need to go to get information X? case studies? issues? hmm .."). Also, try
>to think about good names. People:George W. Bush? Is that a page about
>George Bush or a page with links to people related to George Bush? (IMHO
>only the latter makes sense, as the page about George Bush should not have
>its own namespace, but this is not intuitively clear.)

Excellent points. I'm envisioning the extra namespaces as places for
lists of related links, so People:George W. Bush would be a page with
links to people related to Bush. Also, you're right that we don't
need a separate namespace for "issues."

Perhaps the thing to do would be to simply have ONE additional
namespace, titled "relationships" (plus, of course,
"relationships_talk"). At the bottom of an article on "George W.
Bush," there would be a link to an article on Bush's "Relationships
to People, Organizations, Funders, etc." Assuming the article hasn't
yet been created, the URL would read:
http://www.disinfopedia.org/wiki.phtml?title=Relationships:George_W._Bush&action=edit

Clicking on that page would take people to a textedit form, but
instead of the start text saying "Put your text for the new page
here," it would contain a template, e.g.:

>>Lists of people, events, funding, case studies and information
>>resources related to [[George W. Bush]].
>>
>>== People ==
>>
>>* [[Name1]]
>>* [[Name2]]
>>
>>== History ==
>>
>>* [[Event1]], date
>>* [[Event2]], date
>>
>>== Financial ==
>>
>>* [[Funder1]]
>>* [[Funder2]]
>>
>>== Case Studies ==
>>
>>* [[Article1]]
>>* [[Article2]]
>>
>>== Documentation ==
>>* [[Author]], [[Title]], [url], name of publication, pub date, page

Yet another possibility would be to forego extra namespaces
altogether, and simply post prominent guidelines explaining the kind
of structure we're envisioning. I would hope that people would TRY to
follow our recommended structure, but it would be okay if they
sometimes deviate from it.

>One other way to get the functionality would be to implement HTML anchors
>in wiki syntax. That way you could link to [[George W. Bush#people]] to
>get to the specific article section. You could also implement page
>templates to get a default structure for articles.

Are HTML anchors currently implemented in wiki syntax? Also, how do
you envision implementing page templates? Are you thinking of
something along the lines of the example I gave above?

And what about the idea of creating "pseudo-namespaces"? What I'm
envisioning here is a way of object-typing prospective articles so
that page templates could be customized according to object type. For
example, [[person:George W. Bush]] might create a template with
sections such as date of birth, career highlights, etc., whereas
[[organization:Cato Institute]] might create a template with sections
such as personnel, funders, publications. Has there been much
discussion about ways of integrating Wiki's free-form approach with
XML-style object-typing and data-structuring?

>PS: "Toxic Sludge is Good for You" should really be available as a GNU FDL
>e-book. We need to get this book into schools :-)

Personally, I'd be interested in seeing this happen, but "Toxic
Sludge" was published by a commercial press, and I don't know how
they'd feel about releasing it into GNU space.

On a related tack, I've been toying with the idea of writing my NEXT
book as an open source project from start to finish. We would begin
by posting a chapter outline and letting anyone edit, contribute and
annotate while we write. Do you think this would work? Would it be
possible to publish the book commercially and get it into bookstores
if the writing process took place within a GNU framework? Would the
GNU license be necessary to attract collaborators?
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------

>On a related tack, I've been toying with the idea of writing my NEXT book
>as an open source project from start to finish. We would begin by posting a
>chapter outline and letting anyone edit, contribute and annotate while we
>write. Do you think this would work? Would it be possible to publish the
>book commercially and get it into bookstores if the writing process took
>place within a GNU framework? Would the GNU license be necessary to attract
>collaborators?

Wow! That'd be really keen. With you and whoever else as editors and/or
primary authors, you'd obviously have veto power over what changes get
included, what changes get reversed, etc. If you managed to draw enough
people to the project, I can't even begin to imagine the possible quality of
the end result. When I'm reading books, I seem to find /all/ the typos,
misspellings, and punctuation errors. I guess most books don't get very
meticulous proofreadings (I have to read and digest every single word fairly
slowly when I read, so my reading of a book does equal an insanely
meticulous proofreading). Plus, I imagine such a project would likely
attract fairly intelligent individuals. Having a number of acute minds
contribute to the text would likely bring to the project more depth and
scope, with people suggesting nuances, perspectives, and angles that the
authors probably wouldn't have thought of otherwise.

I'd certainly be interested in meaningfully contributing. And if you
managed to advertise the project in the right channels, imagine the people
that might drop by to throw in their two cents: Noam Chomsky, Howard Zinn,
Ralph Nader, Jello Biafra, Greg Palast, Naomi Klein, Michael Parenti, RMS,
countless anti-globalization kiddies (I use 'kiddie' in a good sense here,
as I'm one of 'em), old peaceniks, numerous academics from around the world,
etc. I don't see how you could go wrong.

So long as a history of all changes is kept, and so long as the
authors/editors review all changes, I don't see how anything bad could come
of the venture. (The part about authors/editors reviewing all changes
shouldn't be too bad, as such a project certainly wouldn't have the volume
of contributions as Wikipedia.)

And I don't think a GNU license would specifically be necessary. I,
personally, would like to see a GNU license, 'cause I'm a big fan of RMS,
and I've been a GNU kiddie since I was 15 or so. But there are plenty of
good GPL-ish (or at least BSD-ish) licenses out there that people respect:
Open Content License, Open Publishing License, Artistic License, or roll
your own, etc.

Peace out,

Derek

_________________________________________________________________
MSN 8: advanced junk mail protection and 3 months FREE*.
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_3mf

Derek Moore wrote:

>Tehehe, me too, actually! I was pretty impressed for wikitech-l when
>Sheldon appeared. You's a pseudo-celebrity amongst radicals, Sheldon.

Great! Does that mean I get groupies? ;)

Wikipedia is a natural place for me to show up. For one thing, I've
always been a bit of a computer hacker. (I founded the computer club
at my high school and got suspended from school once for hacking into
a university computer so I could learn COBOL.) Also, my last book
with John Stauber was titled "Trust Us, We're Experts: How Industry
Manipulates Science and Gambles With Your Future." We did a lot of
writing and thinking about the scientific method and the influence of
funding on research outcomes, and also about the nature and
limitations of academic peer review. I recently adapted part of
"Trust Us" for a medical journal, and when they asked me to offer
solutions for some of the problems that we posed, the best answers I
could come up with were: (1) better standards of disclosure regarding
funding and other possible conflicts of interest related to published
research; and (2) maintaining and expanding an "information commons"
in which research results are treated as public property and kept
freely available to everyone. One of the big problems for the
integrity of research these days is that corporate-sponsored research
tends to produce proprietary knowledge, which inhibits full
publication of data, methodology and other information. Companies
have good reasons from their point of view for not wanting to release
discoveries that they have paid for and from which they hope to
profit. However, there have been cases where companies have
deliberately suppressed data showing that their products are unsafe
or ineffective. Even where this sort of misconduct isn't occurring,
restrictions on proprietary information present a barrier to full
vetting and sharing of research results.

Believe it or not, I actually thought I was coming up with a new idea
when I first used the term "information commons." I was familiar with
the concept of open source software, but I hadn't really given the
concept much attention other than to think it might be nice if the
same approach could be adapted to things other than computer
software. Then last month I attended a conference in Amsterdam where
I heard about Wikipedia for the first time and thought, "Damn! These
people are already doing it!"
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------

Sheldon,

I presume the conference where you heard about Wikipedia was the World-
InfoCon. If so, did you by any chance hear about it on day two from Volker
Grassmuck? He's a friend of mine, and a couple of weeks before the con he
called me and asked me about cool projects in the area of collaborative
journalism and peer-to-peer networks. I told him about Wikipedia, and he
promised to bring it up at the conference. If that's where you heard about
it, I can take at least some small credit for you being here now :-)

> I'm assuming that you've seen the PR Watch web site. We have a fair
> amount of material there, including archives of PR Watch dating back
> almost to its founding, plus our "Spin of the Day" feature (which
> typically includes 10-15 new items each week).

I knew about the news items, but I didn't know Impropaganda Review. Very
good resource. The advantage of a Disinfopedia is, of course, that as a
collaborative/interactive project, it would attract more attention and
could quickly become a central meeting point for people interested in the
subject.

> Once I have the wiki software tweaked and functioning the way I want,
> I'll seed the Disinfopedia with our existing articles from the
> Impropaganda Review plus some other similar information, and offer it
> under the GNU General Public License. At some future point, we may
> choose to do the same thing with other parts of our web site.

As Derek pointed out, the GPL may not be the best choice, as it was
written for software and contains many software-specific clauses. The GNU
Free Documentation License (FDL) is more specifically tailored towards
documents, and that's why the Wikipedia project uses it. It would also
make Disinfopedia articles compatible with Wikipedia (license
compatibility is a big issue).

See
http://www.wikipedia.org/wiki/Wikipedia%3ACopyrights
for details.

Of course you could also be really hip and use the brand new open content
license generator by the Creative Commons Project:

http://www.creativecommons.org/

Caveat, though, as such a license *may* render Disinfopedia content
incompatible with Wikipedia.

> I've already made a few minor contributions to the "real" Wikipedia,
> and I plan to continue doing so. You've touched here on one of the
> questions that I've been wondering about: Should we set up a separate
> "Disinfopedia," or just use the "real" Wikipedia as a repository for
> the knowledge base I'm trying to develop?

I think a Disinfopedia is just fine, for the reasons you mentioned. NPOV
allows people with vastly different views to work together, but it also
means that an article about, say, the Cato Institute will include glowing
comments from libertarians. Wikipedia doesn't "care" much if these
statements are correct or wrong, only if they are attributed to their
adherents. This may not be what you want if you need to refer people to a
quick summary of the facts. Also, articles are more likely to be
completely rewritten, making them less reliable as a reference.

On the other hand, many articles, such as the Global warming article,
would benefit greatly from a more detailed discussion of the PR wars
surrounding the subjects in question. This needs not be done by you if the
Disinfopedia license is compatible with the Wikipedia license.

> Perhaps the thing to do would be to simply have ONE additional
> namespace, titled "relationships" (plus, of course,
> "relationships_talk"). At the bottom of an article on "George W.
> Bush," there would be a link to an article on Bush's "Relationships
> to People, Organizations, Funders, etc." Assuming the article hasn't
> yet been created, the URL would read:
> http://www.disinfopedia.org/wiki.phtml?title=Relationships:George_W._Bush&ac
> tion=edit

In that case, I would be in favor of ditching the idea altogether, as the
relationship stuff could just as well be embedded into the main articles.
As you say:

> Yet another possibility would be to forego extra namespaces
> altogether, and simply post prominent guidelines explaining the kind
> of structure we're envisioning. I would hope that people would TRY to
> follow our recommended structure, but it would be okay if they
> sometimes deviate from it.

This is one of the problems we are currently facing with the brand new
Wiktionary spin-off project:

http://wiktionary.wikipedia.org/

Dictionary articles are much more structured, and keeping that structure
somewhat consistent has been fairly difficult, owing in large part to the
fact that we have pretty much defined it as we went along with the
project. Make sure you define any policies before you launch, and to
prominently link to them on the editing page.

Regarding templates, you nailed it: They would probably be best namespace-
dependant. Create a new article, and you get the standard article
template. Create a new talk page, you get an empty page. If you use more
namespaces, you can use more templates. But remember that for any new
namespace you have, linking gets more difficult.

Alternatively, you could do all sorts of javascripty stuff on the edit
page (buttons to insert standard text blocks), but I think this would be
too browser-dependant.

>> One other way to get the functionality would be to implement HTML anchors
>> in wiki syntax. That way you could link to [[George W. Bush#people]] to
>> get to the specific article section. You could also implement page
>> templates to get a default structure for articles.

> Are HTML anchors currently implemented in wiki syntax?

HTML anchors are not yet implemented, but this is a project I'd be willing
to tackle. We just need a nifty syntax.

> And what about the idea of creating "pseudo-namespaces"? What I'm
> envisioning here is a way of object-typing prospective articles so
> that page templates could be customized according to object type. For
> example, [[person:George W. Bush]] might create a template with
> sections such as date of birth, career highlights, etc., whereas
> [[organization:Cato Institute]] might create a template with sections
> such as personnel, funders, publications. Has there been much
> discussion about ways of integrating Wiki's free-form approach with
> XML-style object-typing and data-structuring?

Not really, also because we don't really need that much default
structuring on Wikipedia (although having consistent names and style for
links, bibliography etc. would help). Do I understand you correctly when I
assume that when you want a link like [[person:George W. Bush]], you want
to later be able to link to this page by just using [[George W. Bush]],
but use the "person" prefix during page creation to choose a proper
template? In that case, the question would arise what would happen to this
qualifier after the page has been created.

If you want more templates without more namespaces, you could also insert
an extra step during page creation:

Choose a template

Person
This template contains the following ..
Company
...
...

Since page creation is not as common as page editing, I think the extra
step wouldn't be too high a price to pay. As an added bonus, you could
alter the table structure of cur, old etc. to store the template class
just in case you want to evaluate it for anything else.

>> PS: "Toxic Sludge is Good for You" should really be available as a GNU FDL
>> e-book. We need to get this book into schools :-)

> Personally, I'd be interested in seeing this happen, but "Toxic
> Sludge" was published by a commercial press, and I don't know how
> they'd feel about releasing it into GNU space.

You could propose a deal, like asking for donations on the ebook page (I
could send you some data that supports the donation model) and giving the
publisher a certain percentage of those donations. You would probably have
a stronger case once the book is out of print, but there's virtually no
data that suggests free online availability would lead to a decline in
print sales -- rather the opposite. See, for example:

http://www.baen.com/library/palaver6.htm
http://www.baen.com/library/palaver7.htm

Try to think like a PR drone -- how can you sell this idea to a publisher?
;-)

> On a related tack, I've been toying with the idea of writing my NEXT
> book as an open source project from start to finish. We would begin
> by posting a chapter outline and letting anyone edit, contribute and
> annotate while we write. Do you think this would work? Would it be
> possible to publish the book commercially and get it into bookstores
> if the writing process took place within a GNU framework? Would the
> GNU license be necessary to attract collaborators?

Yes, I think it would work, but you need to do a lot of editing to keep
the thing consistent. Be sure to name some volunteers as copyeditors to
maintain this consistence. Also, wikis typically evolve a non-linear
structure -- if you want to avoid this, start with a linear skeleton and
discourage the creation of too many new pages.

If the book is profitable, you are sure to get inquiries from contributors
about the distribution of profits. Most agreeable would probably be a
solution where any and all profits are donated to a single charity agreed
upon by all participants.

The GNU license is not necessary and there are others, but I see no reason
not to use it, since it works.

There are some publishers who might be interested in such an undertaking.
O'Reilly has published a few open content books, and not everything
O'Reilly publishes is computing-related, although some connection to the
world of computing and the Net would help to get them interested. Baen
Books provides many books for free download (not open content), but I
think they only do fiction.

Publishing on demand only costs the author a few hundred dollars and
guarantees a virtually unlimited supply (no further charge per book).
Personally I think this would be the most interesting option, but it is
also the most radical. Prices and quality vary greatly here, but it's not
hard to find reviews and I'm sure there are attractive options.

There's also traditional self-publishing. You may wish to read the article
"Adventures in Self-Publishing" on Kuro5hin and possibly contact the
author:

http://www.kuro5hin.org/story/2002/4/12/223216/520

K5 is another highly interesting collaborative writing / discussion site,
BTW, with articles and comments being voted on by readers. Now if you
really want to do something revolutionary, you could transform the PR
Watch website into a combination of a Scoop-powered collaborative weblog
and a Wikipedia-based wiki. :-) It's this combination of weblogs and wikis
that I'm highly interested in; one of my pet projects is to implement a
wiki as part of the Scoop engine that K5 uses.

All best,

Erik

>>>One other way to get the functionality would be to implement HTML anchors
>>>in wiki syntax. That way you could link to [[George W. Bush#people]] to
>>>get to the specific article section. You could also implement page
>>>templates to get a default structure for articles.
>
>>Are HTML anchors currently implemented in wiki syntax?
>
>HTML anchors are not yet implemented, but this is a project I'd be willing
>to tackle. We just need a nifty syntax.

Actually, there really shouldn't need to be any special syntax for anchors.
98% of the time, you'd want an anchor at your headings and nothing more
(well, maybe at your media, too). That should be as simple as modifying the
wiki syntax parser. For headings, if the heading was "External links" the
anchor's name could be something like "#external_links" or "#External_links"
or "#External links"... What do you think, should anchor names be
lower()'d? Should their spaces be translated to '_' and their punctuation
ignored? I tend to think "yes" to both questions. Media embedded in
articles could also probably benefit from anchors. Again, no need for
additional syntax--it ought to be automagic. Anchor names for media could
just be the media's filename.

<plug>By the way, for those interested in new and improved wiki syntaxes,
check out Wikitax:
<http://meta.wikipedia.org/wiki/Wikitax>
<http://meta.wikipedia.org/wiki/Talk:Wikitax>
Erik, Tomasz, and Nemo have contributed some excellent ideas to the syntax
so far, and everybody else interested is encouraged to do the same. I,
personally, tend to think the wiki syntax could use plenty of revamping. If
you tend to think so, too, stop on by and add your ideas, etc.</plug>

Peace out,

Derek

_________________________________________________________________
MSN 8 with e-mail virus protection service: 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf

Erik Moeller wrote:

>I presume the conference where you heard about Wikipedia was the World-
>InfoCon. If so, did you by any chance hear about it on day two from Volker
>Grassmuck? He's a friend of mine, and a couple of weeks before the con he
>called me and asked me about cool projects in the area of collaborative
>journalism and peer-to-peer networks. I told him about Wikipedia, and he
>promised to bring it up at the conference. If that's where you heard about
>it, I can take at least some small credit for you being here now :-)

You're right, it was at the World-InfoCon, from Volker Grassmuck.
Actually, though, several speakers at the conference talked about
Wikipedia.

>HTML anchors are not yet implemented, but this is a project I'd be willing
>to tackle. We just need a nifty syntax.

How about just including them with section headers? For example, take
the following line of wiki syntax:

=== Geography and Climate ===

Right now this produces the following HTML:

<h3> Geography and Climate </h3>

It shouldn't take a lot of work to make the same wiki syntax produce
the following HTML:

<a name="Geography_and_Climate"><h3> Geography and Climate </h3>

This implementation would only make it possible to insert HTML
anchors at the beginning of section headers, but that should cover
most of the places where people might want to have them. Then to
create a hyperlink to the "Geography and Climate" section of the
"Russia" article, you'd simply use the following syntax:

[[Russia#Geography and Climate]]

>Do I understand you correctly when I
>assume that when you want a link like [[person:George W. Bush]], you want
>to later be able to link to this page by just using [[George W. Bush]],
>but use the "person" prefix during page creation to choose a proper
>template? In that case, the question would arise what would happen to this
>qualifier after the page has been created.

Yes, that's true. The specifics of my proposed implementation are
half-baked. The broader concept, though, is the idea of being able to
object-type articles as a way of imposing some kind of structure.
Maybe this is just fundamentally antithetical to the free-form nature
of Wikipedia, but I see that someone else is thinking along rather
similar lines with the proposal for a "Slotipedia."
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------

> How about just including them with section headers? For example, take
> the following line of wiki syntax:

That seems to make sense. I'll give it a try and post an update.

> Yes, that's true. The specifics of my proposed implementation are
> half-baked. The broader concept, though, is the idea of being able to
> object-type articles as a way of imposing some kind of structure.
> Maybe this is just fundamentally antithetical to the free-form nature
> of Wikipedia, but I see that someone else is thinking along rather
> similar lines with the proposal for a "Slotipedia."

It's a reasonable feature to support, the question is whether it can be
done in an easy to use and consistent fashion.

Regards,

Erik