Works in Progress with Semantic Mediawiki

Alan has been accommodating enough to humor my request to install Semantic Mediawiki (hereafter SMW) on the dev version of this Wiki, and so far I've managed not to burn the servers down while tinkering with it. After an inordinate amount of experimentation, I think I have a handle on how it works (and how to make it work the way I want it to), and I have some Proofs of Concept to demonstrate how I think it can be used to improve the Wiki.

A quick primer on what SMW does: It lets you annotate pages with Properties, which can either be attributes, or relationships to another page. An example of an attribute is an Unlawful Device having a sell price of 12.5 echoes. An example of a relationship is Dig it up! being a Source of the Unlawful Device. These properties can be queried to display information on a page, or to be used as input to Templates or Modules.

There are two major benefits that I can see SMW providing. The first is adding useful information to existing article pages. The second is making maintenance easier by reducing or eliminating the. need to enter duplicate information in multiple locations. Both of these benefits can be realized by making use of our extensive templating, in quit a few cases without changing the editor-facing API of these templates.

I have prepared a few proofs-of-concept (proof-of-concepts?) on the dev version of the Wiki to showcase a few benefits. Most of these are extensively deployed throughout the wiki by editing templates, while a few are restricted to toy examples due to lack of admin privileges.

Presenting Extra Information

The decisions for which data to use and how to display them are as varied as the pasts and futures of Parabola. I went a few different directions, and some of these examples lack polish as I wanted to get some feedback before getting too far into the weeds.

In general, I took existing uses of {{Category tree}} as starting points and looked for how a plain list of pages might be improved by adding extra details. SMW bills itself as building upon MW's category system, so this seemed like a natural jumping-off point.

Challenge Info

This one is the most obvious: In addition to the list of pages with challenges against a stat, also pull in the difficulty rating for that challenge.

dev:User:PSGarak/Sandbox/Challenge Test

Storying data was done by modifying dev:Template:ChallengeSection . This ends up being a bit more difficult in practice because of broad vs narrow, actions with multiple challenges, missing difficulty info, and of course everyone's favorite, actions whose difficulty changes dynamically based on other qualities. Those edge cases still end up being tractable in practice.

The demo presents things in a table, which feels a bit heavy, both in terms of presentation and in terms of the implementation requiring a handful of sub-templates. For the guts of how it's working, see dev:User:PSGarak/Sandbox/Challenge tree and related sub-pages.

Quality Unlocks

When I'm looking at an overly-long list of uses for a quality, the thing I wish it had was some notion of context, because the action name on its own isn't always useful. I've added annotations with whether a page represents an Action, Card, or Storylet, and for the latter two, the Location.

dev:User:PSGarak/Sandbox/UnlockTest

Note that for the second & third examples, I'm using wildcard matches "ends with Clay Highwayman" and "starts with Renown" in order to get lists that showcase a broader range of actions, cards, and storylets.

This demo has some edge cases that aren't handled yet, such as cards with no location. Notably, this is done with just built-in formatting options in SMW queries, no extra templates.

The actions/cards/storylets unlocked by a quality were obtained by editing {{Unlock}}. Locations were obtained by using the existing location field in {{Card}} and {{Storylet}}. This could be extended to use the From field on Actions to pull in the name & location of parent card/storylets, but I don't have permissions to edit {{Action}}.

Item Sources

This one is slightly different. It's flagging source actions based on restricted access, i.e. being Fate-locked or retired or belonging to an Ambition or what have you.

dev:User:PSGarak/Sandbox/Source test

Item sources are obtained by modifying dev:Template:Item Gain. Restrictions leverage existing Categories. The implementation re-uses some logic for equipment restrictions, below.

Maintenance

Sometimes we have to update things in more than one place. Ideally everything else should just query the one place.

Module:ItemList

This is a list of all Shadowy Companions, with hopefully the same entries and metadata used by Module:ItemList.

dev:User:PSGarak/Sandbox/ItemTest

Data is gathered by parsing the Effects fields in dev:Template:Item. It should remain up-to-date on its own as items are added or modified. Restriction fields are obtained by reading categories for each item page. Formatting is done by a small Lua script at dev:Module:Access, although that's not germane to the point of the demo.

This is meant to show what data points can be pulled in. To actually make use of this, I would look at the Semantic Scribunto extension, so that Lua could directly access the backing data. I am convinced it's feasible to make drop-in replacements for the hand-curated item lists in ItemList that are backed by SMW queries, so that downstream modules would not need to be updated.

Item Listings by Category

I don't know if we have a name for this, but I mean the tables of items by item category like {{Infernal}} or {{Legal}}. I've been calling them Listings.

I updated dev:Template:Item with a parameter that would try to make a table like this automatically, and updated all of the dev:Historical items to use this auto-generated table. The parameter both registers the item as showing up in the table for other items, as well as displaying the table on the given page. Sale price is currently entered by hand but could be obtained by modifying the Item template as well.

This one has more edge cases that I haven't approached yet, like Hinterland Scrip and Skeleton value and Eyeless Skulls. They all seem approachable, just some time & effort. In the meantime a gradual transition is possible, where some item categories with exceptional cases continue to use hand-maintained template tables and other use query-generated tables.

Module:IL

Unfortunately the magical solution based on Property:Attachment link doesn't work. That's ok because Plan B works great: Add an Icon parameter to {{Item}}, {{Quality}}, etc that replaces the File: link at the top of most pages. The IL can just call a page's icon, rather than having to maintain a big list of icons off to the side in Lua and updating it a dozen times per content drop.

I have not tested this at scale because I don't have privileges for the Text Replace function. But it works great in small tests.

In other good news, the Has icon property could just as easily apply to Card, Storylet, Action, etc. This would make {{IL}} more usable, as well as removing some of the ugly code in {{Option}}.

The future

This is still in the fiddling and experimentation stage. None of the ideas here are ready for primetime yet, although some of them could be close. I would like to get an idea of what other people think so this feels a bit less like navel-gazing and more like doing something productive.

• First and foremost, does this sound useful? Do the things that I'm doing make SMW seem like something that would improve the wiki?
• Are there concerns about introducing a new, complicated technology that I'm the only one that knows anything about it? I'm willing to put in the work to make design docs and editing guidelines, if others would want to read them.
• Am I on the right track with the types of things that it could be used for? If you have any other ideas for how data that already lives on the wiki in some form could be re-purposed, let me know and I can try to see if it's workable.
• This question is for Alan specifically: are there any performance concerns? The docs mention some tuning that can be done but I don't know how to profile or how hot the servers really run.