Guild Wars 2 Wiki:Semantic MediaWiki

From Guild Wars 2 Wiki
Jump to navigationJump to search
Shortcut:
GW2W:SMW

Semantic MediaWiki (SMW) is a data-management extension for MediaWiki that is an integral part of Guild Wars 2 Wiki. It allows us to store data on articles in a way that it can be queried, aggregated, and displayed in other articles.

This page serves to document the semantic properties being used throughout the wiki. For the most part, these properties are set automatically by the infobox template on a page based on the input values given.

The wiki uses semantic notation and templates in articles, so users should familiarize themselves with the use of SMW and its functions even if they are not directly involved with the project. An introduction to using SMW can be found at Help:SMW.

Special:Version lists the currently installed version of SMW and related semantic extensions.

External reference[edit]

Category-specific pages[edit]

Each infobox uses a distinct set of properties, which are described on the subpages below.

Category Infobox Documentation subpage
Everything n/a /General properties
Events {{Event infobox}} /Events
Hearts {{Heart infobox}} /Hearts
Items {{Item infobox}} /Items
Recipes {{Recipe}} /Recipes
Armor {{Armor infobox}} /Items/Armor
Back items {{Back item infobox}} /Items/Back items
Dyes {{Dye infobox}} /Items/Dyes
Trinkets {{Trinket infobox}} /Items/Trinkets
Weapons {{Weapon infobox}} /Items/Weapons
Locations {{Location infobox}} /Locations
NPCs {{NPC infobox}} /NPCs
Objects {{Object infobox}} /Objects
Skills {{Skill infobox}} /Skills
Traits {{Trait infobox}} /Traits
Skill facts {{skill fact}} /Skill facts
Personal story {{story infobox}} /Story
Achievements {{achievement table row}} /Achievements
Vendors {{vendor table row}} /Vendors
Specializations {{specialization infobox}} /Specializations
Guild upgrades {{guild upgrade infobox}} /Guild upgrades

Inline queries[edit]

Parameter Possible values Description
format a format name selected output format; some formats allow further parameters (see Help:Result formats)
sep plain text the results separator. Only works in the case of format = list (does not work for format = template)
template name of a template a template to wrap each result with
limit non-negative number maximal number of pages selected (in the case of a table: rows)
offset number where to start
sort property name or a list of property names separated by , name of properties to use for sorting queries, a blank as a value stands for the main result column (see Help:Selecting pages)
order ascending/asc, descending/desc/reverse, random/rand
or a list of those if more than one property is used for sorting 		defines how results should be ordered, ascending is the default, without using parameter "sort" the sort order of the main result column is set (see Help:Selecting pages)
align right, center, left defines how results should be aligned, only applicable for the result formats table and broadtable (see Help:Result formats)
headers show, plain, hide show headers (with links), show headers (just text) or hide them. show is default
mainlabel plain text title of the first column (the one with the page titles in it), default is no title; set to - to suppress printing the page titles
index number defines which value within a record should be displayed, only applicable for properties of type Record
link none, subject, all defines which article names in the result are hyperlinked, all normally is the default

Note: linking can also be controlled for individual printouts using the plain output format as described in Displaying information.

default plain text if, for any reason, the query returns no results, this will be printed instead
intro plain text initial text that prepends the output, if at least some results exist
outro plain text text that is appended to the output, if at least some results exist
searchlabel plain text text for continuing the search (default is «… further results»)
named args yes, no use named result template parameters

Quirks[edit]

Related to MediaWiki's cache[edit]

Properties not updated immediately after editing a template
When a template is edited, rather than immediately re-processing every page that uses that template, MediaWiki adds those pages to the job queue. Every time a page on the wiki is accessed, the back-end software will process a few pages from this queue, parsing them with the new template code and updating the wiki's cached version of the page. Until a specific page gets processed through the job queue, readers will still see the cached version of the page with the old template code.
Pages with queries not updating immediately
Similar to the above, when other pages are edited to add semantic data (say, a recipe), that new data will not be immediately reflected on other pages that query for it, since their cached versions were generated before this new data was available. Unlike editing a template, however, editing pages in the mainspace will not cause anything to be added to the job queue, which means the cached versions of these pages will not be updated until they expire normally after 24 hours.

It is possible to force the wiki to immediately update the cached version of a page by clicking on the "refresh" tab at the top of the page. This will overcome both of the above quirks.

Particular to SMW[edit]

columns
Historically there used to be a "columns" count formatting parameter. This was subsequently removed within the extension, and can instead be implemented by applying the CSS class "smw-ul-columns-fill" (which applies column-count: auto and column-width: 300px) to a wrapper element. Refer to Template:Member list for how to implement this.
default results
The default is always parsed, no matter if the query yields a result or not. While the default case isn't visible if results are found, some functions may cause interferences. For example setting properties silently (#set) or defining references (ref) are always executed, which results in unwanted or untargetable declarations. However, in-text annotations as visibly setting a property ([[<property>::<value>]]) or defining a category are only executed if the query gives no result and hence are safe to use.
This also means any templates used in the default parameter will contribute towards page size limits and tranclusion limits.
mw:Extension:Cite reference tags
Reference tags can only be added using the tag parser function, e.g. {{#tag:ref|...}}. Attempting to add reference tags in a result template using direct <ref></ref> will result in unparsed parameter values with contents such as {{{1}}} ending up in the final markup. This is fine and workable, however be careful if the semantic #ask (or #show) query also uses the "default" parameter. If the default uses the same result template, then the ref tag will be parsed twice and associated entries will appear twice in the <references/> tag at the end of the page.
Multiple identical values
While SMW can store multiple values per property per page, it will only store distinct values. This can be a problem for certain recipes like Mystic Chest, where three of the ingredients are identical. On that page, Property:Has ingredient will only be given a single instance of the 250 Cured Thick Leather Squares, rather than three, and this will be reflected in query output as on Cured Thick Leather Square#Mystic Forge.
Querying for pages not in the main namespace
Pages outside of the main and user namespaces do not have any semantic properties set - Special:Browse will not produce any results. Thus, for example, SMW cannot be used to query for template pages even if they are in a particular category.
Properties remaining active after page has been blanked
Whilst the reasons for this occuring are unknown, it is believed to be related to the page not fully caching the first time it is created. It can be fixed by deleting the page and then restoring it.
Records with semi-colons in their values
Semi-colons can be escaped when defining a record to avoid the record components being split up unintentionally to different properties. See smw:Help:Type Record/Defining a record#Encode_.3B.
Semantic forms
The {{{field}}} used in forms will evaluate parameters as empty field if the form is used on an existing page. This will leave empty fields in templates and the wiki prefers to remove empty parameters from templates. Forms can be set as hidden, but the form can't be told to ignore a field as the {{{field}}} values is evaluated after parser functions and magic words. Therefore, the form can't differentiate between a user not defining a value for an parameter or simply not including a parameter for the template.
tree format
Prior to SMW 3.0.0, the tree result format used to respect further queries beyond the single property required for the "parent" parameter. This is no longer the case due to mixed up behaviour of the parameter named args. Contradictory to any other format, here the parameter named args = no (which is also default value) requires named properties and named args = yes requries unnamed properties.
Potential fixes:
  • Either redesign the originating query to use a result template that applies an indent, or add #show queries to the individual result format template.
  • Add named args = yes and use unnamed properties (not recommended: as soon as they fix this bug, the template needs to be adjusted again, might be overlooked for months).
  • Number the properties ascendingly, starting with 2 (unnamed parameter 1 is reserved for main result), e.g. ?<property name>=2. This will overcome any named args confusion, whether the template uses named arguments or not (correctly or incorrectly), the result template receive the properties as unnamed parameters (due to the fact that the named parameters are the same as the unnamed paramters).
Sorting
Sorting will remove in articles that do not have the property to be sorted by. You can only sort by properties from the result set of articles from the query; you can not sort by subquery results. There is an exception if you include all results (+) from a subquery, you will be allowed to sort by that property since the property will be present for all articles. This is not a suggested practice because it leads to ambiguity on which property is being sorted, the article or the article of the subquery.
ul, ol and tree formats
ul, ol and tree formats insert an unwanted additional empty paragraph element, which causes a newline, after the </ul> element. This can be remedied by specifying any non-blank intro/outro combination, such as wrapping the output in a <div> with no styles.

Discouraged where possible as confusing[edit]

Retrieved from "https://wiki.guildwars2.com/index.php?title=Guild_Wars_2_Wiki:Semantic_MediaWiki&oldid=2878823"