Working With MediaWiki

calls to such templates can be added to a page. The first is to place the calls to the template after the main template, in this way:
{{Employee
...
}}
{{Position
...
}}
{{Position
...
}}
...
    And the second is to place calls to the multiple-instance template within the call to the main template, like this:
{{Employee
...
|Positions={{Position|...}}{{Position|...}}
...
}}
    We’ll see later in this chapter how Semantic Forms lets you create and edit pages with either of these structures.
    In theory, you could keep going down multiple “levels” of data — if you have embedded template calls, they could themselves have template calls embedded within them, etc. For instance, for each position you could then store the set of bosses the employee worked for at the time, with a start and end date for each. This is not recommended, though — one level of additional data is usually all that works in practice, mostly because Semantic Forms doesn’t support having more than one level of embedding, but also because that’s just too much complexity for most users to deal with.
    There’s one exception to that, though: if you just want to have a list of values for a field in one of those multiple-instance templates — for instance, if you just want to have a list of bosses for every position — that’s possible. Again, see here for a full explanation of handling compound data.

Introduction to Semantic Forms
    So we’ve covered the usage of Semantic MediaWiki and templates together, and why they’re such an important combination. Semantic Forms fills in the missing piece of the puzzle: an easy way to create and edit such pages. It lets you define forms for all your wiki’s different page structures, to let users then easily create and edit pages that contain template calls. The beauty of Semantic Forms is that users don’t have to know the syntax for template calls, and they don’t have to know the names of the templates to use, or the names of their fields. Really, they don’t even have to know that what they’re editing is a wiki page. All they have to do is fill out a form.
    Semantic Forms, or SF as it’s abbreviated, makes use of the data structure defined via SMW to display more intelligent forms. The form input that is displayed for each template field is by default based on the SMW property, if one exists, that corresponds to that field. So, for instance, if a certain template field is stored using a property of type Date, then SF displays a date input to edit that field. And if the property is an enumeration, i.e. it has a pre-defined set of allowed values using “Allows value”, then the form displays a dropdown for that field, with that set of values. The form can be set to override these default input type options, but at its core, SF uses SMW to understand and thus enforce the desired data structure for the wiki.
    On a deeper level, SF and SMW complement each other in an important way, which is that together they can be used to simulate a standard database-backed website of the kind one sees all over the web. We’re used to seeing data in terms of a structured set of fields, used to editing such data with forms, and used to then seeing that data be aggregated and displayed in various ways. That’s true for product-review sites, self-publishing sites like Flickr, YouTube or blogs, or any of a wide variety of content-management systems that people use for their jobs. SF and SMW together let you mimic that kind of interface. The user, importantly, just sees the interface: they don’t have to think about the wikitext or semantic markup, and are freed to think about the important stuff, which is the data itself. There are in fact many cases where users of an SMW/SF-backed system aren’t aware that the system they’re dealing with is semantic, or even a wiki.
    This brings up an obvious question: if it’s a great success for a wiki to mimic non-wiki software, why not just use that other software in the first place? That’s because using a wiki has a number of big advantages. The primary one is that the system keeps a version history of every change — which means that you don’t have to fear random users going in and modifying your data, because any bad changes can always be reverted. That in turn means that suddenly you can open up your data to editing by everyone, which is actually a revolutionary change. In most database-backed systems, tight controls are placed over editing — regular users