Guild Wars 2 Wiki:Semantic MediaWiki
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]
- Help:Properties and types
- Help:Type Record
- Help:Inline queries
- Help:Result formats
- Help:Plainlist format (formerly known as "Template format", contains guidance on valuesep)
- Help:Gallery format
- Help:Count format
- Help:Tree format
- Help:Displaying information (information on correcting thousand separator with a # sign)
- Examples on working with the #set "separator" parameter
- Help:Querying for queries and Help:Special property Query string (searching for inline queries)
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 parameternamed args = no
(which is also default value) requires named properties andnamed 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 anynamed 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
andtree
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]
- Help:Inverse properties - prefixing properties within #ask: statements with a minus sign
- Help:Subqueries and property chains - nesting queries by wrapping them in
<q></q>
tags within other queries.