Using SMW for content management


Jump to: navigation, search

Sep 15 2007. After quite some setup time, I finally got a first functional version of my homepage running. As this probably is also the first example of how to use Semantic MediaWiki as a personal content management system, I will take some time to explain the necessary setup steps. now displays my latest notes on its front page, and this feed is created automatically whenever I add a new note. Moreover, the site now contains most of my publications, and they can be accessed in many ways:

All of those pages access the same information, just like in a typical database application. The difference is that I am not using a customised database application but an off-the-shelf (free) wiki engine. Of course this was incredibly much simpler than creating a new database application that fits my needs. Here is what I did.

Edit: This note applies to an early alpha version of SMW1.0. Everything still works for the final version of SMW1.0, but many restrictions do no longer apply. For instance, SMW1.0 offers RSS feeds now.


Initial setup

Naturally, you need to use MediaWiki as your homepage, so the first step is to install it. Instructions are found in MediaWiki's online manual. In addition to MediaWiki, I installed the following extensions:

Since I do not want anybody to edit my homepage, I inserted some restrictions into MediaWiki's LocalSettings.php:

$wgShowIPinHeader = false;

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read']          = true;
$wgGroupPermissions['*']['edit']          = false;
$wgGroupPermissions['*']['createpage']    = false;
$wgGroupPermissions['*']['createtalk']    = false;

Also, I found that my Sept 2007 version of the ParserFunctions would not work properly with SMW's query functions unless I also added some further lines to my LocalSetting.php, as described on this page.


The main barrier of using MediaWiki to manage your homepage is skinning, i.e. visual adjustments. If you are fine to have it look like Wikipedia, then this is not a problem, but most people prefer some more individual style for their homes. How to achieve this is beyond this note, but instructions are given in MediaWiki's online manual and elsewhere on the Web.

You probably also want to edit things like the page MediaWiki:sidebar that defines your main navigation.

I also configured SMW to not display a Factbox below each page, since it did not fit into the style of the rest of the site. This can be done by adding the following line to LocalSettings.php:

$smwgShowFactbox = SMW_FACTBOX_HIDDEN;

Note, however, that the factbox is a helpful tool whenever something does not work as expected, so you might want to turn it on at least for debugging (future versions of SMW might have more modes for enabling the Factbox only during editing or for allowing it to be collapsed).

Automatic «news feeds» with SMW

Once your homepage is installed and looks basically like you want it to, you can go on and create content. I think the simplicity of adding and modifying pages in a wiki already is worth the above effort, but of course we would like to have some more features as well.

One thing mentioned was the «feed» of current notes or news on the front page. This feed is created by SMW by means of an inline query, a simple query whose result is embedded into another page. In our case, the result of this query is the short list of recent notes. Basically, every entry in this list corresponds to some page in the wiki, i.e. I create a new page for every note I want to post. In order to keep my wiki clean, I therefore created a new MediaWiki namespace called «Note» by inserting the following into my LocalSettings.php:

global $wgExtraNamespaces;
if (!is_array($wgExtraNamespaces)) {
$wgExtraNamespaces = $wgExtraNamespaces +
                     array(120 => 'Note', 
                           121 => 'Note talk');
global $smwgNamespacesWithSemanticLinks;
$smwgNamespacesWithSemanticLinks[120] = true;
global $smwgQDefaultNamespaces;
$smwgQDefaultNamespaces = NULL;

The number 120 was chosen rather arbitrarily, but it should be even and above 105 (which is the last namespace used by SMW). The last four lines ensure that SMW uses the new namespace properly. We ensure that SMW will evaluate annotations on the new namespace, and then disable any default namespace restrictions (normally, SMW will only return query results from the main and image namespace, unless overwritten). There now is a new namespace «Note:», and you can create pages there or inspect its contents via Special:Allpages.

Inline queries in SMW are a means of embedding a list of results into a page. A simple example query could look as follows:


It will merely retrieve all «Note»-pages in a long, comma-separated list. We would like some adjustments:

  • at most 3 notes should be displayed,
  • there should be a link to further notes, if applicable,
  • all displayed notes should provide some «preview» of their content, and
  • the most recent notes should be displayed on top.

The limit and the link to further results is realised easily:

<ask limit="3" searchlabel="older news …">

Here we use searchlabel to modify the link text shown for further results, but the link would be displayed anyway (unless a blank label was given).

The next task is to show a brief preview for each note. I found that the most convenient way of doing this is by using the query format embedded:

<ask limit="3" searchlabel="older news …"
format="embedded" embedformat="ul" embedonly="true">

The format embedded insterts complete page texts for every query result. In other words, every page that is found as a result to the above query is completely embedded into the page where the query is used. The parameter embedformat says that we would like a bulleted list for the results, and embedonly ensures that page titles are not shown (i.e. it does not matter how the note-pages are actually called, unless somebody clicks on them).

But, obviously, this cannot be quite right: if the whole text of a page is embedded in the result list, this would be far too long for a decent «preview» in some cases (consider, for instance, this lengthy note). Since SMW has no mechanism for creating short preview texts, it is necessary to control manually what gets embedded. Luckily, MediaWiki has simple tags for this, called <noinclude> and <includeonly>. Everything enclosed in <noinclude> will not be displayed in the embedded query results, so for long articles one merely puts, say, everything beginning with the second paragraph into <noinclude> tags. The query then will only show the first paragraph. But of course we would also like to show a link to the full text, and <includeonly> can be used for this. On this page, for example, the first pragraph is followed by:

<includeonly>[[Note:Using SMW for content 
management|Read more …]]</includeonly>

We thus already have a simple way controlling what will be shown as a preview for each note. Finally, we need to ensure that the most recent notes are shown on top. For this purpose, we assign a date to every note. First, create a suitable page such as Property:News date (or however you want to call the property). On this page, insert a text like:

This property specifies the [[has type::Date]]
of some note.

The essential part, of course, is the annotation in square brackets, but it is good style to make pages human readable as well. Now there is a property news date that can be assigned to any page. We do so by entering an annotation on each note-page. This page, for instance, starts as follows:

''[[News date::Sept 15 2007]].'' After quite some ...

There are other possible ways of writing the date here, and of course you can write it anywhere on the page. If you want to completely hide it from readers, you can use an annotation of the form

[[News date::Sept 15 2007| ]]

somewhere at the bottom of the page. So now all notes have a date and we can modify our inline query to display them accordingly:

<ask limit="3" searchlabel="older news …"
format="embedded" embedformat="ul" embedonly="true"
sort="news date" order="desc">
  [[News date::+]]

We now replaced the old criterion [[Note:+]] by [[News date::+]], i.e. now all pages with a news date will be dislayed, no matter whether they belong to the namespace Note or not (as I said, the namespace is really just for housekeeping in the wiki). By the parameters sort and order the results will be sorted by the news date in descending order, i.e. with latest date on top.

This finishes the simple news feed: now whenever you add a page that has some value for News date, it will automatically appear on the front page at the top of your news section. Since MediaWiki has many caching mechanisms, it might be that the page with the query is not updated instantly. To enforce this, you can chose the action «refresh» for this page (in the toolbar with «edit»). In any case, the cache will be refreshed after some time.

As a final tweak, I modified the query to

<ask limit="3" searchlabel="older news …"
format="embedded" embedformat="ul" embedonly="true"
sort="news date" order="desc">
  [[News date::+]] [[News date::*]]

This states that the value of «news date» should also be displayed as part of the result. It is quite useles for the output format that we have chosen, but if the list of your notes gets longer than 3 (or whatever threshold you use) then the link to older news will lead people to Special:Ask which currently uses a tabular output format. At this point it is nice to display the date as well. Maybe future versions of SMW will support the use of the format embedded with Special:Ask.

Edit: I found that a dedicated blog page, where notes get more space and a dedicated heading, is more convenient. Thus I created a new page which contains the following query:

<ask format="embedded" embedformat="h2"
limit="10" sort="news date" order="desc"
searchlabel="Look up older entries …">
  [[News date::+]] [[News date::*]]

All the basics are the same as above, but embedformat now is set to h2, while embedonly is missing. This creates level 2 subheadings for each note.

Towards wiki-based blogging

The above gives you a simple way of creating up-to-date news entries on your homepage. Every news item will have its own page and its own (persistent) URL. It also inherits unicode support and printability from MediaWiki. Sounds almost like a decent blogging engine, doesn't it?

Well, one thing that we miss are comments. It is well known that bloggers live from comments, and certainly want to get feedback to their writings. Enabling this is problematic on MediaWiki. It would be possible to allow editing on talk pages, but even this is not quite as convenient as a proper comment system on a blogging site. Maybe the upcoming(?) LiquidThreads will provide a better alternative.

The second thing are tags. Every decent blog uses some tags to categorise entries. But this is rather easy in SMW: you can add arbirtary categories to pages. For example, you could write [[Category:Semantic MediaWiki]] on some page related to this topic, and then use a query like

<ask limit="3" searchlabel="older news …"
format="embedded" embedformat="ul" embedonly="true"
sort="news date" order="desc">
[[News date::+]] [[News date::*]]
[[Category:Semantic MediaWiki]]

to retrieve all news relating to this. One place to put such a query might be the category page itself. Overall, SMW has much more powerful methods for filtering query results than most blogs: if you care to enter the required information in your wiki, you could easily make a query that shows only news that were posted within the year 2007 by an author who has written a book on the same topic. So there should be little restrictions here.

Finally, blogs normally offer various kinds of RSS feeds to enable subscriptions. This functionality is currently not supported by SMW (since it is really not meant to be a blogging tool in the first place), but it could be added if someone needs it. In fact, this boils down to adding another kinds of output format to SMW's query mechanism. At the moment, SMW has the more generic OWL/RDF feeds, which are mistaken by some crawlers as RSS 1.0, but which normally need some specialised tool for processing them.

Adding further features

As mentioned above, also contains many dynamic lists of publications. Since this text is already quite long, I will defer the description of those features to a later note.

Personal tools