Working With MediaWiki

such a category tag automatically, so that users don’t have to add it separately.
    In short, Semantic MediaWiki provides meaning to templates, while templates provide structure to Semantic MediaWiki; it’s a combination that works very well together.
    Let’s see how it works in practice. We’ll start with a simple example: a template that defines data for a page about an employee. We want this template to hold, for every employee, their phone number, email address and current position. Let’s say the template is called "Employee". A call to this template could look like:
{{Employee
|Phone number=x1234
|Email [email protected]
|Position=Senior accountant
}}
    (The employee’s name is not included in the template because it will be the name of the page.) Here’s how the relevant part of the template definition would look:
{|
! Phone number
| [[Has phone number::{{{Phone number|}}}]]
|-
! Email address
| [[Has email address::{{{Email address|}}}]]
|-
! Position
| [[Has position::{{{Position|}}}]]
|}
[[Category:Employees]]
    This code defines an infobox-style table, with one row for each parameter; and it stores each parameter, using a semantic property, at the same time that it displays that parameter. And note also that the template sets a category tag for the page — every page that includes this template gets automatically added to the “Employees” category.
    So now, adding the simple template call above to any page, with the relevant data filled out, will display the data, store it semantically for querying elsewhere, and add the page to the right category — all without any extra work needed on the user’s part.
    What if we want to allow a field to hold more than one value? Of course, there’s nothing stopping users from just entering a comma-separated list of values for a template parameter, but then the semantic property won’t be set correctly, as we’ll see in a moment. For such a case, there’s the #arraymap function. #arraymap is actually defined by the Semantic Forms extension, which is covered in the next section. (It’s somewhat of an accident of history that it’s defined in Semantic Forms, since there’s nothing semantic or form-based about #arraymap, but nevertheless that’s where it is.) We’ll get to the full syntax of #arraymap (and its sibling, #arraymaptemplate) later in this chapter — for now, let’s just look at an example of how it’s used.
    Say you want to add to the Employee template a new parameter, “Previous positions”, that holds a comma-separated list of all the positions the person previously held at the company. In other words, you want a template call to look like:
{{Employee
...
|Previous positions=Junior accountant, Accountant
}}
    In the template, you could of course just attach a semantic property like “Has previous positions” to the “Previous positions” field — but it’s much preferable to separate out the values in the list, so that each is its own property value. (Someone at some point might want to query on anyone who has had the previous position “Accountant”, for example.) To do that, we use the #arraymap function. Here is how the relevant lines of the template would look:
! Previous positions
| {{#arraymap:{{{Previous positions|}}}|,|x|[[Has previous position::x]]}}
    #arraymap splits up the value by the specified delimiter (in this case, a comma), and applies the same "mapping" (in this case, assigning a semantic property) to each resulting element.
    Now, there may be more information you want displayed about each of those previous positions — the start and end date for each, for instance. If you want to store this kind of compound information semantically, you’ll need to use special syntax (see here ). But in terms of simply placing these elements on the page, the template system can handle it quite well. To have such compound data, you just need to create a template that holds a single "row" of information, and then have repeated instances of it on the page. In this case, a good solution would be to have a template called "Position". It would eliminate the need for both the "Position" and "Previous positions" fields in the "Employee" template, and it could be called like the following:
{{Position
|Title=Senior Accountant
|Start date=January 1, 2009
|End date=
}}
    Each employee page would then have an instance of this template for every position that the employee has had, past or present.
    There are two standard ways in which