I’m a big fan of Panic Inc. I use Coda daily and am an advent follower of the smart dudes out of Portland.
They have a new app out called Status Board that allows you to mix different data sources to provide at-a-glance information on your iPad. What is even better is that it can output to a HD display for big screen status board updates.
At work I help manage a MediaWiki environment that we use to document stuff.1 Lately I’ve been trying to figure out how to leverage the MediaWiki API and the External Data Extension to manipulate data from external sources and content within the wiki.
With a few minutes time I figured out how display statistics from MediaWiki on a Status Board!
Basically I use the MediaWiki API to return some XML into a wiki page. That page is then in turn included as an HTML widget in Status Board. The result is something that looks like this:
Here’s the secret sauce. First create a wiki page to house your content. Then use the #get_web_data function of the External Data extension to pull in a xml feed from the MediaWiki API. Here’s what my code looks like for query of the number of jobs currently in queue.
Some other examples, as you can see in the screenshot above, are a list of the N newest articles, most recent edits, or even additions to specific categories (at the bottom). The sky is the limit!
Update: I tweaked the code after posting this. It’s been updated to reflect my working solution!
One of the great things about Semantic MediaWiki (SMW) is the auto-generated fact box at the bottom of any wiki page that has any values for semantic properties.
However, I found that it’s not very intuitive to navigate to a list of all values of a property and see what other articles have that same property value. In order to see a list of all articles that have a particular property value you’d have to navigate to an existing page with that property and then perform a semantic search from there. Or know that there’s a page called Special:SearchByProperty that you could use.
Example of Special:SearchByProperty results
I wasn’t satisfied with that, so I made a fancy list that’s actually really easy to implement and can be used across an entire SMW for other property values too.
The result is a list of all values for a given property that provide hyperlinks to a list of all wiki articles with that property value. It uses the Special:SearchByProperty page for displaying results.
First, I created a template called Property Values Columns. You can use it like so:
{{Property Values Columns|<em>Name of Property Here</em>}}
Here’s the contents of the “Property Values Columns” template3:
<noinclude>Use this template to list all the unique values for a given property.
== Template code ==
</noinclude><includeonly>
*{{#arraymap:
{{#arraydefine: valued
|
{{#ask: [[{{{1|}}}::+]] | mainlabel =- | headers = hide |? {{{1|}}} | limit = 10000|searchlabel= }}
|,| print=list, sort=asc, unique}}
|,|@@|[[Special:SearchByProperty/{{Space|{{{1}}}/@@}}{{!}}@@]]|
<ul>
<li>}}</li>
</ul>
</includeonly>
This is what it does.
1. Gets a comma separated list of property values for whatever property you’ve requested.
2. Parses the name of the property and each unique value to build a URL.
Example: http://wikiname.com/wiki/index.php/Special:SearchByProperty/Property Name/Property Value
3. The secret sauce is another template called ‘Space’ which uses the #replace function to replace all spaces ” ” with the “-20” syntax used in the Special:SearchByProperty query.
3a. The “Space” template contains the following:
{{#replace:{{{1}}}| |-20}}
4. Return the results as a series of list items.
The result is an list of all unique property values that when clicked will query the wiki for all pages containing that property value. You can then use some custom styling to format the results. In the example below I wrapped the template in a div creating two columns.4
As I’ve written about before, we use Semantic MediaWiki extensively at work. One way we use it is to handle research requests for or Solution Architecture team. We have a customer-facing form5 for all requests and the resulting page is accessible for anyone across the organization – sharing our findings beyond the original requester.
For any requests submitted, the form creates a new wiki article as a sub page of “Research”. This is done by adding an attribute of “query string=super_page=Research” to the form.
It helps us to keep things organized by denoting which pages are specific to research vs. general wiki pages.
The problem is how semantic queries display pages that have a ‘super page’ prefix. By default the query results will show the super page as part of the formatting.
Demo of a default query with no template
See the “Research/” prefix on every item? That’s rather redundant (and ugly), so I sought out a way to remove the ‘Research/’ prefix when displaying the results, but still provide the correct link to the sub page.
The magic is two-part. First, you need to make sure your #ask query has the attribute of “link” set to none (link=none) and “format” set to template (format=template)6. This strips out any default formatting of the results. Here’s the #ask query we’re using. Note you’ll obviously want to change the variables to fit your properties.
{{#ask: [[Category:Research]]
|?Research_Level_Requested
|?Research_Submitted_Date
|limit=15
|link=none
|format=template
|template=Research Results Template
|order=DESC
|default=No related research found. Submit a [[Research]] request?
|searchlabel=”’15 Most Recent Research Requests Loaded. View all Research?”’
}}
Then, for your template you’ll use the #arraymap function to format the output.
What this does is for each result it removes the “super-page” prefix (in this case Research/) from the first property returned – the page name.
{{#arraymap:{{{1}}}|Research/|
It then replaces it with the variable noSuperName.
|Research/|noSuperName|
Finally we actually construct a normal internal wiki hyperlink by adding “Research/” and the variable together in the proper syntax.
[[Research/NoSuperName|NoSuperName]]
The remaining variables {{{2}}} and {{{3}}} are called as normal and a break tag is added to keep each query result on its own line.
The result is something like the following screenshot.
Custom template sans-super page prefix
You will then have nicely formatted results that are easier to digest.
I hope this helps those looking to extend the semantic queries and produce clean, repeatable results. Let me know in the comments if you have any questions or ideas of your own.
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”.
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
|format=ol
|limit=10
|link=subject
|default=No related research found. Submit a [[Research]] request?
|searchlabel=More Research Information
}}
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.
