YK: Chapter 19: Additional Semantic MediaWiki functionality

19 Additional Semantic MediaWiki functionality

There are over 50 extensions that make use of Semantic MediaWiki. Many are unmaintained or obsolete, so that number gives a false impression, but nevertheless there is a variety of interesting SMW-related functionality that hasn’t been covered yet in this book. In this chapter we’ll briefly go over some of it.

Semantic Drilldown

The Semantic Drilldown extension offers a drill-down interface to browse the data in each category, available at the special page Special:BrowseData. Each filter for a category corresponds to a single Semantic MediaWiki property. Figure 19.1 shows an example of the interface created by Semantic Drilldown, for a hypothetical wiki about astronomy.

Figure 19.1 Special:BrowseData page, from the Semantic Drilldown extension

The “BrowseData” page lets you browse one category at a time. Note the list of categories on the right-hand side: each of those is a link, to let you browse and drill down through that category’s pages. The Semantic Drilldown interface shows, by default, the full set of top-level categories in the wiki (i.e., categories that do not have a parent category). Subcategories within each category are shown as additional filters.

Each defined filter lists the values that exist for that filter, along with the number of pages that match that value. Already, before even clicking on anything, the user is getting a lot of information:

The number of pages in the wiki, in every main category.

An alphabetical listing of the pages in the current category. (Though this isn’t shown in the screenshots presented here.)

The list of fields (or at least, a subset of them) that each page in the category holds.

The breakdown of the data, including subcategories, in the current category.

Any discrepancies, misspellings and gaps in the current data. The “None” values, for instance, indicate the number of pages that don’t have a value for that field. There’s no opportunity to see misspellings in the screenshots shown here, because all of the filters are either numbers or a combo box that has to be clicked on, but if there were a filter that showed a set of text values on the screen, then misspellings would easily jump out.

Figure 19.2 shows how that page from before would look, after the “2,000 - 3,500” value is clicked for the “Diameter, in miles” filter.

Figure 19.2 Special:BrowseData, after a filter click

The header has been updated; and the other filters show their new values, for only the set of pages that fit the already-selected criteria. Clicking on additional values will further reduce the set of results.

Hopefully, this helps to demonstrate the usefulness of the Semantic Drilldown extension, and more generally, of the approach known variously as “drill-down”, “faceted browsing” and “slice-and-dice”.

Such an approach can certainly be found elsewhere on the web, though the more common approach is field-based search, where users just fill in values for different fields and then hit a big “Search” button at the bottom. Standard search may be more popular just because that sort of search is easier to implement. But a drill-down approach offers a number of big advantages, as we’ve seen.

If you do want a more search-like interface (what’s sometimes known as “faceted search” in contrast with Semantic Drilldown’s “faceted browsing”), you should instead use the “run query” option in Semantic Forms (see here).

Setting up filters

The interface available at Special:BrowseData is useful even if you don’t create any filters, since it lets you view all of the wiki’s categories and their pages in one place. However, it’s even more useful if you do create filters. The easiest way to create a filter is via the filter-creation helper form, available at either the special page Special:CreateFilter or by directly going to a filter page that doesn’t exist yet and clicking on the “Create with form” tab.

Figure 19.3 shows how the page Special:CreateFilter might appear for this astronomy wiki.

Figure 19.3 Special:CreateFilter page from Semantic Drilldown extension

Most likely, all you will need to fill out in this form is the top two fields ­ the name of the filter, and the property that it covers ­ before hitting “Save page”. (And if you’re reaching this form directly from a new filter page, you won’t even see a “Name” field, since the page’s name has already been set ­ you just need to set the property dropdown.)

Every filter corresponds to a single semantic property ­ it lets you filter pages based on those pages’ values for that one property.

Regardless of how this helper form gets filled out, what ends up on the filter page is a set of wikitext, which is mostly comprised of Semantic MediaWiki property tags. Let’s go through those now. (They’re especially useful to know about if you’re editing an existing filter, because the helper form only lets you create new filters, or overwrite the contents of existing filters ­ it doesn’t help with editing existing contents.)

A filter is defined in a page in the "Filter" namespace. To use the example from before: let’s say that those value for “Has rings” are set by a property also called “Has rings”. (The filter and property don’t have to have the same name.) To define a filter called "Has rings", that filters on the values for the "Has rings" property, you would need a page called "Filter:Has rings", that contains the following:

You can change the display name, or “label”, of each filter, using the “Has label” special property. For instance, maybe the “diameter” filter in the example is just at the page “Filter:Diameter”, but you want the text to be “Diameter, in miles”. This would be done with text like the following:

So, you’ve created a filter. Now, how do you get it show up in Special:BrowseData for a certain category? To do that, you just need to link to the filter from the category page using the special "Has filter" property. For our example, in the page "Category:Planets", you would add something like the following:

There’s an alternate way to create filters for categories, which is via the Page Schemas extension (see here). This approach involves storing the filter data via XML and thus doesn’t involve filter pages at all ­ which might be conceptually simpler.

Setting display of results

The tag-cloud-style display of results in the example shown, where the font size of a value is determined by how many pages it has, is not default behavior, but it can be done by setting the values of the variables $sdgFiltersSmallestFontSize and $sdgFiltersLargestFontSize in LocalSettings.php. Here were the settings used for this particular display:

$sdgFiltersSmallestFontSize = 12;

$sdgFiltersLargestFontSize = 21;

You can also change the display of the result pages, to show them in, say, a table or a map, instead of just as a list of page names. To show results in a table, you could add something like the following to the category page:

There are various other features in Semantic Drilldown: you can manually set categories to appear or not appear in the list of categories (using the strings “__SHOWINDRILLDOWN__” and “__HIDEFROMDRILLDOWN__”), you can change the list of categories to show up as horizontal tabs instead of a vertical list, you can have certain filters only show up after other filters have been clicked on, etc. For more information and options, see the Semantic Drilldown homepage, at:

https://www.mediawiki.org/wiki/Extension:Semantic_Drilldown

Semantic Watchlist

The Semantic Watchlist extension lets users “watch” certain properties within certain groups of pages (i.e., categories, namespaces or concepts), in order to be notified by email any time one or more of those properties changes in any of those pages.

Figure 19.4 shows the interface, at the page Special:WatchlistConditions, that Semantic Watchlist provides for administrators in order to create watchlist groups for the wiki. Each watchlist group consists of a category, namespace or concept, a set of one or more properties to be watched, and then optionally some specific text that users get emailed with on certain combinations of property and value.

Semantic Extra Special Properties

The Semantic Extra Special Properties extension lets you store additional wiki-specific metadata about each page, as semantic values that can be queried elsewhere. Among additional values that can be stored for a given page are: the user who created it, the set of all users who edited it, the number of page views it has, the number of revisions it has, and so on. (These special properties come in addition to the standard ones that Semantic MediaWiki offers for storing basic page metadata, such as the date a page was last modified - see here.) For uploaded files, you can also store some of the “Exif” data that came with the file, if there was any ­ for example, for photos taken with a digital camera, the date the photo was taken. You can then query on that metadata alongside true semantic data ­ to find, for instance, the most widely-viewed pages from a certain category. You can read more about this extension here:

https://www.mediawiki.org/wiki/Extension:Semantic_Extra_Special_Properties

Semantic Tasks

The Semantic Tasks extension lets users receive an email when some date occurs, whether that’s a holiday, a meeting or a deadline (not all of these are “tasks”, of course). The emailing is entirely based on information stored via Semantic MediaWiki. To be part of the notification system, an event has to have its own wiki page, which should have dates stored with properties called “Reminder at” and/or “Target date” ­ these are both special properties. And the page should additionally have one or more values for the special properties “Assigned to” and “Carbon copy”, which determine the email recipients. “Assigned to” and “Carbon copy” don’t point to email addresses ­ instead, they point to user pages, and in turn each of those users needs to have an email address specified in order to receive the notifications.

You can read more about Semantic Tasks here:

https://www.mediawiki.org/wiki/Extension:Semantic_Tasks

SMW+/DataWiki

SMW+ was a package of MediaWiki extensions, plus some peripheral elements, developed by the German company Ontoprise; it was first released in 2007. Ontoprise shut down in 2012; currently, some of its former developers are at a new company called DIQA-PM, where SMW+ is still maintained in some form, now under the name “DataWiki” (not to be confused with Wikidata).

If SMW+/DataWiki can be described in brief, the software takes a more standard Semantic Web-approach to data than the extensions we’ve covered so far, enabling free-form annotation of pages, ontology browsing, and the like. That’s in contrast to the approach embodied by Semantic Forms, Semantic Drilldown, etc., where the details of properties and ontologies are hidden as much as possible from users. SMW+ also had two interesting additional extensions, one for WYSIWYG editing (which uses CKEditor) and one for access control. You can read more about DataWiki at http://diqa-pm.com/en/DataWiki.

Page Schemas

Page Schemas is an extension that aims to solve a general problem with Semantic MediaWiki and Semantic Forms, which is that long-term maintenance can be difficult. Semantic Forms offers various tools for automatically creating all of the data structure pages ­ the most popular being Special:CreateClass ­ but all of them create such pages from scratch; there’s no way to edit an existing form or template to, say, add one field; other than manually editing the page source.

It’s an alternate approach to data structure creation and maintenance that has started to gain more significant usage, as the software improves and as people learn about it.

With Page Schemas, you use a single “master” form to define the data structure; that form in turn creates a single piece of XML (stored on the category page), which can then be used to automatically generate all those other pages. You can then keep re-editing that schema, using a helper form, and re-generating all the corresponding pages. You can read more about it at:

https://www.mediawiki.org/wiki/Extension:Page_Schemas

Figure 19.5 shows an image of the interface provided by Page Schemas for editing a schema.

Figure 19.5 Page Schemas “Edit schema” screen