Working With MediaWiki

can usually only edit information that pertains to them, while the editing of general-use information is restricted to a very small group of people who can be trusted to not delete important data, either accidentally or on purpose. And if mistakes happen, they may require a concerted effort to fix — like going through old database backups. On the other hand, with a wiki, having everything editable by everyone is no problem at all — in fact, it’s the default state. So if you’re trying to create a set of general data, you’ve just seen your potential base of editors jump up from a handful of people to, theoretically, billions — or, more realistically, hundreds.
    Even if you only want a small group of people to edit the data, though -- for example, you run an internal knowledge base for a small team of people within a company — having the data stored in a wiki is helpful. Let’s say that, on a page for a project, there’s a detail that you disagree with. On a wiki, a quick check of the history page would let you see who added it, and when — or whether you in fact added it yourself and then forgot. With a non-wiki system, the only real option is to send out an email to the group and hope that someone remembers; which becomes more difficult the larger the size of the data set, and the larger the number of editors, and the longer it’s been in place.
    There are two other advantages that an SMW/SF-based system has over non-wiki software. The first is the flexibility of the data structure; and it springs from the fact that the data, and the data structure, in the wiki are all stored as text, and not in a relational database. Text is a very flexible medium, and changes to the data structure can be both easily done and easily undone. You can thus open up editing of the pages that define the data structure — forms, templates and the like — to everyone, without the fear of having drastic, irreversible changes made. In a conventional database-backed system, the editing of the data structure, i.e. the set of database tables and their fields, has to be restricted to a very small group of technical experts.
    (To be fair, there’s a new wave of “document-oriented database” systems, like MongoDB, also referred to as “NoSQL” systems, that offer this same advantage of flexibility, though without the built-in interface tools.)

Getting started with Semantic Forms
    The rest of this chapter provides a breakdown of the syntax and workflows you can use with Semantic Forms. But if you’re just getting started, the best approach is to use Semantic Forms’ helper pages to quickly create pages. There are essentially five good options:
Use the page Special:CreateClass to create everything at once — categories, properties, templates and forms.
Use the individual pages Special:CreateProperty, Special:CreateCategory, Special:CreateTemplate and Special:CreateForm to create the entire data structure. This is a more hands-on approach, which is less ideal for starting out, but it’s quite useful if you already have templates and categories in place (and possibly properties as well), and only want to create what is still missing.
Similar to the previous option, you can go to any specific uncreated property, category, template or form page, and click on the “create with form” tab, which displays a form that matches the form found in the relevant one of those four special pages.
Copy from an existing installation or package. If you see a data structure setup that you like elsewhere, you can copy and paste all the necessary files to your wiki. (Though it’s usually a good idea to get their permission first, even if legally it probably isn’t necessary.) And there may be a package of such pages, created with a generic purpose like project management in mind, that you want to copy onto your wiki. At the moment, the company semantic::apps offers such packages, though not for free - see here .
Use the Page Schemas extension. See here for an introduction to this extension; it lets you create a set of “schemas” for your data structure, from which forms, templates etc. can be automatically generated.
    First, let’s look at Special:CreateClass. Figure 17.1 shows the interface that appears on that page.
    Figure 17.1 Special:CreateClass page
    Using this interface, you can define an entire “class” — a data structure to represent a single page type, which is composed of a template, a form, a category, and