Guild Wars 2 Wiki talk:Semantic MediaWiki

The following discussion has been archived from Guild Wars 2 Wiki talk:Community portal

Let's talk semantics

Alright, I guess it's finally time for me to make an appearance on this wiki. For those of you who know/remember me from GuildWiki, howdy! And for the rest of you, if my activity here follows my previous patterns... you'll get to know me very quickly.

Any-hoo-hah-wibble-wobble, I would like to submit for discussion the idea of upgrading this wiki with Semantic MediaWiki. SMW is kinda similar to DPL in that it allows you to search the wiki and generate lists of articles, but with some significant differences. With SMW, you deliberately set properties on articles (typically from within templates) that can be queried directly, whereas with DPL you have to create a complex category structure (typically assigned from within templates) to support queries. SMW allows a higher complexity of querying than is possible with DPL, as well as a more customizable template output format.

(Yes, I admit to a small bit of bias here. After GuildWiki migrated from Wikia to Curse, they locked down DPL usage to protected pages only because of the security issues with the extension. To avoid the annoyance of arbitrarily protecting pages simply to use DPL on them, we've been relying more and more heavily on SMW for the past year and a half, and I have come to like it a LOT more than DPL. I've also been helping out at STOWiki recently, where they use SMW extensively and to great effect. I also know that there is an existing bias against SMW here, so I'll understand if this gets shot down immediately.)

The reason I'm proposing this now is because during the BWE, I checked here for crafting recipes, and quickly realized the challenge of maintaining correspondence between recipe articles and material/ingredient articles - i.e. keeping the list of recipes that use a material up-to-date as new recipes are added. SMW would make this automatic and transparent with minimal effort.

• Add SMW code to {{Recipe}} that takes the mat-X parameters and populates a property on the recipe page, let's call this "Has ingredient."
• Create a template (let's call it {{RecipeList}}) to place on the material page that queries "Has ingredient" for pages that list the material as an ingredient. The output can be a simple bulleted list of recipes as is currently used, or it could create a table to list the recipes along with their linked discipline, required level, and the quantity of the material required.

Example for those that don't know SMW that well:

Blueberry Tart is a recipe with the properties:

• Is of discipline::Cooking
• Requires level::25
• Has ingredient::Stick of Butter; 1
• Has ingredient::Bag of Sugar; 1
• Has ingredient::Ball of Dough; 1
• Has ingredient::Blueberry; 1

Ball of Dough is both a recipe and an ingredient. The ingredients for the recipe are:

• Is of discipline::Cooking
• Requires crafting level::0
• Has ingredient::Jug of Water; 1
• Has ingredient::Bag of Flour; 1
• Has ingredient::Stick of Butter; 1

The recipes that use Ball of Dough are queried by {{RecipeList}} on this page, and the output would include Blueberry Tart.

Stick of Butter is only an ingredient, and {{RecipeList}} would include both Blueberry Tart and Ball of Dough.

I believe that to achieve a similar result with DPL would require the creation of "Requires X" categories for every individual crafting material, which, while nominally useful, wouldn't really have much value outside of this. With SMW, on the other hand, lazy players who find Discovery extremely tedious could query the wiki for recipes in their discipline that are accessible to their level and use ingredients they have on hand.

And that's just one example of how to get value out of SMW - I could get into auxiliary extensions like Semantic Forms (standardized data entry for article classes) or Semantic Drilldown (interface to filter pages by categories and properties, similar to the browsing filters on shopping sites like Amazon or Newegg) - but that's just wasted breath... er, keystrokes, until after the discussion about SMW itself.

So yeah. I feel a little silly for suggesting an idea that already got killed off once before, but that was 4 years ago, and just like most anything about GW2, a lot can change in that time. IF this goes through, I would happily volunteer my time to implement it. Dr ishmael 19:33, 30 April 2012 (UTC)

Discussion of SMW proposal

I'm not entirely sure why we wouldn't want this. It just makes a difficult task (that is possible, read on for explanation) much easier.

So I actually have been working on things like automated condition pages (note that it isn't perfect, given my limited understanding of DPL), based on a combination of RegExs and various keywords that are used. I suspect that this would make it much easier to do things such as what I linked to above, so I very much support adding SMW. Aqua (T|C) 19:46, 30 April 2012 (UTC)

Well, the previous discussion seemed to have just died off rather than killed. I've always found DPL a little complex and I hadn't bothered to learn it. If SMW has a simpler and more intuitive syntax, I'd be on board. -- ab.er.rant 19:53, 30 April 2012 (UTC)

"I'm not entirely sure why we wouldn't want this." I ditto this, supposing I understand correctly. Konig/talk 20:14, 30 April 2012 (UTC)

Hey Ish. Nice to see you.

Now, if we're going to "switch off of" DPL in favor of SMW (as it probably doesn't make sense to maintain both side-by-side), my two major concerns, then and now, are "Does it do things DPL can't?" (which you seem to address here, and I'll get back to in a minute as well), and "Can it do what we use DPL for?" You've just barely grazed along the latter question seeming to imply that probably, mostly it can. I'd like to hear from Poke (and anyone else sufficiently versed in DPL used on this wiki) on this before tossing support behind or opposition to this.

One thing about SMW that I've been wondering for some time now is whether its related import data/use external data extensions could potentially be useful working in concert with Anet to pull "live" information from the game servers. Things like the state of Meta Events, and WvW match-ups, and probably a dozen other things I haven't thought of that could make the wiki more of a living resource than a flat collection of information. I've actually addressed this question to some of our more technically-minded folks, and the answers I've gotten have ranged from "I don't know" to "Maybe, depending". So I'll just throw that out here as a discussion point. - Tanetris 20:21, 30 April 2012 (UTC)

@Aqua - That is an ideal example, and yes, SMW could handle it. It would be more work than my recipe example above, but probably still easier than the DPL version.

@aberrant - Yeah, that old discussion wasn't as harsh as I made it seem, guess I was just being pessimistic. The complexity of using DPL is the biggest drawback about it - make no mistake, SMW can get pretty complex, too, but most of that stays on the backend, and the actual utilization is pretty intuitive. If you're good with SQL, then writing SMW queries will feel very natural.

@Tanetris - Nice to see you too! Short answer: yes, SMW can do anything DPL can do. It does have a few limitations that make some things more difficult, but in my experience they don't come up very often. I'd have to spend some time looking at what you're currently doing with DPL to have a better idea of how easy a transition to SMW would be.

On data import, while SMW might be able to do something like that, that's not what it was designed for (which probably explains the ambiguous responses you've received). You'd do better to use an extension specifically designed for dynamic data import, like External Data. —Dr ishmael 21:15, 30 April 2012 (UTC)

Perhaps this is a stupid question, but you can use them in conjunction successfully right? Because DPL is still useful for things that we have categories for, but SMW will prevent the annoying categories on GWW like "Skills that punish blocking". Aqua (T|C) 21:21, 30 April 2012 (UTC)

Well, let's throw some of our usages of DPL out there. How about a recent list of game updates? A trait page? A skill list? Maybe a call that uses a surrogate template in place of a template used on another page? --JonTheMon 21:50, 30 April 2012 (UTC)

Game updates are easy. Assuming the pages are named like 'Game updates/YYYYMMDD': {{#ask:[[Category:Game updates]] | order=desc | limit=5 | format=embedded }} Embedded format uses MediaWiki transclusion to embed the entire article, noinclude/includeonly are respected. Doesn't even require any properties on the pages.

The skill and trait pages would definitely be possible, could be as simple as directly replacing the #dpl with #ask on the skill page, but I don't have time to do any code mockups for them right now. But I can work on that tonight if that would be helpful. —Dr Ishmael 22:17, 30 April 2012 (UTC)

That it works without category structures seems like a nice simplification for at least some of the listings we want here so seems like a good improvement. If it works alongside DPL we can request its installation without losing anything and then work towards the best use of available tools to minimise new user confusion and easiest update efficiency. -- aspectacle  22:38, 30 April 2012 (UTC)

Right, that's what I'm talking about regarding "its related import data/use external data extensions". Back when I was looking at this (admittedly years ago now), External Data and similar were presented on SMW's wiki as "extensions to the extension", or at least extensions designed to play nice with it and understand each other's formats so they could work in concert. But yeah, I realize that goes beyond vanilla SMW. - Tanetris 17:35, 1 May 2012 (UTC)

Ah, I see - in replying to multiple people I missed a few details, namely the word "extensions" there. In that case, yes, it looks like External Data can do what you want, either on its own or in conjunction with SMW. —Dr Ishmael 21:48, 1 May 2012 (UTC)

Continued discussion

(Reset indent) Better than just writing up some pseudo-code, I have working demos for the trait page! Ignore the load times there, I'm just using their free service so it's running on crappy servers. At GuildWiki and STOWiki (both hosted by Curse on good servers), SMW like this runs really fast.

• Warrior traits, exact mirror of current list here (except your table doesn't respect the max-width for some reason)
• Warrior traits, individual tables by trait line

The only direct input on the trait lists is the names of the trait lines, and that's only to retain the in-game ordering. (I could set a "Has sort index" property on the trait lines to define their placement in the ordering, which would reduce the direct input to only the profession name.) Everything else, including the trait line's passive effects, is queried from semantic properties.

Besides completely rewriting the table templates, I only had to make some minor changes to Template:Trait infobox to store the parameters in semantic properties, and added some semantics directly to the trait line pages. —Dr Ishmael 16:53, 1 May 2012 (UTC)

Got another demo set up, this time for my initial idea about recipes/ingredients: Green Wood Log -> Green Wood Plank -> Green Wood Dowel -> Festering Green Inscription -> Bronze Dagger/Festering.

For this one I again made minor additions to templates, Item infobox and Recipe, for capturing the data into semantic properties. However, I also modified Recipe further to remove the {station} and {rank} parameters, since they are directly derived from {discipline} and {level} and thus don't need to be noted separately. Furthermore, I combined the multiple {discipline#} parameters into a single {discipline} that takes a comma-separated-list as input, then parse it using the #arraymap: function (provided by the Semantic Forms sub-extension). Since I transferred all the pages by using Special:Export, I was able to run a find/replace on the XML file to update all usages of {{recipe}} to use this new parameter structure. —Dr Ishmael 05:14, 2 May 2012 (UTC)

I have been refraining from getting involved in this seemingly technical discussion, mainly because (as many of you know) my qualities are found in graphical design, extremely wordy walls of texts, and categories, rather than technical aspects of the wiki, especially behind-the-scenes technicalities.

Now that I have read the discussion and seen the examples, my first impression is probably one of the more important arguments in favour of this extension; it looks extremely basic to edit with. This in opposition to DPL, of which I still only understand various basic techniques (after having been actively involved with wikis for at least 5 years now (not just GW2W)). In case of user-friendliness, this is a near-infinitely much better way to do what we're currently doing with DPL (assuming everything DPL does, this extension can do too, or do better).

If it can also do more than DPL, this has my full support. - Infinite - talk 16:55, 2 May 2012 (UTC)

I really like this too. Being a terrible coder, and not understanding how to code DPL much at all, I think this is much easier to use with less headaches. If I understand it correctly it seems like SMW can do more with less work compared to DPL. --Lania 17:14, 02 May 2012 (UTC)

Yes, this is (almost always) much easier to use than DPL, especially if we start making use of it now. In particular, SMW allows us to simplify the number of variables that need to be specified (e.g. see Ish's notes above about recipes), which makes it more likely that we are able to be more comprehensive and accurate more quickly. Another example would be map locations: if we were using SMW to describe Waypoints and PoIs, then each map article could automatically present the list on the page and the counts in the page's infobox; we wouldn't have to manually keep track.

Is there any reason why we shouldn't head down this direction? – Tennessee Ernie Ford (TEF) 17:29, 2 May 2012 (UTC)

Allow me to rephrase: we seem already to have a consensus that this would be useful and beneficial. Is there anyone who thinks this requires more discussion before allowing Ish to begin implementation (including laying out a project to follow through on details)? (Also, in case it's not obvious, I'm happy to help make this happen.) – Tennessee Ernie Ford (TEF) 17:35, 2 May 2012 (UTC)

Oooooooh yeah, maps. No need to stop at simply counting and listing the places in an area - map them. There's a Semantic Maps extension that makes it very easy to create maps with placemarks using a service like Google Maps or OpenLayers - store the coordinates in properties on the place's article, then just run a query for the places you want to display. I'm pretty sure it's possible to use custom map layers in at least one of those services, i.e. display a map of Tyria. I've played with that a little bit, but if there's anyone who has more experience working with map services like this, that would help a lot. —Dr Ishmael 18:20, 2 May 2012 (UTC)

Have you seen the previous map work that was done on GWW? gw1:Ascalon/Map --JonTheMon 18:25, 2 May 2012 (UTC)

Yes indeed. I had wanted to do that on GuildWiki for a long time, but the template work required was beyond my abilities at the time. I gave up on it completely when I saw it on GWW, because they did a great job with it there.

Semantic Maps would add all the features of a full map service, like pan, zoom, and placemark annotations (e.g. click on a Heart or Skill icon to show the "quest" name, description, "quest"-giver, etc.; not too useful for waypoints or PoIs, though). It would be a lot of work, but I'm sure that eventually we could replicate the in-game map almost exactly. —Dr Ishmael 18:40, 2 May 2012 (UTC)

Waypoints and points of interest all have names though, so even to that extent it can be quite useful. - Infinite - talk 18:42, 2 May 2012 (UTC)

True, but if consensus decides to display the name with the placemark, then there's nothing else to display in an annotation balloon. Anyway, we're probably getting ahead of ourselves here. —Dr Ishmael 19:15, 2 May 2012 (UTC)µ

Somehow i seem to have missed this discussion. Here i was bravely starting to figure out how to code maps by hand. Definitely support this.--Ee 13:52, 3 May 2012 (UTC)

Your page would be a good place to centralize discussion on this specific feature, so don't get rid of it or anything. Like I said, it's gonna take a lot of work to implement this, and I'm sure there will be lots of discussion about the details. —Dr Ishmael 14:16, 3 May 2012 (UTC)

(Reset indent) So, I'm not opposed to this extension, but I think it definitely requires some thought and planning before we decide to implement it. From my talks and discussions it looks like SMW is slightly weaker with categories. It automatically includes all pages in sub-categories and is not able to exclude categories either. This mostly comes into play if you wanted, say, a list of traits, but not historical traits, or a GW example would be non-PvE-only warrior skills. So, I think we'd need to think of how to handle exclusions before implementing.

Also, I'm not sure if we've addressed this, is the intent to have SMW alongside DPL, or to migrate from one to another? --JonTheMon 13:18, 4 May 2012 (UTC)

There are ways of handling exclusions - the easiest is by letting infoboxes, which are used on all pages of the same type, set boolean properties for these filters. For example, instead of applying {{historical content}} separately, add a historical= parameter to the various infoboxes to display it and set a boolean Property:Is historical on all pages.

Tanetris above mentioned a full migration to SMW so that we don't have to maintain both extensions. However, I am not opposed to keeping DPL, because there are things it can do that SMW can't. Namely, DPL can access wiki-level page data like revisions, contributors, and links (to/from other pages and transclusions), where SMW can only access a limited subset of this data (creation time, last modification time, and last contributor). In other words, DPL can do stuff like this that SMW would have difficulty with.

For namespaces, DPL can directly access and act on that information at runtime, but SMW has a configuration setting where specific namespaces are explicitly enabled (pages in other namespaces will not set any properties). My thinking is that we'll only have SMW enabled for mainspace, so there won't be any need to filter on that anyway. —Dr Ishmael 14:26, 4 May 2012 (UTC)

Another tech demo: Bronze Dagger - see section 'Base ingredient cost'. I built a recursive semantic template that factors out a recipe to the basic crafting materials, showing the full set of materials required to craft the item from scratch.

@Jon: I haven't forgotten about skill lists, I've just felt more inspired to work with crafting recipes for some reason. —Dr Ishmael 06:28, 5 May 2012 (UTC)

List of warrior skills is converted. Works the same as current implementation, setting skill description and recharge into variables that are called from within the table. One thing I changed is that it also does this for skill point cost in the same query, rather than running a separate query to get the sp-cost on each individual skill. (That could probably be updated in the DPL here, too, to make them more efficient in the meantime.) —Dr Ishmael 20:43, 5 May 2012 (UTC)

A bit late to the party (and pretty confused where to reply xD), just a quick heads-up from me: First of all note that we are using a different, (sadly) still non-public version of DPL which has the security issues fixed, so we don’t necessarily need a replacement extension for DPL. Instead I would favor keeping DPL around for a while longer just to a) have the current pages keep working, and b) allow people to use DPL where an SMW solution isn’t available yet.

That being said, I do not have a strong opinion about SMW – which abbreviation really confuses me; Super Mario World anyone? – I can’t really comment on details, as I haven’t used it much myself, and Ishmael definitely knows more about it. It definitely brings a lot cool features but also requires quite a bit maintenance and – and this is important – clear rules what properties to set up and how to name them. It’s only semantic, as long as the property names are semantic. So when we add it, we should be clear from the beginning on how we use it.

But overall I think it makes sense to have it installed, especially as I feel that in GW2 things are much more connected than before. Regarding SMW <-> DPL, I’m not sure if either can do everything the other does. I don’t think we ever touched the really craziest things in DPL yet though, so we should be able to replicate most of it with SMW. I’m not sure if something like the Nicholas Research pages would work as easily.

One thing that should be clear however is that DPL is way more flexible than SMW. When you could "easily" query DPL everything there is on a page, or a template, SMW will require those semantic bits to be set explicitely (at least most times).

That being said, sure, bring it on! ^^ poke | talk 15:35, 18 May 2012 (UTC)

Yes, SMW does require more pre-planning, whereas DPL can work however you set up the templates. As a general rule, each input to a template should be stored as a separate property, which allows SMW to access the same template data that DPL can.

Regarding Nick, see here. That table is generated by SMW based on properties of the item and location pages. —Dr Ishmael 16:37, 18 May 2012 (UTC)

As a follow-up to my comment just above about "pre-planning," I am beginning to draft the semantic data model for this wiki at [[User:Dr ishmael/SMW]]. Feel free to contribute with any ideas you may have. Currently, the only aspects of the game I really feel familiar with are skills, traits, and crafting - that leaves weapons, armor, all other items, locations, NPCs, and lots of other stuff that I don't know much about, so I'll need everyone's input on what properties should be set up for those types of articles. —Dr Ishmael 01:51, 1 June 2012 (UTC)

This section is currently buried in a fearsome wall-o'-text in many topics--might I suggest to the audience at large a new header or some other methods of cleaning/archival to facilitate easier feedback? Redshift 02:32, 1 June 2012 (UTC)

Implementation of Semantic Forms

And finally, I have an implementation of Semantic Forms. This is actually the biggest reason I wanted to get SMW installed here, because a well-configured form makes it very simple for a new user to enter data on the wiki.

Form:Skill is the form definition page, so you can click "edit" there to see the form markup. Also go to Arcing Slice and Blowtorch and click "edit with form" to see how it works on an actual skill page.

I made quite a few conceptual modifications to the infobox parameters in setting up the form, and I haven't completely implemented these in the infobox itself yet. The form itself isn't even 100% feature-complete, either, but that's mostly because I don't yet have comprehensive knowledge of the GW2 skill system. If anyone would like to discuss these changes, I've written explanations for some of them on the form's talk page. —Dr Ishmael 02:45, 13 May 2012 (UTC)

Awesome. I'm looking forward to using this (and allow these definition articles to help automagically populate lists, categories, and various other content that the community will find hard to keep in synch otherwise). – Tennessee Ernie Ford (TEF) 03:04, 13 May 2012 (UTC)

Caveat - A new build is available

Since it's looking more likely that SMW will get installed here, I should point out that the current version of most of the semantic extensions (and SMW itself in its next release) no longer support MediaWiki 1.16. To install most of them on the wiki currently would require reverting to an older version that still supported 1.16.

I don't know if a MW upgrade has been discussed here yet, but it's probably time to do so. Curse spent the past couple months upgrading all their wikis to 1.18, and just today Wikimedia released 1.19. I would strongly recommend we upgrade to at least 1.18, not just for SMW but also for the general reasons - bugfixes, efficiency improvements, new features, etc. —Dr Ishmael 19:31, 2 May 2012 (UTC)

Last I heard we were planing to go straight to 1.19, we were just waiting for the release (and for the server guys to have time). - Tanetris 19:56, 2 May 2012 (UTC)

Great, I was afraid I'd be opening a can of wurms here. That's a lot less to worry about. —Dr Ishmael 20:17, 2 May 2012 (UTC)

Sorry if I sound antsy with this or anything, but what sort of timeline can we expect on getting MW upgraded and SMW installed? At GuildWiki, I have commit access to Curse's Hg repository, so I'm used to being able to make changes and have them go live pretty quickly. I know the MW upgrade isn't going to be a simple deal, so I'm expecting to wait a week or two. Still, I'd like to see us get semantics in place before the next BWE. I'll continue working on stuff over at my SMW testbed mirror in the meantime, of course. —Dr Ishmael 19:23, 3 May 2012 (UTC)

Start a discussion/subpage at GW2W:TECH? --JonTheMon 19:29, 3 May 2012 (UTC)

Oh, good idea, didn't know about that. Maybe this whole discussion should be moved there? —Dr Ishmael 19:39, 3 May 2012 (UTC)

SMW vs DPL (a tl;dr comparison)

Although they offer similar functions, SMW is often easier for non-experts to use to answer questions they might have otherwise not available on a specific article. The Doctor Who wiki has a [[wikia:tardis:T:SMW#The fun stuff|great example]] comparing the ease-of-use of SMW to DPL. If you're interested in a exercise for the reader, compare how the GW1 wiki handles Nicholas the Traveler's collections vs how it's done at Guild Wiki. GWW has to create a dummy table whereas GWiki just reads properties that are already stored at each item. It means virtually anyone at GWiki can make a simple update each week to keep Nick current, compared to GWW requiring that people understand a little of how the code is setup. (To be fair, some of that is the design of the system, but it's easier for the novice to do similar things on their own using SMW.)

When GuildWiki first considered adding SMW, I wasn't a supporter because I thought that DPL already did a great job of dynamically producing lists. However, now that I've seen what both can do, I find SMW to be more useful and easier-to-use. It has allows us more flexibility in overlapping classifications and means we don't have to create huge (otherwise unneeded) categories just to run queries. – Tennessee Ernie Ford (TEF) 18:57, 29 June 2012 (UTC)

I still have to learn more about SMW, but seeing this it feels so easy and yet so complete, when you switch to SMW, will you wipe all those DPL calls or use both? – Valento ^msg 00:20, 30 June 2012 (UTC)

There are some things DPL can do that SMW can't do, because they have different goals. Primarily, DPL can access a lot of metadata about articles that SMW doesn't care about, like template usage, image usage, links to/from a specific page, the users who created the page and last modified the page, old revisions of a page (SMW is only concerned with the present revision), etc. So we'll keep DPL around for applications that need that kind of data, but for the most part we'll be able to replace it with more efficient SMW queries. —Dr Ishmael 00:34, 30 June 2012 (UTC)

Vendor tables

We will eventually set the "cost" for items in the vendor tables themselves. We would have a record that holds item, cost, and type of currency/token. The item itself wouldn't bother with displaying the cost in the infobox, we would have a section that generates a table with all the vendors, along with their locations.--Relyk ~ talk > 08:35, 11 May 2013 (UTC)

Records wouldn't work, because in a query, you can't return just a single record off of a certain vendor's page, you'd get all of them. This is where subobjects are required, because a subobject acts like a separate page when you're running a query - the query can select individual subobjects and return only the properties of that subobject. —Dr Ishmael 15:01, 11 May 2013 (UTC)

The record is a blab to store information. Just wondering if we want to do this as the current approach is listing all the costs in the infobox (with the obvious drawback of not connecting the information to the vendor).--Relyk ~ talk > 20:37, 11 May 2013 (UTC)

A subobject is also a blob to store information, the difference is that a subobject acts like a separate page, while a record belongs to a page. (You can also assign arbitrary properties within the subobject, instead of being restricted by the record's definition.) If you tied the cost to the vendor using records, then when you tried to query for a specific item's cost on the item's page, the query would return all the records for all the items the vendor sells, and you'd have to parse through them for the one you need. With subobjects, you can directly query for the single object that defines that item's cost. —Dr Ishmael 21:36, 11 May 2013 (UTC)

The record was an arbitrary word for whatever method we use to store and retrieve the data. I think I used "blab" right, it means "chatter thoughtlessly or indiscreetly" :D--Relyk ~ talk > 21:55, 11 May 2013 (UTC)

Sorry, that really wasn't clear. And I assumed you had typoed "blob". —Dr Ishmael 22:57, 11 May 2013 (UTC)

Automaticly add NPC to location page.

Would it be possible to automatically add a NPC to a location page. Template_talk:NPC_infobox#Automatically_add_as_ally_or_foe_to_location_page. Anzenketh (talk) 21:22, 18 August 2013 (UTC)

List of weapon models

Barring entire sets that share skins, if we want to generate a basic list of weapon models for each weapon type, we need to tag the images with a specific id to map all weapons using that model to that id. We can keep unique images for each weapon that way. Then the gallery can display the appearance of the first weapon and have the caption display the simple comma-separated list of weapons with an image having that id (maybe the item icon id?)--Relyk ~ talk < 19:23, 12 September 2013 (UTC)

Browsing bug

occasionally I'm finding that the (Next 25 | Previous 25) buttons on property pages are not appearing. (I added {{property index}} to get around this) -Chieftain Alex 23:43, 13 March 2014 (UTC)

Locations, NPC movement, and Location pages

Is there a way that we can systematically update location pages with what NPC's are located there based upon the infoboxes or other information on the NPC pages. There are some NPC's that change quite frequently It would be easier to just change the NPC pages and that update the other pages as needed. Anzenketh (talk) 17:35, 26 May 2014 (UTC)

Turns out I already asked that question once here.Anzenketh (talk) 18:20, 26 May 2014 (UTC)

Locations and sub-properties

I was wondering if we can have locations setup as sub-properties this would allow us to more easily call upon a specific location type (Zone,Area,Region). Anzenketh (talk) 16:15, 31 May 2014 (UTC)

This exact proposal has been made before: Guild_Wars_2_Wiki_talk:Projects/Cartography#Turning_locations_into_true_subcategories. tl;dr that's not what subproperties are for, use property chains instead. —Dr Ishmael 16:41, 31 May 2014 (UTC)

Hum. Guess I will just have to figure out another way to sort {{NPC service list}} by region I don't even know if this is possible. Anzenketh (talk) 18:54, 31 May 2014 (UTC)

You can't do it in the query, you can make the table sortable and people can sort by region or zone if they need to. You can also use #arraymap if sorting by location is desirable, although it has some issues.--Relyk ~ talk < 19:31, 31 May 2014 (UTC)

It wouldn't be possible even with subproperties. —Dr Ishmael 20:22, 31 May 2014 (UTC)

Drilldown

I remember seeing Ishmael testing a few semantic drilldown filters on the test wiki. These didn't make it over to here. I added a super basic one to Category:Shields a while ago but I've not added it anywhere else. (I guess we'd use a template to apply the drilldown filter since its going to be pretty generic across the same category?)

I don't know anything about drilldown yet, but the "Choose a category:" option at the right hand side is producing some pretty poor category suggestions, ideas to fix those? -Chieftain Alex 22:04, 22 October 2014 (UTC)

Just spotted that all the suggested choose a category options were redirects. -Chieftain Alex 22:10, 22 October 2014 (UTC)

I see. All of the categories that were listed were top level categories because they either weren't in another category or they were redirects. After deleting/fixing the categorization the filter options disappeared >< oops -Chieftain Alex 22:14, 22 October 2014 (UTC)

Adding an uncategorized (top level) category, or adding _ _SHOWINDRILLDOWN__ makes forms possible.

I've added it to categories that contain pages with infoboxes such as Bestiary, NPCs, Locations + Items to get us started (and make the filters appear...) -Chieftain Alex 22:22, 22 October 2014 (UTC)

Removal of Extension:Semantic Drilldown

I'm going to suggest this extension is removed. The extension status has been downgraded to "beta" on MediaWiki as the original maintainer stopped having interest in it in September 2022.

The drilldown pages were a cool idea, but in reality due to the way they display (a) deleted pages, (b) don't play nicely with subobjects, we end up missing a load of relevant content with the drilldown pages. Example: https://wiki.guildwars2.com/wiki/Special:BrowseData/NPCs

For the categories I added the SHOWINDRILLDOWN tag to in 2014 (NPCs, Items, Bestiary, Shields), I've removed the flags today. -Chieftain Alex 11:34, 16 September 2023 (UTC)

Skill challenge

I'm thinking of adding "Property:Provides skill challenge" to skill challenge articles. Differentiating the source of the skill challenge and actual event is really annoying. A general flag for the source of the skill challenge is an easy way to semantically query for skill challenges.--Relyk ~ talk < 21:48, 2 May 2015 (UTC)

How about instead we just fix the categorization?

Infobox	Current challenge category	Proposed category
Template:Object infobox	[[:Category:Hero challenge objects]]	no change
Template:NPC infobox	[[:Category:Hero challenge NPCs]]	no change
Template:Event infobox	Category:Hero challenges	Category:Hero challenge events
Template:Item infobox	no category	Category:Hero challenge consumables

Hmmm... okay, it's not that much of a change, actually. But if we changed those, then you can see that you would look at the objects and NPCs subcategories for the actual challenge triggers, at the events subcategory for the triggered events, and at the consumables subcategory for the received items. I don't think we need a property. —Dr Ishmael 01:34, 3 May 2015 (UTC)

The thing with consumables is they don't have a location semantically.

{{#ask:<Give me all the skill challenges>[[Located in.Located in::<zone>]]
|?Has game context
|?Located in
}}

What we really want to list is the location the consumable is received in a list of skill challenges. So the query will ask for [[Category:Skill challenge objects]][[Category:Skill challenge NPCs]][[Category:Skill challenge events]] and we guarantee that the sources give consumables? We don't have a property connecting the source to the consumable item though, which makes the query rather weak. Do we add like [[Property:Gives skill challenge item]] to those pages?. The object infobox already has that parameter, but not the NPC.--Relyk ~ talk < 00:23, 4 May 2015 (UTC)

No, you only have to look for objects and NPCs - they both already have locations. Consumables are given by either an object or an NPC. Events are triggered by either an object or an NPC. —Dr Ishmael 02:59, 4 May 2015 (UTC)

Not sure how that allows us to present skill challenges to readers then.--Relyk ~ talk < 03:14, 4 May 2015 (UTC)

{{#ask:[[Category:Skill challenge NPCs]][[Located in.Located in::Blazeridge Steppes]] OR [[Category:Skill challenge objects]][[Located in.Located in::Blazeridge Steppes]]}}

If you want to connect the items/events to the NPC/object, then you need a property (or two) to link them, of course. But your original idea of a boolean that simply identifies the challenge initiator is unnecessary. —Dr Ishmael 04:01, 4 May 2015 (UTC)

That sounds fine then.--Relyk ~ talk < 20:37, 4 May 2015 (UTC)

Specializations

Time to wrap the properties in a template. With core and elite specializations, an infobox would be a good idea at this point. The semantic annotation on the pages are dumb.--Relyk ~ talk < 05:53, 5 July 2015 (UTC)

I've replaced the dumb annotations with a dumb invisible infobox that looks like nobody touched the page. Infobox now provides cname, icon, profession, type (core/elite) + categories. Categories need renaming probably. -Chieftain Alex 18:14, 9 July 2015 (UTC)

Okay let's talk about cutting down properties

So according to Justin we have about 1.3 million property values set. That is more than quite a few. I agree with the premise that we should consider reducing the number of properties, especially if it leads to less god damn 502 and 503 errors.

I've had a look at where these properties are distributed, and grouped them by property category, so in rank order the biggest seven categories are as follows:

1. Item properties — 323072
   • "Is unique" - don't set this for non-ascended gear?
2. General properties — 314317
   • Has availability + Is historical... these kind of serve the same purpose but allow us to discriminate between the two
   • Why store "Has description" for anything except skills + traits?
3. Recipe properties — 187213
   • Removed all the v2/mystic API non-record properties
4. Vendor properties — 90859
   • Not sure if we use the vendor unit price
5. NPC properties — 13164
   • Really all we should need would be the Name, Level, Service + Drops item. I don't think there's a point in storing the rank, appearance or race.
6. Skill properties — 9752
   • We shouldn't need to find lists of non-ground targeted skills.
7. Location properties — 6587
   • Lots of nested queries. Map completion has the important totals, we could query on the zone page, but there isn't really a point in doing it for an entire region or continent.

These values are what has currently been generated since the rebuild, so this isn't the grand total, but the ratio will be about right I think.

Google spreadsheet (edit: new link). Please add any useful notes that you wish. -Chieftain Alex 19:27, 16 August 2016 (UTC)

My ignorance of SMW might be reflected here, so keep that in mind while reading.

As a general rule, people don't give a damn about items being unique if they aren't ascended (do unique <ascended even exist?), so I think that keeping it listed but having the option to search them removed is acceptable. Ascended trinkets however, I can see the need to know what is unique or not (but this really shouldn't be that many items).

With regards to NPC properties; would removing the option or "race" prevent any search for say "all female norn"? if so then I'm not sure it's good idea to dump it. Additionally, isn't "Has appearance" useful to make a link between images and their page? I'm not 100% sure about that... -Darqam (talk) 19:45, 16 August 2016 (UTC)

We don't even store the gender so you'd be searching for "all norn", but yeah i guess it might be useful for the NPC model project (kinda). I'm just looking at what we have + trying to figure out why it's useful or not. -Chieftain Alex 20:07, 16 August 2016 (UTC)

There are unique items that aren't ascended, or even equipment: Unique#Other items. I found that list interesting enough to write the query to generate it, at least... (but I don't think there's any need to store Unique=false for non-Ascended items, since that's the default and thus uninteresting state for them). -- Dagger (talk) 20:00, 18 August 2016 (UTC)

What about "Has minimum power", "Has maximum power" and "Has weapon strength"? -- Dagger (talk) 17:50, 19 August 2016 (UTC)

I've set the "Is unique" property if the parameter has been given, and stored negative responses if the item is ascended rarity.

I can't think why weapon strength isn't just a string with "<max value>—<min value>" (i.e. one property instead of three)

I'm also now wondering if we really need to store detailed item subobjects for things in templates such as {{craft table row}} (the table displays the data, why would I want to query it) or {{Loot variant table row}}. -Chieftain Alex 18:19, 19 August 2016 (UTC)

Why is this being brought up? Why do you think the number of properties is related to performance issues? Justin hasn't said why SMW was causing issues. Do you have any way of showing that's in fact the issue? Are you going to make all these changes and hope that the problem is fixed? If it doesn't, are we going to rollback the changes or something? Why do you consider 1.3 million "quite a few"? Have you checked whether other sites have issues dealing with the properties. I also find it silly how you're focusing on the location infoboxes as an issue when you have no testing to show. Those aren't even nested queries, unless you mean subqueries (which those are not). Why are we making decisions based on what we find useful or not? We don't know if something is useful or might be useful in the future. I completely disagree with the proposal until we understand why SMW jobs were causing issues.-Relyk ~ talk < 06:25, 21 August 2016 (UTC)

Okay relyk, here's the quote I've started this from

“

.. FYI once we've fixed the 2 problems we're currently facing (SMW jobs getting stuck, 502 errors), I'd like to start a public project to see if any cleanup of the SMW information can be done (e.g. eliminate redundancy, useless info, etc.)...

— --Stephane Lo Presti talk 14:36, 16 August 2016 (UTC)

Admittedly I started looking at this problem before the SMW job queue finished, so the numbers + order above don't reflect the final count. I'll update them in a second using the google spreadsheet.

You are correct that we don't know if the 502 errors are related to the size of the SMW database, however the current size is unsustainable if it takes a week to process a new SMW database. I think it is a practical suggestion to try and remove redundancy anyway. The 502 errors are quite a recent problem, as in they popped up only in the last few months, they persistently been there since the beginning of the GW2W - something has changed, and while we have had some mediawiki updates, the database is constantly growing, and if we can reduce the burden on the servers then we should. -Chieftain Alex 09:55, 21 August 2016 (UTC)

• Updated count:
  • Total - 1,599,080 (1.6M) - 100%
  • General properties - 582075 - 36% of total
  • Item properties - 413227 - 26% of total
  • Recipe properties - 221620 - 14% of total
  • Vendor properties - 201314 - 13% of total

These amount to ~90% (1418236) (1.4M) of the SMW properties stored on the wiki. To put this in perspective, the german wiki has most of the functionality that we do, but has 700k. We have double that. -Chieftain Alex 10:04, 21 August 2016 (UTC)

w:Wikipedia:Template limits#Why are there limits? - effectively there's a chance that we're DoSing ourselves if a page wih a large hefty query or #set/#subobject calls gets purged. -Chieftain Alex 10:22, 21 August 2016 (UTC)

The French wiki had 950k (and IIRC a lot of it was created via bots) --Stephane Lo Presti talk 23:58, 24 August 2016 (UTC)

Hi Relyk and Alex, First thanks to Alex for starting this discussion. While we do not have solid evidence between the 502s and the amount of SMW property values, we: 1) suspect that they could contribute, but we're not sure how (it could be the amount, or how they're setup, or how they're queried, or a combination); and 2) wonder if this very large number that's not going to stop growing could lead to even more issues. We're continuing to investigate on several front but I thought I'd ask questions on the SMW content meanwhile, hence my quoted sentence. I do think that givew how heavily SMW is used in this wiki, it'd be a good practice to check the redundancy, consistency and efficient of all this information (on a regular basis). As we're not very fluent in SMW, we rely on this community to help us figure this out. If there's something we can do to help with this discussion, please let us know! --Stephane Lo Presti talk 23:58, 24 August 2016 (UTC)

Re: Black Lion Weapons Specialist (The Vaults)

This page was mentioned on Guild Wars 2 Wiki:Reporting wiki bugs#502 and 503 errors as not even loading, so I did some poking. When you edit that page, you might get a 502 error. If you get a 502, it happens after 30s, and if you don't then the parser profiler gives the CPU time used as being 25~28s or so. The page consists almost exclusively of calls to {{vendor table row}}. So I think it's safe to conclude that taking more than 30s to render is the cause of the 502 here, and that it's something in {{vendor table row}} (probably but not definitely SMW-related) that's causing the CPU usage.

That page has 308 vendor subobjects (here). Each subobject has 8 properties (here). 25% of those properties, per the above discussion, are redundant.

So what I'm thinking is: we have some properties which are set frequently on the page and should be removed, so let's do that. But more importantly we also have a way of measuring the impact of doing so, via the render time of the page. And if removing these properties doesn't help much, we have a template ({{vendor table row}}) that we can copy and disable bits of to measure the impact on its rendering time, which might give us a better idea of where the problems are. -- Dagger (talk) 18:24, 26 August 2016 (UTC)

...for example, 308 calls to {{Item icon}} takes ~7.4s to render, so something like 20-25% of the time spent creating Black Lion Weapons Specialist (The Vaults) is spent just on making the item links. (Did anybody reading my last message think to blame {{Item icon}}? Didn't think so.)

I managed a 25% reduction in {{Item icon}}'s CPU use by doing a single query to fetch the game icon and canonical name (with a separate template to render the final result). As what has to be our most used template, speeding it up would not be a bad thing (but I have no way to measure how much of our total CPU time is spent in that template, so it's hard to say how much this'll help wiki-wide 502s.) -- Dagger (talk) 21:10, 26 August 2016 (UTC)

If you switch to only storing the subobjects instead of rendering tables as well, then the real CPU time reduces from 39.75s to 4.797s for Black Lion Weapons Specialist (The Vaults). I agree that there must be savings to be made here (obviously subobjects without any tables takes it to an extreme). I don't know if using a result formatting subtemplate for {{item icon}} will cause us to hit the template transclusion limit instead, worth a shot though. --Chieftain Alex 21:56, 26 August 2016 (UTC)

Ugh, right, transclusion limits. Although there's an argument that any page big enough to hit the transclusion limits perhaps ought to be rewritten to, as Relyk points out, remove the {{Item icon}} calls completely. Another option is a "lite" version of {{Item icon}} that only looks up the icon and not the canonical name. (How did you get 39.7s? I just get errors for anything above 30s.) -- Dagger (talk) 09:30, 27 August 2016 (UTC)

FYI 30s is the regular timeout, when an error gets sent by the server. We're investigating what is causing the 502s that have been reported to us (as unfortunately last week's semantic database rebuild didn't help). Your analysis of the render times is interesting, is this something you're doing on the client side (e.g. Chrome's dev console)? If you have clues, questions or comments that can help us, let us know! --Stephane Lo Presti talk 22:19, 26 August 2016 (UTC)

The 502 error says "an upstream server returned an error"... do we know what the upstream error is? I'd hate to be doing all this guessing if the server secretly responding with something more useful than "something went wrong". -- Dagger (talk) 09:30, 27 August 2016 (UTC)

@stephane, look at the "Parser profiling data" on Show Preview.

So 25% of 8 properties is 2 properties. I assume you mean Property:Is historical and [[Property:Has unit cost]]. I don't know what you mean by properties "set frequently". You probably can't tell me what Has unit price is for (Hint: It's not being used yet), yet conclude we should remove it. Has unit price is literally dividing the quantity by the quantity to get unit cost for the item. The purpose is so we don't have to use a query and format template to output the unit price in tables. I decided on doing it this way to keep our query templates clean and there's little overhead as the item quantity has to be updated in the subobject anyways. I'm hard pressed to come up with a better solution.

The cost of additional properties in a subobject are minimal because we're already paying the price for a subobject. Neither of those properties are used in queries and they aren't likely to be used in subqueries. Historical is already deprecated and we don't use it in any queries. Alex and I have slowly cleaned up historical parameters, but just be careful of breaking templates. If you want to test the overhead of the subobject creation, you can do a simple test like:

{{#arraymap:1,2,3|,|$$$|{{#arraymap:{{numbers|1|100}}|,|@@@|
{{#subobject:$$$@@@
|Property1=1
|Property2=2
|Property3=3
|Property4=4
|Property5=5
|Property6=6
|Property7=7
|Property8=8
}}
}}}}

We already did the optimization for {{item icon}} on {{Recipe list result format}} and I left notes on Template talk:Recipe list result format (If you want to catch up on some stuff Dagger). {{item icon}} isn't designed for formatting templates, and the template should handle this itself. The reason we didn't do this on {{vendor table row}} is the vendor quantity field is in between the item icon and the rest of the information. This means adding a userparam for vendor item quantity to the item lookup that we already do for the item and it results in more complicated code.

The main overhead on pages with vendor entries is from rendering rather than subobjects, as you concluded. This is what I explored on Template talk:Inventory/Vendor subpage header for options to edit entries without rendering them. This is why I wanted an explicit data content tag and options for not rendering the pages. I want to hide the tables on pages that involve semantic properties to making editing easier all though you don't get a convenient preview of the resulting table. That's why I don't like transcluding these tables and would rather generate the tables on NPC pages with queries. The wiki will have an easier time caching the pages that way, the downside being that you have force the query to update as an editor. The intermediate solution is what I implemented on Gem Store, moving Gem Store section to subpages and historical to reduce render time.--Relyk ~ talk < 02:18, 27 August 2016 (UTC)

I ended up using a script with the API action=parse function, but it's the same stat you can get by looking at the preview page. (I can post the script if anyone else wants to use it.)

I got the impression that we thought it was the creation/setting of lots of subobjects/properties was a problem... but completely removing the subobject creation from BLWS(TV) won't even reduce its render time to below the 30s limit, so actually it doesn't take that much time compared to the rendering part. This also suggests that splitting {{Vendor table row}} up into separate SMW data + render parts might not actually help much, because we'd be replacing the time spent setting subobjects with the time spent looking those subobjects up. (Unless we can arrange things so that changing one table doesn't require re-rendering all the other tables? But if so, couldn't we do that without breaking preview?)

"{{item icon}} isn't designed for formatting templates, and the template should handle this itself" sure would be nice if that was mentioned on {{item icon}}...

Looking at {{Recipe list result format}}, it looks like we ended up just having the two queries from {{item icon}} (which take 2/3rds of the total time) in the main template. It'd be even better if we could get that down to a single query... but then we're back to needing a subtemplate for the formatting, because SMW doesn't have an output option that just takes a format string for the output. Sigh. -- Dagger (talk) 09:30, 27 August 2016 (UTC)

Not sure what you're talking about for vendors or if my comment already answered that. As far as as item icon comment, this applies to all templates that make semantic queries. Editors maintaining templates have to be aware that semantic queries are used in template and familiarize themselves with SMW if they aren't. Recipe list isn't going to have issues because 95% of items are used in 1-2 recipes, the outliers will obviously be crafting materials. The expensive part is not {{item icon}} but listing the recipe ingredients. Like I said before, I don't look at optimizing this part unless we identify it as a bottleneck. What we do need to check for is pages using {{recipe list by discipline}}, which is much more heavyweight than recipe list. For example, we split pages like Obsidian Shard into sections when it gets too large and started causing errors.--Relyk ~ talk < 02:26, 29 August 2016 (UTC)

SMW unused properties

This may only be tangentially related to the topic but since we're talking SMW, I thought I'd ask: do you know what's going on with Special:UnusedProperties? We've also noticed that the SMW properties are back to 1.4 millions, after the rebuild where they were around 1.3. --Stephane Lo Presti talk 14:59, 31 August 2016 (UTC)

I counted 1.6M entries after the rebuild completed (spreadsheet total).

The unused properties are bizarre. Some of them are blatantly asking for {{#ask: [[Has context::Item]] }} or {{#ask: [[Has vendor value::+]] }} - they are probably queries that went wrong or have illegal characters in their names, e.g. blanks or plus symbols specified as query parameters. yet again i don't know how we would track the issue down. -Chieftain Alex 17:40, 31 August 2016 (UTC)

Is there anything we could look for on the backend side of things to help figure it out? --Stephane Lo Presti talk 17:43, 31 August 2016 (UTC)

I've no idea Stephane, I may have a reasonable working knowledge of the user side of SMW, but tracking down obscure issues is mostly beyond me. I've temporarily blanked the semantic Query forms to see if they are the issue. (currently 213 rows in Special:UnusedProperties). -Chieftain Alex 06:31, 1 September 2016 (UTC)

Unused properties has been an issue for a long time before we had any forms. There used to be way more than there is now. I remember the French wiki has the same issues. The messed up red links are probably maligned property annotations that have the # symbol in them.--Relyk ~ talk < 15:41, 1 September 2016 (UTC)

Thanks Alex and Relyk. We'll continue that discussion by email :) --Stephane Lo Presti talk 15:54, 1 September 2016 (UTC)

Documentation

Motivation

The current SMW documention is kinda outdated and incomplete for several reasons:

• I guess it's a tedious and slightly boring task to copy all the stuff and put manually in the same documentation style, also changes in documentation style are hard to apply to all of them.
• Furthermore, at this point it's kinda easy to lose the overview of which property belongs where.

Idea

• Use predefined properties such as Has type, Property description, Allows value and Has fields as well as new properties such as Used by (or Declared by) to store the relevant property information.
• Rather than adding all the property information directly in plain text, we could apply them in one universal format using the template property with the parameters "type", "description", "has fields", "allows value", "used by" and "category".
• Then we could use SMW inline queries to create the SMW documentation pages based on either the template or the category.

Code

• The template property would look like:

This is a [[Has type::{{{type}}}]] property. {{{description|}}}
{{#if: {{{allowed values|}}}|<nowiki/>
;Allowed values
{{#arraymap: {{{allows value|}}}|*|@@@|* [[Allows value::@@@]]|\n}}
}}{{#if: {{{has fields|}}}|<nowiki/>
;Record
* [[Has fields::{{{has fields}}}]]
{{#if: {{{used by|}}}|<nowiki/>
;Used by
{{#arraymap: {{{used by|}}}|*|@@@|* [[@@@]]{{#set:Used by=@@@}}|\n}}
}}{{#arraymap: {{{category|}}}|\n|[[Category:{{{category}}}]]|}}

• Alternatively, we could either use more inline text (e.g. "This is a page property") or more paragraph headings (e.g. "Type <newline> Page <newline> Description <newline> It describes the ...")
• We might want to be able to add additional information for the parameters "allows value" and "used by"; thus we might need to introduce a separator and use #explode.

Example

• The property Has achievement type would have the following wiki text:

{{Property
| type = Text
| description = It identifies the type of an achievement from a set of seven choices.
| allows value =
* standard
* meta
* repeatable
* daily
* daily meta
* weekly
* weekly meta
| used by =
* Template:Achievement table row
| category = Achievement properties
}}

SMW documentation with inline queries

• Once implemented, all properties related to a template or category could be obtained by using the new template property doc with the parameters "template" or "category" in order to create the SMW documentation.

{{#ask: {{#if: {{{template|}}}|[[Used by::{{{template}}}]]}} {{#if: {{{category|}}}|[[Category:{{{category}}}]]}}
| ?Has type
| ?Property description
| ?Allows value
| ?Has fields
| ?Used by
| ?Category
| limit = 500
| format = plainlist
| template = <result template>
| sort = Category, <!--alphabetically by property-->
}}

• Hence, as long as the properties itself are set up correctly, also the SMW documentation will be complete and up-to-date.

Problems

• I have no idea how using the template property in the namespace "Property" would behave. For example:
  • How would it react to property rebuilds or on MW/SMW upgrades?
  • How would the internal property declarations react to template adjustments even if those are purely cosmetical (e.g. wording or style) and doesn't affect any SMW related stuff?
  • How would the transition from manually added text to a template look like (again, even if SMW-wise nothing changes)?
• The template property needs to be protected (admin only) as one could easily abuse it to break literally all property pages at once.

Final thoughs

I approached this topic pretty much just with the idea of improving the SMW documentation. However, it turned out that by writing down the steps everything seems quite straigth forward. Some steps might need some fine-tuning and adjustments but I hope that I was able to present the overall idea in a solid way.

Obviously, this is more a long-term goal that can only be applied if the wiki is stable again. --Tolkyria (talk) 12:24, 14 October 2022 (UTC)

I had completely forgotten about all of the pages in Category:Semantic MediaWiki. Do we still want them? Many haven't been updated in a long time.

	Modification date"Modification date" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki.
Semantic MediaWiki/Items/Dyes	2013-06-06T13:02:56
Semantic MediaWiki/Vendors	2013-10-07T23:53:10
Semantic MediaWiki/Events	2014-09-08T19:15:30
Semantic MediaWiki/Items/Trinkets	2014-09-26T22:23:58
Semantic MediaWiki/General properties	2015-03-25T13:24:47
Semantic MediaWiki/Specializations	2015-04-30T14:14:05
Semantic MediaWiki/Achievements	2015-11-11T21:52:14
Semantic MediaWiki/Recipes	2015-12-07T15:47:56
Semantic MediaWiki/Items/Back items	2016-02-10T03:07:39
Semantic MediaWiki/Hearts	2018-07-13T04:17:46
Semantic MediaWiki/Objects	2018-07-15T21:21:23
Semantic MediaWiki/NPCs	2018-07-15T21:24:53
Semantic MediaWiki/Locations	2019-01-26T19:05:09
Semantic MediaWiki/Traits	2020-09-01T10:21:17
Semantic MediaWiki/Story	2020-12-05T15:15:39
Semantic MediaWiki/Skill facts	2021-01-11T13:31:27
Semantic MediaWiki/Skills	2021-08-15T03:02:28
Semantic MediaWiki/Items	2021-10-17T20:32:19
Semantic MediaWiki/Items/Weapons	2021-10-18T23:23:10
Semantic MediaWiki/Items/Armor	2022-08-09T17:58:41
Semantic MediaWiki/Guild upgrades	2024-03-02T21:14:08
Semantic MediaWiki	2024-10-01T18:17:59

Personally, if I'm modifying templates and adding properties, I go off the property page only and would never think of looking in this category.

As to the proposal, I would strongly advocate not setting the allows value or record properties based off a single template.

I would be ok however with using a template to record (1) the general description of a property (i.e. the first line of a property page), and (2) which templates it is generally used by (usually we don't have this on the current property pages).

On the documentation page(s), we could then query for the (3) "type", (4) "allows value", and (5) "has fields" special properties (without setting those in a template). -Chieftain Alex 11:47, 16 September 2023 (UTC)