Blog@Case Topics: casewiki

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps102007-02-11T05:33:20ZCase Wiki API Workinghttp://blog.case.edu/gps10/2007/02/11/case_wiki_api_working2007-02-11T05:31:32Z2007-02-11T05:33:20Z

The Case Wiki API ( http://wiki.case.edu/api.php) appears to be magically working now. There are lots of really cool things that could be done with this. I'll leave it up to the reader to devise some.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Overengineered Wikishttp://blog.case.edu/gps10/2006/09/28/overengineered_wikis2006-09-28T18:49:38Z2006-09-28T18:49:10Z

According to Wikipedia,

A wiki is a type of website that allows users to easily add, remove, or otherwise edit and change some available content

To add to that, a wiki usually has a minimal markup from which readable output (usually HTML) is generated. Wikis are cool technology. Unfortunately, general adoption of wiki technology suffers from a critical fault: specifically-tailored, overengineered solutions. Wiki software packages come with all sorts of features-- file uploads, WYSIWYG, user permissions, spaces, plugins, advanced caching, etc. This is all fine and dandy, but they are missing one significant feature: indirection of core wiki abilities. At its core, a wiki is just a parser for a grammar, a versioning system and a front-end to the system. Wiki syntax is just like HTML, BBCode, TeX, XML, etc. It is a markup language. Nothing more, nothing less. Wikis are different from (most) content management systems in that they store a complete history of every change, much like RCS, CVS, or Subversion. Again, nothing special here. All wikis have these two attributes. The only thing that makes one wiki software package different from another is the front-end to control it all. My peeve is as follows. If two of the three qualifying attributes for wiki software are common among all wikis, how is it that wiki software varies so much? Why, when I install a wiki, don't I have the choice of selecting the markup parser? Why also can't I select the version storage system? These components should be interchangeable, should they not? At the programming level, there should just be a set of common interfaces for interacting with a wiki parser as well as storing content. Everything that makes one wiki software different from other wiki software should be the UI, ACL's, file attachments, and whatever other gadgets are part of wiki packages. Let's take MediaWiki for example. MediaWiki powers Wikipedia and because of this, its wiki syntax is probably the most recognized of all in existence. When selecting a wiki, one might want MediaWiki based solely on the popularity of the syntax. However, MediaWiki simply doesn't work for many scenarios. You want access control? You are out of luck. You want a very simple interface, again, you are out of luck. You look at DokuWiki. But wait, its wiki syntax is different and it only stores revision information in files. This isn't suitable! The same holds true everywhere you turn. One wiki offers a great set of features, but the limiting factor is often the syntax or the storage engine, something for which you have a hard requirement. In case you haven't guessed, this all goes back to deploying a wiki farm at Case. We are already dedicated to MediaWiki on wiki.case.edu. Unfortunately, MediaWiki doesn't support ACL's (despite what the access control patches available claim to do) and it doesn't easily support the concept of spaces. Making MediaWiki perform as part of a wiki farm is like hammering a square peg in a round hole. The ideal solution is to take something like SocialText and plug in the MediaWiki syntax. But wait, you can't plug-and-play wiki parsers. Back to square one. Ugh.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Potential for the Semantic Wikihttp://blog.case.edu/gps10/2006/09/05/potential_for_the_semantic_wiki2006-09-05T19:13:17Z2006-09-05T19:52:30Z

Semantic MediaWiki was installed on the Case Wiki last week. Since then, about 150 relations and 50 attributes have been defined. There is still lots of room to grow. We have yet only covered the basics of what the semantic wiki can do. So far, the most popular semantic in use is the located in relation. This relation allows you to define that one article is located in another article. Take a look at Yost Hall, Nord Hall, or many of the building articles. These articles now look at the semantic relationships and automatically display a list of articles that have the "located in" relation set to that building. Cool! Brian Beck already has a geolocating tool for Case that follows this relation to find the location of something on campus. Anyway, we have barely scratched the surface of what is possible with the storage of semantic data. Here are a few ideas I have thought of:

Event information - Per-event articles could be created in the wiki. Each article would have attributes defining the event date, time, location, sponsors, etc. It would be possible to query the wiki for all events in a given day, building, with free food, etc. It would also be possible to write a wiki "bot" or web service that allowed others to remotely publish event information to the wiki. A calendar bot could scour the Case network, parsing calendar information and publish event info to the wiki. The Case Wiki could automatically import feeds from USG or Case Life. The Case Wiki could also provide an API for publishing event info (Atom Publishing Protocol or CalDAV perhaps). The Case Wiki could easily be a calendar aggregator for the university. Of course, this is a stretch from the purpose of the Case Wiki, but it is possible. We could always set up a specialized "Events Wiki" whose sole purpose is to track events across campus.
Location-based services - We have already seen how the "located in" relation works. We can do much more. Imagine if every building on campus had the subnetwork attribute defined. One could easily parse the XML output from the wiki and match an IP address to a building. This could be used on numerous web sites across campus to dictate web site behavior. The location information could also be used to building a virtual tour of the university. You could be walking around with your GPS-enabled phone and your phone will be able to find all restaurants within 500 ft.
Finding businesses - The semantic extension comes with a very powerful query tool. It is possible to dynamically search for articles matching a given criteria. Currently, we can do things like "find all places in Little Italy" or "find all bars in Coventry." Imagine what happens when articles have attributes defining their hours of operation. "Find all pharmacies currently open" or "Find a grocery store open Friday at 11 pm."
Establish detailed history of events - Imagine if all the buildings on campus had attributes defining their history (construction date, tear-down date, etc). It would be possible to construct interesting queries about the university. For example, "Find all buildings existing in the Case Quad in 1954" or "Find the oldest restaurants in Little Italy."
Crime log - The Case Wiki could be used to record crime events around campus. Attributes such as severity, suspect description, location, etc, could be recorded for each. It would be possible to query for "All bikes stolen in 2005" or "All crime in the Case Quad in May though August". It would make Brian's campus crime parser a lot easier.

Because there are no restrictions on what relations and attributes can be defined in the Case Wiki, there are limitless possibilities for ways it can be used. However, we must always keep in mind that the Case Wiki is a wiki and that it is meant to be an encyclopedic reference about the university. We shouldn't be shoving everything in the Case Wiki just because we can. There comes a time where a large or unrelated data set requires its own wiki. This is where a wiki farm comes in and another reason why MediaWiki with its semantic extension is a compelling choice for the software to power it. Actually, the more I think about it, there should be multiple wiki farms on campus. People should be able to chose between MediaWiki (for compatibility with the Case Wiki and the semantic extension) or from something else. This topic is for another post, though. So, I hope I've given you a taste of what is possible with the semantic Case Wiki. If you have an idea, leave a comment, or start adding semantic content to the Case Wiki!

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Semantic MediaWiki Active on Case Wikihttp://blog.case.edu/gps10/2006/08/30/semantic_mediawiki_active_on_case_wiki2006-08-31T02:47:37Z2006-08-31T02:59:53Z

I installed Semantic MediaWiki (SMW) on the Case Wiki this evening. Semantic MediaWiki allows you to embed relations and attributes in articles. In a nutshell, it gives the wiki itself the ability to understand properties about something. For example, you can say that something is "located in" something else and later ask the wiki for all articles located within that something. Semantic MediaWiki works by introducing new wiki syntax, which is documented at Help:Annotation on the SMW web site. I will plan to add something on the Case Wiki help, but until then... Semantic MediaWiki opens up a whole new door of possibilities for the Case Wiki. Documenting relations and attributes is only the first step. The real power comes in the ability to query the stored relations and attributes. For example, with a semantic-aware wiki, you will be able to craft specialized queries. For example, "Find buildings in the Case Quad built between 1900 and 1950" or "Find all places to eat in the Case Quad." Best of all, there will be no more need for manually-edited articles like "Places to get coffee." Instead, you can just query for "food providers who sell coffee." Cool, eh? I welcome any feedback people may have to this new feature.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Potential for Enhanced Collaboration at Casehttp://blog.case.edu/gps10/2006/07/11/potential_for_enhanced_collaboration_at_case2006-07-11T17:01:17Z2006-07-11T17:04:22Z

Would a service that provides customized web space for groups or individuals to develop content and upload files be useful to the campus community? If you believe so, please read Wiki farm proposal on the Case Wiki and sign your name to the list presented there.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Case Wiki Upgraded to MediaWiki 1.7.1http://blog.case.edu/gps10/2006/07/10/case_wiki_upgraded_to_mediawiki_1712006-07-10T06:35:14Z2006-07-10T06:36:29Z

I just upgraded the Case Wiki to MediaWiki 1.7.1. If you notice any weird behavior, please send an e-mail to wiki-admin@case.edu.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10More People Talking about Computer Help Documentationhttp://blog.case.edu/gps10/2006/06/13/more_people_talking_about_computer_help_documentation2006-06-13T19:15:37Z2006-06-13T19:33:51Z

I have mentioned computer help documentation in my blog before. With a new help documentation site accessible through the portal looming on the horizon, people are concerned that the solution is not ideal. I have to agree with them. I'm not trying to be a shameless promoter of my product. I'm just trying to raise awareness of what is best for the university. So, read the Case Forum thread, help.case.edu getting replaced and lend your $0.02.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Google Map of Case Campus Updatedhttp://blog.case.edu/gps10/2006/04/16/google_map_of_case_campus_updated2006-04-17T03:04:02Z2006-04-17T03:06:06Z

I was randomly checking the Google Map of Case on the Case Wiki and noticed that the satellite photographs have been updated. Instead of a blank field, we now have construction photos of the Village at 115. Unfortunately, the Baker Building still exists. I guess we'll have to wait until the next update...

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10MonoBook Skin Enabled on Case Wikihttp://blog.case.edu/gps10/2006/04/07/monobook_skin_enabled_on_case_wiki2006-04-07T19:48:16Z2006-04-07T19:52:19Z

More choices are better! Many can relate to the skin used by the Wikipedia projects. So, in an attempt to reach out to these people, I have enabled the MonoBook (Wikipedia) skin on the Case Wiki. The default skin for users is the skin that you have come to know. However, now you can go to Special:Preferences and change the skin if you so desire. I would like to thank Andrew Witte for contributing the logo.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Case Wiki Upgraded to MediaWiki 1.6.1http://blog.case.edu/gps10/2006/04/07/case_wiki_upgraded_to_mediawiki_1612006-04-07T08:16:04Z2006-04-07T08:22:22Z

I have upgraded the Case Wiki to version 1.6.1 of MediaWiki. I believe I worked out all of the kinks, but there might be some real minor things here and there. As always, if you see something weird, please report it at CaseWiki:ToDo or send an e-mail to wiki-admin@case.edu . One change that you will notice is an AJAXy search feature. Type something in the search box then move your mouse over one of the buttons. There are also numerous new Special Pages. The real exciting part about upgrading to 1.6 is the availability of many new hooks inside MediaWiki to further customize the software. There should be some new features on the Case Wiki in the upcoming days or weeks...

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Footnote Support Added to Case Wikihttp://blog.case.edu/gps10/2006/03/27/footnote_support_added_to_case_wiki2006-03-27T05:42:40Z2006-03-27T05:44:40Z

I quietly added support for footnotes on the Case Wiki a few days ago. The librarians and encyclopedia purists can now happily cite sources when writing content.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Thoughts on Establishing a Wiki Farmhttp://blog.case.edu/gps10/2006/03/24/thoughts_on_establishing_a_wiki_farm2006-03-24T07:31:05Z2006-03-24T19:55:13Z

Following in Jeremy's footsteps, I am going to jot down my thoughts on a wiki farm at Case. I will try to avoid saying why a wiki farm is needed. Jeremy already did an excellent job at communicating that point. By now, hopefully you are aware of what a wiki is and why it is useful. Although the Case Wiki is a great start, many still desire something that is less official, something that is smaller, something that is more customizable. Enter a wiki farm. A wiki farm is someplace you can go to create your own wiki. A wiki for every individual. A wiki for every group. Wikis viewable by just you. Wikis viewable by just your department. Wikis editable by students in a class. It doesn't matter. You have it any way you like it. A wiki farm at Case is a great idea. Here are some of my thoughts on the matter:

How independent are separate wikis?

Are separate wikis actual separate wiki software installations, or are they simply spaces within a master wiki? The former would theoretically allow higher per-project customization and possibly even allow multiple wiki software packages to be utilized. The later would establish a more-controlled and uniform environment, but potentially at the cost of customization.

How do you leverage authentication and authorization?

For authentication, there are two methods: CAS for authentication of university people, Sympa (lists.case.edu) for authentication of external people. For authorization, we can do group membership through LDAP, Sympa and the USG web service. Shibboleth can also be leveraged in there too. How are all of these methods combined seemlessly? We need to select a software package(s) that allows these all to be used.

Why can't we use a wiki hosting provider?

There are free wiki farms in existence. We could use them. However, they wouldn't integrate with our authentication and authorization architectures. Considering some wikis could be used to discuss sensitive university matters (say a wiki on how to invest the endowment), we would not want this information to leave the Case network. Reasons enough.

Consistency Matters

Wiki syntax can be difficult to master. Do we really want to introduce a separate syntax from the Case Wiki that is only valid on the wiki farm? If so, does this mean we are constrained to using MediaWiki?

What software is available?

MediaWiki is proven to work well for individual projects. We could install many instances of MediaWiki using custom software to manage them. I am very fluent in MediaWiki's architecture and could create something rather quickly. XWiki is a promising wiki software product that natively supports creating multiple wikis, or spaces, within one master wiki. XWiki is opensource and is coded in Java. Confluence is like XWiki, but costs money and looks to have a more confusing interface (from personal experience). Given financial situation of the university, rule out Confluence. DokuWiki, TiddlyWiki, and others should all be considered. Many would require custom software to tie them together in a wiki farm. Wiki syntax is different for every wiki.

Can MediaWiki Work?

As stated earlier, I could hack out a farm control application for MediaWiki with relative ease. MediaWiki IS meant for single project installations. We would just have many installations controlled via the farmer interface and would give owners of each wiki control over what extensions to enable. However, MediaWiki can seem overpowering. It IS overkill to drive a 10-page, 5-user wiki. At the same time, syntax agrees with the Case Wiki. The work we put in to the development of the Case Wiki can easily be translated to the wiki farm. Because of the existence of the Case Wiki, MediaWiki is in a position of "why shouldn't we select MediaWiki" instead of "let's evaluate MediaWiki as a possibility." Is this logic flawed?

Other thoughts

Is there a market for the service? The reason for proposing a wiki farm is to give people a place to play that is not the Case Wiki. The Case Wiki can't serve everyone's need. There must be another service. Yet, would people utilize such a service? ITS has an internal wiki. IT for Enrollment Management has an internal wiki. The Case iTunes group has a wiki. My fraternity has a wiki. Would these groups have chosen the central wiki service if it were available? How do we encourage people chose the central wiki service? Just some random thoughts at the wee hours of the morning. Perhaps when somebody gives the green light for the wiki farm, my thoughts will be consulted. Who knows.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10New Syndicated Feeds Available for the Case Wikihttp://blog.case.edu/gps10/2006/03/22/new_syndicated_feeds_available_for_the_case_wiki2006-03-22T07:29:52Z2006-03-22T07:33:58Z

I completely rewrote the syndicated feed generation for the Case Wiki today (for the 3rd time). Feeds are now available at Special:WikiFeeds. If you run MediaWiki, you too can enjoy the enhanced features of this plugin. Source code is available at My MediaWiki Project Site. I'll be redirecting the existing feeds to route to this new script. If anybody notices any issues with the feeds not validating or any other strange behavior, please let me know by e-mailing wiki-admin@case.edu or leaving a comment on CaseWiki:ToDo.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Case Wiki Moved to Different Server, Almost Ready to Be Production Servicehttp://blog.case.edu/gps10/2006/03/15/case_wiki_moved_to_different_server_almost_ready_to_be_production_service2006-03-15T07:14:44Z2006-03-15T07:25:15Z

The Case Wiki has been moved to a new physical server. The new server will be the wiki's permanent hardware home for a long, long time. This move represents the first major hurdle in transitioning the service from beta to production. However, before that can occur, I would like to make a strong push at resolving all outstanding issues with the service. If you have any ideas for what you would like to see in the Case Wiki, please leave a comment here or on CaseWiki:ToDo. For you techies, you are probably interested in the specs of the new server. It is running off of 2 dual-core 3.06GHZ Xeons with 4GB of RAM. The OS is Linux. As for software, it is being powered by Apache 2.2, MySQL 5.x, and PHP 5.1.x-- all opensource software. The previous server (which is still running this blog system) is the same hardware configuration, but with older versions of Apache, MySQL, and PHP. During the upgrade, I made a few slight changes to the MediaWiki caching mechanism. You might notice a slight speed increase as a result.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10eAccelerator: Now With Support for PHP 5.1http://blog.case.edu/gps10/2006/03/10/eaccelerator_now_with_support_for_php_512006-03-10T14:09:39Z2006-03-10T14:14:11Z

I was installing a fresh LAMPS environment for an ITS server (the Case Wiki's final home no less) and saw that eAccelerator now supports PHP 5.1! PHP 5.1 was tons faster over 5.0.x, however, nothing could prepare me for how fast PHP is now with 5.1 + eAccelerator. What makes it even better is MediaWiki has built-in support for eAccelerator, using the eAccelerator API to cache common SQL requests. Needless to say, the Case Wiki will be much faster once it is deployed on its new home. I can't wait to complete the transition.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Case Wiki Hits 1000 Usershttp://blog.case.edu/gps10/2006/02/20/case_wiki_hits_1000_users2006-02-20T06:24:52Z2006-02-20T06:44:35Z

I just noticed that the Case Wiki has hit the 1000 users mark! Since the wiki can log you in automatically if you are logged in to CAS, I thought these numbers might be a little deceiving, so I decided to do a little analysis... Of the 1025 people in the user table as of this post, 301 have contributed at least 1 revision, of which there are about 7500. For comparison's sake, the Case Blog system has 1013 authors and 920 blogs. The 5962 individual posts have been made by 374 distinct people. The Case Wiki was launched in June of 2005 and this blog system in December of 2004. From these numbers, it appears the Case Wiki is growing faster than Blog@Case, at least from a user-contribution perspective, as it should be. Since the Case Wiki is a "factual" nexus about Case, one would expect people to find it quicker, as the content of a wiki would theoretically yield more search results than opinions, which are commonly made in blogs. Also, the barrier to publishing in the Case Wiki is much lower. There is no need to create your blog. You just click the "edit" link and you are there. I would be misleading if I neglected to mention the actual "popularity" of each service in terms of unique page hits. The numbers of hits in the past three months to the Case Wiki is roughly 1.281 million. Blog@Case has 3.58M, almost 3x more. Blog@Case is definitely a more popular service. ( Case Wiki stats, Blog@Case stats). I believe both these services have only scratched the surface when it comes to usability potential. Many people still do not know Case has a Blog or Wiki system. Until these services get prime-time exposure, it will probably remain that way. It makes me start to wonder about how to best advertise an IT service. It would be interesting to see the usage graphs for IPTV and the My Case Portal after their posterings last semester. As a teaser, I can say that the next product from SIS will attempt to address the problem of people not knowing about service availability. If you are a good internet sleuth, you will have no trouble finding the test site(s) for this product.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Case Wiki Named "Wiki of the Weekee"http://blog.case.edu/gps10/2006/02/07/case_wiki_named_wiki_of_the_weekee2006-02-07T17:41:04Z2006-02-07T17:47:34Z

Wiki That! has named the Case Wiki it's 17th "Wiki of the Weekee." In their announcement, they rate the Case Wiki. The Case Wiki scores a perfect score in everything except "Collaborative activities or events." It is worth noting that the Case Wiki is meant to be an encyclopedia for the university and although it can power collaborative activities, there are other forums that might be better suited for such activity. Perhaps in the future it will become the nexus for campus dialogue. Time will tell.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10My Sins Against the Wiki Communityhttp://blog.case.edu/gps10/2006/01/26/my_sins_against_the_wiki_community2006-01-27T02:46:39Z2006-01-27T03:18:07Z

Last December, I was contacted through the grapevine to explore the possibility of using the Case Wiki to host the discussion for the 2006 Academic Happy Hour. Organizers wanted a piece of technology that could be used during and after the event for collaboration. I told them it is possible to do this with the Case Wiki, but other products, such as forum.case.edu or this blog system might be better suited, depending on the discussion format and desired output. Earlier this month, I was informed that the deciding powers had chosen to use the Case Wiki and the format for discussion was well within the abilities of MediaWiki. So, I thought all was well. I went to obtain the implementation details so I could see what skeleton pages I would need to create. There, I was told something I wasn't expecting: the administration have decided that they want the wiki postings from the Academic Happy Hour to be restricted to just the Case community. First, I was shocked, as this was the most remote possiblity imaginable after the past discussions about the usability of the Case Wiki. Secondly, I started second-guessing the decision. Why would they want to protect content? It is not like they are checking ID's at the door. Anyway, I am a worker bee. I needed to make this work. So, here we are. I have just committed a page restriction patch to the Case Wiki. Only certain users (currently just me) can "restrict" pages. Once a page is restricted, only a logged-in user can view it. Let me assure the community that as soon as the administration deems the content on the Academic Happy Hour page worthy of public consumption, I will remove the page restriction feature. What is the point in having an encyclopedia where certain volumes are behind lock and key? I don't know either.

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10Watching Wikis in Real Timehttp://blog.case.edu/gps10/2005/12/18/watching_wikis_in_real_time2005-12-19T04:14:57Z2005-12-19T04:20:20Z

I have created an AJAX-powered extension to MediaWiki that lets you watch edits in a wiki in real time. It is like watching the recent changes page with an automatically updated view of the differences between articles. Something like this would go a long way to make a wiki a credible medium for real-time collaboration. Check it out at Special:AJAXWatcher. First, load up the page then make an edit on the Case Wiki. More features will come soon. If the extension is buggy, I apologize. I can confirm it works with Firefox 1.5 on Linux ;)

Gregory Szorcgregory.szorc@case.eduhttp://blog.case.edu/gps10