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!

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.

Am I the only person that does this? You see, I visit a web site (maybe it's someone who got linked to by the grandiose blogosphere, maybe it's a vendor we're evaluating, maybe it's a company I plan on purchasing goods or services from, maybe it's a web application I am evaluating for personal or professional use), and I always View Source on it and check up its markup, CSS, and Javascript. I always do this. It is one of the first evaluations I do on company/person/product. If you/it don't/doesn't have clean markup, well separated presentation layers, and non-intrusive Javascript that degrades gracefully, I knock of like 10 points from their/its first impression. I know I am a geek and that is why I do it. But am I the only geek that does it or gives it this much weight? It's a big deal to me. Like if you were a company and you wanted to hire me, I will definitely factor in how well your web site is designed – not just aesthetically but also how well it was engineered – in my decision to accept your offer. I don't care that you out-sourced it and had a design firm do it for you; whoever hired that design firm from your company should still be held accountable. Am I a crazy person?

Everyone knows the Wikipedia, the free encyclopedia. It has thousands of users and the content is, on average, pretty reputable. The Wikipedia can be used as a quick source to find facts. However, these facts are expressed in tables, phrases, and sentences in entries. For example, Wikipedia:Abraham Lincoln. To get facts such as his birthdate, years in office, etc, somebody types these attributes into the article. After those attributes are entered, the computer knows nothing about them other than the fact they are characters forming a string forming the article content. That is, without somebody manually adding the article to Category:1865 deaths, we have no way to extract this information. In the ideal world, one would have a article for a person, define their date of death, and we could query in real-time and without relying on individual's resiliance to make an article of a category saying so, the people who died in a certain year. The Semantic Web is a project to create a medium in which to exchange this type of information-- attributes and relationships among things. The biggest hurdle with the Semantic Web is establishing this information. How do you collect it? How do you update it? How do you verify its integrity? I hypothesize that a wiki, especially the Wikipedia, is an excellent arena in which to define significant portions of the Semantic Web. I'm elated to see that the Semantic MediaWiki project exists to do just this. By slightly modifying the syntax in which you compose wiki articles, you can define relations and attributes of the articles themselves. For example, instead of typing "Nord Hall is a building in the Case Quad" (or

"[[Nord Hall]] is a building in the [[Case Quad]]"

in wiki syntax), you would type

"[[Nord Hall]] is a [[is a::building]] in the [[located in::Case Quad]]"

. You could further define attributes about the article, for example

"It has [[floors:=3]] floors"

. Although there is no difference to the average user, the relationship of this article to others and attributes of this article are now understood by the wiki-- by a computer. This opens up a whole floodgate of possibilities. Imagine you are visiting campus and you want to know your way around the Case Quad. You know about the existence of the Case Quad, but not what the buildings are. So, you go to Category:Case Quad on the Case Wiki. What you might see are articles tagged as relevant to the Case Quad. Some of these could be statues, fountains, etc. You don't care about them! You just want buildings. But wait, since the wiki knows about other article's relationships to the Case Quad, it can automatically say "They are n buildings located in the Case Quad. Here is a list." Or, you are composing a paper about the history of the Case Quad. You cannot find a list or map anywhere of what the Quad resembled in 1940. So, instead of referencing articles for every building in the Case Quad category, you just say, "Give me a list of buildings located in the Case Quad that were built before 1940." Since all the relationships and attributes of objects are known, the possibilities for data harvesting is immense. For an example of the Semantic MediaWiki project in action, see the San Diego article on the demo site.