[DDI-users] Solving the issue of "Other - please specify"

Samuel Spencer theodore.therone at gmail.com
Wed Jan 25 19:29:12 EST 2012


Hi Wendy,

With regards to the second email: this solution is meant to be a reusable
attempt at solving this issue in DDI3.1 exclusively. If the standard
changes this approach may also have to change as well, or be wholly
unnecessary.

It also very much depends on what problem you are trying to solve. For me
the issue is how can one document the structure and semantic logic of a
form in a succinct way, keeping as much of that information in the DDI.

With this in mind, if you take the
QuestionItem/StructureMixedResponseDomain approach to documenting these
kinds of questions, the logic about when one can fill in the "Other please
specify" text field has legitimate storage location within 'pure' DDI
(although a not could be attached - however, I try to limit this approach
when ever possible).

The MultiQuestion approach means that the Coded response and free text
response can be linked together in a meaningful way, and have some
presenational/semantic logic applied at the point within the metadata -
along with the intent of this logic. This means that if there were multiple
tools for presenting DDI forms, be they web, paper or other, if I grabs DDI
from another agency who used a different tool to me, I could read the
intent of the logic within their metadata surrounding the 'other please
specify' question, and at most have to attach a new expression for my tool
within the SubQuestionSequencing.

While the reality of the situation is that there are few publicly available
DDI to web form tools or metadata-driven paper form creation/scanner
systems people are probably working in this space. And a common way that
both support automated design and is relatively sound DDI in principle will
help ensure that as people begin announcing more tool that they will be as
compatible as possible with each other.

However, as you said the changes to MultiQuestions in DDI3.2 will be vast
and by the looks of it quite an improvement, and may render such approaches
obsolete in the future making this a stop gap to support an immediate need,
rather than an ongoing best practice.

Cheers,
Sam.

--- Specificity is the soul of all good communication ---
--- When the game is over, the king and the pawn go into the same box ---
Find out more about me: http://about.me/legostormtroopr


On 26 January 2012 03:33, Wendy Thomas <wlt at umn.edu> wrote:

> Actually Sam the normal way is to use a single question and
> StructuredMixedResponse
>
> Field Level:
> ResponseDomains should be chosen that do NOT duplicate responses such
> as CodeSchemes with overlapping codes. Be aware that certain
> instruments may collect responses in such a way that confusion between
> a code response and text response may be possible. The process of
> resolving such conflicts should be addressed in the data processing
> instructions. There is an assumption that if a text or numeric
> response duplicates a coded response to a question, that the value is
> that of the coded category.
>
> See page 42 of DDI 3.1 Part II: User Guide
>
> At least that how it was designed to work.
>
> Wendy
>
> On Sun, Jan 22, 2012 at 6:07 AM, Samuel Spencer
> <theodore.therone at gmail.com> wrote:
> > Hi all,
> >
> > I had a bit of a brainwave late in the weekend looking at how to work
> with
> > the idea of complex questions in DDI.
> > The issue at hand is how to solve questions where a respondent either
> picks
> > from a list of codes or enters their own option. For an example see this
> > image from the ONS 2001 Census here: http://i.imgur.com/9xpvP.png
> >
> > The normal approach is to use a MultipleQuestionItem, but there have been
> > issues about how to deal with the logic about what two answer when. I
> > believe a suitable approach that keeps the questions together, and
> supports
> > the logic is through the use of a SubQuestionSequence within the
> > MultipleQuestionItem.
> >
> > Rationale and a larger example are available here: http://bit.ly/yEPcZ5
> > A more comprehensive example will be put into the DDI Examples Repository
> > later this week, pending critique of the suggested approach.
> >
> > Cheers,
> > Sam.
> >
> > --- Specificity is the soul of all good communication ---
> > --- When the game is over, the king and the pawn go into the same box ---
> > Find out more about me: http://about.me/legostormtroopr
> >
> > _______________________________________________
> > DDI-users mailing list
> > DDI-users at icpsr.umich.edu
> > http://lists.icpsr.umich.edu/mailman/listinfo/ddi-users
> >
>
>
>
> --
> Wendy L. Thomas                              Phone: +1 612.624.4389
> Data Access Core Director                 Fax:   +1 612.626.8375
> Minnesota Population Center             Email: wlt at umn.edu
> University of Minnesota
> 50 Willey Hall
> 225 19th Avenue South
> Minneapolis, MN 55455
>
> _______________________________________________
> DDI-users mailing list
> DDI-users at icpsr.umich.edu
> http://lists.icpsr.umich.edu/mailman/listinfo/ddi-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.icpsr.umich.edu/pipermail/ddi-users/attachments/20120126/dd1cf7b1/attachment.html 


More information about the DDI-users mailing list