Align a Badge to an External Framework, Competency, or Value

[ottonomy]

Requirement: Issuers can indicate what Competencies, Skills, or Standards are targeted by a BadgeClass, by identifying alignment information. Consumers can understand these alignment targets by comparing and indexing defined attributes.

Motivation: Issuers, recipients, and consumers should understand how learning experiences and credentials fit together, even when they arise from a variety of educational programs and badge issuers. Alignment to standards and Competencies that are understood in a community is an important to way to understand how badges relate to the educational environment.

User Stories:

1. As an issuer of badges aligned to a set of educational standards, I want to indicate the specific standard to which each of my BadgeClasses aligns so that earners and consumers can understand how badges may stack and build upon one another.
2. As a consumer of badges related to a specific Competency, I want to determine if two different BadgeClasses align to the same Competency so that I can understand how badges may stack and build upon one another.
3. As an issuer of badges, I want to indicate that a single Assertion aligns to an element of an external framework (e.g. a Playlist or a Learning Pathway).

Complications:

1. Are there any substantive differences between Competencies, Standards, Dispositions, Skills, etc. that make it adviseable to treat these differently.
2. How do we cleanly operate in a world where many of the things we wish to align badges to do not have canonical @ids?
3. Are there important relationships between different types of entities that a BadgeClass may be aligned to that makes it inadvisable to just define how BadgeClasses align to each of these items?

[jgoodell2]

Re: Complications #1 IMHO The standard need not and should not try to classify the thing on the other end of the alignment. Let each competency framework itself provide the context and labels for the statement and how it fits as a level in a hierarchy. (This is a messy business; different frameworks use the labels or the same label in different ways, e.g. "competency" as a more or less granular statement of skills, knowledge, dispositions, practices...or some rolled up summary of KSAs.) It is better to treat the alignment as a resolvable identifier (URL) for any node in any framework and let the meaning be discoverable.

[ottonomy]

Thanks @jgoodell2 for that comment.

A couple specific question on how that might look:

1. Are name and description applicable enough across the competency models you're familiar with to require in a badge?
2. Not all alignment URLs are assumed to have any machine readable content on the other side of the URL. Just like criteria URLs and evidence URLs are currently not assumed to be machine-readable. Should only Competencies that have machine readable JSON-LD endpoints at persistent URLs be eligible for alignment, or should we focus on trying to make sure that issuers who want to align to the same non-machine-readable URLs can provide useful and consistent metadata about those URLs right in the BadgeClass.
3. Not all elements of educational standards have usable URLs that can serve as an alignment identifier. What can serve for uniquely identifying standards in the Common Core or NGSS?
4. Is it appropriate to include the complete linked data representation of a Competency in a BadgeClass, as defined by an external competency framework/vocabulary, like CEDS?

[ottonomy]

Some excellent issues are identified in this document by the Open Badges Network: Open Badge Network - Proposal on Competency Alignment and Directory (Open for comment)

[jgoodell2]

@ottonomy sorry for the slow reply:

1. I think "description" might be repurposed as a "statement" in a competency framework, but it is a stretch. (The Open Badges Network proposal of adding to schema.org has merit, but should consider the best parts of the comparable models, such as ASN-DL, CEDS, SIF, and the new IMS standard draft, not just inLOC. Various initiatives have advanced the state-of-the-art since 2013 learning from and acknowledging the work of Simon G and the inLOC team. A light-weight best-of-breed approach for any schema additions may be best.)
2. There are some promising initiatives that could make it much more likely that machine readable content on the other side of URLs. (The Wiki based proposal in the Open Badge Network proposal is also an interesting independent approach as long as the format is standardized.) I think a way to "provide useful and consistent metadata about those URLs right in the BadgeClass" would also be good, but not a substitute for the richer content and contextual info that could existing at an endpoint.
3. Your question just scratches the surface of the problem when you consider the variations of CCSS and NGSS uses in various states.
4. IMHO a "complete" representation of competencies metadata and contextual framework info might be too much too pack into the BadgeClass, but maybe the critical elements about the node in the CF embedded using common vocab/definitions (CEDS) and appropriate serialization standard. Then the remaining context could be retrieved as needed, if and when framework data is available as machine readable data resolved from the URL.

[1l2p]

This is best handled by pointing to external specifications (I think that's what @jgoodell2 suggested as well). Seems hard to try to accommodate all possible competency frameworks, especially as those are likely to evolve.

[ottonomy]

We've currently got the following in badges:

{
  "@context": "https://w3id.org/openbadges/v1",
  "alignment": [
    {
      "name": "Big Skill",
      "description": "A big skill, takes many hours to learn",
      "url": "http://standards.net/CCELA-RL-6"
    }
  ]
}

Issues with this:

• For historical reasons v1.1 does not use the proper schema.org vocabulary items for alignment. Additionally, many standards don't have unique URLs for all the items that users might want to align to, so in some cases, a code may be necessary.

What about the following?

{
  "@context": "https://w3id.org/openbadges/v2",
  "alignment": [
    {
      "targetName": "Big Skill",
      "targetDescription": "A big skill, takes many hours to learn",
      "targetUrl": "http://standards.net/CCELA-RL-6",
      "targetCode": "CCSS.ELA-Literacy.RL.6.3"
    }
  ]
}

@1l2p, @jgoodell2: This includes only basic information, not necessarily every complex property of that alignment target, as you suggested would be the right thing to do.

[szerge]

Following the reflection on issue #84, I suggest that the criteria and alignment field could be merged.

{
  "@context": "https://w3id.org/openbadges/v2",

    {
    "criteria": "In order to get that badge, you need to demonstrate
    that you are contributing to the standards working group
    [1](http://www.compedia.org/standards-design/#attending) provide
    comments [2](http://www.compedia.org/standards-design/#commenting),
    and making written suggestions, c.f.
    [3]http://www.compedia.org/standards-design/#suggesting).",
    "alignment": [
        {
            "targetCode": "Standards Design",
            "targetName": "Attending work group meetings",
            "targetUrl": "http://www.compedia.org/standards-design/#attending",
            "targetDescription": "....",
        },
        {
            "targetCode": "Standards Design",
            "targetName": "Providing comments to suggestions made by others",
            "targetUrl": "http://www.compedia.org/standards-design/#commenting",
            "targetDescription": "....",
        },
        {
            "targetCode": "Standards Design",
            "targetName": "Making suggestions to improve the group work",
            "targetUrl": "http://www.compedia.org/standards-design/#suggesting",
            "targetDescription": "....",
        }
    ]
    }
}

[ottonomy]

The CTI vocabulary has a term for "codedNotation" that we could use for "targetCode": http://credreg.net/ctdl#codedNotation

[szerge]

Makes sense ("targetCode"), also "credentialAlignment" and other fields. Although, we have to be careful not to make all badges look like "competency badges," i.e. leave space for affiliation, dream badges and more... Unless we decide that badges are just for credentials :-(

One thing we might want start exploring is application profiles, so we would have different 'profiles' for the different types of badges. For interoperability issues, my understanding is that it is better to have restrictive profiles, subsets of a global spec; but that was a few years ago. Maybe we have better ways for dealing application profiles adding to a reference one.

[dpresant]

Just to complicate things at the last minute... I think alignment should accommodate multiple (incremental) alignments and that the endorsement of badge class should have an alignment dimension.

• As an issuer, I want to be able to specify multiple alignments to maximize the semantic reach of my badge (without becoming a skill spammer)
• As an endorser, I want to be able to align the badge I'm endorsing to a specific framework(s) important to my organization or community, to increase the RPL/re-usability of useful badges that have been issued externally

A lot of this may emerge after the badge is issued, especially for the second use case.

[ottonomy]

@dpresant to make you feel better, the use cases you just clarified were exactly how I am putting this together. No scope change at all. 💯

[dpresant]

Great! This came out of a blog post I'm writing about employability soft skills:

Given all the overlap and the difficulty in getting universal agreement on terminology, I think that for recognition of employability soft skills via Open Badges it makes sense to simply link to individual frameworks as needed or demanded by different audiences, especially badge consumers such as employers, This way, the badges will aligned to their hiring context with a minimum of adjustment on their part ("Don't make me think!"). The technology should be able to accommodate this in version 2 of the Open Badges standard: alignment to skills framework(s), which could be a feature of post-facto third party endorsement.

[mgylling]

Closing this issue, as it was resolved by the 2.0 Recommendation. This issue and all other issues resolved by 2.0 can be found via the 2.0 Release Candidate milestone and PR #99.