Skinning

We were able to design a really nice skin for the site, based on the specs of their designer. It uses a 3-column layout which is kind of uncharted territory as far as MediaWiki skins go. Part of the challenge here was the right-hand column. The search section is a part of the skin, while the maps, photos and videos are generated by the MediaWiki page itself. This was accomplished by putting that stuff into a div which uses absolute positioning.

Another challenge was trying to fit a decent form into a very narrow middle column. The solution was to hide the right column via CSS, since the search form doesn’t really need to be on a form page. Then, the middle column is stretched to cover both columns. This was easy to do, since Semantic Forms helpfully adds a class to the body tag for any formedit page (which works for existing pages) and MediaWiki adds a tag to any Special page (for when adding a new place with Special:FormEdit). So the content area was accessed with:

.action-formedit #content, .mw-special-FormEdit #content {
   width: (a whole lot);
}

Displaying different stuff to logged in and anonymous users

While on the topic of body attributes, MediaWiki does not add any classes to the body tag which would differentiate logged in from anonymous users. This doesn’t present a problem for the skin, which can easily check if the user is logged in. But what if you wanted to have a part of the MediaWiki content page displayed only for anonymous users? A common example would be exhortations to create an account and/or sign in. That’s something that should be hidden for logged in users. Fortunately, this is easily and cleanly resolved.

Since this was a custom skin, we overrode the Skin class’s handy addToBodyAttributes function (hat tip):

/* Extend the body element by a class that tells whether the user is
 logged in or not */
 public function addToBodyAttributes( $out, &$bodyAttrs ) {
    if ($this->loggedin) {
       $bodyAttrs['class'] = $bodyAttrs['class'] . ' isloggedin ';
    } else {
       $bodyAttrs['class'] = $bodyAttrs['class'] . ' notloggedin';
    }
 }

For the built in skins, this is still easy to do. Just use the same code with the OutputPageBodyAttributes hook in your LocalSettings.php. This function adds a class to the body tag called either “isloggedin” or “notloggedin.” Then add the following CSS to your MediaWiki:SkinName.css:

.isloggedin .hideifloggedin {
   display:none
}
.notloggedin .hideifnotloggedin {
   display:none
}

Now in your MediaWiki code simply use these two classes to hide information from anonymous or logged in users. For example:

<span class="hideifnotloggedin">You're logged in, mate!</span>
<span class="hideifloggedin">Dude, you should really make an account.</span>

Combine with some nifty login and formedit links

Or even better, here’s a trick to generate links to edit the current page with a form:

<span class="hideifnotloggedin"> [{{fullurl:{{FULLPAGENAMEE}}|action=formedit}} Edit this page]</span>

…and a bonus trick that will log in an anonymous user and THEN bring him to the form edit page:

<span class="hideifloggedin">[{{fullurl:Special:Userlogin|returnto={{FULLPAGENAMEE}}&returntoquery=action=formedit}} Log in and edit this page.]</span>

It doesn’t get much better than that! See it in action here. Yes, you’d have to make an account to really see it work. So take my word for it.

Spam bots

While on the subject of making an account, it seems that bots have gotten way too sophisticated. One of our clients had been using ConfirmEdit with reCAPTCHA and was getting absolutely clobbered by spam. I’ve found that for low traffic wikis, the best and easiest solution is to combine with QuestyCaptcha instead. They’re easily broken by an attacker who is specifically targeting that wiki, but very few wikis have gained that level of prominence. The trick is to ask a question that only a human can answer. I’ve had success with this type of question:

Please write the word, “horsse”, here (leave out the extra “s”): ______

Featured article slideshow

This site has a pretty cool main page. The main contributor to that coolness is the transitioning slideshow with various featured articles. Gone are the days when a wiki only featured one page! This was made possible by bringing the Javascript Slideshow extension up to date, which was done by our founder Yaron Koren in honor of Innovention wiki. The articles are inserted manually which gives the user complete control over the appearance. But it would be pretty simple to generate the featured pages with a Semantic MediaWiki query.

Tag Cloud

Also on the main page is a nifty tag cloud. That is done with Semantic Result Formats and its tag-cloud format (by our own Jeroen De Dauw). Maybe I’ll blog more about that as it develops.

Stay tuned

The site will be developed further over the next few weeks, with some neat stuff to come…

Wikidata is headed by Denny Vrandecic, who, like Jeroen, is a friend and colleague of mine; and its goal is to bring true data to Wikipedia, in part via Semantic MediaWiki. There was a press release about it on Friday that got some significant media attention, including this good summary at TechCrunch.

I’m very excited about the project, as a MediaWiki and SMW developer, as a data enthusiast, and simply as a Wikipedia user. This project quite different from any of the work that I’ve personally been involved with, because Wikipedia is simply a different beast from any standard wiki. There are five challenges that are specific to Wikipedia: it’s massive, it needs to be extremely fast at all times, it’s highly multi-lingual (over 200 languages currently), it requires references for all facts (at least in theory), and it has, at this point, no real top-down structure.

So the approach they will take will be not to tag information within articles themselves, the way it’s done in Semantic MediaWiki, but rather to create a new, separate site: a “Data Commons”, where potentially hundreds of millions of facts (or more?) will be stored, each fact with its own reference. Then, each individual language Wikipedia can make use of those facts within its own infobox template, where that Wikipedia’s community sees fit to use it.

It’s a bold vision, and there will be a lot of work necessary to pull it off, but I have a lot of faith in the abilities of the programmers who are on the team now. Just as importantly, I see the planned outcome of Wikidata as an inevitable one for Wikipedia. Wikipedia has been incrementally evolving from a random collection of articles to a true database since the beginning, and I think this is a natural step along that process.

A set of files were discovered in 2010 that represented the state of Wikipedia after about six weeks of existence, in February 2001. If you look through those pages, you can see nearly total chaos: there’s not even a hint of a unifying structure, or guidelines as to what should constitute a Wikipedia page; over 10% the articles related in some way to the book Atlas Shrugged, presumably added by a devoted fan.

11 years later, there’s structure everywhere: infobox templates dictate the important summary information for any one subject type, reference templates specify how references should be structured, article-tagging templates let users state precisely the areas they think need improvement. There are guidelines for the first sentence, for the introductory paragraphs (ideally, one to four of them, depending on the article’s overall length), for how detailed sections should be, for when one should link to years, and so on. There are also tens of thousands of categories (at least, on the English-language Wikipedia), with guidelines on how to use them, creating a large set of hierarchies for browsing through all the information. These are all, in my eyes, symptoms of a natural progression toward a database-like system. Why is it natural? Because, if a rule makes sense for one article, it probably makes sense for all of them. Of course, that’s not always true, and there can be sub-rules, exceptions, etc.; but still, there’s no use reinventing the wheel for every article.

People complain that the proliferation of rules and guidelines, not to mention categories and templates, drive away new users, who are increasingly afraid to edit articles for fear of doing the wrong thing. And they’re right. But the solution to this problem is not to scale back all these rules, but rather to make the software more aware of the rules, and the overall structure, to prevent users from being able to make a mistake in the first place. That, at heart, was the thinking behind my extension Semantic Forms: if there’s a specific way of creating calls to a specific template, there’s no point requiring each user to create them in that way, when you can just display a form, let the user only enter valid inputs, and have the software take care of the rest.

Now, Wikidata isn’t concerned with the structuring of articles, but only with the data that they contain; but the core philosophy is the same: let the software take care of anything that there’s only one right way to do. If a country has a certain population (at least, according to some source), then there’s no reason that the users of every different language Wikipedia need to independently look up and maintain that information. If every page about a mutiplanetary system already has its information stored semantically, then there’s no reason to separately maintain a hand-generated list of multiplanetary systems. And if, for every page about a musician, there’s already semantic information about their genre, instrument and nationality, then there’s no reason for categories such as “Danish jazz trumpeters“. (And there’s probably much less of a need for categories in general.)

With increased meaning/semantics on one hand, and increased structure on the other, Wikipedia will become more like a database that can be queried, than like a standard encyclopedia. And at that point, the possibilities are endless, as they say. The demand is already there; all that’s missing is the software, and that’s what they’ll be working on in Berlin. Viel Glück!

There are some scripts out there that would do this. You don’t need them. Here’s what to do:

{| style="float: right; width: 613px" ... |}

<div id="image-holder" style="margin-right: 630px;">
[[File:Image.jpg]]
</div>

Then add some CSS:

div#image-holder img {
  height: auto;
  width: 100%;
}

Simple, right? Basically, the 100% width combined with the right margin gives us a “100% percent minus x number of pixels” effect. The browser responds accordingly.

See it live here.

I think the way we hooked into the sidebar was neat and the tips I took from it are useful for any other extension that adds to the sidebar. We of course used the SkinBuildSidebar hook. The problem is that monobook automatically puts a header on top of the new sidebar item – in this case AdManager1 – and puts a border around it. Neither of these was desired. Good thing that MediaWiki also gives it an id (p-AdManager1) so you can use some CSS to hide it. The trick here is that there can be multiple zones added so we may have other ids like p-AdManager2 and so on. So here’s the nifty CSS that will match all of those ids:

div[id*='AdManager'] h5 {
	display: none; #Hide the header
}
div[id*='AdManager'] .pBody {
	border: none; #and the border
	padding-left: 0; #override the normal padding
}

Unfortunately, you’ll need admin rights to see the 2 special pages that handle the settings. And that’s that.

You can see it in action here.

We then pulled off the same idea for another one of their sites. (Both of these skins have since been revamped by a fellow WikiWorks consultant.)

I think the main lesson for me was how easy it is to integrate MediaWiki with the rest of a site. We’ve all come across well-designed sites with a wiki component. Click the wiki and you’re off into monobook-land with no (apparent) links to help you return. Now what? As it turns out, it doesn’t have to be that way. With a little bit of effort, that nice theme can be applied to MediaWiki.

First, I’ll say that visiting Israel was an absolutely amazing experience. We managed to see a huge amount of the country – Haifa, Tel Aviv, Jaffa, Jerusalem, the West Bank, etc. We met secular Jews, orthodox Jews, Arabs, Russians, Americans (plus all the really diverse attendees of Wikimania, but that’s a separate story). We visited ancient ruins, high-tech parks, leafy neighborhoods, government offices, and settlements on the edge of a desert. And my extended family could not have been nicer – and the same actualy holds true for almost everyone I met, which really defies the stereotype of rude Israelis. (I was 90% enthused about it and 10% – dare I say? – disappointed.)

With that said, on to the conference. Here are some general observations of mine:

• I think there was a general view that this was might have been the best-organized, best-run Wikimania ever. The venue was great, the food was amazing, the parties were on-point, the keynote speakers (Yochai Benkler and Joseph Reagle) were well-chosen, and there were lots of nice little touches, like awesome videos at the opening and closing (the closing one must have been prepared in less than a day). The one technical glitch was the lack of enough power outlets – but people managed. I’ve been to four of the seven Wikimanias, and they’ve all been enjoyable and well-run, but this one just seemed to have that something extra. I’m biased, though, because I grew up in Haifa, so maybe I’m the wrong person to ask.
• I have to admit that I had soured a little on Wikimania beforehand – it’s a great experience for anyone who hasn’t been before, but at some point one can get a little Wikipedia’d out. There are always technical discussions about Mediawiki, but never enough, in my opinion. This one had more than usual, though, and a lot of interest among the attendees, so that was a very positive step. As always, I got to talk to other developers, and as always I got to meet some of them for the first time – like Niklas, two ahead of me on the contributors list.
• The next Wikimania will be in Washington, D.C. At the end of the conference, the D.C. organizers gave a shambolic presentation that I think had everyone worried. Still, the conference will be in the U.S., which gives them a huge natural advantage in terms of getting both attendees and speakers. I plan to be there, in any case.

And, since we’re a Semantic MediaWiki-related company, some Semantic MediaWiki-related comments:

• There was one directly SMW-related talk, given by Denny Vrandecic, Daniel Kinzler and me. The talk was mostly about adding SMW to Wikipedia, and not about the software per se. Denny talked about the basic premise of SMW, I went into the details and showed some demos, and then Denny and Daniel talked about the planned upcoming “Wikidata” project, which is meant to supply infobox data to all the different language Wikipedias (and, via RDF, to the world), using SMW as the backend. We had 40 minutes to talk, but we could have easily talked for twice that long – we barely talked about the Semantic Web, didn’t mention projects like DBpedia and Freebase, and the SMW demos were quite minimal. Also, there was a packed room, with about 60 people, and lots of questions and comments at the end. Anyway, you can find more information about the Wikidata proposal here.
• Wikimedia operations guy Ryan Lane gave a talk about the WMF’s server management, where he mentioned that Semantic MediaWiki was used to store details about their setup. (You can see an explanation of that here.) That was pretty cool.
• There was a session called “Ask the developers“, where I found out about the MediaWiki style guide, which I hadn’t seen before. It’s awesome, and I’ve actually already modified the error-messages display in Semantic Forms to match what’s in the guide.
• As at previous Wikimanias, there was a good amount of discussion about making editing easier, both of template calls and of wiki syntax in general. Brion Vibber, the head MediaWiki programmer, talked about it a few times, as did Sue Gardner, the WMF executive director. And Jimmy Wales focused a lot of his talk, which was the final talk of Wikimania, on improving the interface on Wikipedia to make things like requesting page moves easier. That last one is not directly editing-related, but it does tie in to making smarter, more user-friendly interfaces. If anything comes out of either initiative, it will undoubtedly be interesting to the Semantic MediaWiki community.

We had over 30 attendees, from all over the United States in addition to Germany, the Netherlands, China and Japan. The plurality, though, and maybe even the majority, were from the area.

Some thoughts about the conference:

• The biggest discovery, in my opinion, was the success of the tutorial day. Previously we’ve always had two-day conferences, but for this one we added a third day at the beginning, which was intended to be strictly for tutorials – letting people learn about the basics of MediaWiki, Semantic MediaWiki and its spinoff extensions. It was useful both in the context of the conference – so that people could attend having a good sense of what all the technology was about – and as simply a training session for the software. I led the first two of the four tutorial sessions. There were around 25 people attending – mostly people from the conference, although some attended only the tutorial day. Each attendee paid around $100 to attend (dinner included); which, as training sessions go, is very much on the cheap side. Still, the tutorial ended up basically paying for the rest of the conference, with a little bit of surplus at the end; which was a nice state of things.
• The rest of the conference was great too. As usual, we had a mix of talks by developers, users/administrators who shared interesting things they were doing with Semantic MediaWiki, and some talks on more general, sort of cerebral topics (like my talk about the future of semantic wikis). We definitely had more than enough material to cover both days.
• This was probably the most corporate and enterprise-y Semantic MediaWiki meeting yet. The conferences in the U.S. tend to be more corporate anyway than the ones in Europe, which tend to have a higher share of academics and “hackers”. But this one especially was pretty serious – lots of people representing various organizations, including, as you’d expect, many working either directly or indirectly for the U.S. government.
• I got to meet a bunch of people that I had only talked to online, which is always neat – there were probably about 10 people there that I had only talked to via email, wiki talk page, etc.
• We also had some celebrities – well, quasi-celebrities – in the group, including Sherrod DeGrippo, who famously (or infamously, depending on your opinion) shut down the wiki Encyclopædia Dramatica last month and redirected it to an awesome new Semantic MediaWiki-based wiki, Oh Internet. (When I first met her, I told her it was great meeting an internet celebrity – she was nonplussed, and responded, “I’m more like – what do you call the kind of celebrity that most people hate?” “Celebrity,” I answered.) We also had two semantic-web pioneers: Mike Dean from Raytheon/BBN (who helped to arrange the conference) and Mark Greaves of Vulcan. There was also my friend Mike Cariaso, who gets a steady stream of press due to SNPedia, the site he co-founded, most recently a nice writeup in Reason magazine.

The slides from talks have mostly been uploaded, and are linked on the wiki page. The talks were also videotaped, but the videos haven’t been uploaded yet. It’s in progress, though – another SMW user has graciously volunteered to help with the process, so my guess is that within a few weeks the videos will start showing up on of your favorite video-sharing sites.

The basic premise of the book is that the rise in popularity of tech products is very rarely a smooth upward curve: even for products that have a nice initial burst of popularity, it’s very difficult to move past the early user base and start to get acceptance among the general population (or the population who might use one’s product, in any case). That’s because those early adopters are usually the ones who already seek out and embrace new technologies; while the majority of people are either, in the book’s vocabulary, “pragmatists” (who just care about getting things done with a minimum of headache) or “”skeptics” (who actively dislike switching from whatever they’re using now).

When trying to move from the early adopters to everyone else, Moore argues, everything has to change: your marketing pitch, your sales strategy, the array of additional services and peripherals around the product (if any even existed), and even your company culture.

“Crossing the Chasm” then gives a prescription for the marketing and sales strategy to use: find a suitable niche market, and then put all your focus on that, trying to monopolize it to the greatest extent possible. The operative theory is that pragmatists and skeptics tend not to switch over to new technology unless they start to see people around them using it; so you need to focus on a very small group of people and keep marketing to it until many of them have become convinced by each other’s examples to start using your software. Once that happens, you can let your success among that group propagate out to related markets, to other departments within organizations you’ve already sold to, etc.

On top of that, there’s then a specific branding strategy, to use when marketing to that niche group: find the main software you’re trying to replace, then describe yourself as like that software, but with one improvement: the pitch should sound like, “it’s like X, but Y”. That applies even if your software has more than one benefit over your competitor: the key is, at all costs, not to confuse your potential new customers or overload them with facts, which would give them an excuse to tune you out.

There are some case studies cited in the book; the one that struck out at me was Documentum, a document-management software company which did just that – in 1993, after several years of flat revenues, they decided (based on reading “Crossing the Chasm”’s first edition, it turns out) to focus on a tiny niche: the regulatory-affairs departments at large pharmaceutical companies. As the book puts it, the company was paradoxically “reducing its market scope from ‘all personnel who touch complex documents in all large enterprises,’ to maybe one thousand people total on the planet.” It worked for them, though – they started doubling their revenues every year, they went public in 1996, and in 2003 they were bought by EMC.

Crossing the Chasm was first published in 1991, and then re-published in 2000 with extensive rewrites; the 2000 version is the one I read. So – is it still relevant?

There are ways in which “Crossing the Chasm” is an outdated book, especially for the open-source web software business. The overriding feeling of the book is one of urgency – in its parlance, you have to, with great discipline, “secure a beachhead”, before you can be attacked by rival companies or by “vulture capitalists”, VCs looking for struggling companies to buy up and exploit. The source of all that angst is that, for a company developing proprietary software, the “burn rate”, the amount of money it takes to keep the company going, pay developers’ salaries, pay rent on the office, etc., can be large – over $100,000 per year per employee, on average. For a 20-person startup, that’s over $2 million a year, so if you’re not making that much in revenue every year, you’re in constant danger.

There’s just less urgency in open-source. It’s true that some open-source software companies do follow the proprietary software model – the software is developed by a small group of people who work together in an office, and they just happen to release the resulting code for free. But I think that’s the exception: most of the time in open source, the development work is split between paid and volunteer developers, and even the software’s paid developers can be split among different organizations. (Also, developers often work remotely, saving on office expenses – though that’s happening more and more for propriety software as well.) All of that serves to keep development costs much lower for software of what I think is comparable quality.

Beyond that, the nature of marketing software in 2011 is almost another world from marketing software in, say, 1995. Back then, the success of the Netscape browser in getting market share through free internet downloads pointed the way of the future; but for the most part, software was sold in stores or through third-party sellers, and people learned about new software from their acquaintances, or through a network of salespeople, or by reading trade publications. These days all of those still exist, but we also have tech blogs, Twitter feeds, and web searches. And in the case of web software, people can instantly check out examples of the software in action. And in the case of open-source web software, they can also download it themselves and try it out for free. (Though proprietary software can also have free evaluation periods and the like.) Which means that, unlike 15 years ago, lots of people can find out about, and use, your software, without a single sales call having to be made (even if people still called on the phone, which apparently no one does any more).

(Finally, there’s a third major difference, which is that much of the software used these days is hosted directly on web sites – or “in the cloud”, as people like to say. And WikiWorks is in that business too, with the Referata wiki-hosting service. But my main topic here is Semantic MediaWiki, which has to be downloaded.)

With all that said, I think the book is still relevant. Human nature hasn’t changed in the last 20 years; most people still won’t switch to using software until they know that other people in their situation are using it. Which means that, given the choice, it’s probably better for one’s future success to have 100 people from the same industry or niche using one’s software, than to have 100 people randomly distributed in different careers around the world.

So where does that leave Semantic MediaWiki? (You could ask the same thing about MediaWiki as a whole, which is another interesting question, but for the sake of simplicity here I’ll just assume that the ideal installation of MediaWiki always involves SMW, and thus that the two are synonymous.) Our usage is right now essentially random, with some interesting pockets of adoption in different markets but no real pattern to it. There’s definitely an argument that we’d be better off focusing our marketing efforts. By “marketing” in this case, I mean the wording we use to describe the software, the kind of marketing documents we create, the types of conferences we attend, the blogs and publications we pitch to, and even potentially the kinds of peripheral software created.

The obvious next question, then, is which market, or markets, should be targeted. Interestingly, pharmaceutical companies – the niche Documentum started with – might be a good choice for us too. Pfizer already uses SMW, and another one, I’ve heard indirectly, almost started to use it for a major project, backed out a few months ago, but still may end up using it later. Pharmaceuticals have a combination of massive amounts of data; an always-changing data structure (because the concepts being discussed are always in flux), which makes creating industry-specific applications difficult; and massive amounts of money. The first two make SMW a good tool to use, and the third makes it definitely worth our while to get involved.

Another interesting niche is biotech companies, for much the same reason.

Another strong possibility is one or more sectors within the U.S. Government. There, too, there are massive amounts of data, and, for better or worse, massive amounts of money (at least at the federal level). WikiWorks has already done Semantic MediaWiki-related setup work for some U.S. federal agencies, and we hope to do more.

So those are some potential niches; what about a branding strategy? To the extent that there’s a single, identifiable competitor, it seems like it would have to be Microsoft SharePoint. So what’s SMW’s one advantage over SharePoint? Is it like SharePoint, but open-source? That’s certainly catchy, but there are already various other applications that bill themselves that way – which doesn’t mean, of course, that SMW can’t join them. (Very interestingly, the main application listed in that article, Alfresco, is, from what I understand, an open-source update of Documentum, produced by some of the same people. It’s all come full circle! Somewhat less interestingly, I once met the guy from Alfresco quoted in that article.)

SMW could also be “like SharePoint, but Semantic Web-enabled”, which is undeniably true, but maybe not very compelling at this point. And it could be “like SharePoint, but a wiki”, which is, I think, easier to understand, and possibly more compelling.

Any thoughts from the crowd? Comments, as always, are welcome.

Update: I just want to clarify that I’m in no way dismissive of all the many varied and interesting uses that Semantic MediaWiki has gotten so far, including among our clients and including wikis run personally by various WikiWorks members. I hope SMW continues to get lots of usage in all different sort of fields – all I’m trying to discuss here is where to focus future marketing efforts.

On Friday I attended the “Wikimedia Data Summit”, which was held at the O’Reilly Media offices in Sebastopol, California. It was a one-day event, that was actually more like three summits, on three different topics. The first, and the one I was involved with, was meant to discuss plans for making the Wikimedia projects, mostly Wikipedia, more data-focused: essentially, the “Semantic Wikipedia” dream that some people have had for a long time. The second was a discussion on how to improve the web analytics of Wikimedia sites: improving the info and visualizations gathered about page views, editing statistics and all that. And the third was a smaller discussion about improving MediaWiki’s wiki-text parser.

The day started with everyone in the same room, first with an introductory talk by Erik Möller and then with 10-minute talks by various people related to each of the three main topics. Six of them were related in some way to Semantic MediaWiki:

• I was tasked with explaining all of SMW and its family of extensions in 10 minutes (which I sort of managed to do, barely)
• Denny Vrandecic talked about Shortipedia, his new-ish SMW-based research project
• Michael Erdmann from ontoprise talked about SMW+
• Christian Becker, best known as one of the DBpedia people, talked about his work on the SMW+ Linked Data Extension
• Mark Greaves from Vulcan talked about Ultrapedia, Vulcan’s demonstration of an SMW-annotated subset of Wikipedia
• Michael Dale talked about the MetaVid extension and website

You can see the notes from that first session here; and, if you’re curious, you can see the slides from my talk here.

We then split up into three groups, and I joined the “Semantic Wikipedia” group, which was led by Erik, and included the six SMW-related people, as well as people from Google, Freebase (although that’s technically Google too), DBpedia and some other groups. I volunteered to be the note-taker for the discussion, and you can see my notes here.

The basic goal, as Erik defined it, is that they want to create a “Wikimedia Data Commons”, in the spirit of Wikimedia Commons – a single site that would serve as a data repository for all the different language Wikipedias. Facts would be entered there in the form of semantic triples, although really they would include more than three things – besides the fact itself, there would be data like the source (which might include a URL), the date, the language that the information is in, etc. Every Wikipedia could then somehow query that data in order to display it within infoboxes; and the data could also be queried by outside applications.

Ultimately, this project is Erik’s own, and it became obvious early on that his preferred approach was to use Denny’s Shortipedia as a basis; actually, it turned out that Shortipedia had originally been developed, about five months ago, after discussions with Erik. If I can give my own perspective on Shortipedia: it’s a fact-based approach to data, as opposed to Semantic MediaWiki’s generally page-based approach. As far as I know, Shortipedia uses SMW mainly for its pre-existing database tables, as opposed to making use of much of the logic in the SMW code. Actually, Shortipedia reminds me more than anything (as I told Denny when he first showed it to me) of other semantic wiki applications I’ve seen, like AceWiki and OntoWiki. In the non-SMW semantic wikis, the semantic stuff is generally kept separate from the other content, and there’s usually some sort of mini-form that lets you keep adding triples to a page. That approach generally, from my experience, works poorly for individual wikis; but for a massive data repository like the “Wikimedia Data Commons”, it may well be the right way to go. So there you have it: if you want to see the future of data on Wikipedia, Shortipedia might be it.

As far as the event itself: if I had planned it, I would have done various things differently. The major issue was that I didn’t think all three events should have been held together. The three topics are rather discrete, and I didn’t think there was much “synergy” generated by putting them all under one roof. Worse than that, it meant that various people who ideally would have taken part in two or all three of the meetings (like many of the Wikimedia development staff) could only be in one.

As for the the semantic/data part of things, advance notice that Shortipedia was the way things would probably go would have been helpful – I would have spent more time beforehand thinking about the ramifications of it, something I only really started doing today. As it was, the most helpful thing I contributed at the time was probably my note-taking skills (which I’m proud of, by the way!)

Anyway, the big takeaway from the meeting wasn’t my somewhat underwhelming experience, but rather the fact that there now appears to be at least the beginnings of a path forward for data on Wikipedia. That’s probably the more important news, in the greater scheme of things. :)