The next step in building the project is to tell Parity Builder which attributes are categorical, which are numerical, which are affinities, which are labels (to be ignored, other than for purposes of identifying individuals), and how important it is to balance each of the categorical, numerical and affinity attributes across rosters. Click on the Attributes tab and observe that all six attributes are classified as labels, and that the first name attribute has a check mark indicating it is the identification (ID) attribute.
Let us start with the obvious. Click in the type column next to the gender attribute and change it to "category". This activates the case-sensitivity column, where you can tell Parity Builder whether values that differ only in capitalization should be considered distinct. In this case, children are coded either 'M' or 'm' for male and either 'F' or 'f' for female. Whoever entered the data was not consistent about the use of upper versus lower case, so you want to ignore case. Leave the case sensitivity box unchecked. The decimal places column is inactive for category attributes. You can type notes to yourself about how attributes are coded or what they represent in the description column. (Parity Builder ignores anything entered in that column.) So, for instance, you might want to type a brief reminder such as "m = male, f = female". Feel free to leave it blank if you wish. The last thing you have to do in this row is set a priority for balancing teams with respect to gender. This is probably not as important for first and second graders as it would be for older athletes, so enter a relatively low priority (say around 40). As with the team size and team count settings earlier, you can change the priority either by dragging the slider handle (which will become visible once you click in the cell) or by editing the number directly. Parity Builder can be a bit finicky when changing cells in a table. Sometimes clicking outside a cell after a change locks in the change, but sometimes you may need to press the Enter key.
Similarly, the experience attribute ("Exp") is coded 'y' (or 'Y') for experienced and 'n' (or 'N') for inexperienced. Make that attribute categorical and leave it insensitive to case. Balancing teams with respect to the proportion of players having prior experience is fairly important, so assign a relative high priority (for instance, something around 70).
The grade variable is coded 1 for first graders and 2 for second graders. Even though it is coded with numbers, it is really not a numerical attribute: one second grader does not equal two first graders. Make this one categorical as well, and assign a medium priority (something in the vicinity of 50).
Next comes the ranking attribute. Someone (a coach or league official) has assigned each player a skill level of 1, 2 or 3. For this attribute, you can make a case either for it being categorical (as with grade) or numerical (two players with skill level 2 might be comparable to one with skill 1 and one with skill 3). To get some variety in the tutorial, if for no other reason, set the type for this attribute to "number". The case-sensitivity check box is now inactive, and the decimal places column contains '-1'. The decimal places column tells Parity Builder how many decimal places to treat as significant (with '-1' meaning all of them). If, for example, you were to use grade point average (say on a scale of 0 to 4) as a numerical attribute and set the decimal places column to 1, then Parity Builder would round all averages to one decimal place, with the result that it would consider 3.72 and 3.66 to be the same (rounding both to 3.7). On the other hand, if you set decimal places to 2 or more (or left it as -1), Parity Builder would not round 3.72 or 3.66, and would treat them as distinct from each other. In the tutorial project, the ranking attribute is recorded as integers, so no rounding will occur no matter you use for the decimal places setting. Feel free to leave it as -1. Balancing skill levels is quite important, so give it a high priority (for instance, 90).
The final attribute is the child's neighborhood. League officials would prefer to keep the number of different neighborhoods represented on each team low; having a team largely or entirely from one neighborhood might help with both team cohesiveness and scheduling practices. Set the type for this attribute to "affinity" and give it a priority around 60. Affinity attributes are similar to categorical attributes in that they can be made case-sensitive. In this case, we will leave the case-sensitivity box unchecked. As with categorical attributes, the decimal places field is inactive for affinity attributes.
At this point, you are done editing the attributes. It would probably be a good idea to save the file; then proceed to the next step, in which you will clean up any problems with the data.
previous: Input individuals | next: Correct data problems |