Enable condition profile to point to target occupation

[siuc-nate]

From @jkitchensSIUC: Use Cases for Third-Party Recomendations or Requirements for

Advanced standing to earn a credential Preparation to earn a credential Advanced standing for (Learning Opp) course or progam equivalence (don't have to take the course) Advanced standing for (Assessment) assessment equivalence (don't have to take the assessment) Prep

The school (e.g., Vincennes accepts the third party recommentations and indicates what they accept as advanced standing or prep for based on X recommendations:

1. Military Occupation System Ratings
2. Other credentials.
3. Other assessments

The above use case for Vincennes is not necessarily dependent on a third party recommendation or requirement, Vincennes could determine this without a 3rd party.

Example 1: X program (e.g. learning opp or assessment) or credential, accepts x occupations (military or civilian), and/or X credentials, and/or assessments as advanced standing. We did this on our own or we did this at the recommendation of X organizations.

See https://www.cool.navy.mil/usn/

http://purl.org/ctdl/terms/advancedStandingFrom

The user needs to be able to find all credentials, learning opps or assessments that my military occupations (MOS/RATING) is advanced standing for. A MOS rating is a title and a code specific to branches.

Simple - the advance standing is referenced broadly to a credential, learning opp profile or assessment profile, not every single course

Here's an example in the Publisher https://credentialengine.org/publisher/detail/credential/1417

[siuc-nate]

Could this be as simple as adding occupationType to ConditionProfile? Then you could do:

Credential -> advancedStandingFrom -> ConditionProfile (contains "3 credit hours") -> occupationType -> [URI for military E5]

[jeannekitchens]

I documented these use cases for the upcoming meeting with Indiana and SOLID.

1. An organization can, or will, accept, work experience (e.g., military occupations/ratings or could be other occupations), and/or other credentials, and/or other learning opportunities, and/or other assessments as

• advanced standing for http://credreg.net/ctdl/terms/financialAssistance#isAdvancedStandingFor) • or as preparation for (http://credreg.net/ctdl/terms/financialAssistance#isPreparationFor) • or as recommended for (http://credreg.net/ctdl/terms/financialAssistance#isRecommendedFor) • or as required for (http://credreg.net/ctdl/terms/financialAssistance#isRequiredFor)

A Credential, Learning Opportunity or Assessment. For the Vincennes examples, they’re the org accepting the work experience (i.e. Military Ratings). Are they accepting it as advanced standing? If so, entries belong under Connections. However, we need to add properties to enable the references to work experience, e.g., military occupation title, Military occupation code, in addition to the connections already enabled.

This is documented here https://github.com/CredentialEngine/vocabularies/issues/512. We’ll work on it now and set a date for an update.

2. A third-party (e.g., ACE or Indiana Board of Higher Education) makes recommendations for or requirements for credentials, learning opportunities or assessments to accept work experience (e.g., military occupations/ratings or could be other occupations), and/or other credentials, and/or other learning opportunities, and/or other assessments as

• advanced standing for http://credreg.net/ctdl/terms/financialAssistance#isAdvancedStandingFor) • or as preparation for (http://credreg.net/ctdl/terms/financialAssistance#isPreparationFor) • or as recommended for (http://credreg.net/ctdl/terms/financialAssistance#isRecommendedFor) • or as required for (http://credreg.net/ctdl/terms/financialAssistance#isRequiredFor)

If the third party issues credentials that may have learning opps and/or assessments they offer for advanced standing for, prep for, recommended for, or required for, they can self-identify these connections in the registry.

If the third party only serves the role as a recommender or requirer, the only role for this is a Quality Assurance Org, at this time, they would publish their information as a QA org and describe their services.

3. We’re also looking at third-party mapping that will provide the means to relate the assertions by the first and third parties. See the details and modeling here https://github.com/CredentialEngine/vocabularies/issues/498

Thanks so much, Jeanne

[jeannekitchens]

Use cases:

• “Vincennes (as the credentialing org) accepts x military occupations/ratings as advanced standing for X credential as recommended by X and X and X. The military occupation, and or X, and or X, may equate up to X credit hour value for x credit hour type or x credit unit value for x credit unit type.”

• “Vincennes (as the credentialing org) accepts x military occupations/ratings as advanced standing for X learning opportunity as recommended by X and X and X. The military occupation, and or X, and or X, may equate up to X credit hour value for x credit hour type or x credit unit value for x credit unit type.”

• “Vincennes (as the credentialing org) accepts x military occupations/ratings as advanced standing for X assessment as recommended by X and X and X. The military occupation, and or X, and or X, may equate up to X credit hour value for x credit hour type or x credit unit value for x credit unit type.”

[stuartasutton]

I'll be looking at this more this afternoon, I don't think a full solution is as simple as adding an occupationType to ConditionProfile because when we say "x military occupations/ratings", it is the confluence of two data points:

1. designation of occupation (called different things in different branches); and
2. rank (pay grade) (e.g., E6).

In a mapping the designation of occupation could have different credits allowed for the same occupation at different ranks.

Still digging...

See "occupation Codes" by branch:

http://www.military1.com/navy-enlistment/318808-navy-ratings/ http://www.military1.com/air-force-enlistment/318824-air-force-specialty-codes/ http://www.military1.com/all/article/318809-marine-corps-mos-codes/ https://www.military1.com/army-enlistment/318806-army-mos-codes/

[siuc-nate]

I think you could cover those data points via a concept scheme (or set of schemes) that reflects them. Since the property already exists and is intended to point at concept schemes (or frameworks, depending on who you ask) of career designations like SOC and ESCO, it seems like a good fit.

Regarding the codes you listed, I think we don't want to confuse MOS codes (the job you do) with ranks or with pay grades. Having said that, you could probably point to all three of those using the occupationType property.

For example:

{
  "@type": "ceterms:Credential",
  "ceterms:ownedBy": [
    "http://uri-for-vincennes-university"
  ]
  "ceterms:advancedStandingFrom": [
    {
      "@type": "ceterms:ConditionProfile",
      "cterms:creditHourValue": 3,
      "ceterms:occupationType": [
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "MOS Codes",
          "ceterms:framework": "http://....",
          "ceterms:targetNodeName": "Infantryman",
          "ceterms:codedNotation": "11B"
          "ceterms:targetNode": "http://...."
        },
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Army Rank",
          "ceterms:framework": "http://....",
          "ceterms:targetNodeName": "Private First Class",
          "ceterms:codedNotation": "PFC"
          "ceterms:targetNode": "http://...."
        },
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Uniformed Services Pay Grades",
          "ceterms:framework": "http://....",
          "ceterms:targetNodeName": "E-3",
          "ceterms:codedNotation": "E-3"
          "ceterms:targetNode": "http://...."
        },
      ],
      "ceterms:assertedBy": [
        "http://uri-for-asserting-organization"
      ]
    }
  ]
}

My argument for including pay grades here, aside from the simplicity of it (hopefully), would be that pay grades are still an indicator of the type of occupation you have (something in the US uniformed services at a certain grade of pay). The fact that it also happens to be called "pay grade" and tied to the money you receive is secondary to its use here as an indicator of your occupation. Of course it's also possible that I've got it all wrong because I'm not very familiar with the subject.

From what I can see, the relationships between job title, rank, pay grade, and what terms are used in which branch(es) of the military are quite complex and I think we should consult with someone from that world (perhaps our Indiana/military contacts?) to get a clearer understanding of them (preferably with some kind of charts and/or graphs) before we go trying to schematize things we don't really "get".

[stuartasutton]

OK, but all I was intending to say is that it's not a single node in an occupation vocabulary, but a confluence...here you have nodes from 3 vocabularies.

[siuc-nate]

Correct, but perhaps I misread your previous comment as meaning that we would need more properties as opposed to more concepts/schemes.

[siuc-nate]

I expanded the example in my earlier comment to cover the use cases @jkitchensSIUC outlined more closely in terms of who is providing what information.

[stuartasutton]

Nate, I may be missing something, but the array of 3 values of the occupationType property in your example are related (Infantryman, Private First Class, E-3). What if I have an occupationType array made of 2 or more sets of such related concepts?

[siuc-nate]

The simplest way to handle that, I think, would be to add another condition profile - you would need to do so anyway if, for example, the number of credit hours was different between two sets of concepts.

For example (leaving out the URI properties in the alignment objects for brevity):

{
  "@type": "ceterms:Credential",
  "ceterms:ownedBy": [
    "http://uri-for-vincennes-university"
  ]
  "ceterms:advancedStandingFrom": [
    {
      "@type": "ceterms:ConditionProfile",
      "cterms:creditHourValue": 3,
      "ceterms:occupationType": [
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "MOS Codes",
          "ceterms:targetNodeName": "Infantryman",
          "ceterms:codedNotation": "11B"
        },
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Army Rank",
          "ceterms:targetNodeName": "Private First Class",
          "ceterms:codedNotation": "PFC"
        },
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Uniformed Services Pay Grades",
          "ceterms:targetNodeName": "E-3",
          "ceterms:codedNotation": "E-3"
        },
      ],
      "ceterms:assertedBy": [
        "http://uri-for-asserting-organization"
      ]
    },
    {
      "@type": "ceterms:ConditionProfile",
      "cterms:creditHourValue": 4,
      "ceterms:occupationType": [
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "MOS Codes",
          "ceterms:targetNodeName": "Combat Engineer",
          "ceterms:codedNotation": "21B"
        },
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Army Rank",
          "ceterms:targetNodeName": "Corporal",
          "ceterms:codedNotation": "CPL"
        },
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Uniformed Services Pay Grades",
          "ceterms:targetNodeName": "E-4",
          "ceterms:codedNotation": "E-4"
        },
      ],
      "ceterms:assertedBy": [
        "http://uri-for-asserting-organization"
      ]
    }
  ]
}

[stuartasutton]

Thank you!

[siuc-nate]

I'm not quite sure what I did that was worthy of being thanked, but, you're welcome, I suppose.

Thinking on it a bit more, I do see a potential point of confusion in that we haven't really defined (perhaps for the best) whether multiple values for a single property should be considered in aggregate or if satisfying any one of them will meet the parent condition profile.

In other words, do you only have to be an E-1 to get the 3 credit hours or do you have to also be a US army private first class infantryman? Would that same logic hold in a completely different scenario (let's say the occupationType field lists "crane operator", "fireman", and "pastry chef")?

Am I correct in guessing that this is what you were getting at earlier? I hadn't thought about it in that way until just now.

I think a potential solution would be to come up with, as I think you suggested earlier, a concept scheme that combines that information into specific URIs that cover the possible combinations - and to correctly construct (or find, if it already exists) such a concept scheme (or framework), I go back to my previous suggestion that we speak with someone who knows their way around that kind of information.

[siuc-nate]

To revise an earlier example:

{
  "@type": "ceterms:Credential",
  "ceterms:ownedBy": [
    "http://uri-for-vincennes-university"
  ]
  "ceterms:advancedStandingFrom": [
    {
      "@type": "ceterms:ConditionProfile",
      "cterms:creditHourValue": 3,
      "ceterms:occupationType": [
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Uniformed Services Roles",
          "ceterms:targetNodeName": "E-3 US Army PFC Infantryman",
          "ceterms:codedNotation": "E-3/ARMY/PFC/11B",
          "ceterms:targetNode": "http://uniformedservicesvocabulary.source/E-3/ARMY/PFC/11B"
        }
      ],
      "ceterms:assertedBy": [
        "http://uri-for-asserting-organization"
      ]
    },
    {
      "@type": "ceterms:ConditionProfile",
      "cterms:creditHourValue": 4,
      "ceterms:occupationType": [
        {
          "@type": "ceterms:CredentialAlignmentObject",
          "ceterms:frameworkNodeName": "US Uniformed Services Roles",
          "ceterms:targetNodeName": "E-4 US Army CPL Combat Engineer",
          "ceterms:codedNotation": "E-4/ARMY/CPL/21B",
          "ceterms:targetNode": "http://uniformedservicesvocabulary.source/E-4/ARMY/CPL/21B"
        }
      ],
      "ceterms:assertedBy": [
        "http://uri-for-asserting-organization"
      ]
    }
  ]
}

I could see an encoding scheme with semantically-interpretable URIs with the format of: [Pay Grade]/[Branch]/[Rank]/[Job] Since pay grades are, from what I can tell, universal across the uniformed services (and used as a means of determining seniority between members of different branches), they come first. Then the branch, as it seems like the next logical grouping, then rank, then role. I suppose it isn't really important since this is just an example and those URIs could just as easily contain GUIDs instead, but the point is that I do believe it's possible to encode that combination of 4 factors into a single (if quite large - but then so is NAICS, SOC, etc.) concept scheme.

@stuartasutton would something like that solve the problem?

[stuartasutton]

Nate, the AlignmentMap is designed to do this sort of mapping. Such mapping data is not something that you'd embed in the credential description itself. We can think of these maps as overlays on the credentials. Machine actionable schemas for MOS codes, ranks, service pay grades (or a faceted aggregation thereof) is not something that 'we' should do. But a mapping statement could include such data as either literals or as things (should the armed forces get around to formally defining them as concept schemes).

[siuc-nate]

Creation of these alignment maps requires a tool. CASS has a tool that seems to fit the bill - we need to investigate whether this can be adapted for our needs.