Is there a way to place a priori constraints on item difficulty under item response theory?

Question

I have a dataset where the difficulty level of my items and skill of my participants is unknown, but I would like to be able to extract some metric of how individual participants do on the test. What comes to mind initially is to use an item response theory model. However, I have two a priori constraints that makes me question whether IRT will be able to adapt to my peculiar case, or whether there is a better approach to use. As there are two constraints, I will split them into two questions. If these questions are too simple, please refer me to an entry level IRT text which will provide the answers. The first question is this:

I know that the difficulty of my items increases monotonically, by which I mean I know item A is harder than item B, and so on, but I do not know the extent to which item A is harder than item B. Is there a way to construct an item response theory model to adjust the model so that the item difficulty parameters are forced to reflect this?

P.S. I was unable to think of appropriate tags for this question, if you have some suggestions please either make the edits yourself or suggest them in comments.

Answer 1

Off the shelf, the various software offerings from SSI may do what you want.

If I wanted to enforce the constraint, and I didn't have too much data, then I'd switch into a BUGS / JAGS MCMC framework for modelling. I'd use the LSAT example in book 2 of the worked examples (contained in the JAGS distribution or as a separate download from the BUGS people) as the code for standard '3 parameter' IRT model. Then I'd add a line imposing the parameter constraint as described on p.35 of the current JAGS manual. I'd then curl up with a good book, since convergence on such models tends to take ages.

Or I might not bother. Standard errors for such parameters tend to be pretty tiny for a respectable number of subjects, so the ordering constraint may not make any difference to your estimation certainty. And if your parameters end up sitting on top of one another, they're probably trying to tell you your prior is wrong.