User:M.mendel/Wikibase

What is a Wikibase?
A wikibase is an object-oriented database implemented on top of the wiki using wiki template code to acess it.

Once the decision was made to remove the Skillbox calls from the skill articles and store them separately, in effect a database was created. Only no-one saw it that way, so it doesn't work as well as it could.

Each skill article in Template: namespace is a database entry. Its article name is its identifier and single key; and the fields it calls Skill Box with are its attributes - the data, if you will.

Even now, there are two ways to retrieve this data:

Technique 1: Parse the Template Source
We can grab the content of the template with msgnw: and parse it using #pos:, #replace: or #explode:, e.g.    will retrieve the value  of the field Profession from the skill Abaddon's Chosen. It does that by determining the position of the field within the template with #pos:, discarding everything before it with #sub: and cutting out first the bit between the pipes and then the piece after the = with #explode:. The value of this field should be Monster: it is . Cost: Pre-expand include size: 1027/2097152 bytes, Post-expand include size: 1228/2097152 bytes, Template argument size: 0/2097152 bytes.

Granted, this looks unwieldy, but it could be defined in a Template:GetFrom that is called   and still gives  (should be Monster). Pre-expand include size: 1689/2097152 bytes, Post-expand include size: 1702/2097152 bytes, Template argument size: 49/2097152 bytes. I suppose it needs more error-checking code, though.

Technique 2: Use a "Get Field" Template
We can call the skill directly, using a custom Template: Skill box Get profession that only returns the needed field:. A call to   should be Monster: it is . Pre-expand include size: 417/2097152 bytes, Post-expand include size: 32/2097152 bytes, Template argument size: 21/2097152 bytes. Clearly, as of now, method 2 is superior: it is more readable and uses less system resources. The drawback is that for each field that is to be returned, a custom "Skill box Get field" template has to be created.

Suggestions
It is certainly difficult to redesign the present skill system; with over 500 skills such a move requires considerable planning and effort, and it may not be worth it. However, if the beastinfo or other database-like information structures should move to a more data-base like system, and of course for the Guild Wars 2 wiki the following improvements should be considered.

Suggestion 1: Dollar format
If the above methode 1 is to be used (parsing the template itself with string functions), then it would help if the data was more parseable. The above skill, now stored as could be stored as $name$Abaddon's Chosen $type$Enchantment Spell $profession$Monster $campaign$Nightfall $activation$¾ $recharge$90 $description$Target cannot lose Health for 10 seconds. $concise_description$(10 seconds.) Target cannot lose Health. or similar. The advantage is that msgnw: need not be used to access the data.

It is still possible to fill fields with the data and call a template with that, as User:M.mendel/Templates/merge_PvPvE demonstrates. It takes as first parameter a template to call, and as a second parameter a skill dataset in the above $format$. This can be generated from the present skill data by calling. It invokes the Skill box data template that checks for all fields that could possibly occur in a skill object and wraps them in $. (I made this to extract data from a PvP skill and its PvE counterpart and feed both to my dual skill box.)

Suggestion 2: Template call-through
The beginning of Abaddon's Chosen is {{Skill box {{{1|}}} Therefore, it can only ever call a Skill box. If it began {{ {{{1|Skill box}}} | {{{2|}}} | {{{3|}}} | {{{4|}}} then it would be much more flexible. The call {{Template|Abaddon's Chosen}} works the same in both versions, and a call that is presently {{Abaddon's Chosen|qr}} would be converted to {{Abaddon's Chosen|Skill box qr}}. The gain in flexibility is that it would be possible to have Abbadon's Chosen call any other template - even in User: space - and pass along three unnamed parameters as well.

What's more, a Template:Get can be written that retrieves any parameter: {{{ {{{1}}} }}} is enough to do so. Observe: The call  {{Abaddon's Chosen|Get|campaign}}  would be executed as {{ Get | campaign | | | | nocats = yes | name = Abaddon's Chosen | campaign = Nightfall | profession = Monster ... }} and give {{:User:M.mendel/Templates/Get | campaign | | | | nocats = yes | name = Abaddon's Chosen | campaign = Nightfall | profession = Monster }} Neat, huh? This means that we don't need a template for every single field we want to access, thanks to the pass-through parameters.

It is also easy to call templates that work on the fields in the template, for example to compute a score for a skill or to autocategorize it. The possibilities are endless, and the cost is neglible.

Site Integration
If the database articles reside in a special namespace (be it Data: or Data/ ), site CSS and Javascript could help the user keep the data properly formatted whenever such a page is being edited. Perhaps it would be enough to place a &lt;div class="database"&gt; on the page. I'm open for suggestions.

Conclusion
Our "Wikibase" can be improved. It is up to the community to decide how far we want to go on this road. We need to decide which of the two presently possible techniques are acceptable to use (both require adding some "Skill box" templates as needed). We need to decide whether we have data sets that we want to convert to a wikibase, and what kind of wikibase to convert them to. We should evaluate whether we want to push for one of the improved systems to be used for the Guild Wars 2 wiki(s) from the start.

|Discuss.