This article is not interested in making a neutral comparison — but instead aims at making a full-fledged argument for either why Semantic MediaWiki or Drupal is the better software.
- Semantic MediaWiki: If an online wiki/knowledge is the only requirement, then this a great option as it provides advanced wiki functionalities.
- Drupal: If there are varied sets of requirements, such as community functions, granular roles & permissions and configurable blocks, this would be a great choice.
Choosing between the two
Ease of Use
Drupal shines here with a WYSIWYG editor combined with an intuitive and enriched linking experience powered by the LinkIt module.
Linkit provides an easy interface for internal and external linking with wysiwyg editors by using an autocomplete field.
Semantic MediaWiki(SMW) on the other hand requires authors/content writers to learn Wiki markup. Not having the autocompletion feature and having to do the linking manually makes SMW trail behind Drupal in terms of ease of use.
Both SMW and Drupal can be themed and customised to a great degree, but since the Drupal ecosystem has a bigger community, the biggest open-source one in fact there are a large number of themes available that be used to customise the portal
— Drupal’s look and feel can easily be customised with themes.
— SMW’s UI/UX is a bit more rigid.
- Updates need to done as soon as a new release comes out, this is to safeguard against possible security vulnerabilities.
- Both Drupal and SMW can sit behind a reverse-proxy such as Varnish to safe guard against distributed denial of service attacks.
- Deploying as Dockerised containers on the Cloud, both platforms can scale to handle requests from different parts of the world.
- Varnish for server side caching
- A headless installation of Drupal can power client-side applications built with Angular, ReactJS, Polymer, etc.
- Both SMW and Drupal being open-source software are free to use.
- Development costs incurred are around the same for technologies.
- Drupal would be significantly faster as our team as a better command over the technologies
- SMW would take longer as we need to get more experience.
Maphub — An online application for exploring and annotating digitized, high-resolution historic maps. All user-contributed annotations are shared via the Maphub Open Annotation API. The first demo has been bootstrapped with approximately 6000 public domain maps taken from the Library of Congress Historic Map division.
- Annotation — easily added by creating overlays on top of map images.
A window will pop up, prompting you to add an annotation for that region. While you are typing your annotation, Maphub will suggest possibly relevant Wikipedia tags for your annotation.
You can either accept or deny these tags. Accepted tags will then be linked to the annotation and support multilingual map search and retrieval.
- Multilingual Search — Annotations and Control Points connect maps with globally connected data sources — such as DBpedia. It is then possible to exploit those connections to enrich annotations and their tags with additional information, such as the ability to search for a map by its content and not its title, and translations of terms in other languages.
- GeoReferencing — Control points may be added to each map.
Each control point is associated with known geographic coordinates.
After at least three of these points are added to the map, a geographic model can be computed for the map. Maphub will then be able to prompt the user with more locations as well as generate possible tag choices for annotations.
- Map Overlays
After adding at least three control points to a map it is possible to calculate real world locations for any point on the map. This allows us to create different views through Google Maps
and Google Earth.
The similarities between the two platforms are quite striking, both are like Lego blocks, you can combine these basic building blocks to realise any functionality with extensions in SMW and modules in Drupal
What Drupal has going for it
— Content types such as Book, Play, Scene, Act, Person, Article, Place, etc. with Schema.org Type definitions and Property values with suggestions for content architects while they’re creating these content types.
— Taxonomies that define structure to tags, hierarchical tagging is a breeze for content writers
— Roles & Permissions at a very granular level, you can give very specific specific permissions to a very specific set of people belonging to a so called role.
— Blocks make it easy for non-developers to place specific content blocks onto specific regions on all, a subset or individual pages. One specific block type “SPARQL block” allows pulling in Linked Data from the LOD-cloud. For e.g. Pages about Places in the Elizabethan era can be enriched with information from DBpedia(Linked data extracted from Wikipedia)
— Developer Community of Drupal is far more extensive than that of Semantic MediaWiki’s, there’s a module for everything.
— Blogs, Forums, Groups, Comments integrated into the platform giving users of the online wiki more of a community portal experience than a simple wiki experience.
— In addition of being a content management system, it is a development platform. So, you get all these cool things like third-party integrations, sub-systems built on top of sub-systems, and other efforts to create products out of the various contributed modules.
The niche is essentially creating complex sites that are powerful on the backend, and creating easy to use workflows and upgrade paths on the front end so communities can use them. The point is to leverage the power of Drupal and the contributed modules to get the web out of the way for people to make change.
What Drupal doesn’t have going for it
- No backwards compatibility.
- Having to augment the wiki-like functionality that SMW provides out of the box.
- Security vulnerabilities that any open-sourced software comes with
What Semantic MediaWiki has going for it
- Easy referencing, with reporting tools that assist in deepening buckets of knowledge (show me most referred to non-existent pages from a given category, please!)
- Robust taxonomies and semantic tools for structuring data in personally meaningful ways, but still easy to tweak as needed
- Decent search with additional options
- PHP app, easy to use with most familiar software stacks
- Transclusion. Makes templating amazingly straightforward, and cross-referencing can be wondrous.
What Semantic MediaWiki doesn’t have going for it
- Dependency management is complicated for semantic modules.
- URLs are machine-friendly at best. MediaWiki is the only software that doesn’t form lowercase, dashed words in URLs. Visually distracting when viewing an article on a MediaWiki site. Workarounds break some linking functionality.
- Themes in MediaWiki are not great. There is a design aesthetic to wiki dictated by Wikipedia, and we might just be stuck with it. Alternatives ask that content be changed in such a way that one can’t easily switch between skins, and that is even worst.
- MediaWiki markup is complicated to do normal things, and alternatives require additional server resources.
- Portability is an issue. One can’t copy and paste into a blog post, which is how it should work.
Who’s using SMW
TETHYS — A knowledge management system that actively gathers, organizes, and disseminates information on the environmental effects of marine and wind energy development.
Who’s using Drupal
Data.gov and many other government agencies
Other concerns for comparison
Performance Considerations: Although it may be harder to create
equivalent classes in Drupal than those made directly in the Semantic Mediawiki environment, which environment has better performance? Is there a distinct performance difference between a customized Semantic Mediawiki system and an equivalently customized Drupal system, regardless of how long it took to create either system?Look and Feel Programming: Is it easier to create and modify form / view (i.e. template) interfaces in Drupal using WYSIWYG layout tools, versus doing the equivalent by hand on the Semantic Mediawiki (for instance, using tables to place fields and preview to check the look)?
Neutralising the debate of ‘which is better’
One way to neutralise the debate of ‘which tool is better’ is to simply explain side by side how SMW does things, how Drupal does the same thing, and let people decide what fits their needs best.
For e.g. SMW automatically preserves internal hyperlinks when you rename a wiki page. Drupal doesn’t.
This is not saying Drupal is bad or SMW is good. If you don’t care about preserving links integrity across pages of the wiki, Drupal could work just fine.
Another example: SMW doesn’t have a WYSIWYG editor out of the box (but one is available as an extension). Drupal includes a WYSIWYG editor.
Copy/pasting content from emails or Word files into a Wiki page can be a critical feature for some people. Having a ‘source’ text free of superfluous markup may be more important for others (if you care about future export of your wiki to another platform for example).