Add Condition Profile to Transfer Value Profile

[jeff-grann]

I'd like to show that a minimum score of 3 is required on a transferValueFrom an AP test to receive 4 credits of transfervalue on a transferValueFor an Ivy Tech course.

This is a very common need for states and institutions, which have particular score thresholds on 3rd party exams.

Here are some example data sets illustrating the need.

State-wide agreements
https://transferin.net/transfer-resources/transfer-databases/ap-courses/
https://transferin.net/transfer-resources/transfer-databases/clep/

Credential Providers
https://admissions.tc.umn.edu/advanced-placement-course-awards
https://www.njit.edu/apib-and-college-transfer-credit

[siuc-nate]

This overlaps somewhat with the need we've had in the past to express that someone must earn a certain grade/certain amount of credit from a set of courses in order to meet some requirement. Those have all been done via pathways.

Condition Profile doesn't currently have a way to capture that kind of information. Any changes we make to accommodate it would need to consider the above use case as well.

CTDL doesn't have a minimumGrade/minimumScore property - the closest we have to that is the Constraint structure we developed for pathways, which is probably overkill for something as common as a minimum required score/grade/percentage/etc.

However, grades are particularly tricky since those tend to be represented as concepts (e.g. A, B, C, D, F) rather than a numeric scale that can have a simple value as its minimum. We got around that in the pathway/Constraint work by basically listing all of the Grades that would pass the threshold rather than trying to figure out a way to numericize them.

I had briefly started sketching up ideas for the "earn x credits from y set of courses" problem - I'll dig that up and see if something there can be adapted to solve this, too.

[siuc-nate]

These are the lines along which I am thinking, currently. I usually end up going through a few iterations on this sort of thing, so this may change:

I included the condition profile stuff there for context, but the relevant portion for this issue is the upper-right part of the diagram.

The main idea is to create a new class (OptionList) and five new properties: hasOptionsList, hasOption, hasOptionFrom, requiredCredit, and awardType. I'm trying to provide enough detail to capture what we need to capture while not completely reinventing the existing Pathway/Component/Constraint structure.

Option List is a generic class meant to make assertions about some list of resources of any type(s). It generally means "complete x options from y list with z requirements". It would probably be a subclass of Collection, the main difference being the inclusion of properties like "requiredNumber" which a Collection wouldn't have. It is roughly comparable to a Multi Component.

Has Option List is just a property to get from Condition Profile to some array of Option Lists.

Has Option is the property an Option List uses to point to all of the things that are valid options for that list. We could probably get away with using "hasMember" instead here.

Has Option From is intended to cover the use case where we want to point to a pre-defined list of things without re-listing them. Basically, "the option list consists of whatever items are in the referenced container", similar to how Collection Component works, but as a property rather than a separate class.

Required Credit is the credit someone must earn in order to pass some threshold. In the context of an Option List, this would be the credit you have to earn from the items in the list.

Award Type (I struggle with coming up with a good name for this one) is a list of things that can be awarded, in this case, grades (embodied as concepts here - maybe grades should be progression levels?). Award type could conceivably be credentials (either specific or general credential types) in some other context/use case, so I tried to keep the name of this property somewhat generic. The purpose of this property is to get around the "grades aren't numeric values" problem by allowing for a list of values that meet the threshold in question. In this context, the list of courses would have a required credit of at least one item from the list of concepts (A, B, or C).

I considered having requiredCredit hang off of Transfer Value Profile directly, but having an intermediate OptionList allows for cases where a complex Transfer Value Profile wants to say "x credits from these courses, y credits from these other courses, and a minimum of z score in this assessment".

Anyway, that's where I'm at currently. I'll update this if I think of something different/better.

[siuc-nate]

A variation of the above that borrows existing Pathway terms (likely as bnodes), but doesn't involve the verbosity/complexity of the Constraints stuff, would look something like this:

[siuc-nate]

See also #848 and #938