For discussion: fieldOfStudy as array vs string

[kayaelle]

I was asked how multiple majors may be represented in a degree credential. Right now achievement.fieldOfStudy is a string. Could we consider changing to an array so that multiple majors could be represented by one open badge?

Also (and possibly a separate issue), how do we represent majors and minors in a degree?

In the short term, a long sentence could be used but that may not be as useful or display as succinctly if in distinct metadata properties.

Field of study could be an optional array of objects something like:

id: type: fieldOfStudy focus: primary name: computer science

id: type: fieldOfStudy focus: primary name: graphic arts

id: type: fieldOfStudy focus: secondary name: history

[andyfmiller]

The American Association of Collegiate Registrars and Admissions Officers published Alternative Credentials: Considerations, Guidance, and Best Practices in 2022. I think it covers representing multiple majors. I remember that use case was discussed quite a bit.

I hope that helps.

[kayaelle]

Hi @andyfmiller - circling back. Thanks for your comment. I don't see anything in the AACRAO doc that discusses how to represent multiple majors in a degree. Woudl you mind highlighting what you are referring to?

As the standard is now, an institution would need to issue multiple OBv3s for each major. Is that the recommendation? Or would it be better to insert the multiple majors in one field? Thanks!

[kayaelle]

One other thought - how would we signify major, minor, specialization, emphasis of study if more than one of these is true? For instance if I major in art and minor in environmental science, what's the recommendation? It's one conferred degree.... Thanks!

[robcoyle913]

Hi All, I asked Mark McConnhay to weigh in:

Kerrie/all -

The way we (AACRAO Committee) modeled this (if I understand your question correctly) is to make majors/minors an achievement that were children of the degree program (once awarded) or the academic objective (if still being pursued). Since there can be multiple associations, this enables courses to be grouped according to what they support - in addition to supporting the degree program in its entirety. For a diagram, take a look here: ims-global-clr-implementation-guide-(12-2-2022).pdf (aacrao.org) on page 44.

There are other ways of doing this as well: A "Major" achievement could be defined and each major spelled out in Results. Likewise for Minors. I prefer the former - but the nimbleness of the standard can lead to interpretation issues for those trying to ingest the data (must they build If-then-else type code to cover how the issuer is rendering the primary elements of the CLR???)

-Mark

Mark McConahay AACRAO Sr. Consultant and Innovative Credential Coordinator

[kayaelle]

Hi @robcoyle913 & Mark - thanks for the insight about the CLR. We would like to issue degrees as open badges (versus CLR) and indicate in a simple single achievement model what the major(s), minors, etc. are. The simplest approach would be to extend fieldOfStudy to be an array. DCC could recommend inserting other vocabularies like schema.org (can explore CTDL) in place of fieldOfStudy. DCC isn't issuing CLRs at this stage but our members are issuing degrees as VCs and potentially open badges.

[kayaelle]

Adding a few more thoughts here to fuel the discussion. Keeping in mind that the objective of this challenge is to issue a degree as an Open Badge. The DCC is working on recommendations for issuing degrees. Prior to 3.0, I don't think there was a property called fieldOfStudy. It would make sense that the CLR would have this property and apply it in the way @andyfmiller and Mark mention above.

Open Badges wasn't used to issue degrees prior to 3.0 -- well actually in the very early days there was a company that issued signed open badges as degrees -- but for the most part, Open Badges were hosted. The DCC thinks that Open Badges 3.0 is one of the standards that could be used for degrees but fieldOfStudy as a string doesn't really accommodate multiple majors, minors, and concentrations clearly. We'd like to offer some options to our members fueled by this group discussion.

Here are some thoughts to aid the discussion:

1. List all fieldOfStudies as a comma delimited string in the fieldOfStudy property

2. fieldOfStudy could be changed to be an array of objects but it sounds like this won't fit how CLR implements multiple fields of study and OBv3 is final for now.

3. Could create an extension(s) for majors, minors, etc.

4. Could issue a separate Open Badge for each major, minor, etc.

5. Could use Credential Engine's: ceterms:degreeMajor, ceterms:degreeMinor and ceterms:degreeConcentration which right now use an alignmentObject for values

From the DCC perspective, this discussion is exploratory and any or all of the above and other thoughts not listed here could be useful. Curious to hear your thoughts on the above options, about use cases, etc. Thanks!

[ottonomy]

@kayaelle great specific issue to consider. This could be explored in 3.0 and I bet we can get to a great solution in 3.1 at least and in the meantime get a pretty good solution implemented with 3.0.

Issuing as an OpenBadgeCredential, I'd probably recommend creating a belt-and-suspenders approach that emphasizes maximum display support for humans by using built-in properties with something closer to the exact data you want as an extension.

For example, use narrative to describe in prose what the major(s) and minor(s) were. List all concentrations as comma-separated in fieldOfStudy. This field doesn't take IRIs, so it shouldn't likely be treated as an exact match situation.

Then also build an extension to represent the exact data you want as a claim on credentialSubject. I could draft up a quick context and example if you want a little help.

You also mentioned alignment. This would be great and would have good display support, but there are some potential issues related to confusion around to what extent two learners have the "same" achievement. Some people think that the same achievement ID should imply identical content. But I bet this approach would generally work fine, and there isn't any advanced processing business logic built into any real product that would yet grow confused by this, I think.

I won't be on the call today, in transit.

[Vlszbra]

There is a potential use case on the Secondary school level. At IDCTE we use SkillStack(r) with our secondary CTE students to award badges based on the CTE pathways (Health Science, Agriculture, etc.). We do have students that get multiple badges that fall under different pathways. So please consider how this might impact learners in high school / secondary school considerations.

[hdcarle]

I had understood "field of study" to be the subject area of the degree

field of study: Business Administration (reflects focus of the college or department of the college; corresponding to a CIP code area) name: B.S.B.A, Accounting (of achievement is name of the degree that appears in the academic catalog) achievementType: bachelorsDegree

Given that specialization is a string value, might it be sufficient to format the major and minor into the existing field? i.e.: "specialization": "Major: Business, Minor: Marketing",

If an extension for major and minor is added separately for open badges or CLR, more explanatory text in the implementation guide or elsewhere might be needed about how to use the extension together with the "specialization" field which is a formal part of the specification.

Not to muddle the point further... perhaps I have missed it, but I haven't found documentation of where academic honors are to be included with the degree. If we are considering gaps related to other elements of degree conferral, can we address that item as well? Seems like all of this information should be in one place.