Result should contain maxScore

[myclues]

Heya, I think a raw points earned (normalScore, extraCreditScore, totalScore) isn't meaningful without the maxScore associated with the assignment, however maxScore is only available on the attempt, completely decoupled with the result.

I propose Score become its own entity to capture all of these values together, instead of having them be individual top-level properties on Attempt and Result

[arwhyte]

Good idea. We can talk about this on today's call. But note that we need to decide whether or not this is a must have for 1.1 or can be deferred to 1.2.

[arwhyte]

So this (minimally):

{
  "NumericScore": {
    "maxScore": 0.0,
    "normalScore": 0.0,
    "penaltyScore": 0.0,
    "extraCreditScore": 0.0,
    "totalScore": 0.0,
    "curvedTotalScore": 0.0,
    "curveFactor": 0.0
  }
}

A quick fix is simply to add Result.maxScore as you note. Note too that the optional Result.attempt references the Attempt which via Attempt.assignable references the AssignableDigitalResource and the maxScore.

[arwhyte]

@ViktorHaag and I were talking about providing a generic Score entity as you suggest that we could extend with NumericScore for 1.1 and then perhaps other subtypes for 1.2.

[ViktorHaag]

I'd also be in favour of taking what we want to support in our NumericScore object right out of the gradebook services (i.e. "rich outcomes 2") work in LTI (see https://www.imsglobal.org/specs/ltigbv2p0).

Right now, all that's supported in a "score" is "score given" (by tool provider) and "score maximum". (The "score" is the immutable score awarded by the tool provider, which the tool consumer is not supposed to change.)

The "result" (provided by tool consumer upon request) is the mutable value that's intended to be "how the grade is in the gradebook" and what you have there is "resultScore" and "resultMaximum".

Much simpler than all the extra hoo-hah that's in our score object (which I'm not at all convinced anyone really wants or needs, but could of course be put in as added properties via extension if some vendor really wants to have them there...)

[arwhyte]

@ViktorHaag -- yeah, agreed on that. I recall that all the score hoo-hah was drawn in from LIS. Alignment with Rich Outcomes ought to be considered.

[arwhyte]

Read this for background: https://github.com/IMSGlobal/LTI-spec-Gradebook-Services

LTI GS Score: an entity that records a decimal value and other relevant metadata. Immutable. Minted by a Tool Producer. Stored by the Tool Consumer as part of a Gradebook line item.

LTI GS Result: an object that stores the current grade (literal value) and other relevant metadata. Mutable. Minted and returned by a Tool Consumer at the request of a Tool Provider whenever the latter queries the Tool Consumer for the current results of one of the Tool Provider's own line items.

For a given line item, the Score and the Result represent two views of the same resource.

Arguably, if we added Result.maxScore we'd be close to mirroring an LTI Grading Service Result. But that's not the real issue in my view.

The issue is one of misalignment as regards terms. A Caliper Result is the equivalent of a Grading Service Score. Both are objects generated by a producer (Caliper) or a provider (LTI). A GS Result on the other hand is an object minted by a consumer (LTI) and returned to a provider whenever the latter queries the consumer for the current results of one of its own line items. An endpoint if you will.

If we think it important to align with the LTI Grading Service then we should consider adding a Caliper Score entity modeled, in part, on the GS Score. We'd then modify the Grading Profile swapping in Score for Result as the generated value of the interaction.

As for Result we'd either deprecate it or leave it as part of the model but deprecate all it's current score related properties in favor of maxResult (literal) and resultGiven (literal).

Otherwise, we consider the original request (add Result.maxScore) and punt the term misalignment issue to 1.2.

[ViktorHaag]

I'd prefer to be out in front of the alignment issue, especially if we're expecting our action after 1.1 is "to leave this for time to soak amongst vendors", because that will carry a real risk of growing inertia over things we know we need/want to fix, and increase resistance to them being fixed.

[arwhyte]

Resolved by #204 and #207.