Hierarchy in Properties Using Semantic Mediawiki #arraydefine and #arraymap Magic

At work, I’ve been working with our HR reps to develop something we’re calling Career Learning Maps.  The Learning Maps are a way of determining the various opportunities via career level (Positions such as Associate, Senior, Lead) and the skills required at each level. For each skill we’d have a list of suggested Learning Resources such as books, videos, seminars, etc. that assist in developing those skills.

For example, today you might be a Senior Database Engineer, but you’re looking to move up to Lead Database Engineer. What skills are required at this new level? Or what if you’re currently an Associate Technician, but want to move toward a Management position?

The Learning maps can help you understand the various job descriptions and associated attributes available to co-workers.

Since we already have Semantic Mediawiki as our knowledge repository for our department we decided to leverage its capabilities to deliver the Learning Maps.

One of the issues I was running into was figuring out a way to develop a hierarchical list of skills. Each skill is related to what we’re calling a Skill Dimension. Think of the dimension as parent groupings of skills. Business Acumen is a skill dimension that includes the skills of General Healthcare Industry KnowledgeProcess Improvement and Business Process Management among others.

I figured out a cool way to use #arraydefine and #arraymaptemplate to create a hierarchical list based upon properties. This list appears on each individual Job Description and shows the relationship between the career level, related skill dimensions (to that career level) and individual skills organized by skill dimension. Check this out:


Each job description is semantic form/template driven, as is each career skill dimension and career skill.

 

—-

Here’s the code – in case you might want to use it in the future.

In the Job Description Article Template (after building your form/template to include these properties!):

{{#arraydefine:levelsman|{{#arraymap:{{{Career_Level|}}}|,|@@|@@}}|,}}

(This defines an array using the specific job description’s career level.)

{{#arraymaptemplate:{{{Skill_Group|}}}|Career_Skills_Dimension_Template|,|
}}

(Ok, how many Skill Dimension apply to this job description? Give me a list and format it with a template.)

In a template called “Career_Dimension_Group_Template”

'''[[{{{1}}}]]'''<br>
{{#ask: [[Category:Career Skills]]
[[Skill Dimension::{{{1}}}]]
[[Career Level::{{#arrayprint:levelsman | }}]]
|link=none
|order=ASC
|format=ul
|default=No Skills Listed
|searchlabel=
}}

(Spit out a Skill Dimension, followed by an #ask that lists all relevant skills that are both part of that group and at the same level as this job description.).

The best part is that each property value is a page, so I can change “link=none” to “link=all” to have each skill in each group be a link to that individual skill’s article as well!

—-

To expand this even further, I’ve created a matrix listing all Skill Dimensions by Career Stream (Management, Professional, Technician) in a matrix with each Career Level. Co-workers can use this to easily see which skills are relevant across a given level or dimension.

While not very attractive, each cell in the matrix has a variation of the following #ask query.

{{#ask: [[Category:MTS Career Skills]]
[[MTS_Career_Level::Executive Director]]
[[MTS_Skill_Dimension::Strategic Focus (Management)]]
|link=all
|order=ASC
|format=ul
|default=
|searchlabel=
}}
The MTS_Career_Level and MTS_Skill_Dimension property values change for each cell.

—-

All together this creates a responsive and scalable solution to manage these relationships. Adding a new skill, resource or job description automatically updates all areas. In fact, most updating happens via forms and templates so our HR and Training folks can easily develop these resources with minimal Semantic Mediawiki development.

I hope this might be helpful for folks using Semantic Mediawiki to show relationships between properties in an interesting or unique way. Let me know if you have any questions or feedback.

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.