Semantic Forms for MediaWiki

Last time, I described the functionality of the Semantic MediaWiki plugin that allows you to manage the structured data in your system and create various representations based on it. Spoon of tar here is that users have to learn additional elements of markup.
Today we will talk about the expansion of the Semantic Forms , which allows you to make a wiki completely different from a wiki and bring a wider range of users to work.



Recall that the heart of Semantic MediaWiki is the mechanism of semantic properties. The purpose of the semantic property of a page, though similar to the simple creation of a wiki link [[ :: | ]] [[ :: | ]] , but, nevertheless, this is a new syntax. In addition, even if our users are so disciplined that they read and understand the property creation guide, they are unlikely to call all the terms uniformly.
On my wiki dedicated to historical figures, half the people will be described by the property, other participants will describe people by the , and the third by the . Now, in order to get a list of historical figures and display their dates of birth, I need to write three queries instead of one:
')

 {{#ask:[[  ]] | ?  }} {{#ask:[[  ]] | ?  }} {{#ask:[[  ]] | ?  }} 

To solve these problems, apply templates and forms.

Templates

Templates they are very often used to use complex markup on wiki articles, while hiding implementation details. A good example of templates are infoboxes on Wikipedia. Experienced editors create templates using html so that all colors and indents in the infobox are pleasing to the eye, while the regular authors of the articles use the following simple syntax to insert infoboxes into the wiki pages:

 {{  | 1=  1 | 2=  2 | 3=  3 }} 

A small example: click the Edit button on the Russian page on Wikipedia dedicated to Leonardo da Vinci. Calling the template is converted into a nice infobox. In the template itself , colors, fonts, indents and other things related to the design are determined.



The template implementation is stored in the Template namespace. The named parameters of the template are enclosed in triple curly brackets, and at the moment of calling the values ​​of the parameters are substituted in the right places. With the help of a template you can uniformly design not only infoboxes. Here is a small example in which I use a template in order to format the data by date and place of birth as a phrase wrapped in a div element with some decoration.

Pattern code	Result
<div class="awesomebox">{{{}}} {{{ }}}. {{{ }}}</div>	15.4.1452.

Semantic patterns

Of interest to us is the following: if a semantic property is placed in the template text, then all pages using the template will have this property. Let's try to apply this approach to our example with Historical Persons: let's make a template of the same name with the parameter.

Pattern code	Result
<div class="awesomebox">{{{}}} [[ ::{{{ }}}]]...	15.4.1452...

Not bad! Now users will not be confused when describing objects: all pages using our template will have the property. From this follows two important points:

1. Now wiki authors don't need to know anything about semantic properties. They just use templates.
2. if the template already existed before you put SMW , you can simply add semantic properties to it and take advantage of the organization of structured data so that users will not notice anything. This is a great way to painless semantics.

Patterns cannot, however, solve the problem of writing the same data differently. Some will indicate on the something like 24 1893 . , others will use a record of the type of . 1349 . . . . 1349 . . . or worse, . . We'll have to keep track of who and in what format indicates the date and manually bring it into a form suitable for use in #ask queries.

Semantic forms

This is where semantic forms come to the rescue. The powerful and huge Semantic Forms plugin provides wiki authors with a variety of input elements, so the community does not waste time on manual data unification. The semantic Forms syntax is just as horrible as the entire MediaWiki syntax, however we have many ways to avoid creating forms manually. Consider for a start the most common moments.

The form is described on the wiki page located in the Form namespace using html, wiki markup and special tags. It can be edited just like any other wiki page. A form is a means of filling in templates; when creating it, think first of all about the template parameters!

Typically, the form text has the following structure (I tried to format the code for clarity, but remember that this is not allowed in MediaWiki):

 {{{info| < [ ]> }}} <!--    :     ,         . --> {{{for template |  }}} <!--, ,     --> {{{field |   | input type=text }}} <!--   --> {{{field |   | input type=calendar}}} {{{field |   | input type=calendar}}} {{{field |  | input type=textarea}}} {{{end template}}} <!--   --> {{{standard input|save}}} {{{standard input|cancel}}} <!--  , ,    --> 

The most important tag in the Semantic Forms is of course the field . It forms the input element: a text field, a drop-down list, a calendar for entering the date, etc. The name of the input element must match the name of the template parameter, for example, the calendar {{{field | | input type=calendar}}} {{{field | | input type=calendar}}} {{{field | | input type=calendar}}} will fill in the {{{ }}} parameter of the template. This tag has a huge number of parameters that allow you to preload some default text into the input, make it mandatory to fill in, set a list of acceptable values ​​and much more. Full documentation is on the help page.

For the Semantic Forms written a great many different types of inputs. Some of them are located directly in the Semantic Forms , and some are placed in a separate extension of the Semantic Forms Inputs . In addition to standard ticks, radio buttons, input fields and lists, we also have more interesting input options (and if you want to write your own, welcome to the manual ).

Name of the input	Description	For which types	Picture
datepicker	Date picker	Date
timepicker	Tool (better not call) for timing	Date
two listboxes	Values ​​from the left list are transferred to the right when you click on them.	any type. Possible values ​​must be preloaded with the values option
menuselect	Selecting a value from the tree menu	any type. Possible values ​​are preloaded in the structure parameter

Separate is an input to enter geographic coordinates. It allows you to specify the coordinates, poking at a specific location on the map:


Usually the form is made up in the form of a plate. Signatures to input elements are made using regular wiki markup or using html. Here is a real example code for a form that uses MediaWiki table syntax :


So, we wrote a small form, now we need to run it somehow.

Run Forms

The page in the Form namespace is only the source code of the form. In order to run a form (I think of this process as an interpretation), there are several ways.

• You can use the Special:FormEdit/_ page Special:FormEdit/_ .
• You can use the {{#formlink: form=_|link text=__}} , which will form a link to the form and allow you to pass various parameters to it
• You can use the {{#forminput: form=_|button text= }} function {{#forminput: form=_|button text= }}
• An interesting opportunity to call the form for the "red links" . In MediaWiki, links to non-existent pages are indicated in red. Click on the red link Paris - get an offer to write an article about Paris. And a text editor. Semantic properties can also point to non-existent pages. The creators of the Semantic Forms came up with the idea: if we have, for example, the property , then why not call the creation form when you click on the red link? We just go to the Property Has Capital page and write the following code there:
  [[has default form :: City]]

Form generation

Writing semantic forms from scratch is a thankless and unpleasant affair. In the absence of a normal wiki markup editor (those who wish can try WikEd , this is the best we have), the probability of error is very high. Therefore, forms (and templates) prefer to generate, and we have several tools at our disposal.

First, Semantic Forms provides several service pages designed to generate patterns, descriptions of semantic properties and forms. These pages are called Special:CreateProperty , Special:CreateTemplate and Special:CreateForm . They will make your life easier. Special Page Special:CreateClass allows Special:CreateClass to describe a class of objects in one fell swoop: it creates all the necessary properties, templates, and forms.


The problem with all these special pages is that they do not allow editing existing templates and forms: you can make it easier for you to take the first steps in creating a form interface, but you have to tweak it manually, remembering the bad words of those who invented the syntax of the MediaWiki tables. Adding new template parameters and input elements requires you to jump between multiple pages. So it is with the removal.

Schemes: Page Schemas Extension

A more progressive approach requires installing the Page Schemas plugin . Schemes are called XML descriptions associated with a category, containing instructions on what properties related objects will have, what templates will be used to describe them, and what forms will fill these templates.

With Page Schemas, life takes on new colors. I just go to the page : and click on the Create Schema button. At my service is a visual schema editor, in which I say that I need to create a form that will fill out a template of the same name. I immediately create my four fields ( , , , ), describing what semantic properties need to be created, what input elements should be used and what additional parameters I want to specify for them.

The editor takes up a lot of space on the screen, so I’ll only show you how to edit one field - .


The schema editor generates an XML document that is now stored on the category page. I click the Generate pages button and Page Schemas generates all the necessary pages (forms, templates and properties). If I want to add a field, I don’t need to manually edit the template, edit the form and create the Property: Birthplace page. I simply return to the category page, click on the Edit schema and add a new field. After I ask Page Schemas to regenerate all pages of interest to me in accordance with the updated scheme.

For describing visual interfaces, screencasts fit much better than a sheet of text, so I recorded a little video at one time. Since its entry, we have managed to add many new features to Page Schemas and are going to add many more:

Examples of using

The combination of form input with dynamically updated data has generated many web systems that you do not immediately recognize MediaWiki. The SMW community even started a Wiki of the Month contest in which the most interesting semantic wiki is selected every month. Experience shows that using forms can significantly reduce the entry threshold for a user, and attract people to the wiki-work who couldn’t imagine themselves as editors in a nightmare.

And here are some forms that are actually used in various wikis. Complicated form for describing plants with the Gardenology wiki



But we have already created such a form for working with technological foresight:

Conclusion

I did not tell much. For example, the fact that forms can be used not only as a means of creating pages, but also as forms for semantic queries. About how forms can be reused, how forms can be rebuilt in the editing process, about how a simple voting ticket can be built on their basis. Write what you would like to see in future articles.

Links

• Documentation on the Semantic Forms is complete, but requires peering
• PageSchemas documentation
• SMWCon Fall 2013 is a conference of semantic wiki lovers and SMW in particular. Come to us in Berlin!

Thank you vedmaka for the complete pathos of the first drawing!
All pictures published under the license CC-BY 3.0