Create properties for ETPL

[siuc-nate]

Per our 6-15-2020 meeting:

Create:

URI: ceterms:hasETPLResource Label: Has ETPL Resource Definition: Resource that is on the WIOA Eligible Training Provider List described by this resource. Comment: State or Local Workforce Board indicates the resource being referenced (e.g., credential and its learning opportunity or assessment) is on their Workforce Innovation and Opportunity Act (WIOA) Eligible Training Provider List. Domain: ceterms:QualityAssuranceCredential Range: ceterms:Credential (and subclasses), ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile

URI: ceterms:isETPLResourceOn Label: Is ETPL Resource On Definition: WIOA Eligible Training Provider List on which this resource is listed. Comment: This resource (e.g., credential and its learning opportunity or assessment) is referenced on a State or Local Workforce Board's Workforce Innovation and Opportunity Act (WIOA) Eligible Training Provider List. Domain: ceterms:Credential (and subclasses), ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile Range: ceterms:QualityAssuranceCredential

See #698 for schema:baseSalary

Usage:

Examples:

{
  "@type": "ceterms:QualityAssuranceCredential",
  "ceterms:name": { "en": "New Jersey ETPL 3" },
  "ceterms:description": { "en": "descriptive text" },
  "ceterms:ownedBy": [
    "https://uri-to-newjersey-org"
  ],
  "ceterms:availableAt": [
    {
      "@type": "ceterms:Place",
      "ceterms:name": { "en": "WIOA 3" },
      "ceterms:geoURI": [
        "https://uri-for-county1",
        "https://uri-for-county2",
        "https://uri-for-county3"
      ]
    }
  ],
  "ceterms:occupationType": [
    {
      "@type": "ceterms:CredentialAlignmentObject",
      "ceterms:targetNodeName": { "en": "name of demand occupation" },
      "ceterms:targetNode": "https://uri-for-soc-code"
    }
  ],
  "ceterms:requires": [
    {
      "@type": "ceterms:ConditionProfile",
      "...": "//requirements to be on the ETPL"
    }
  ],
  "ceterms:hasETPLResource": [
    "https://credentialengineregistry.org/resources/ce-...",
    "https://credentialengineregistry.org/resources/ce-...",
    "https://credentialengineregistry.org/resources/ce-...",
    "https://credentialengineregistry.org/resources/ce-...",
    "https://credentialengineregistry.org/resources/ce-...",
    "..."
  ]
}

See issue #645 for more details

[mparsons-ce]

@siuc-nate re: AvailableAt -Physical location where the credential, assessment, or learning opportunity can be pursued. Use of this property for the context of where the QA credential applies, would seem to be confusing based on the definition and how used for other credentials. Wouldn't jurisdiction make more sense? I don't recall if the latter was considered and rejected for some reason.

[siuc-nate]

The key here is that QA credentials are issued to things other than people.

In this case, the QA credential is to be issued to the other credentials/assessments/learning opportunities that are part of the ETPL. As such, it would be interpreted as "this QA credential is ceterms:availableAt [place] to be pursued by your credential" - so if your credential is also ceterms:availableAt [place], it might be a good fit. But that assertion is kind of loose and is probably more useful to those looking to submit their credentials for approval to such an ETPL.

More tightly, the QA credential can (as you suggest) ceterms:requires a ceterms:jurisdiction that precisely covers the area where the credential hoping to "earn" that QA credential must operate (in other words, "this QA credential requires that your credential have a jurisdiction of [place]").

This is something that can, with adequate data, be programmatically compared against the other credential's jurisdiction/availableAt to see if the QA credential's required jurisdiction falls inside of (or is congruent with) the other credential's ceterms:Place (in other words, if the other credential applies to the whole state and that state contains the counties that make up the ETPL's LWIA, it would qualify).

[jeannekitchens]

@siuc-nate @stuartasutton schema/estimatedsalary is not the right term to use for a person's salary. See the Schema.org defintion here https://schema.org/estimatedSalary.

Use schema/baseSalary

See the JDX Schema @siuc-nate this was designed by @stuartasutton https://www.uschamberfoundation.org/sites/default/files/U.S.%20Chamber%20Foundation_JDXJobSchema%2B_ForPublicComment.pdf

See Shema.org Base Salary https://schema.org/baseSalary.

@siuc-nate please update all related domain models and add to definitions proposal.

[stuartasutton]

Using schema.org/baseSalary is fine. If we need anything from JDX, that PDF is not the place to go. I've attached a zip with the last state of JDX in HTML pages generated by me.

Stuart

On Thu, Jun 25, 2020 at 5:49 AM Jeanne Kitchens notifications@github.com wrote:

@siuc-nate https://github.com/siuc-nate @stuartasutton https://github.com/stuartasutton schema/estimatedsalary is not the right term to use for a person's salary. See the Schema.org defintion here https://schema.org/estimatedSalary.

Use schema/baseSalary

See the JDX Schema @siuc-nate https://github.com/siuc-nate this was designed by @stuartasutton https://github.com/stuartasutton https://www.uschamberfoundation.org/sites/default/files/U.S.%20Chamber%20Foundation_JDXJobSchema%2B_ForPublicComment.pdf

See Shema.org Base Salary https://schema.org/baseSalary.

@siuc-nate https://github.com/siuc-nate please update all related domain models and add to definitions proposal.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/Schema-Development/issues/696#issuecomment-649519926, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWNRJSDKQITXNZLL5ZKRKLRYNBWDANCNFSM4N6J4CHQ .

[mparsons-ce]

Will we have any constraints on which credentials baseSalary can be referenced (e.g. apprenticeships) or allow for all credentials? moved to #698

[mparsons-ce]

MonetaryAmount has the property UnitText. In the CTDL context, the latter has the conceptScheme CreditUnit which relates to Degree credit etc. Will UnitText in the Monetary amount context be a different concept scheme, or just text. If the latter, should it be a lang string? Especially if it will be used to indicate per hour, per years, etc. moved to #698

[siuc-nate]

I created #698 to handle figuring out what to do with schema:baseSalary and its range, so that this issue can stay focused on the two ETPL properties.

[siuc-nate]

Per our 6-29-2020 meeting:

We need to find out whether or not partners will expect a "training program type" using the following terms, and how/where these might already be embodied in CTDL:

• Basic Skills/Remedial - Core academic skills such as literacy and numeracy, including English as a second language
• Registered Apprenticeship - A combination of paid on-the-job training and related instruction
• Vocational - Training for employment specific to an occupation or career pathway

References: http://illinoisworknet.com/Training/Pages/WIOATrainingProgramSearch.aspx https://apps.il-work-net.com/WIOAPolicy/Policy/Index/58

[siuc-nate]

Note: In some of our meetings some time ago we worked on the idea of a ceterms:ETPLResource class to carry information specific to a given credential with regard to when it was added to (and when it will expire from) a given ETPL: https://drive.google.com/file/d/1aLmnRbaxblvJhQqYQlJq8pYGgAcqH6MP/view

[siuc-nate]

Adding this to the next milestone so we can evaluate it.

In thinking about it a little bit more, I have created another diagram that treats ETPLResource more like an Action subclass, which I propose that it actually is.

In detail, my updated proposal is:

Create:

URI: ceterms:ETPLAction Label: ETPL Action Definition: Resource that is on the WIOA Eligible Training Provider List referenced by this action. Comment: State or Local Workforce Board indicates the resource being referenced (e.g., credential and its learning opportunity or assessment) is on their Workforce Innovation and Opportunity Act (WIOA) Eligible Training Provider List. Subclass Of: ceterms:CredentialingAction Properties: ceterms:name, ceterms:description, ceterms:ctid, ceterms:actingAgent, ceterms:startDate, ceterms:endDate, ceterms:instrument, ceterms:object, ceterms:jurisdiction

This has a few benefits over the methods we were previously looking at using:

• It makes ETPL Actions first-class citizens of CTDL, complete with CTIDs (and URIs, and so on)
• It means you don't have to republish the QA Credential every time the list of things on the ETPL changes
• It leverages existing CTDL properties
• It allows separating the QA Credential whose terms are applied and the organization that is issuing the action (in case a state board decides to use some other organization's QA credential in its determination)
• It allows separating the publisher of the data from the state board organization itself (which should help with third-party publishers and other organizations that will be interacting with the registry on behalf of state boards)
• The use of startDate/endDate instead of credentialingActionStatus means that ETPL Actions don't need to be republished when they expire (i.e. it avoids confusion that would otherwise exist if an ETPL Action had a "current" status but was past its endDate)

Additionally, I envision the usage of the Credential/Assessment/Learning Opportunity on the other end of the object property to follow the same approach we use for Transfer Value Profile where one of two things happens:

1. Either the Credential/Assessment/Learning Opportunity is referenced directly (if the ETPL is making no additional assertions about it), or
2. The ETPL Action references a bnode with a @type of Credential/Assessment/Learning Opportunity, makes all relevant assertions within that bnode (like Industry Type, relevant Competencies, etc.), and then that bnode uses ceterms:sameAs to reference (if available) the "real" data in the Registry

That would also handle cases where there is no pre-existing "real" record for the Credential/Assessment/Learning Opportunity in the Registry to point to. And I think it might even solve the ProPath use case of needing to handle "augmenting" data, but we'll need to explore that a bit further to be sure.

[siuc-nate]

Updated diagram:

[siuc-nate]

I couldn't find the original source for the diagram above (it looks like it was modified into something else?) so I recreated it with a few small adjustments for formatting and such, and to include the presence of "sameAs", which is important to the implementation:

[siuc-nate]

An alternative approach using ceterms:WorkforceDemandAction and ceasn:Collection with ceterms:classification

This approach:

• Uses ceterms:WorkforceDemandAction instead of ListAction in the above diagram
• Collects the ceterms:WorkforceDemandActions together in a state ETPL via ceasn:Collection
• Uses ceterms:classification to indicate that the Collection is a state ETPL
• References the state ETPL concept in the ceterms:result property (this may not be necessary since the Collection also references it)
• Uses a mix of indicators of demand via the ceterms:result property

https://github.com/CredentialEngine/Schema-Development/blob/master/Contextualized-Competency-Statements/WorkforceDemandAction%20for%20ETPL.json

[jeannekitchens]

This is handled by #806 .