Limitations of Semantic MediaWiki

THIS IS NOT AN OFFICIAL DOCUMENT. The text below can be inaccurate or self-contradictory, please go ahead to add your limitations or object against the exising ones.

Semantic MediaWiki is good for some things and bad for some other things. In this page we explain when SMW is your best possible choice and when you should be ready for the complications.

SMW is awesome for

Using it for existing and working MediaWiki

If you have working installation of MW and people are happy with it: go ahead and install SMW: a lot of stuff will become much easier. For example you will have automatic lists and data representations.

Collaborative database management

Many people without technical knowledge can work together to create a database. All the goodies of a wiki, combined with some of the goodies of noSQL databases.

Simple network analysis

While not an alternative to Gephi or other tool, SMW still offers basic capabilities to browse and understand your linked data.

SMW is not that awesome for

Managing private data

Don't use MW+SMW if you want to manage private data with it, like credit card numbers, private comments, etc.

Implementing strict workflows

Write acces control is possible but it's hard to implement a strict workflow within SMW. Only one level of approvement is possible with ApprovedRevs/FlaggedRevs.

Example The simplest example is the workflow in a newspaper. First the reporter write the news page. Than the editor check if there's no factual errors. After that the corrector checks if there's no errors in grammar and style. You will face the difficulties

Representing complex data structures

It's hard to represent data structures in SMW: like trees/hierarchies, nested objects, etc. Learn the limitations of subobjects, property hierarchies and category hierarchies. If you need anything more than them, please prepare for coding.

Implementing complex business logic

Usually it's hard to implement a complex logic within SMW-based system. On the one hand all the logic implemented with parser functions, templates or Lua modules is dependent on page view. You can implement the logic with bots, but it won't be real time. You can try to implement it as your own extensions but it's tricky to assign new property values. The PHP API for accessing values is also not very cool.

Examples:

Unqualified users

You can't offer SMW-based system to completely unqualified users. Although Semantic Forms makes it easies to edit the data, there are still several limitaions.

Markup

The wiki markup is still here and there's no way to restrct its usage or escape it within the form fields. Wiki editing is something between the text editing and web development. There is no visual editor too since FCKEditor was deprecated.

Examples:

Uncomprehensible errors

One unpaired curly bracket in the textarea field or one wrong slash (|) can screw up the whole page appearance. If you've made a good job of hiding the wikitext from the view of users they will still see strange errors related to wrong values of the properties.

Examples:

Real time systems

Don't use SMW for real-time systems. SMW uses parser function mechanism so:

• the data gets updates when the page is viewed
• sometimes the data is cached and the data is updated when the page is edited
• #ask-query rarely use AJAX and are usually cached

Files and pictures

MediaWiki pays a lot of attention to files. The filename matters. The file has metadata, it can be categorized, you can create the whole wiki page about the picture file. You can't upload the same file twice. This is very different from many other systems where the picture is just a picture: nobody cares what's its filename or how many times have it been uploaded.