Room 208

[Tzetze 8/8/2011]

I want to fork the wiki. My main reason is technological; to me, the (well-known) problems with the wiki software, namely all of it, are more important than the “social” concerns that are often complained about. The pervasive lack of secure authentication, the terrible parser, the ugly code, the generally ugly site, that kind of thing, which Fast Eddie hasn’t really shown any desire or ability to improve.

However, I think that this is only the tip of the iceberg, and that the technical and the social problems could be dealt with in a unified way.

What is the point of TV Tropes? I think that it has been, since near the beginning (originally, I’m sure, the point was finding commonalities in Firefly and BtVS :P), to catalogue recurring patterns in media. And I think that it has been, and still is, successful at that! Right now the wiki probably has thousands if not tens of thousands of distinct tropes described, with pretty good lists of what works they show up in. The various controversies we’ve had, from Cosmetor to renaming Nakama to sock tropes have had pretty much no real effect on that goal.

(A fork, if you don’t know, means taking the existing pages on TVTropes, and copying them to somewhere else. This is of course perfectly legal mod the attribution list actually working :))

I think it’s a good goal. But I don’t think that it’s all a trope site could do. In 2009, one Kurt Cagle wrote an article on TV Tropes as a semantic website, and someone later tried implementing this. The “semantic web” is one of those buzzwords that everybody loves to hate. The idea ties in with computer knowledge representation (representing human knowledge in a computable format). Essentially, using a standard format like RDF/OWL, relationships between entities are represented with simple sentences made of a noun phrase, a verb/copula, and an object. “Cars/are a type of/motorized vehicle.” “Cordyceps/infects/grasshoppers.” And so on.

This hasn’t worked out well for human knowledge in general for a variety of reasons, such as the vast number of verbs needed. But I think it could work for the limited domain of tropes. You have a limited number of them.

• “demonstrates/exemplifies”: “IchibanNoTempura demonstrates RedemptionEqualsDeath.”
• The inverse: “TheFireflyEffect is demonstrated by JungianTelomereTeleportPlunkSpotNumberNine”
• “subverts”: “Firefly subverts ThisIsSomethingHesGotToDoHimself.”
• “is a subtrope of”: “BabyGotBack is a subtrope of Fanservice.”

And so on.

That’s the pie-in-the-sky vision. How would this be implemented, and what would be the effects for those people who don’t give a shit about knowledge representation? Well,

• Tropes and works would be identified internally using a separate identity from the name, such as a serial number, making renames and changing display names trivial.
• Trope and work pages would be divided into two readable sections: Description and list. A formalization of what we already do, is the idea.
  • The description would be basically the same as it is now; a human-readable description, possibly with a picture and snarky caption. The only major difference here is that you would edit the description separately from the list.
  • The list would be superficially the same, an unordered, bulleted list of tropes (for a work page) or works (for a trope page). Each entry would consist of a link to a work or trope, followed by a human-readable description, which would elaborate on the usage, blablabla, same ol’. The entry could be marked as a spoiler and moved to the end of the list appropriately.
    • Adding an entry would automatically add the inverse to the linked page. For example, if I added “Loads and Loads of Characters: And each is given at least a paragraph describing their thoughts.” to the Middlemarch page, the Loads and Loads of Characters page would have “Middlemarch” (with no human-readable part, since it wouldn’t fit) added to it automatically.
    • Each entry would be stored separately in the database, so editing an entry description could be more easily done with a JavaScript popup, rather than a separate page where the entire work/trope is locked down, copied, sent.
    • Subversions, aversions, justifications, etc. shit could be chosen with a dropdown or something, which would store that selection programmatically. Then maybe subversion entries could be colored differently for viewing.
• Pages would be tagged with metadata. Trope metadata might be like “supertrope:”; work metadata could have “year of origin”, “nation of origin”, “medium”, “author/notable writers”, etc. Strictly out-of-universe stuff, and probably nothing as arguable as genre. Medium would be pretty strict as well, with anime and western animation both listed as “animation”. The exact boundaries would have to be laid out beforehand.
  • Each tag (“Japan” (as a nation of origin of works), “Jane Austen” (as an author), “Lord of the Rings” (as a series)) could also have a description section, followed by an automatically generated list of things tagged with it, thus serving for the indices we use now.

The program-readable listings, along with tags, could make searching and discrimination functions much more powerful. For example, if you hate anime, you could go into your settings and set works tagged “animated” medium and “Japan” nationality not to display. Or if you were doing an English major sort of project, you could get a list of all works using the Defiled Forever trope sorted by year of publication, or all 19th century works using subtropes of Living A Double Life, or any number of things.

The main disadvantage of all this is that it would take a lot of new coding, but it’s doable. It would also make copying the content from TVTropes nontrivial. But, I think this is a good way to make a TVTropes fork something both more fun to browse and more useful.

Kinks to work out:

• What constitutes a medium?
• How do you pick a nation of origin in some cases? Nabokov was Russian, but he mostly lived in Germany and the US, and wrote many novels in English.
• Etc.; I think the general “solution” is “tagging/metadata isn’t perfect, but it’s still pretty good”.
• Should a trope’s entry in a work always display the same as the corresponding work’s entry in the trope, and if not, how do we deal with it? (was3)
• (suggest more)

Other issues:

• Where to host? TVTropes gets a lot of traffic, and this would require hacking on the wiki software.
• What syntax should be used? TVTropes’ is kind of shitty/haphhazard, but changing would require some work.
• What kind of content should be allowed? Tropes for pornography, etc.?
• Something like Troper Tales? I’m thinking “fuck no”, because it’s recurring patterns in media, but there could be some sort of allowance for tabletop campaigns?
• Joke pages
• Who should administrate/moderate? Bureaucrate (totally a word) or no, and how?
• Discussion pages/forums
• (suggest more)

Brief IRC discussion, 8/8:

• 19:12 <IllFlower> You could probably fake a lot of this with templates that inject semantic data [I meant “markup”], assuming we stick to just one edition of the wiki.
• 19:13 <Jack> You mean like Mediawiki-style templates, right?
• 19:14 <IllFlower> Yeah, those. Also, I don’t know if you’ve seen www.omegawiki.org or m:wikidata but those might be relevant in some capacity.
• 19:16 <IllFlower> In case it wasn’t already clear, I have a slight bias towards MediaWiki-based solutions ;)
• 19:21 <IllFlower> It’s ambitious, to say the least. First aim would be getting the existing data out and editable = just start with a plain wiki.
• 19:22 <IllFlower> Oh, also I think you might be able to bend MediaWiki’s existing category system to your will.
• 19:22 <Jack> I suppose. Writing a trawling script shouldn’t be too hard, but I still need a host
• 19:23 <IllFlower> Yeah, I think that’s the biggest problem, followed closely by figuring out who would run the whole show.
• 19:24 <Jack> I would be dictator-for-life, of course

Edit 19:50: http://semantic-mediawiki.org/wiki/Semantic_MediaWiki

— IllFlower 2011-08-08 19:36 +0000

Looking at the Semantic MediaWiki documentation, it looks like it should be possible to do what we want without too much trouble with concepts and/or inline queries. The biggest issue, IMHO, will probably be possible performance issues involving the fact that in order to use queries to keep track of examples, each example might have to be on its own page–I’m not sure how well MediaWiki works under that kind of load(I think IllFlower’s our resident MediaWiki expert here). Actually, performance issues might be our biggest stumbling block with Semantic MediaWiki and this project in general, since according to SMW's Wikipedia page performance issues (albeit with Wikipedia, which is much bigger than Semantic Tropes will be) are the main stumbling block keeping them off of Wikipedia.

Edit 10:28: Looking at MediaWiki's database schema it seems that each page is just a line per page in a few tables and a line per revision in a few tables. This shouldn’t be too bad. Though it raises the question of how often these pages should be generated: Dynamically? Cache at fixed intervals? Cache each time the page is edited?

Edit 11:15: Apparently Wikipedia and other large wikis use a HTTP cache program called Squid for all their caching. It might be superior to do trope/works pages dynamically and just have them HTTP cached, though this might require extra wrangling with respect to removing pages from the cache.

— was3 2011-08-09 08:57 +0000

http://gorogoroiki.referata.com/wiki/Special:AllPages http://gorogoroiki.referata.com/wiki/Main_Page Here’s a little proof-of-concept type thing. I’ll need access to the codebase to make certain things work the way we want, and I’ll need a certain unhealthy plant reproductive system to make it pretty.

— was3 2011-08-09 19:26 +0000