Professional > Interview scripting > Writing interview scripts > Keywords for data analysis > Defining analysis requirements > Axis block or analysis elements?
 
Axis block or analysis elements?
Axis blocks and analysis elements are two ways of defining analysis requirements in an interview script. Sometimes the method you use is a matter of personal choice or company standards. At other times you may find that only one method produces exactly the output you require. The following table summarizes the differences between the two methods and the advantages and disadvantages of each.
Analysis elements
Axis blocks
Syntax checked when the script is saved.
Not checked until the block is used in an analysis application.
Text can be translated in the same way as other metadata texts.
Text cannot be translated.
Syntax can be long and complicated.
Simple syntax.
Some analysis requirements not catered for.
All analysis requirements catered for.
Here are a couple of examples that illustrate some of these differences.
The first example sets up a mean and standard deviation for a set of categorical responses. The first version uses an axis block so you know that the top part of the definition is for interviewing only, and the axis block is for analysis only. Notice the line containing the two dots near the start of the axis block. This is a shorthand way of referring to all the categories in the main response list that saves you having to retype or copy and paste the response texts. However, if you want to put the responses in a different order in the tables then you can define them in full in the axis block. Just be sure to keep the category names the same in both sections otherwise the analysis program will not be able to match up the analysis elements with the correct data.
Rating "What is your overall rating for the hotel?" categorical [1..1]
{
Excellent factor(5),
VGood "Very good" factor(4),
Satisfactory factor(3),
Poor factor(2),
VPoor "Very poor" factor(1)
}
axis (
"{
..,
RatingMean 'Mean rating' mean(),
RatingSD 'Std. dev' stddev()
}"
);
Now here’s the same question written using elements with Analysis keywords.
Rating "What is your overall rating for the hotel?" categorical [1..1]
{
Excellent factor(5),
VGood "Very good" factor(4),
Satisfactory factor(3),
Poor factor(2),
VPoor "Very poor" factor(1),
RateMean "Mean rating"
[CalculationType=Mean, HasNoData=True, ExcludedFromSummaries=True]
elementtype(AnalysisMean),
RateSD "Std. dev"
[CalculationType=StdDev, HasNoData=True, ExcludedFromSummaries=True]
elementtype(AnalysisStdDev)
};
In this scenario, there’s not much to choose between the two methods, as they both produce the same output, although there is less typing in the axis block version and you may find it easier to follow. This is not always the case. Here’s an example that illustrates the opposite view. It defines a question that respondents can skip. The question has a base element that reports the number of people who answered the question, and the requirement is that the hidden “No answer” response does not appear in analyses.
' The routing section contains Gender.MustAnswer=False.
' Respondents who click Next without answering are automatically coded as
' GenderNA. This response is not displayed during interviews.
Gender "Are you ...?" categorical[1..1]
{
Male, Female,
GenderNA "No answer" na
}
axis(
"{
..,
GenderNA [IncludeInBase=False, IsHidden=True]
}"
);
In this version, the axis block uses the “..” notation to pick up the responses defined in the main part of the question. The “No answer” category is defined with additional properties that exclude it from the automatic base element and hide it in analyses. Any tables that use Gender as the rows or columns will show Male and Female only. Here’s the Analysis keyword version.
' The routing section contains Gender.MustAnswer=False.
' Respondents who click Next without answering are automatically coded
' as GenderNA. This response is not displayed during interviews.
Gender "Are you ...?" categorical [1..1]
{
GenderBase "Base (all answering)"
elementtype(AnalysisBase) expression("Gender <> {GenderNA}"),
Male, Female,
GenderNA "No answer" na
};
This time we need to define the base ourselves as there is no way to exclude “No answer” from the automatic base. The base element contains an expression that excludes anyone who did not answer the question. However, excluding respondents from the base does not exclude them from the analyses. All responses that appear in the response list automatically become part of the analyses, so although “No answer” is excluded from the base it will still appear in tables. This means that the definition does not suit the analysis requirements. (A way round this is to hide the unwanted element using facilities in the analysis program, but this can be a nuisance if you have to edit a lot of variables.)
A similar thing sometimes happens when you want to vary response texts between interviewing and analysis, perhaps using longer texts in interviewing so that respondents are clear about what each response means. If you use an axis block you can define whatever text variations you want, whereas with Analysis keywords you have to use the same text in both types of output or define different texts in the Analysis context. See Different response texts for interviews and analyses for more information.
Remember, also, that elements defined using Analysis keywords become part of the project’s metadata and are checked when you saved the script in UNICOM Intelligence Professional and when you activate the script. They can also be translated. Anything in an axis block is not checked until you use the question in analyses and cannot be translated.
You can use Analysis elements and an axis block in the same question. If you want to refer to an Analysis element in the axis block, just use its name the same as you do for ordinary responses.
See also
Defining analysis requirements