Use Semantic Mediawiki & Semantic Forms to Create a Folksonomy for Tagging Related Pages

At work we use Semantic Mediawiki to augment an internal wiki running on Mediawiki. It’s used to house anything from process documentation to troubleshooting guides for our IT department. We recently figured out how to use Semantic Forms and the #ask function to create a customizable and reusable folksonomy. Read on to find out more.


One of the functions of my team is to fulfill research requests for co-workers within our IT department. These requests can be as simple as something like finding a white paper from a vendor or research organization, or as in-depth as custom analysis and reports of a given topic.

In order to handle these requests, we’ve created a submission and request fulfillment process using Semantic Forms.

Co-workers can fill out the form and we’ll use the resulting wiki page to fulfill the request.

One of the fields in the form that we use when fulfilling the request is an open text box for tagging related topic areas. Those fulfilling the research request can use a comma separated list of items to generate a folksonomy that can be used elsewhere on the wiki.

In the form we have the following. The property “Research Related Tags” is a property with the type of “Page”.

{{{field|RelatedTags|property= Research_Related_Tags |values_from_property= Research_Related_Tags}}}


Then for our template, we have the following.

{{Research Entry Template|RelatedTags=}}

The following is to query the semantic data and display it.


The #arraymap function pulls back the list of tags and displays them in the template.

For example, I might get a request for researching more about Hover Cars. Hover Cars might be related to other wiki pages such as our Transportation page or a page titled Automobiles. If I enter a comma separated list of related pages into the tag box when fulfilling a research request (such as ‘transportation’ or ‘automobiles’, links to the research documentation will automatically be created to any page that matches that name.

Now the cool part is that we have a lot of existing content elsewhere in the wiki and we could never predict what new content is going to be created.

What we’ve done, is to modify the default template for every wiki page to pull back any research documentation related to that page. If you were on our Automobiles page at the bottom would be a link to any research requests tagged Automobiles. Automagically!

Silly nonsensical test items all tagged with “Big Data”

To do this, we use the #ask parser function to query the “Research Related Tags” property, but only show research requests that match the current page name.

{{#ask: [[Category:Research]] [[Research_Related_Tags::~{{FULLPAGENAME}}]]
|? Research_Level_Requested = Research Type
| ?PAGENAME= Entry Title
|default=No related research found. Submit a [[Research]] request?
|searchlabel=More Research Information

The secret sauce is in this opening line.

{{#ask: [[Category:Research]] [[Research_Related_Tags::~{{FULLPAGENAME}}]]

This starts the inline query, limited to the Category of Research that has a value for “Research Related Tags similar (~ is a semantic wildcard) to the current FULLPAGENAME.

The rest of the ask command is pretty standard semantic media wiki syntax. The one additional item to point out is the default= condition. As I mentioned earlier, this query is on every wiki page and some (a lot of) wiki pages won’t have related tags.

If no research exists users are given the suggestion of submitting a research request. When new pages are created and they match existing research (or vice versa) this part of the page will automatically update with related research.


I hope this provides inspiration into a new way of extending the use of semantic data in your Mediawiki environment. Leave a comment if you have any questions.

4 thoughts on “Use Semantic Mediawiki & Semantic Forms to Create a Folksonomy for Tagging Related Pages”

  1. Hei Chris,

    I really liked your comments, and want to discuss further on creating the taxonomy or even the “ontology”. In my case I allow users to add topics (like lectures, thesis, meetings) and provide keywords to those pages.
    But it ends up that the list of keywords is exploding, and I have not found a good way in “relating them”:
    * within the wiki through Categories (cumbersome, and results are not that easy visible)
    * mindmap (good for visualisation, but needs an extra step to bring results to the wiki)
    * ontology through Protege (have not found the tool to import the results back into the wiki).

    How are you handling the explosion of keywords?

    Please check on or the list of keywords at

    1. Josef,
      The keywords will expand, yes. I’m afraid that’s the nature of an open folksonomy/ontology. I have a few ideas I’ve shared below – all off the top of my head.

      Autocomplete can help manage the open text field a bit, which I might suggest. You could even have a multi-select of the “keywords” displayed in the form with an ‘add your own’ text field below, both completing on the Category:Keyword. Users would first be prompted to select from existing keywords, but could also add their own.

      Another idea would be to include additional metadata in the form that could help slice information in new ways.

      Using the property type of “Page” (as you are doing) is a great start. Each keyword can have a standard template that not only lists articles with the property, but can also contain descriptive text or other associated information.

      You might even look into figuring out a way of using an #arraytemplate to embed an #ask query in said template. This might allow for more granular relationships across multiple criteria. I wrote about a use case that might be helpful here:

      Or, alternatively, don’t worry and let it grow!

      I like the word cloud of the most popular words in the Thesis Work and Courses. That’s pretty slick – in fact your entire wiki is impressive. I hope some of this rambling helps ideas pop up. I’d love to hear more!

Comments are closed.