Glossaries in Semantic MediaWiki

A simple glossary system for Semantic MediaWiki that lets you define key terms for use in technical documentation etc.

A term can be referenced from anywhere in the wiki with {{defined term inline|term}}. This results in the term being displayed in a distinct style (green for instance) and linked to the term’s wikipage. When a user hovers over the link, a tooltip is displayed that contains the term’s definition.

Software required: MediaWiki, ParserFunctions, SemanticMediaWiki, SemanticForms.

Pages required:

  1. Defined terms
  2. Template:Defined term
  3. Template:Defined term inline
  4. Form:Defined term
  5. Property:Definition
  6. MediaWiki:Common.css (to change the style of the inline terms)
  7. MediaWiki:Common.js (to fix the tooltip display)
  8. Category:Defined terms (no content actually required, but probably should at least be categorized)
  9. Data pages

Continue reading Glossaries in Semantic MediaWiki

ReqWiki semantic software requirements management

ReqWiki is a Semantic MediaWiki-based system for software requirements management. It looks very interesting.

We know that requirements engineering has a large impact on the success of a project, yet sophisticated tool support, especially for small to mid-size enterprises, is still lacking. We present ReqWiki, a novel open source web-based approach based on a semantic wiki that includes natural language processing (NLP) assistants, which work collaboratively with humans on the requirements specification documents.

ReqWiki features three top-level wiki pages that are considered the entry points to the SRS documentation platform. They have been designed to guide stakeholders through the RE process (Fig. 3).

The top-level pages are as follows:

  • A Vision page to define the product position, stakeholders, assumptions, dependencies, needs, and features;
  • a Use Case page to define actors, goals, and use cases;
  • a Supplementary Specification page to define functional and non-functional requirements, standards, legal notes, test cases and traceability links.

The wiki pages are available on Github.

(Here’s a local copy of the PDF, in case the link above goes away one day.)

SMW suitability

Semantic MediaWiki can basically be coerced into doing whatever one wants. It’s powerful, and pretty easy to use, and works well for situations with lots of different types of things. The question is whether it is actually suitable, half the time.

Like a blog, for instance. Why would one use SMW over (say) WordPress? It seems to come down to how many other things one wants to do with the system. For example, blog posts might have photos attached, and if one wants to treat those photos as items in their own right (with authorship information, location, and other metadata, perhaps) then a straight-out blogging platform isn’t going to do that as flexibly.

See? I’m just trying to convince myself! I like MediaWiki…

:-)

Upgrading MediaWiki and SMW

I was updating MediaWiki to 1.17 last night, and kept getting a::

  Fatal error: Call to undefined function wfWarn() in /var/www/w/extensions/SemanticMediaWiki/includes/SMW_Setup.php on line 49

because I was setting up SMW with $wgServerName:

  require_once("$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php");
  enableSemantics($wgServerName);

and this has been deprecated in 1.17. As for why SMW is using the nonexistant mfWarn(), I haven’t got time to investigate.

Semantic MediaWiki and Me

Stone was right, that photo I posted last night of Sol-R was rubbish. I appologise. But I make no claims to be any sort of a photographer other than one who records the existence of things, and not their particular light-patterns. The photographic collection of 20th century telegraph poles notwithstanding, of course.

Which brings me to Semantic MediaWiki. Or, it doesn’t really, but through some elongated and multi-noded decision tree it does. I am trying to set SMW set up on the FS site, and it’s doing funny things to my head. I even had dreams about it last night! A strange feeling of being unable to bootstrap the whole show: one must set up these data entities (the templates; am I right here?), each comprising some number of properties, and without which it’s odd to set up other entities whose properties are of this entity’s type. Agh. Sleepy brain can’t handle!

Of course, the main problem is that I’m used to building data models in ‘proper’ programming languages, and SMW — or, rather, MediaWiki, with it’s horrible syntax, that I can see I’m just going to have to force myself to love — is a fairly different way of thinking. It’s not vastly different, because still we’re buiding a classic (as in, class-ic, or ‘of class’, as a lecturer of mine used to be fond of distincting [is that a word?]) system, where entities have properties, and those properties have types, and those types are entities. The weird part of it is that wiki pages define all of these, and they define the data!

The point that I’m getting to is that this should make more sense to an OOP programmer than more common ways of doing this. Because an object of a class encapsulates behaviour, structure, and data! So where’s my data in a Java app? In the flippin’ database! And in SMW? Right there: with the structure and behav… oh, hang on… this isn’t a programming language. It has aspects of one. But by gosh it’s annoying to code in….

Well. I didn’t think that out too carefully did I? A vaunting of SMW as somehow making more intuitive sense than a proper language? Silly me. I’m just getting tied up in all that persistent object storage stuff, and I don’t feel up to that on a Thursday (Thursdays are for visiting friends and having a little something, after all!) so I shall give up now.

I’ll get back to building a coming-events-calendar on the FS wiki, which, it turns out, is not such a complicated business after all.