Category: Technology

Semantic MediaWiki Templates and #arraymaps are Awesome

Templates are awesome.

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 form1 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)2. 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.

{{#arraymap:{{{1}}}|Research/|noSuperName|[[Research/noSuperName|noSuperName]]}} – {{{2}}} – {{{3}}}

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.

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.

{{#arraymap:{{{RelatedTags|}}}|,|x|[[Research_Related_Tags::x]]}}

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
}}

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.

A Personal History of Digital Cameras as Presented by a Simple Chart.

 

As I was flipping through my now 120GB+ iPhoto library I realized that my family is now on our 4th digital camera. Above is the oldest photo I have. This was taken with my wife’s (then girlfriend) Olympus C-830L3. That was back in December of 1999.

Fast forward to today and here’s a shot taken with our newest camera.

My Dog at Night

Because I like visualizing information, I made a chart comparing all of our past cameras resolution against our most recent.

Click for 36.3 megapixels of chart love

This chart shows a 1:1 scale comparison between that first camera and our most recent – a Nikon D800. That’s a pretty substantial increase in megapixels. That’s to be expected, as we’ve gone from basic point-and-shoots to full-body DSLRs over the past 13 years. While megapixels aren’t the only improvement made since 19994, this is just one way of visualizing the dramatic improvements in digital photography since I started.

1.3 to 36.3 megapixels of history. I’ve loved every camera and I’m excited to see how things look in another 12 years!

Notifications are Bad and You Should Feel Bad

This is a rant against notifications.

Notifications are those things you have on your phone, tablet or computer that pop up in the corner of your screen when you get an email, meeting invite, Twitter reply, or a file change in Dropbox.

I’d even extend the buggery of notifications to the badge alerts for anything not mentioned in this footnote5. Why do I need a badge on my Draw Something icon? Of course there are people in there waiting for me to play. That’s the entire premise of the app!

If you’re like me, every time I see little red badge holding a number I get anxious. I need to check that app! I have to get rid of the number! I don’t care if my Aunt called me and left an important voicemail – I’m going to open the Phone app just to make the badge go away.

We don’t need the mental stress of being reminded of things that are not immediate to the work we’re doing.

Outlook has had these pop-ups for years6 and on the Mac, Growl has been around for a while and quite successful. Notification Center in iOS and now OS X Mountain Lion continue the trend of annoying people under the guise of productivity.

These things are useless. Out of the box, you’re likely to have half a dozen or more applications vying for your attention. The promise of notifications is that you’ll be more productive – quicker to react to things that require your attention.

After a few weeks with Mountain Lion, here’s the apps that are in Notification Center:

Not pictured: Twitter, Google Chrome, Tweetbot and Mail!

Notifications give you the false impression of being productive, but in reality they merely distract you from whatever focused work you were trying to accomplish. It’s a pavlovian response when you hear that ding that you need to act upon it. Most people, myself included, don’t have the willpower to simply ignore those chimes, dings and rings. We have to look.

I use to love notifications. I used Growl for a long time7, and when I got my first iPhone Notification Center was filled with dozens of apps. I use to think, “What if I get a Game Center request? What if I get a super awesome email at 11 o’clock at night!?

But that’s the rub, innit?

Notifications are useless. You don’t need them. They are distracting, they break your train of thought and inhibit your ability to focus on whatever task you’re working on. Even if you ignore them, your subconscious spends time pondering the content while you try to continue working on what is in front of you.

So here’s a challenge. Turn off some of  your notifications. Pick five apps that display a pop-up or a badge and turn them off for a week. See what happens. I bet dollars to doughnuts that you don’t notice they’re missing. You might even notice (see what I did there) that you’re a little more focused on the essential than the urgent.

Bonus: As I was writing this, my good friend and I cracked a joke.

 

 

Management vs. Leadership

I was listening to The Critical Path podcast last week while at the gym and had a thought.
(at 22:00) Horace Dediu says the following,
“The dilemma is that management and leadership are one of these water and oil types of things. It turns out that distinction between management and leadership: – Management is keeping things running. Leadership is breaking things and not keeping things running the way they are. 
Leadership is about change, management is about the avoidance of change. Many times we embody with the word manager both of these things. so there’s an almost implicit recognition of the duality of management.”
I keep hearing folks talking about how frustrated they are when dealing with management in relationship to the work they do. Some managers get the bigger picture, others are totally heads down and don’t want to be bothered.
Are we expecting too much out of managers? People whose job is to keep the status quo vs. leaders – those whose job is to disrupt that work?
—-
I sent the above to a few co-workers I admire. One of them had the following to say,

“My adage on organizational hierarchies:

If you aren’t thinking past the work of “management” then you shouldn’t be promoted past the level of “manager.”

Have I over-simplified sufficiently? “
Spot on.