ETPL approval indicator

[jeannekitchens]

Each state maintains WIOA-approved program lists. Federal and state policies determine how programs qualify to be included with a state's list. At this time, these lists are state by state and programs may be approved either statewide or regionally. Regions are Local Workforce Innovation Areas. It is very likely that some of the programs are approved state by state are national credentials that should not be duplicated in the Registry. In order for states to differentiate the programs that are WIOA-approved an indicator is needed. Other properties may be needed as well. This may require a task group to be convened.

[siuc-nate]

Solution 1 of 3:
Direct property relationships. For example, the state of New Jersey (a QA organization) would reference a number of credentials via the ceterms:etplApproves property. Those credentials would point back to New Jersey via the ceterms:etplApprovedBy property. This solution introduces two new properties: (1) ceterms:etplApproves and (2) ceterms:etplApprovedBy and is easy to implement.

However, it does not provide a means to create ETPL lists in the registry and include additional properties for describing how the credentials meet additional ETPL requirements or are offered within jurisdictions (e.g., a Local Workforce Innovation Area, Areas, or statewide). These ETPL requirements would likely not be described by the credential offerer and it's important to understand that these credentials can be obtained by people besides those who qualify for WIOA funds to pay for training or limited to a jurisdiction determined by LWIAs for meeting demand occupation requirements.

(QA Credential Organization) -[ etplApproves ]-> (Certificate of Completion)
(Certificate of Completion) -[ etplApprovedBy ]-> (QA Credential Organization)

URI: ceterms:etplApproves
Label: ETPL Approves
Definition: Resource that is approved to be on an Eligible Training Provider List related to this organization.
Domain: ceterms:CredentialOrganization, ceterms:QACredentialOrganization
Range: ceterms:Credential (and subclasses), ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile

URI: ceterms:etplApprovedBy
Label: ETPL Approved By
Definition: Referenced organization is related to an Eligible Training Provider List that includes this resource.
Domain: ceterms:Credential (and subclasses), ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile
Range: ceterms:CredentialOrganization, ceterms:QACredentialOrganization

---

Solution 2 of 3:
Resource Set object. For example, the state of New Jersey (a QA organization) would reference a Resource Set for each of its ETPLs. These Resource Sets would, in turn, reference the information relevant to that ETPL, such as LWIA, demand occupation, and the list of applicable credentials. This solution requires creating a new class and terms, but may also serve other use cases.

The Resource Set object allows referencing and describing a set of resources as a single unit, which serves a variety of purposes.

URI: ceterms:ResourceSet
Label: Resource Set
Domain: Arbitrary collection of resources related for some purpose.
Properties: ceterms:name, ceterms:description, ceterms:subjectWebpage, ceterms:targetCredential, ceterms:targetLearningOpportunity, ceterms:targetAssessment, ceterms:targetAgent, ceterms:targetCompetency, ceterms:targetLearningResource, ceterms:targetResource, ceterms:instrument, ceterms:region, ceterms:industryType, ceterms:occupationType, ceterms:instructionalProgramType, ceterms:resourceSetType

The Has Resource Set property enables an organization to reference the Resource Sets that it has published.

URI: ceterms:hasResourceSet
Label: Has Resource Set
Definition: Resource Set maintained by this organization.
Domain: ceterms:CredentialOrganization, ceterms:QACredentialOrganization
Range: ceterms:ResourceSet

The Resource Set Type property allows categorizing a Resource Set using either a Credential Alignment Object alone or the combination of a Credential Alignment Object and some skos:Concept from a Concept Scheme.

URI: ceterms:resourceSetType
Label: Resource Set Type
Definition: Type of Resource Set; select from an existing enumeration of such types.
Domain: ceterms:ResourceSet
Range: ceterms:CredentialAlignmentObject

The Target Agent property fills a gap in the Resource Set's ability to reference things (and a gap in CTDL's ability to reference a list of organizations generically). I am surprised we don't already have a property like this.

URI: ceterms:targetAgent
Label: Target Agent
Definition: Agent that is relevant to this resource.
Domain: ceterms:ResourceSet
Range: ceterms:CredentialOrganization, ceterms:QACredentialOrganization

The Target Resource property acts as a catch-all to enable referencing other kinds of resources that don't have explicit properties. This avoids the need to create new properties every time some new type of resource-to-be-referenced is identified (and the delay in doing so).

URI: ceterms:targetResource
Label: Target Resource
Definition: Resource that is relevant to this resource.
Usage Note: Use this property when no more specific property is available or appropriate.
Domain: ceterms:ResourceSet
Range: xsd:anyURI

{
  "@type": "ceterms:QACredentialOrganization",
  "ceterms:hasResourceSet": [
    "https://.../abc"
  ]
}

{
  "@type": "ceterms:ResourceSet",
  "@id": "https://.../resources/ce-abc",
  "ceterms:name": { "en": "New Jersey Manufacturing ETPL" },
  "ceterms:description": { "en": "..." },
  "ceterms:subjectWebpage": [
    "https://.../etpl/manufacturing",
    "..."
  ],
  "ceterms:resourceSetType": [
    {
      "@type": "ceterms:CredentialAlignmentObject",
      "ceterms:targetNode": "https://.../resources/ce-xyz",
      "ceterms:targetNodeName": { "en": "Eligible Training Provider List" }
    }
  ],
  "ceterms:industryType": [
    "https://.../industry/manufacturing"
  ],
  "ceterms:occupationType": [
    "https://.../demandoccupations/cncmachinist",
    "https://.../demandoccupations/welder",
    "..."
  ],
  "ceterms:region": [
    "https://.../wioa/2",
    "https://.../wioa/3"
  ],
  "ceterms:targetCredential": [
    "https://.../resources/ce-123",
    "https://.../resources/ce-456",
    "..."
  ],
  "ceterms:instrument": [
    "https://.../resources/ce-789"
  ]
  "ceterms:approvedBy": [
    "https://.../resources/ce-def"
  ]
}

Additional considerations before moving forward with this solution:

• It's probably useful to define a concept scheme for Resource Set types, but should also allow user-defined types (i.e. "Other" options).
• We could simplify the Resource Set property list by using targetResource instead of the other various target___ properties. This would avoid any definition conflicts and avoid the need to create a targetAgent property, but would mean that all such resources would need to be resolved in order to find out their @type value.
• It would probably be useful (for this and other cases, such as the Publisher's need to reuse locations) to be able to reference a ceterms:Place by URI instead of repeating it inside of objects. It may be possible to circumvent this by publishing an organization to represent each WIOA's board, putting the ceterms:Place information for that WIOA in that organization's data, and referencing that organization via the targetAgent property.

---

Solution 3 of 3:
Leverage QA Credentials as ETPLs. This approach takes advantage of the full compliment of properties and connections already present in QA Credentials to enable defining the relevant organization(s), place(s), connections to concept schemes (i.e. industry/occupation/program type), and definition of requirements for being a part of that ETPL. Rather than creating a new object to connect the requirements described in a QA credential, this approach just uses the QA credential itself to embody the list. This also fulfills the need to be able to refer to a list of resources as a group. To actually reference the relevant members of the list, it uses properties based on those from Solution 1.

(QA Organization: New Jersey) -[ owns ]-> (QA Credential: ETPL 1)
(QA Credential: ETPL 1) -[ hasETPLMember ]-> (Credential/Assessment/Learning Opportunity/etc.)
(Credential/Assessment/Learning Opportunity/etc.) -[ isETPLMemberOf ]-> (QA Credential ETPL 2)

URI: ceterms:hasETPLMember
Label: Has ETPL Member
Definition: Resource that is a member of the Eligible Training Provider List described by this resource.
Domain: ceterms:QualityAssuranceCredential
Range: ceterms:Credential (and subclasses), ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile

URI: ceterms:isETPLMemberOf
Label: Is ETPL Member Of
Definition: Eligible Training Provider List of which this resource is a member.
Domain: ceterms:Credential (and subclasses), ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile
Range: ceterms:QualityAssuranceCredential

[siuc-nate]

I think I've changed my mind after seeing how much of a behemoth solution 2 became - I think solution 3 gives us all of the benefits we're looking for without all the extra overhead, dev time, complexity, task groups, etc.

The main benefit of solution 3 over solution 1 in my opinion is having that object in the middle (the QA Credential) that allows an organization to have multiple ETPLs, each of which can be uniquely described and referenced. Since QA Credential already facilitiates connecting to a bunch of other things (including WIOAs via Place, boards for those WIOAs via approvedBy, branching requirements for being on the ETPL, financial assistance info, etc.) I think it makes more sense to use it instead of creating a new object that risks ballooning into a Credential-sized thing.

To me this outweighs the reusability features of solution 2, which would be "nice to have" but for which we don't have an actual pressing need. We can always come back to the notion of a Resource Set later if such need arises.

So my vote is for solution 3. I think it gets us the simplicity of solution 1 with the flexibility of solution 2 (moreso in fact since QA credential already has a bunch of properties) while being very simple to understand and implement (and we get to leverage having ETPL-specific properties we can define more closely).

It also dodges the need to create a Resource Set concept scheme.

As far as justifying the use of a QA Credential semantically goes:

• QA Credentials are meant to embody a list of requirements something else must meet for QA (check)
• QA Credentials are meant to be issued to things that meet those requirements (in essence, being on an ETPL means you met those requirements and earned your slot) (check)
• The hasETPLMember property does an end-run around the need to figure out how to use a CredentialingAction class

In other words: Semantically speaking, don't think of the QA Credential as a list of things (even if we sort of use it like one); think of it as something that was issued to all of those things (via the hasETPLMember property instead of an Action). This is within the boundaries of what QA Credentials are meant to do.

[stuartasutton]

Nate, I agree that this is the better of the three solutions.

I think we still need to talk a bit about the fact that this is QA Credential that may be relatively dynamic in terms of the programs an instance references; although, I doubt that programs granted the imprimatur lose it very often and spinning up new programs within an geographic area are also costly and likely don't occur with great frequency.

Obviously, I'm pleased that ResourceSet has been tabled. I'm not fond of chameleon classes that lack a particular identity and take on the form of anything needed where there are choices like here where the problem can be solved using non-chameleon classes.

[philbarker]

@siuc-nate +1 for option 3.

Are the arrows for isEPTLMemberOf pointing in the wrong direction?

[siuc-nate]

@philbarker Oops - good catch. I fixed the image.

[siuc-nate]

Replaced by #696