Main Page | Recent changes | View source | Page history

Printable version | Disclaimers | Privacy policy

Not logged in
Log in | Help


From dKosopedia


Principle of Namespaces (?)

As far as I can tell, in general, namespaces are for cases in which you want to have alternate articles on the same target (you have X and talk: about X) and you also have namespaces if you might have a name collision, that is, you might have History:California since you can have history about anything, and this is different from a discussion, espc in a reference for contemporary issues. (Note: that's just an example, I don't think we need a history namespace... we can do this with naming convention, eg: HistoryOfCalifornia). Just saying for reference or alternately to solicit contradiction.

Oh, gosh, I forgot to comment on "HistoryOfCalifornia" earlier! History of California works just fine, and is recommend to increase the number of occasions where the title of the article can be used in running text without further ado. For the same reason, a reference to history of California is treated by MW as indistinguishable from the captital-H version.
The title-"pipe" construction is available for case where the title doesn't flow in nicely, e.g. [[History of California|history of northern California]] is rendered as
history of northern California
but that other style (maybe called "CamelCase"?) is an unnecessary burden.
--Iks(TkPg) 12:27, 20 Jun 2004 (PDT)
--Pyrrho 12:50, 21 Jun 2004 (PDT) The "CamelCase" is my programmer side Ikswazi, I agree, better to have the spaces. btw, I love that term for it... CamelCase :)
--DRolfe 19:41, 28 Jul 2005 (PDT) My bunch has always called this EmbeddedCaps, but CamelCase is much wittier. :-D Anyhow, MediaWiki will let you link stuff without the namespace using a special pipelink shorthand. In the example case a link [[History:California|]] and [[California]] would both appear as California. The 'empty pipe' trick chops off all namespacing to the left, and all typing to the right. That is [[California (movie)|]] would also look like California, all three of these links would go to different places though; repectively History:California, California, and California (movie). I would have liked a namespace for Kossary to avoid collisions from real articles and snarky definitions ... but I guess that could be changed later, whenever, if at all.

Here's a different take on Namespaces, based on experiences with Wikipedia (WP): IMO, the thrust is more to separate the content from the infrastructure.

Note that according to the above, the current discussion belongs on

dKosopeida talk:Namespaces


dKosopeida talk:Namespace

since WP policy is to avoid plural titles where feasible). By this logic,


should mention what namespaces exist on dP (dKosopedia), and that so far, we are not proliferating namespaces. A summary of the reasons for this & other such decisions would also be part of the presentation of the policy decision, but preservation of the whole record of how we got there is more appropriate to this talk page.

Most of the Namespaces are distinctively handled by the MW engine:

This article is a stub. You can help dKosopedia by expanding it.

MediaWiki talk:Stub

(or edit it, and explain your reasons there)

I'll say more later, including what a great idea the dP innovation of the Vote: Namespace is, and why I expect to push for WP adopting it!

--Iks(TkPg) 00:10, 20 Jun 2004 (PDT)

--Centerfielder 09:21, 20 Jun 2004 (PDT) Very nice, Iks, thanks. I don't disagree with anything here, and think this should be the start of an article explaining our Namespace structure. I've come around to liking the "Vote:" idea; last night I got a start on a tallybot, and if all the Vote page titles start with "Vote:" then the tallybot's job is a lot easier. (Although it's not a truly different namespace because the cur_namespace field is still 0, but the tallybot can still handle it.)

Tnx, CF, that kind of confirms something I just speculated in my other rant, on Talk:MemeTank#New Discussion, before noticing you had responded here. Maybe some of that should also be folded into the dKosopedia: page you are talking about.

I also referred there to the "chief dKP software guru", which I also suspected was you, and which I now believe more strongly. It's probably worth asking you what you think your title is; on WP, it's not clear there there is one, with the functions apparently shared among the developers (designers and coders) of the MediaWiki server software, so I don't even know what to suggest.

Vote namespace

The reason I like the idea of a Vote: namespace is that IMO it could be built into the MediaWiki server software [after the fact addition by Iks(TkPg) 12:27, 20 Jun 2004 (PDT)] as a near-mandatory namespace (as MediaWiki: is probably mandatory and Template: is so valuable that it's hard to imagine why anyone running MW 1.3 would want to shut it off). IMO, voting is probably so inherant in Wikis that it is worth supporting with single purpose software, instead of relying on adapting the Wiki-editing mechanisms. Besides

there could be

Tho this is grossly premature, I'm beginning to look forward to the prospect of supporting you as a new MediaWiki developer!
--Iks(TkPg) 12:03, 20 Jun 2004 (PDT)

--Pyrrho 13:04, 21 Jun 2004 (PDT)
Ikswazi, yes this is Centerfielder's site, I hope we will help develop, I'm certainly game for that and eager except I've been too busy at work to worry about coding in my spare time and will continue to be until august, (fortunately for me my busy-ness in july is a vacation! :).
Centerfielder-- if you get anywhere with the vote tallying in the next month or so... we'll need to share code, I absolutely want to work on this and probably not duplicate effort (I'm still wondering if I want to write this stuff in C++... but if you start something in PERL, I'd probably take the path of least resistance and help you with it). I agree with Ikswazi that there is a lot of stuff for bots to do for a dkos version wiki. Glad to see you guys coming around to a "Vote:" namespace (pseudo or otherwise... it was a bit difficult to generate discussion about when the wiki was in it's formative stage... but I was sure we would come to need and want such a space and the automation, such as vote counting, relating to it)
On Integration with MediaWiki of vote tallying bots, etc: I think this should be separate code. It may make sense for MediaWiki to have a special interface besides the editing interface, i.e. a more efficient way of allowing access by the bots, but the main thing is it should be separate from the installed software for several reasons.
  • because it needs to be controlled by external people, e.g. if there is a new ThinkTank, the methodologies of that thinktank are defined by the people working on it and this impacts the policy involved running the tally bot,etc.
  • because the bots need to evolve at their own pace and not be very dependent on wiki updates
  • because the bots should be able to be written in various languages and with various tools.
So the MediaWiki or specifically dkosopedia standards required are
  • Vote format conformity enough for consistent parsing
  • An interface for automated editing, the regular editing interface used by humans is good enough but probably not optimal.

Question: what advantage is there to "vote" being a real namespace as opposed to a naming convention? I can't think of any but I don't know the MediaWiki software that well yet. (whew, sorry it's so long, but these are some interesting/important issues). cheers.
--Centerfielder 20:41, 21 Jun 2004 (PDT) Well, it appears that creating an article with a colon, such as "Vote:Is The Moon Made of Cheese" simply creates a page in the "Main" namespace (cur_namespace == 0 in the cur table) with the name "Vote:Is_The_Moon_Made_of_Cheese" (the field is cur_title). If "Vote" were a real namespace then cur_title would be "Is_The_Moon_Made_of_Cheese" and cur_namespace would be the id of "Vote". For tallybot purposes it really doesn't matter since I can query based on cur_title starting with "Vote:" in the, uh, current situation or query based on cur_namespace = k where k is the id of the now nonexistent namespace "Vote".
In either case, yes, Voting pages need to adhere to a certain format or the tallybot will get upset. The first pass I made at a format should be extended to allow more than just "Yes" and "No" votes, and I have an idea how to do that but it's time to put the kids to bed right now. I do have a perl script that grabs pages whose title starts with "Vote:" in the main namespace; that was the hard part since I'd not used DBI before, but it was dead simple. The rest should be easy. I'll make a few more passes and point you towards a test page.
Also, I'm not sure what you mean by "interface for automated editing", unless you mean an API.
-Pyrrho 14:12, 22 Jun 2004 (PDT) When I first started playing with naming-conventions-that-look-like-namespaces (the first was "vote:", but I've also used "MemeTank:") I found it all went into the main namespace which is what I wanted (the alternative being that it would confuse mediawiki and be a bad naming convention).
re: interface for automated editing: I'm thinking about a protocol. Such a protocol would likely still be via HTTP in my ideal world because as I said I think the bots should be cleanly seperate from the wikimedia internals. I don't think we NEED such an interface, mind you, but it would be more efficient because, for example, this form I'm typing in right now has a lot of HTML and text around it that the bot would not care about, the side bars, etc. etc. It's pretty easy to parse that stuff away and not a huge bandwidth cost. But the issue of having an actual "vote:" namespace and a "real" system for this and other automated editing probably goes in that sort of direction in some (far distant) future. btw, have you read up (or already familiar with) the history of bots and Wikipedia? Very interesting. It also shows how the kinds of bots we need are somewhat distinct from what Wikipedia has needed.

Voting - A separate namespace?

--Pyrrho 02:27, 3 May 2004 (PDT) Adding this on top, hope that's fine, it's easier to see a new topic... I use the diff to find new replies... might get hectic... it would be nice to use scoop for the talk pages. But here is my idea...

namespace "vote:" We discussed voting on pages to classify them before. I now think we should have a namespace which are community votes, i.e. endorsements. This allows us to have any kind of position paper in the wiki since there can be a page of votes that will demonstrate the consensus or lack theirof. Not only this but it can characterize the nature of the consensus as follows.

The page will have questions, separated by horizontal rule. There will be standard questions based on the type of article, e.g. if the article took a position on an issue, "Do you endorse the position advocated in this article?". Such standard questions would be there to help tools that gather votes. However people could put any kind of question on this page and people could submit votes.

There was a vote standard someone submited (forget who), which I paraphrase. A line appearing below the question.

Vote String, username, date, [keyword1, ..., keyword2]

e.g. "No, pyrrho, 2002-5-2, vehemently oppose"

Note, you can change your vote as the article changes.

keyword is essentially for other keywords which can again, wiki style, be anything that someone wants to annote their vote with. My example assumes a family of keywords for characterising one's support, e.g. when limited to a Yes/No vote: vehemently support, strongly support, support, oppose, strongly oppose, vehmently oppose.

A namespace provides a place that applies to every article in the wiki.

-Jeff Weger(je)son 05:53, 3 May 2004 (PDT) I am intrigued by this idea. I'd like to see it in action. I'm curious to see how it would work and the consequences of doing something like this. It's definately worth the effort to test out this idea. I think this has the potential to be an important and distinguishing feature for a political wiki like we desire to create. Voting is the iconic political action. What better way to embue this wiki with the political spirit than with voting mechanisms. Two of the best features of dailyKos are the polls and the comment votes. Put me down as seconding the motion and I "vehemently support" as a vote.
--Centerfielder 19:49, 4 May 2004 (PDT) Re: Voting. The Wikipedians do something similar - see this page for an example. The question polled is very specific, only yes or no answers placed under a specific heading, comments in a different heading. Seems like they've done this before. Take a look.
--Pyrrho 00:10, 5 May 2004 (PDT) ah, yes. I forgot about that... someone (forget who) linked to a similar vote at wikipedia before. I forgot they put the votes under the voting option. That's probably less error prone than having to type the vote on your vote line... btw, I noticed that the mediawiki software includes a python framework for making medeawiki bots... which is very cool as I see using use bots to automate vote counting, etc.
--DRolfe 21:12, 28 Jul 2005 (PDT) - I also mention that Everything2 has already invented this wheel as well. The ability for the community to provide a consensus on the quality of a piece of writing is what allows for the crap to be culled and the gems to remain. It would probably be worth just making a suitable patch to MediaWiki to add to every article with either a 'up or down' vote or a perhaps a decimal measure agreement/disagreement. The hard work sets in when you want to allow only logged in voters to vote (and change their votes later on i.e., adding new tables or extra columns to every article for which voters have voted which), or to let everyone vote but use all kinds of crazy ballot-stuffing countermeasures. Probably the worst part is ... the article changing between votes means that votes get crufty (many many negative votes on an article that has materially changed) leading to near useless results, or locking voting to specific revisions which makes voting on the wiki pointless as you could instead just export the article into a diary and let people vote on it. In summation, I think voting and wikis don't mix -- the target will be changing too often for vote results to be meaningful.
Everything2 addresses this by allowing voting only once on any article -- for this reason write-ups are controlled by only one owner and exist under a title competing with the others; They are editted and polished before they are submitted the first time. They then undergo a trial by fire and if they fail they are deleted. If they do poorly the submittor can improve the article in hopes that future votes will go their way. If the write-up is excellent it will supplant the others and all future edits are minute corrections or long term updates. Finally, only voters can see write-up scores. E2's consensus by king-of-the-hill approach predates Wikipedia (and due to Everything's single author per write-up archetecture it was soon outrun by Wikipedia with its ability to tap a larger labor pool). I think article reputation was strictly not implemented in Wikipedia because they'd seen it restrict flexibility in previous collaboration platforms.
Anyway, sorry to rain on the parade, I just don't see how rep or consensus scores can ever be meaningful when people are voting at will on a mutable document. It seems more effective to make a Consensus: namespace (like Consensus:George W. Bush) that leads to an immutable template document with lots of checkboxes like "douchbag", "idiot", "visionary leader", "nice guy", "has good hair", "favorite", etc., where the opinion of the users of this site just mark off all they believe apply and then submit. This long binary string gets encoded and stored with the users ID in the database. Then this data is just formulated into a consensus variable that's tagged into the article. If you know let's say 60% of all submissions have douchebag checked then it's included in the consensus string. If people revisit their opinions as events change or as he document changes they change their modifier page, resubmit, and the consensus variable is changed. The variable is built into a template page maybe as Results:PAGENAME than can then be included in the main article in a box with a [Template:Consensus Box] which includes a msg:Results{PAGENAME} substitution. Jeez, I really started rambling. Anyhow, that's my two cents. ;-)

Esoterica? People space?

--Centerfielder 13:26, 22 Apr 2004 (PDT) Should more esoteric subjects, such as political philosophies or economic theories, be under a single separate topic, perhaps called Esoterica?

--DRolfe 20:17, 28 Jul 2005 (PDT) - God, no. That would cloud up both searching and linking. Namespaces should only be used to avoid ambiguities and collisions where it is very likely that articles will have the same name. E.g., James Carville and User:James Carville (the obvious case); or MSM, which contains a common redirect and Kossary:MSM which contains a snarky definition; also Filibuster, the real discussion, vs. the entry for filibuster in Kossary.

--Centerfielder 13:26, 22 Apr 2004 (PDT) Should there be a separate namespace for people, i.e. people:james_carville

pyrrho - wegerje... well, a namespace for people/biography might be overkill, but the option of using a naming convention pollutes the article name itself. The goal is to be able to do a search and get ALL biographies, etc... I think the way for this might be a system of keywords that we insert into a visible keyword area in the article that help us do searches like this. btw: hola!

--DRolfe 20:17, 28 Jul 2005 (PDT) Hasn't mediawiki solved this with categories?

--Centerfielder 08:00, 27 Apr 2004 (PDT) ok. I think it's better to keep it simple and add namespaces later if it becomes necessary.

Retrieved from "http://localhost../../../n/a/m/Talk%7ENamespaces_3fd3.html"

This page was last modified 04:12, 29 July 2005 by dKosopedia user DRolfe. Based on work by dKosopedia user(s) Pyrrho, Centerfielder and Ikswazi af Fahr. Content is available under the terms of the GNU Free Documentation License.

[Main Page]
Daily Kos
DailyKos FAQ

View source
Post a comment
View content page
Page history
What links here
Related changes

Special pages
Bug reports