Property talk:Is for profession

Do we really need the "Any" parameter? It's the same as not setting the property at all for wherever we use it afaik. I guess we need it for sorting, but there's no need to display it.--Relyk ~ talk > 02:04, 25 April 2013 (UTC)

Yes, we need it, otherwise we can't query for it. SMW doesn't have the capability to select pages that don't have a property set. It's the same reason we set Property:Is historical to N by default, rather than not setting it at all. —Dr Ishmael 02:47, 25 April 2013 (UTC)

That's what I thought--Relyk ~ talk > 02:57, 25 April 2013 (UTC)

Property type and allowed values

1. What will happen if we turn this property from type "Text" to type "Page"? Or formulated differently: Is there any template that relies on that this property is of type text? E.g. calling the profession icons templates with #show (or #ask) without link = none would break on type "Page".

{{ {{#show: <skill> |?Is for profession}} }}

2. Regarding "Allowed values: Any" and this edit which removed it from the skill infobox. What about removing "Any" from the allowed value list and move it's functionality to the boolean property Is profession skill, maybe together with another new property Is specialization skill.
See also discussion above.

This would allow to ask for:

• 0/1 [[Is profession skill::N]] — commmon skills (currently one have to work with [[Category:Common skills]], no categorization for historical skills)
• 1/1 [[Is profession skill::Y]] — all profession skills (this can be done right now)
• 0/1 [[Is profession skill::Y]][[Is specialization skill::N]] — all profession skills but no elite specialization skills (this cannot be done properly now, one have to use [[Has specialization sort order::0]])
• 1/1 [[Is profession skill::Y]][[Is specialization skill::Y]] — all elite specialization skills (this can be done right now)

Conclusion: After writing this down, maybe simply reactivating "Any" is enough, but introducing this two properties looks cleaner to me. --Tolkyria (talk) 10:07, 13 January 2020 (UTC)

The only reason to use "text" vs "page" is to prevent it correcting the redirect Any → Profession. I've (?) also unwittingly broken Monster skills as an option atm. I'd be happy to switch the profession annotation off for non-profession skills, but that leaves me with a bit of a quandry about Asura etc skills. -Chieftain Alex 00:09, 14 January 2020 (UTC)

Sorry, my bad, see here. In the skill infobox the profession is defined as a {{#var:profession}} at the top, to automatically get the profession based on the specialization only (Is this actually needed? I think all pages with the variable "specialization" also have the variable "profession"). Otherwise it set the {{#var:profession}} to "Monster", if variable monster was used. I replaced the smw part from {{{profession|}}} to {{#var:profession}} which caused the error. (Which raises also the question, what to do with the "slot = monster" that isn't used at all. Simply upon setting the variable monster and ignoring the variable slot seems to be enough, see also my suggestion below for a new approach.)

Regarding the topic. Well, Property:Is for race is a page property and sets it to "Any" which will redirect it, as you said above, to Profession. Maybe we should consider this too, again see below.

Therefore, one step back. We are documenting four "types" of skills, that neither can be captured with skill context (weapon, utility, elite, etc...) nor classical skill type (e.g. Signet, Elixir, etc...), namely:

1. Profession skills
2. Common skills
3. Monster skills
4. Race skills (for me it seems like that they are an own type, they neither really fit into common nor profession skills; with an exception of racial engineer tool belt skills, which are actually profession skills)

Hence, instead of a boolean property as I suggested above, this now sounds more like a text property Has skill supertype which is either set to Profession, Common, Monster or Race.

Remark: Later, if we actually use this approach, we can discuss if "special action" skills are common skills or an own supertype.

This will

1. allow to track profession skills without setting the value Any. If everything else is fine it could be change to a page property (if we want to).
2. allow to track common skills, especially historical common skills which aren't categorized in the category Common skills.
3. remove the currently unused "slot = monster" option and will replace it with the supertype (based on how the supertype will be set).
4. remove the Any value from the Is for race property of type page.

The skill supertype could be either set explicitly with the variable "supertype" or implicitly when one of the variables "property", "race", "monster" are set.

Regarding profession and specialization skills: The property Is specialization skill would be a boolean property as described above and will be set for [[Has skill supertype::Profession]] only.

Conclusion: All different skill supertype skills can be asked for easily with one property, rather than relying on property values Any or categories (which aren't even set for historical skills). --Tolkyria (talk) 14:45, 14 January 2020 (UTC)

I like this proposal a lot (even if its just because "supertype" is an awesome word). This would easily facilitate selecting skills without inserting crappy property values.

I did try to put a table together with supertype vs context to get me thinking about what these properties effectively do...

• Context is really "where is the skill positioned" in the UI.
• Supertype is "who can possess the skill"
• Type is from the description, but is effectively "how does the skill behave"

-Chieftain Alex 22:38, 14 January 2020 (UTC)

Sounds good, that's exactly how I understand it.

I'll try to formulate a roadmap for the Has skill supertype concept, at least what I think are the most important points (to see if I have missed something, etc...).

1. Add the parameter "supertype" to the skill infobox and set the property Has skill supertype with the allowed values: "Profession", "Race", "Common", "Monster".
   • While this parameter can be used explicitly, most of the time the supertype should be determined based on the following parameter:
     • profession: can be set to one of the nine professions and "common" (currently used, imo should still be supported)
     • monster: this parameter defines the monsters which use this skill
     • race: required race to use this skill
   • If parameter monster is set, then set supertype to "Monster" and ignore any further parameters.
   • Else-If parameter race is set, then set supertype to "Race" and check if profession is set to one of the nine professions. If yes, set it also to "Profession". This case will only happen for engineer toolbelt skills that correspond to racial utility skills, hence the supertype "Race, Profession" is allowed. If profession is set to "Common", ignore it (because we are splitting race skills decidedly from common skills). Or set it to "Common" on default, they are a sub-supertype of either "Profession" (engineer toolbelt) or "Common" (the rest). Not sure about this yet.
   • Else-If parameter profession is set to one of the nine professions, then set supertype to "Profession".
   • Else-If parameter profession is set to "Common", then set supertype to "Common".
   • Else none of the parameters profession, monster and race are set, then this skill is a common skill (the way it is currently handled) and set supertype to "Common".
2. Remove the "Any" values from Is for profession and Is for race.
3. Clean up the #var:profession usage in the skill infobox template
   • Do we need the automatic profession query when only the parameter specialization is set? The specialization -> profession was introduced 2015, but 2016 the property setting Is for profession was changed back to parameter profession, ignoring what #var:profession is. So over all this years the parameter profession was required for the correct smw property usage, hence I would remove it (Edit: remove it = remove the automatic profession query).
   • Separate the monster skill part from it, don't forget to set the category.
   • Not sure about the common skill part, it shares the infobox profession entry, so this could be kept.
4. Monster skills:
   • Remove the supported but currently unused slot = "monster", this will be handled by the supertype.
   • Create the property Is for monster?

--Tolkyria (talk) 23:47, 14 January 2020 (UTC)

I've drafted the proposed rewrite so far at User:Chieftain Alex/sandbox5.

For the if-else logic, they should be pretty mutually exclusive apart from engi toolbelt skills so I just stuck them at the same level with if's but no else's.

I've removed 'common' as a profession option atm - it isn't on the current list of valid property values, up to you whether we add it onto the property page and the template. --Chieftain Alex 20:38, 15 January 2020 (UTC)

Your cleanup looks great, I'm impressed how readable this infobox code can be. Thanks!

The reasoning behind my if-else logic.

1. Ad "Monster": what if the monster, e.g. raid boss, is clearly of a certain profession then the wiki users could potentially set monster and profession. To avoid this I proposed an if-else.
2. Ad "Profession": currently we are displaying for common skills the infobox entry: ;Profession :{{common}} Common. So to be consistent between the input and the result we should support that profession can be set to "common" although this will happen only in rare cases.

Please note that your current rewrite does not support "common" at all, neither the current way to display it nor the categorization (please note also that there are some skills that use profession = common). Alternatively, we could choose another way to display that a skill is a common skill in the infobox than via the current profession way.

Of course, whatever option we choose, the property Is for profession will not be set to Common. --Tolkyria (talk) 20:58, 15 January 2020 (UTC)

Edit: The page Profession does not contain the term "Common" at all. So, I'm tempted to find an alternative form of displaying common skills rather than having it associated with Profession. E.g. ;Used by: {{common}} Common if supertype is "Common" or if none of the three other parameters profession, race, monster are set.

Edit 2: It seems like I'm arguing with myself... complete turnaround. The infobox line ";Profession: Common" must remain to clearly indicate that this skill can be used by any profession. Only telling it implicitly, as I suggested in the previous edit, through the absence of the profession line is not enough and must be avoided. Therefore, I claim that the infobox must support the that the parameter profession could be set to "common", although this will neither trigger the supertype "Profession" nor set the property Is for profession. Instead it will be the same as if the three parameters profession (here considering only actual professions), race, monster are not set. --Tolkyria (talk) 21:27, 15 January 2020 (UTC)

See User:Tolkyria/Sandbox for a #var:supertype approach, allowing the supertypes: "Profession", "Race", "Profession+Race", "Monster", "Common". --Tolkyria (talk) 23:37, 15 January 2020 (UTC)

Special cases that I think the template should handle (based on what I said above):

• No parameter set OR profession = common. Result: Display infobox line ;Profession :{{common}} Common, set Has skill supertype = "Common", add "Category: Common skills"
• profession = common and race = human. Result: Display infobox common profession line, but set only Has skill supertype = "Race", add "Category: <race> skills"
• supertype = profession, race. Result: Display profession and race line, set Has skill supertype = "Profession", "Race", add "Category: <profession> skills" and "Category: <race> skills". --Tolkyria (talk) 23:51, 15 January 2020 (UTC)

I was with you all the way up to the last bullet, where you lost me. Why would we want the capability to manually specify multiple supertypes?

{{User:Chieftain Alex/sandbox5 
| description = Beseech Dwayna to [[healing|restore]] your health.
| variables = {{skill fact|healing|6520|coefficient=0.85}}
| recharge = 30
| activation = 1
| profession = engineer
| race = human
| slot = healing
| uw-replaced-by = none
| tool belt=Blessing of Dwayna
| id = 12360
}}

works for all three test cases I think.. -Chieftain Alex 00:02, 16 January 2020 (UTC)

Well, okay... I thought that we should be able to manually do everything that can also be done internally. Maybe it's an overkill.

The empty case doesn't work for {{User:Chieftain Alex/sandbox5}}, it should display the profession common line. Not gonna claim that my approach is better, defining the supertype at the top looks horrible, but then it's actually quite nice to display the profession and set the categories.

<div class="wrapper">{{#switch: {{#var:supertype}}
 | Profession
 | Profession+Race =
; [[Profession]]
: {{profession|{{{profession}}}}} [[{{ucfirst:{{{profession}}}}}]] <!-- [..] -->
 | Race
 | Common = 
; [[Profession]]
: {{profession|common}} Common
}}<!-- [..]

--Tolkyria (talk) 00:22, 16 January 2020 (UTC)

Turned the "horrible" supertype definition code into hopefully nice looking code. I honestly prefer using #var:supertype (stating exactly what to use when, namely based on the supertype) over using #var:profession (kinda vague, using the profession variable to split between actual profession and common skill was and still is somehow wonky, furthermore it caused so many troubles in the past).

 {{#switch: {{#replace:{{lc:{{{supertype|}}}}}| }}
 | profession      = {{#set: Has skill supertype =Profession }} {{#vardefine:supertype|Profession}}
 | race            = {{#set: Has skill supertype =Race}}        {{#vardefine:supertype|Race}}
 | monster         = {{#set: Has skill supertype =Monster }}    {{#vardefine:supertype|Monster}}
 | common          = {{#set: Has skill supertype =Common }}     {{#vardefine:supertype|Common}}
 | profession,race
 | race,profession = {{#set: Has skill supertype =Profession,Race|+sep=,}} {{#vardefine:supertype|Profession+Race}}
 | <!-- not set -->= <!-- if monster -->
   {{#if: {{{monster|}}}
    | {{#set: Has skill supertype =Monster }} {{#vardefine:supertype|Monster}}
    | <!-- else if profession -->
      {{#switch: {{lc:{{{profession|}}}}}
       | guardian
       | revenant
       | warrior
       | engineer
       | ranger
       | thief
       | elementalist
       | mesmer           <!-- else if race for profession -->
       | necromancer    = {{#if: {{{race|}}} |{{#set: Has skill supertype =Profession,Race|+sep=,}} {{#vardefine:supertype|Profession+Race}}
                          <!-- profession -->|{{#set: Has skill supertype =Profession }}            {{#vardefine:supertype|Profession}} }}
       | common           <!-- else if race for common or empty profession -->                                 
       | <!-- empty --> = {{#if: {{{race|}}} |{{#set: Has skill supertype =Race}}                   {{#vardefine:supertype|Race}}
                          <!-- else common-->|{{#set: Has skill supertype =Common }}                {{#vardefine:supertype|Common}}}}
      }}
   }}
}}

--Tolkyria (talk) 10:51, 16 January 2020 (UTC)

Last one looks pretty nice; I'm happy with anything that works. -Chieftain Alex 16:57, 17 January 2020 (UTC)

Okay, my User:Tolkyria/Sandbox passed all the tests I came up with. Format-wise it's almost the same as yours (except #var:supertype and some additional whitespaces), initially based on your readable infobox-cleanup. --Tolkyria (talk) 19:53, 17 January 2020 (UTC)

Done, see here. Thanks for your help! --Tolkyria (talk) 22:53, 17 January 2020 (UTC)