I think you'd have to base the sub-summary report in a layout based on the Survey Responses table. But in order for the TQ data to show correctly, I think the relationship should be a one-to-many from TQ to Survey Responses. You could fix that by adding a unique key to TQ and use that instead of QuestionID, or add the TraitID to Survey Responses and add it to the relationship.
i think i understand why you are suggesting to create a one-to-many relation between TQ and survey responses. but frankly, i can not see either suggestion to implement that working correctly.
i think the way to make it happen is to create a calculation table that stores the base calculations for each person surveyed based on a culmination of both the traits, the weights within, and the responses from the surveys. a script can be written that is run and populates this calc table every time the layout is entered. unless someone comes up with a relation way of doing it, this script to table method is the only way i see it working correctly.
have a subsummary part for each person in the survey, and under that, another subsummary part to show each of the 5 traits
I agree with Ender. The way you have it, each response "knows" which question was answered - but not which one of the question's traits. So it's not possible to summarize the responses by trait.