User:Samwilson/Blog/Semantic MediaWiki CRUD

These are some notes about how I go about setting up a basic Create-Read-Update-Delete structure for an entity in Semantic MediaWiki with Semantic Forms. (Not that deleting gets much of a look in, because that's handled by standard MediaWiki.)

A Person entity, for example, gets the following pages (note the usages of plural and singular entity names):


 * (plural; contains all the instances of the entity, and no other pages)
 * (singular; to create and edit the instances)
 * (plural; the search form)
 * (singular; formats the data pages and adds pages to the above category)
 * (plural; used by Special:RunQuery to display search results)
 * ,, etc. (properties as required)
 * (plural; contains information, search form, statistics, etc.; the starting point for end-users so far as this entity is concerned)
 * (actual data page; named after some identifying property of the entity; contains only the Person template above)

The following sections go through each of these, roughly in the order in which I generally create them.

Data Entry Form (e.g. )
I start with the form (not, as the official docs recommend, the properties; they will become clear as you design the form, and it's usually the form that end-users see first so it's also a useful starting point when implementing someone else's ideas).

Name:

Date of Birth:

This creates a form with fields for name and date of birth, and automatically creates pages named after the person (the page name parameter of the info tag can do automatically-incrementing ID numbers as well). Note that template values that are going to be used in the page name should be mandatory.

Data Template (e.g. )
The template is what is actual displayed on the person's data page. At a minimum, it should add the page to the relevant category and define the values of the semantic properties. Name: Name::

Date of Birth: Date of Birth::

Category (e.g. )
Categories in Semantic MediaWiki should only be used to group pages by fundamental and non-mutable characteristics; other groupings should be done via semantic querying features. For instance, every page using a  template is defining a person, so it always makes sense for those pages to be in the   category, and never makes sense for them not to be. Pages in this category represent People, and should be edited using the has default form::People form.

The  category is of course optional, but it's nice to collect these together somewhere. I usually also have a  page that summarises them all.

Overview Page (e.g. )
The mainspace page gives a general overview of the entity, and provision for searching, adding, viewing statistics, etc. At a minimum, it should include the search form and a link to the data entry form for new records:

Properties
Properties are defined as required, and should take sentence case.

Use of properties is explained far better than I can on the SMW and Semantic Forms sites.

Data Pages (e.g. )
Data pages, in the mainspace, are created from the form above, using one of the fields as their name. They contain only the template, and should be able to be edited completely via the form.

Search Form (e.g. )
The search form is usually pretty similar to the Data Entry Form,

Name:

Date of Birth:

Search Results Template (e.g. )
This template is given the values entered by the user in the search form above. It should use these in a query, to show the actual results:

Note that, as both of the search terms here are optional, we only include them in the query if they've been specified. This could also be done here by writing, for example (to use the provided value for Name or else the find-all wildcard), but with the ParserFunction construct we can also do things like include a list of property values: