User talk:Dr ishmael/SMW

Testing regimen

Here's a rough outline of what we'll want the ANet tech team to do to test out SMW and forms.

• Use the Semantic Forms special page Special:CreateClass ([1]) to automatically set up a category, form, and template, with multiple properties that cover the different data types
• Create some articles using the form, edit them with the form
• Run some queries based on that class's properties

Now, given what we know of the game, what would be a good example for them to actually go through? --JonTheMon 18:58, 13 June 2012 (UTC)

Since skills are where I've done the most work so far, I could give them an outline of how to set up the basic properties for a Skills class and work from there. It all depends on how thoroughly they want to test - if they just want a simple systems test to show that the basic functions are working, that's easy; if they want more than that, like to take live wiki templates/pages and insert semantic annotations (the way we'll have to here on GW2W), that would require a lot more work to show them what to do. —Dr Ishmael 01:30, 14 June 2012 (UTC)

Wished i could say something smart about this, but my intelligence lies in different fields i'm afraid. Still want to support all the hard work you're doing, keep up the good work! --Ee 04:42, 14 June 2012 (UTC)

Property names

Do semantic names generally start with is or has? usually you limit those to booleans.--Relyk 18:34, 3 November 2012 (UTC)

The standard methodology is to use verbal phrases for property names. They don't have to start with "is" or "has", those are just common auxiliary verbs that simplify the process of turning a noun or adjective into a verbal. —Dr Ishmael 02:27, 4 November 2012 (UTC)

Another random note

This should actually be trait line right?--Relyk ~ talk > 14:46, 2 January 2013 (UTC)

Also, does #arraymaps allow you to pass multiple properties to query template in a single parameter?--Relyk ~ talk > 15:12, 2 January 2013 (UTC)

1. No, that is identifying the trait line as belonging to a certain profession. 2. I'm not sure what you're asking. —Dr Ishmael 15:33, 2 January 2013 (UTC)

1. Ahhh Is for profession will be a generic property, we would use categories to grab all the skills for a profession like you would with dpl. I was trying to query skills with the property, but that's just because the property has only been defined for skills for the most part.

2. Passing properties as parameters to a template like Is for profession::Elementalist and Has combo effect:Blast to User:Relyk/Template:Skill table2, since the syntax will just define the properties on the page instead of pass them as parameters (as strings). My solution was passing two separate parameters.--Relyk ~ talk > 22:21, 6 January 2013 (UTC)

1. To get skills for a profession, you should be able to do [[Category:Skills]][[Is for profession::Elementalist]]. That doesn't work right now because our SMW is configured to ignore subcategories ($smwgQSubcategoryDepth = 0), which I thought Justin was going to fix immediately after we discovered that, but apparently he never did.

2. Oh, you're talking about templating a query and parameterizing the query conditions. There are a number of ways you could do that, and it looks like you tried most of them. A) Pass the full set of conditions as a parameter. B) Hard-code the query to a single condition, but pass the property name and search value. C) Hard-code the query to a set of specific properties, and pass the search values for each. The method picked would have to depend on the intended usage of the template. —Dr Ishmael 22:35, 6 January 2013 (UTC)

Runes and set_internal

So this is my draft for rune infobox: User:Relyk/rune/template. Not sure if you should/can call set_internal multiple times or all at once. I figure we're going to split runes from the upgrade infobox, like the other specific infoboxes.--Relyk ~ talk > 22:30, 6 January 2013 (UTC)

#set_internal can be called multiple times, but each call creates a separate internal object. The only reason to use #set_internal is when you have a group of properties that you want to associate together, without letting them get mixed up with other properties on the page. If you're planning on keeping the minor/major/superior tiers on the same page, then you would use 1 internal object per tier, in order to associate all the bonuses of that tier together. If you're going to split them into individual pages (I think that's where you and Alex are heading with this), then there's no need for internal objects. (Not to mention, Semantic Internal Objects hasn't been installed yet anyway.)

Instead of Has version, which is an extremely generic property name, I would call it Has rune tier. That would obviously mean you'd have to also have Has sigil tier, instead of using the same for both, unless you can think of something better. —Dr Ishmael 22:49, 6 January 2013 (UTC)

Alex is way too behind on understanding any of this not-quite-fully-installed smw, not being able to test it means I won't pick it up for ages.. so far its all colons, set, has... headache. Chieftain Alex 22:54, 6 January 2013 (UTC)

I see, it wouldn't be used that way. But if we have a "Property:Has rune stats" that just uses #arraymaps to pass in the 2, 4, or 6 variables, we need to associate each bonus with the level, hence an internal object for each bonus. Otherwise we have a collection of bonus values that just happen to be sorted due to be defined in order by the template. We can't pick a specific bonus from rune stats.

Or I'm just using the wrong implementation, but ability to query for a the bonus for a specific rune stat level--Relyk ~ talk > 22:15, 10 January 2013 (UTC)

Derrrr... Yeah, you could use an IO for that. Or a subobject. Or a record property. Or a separate property for each of the 6 levels. The biggest factor in this choice is how you envision the data being accessed, since each of those options has its own quirks in that regard. —Dr Ishmael 22:41, 10 January 2013 (UTC)

Since we will always list the rune stats in order (since they stack) using a Record would be the best idea. The other ones seem to let them be accessed in any order, but we will only be grabbing either 2, 4, or 6 rune stats from any Record at a time. It doesn't seem like an IO is needed for making any specific queries (aka simplify the syntax). But I'm not confident at all in saying any of that...--Relyk ~ talk > 03:57, 11 January 2013 (UTC)

Hmm, that wasn't the way I was thinking of using records. I was thinking the record would be (number; string) = (bonus level; bonus text), 2/4/6 records per rune; you're thinking of it as (string; string; [string; string; [string; string]]) = (bonus 1; bonus 2; [bonus 3; bonus 4; [bonus 5; bonus 6]]) and 1 record per rune. You're right about that always returning the bonuses in a reliable order, but it makes querying the bonuses difficult. If you want to see all runes that provide bonuses to e.g. Power, you'd have to do something like [[Has rune bonus::~*power*;;;;;||;~*power*;;;;||;;~*power*;;;||;;;~*power*;;||;;;;~*power*;||;;;;;~*power*]] in order to find all results where "power" is in any of the 6 fields. (Unless there are guaranteed systematics where e.g. primary attributes are never boosted by bonus 6.)

OTOH, using a distinct record per bonus (as I described above) or a distinct internal/subobject per bonus (where the object has 2 internal properties, Has rune bonus level and Has rune bonus) makes the querying easier, since you only have to search within 1 field of the record or 1 property of the object. —Dr Ishmael 05:05, 11 January 2013 (UTC)

I was only suggesting records to display rune properties in lists, which is simple with records. Of course to make specific queries, we'd want to implement an internal object for holding the the level and bonus (like I was talking about early on). The implementation I want for it is so that you can:

{{#ask:[[Has rune bonus::+]]
|?Has rune stat 1
|?Has rune stat 2
|?Has rune stat 3
|?Has rune stat 4
|?Has rune stat 5
|?Has rune stat 6
|format=template
|template=<table formatting>
}}

The simple way is to create individual objects for each stat, but queries will always be asking any of the rune stats that have a certain property and you gain all previous rune stat properties up to the property you ask for. As far as querying for individual stats, most individual stats are either unique or they follow the even/odd bonus pattern. Making queries to individual rune stats rather than a Rune stats property seems ugly.--Relyk ~ talk > 02:49, 14 January 2013 (UTC)

I think you've finally found a situation where subproperties would be ideal, and you didn't even realize it. :P Create properties Has rune bonus 1...6 as subproperties of Has rune bonus. Then you can query all bonuses for all runes on Has rune bonus, then display them individually with the subproperties. —Dr Ishmael 03:54, 14 January 2013 (UTC)

Resizing icons

Your talk page is busy. Will we eventually upload 25x25 skill icons and similar and set a Has wiki icon property? Using formatting templates to dispaly the icons correctly tends to remove the advantage of SMW generating sortable tables. It also makes the nifty code in the skill icon template redundant.--Relyk ~ talk > 07:50, 16 January 2013 (UTC)

I don't see a problem with using {{skill icon}}, take a look at what I did to your skill table 3. It seems to be sorting the skill column just fine. —Dr Ishmael 16:29, 16 January 2013 (UTC)

Forgot you'd use the class to make it sortable instead of SMW doing it automatically with the table format.--Relyk ~ talk > 21:33, 16 January 2013 (UTC)

Right, since it's not using the table format, you're making the table yourself, you can't rely on SMW to set the class. ;) —Dr Ishmael 00:15, 17 January 2013 (UTC)

Is for profession/race

We can put the races as Is for profession instead of trying to give a fancy name, it won't cause any confusion. The distinction will be made in the query, as soon as we have subcategory depth for Category:Racial skills. There wouldn't be many queries using the property either.--Relyk ~ talk > 16:45, 24 January 2013 (UTC)

Eh, semantically it would cause confusion, because races are not professions. [[Is for profession::Asura]] would be inaccurate. —Dr Ishmael 20:04, 24 January 2013 (UTC)

I forget it's a general property for articles, we will be using it for queries on NPCs and others as well as skills.--Relyk ~ talk > 20:36, 24 January 2013 (UTC)

Project page

This has moved far enough along that we can move it to a project page. Although having a project that impacts the entire wiki sit in your userspace is cool and all.--Relyk ~ talk > 10:29, 11 February 2013 (UTC)

Yeah, I just haven't bothered to do that yet. —Dr Ishmael 14:18, 11 February 2013 (UTC)