Help:Data Storage

Help page

As the wiki includes more and more information, it becomes useful to consider other ways to handle information than just categorizing pages in Categories.

This guide will assume you are familiar with Namespaces (ie "File:", "User:", "Template:", "Category:", etc.) and Categories (ie Category:Characters). It will primarily cover Properties and Concepts, and a little bit of Parser Functions (namely, the inline queries #show and #ask).


A Property holds data for a page (a "property" of the page) that can be used on another page with a few lines of text, or to "categorize" a page (see Concepts), or to sort pages.

  • {{#set:Property name=Property value.}} To set a property of a page.
  • [[Property name::Property value]] To set a property of a page, while leaving a link to the property value.
  • {{#set:Property name=Property value.|Property name=Property value}} To set multiple properties of a page at once. You can also set the same property multiple times to different values (e.g. Eye Color to Green and Blue).
  • {{#show:Page|?Property}} To show the property's value for that page.
  • {{#ask:[[Property:property value]]}} To get all pages with the Property set to that property value (in a table)

Properties have pages prefixed by "Property". You can see all properties that currently exist on the wiki, and all properties with a page (change the Namespace dropdown to "Property"). Properties without a page are usually added automatically by software, whereas properties with a page are usually created by users.

Note that the properties talked about here (the namespace and functionality provided by Semantic MediaWiki) are different from the "page properties" listed on the Special:Pages With Properties page.

Properties vs Categories

  • Properties are "hidden" from viewers of a page, whereas Categories which are "shown" (at the bottom of the page).
  • Properties are more flexible than Categories, and are well-suited for use with Templates, Modules (Scripts), Parser Functions, and other advanced topics, although Categories can be used for these purposes as well.

Semantic MediaWiki has dedicated a whole page to this.

Important Properties

Property Name Description
Caption Seen most commonly on the pages of images. This property defines the text for that image that will be used as a caption for that image on a character's Gallery page, or any gallery created by using the Master Gallery template or the Gallery Section template.
Date This property was added automatically by the system (not by a user). However, it can be added to pages just like any other property. It can be used to sort images in galleries by date rather than by alphabetical order.


To illustrate this, let's say we want the "color of a character's eyes" to be a Property. Following the suggested style of naming, we'll call this property "Has eye color" (as in, Ragna the Bloodedge "has [the] eye color" green).

Setting Properties

1. On Ragna's page, we can say his eyes are green by writing:
{{#set:Has eye color=Green}}
2. Since Ragna has two colors for his eyes (one color for each), we put a "|" and add his second eye color afterwards:
{{#set:Has eye color=Green|Has eye color=Red}}
This gives the page for Ragna the Bloodedge the Property "Has eye color" twice, once for "Green" and once for "Red". Or, we could say it sets the property twice to those values. Ragna the Bloodedge now "Has eye color" green and red.

Getting Properties

3. You can get Ragna's eye colors (i.e. print it) on any page with:
{{#show:Ragna the Bloodedge|?Has eye color}}
This will show what was set for the property "Has eye color" for the page "Ragna the Bloodedge". The "?" before the Property is to say that "Has eye color" is a property (as opposed to a Category or a page).
* For more details on #show, see here.
4. Alternatively, you can use what is called an Inverse Property to get Ragna's eye colors with:
{{#ask: [[-Has eye color::Ragna]] }}
However, this is hard to read, and it only retrieves pages. In this case, if "Green" and "Red" do not have pages, then writing the above will not work. (An example of a better usage would be something like {{#ask:[[-Has grimoire::Ragna]]}}, which can be imagined to return Azure Grimoire, which does have a page.)

Getting Pages with a Certain Property

5. You can also gather a list of all pages with a property (displayed in a table) using #ask:
 [[Located in::Germany]] 
 |?Area#km² = Size in km²
In this example [[Located in::Germany]], ?Population, and ?Area all define the use of Properties - specifically, the "Located in," "Population," and "Area" properties. In the above example, #ask will ask for all the pages that are [[Located in::Germany]] (have the "Located in" Property set to "Germany") and are categorized as cities (in the category "City"). It will then display the Population and Area properties of each page that fits those criteria. By default, this is displayed in a table.
* For more details about the above example and what else can be done with #ask, see here)
6. You can also get a list of all pages with a property by using a Concept (see Concepts below).

Creating Pages for Properties

On the property's page, be sure to include somewhere its type with something similar to This property is of type [[Has type:type]].. See Semantic MediaWiki's page on Property declaration for what types are available and more details.

Reference Links

Properties are part of the Semantic MediaWiki extension. For more details, you can refer to the Semantic MediaWiki's Properties page.


A Concept is a page that is created in the Concept namespace, which defines a "dynamic category."

 [[Has planned start::> Jan 1 2012]]
 [[Has planned finish::< Dec 31 2012]] 
 |Semantic MediaWiki Cons in the year 2012 that have been announced on this wiki.

Why Use Concepts?

  • They can be used to define a "pseudo-category" that doesn't need an explicit category page, but would be nice to have as a logical group.
For example, "Staff Extras by Toshimichi Mori." We have the category Staff Extras and the category Mori, Toshimichi, but it would be overkill (and difficult to maintain) if we were to try to define a third category "Staff Extras by Toshimichi Mori" to determine the two categories' intersection.
With a concept, you only need to create a page "Concept:Staff Extras by Toshimichi Mori" and write the query for the concept inside. Then, you will be able to view the concept's page the same way you can view a category's page, and see all the pages gathered in that concept.
  • They can be used to create a Page Form ("forms to add and edit wiki pages"). A Page Form defines a form that just needs to be filled out to create a complex page. Concepts can be used to define a list of possible values for a field on the form (for example, valid categories to categorize the page with). For more details, see Semantic MediaWiki's pages on Page Forms and Concepts.
  • They can be used with inline queries (like #show and #ask).


Please refer to the Semantic MediaWiki's page on Concepts.

Reference Links

Concepts are part of the Semantic MediaWiki extension. For more details, you can refer to the Semantic MediaWiki's page on concepts.


Cargo is an extension to MediaWiki that provides a lightweight way to store and query the data contained within the calls to templates, such as infoboxes. It is similar in concept to the Semantic MediaWiki extension, but offers a number of advantages, including ease of installation and ease of use.

The extension defines a number of parser functions; these three are the most important:

  • #cargo_declare - placed within the <noinclude> part of a template; it defines the schema for a table.
  • #cargo_store - stores one row to a Cargo table; usually placed within the <includeonly> part of a template.
  • #cargo_query - queries one or more Cargo data tables, using SQL components.

The other defined parser functions are:

  • #cargo_attach - defines a template as adding rows to a table declared elsewhere.
  • #cargo_compound_query - displays the results of multiple queries in one place.
  • #cargo_display_map - displays a map showing a single point.
  • #recurring_event - prints out the dates for a recurring event; for use by #cargo_store.

- MediaWiki, Extension:Cargo

Cargo is like a mini database. It is meant to be used with templates, and specifically infoboxes, (e.g. Character Infoboxes). Cargo inserts each field of the infobox (EN name, JP name, romaji, eye color, height, birthday, etc) into a "database" for the page that template is included on.

Simply put, the page "Ragna the Bloodedge" can become connected to the values "Ragna the Bloodedge" as his English name, "ラグナ=ザ=ブラッドエッジ" as his Japanese name, "March 3rd" for his birthday, "Artificial Human" for his species, and so on and so forth.

Why Use Cargo?

  • It keeps pages cleaner and more consistent by defining all "properties" on a template page.
  • Using Cargo is purportedly simpler (in templates, etc) than using Semantic MediaWiki (and its Properties and Concepts).
  • Just the one Cargo extension can take the place of several others to provide the same functionality.
  • Cargo is best used for infoboxes that define a set of values that won't change often, and do not have many unknowns about what could be in the value (for example, if there will be references or links included, or if you'll be using DD/MM/YYYY instead of MM/DD/YYYY). For example, unit data (stats, skills, unit types, rarity).

Cargo vs. Semantic MediaWiki (Properties and Concepts)

MediaWiki's page on Cargo and Semantic MediaWiki gives us this:

Philosophically, Cargo differs from SMW in three main ways:

  • Cargo ties data storage directly to templates. In SMW, semantic values can be placed anywhere on the page, even though in practice they're usually confined to templates; but in Cargo, it is the template itself that is responsible for storing its data.
  • Cargo stores its data in as simple a fashion as possible, using standard database tables to hold tabular data; while SMW uses a database to represent "triples" of data.
  • Though this is a more minor difference, Cargo is less customizable than SMW and its spinoff extensions, opting instead to base display settings on the data itself.