Semantic MediaWiki vs. SharePoint

(For the purpose of this essay, we'll use the term "Semantic MediaWiki" or "SMW" to refer to the combination of MediaWiki, the Semantic MediaWiki extension, and the set of helpful extensions that exist around Semantic MediaWiki, such as Page Forms. We apologize for any confusion.)

Microsoft SharePoint is Semantic MediaWiki's biggest competitor. When companies and other organizations are considering using SMW for any sort of data management, SharePoint is the alternative they almost always consider, if they consider one.

SharePoint provides a variety of different functionality, but broadly speaking you can think of it as two things in one: a document-management system, and a content-management system. For the document-management part, SharePoint's specialty is providing a central, web-based interface to store and edit Microsoft Office documents: Word, Excel, PowerPoint, etc. For the content-management part, SharePoint provides a way to create standard "groupware" elements like wikis, blogs, calendar events, tasks, plus more free-form items.

If the main goal of your system is to manage Microsoft Office documents, then SharePoint is undoubtedly the way to go - no one handles editing of Microsoft documents better than Microsoft. However, for most organizations, content management is an important feature, or even a crucial one. And for content management, we think Semantic MediaWiki offers the clear advantage, in almost every way.

Semantic MediaWiki's main advantage draws from its simplicity. Instead of treating tasks, events, news items, etc. as different things, every item in SMW is the same thing: a wiki page. In SMW, it's the combination of templates, semantic properties and layout in a page that serve to specify its purpose, and its data structure. That simple approach offers a number of advantages right from the beginning:

• Flexibility. What if, in SharePoint, you want to add additional fields to an event, besides the standard ones? Or you want to have more than one kind of task? It's all doable in SharePoint, but it requires customization, and most likely some custom coding in Visual Basic - after which you have a set of proprietary code that you need to maintain. In SMW, conversely, the same process exists for creating any kind of page type, that involves only creating wiki pages and some markup within them. Unlike with SharePoint, there are no pre-defined page types like events or announcements. But once you get the hang of working with properties, templates and forms in SMW, creating any kind of page type, no matter how complex, becomes a fairly simple task.


• Complete version history. Having a version history for everything can be critical, especially when you have many users potentialy modifying documents at the same time. SharePoint has versioning - when changes are made to documents or to groupware items, you can track the changes, revert them, etc. But there are a lot of limits to SharePoint's versioning ability:
  
  
  • In SharePoint, you can check out a file for an unlimited amount of time, and make any set of edits you want, before checking it back in - if you do that, all intermediate edits will be lost.
  
  
  • Let's say, in SharePoint, that you have a page type containing some custom fields. You decide to remove one of the custom fields, but then a week later reconsider, and add it back in. All values for that custom field, both the most recent ones, and all previous ones, will be lost. With Semantic MediaWiki, on the other hand, every value that has ever existed in every page is preserved, even as the data structure changes.
  
  
  • In Semantic MediaWiki, changes to the data structure are themselves preserved in the version history. The entire data structure is defined via a set of wiki pages; so as the structure changes and expands, previous versions are automatically stored, and can be reverted to. In SharePoint, there's no record of previous versions of the data schema.
  
  
  • Pages that are deleted in Semantic MediaWiki are never truly deleted - they can always be restored by an administrator, along with their full version history, if needed. In SharePoint, deleted items are gone for good.


• Better tagging. There's one way in which SMW has an advantage over SharePoint even in dealing with Microsoft documents: improved tagging and classification of those documents. When you upload a file to SharePoint, the contents of the file, and its name, are all that's stored about it. So what if you want to find all documents relating to, say, hardware sales in Virginia? You need to see if a list of such files is maintained somewhere, or if all such documents are contained in a specific folder, or do a text search and hope that all such documents contain the words "hardware", "sales" and "Virginia". In SMW, every uploaded file has an associated wiki page attached to it, and you can easily set up a form for users to enter whatever metadata fields you wish to have for documents, to make searching and aggregating easier. The same goes for actual wiki pages: in SharePoint, you can create wiki pages, but you can't tag them - they are unstructured data. With SMW, as you might expect, a mostly free-form wiki page can still include a little bit of structured data at the top, to help in finding it later.

(An analogy can be made to the world of cooking: SharePoint can be compared to a large set of knives you can purchase, each one for a separate task: slicing vegetables, cutting meat, cutting bread, filleting fish, etc. Because the aim is to sell these in bulk, their quality is often low; but at least you know, right out of the box, exactly which knife should be used for which task. Many experienced cooks and chefs, though, use the proverbial "one good knife" for almost everything, because once they've gotten used to it, it can do almost everything they need. Semantic MediaWiki is like the one knife: once you understand how it works, you can do most things with it.)

Additionally, there are more weaknesses to SharePoint, unrelated to its data design:

• Security. SharePoint runs entirely Microsoft software, and while we respect Microsoft as a global software developer, there's no question that Windows NT, IIS and the like have a record of many more security vulnerabilities than the server software MediaWiki usually runs on, Linux and Apache. And MediaWiki's own security is provably strong, given that it successfully runs Wikipedia, one of the world's most popular websites.


• Cost. Finally, there's what some people consider to be SharePoint's biggest drawback: its cost. The cost of SharePoint is quite variable, and it depends on a number of factors, but it's undoubtedly expensive. Between the purchase of necessary software like IIS and SQLServer, and the actual user licenses, implementing SharePoint for a 1,000-person organization will most likely cost over $100,000. And that's not even counting the consulting fees, if you hire consultants to customize your SharePoint installation - they can easily cost even more than the software. In contrast, Semantic MediaWiki is free and open-source, and every piece of software it runs with can be similarly free and open-source: SMW usually runs with a combination of Linux, Apache, MySQL and PHP, all open-source. (PHP is required, and the other three are the standard options.) Implementing it of course takes time and/or money, but in our experience it's a different order of magnitude: the most we've heard of companies or organizations spending on MediaWiki or SMW implementation is in the tens of thousands of dollars, while some companies have been known to spend millions on SharePoint.

In fairness, there is one other major advantage to SharePoint, besides its ability to work with MS Office documents: its built-in access control. If you need fine-grained restrictions over who can read which pieces of data, SharePoint is the better tool. In practice, though, we've found that the need for such read-access control is usually minimal: information that's truly private is usually restricted to email or hard-copy anyway. And for good reason: once a piece of information or document is uploaded to a CMS, often simple human error can make it readable to everyone, no matter how good the access-control system is.

For some other features, SMW and SharePoint are comparable. In SharePoint, you can query SQL-based databases, and structured files like XML and CSV files. You can do all of that in MediaWiki too, using the External Data extension (though with SMW, unlike with SharePoint, you can also tie in to RDF-based data integration). And SMW and SharePoint both offer workflow-type functionality, in which certain events trigger pre-specified actions.

We encourage you to read more about Semantic MediaWiki (the extension), including viewing the testimonials for it. The SMW wiki of the month page showcases a nice collection of sites that have been using Semantic MediaWiki, and related extensions, for a wide variety of purposes. You may be surprised at how much sense Semantic MediaWiki makes as a way to manage your data.

Return to main page.