Credential Transparency Description Language (CTDL) Handbook

Creative Commons License
Credential Transparency Description Language (CTDL) by Credential Engine is licensed under a Creative Commons Attribution 4.0 International License.

CTDL Handbook

About

This document is intended to introduce newcomers to the basics of Credential Transparency Description Language (CTDL) and to provide those familiar with the description language with a means for quick reference and example solutions in describing credentials and other key entities in the credentialing ecosystem. It is not intended to be a complete guide for using all of the properties in the dictionary of the description language. The CTDL is designed to enable: (1) creation of simple descriptions and to serve as a basis for website markup; and (2) rich descriptions to support fairly refined comparisons among credentials.

The status of this document is “draft” since we consider it incomplete (and likely includes the occasional error). We anticipate that the guidance provided here will be steadily improved and further developed by means of reader input and implementer experience.

Editors

Jeanne Kitchens, Associate Director, Center for Workforce Development, Southern Illinois University

Stuart A. Sutton, Emeritus Faculty, Information School, University of Washington

Status

Draft

Latest Update:

2017-11-06

Table of Contents

Top
  1. Introduction: CTDL model and its application
  2. Primary classes
    1. Credential, Agent and their subclasses
      1. Agents
      2. Credentials
    2. Condition Profile and 'condition sets'
      1. Condition Sets
      2. Sub-Conditions
      3. Degree with Concentrations
      4. Degree Requiring a Set of Certifications
      5. Dependent Dual Degrees
      6. Condition Manifest
    3. Assessment Profile
    4. Learning Opportunity Profile
    5. Career Pathway
  3. Support classes
    1. Cost Profile
      1. Credential-level Costs
      2. Cost Manifest
    2. Duration Profile
    3. Earnings Profile
    4. Employment Outcomes Profile
    5. Jurisdictions Profile
    6. Process Profile
    7. Revocation Profile
    8. Verification Profile
  4. Utility classes
    1. Credential Alignment Object
      1. Competency Frameworks
      2. Concept Schemes (Controlled Vocabularies)
    2. GeoCoordinates
    3. Identifiers
      1. URI
      2. CTID
      3. Other Identifiers
    4. Postal Address
    5. Contact Point
  5. Agent actions
  6. Concept Schemes (controlled vocabularies)
  7. Competency Frameworks
    1. Competency framework definitions & Examples
    2. Competency framework—RDF model & description set
      1. Competency Framework class
      2. Competency class
    3. The Taxon (traversal) path and structural properties
    4. 3rd Party Derivative Statements
    5. Examples
    6. Alignment of competencies in different frameworks
  8. Connections by 3rd Parties
    1. Alignment Maps
    2. Connecting other Resources
  9. CTDL Profiles
    1. Credential Engine Registry Profile
    2. CTDL Thin Profile (minimum required)
    3. Schema.org

Term Status

The classes and properties (terms) in the CTDL have an assigned status. It is very important that you look at the terms status so you can make an informed decision before you use it. The status designations are as follows:

Stable
The term is recommended for use.
Unstable
The term is under development and not yet recommended for use. Unstable terms are subject to removal.
Deprecated
The term is out of date or superseded and that new uses of it are no longer encouraged.
Obsolete
The term should no longer be implemented or deployed.

The status of upcoming CTDL releases are denoted as Pending. All items designated as Pending can only be viewed via the Technical Advisory Committee (TAC) area of the website. Pending items are not considered part of CTDL, but represent work in progress that is both intended to be included (or not) in an upcoming release and subject to change up to the time of release.

1. Introduction

The Credential Transparency Description Language (CTDL) is a vocabulary comprised of terms that are useful in making assertions about a Credential and its relationships to other entities. The word "vocabulary" is used here to refer specifically to a set of terms, a set in which the members are properties, classes, concept schemes, and/or data types.

In a sense, the CTDL is like a dictionary comprised of nouns (classes) and verbs (properties) that allow us to make simple statements, which, in aggregate, enable rich description of credential-related resources including credentialing organizations and specific subclasses of credential such as degrees, certificates, certifications, and digital badges. Credentials are related (linked) to other entities in the credentialing ecosystem such as assessments (Assessment), learning opportunities (LearningOpportunityProfile), and a myriad of conceptual frameworks such as competencies (Competency), assessment rubrics, and conceptual entities including formal classifications of occupations and instructional programs. The CTDL provides the terms to assert relationships among all of these entities.

Beyond defining the meaning and relationships among the terms—properties and classes—in this 'dictionary', the CTDL does not prescribe constraints on how those terms are used to create descriptions of resources. The CTDL does not define "records" and their accompanying constraints such as optionality and cardinality. Instead, CTDL leaves the definition and publication of such constraints to profiles developed by communities of practice and organizations. This allows the CTDL to be tailored to specific needs while promoting maximum data interoperability among these profiles.

One such community profile is the CTDL-CR defining constraints on the language for resource descriptions intended for publication in the Credential Engine Registry (CER).

The scope of the CTDL is description of credentials offered and does not include description of credentials awarded. While the language will prove useful for generation by others of verifiable claims of a credential holder, full description of such claims in outside the scope of the CTDL.

The CTDL is modeled as a directed graph using the W3C's Resource Description Framework [RDF] for describing data on the Web.

The Resource Description Framework (RDF) is an entity-centric framework for expressing information about resources. Resources can be anything, including documents, people, physical objects, and abstract concepts.

RDF is intended for situations in which information on the Web needs to be processed by applications, rather than being only displayed to people. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. The ability to exchange information between different applications means that the information may be made available to applications other than those for which it was originally created. [PRIMER]

RDF extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link (this is usually referred to as a "triple"). Using this simple model, RDF allows structured and semi-structured data to be mixed, exposed, and shared across different applications.

This linking structure forms a directed, labeled graph, where the edges represent the named link between two resources, represented by the graph nodes. This graph view is the easiest possible mental model for RDF and is often used in easy-to-understand visual explanations. This Guide uses this visual form of explanation as an abstract syntax for its figures. Where relevant, this abstract syntax of the Guide figures is accompanied by concrete syntaxes in JSONLD and RDF Turtle.

Many of the properties in CTDL have multiple domains and ranges. To avoid unintended semantic inferencing, CTDL defines properties using schema.org's domainIncludes and rangeIncludes instead of RDF Schema's domain and range.

2. Some Basics

The "triple" is the basic grammatical construct in making RDF data assertions about "things" and is comprised of three simple components: a subject, a predicate and an object. Some find it useful to think of the subject as the thing being described and the predicate and object as an 'attribute-value' pair.

The following table contains a simple set of such three-part assertions about a dental assisting certificate. The entities (things) in the set are a: (1) credentialing organization, (2) credential (certificate), (3) required learning opportunity, (4) required competency, and (5) quality assurance organization. The table is followed by the same data as a directed graph (abstract syntax). Where relevant, the icons for the JSONLD and Turtle concrete syntaxes appear below the figure.

STATEMENTS ABOUT THINGS (TRIPLES)
SubjectPredicateObject
Thing-1 type CredentialOrganization
CredentialingOrganization name Santa Rosa Junior College
CredentialingOrganization offers Certificate
CredentialingOrganization accreditedBy QualityAssuranceOrganization
Thing-2 type Certificate
Certificate name Dental Assisting
Certificate requires LearningOpportunityProfile
Certificate requires Competency
Thing-3 type LearningOpportunityProfile
LearningOpportunityProfile name Applied Dental Science
Thing-4 type Competency
Competency description Graduates of the dental assisting program will be able to make ethical decisions, and demonstrate problem-solving abilities through independent and critical thinking.
Thing-5 type QualityAssuranceOrganization
QualityAssuranceOrganization name American Dental Association, Commission on Dental Accreditation.

 

This set of terse statements in the 3-part grammatical form of triples is expressed in the abstract syntax of the directed graph below.

In the graph, properties are represented as arcs or single-direction arrows and classes (things) are the circles. There are two types of properties connecting components of the graph: (1) object properties that connect two nodes; and (2) data type properties connecting a node to literals (strings) describing attributes of the node. Literals are of three general types: (1) plain literals (e.g. "Gone with the Wind"), (2) language-tagged literals (e.g., "Gone with the Wind" in English); and datatypes (e.g., formally structured strings such as dates—"2016-02-15").

We use this abstract syntax to illustrate aspects of the CTDL as graph throughout this Guide. Below most of the graph images, we also include concrete syntax icons with links to files in JSON-LD and RDF/Turtle.

With the abstract graph representation, it can sometimes be difficult to know exactly where it is most meaningful to "enter" the graph for most efficient and meaningful traversal. In other words: "Which resource (thing) should I pick as a starting point so I can make the most sense of this graph?" In a sense, a directed graph is like a paragraph describing something. It is always better to start with the first word of the paragraph than in the middle. So, to assist, we have circled in red the entity that we consider the optimal entry resource. Using this suggested entry as a starting point guarantees that by following the grammatical arcs, you are guaranteed traversal of the entire graph.

2. Primary classes

The CTDL is comprised of a small set of primary classes identifying major entities in the credentialing ecosystem and includes the superclasses Agent and Credential. These two superclasses define families or sets of subclasses used throughout the CTDL. The primary classes also include: (1) the ConditionProfile used to define sets of constraints on both entry and earning the Credential being described; and (2) any AssessmentProfile, LearningOpportunityProfile, and CompetencyFramework for expressing learning goals and outcomes in terms of knowledge, skills, and abilities.

Figure 2a sets out these six primary classes and illustrates their general relationships. In the following subsections, each of these primary classes is described. Supporting classes are described in Section 3, Utility classes in Section 4, Agent Action classes in Section 5, and Competency Frameworks and competencies in Section 7.2. Properties related to each of the classes are illustrated throughout; however, to make the illustrations more useful, the examples include only select properties. The reader is advised to visit the class Specification Tables under which all properties related to a specific class are listed.

Figure 2a: Primary Classes
Figure 2a: Primary Classes

2.1. Credential, Agent and their Subclasses

In the figure below and throughout this Guide, references to the Agent class and to the Credential class are equally applicable to their sub-classes. The figure illustrates object properties relating Agent-to-Credential, Agent-to-Agent and Credential-to-Credential.

Figure 2.1a: Subclasses of Credential and Agent and their relationships
Figure 2.1a: Subclasses of Credential and Agent and their relationships

2.1.1. Agents

The Agent superclass is broadly defined as "The direct performer or driver of the action (animate or inanimate)." More targeted subclasses have been defined for use in describing agents playing key roles in the lifecycle of Credential development, maintenance, and application:

CredentialOrganization
QualityAssuranceOrganization
CredentialPerson [Unstable]

The figure below illustrates an instance of the CredentialOrganization subclass and includes a few of the available properties including the name of the organization, its subject webpage (subjectWebpage), a number of official identifiers (fein, opeID, and ipedsID), a reference to the organizations postal address (PostalAddress), and a reference to one of its offered certificates (Certificate). For additional information about the Agent class and its subclasses, and additional properties, see the Agent schema tables as well as additional properties available for use in describing relevant organizations and persons.

Fig. 2.1.1a: "Santa Rosa Junior College as Credential Organization
Fig. 2.1.1a: "Santa Rosa Junior College as Credential Organization
CTDL Classes Used CTDL Properties Used

For additional details about use of PostalCode class and its relationship to GeoCoordinates class, see Section 4.2 below and in particular Figure 4.2b.

Note that the subclasses of Agent within the context of CTDL do not include people to whom credentials have been awarded.

2.1.2. Credentials

The Credential superclass is broadly defined as "A qualification, achievement, personal or organizational quality, or aspect of an identity typically used to indicate suitability" and includes entities beyond the scope of the CTDL including things like passports, birth certificates, etc. The Credential superclass should not be used in CTDL resource descriptions where a more narrowly defined subclass is applicable. References throughout this Guide to the Credential class are equally applicable to its subclasses.

CTDL defines the following Credential subclasses for use in resource descriptions by the credentialing community:

Badge
    DigitalBadge
    OpenBadge
Certificate
    ApprenticeshipCertificate
    JourneymanCertificate
    MasterCertificate
Certification
Degree
    AssociateDegree
    BachelorDegree
    MasterDegree
    DoctoralDegree
        ProfessionalDoctorate
        ResearchDoctorate
Diploma
    GeneralEducationDiploma
    SecondarySchoolDiploma 
License    
MicroCredential 
QualityAssuranceCredential      

The following figure provides a brief description of a Dental Assisting Certificate from the Santa Rosa Junior College (SRJC). This brief description includes the certificate name (name), total credit units (creditUnitValue), and the certificates webpage on the SRJC website (subjectWebpage). In addition, one required (requires) course (LearningOpportunityProfile) is referenced. The description also identifies and describes the O*Net "Dental Assistants" occupation code (occupationType). The Certificate product identifier (ctid) is included.

Figure 2.1.2a: Dental Assisting Certificate
Figure 2.1.2a: Dental Assisting Certificate
CTDL Classes Used CTDL Properties Used

For more on the LearningOpportunityProfile class, see Section 2.4 below. For more on the CredentialAlignmentObject class, see Section 4.1 below.

2.2. ConditionProfile

The conditions for awarding or renewing a credential may be quite complex involving a number of tightly coupled sets of constraints that the CTDL calls "condition sets". The ConditionProfile class is used to describe a "condition set". The "condition set" of a particular instance of ConditionProfile is invariably applicable to all of the Profile's target resources. The "condition set" may include constraints on applicable audience, residency requirements, minimum age and experience requirements, credit hour requirements, and jurisdictional restrictions. Since an Agent may offer the same Credential with varying "condition sets", their may be as many instances of the ConditionProfile class for a single property (e.g., requires or recommends) as their are applicable condition sets.

2.2.1. Condition Sets

The figure below illustrates a Certificate that requires a "condition set" of 3.5 years of experience and a minimum age (minimumAge) of "21". This "condition set" is applicable to any and all of the figure's "target" resources—here instances of the AssessmentProfile class and the LearningOpportunityProfile class.

Fig. 2.2a: "Condition set" illustration with multiple targets
Fig. 2.2a: "Condition set" illustration with multiple targets
CTDL Classes Used CTDL Properties Used

2.2.2. Sub-Conditions

A set of conditions represented by a Condition Profile may have sub-sets of conditions defined by additional instances of the ConditionProfile class. In other words, a Condition Profile may branch into two or more optional instances of the ConditionProfile class—each option defining a different aggregate set of conditions. The following figure illustrates a Certificate that has entry condition property (entryCondition) pointing to a Condition Profile requiring submission of transcripts (submissionOf) and the taking of an targetAssessment. Through use of the alternative conditions (alternativeCondition) property, this Condition Profile branches to separate instances of the ConditionProfiles class—one branch points to a ConditionProfile requiring a Master's Degree (MasterDegree) and the other branch requires both a Bachelor's Degree (BachelorDegree) and 2 years of experience in a relevant field. The result is aggregate condition sets for two entry options:

ENTRY CONDITIONS
OPTION 1 OPTION 2
  • Transcripts
  • Assessment
  • Master's Degree
  • Transcripts
  • Assessment
  • Bachelor's Degree
  • 2 Years Experience
Fig. 2.2b: Credential with two Sub-Conditions
Fig. 2.2b: Credential with two Sub-Conditions
CTDL Classes Used CTDL Properties Used

2.2.3. Degree with Concentrations

Degree's frequently provide more than one prescribed path to earning the degree. These options, while variously named, are referred to in CTDL as concentrations. The following figure illustrates a Bachelor of Arts in Communication that provides a common set of courses that all students take and then two concentrations from which the students may choose—Social and Cultural Communication and Technology and Global Media. Each concentration has an array of learning opportunities.

Figure 2.2c: Bachelor Degree with with two subconditions defining degree concentrations
Figure 2.2c: Bachelor Degree with with two subconditions defining degree concentrations
CTDL Classes Used CTDL Properties Used

2.2.4. Degree Requiring a Set of Certifications

Some degrees are primarily or solely comprised of certificates earned. Those certificates may or may not be developed and controlled by the entity awarding the degree. The figure below illustrates a set of conditions wherein the learner takes required courses, some of which prepare him or her for required CompTIA certification.

Fig. 2.2d: Two required Conditions--Courses + Certifications
Fig. 2.2d: Two required Conditions--Courses + Certifications
CTDL Classes Used CTDL Properties Used

2.2.5. Dependent Dual Degrees

Dependent dual degrees are two degrees that are tailored to go together—e.g., a Master of Architecture and a Master of Science in Civil Engineering. Dual degrees are described in CTDL as two separate degrees and mutually related through through an instance of ConditionProfile. The following figure illustrates such dependent dual degrees with an intersecting ConditionProfile describing the condition set identifying requirements with a description property stating that "[a] maximum of 15 credits may be used to satisfy requirements of both Architecture and Engineering degrees".

Figure 2.2e: A tailored dual degree program permitting students to obtain both an Master of Architecture and a Master of Science in Civil Engineering
Figure 2.2e: A tailored dual degree program permitting students to obtain both an Master of Architecture and a Master of Science in Civil Engineering
Architecture:
Engineering:
CTDL Classes Used CTDL Properties Used

Dual degrees may or may not be the "same" degrees as those offered separately. Frequently, due to changes in credit hours or other accommodations of a dual degree program, there are differences that means the regular version of the degree and the dual degree version should be described separate and assigned difference ctid identifiers.

2.2.6. Conditions Manifest

While the ConditionProfile class is useful for describing the condition sets of a particular credential, there are frequent circumstances where a condition set is applicable at the institution or programmatic level and thus controlling across an array of credentials. The ConditionsManifest class addresses the description of these institution- or program-wide condition sets. In the figure below, we see Western Governors University and its College of Information Technology. Each of these entities has a ConditionsManifest. While the College has its own ConditionsManifest, it shares the University’s ConditionManifest as required CommonConditions.

The College offers a bachelor's degree that is subject to the College’s ConditionManifest, and, indirectly, subject to the requirements of the University’s ConditionManifest. While not illustrated here, the bachelor’s degree can have a ConditionProfile containing conditions not covered by either controlling ConditionManifest. Thus, the degree has a cumulative set of conditions: (1) unique conditions peculiar to itself, (2) it’s College’s conditions, and (3) its University’s conditions.

Figure 2.2.6a: Parent and sub-organization, each with condition manifests
Figure 2.2.6a: Parent and sub-organization, each with condition manifests
CTDL Classes Used CTDL Properties Used

2.3. Assessment Profile

The AssessmentProfile is defined as "[a] resource that describes the key characteristics of an assessment for a credential." The figure below illustrates the use of Assessment Profile to describes a summative (Summative) performance (Performance) evaluation called "Modern Dance Performance Findal (Recital)" required by a course (LearningOpportunityProfile) named "Modern Dance VI". The concept values for both the assessment use and the assessment method are drawn from controlled vocabularies described using the CredentialAlignmentObject.

Figure 2.3a: Assessment Profile of a Learning Opportunity (Dance)
Figure 2.3a: Assessment Profile of a Learning Opportunity (Dance)
CTDL Classes Used CTDL Properties Used

For information on the CredentialAlignmentObject, see Section 4.1 below.

2.4. Learning Opportunity Profile

A learning resource is defined as “[a] resource describing a learning opportunity”. Learning opportunities include required and optional programs, courses of study, apprenticeships, and any other structured experiences intended to serve as educational or training events.

Figure 2.4a: Condition Profile referencing a Learning Opportunity Profile
Figure 2.4a: Condition Profile referencing a Learning Opportunity Profile
CTDL Classes Used CTDL Properties Used

2.5. Career Pathway

[In development]

3. Support classes

In addition to the Primary Classes, there is an array of supporting classes that make it possible to describe various aspects of a Credential in greater detail including data from external sources such as aggregate earning and employment data for the Credential being described. The following figure illustrates in a general way the relationships between the Primary Classes and these Supporting Classes and includes brief definitions.

Figure 3a: Primary class relationships to profile classes
Figure 3a: Primary class relationships to profile classes

In the following sections, we'll discuss each of these supporting classes.

3.1. Cost Profile

The CTDL provides the means to describe various types of costs as reflected in the CostType controlled vocabulary. Some of these costs may be applicable to a specific Credential or its associated AssessmentProfile or LearningOpportunityProfile classes. Such credential-level costs are illustrated in Section 3.1.1 below. However, other costs are more broadly applicable institutionally or programmatically across an array of Credential, AssessmentProfile or LearningOpportunityProfile classes. Such institutional or programmatic costs are illustrated in Section 3.1.2 below.

3.1.1. Credential-level Costs

Fig. 3.1.1a: Total tuition for a full-time, in-state student.
Fig. 3.1.1a: Total tuition for a full-time, in-state student.
CTDL Classes Used CTDL Properties Used

3.1.2. Cost Manifest

While the CostProfile class is useful for describing the costs of a particular credential, there are frequent circumstances where costs are applicable at the institution or programmatic level and across an array of credentials. The CostManifest class under development will address the description of these institution- or program-wide costs.

Fig.3.1.2a: Brandman University example of a cross-program Cost Manifest
Fig.3.1.2a: Brandman University example of a cross-program Cost Manifest
CTDL Classes Used CTDL Properties Used

3.2. Duration Profile

Many entities in the CTDL model have temporal aspects—i.e., durations, dates, start and end times. The DurationProfile supports description of these temporal aspects. Aspects of time are expressed using the ISO 8601 Data Elements and Interchange Formats–Information Interchange–Representation of Dates and Times [ISO8601]. Temporal values encoded using ISO 8601 can be parsed and displayed in a manner suitable for particular audiences. For example, the letter "P" (period) in the temporal values in the following figure is the duration designator and starts values denoting a specific duration. "T" (time) is the time designator that precedes the time components of the representation and the "H" is the ISO 8601 hour designator.

Figure 3.2a: Duration of a self-paced course.
Figure 3.2a: Duration of a self-paced course.
CTDL Classes Used CTDL Properties Used

3.3. Earnings Profile

[In development]

3.4. Employment Outcomes Profile

[In development]

3.5. Jurisdictions Profile

The JurisdictionProfile class is used throughout the CTDL to describe geographic and geo-political regions where a Credential is available or useful. The Profile supports description of the main region (mainJurisdiction) as well as any exceptions to that main region (jurisdictionException). The figure below illustrates a main region of "United States" with the exception of "Texas". JurisdictionProfile also supports a narrative description of the region as well as the ability to assert global applicability or utility (globalJurisdiction).

Figure 3.5a: Jurisdiction with an exception
Figure 3.5a: Jurisdiction with an exception
CTDL Classes Used CTDL Properties Used

Where the complexity of designating exceptions is not present, a more direct reference to a region is possible using the GeoCoordinates class by itself. The following figure illustrates this use in declaring that an instance of the Certification class has utility throughout the United States. (See another example of this use of GeoCoordinates in figure 5.2a below).

Figure 3.5b: Simple reference to an applicable region
Figure 3.5b: Simple reference to an applicable region
CTDL Classes Used CTDL Properties Used

3.6. Process Profile

The Process Profile (ProcessProfile) supports description of development, maintenance, and administrative processes in the lifecycle of instances of the Credential class. The Profile provides for identification of relevant Agents, frequency and nature of required processes, required standards to be applied in these processes, and the forms of external inputs into development, maintenance, and administration. Any constraints on processes in terms of temporal or spatial factors can be identified and described.

The following figure illustrates a simple use of the ProcessProfile class in describing the maintenance of a Certification (Certification). It identifies a frequency of "annual review and update" and requires external input from "subject matter experts" in that process. It uses the CredentialAlignmentObject to identify the type of external input as defined in the CTDL ExternalInput type vocabulary where the concept of "Expert" is identified by URI (for use in Linked Data) and its semantics defined.

Figure 3.6a: Certificate with annual maintenance review
Figure 3.6a: Certificate with annual maintenance review
CTDL Classes Used CTDL Properties Used
The CTDL defines three properties for referencing an instance of ProcessProfile from a Credential: (1) administrationProcess, (2) developmentProcess, and maintenanceProcess.

3.7. Revocation Profile

The Revocation Profile (RevocationProfile) describes the "conditions and methods by which a credential can be removed from a holder". The Profile provides the means to describe the revocation criteria, reference webpages with detailed information, any jurisdiction or region of applicability, and effective date. The figure below describes the revocation information for a Certificate.

Figure 3.7a: Credential revocation information
Figure 3.7a: Credential revocation information
CTDL Classes Used CTDL Properties Used

3.8. Verification Service Profile

The Verification Service Profile (VerificationServiceProfile) describes "the means by which someone can verify whether a credential has been attained". The Profile includes properties for providing a narrative description, whether the holder must authorize any verifications, jurisdiction or region of application, the type of a claim, and any related costs for the service. The figure below documents the verification service of a Credential Organization that requires the holder of a credential to authorize the organization to provide the verification service, the $25 fee charged for the service, the type of verification (through transcript) and its description.

Figure 3.8a: Verification by transcript
Figure 3.8a: Verification by transcript
CTDL Classes Used CTDL Properties Used

4. Utility classes

CTDL defines a set of utility classes that have application across the description language. They support, in a consistent way, description of values defined in: (1) concept schemes (controlled vocabularies) and other structured frameworks; (2) geospatial dimensions for regions of presence and jurisdictions of applicability; (3) postal addresses and contact points; and (4) various identifiers and their purpose.

4.1. Credential Alignment Object

The Credential Alignment Object is used throughout the CTDL to reference conceptual values, as well as people, places and things in structured frameworks such as:

All are described in the CTDL using the Credential Alignment Object. The illustrations and the linked example encodings illustrate the broad use of the Credential Alignment Object.

4.1.1. Competency Frameworks

One of the most pervasive uses of the Credential Alignment Object class is relating various entities in the CTDL model to competency frameworks (CompetencyFramework) and their member competencies (Competency). Using the targetCompetency property, the learning opportunity (LearningOpportunityProfile) in the figure below is linked to an instance of the Credential Alignment Object (CredentialAlignmentObject) that identifies a competency in the Degree Qualification Profile (DQP) to which the learning opportunity is aligned.

The description properties for the identified competency node in the DQP framework include: (1) the framework name (frameworkName), (2) the identity of the framework by URI, (3) the target node in the framework (targetNode) by URI, and (4) the text of the competency (targetNodeDescription).

Figure 4.1a: Credential alignment object referencing a DQP competency
Figure 4.1a: Credential alignment object referencing a DQP competency
CTDL Classes Used CTDL Properties Used

4.1.2. Concept Schemes (Controlled Vocabularies)

The following graphic illustrates the use of the Credential Alignment Object (CredentialAlignmentObject) to assert that a certain instance of the Credential class has an occupation type (occupationType) of "Deaf-blind interpreter" as defined in the RDF-based European Skills/Competences, qualifications and Occupations (ESCO) and identified with the URI of http://data.europa.eu/esco/occupations/18622.

Figure 4.1b: Credential alignment object referencing ESCO occupation
Figure 4.1b: Credential alignment object referencing ESCO occupation
CTDL Classes Used CTDL Properties Used

The following example follows the exact same pattern of use but adds targetNodeDescription and codedNotation properties to more fully describe the instructional program type of the Learning Opportunity being profiled. The framework being used is the Classification of Instructional Programs (CIP) and the specific CIP program is Engine Machinist.

Figure 4.1c: Credential alignment object referencing CIP instructional program type
Figure 4.1c: Credential alignment object referencing CIP instructional program type
CTDL Classes Used CTDL Properties Used

In addition, the CTDL has created nearly 20 concept schemes defining values to be used with specific properties. In CTDL conformant data, those values are expressed in resource descriptions using the Credential Alignment Object in the manner illustrated below.

Figure 4.1d: Credential alignment object referencing CTDL concept
Figure 4.1d: Credential alignment object referencing CTDL concept
CTDL Classes Used CTDL Properties Used

4.2. GeoCoordinates

Important data regarding geographic regions and jurisdictions of credential applicability is captured through the CTDL JurisdictionProfile which relies on the GeoCoordinates class to identify geo-coordinates (longitude and latitude) of relevant countries, regions, and cities. The following figure uses the availableAt property to identify the exact geographic coordinates of the of the Santa Rosa Junior College where the Certificate being described is available.

Figure 4.2a: GeoCoordinates of an entity
Figure 4.2a: GeoCoordinates of an entity
CTDL Classes Used CTDL Properties Used

A further refinement of the GeoCoordinates class is the description of the postal address of the a building located at the stated coordinates.

Figure 4.2b: GeoCoordinates of an entity with embedded postal address
Figure 4.2b: GeoCoordinates of an entity with embedded postal address
CTDL Classes Used CTDL Properties Used
(See also JurisdictionProfile for addition uses of GeoCoordinates.)

4.3. Identifiers

4.3.1. URI

As noted in the introduction to this Handbook, RDF uses URIs as the basis of its mechanism for naming (identifying) the subjects, predicates, and objects in statements. However, where no RDF description of a resource being referenced in the object position is known, the resource may be represented as a blank node [bNode], and, depending on the circumstances, with or without bNode identifier [bNodeID].

In all cases, the classes identified as "Primary" in Section 2 above as well as instances of Credentialing Actions in Section 5 below should be identified by URI capable of returning the RDF data describing the resource. There is nothing prohibiting identification of all instances of CTDL classes by URI. Wherever possible, concept schemes, concepts, competencies and competency frameworks used as objects of statements should be identified by URI.

4.3.2. CTID

Where a credential and its associated entities are to be registered with the Credential Engine Registry, they must be assigned a Credential Transparency Identifier (CTID). A CTID is assigned the the following classes:

For information about the structure and role of the ctid in the Credential Engine Registry, see the CTID entry in the CER Handbook.

4.3.3. Other Identifiers

In addition to providing dedicated properties for a number of standard identifiers used in the credentialing ecosystem such as the ctid credential identifier, fein, ipedsID, duns, and opeID, the CTDL makes it possible to express the type and value of any other identifier deemed necessary through use of the IdentifierValue class. For example, in the following figure, a credentialing sub-organization includes a locally defined administrative sub-unit identifier.

Figure 4.3.3a: Local identifier definition and value
Figure 4.3.3a: Local identifier definition and value
CTDL Classes Used CTDL Properties Used

4.4. Postal Address

CTDL provides for description of postal addresses of instances of CredentialOrganization, QACredentialOrganizaiton, and Person.

Fig.4.4a. Adding an address to an organization.
Fig.4.4a. Adding an address to an organization.
CTDL Classes Used CTDL Properties Used

4.5. Contact Point

Large Agents frequently have numerous important contact points handling specific activities such as application, credential verification, and general information. The ContactPoint class provides an array of properties for describing such contact points.

While not illustrated in the figure below, the socialMedia property can be used to included social media addresses that are unique to the contact point. Social media addresses applicable to an organization as a whole should be included when describing the organization and should not be repeated with contact points.

Figure 4.5a: Two contact points for an entity
Figure 4.5a: Two contact points for an entity
CTDL Classes Used CTDL Properties Used

5. Agent Credentialing Actions

The CredentialingAction class enables Quality Assurance Organizations (QACredentialOrganizaton) to describe "actions" sufficiently to support verification. Different kinds of actions are expressed in the CTDL as distinct subclasses of CredentialingAction (see Credentialing Action Subclass table below). While simple RDF assertions for each of these kinds of CredentialingAction are available (e.g., accredit, approve, revoke), these CredentialingAction subclasses support more detailed description of actions taken where such detail is justified or verification is desirable.

NOTE: Since a Credentialing Action is an assertion by an organization that it has taken an action, creators of instances of the CredentialingAction subclasses (e.g., AccreditAction) should be limited to the agent of those actions. There are adequate properties for an organization that has been accredited by a quality assurance organization to make that assertion by using the accreditedBy and similar properties relating it to the acting quality assurance organization.

The following figure provides a general view of CredentialingAction in terms of related entities and supporting properties.

Figure 5a: Agent action
Figure 5a: Agent action

The following figure illustrates a particular use of the AccreditAction subclass of CredentialingAction in which a Quality Assurance Organization (QACredentialOrganization) took a January 23, 1971 (startTime) accredit action on the "Dental Assisting Program" learning opportunity (LearningOpportunityProfile) offered by a Credentialing Organization. The Quality Assurance Organization is the agent of the action and the learning opportunity is the object of the action. The instrument used by the Quality Assurance Organization in taking the action was its "Accreditation Standards for Dental Assisting Education Programs" (CompetencyFramework). The outcome was an awarded credential (CredentialAssertion) for the learning opportunity. Since there is no end date (endTime) the action of accreditation is ongoing.

Figure 5b: Quality Assurance Credential of an instructional Program
Figure 5b: Quality Assurance Credential of an instructional Program
CTDL Classes Used CTDL Properties Used

Subclasses of CredentialingAction are:

Action Description
Accredit Action An action by an independent, neutral, and authoritative agent that certifies a resource as meeting a prescribed set of standards.
Advanced Standing Action An claim by an agent asserting that the object credential of the action provides advanced standing for a credential under the asserting agent's authority.
Approve Action An action by an independent, neutral, and authoritative agent that pronounces a favorable judgment of a resource.
Recognize Action An action by an independent, neutral, and authoritative agent acknowledging the validity of a resource.
Regulate Action An action by an independent, neutral, and authoritative agent enforcing the legal requirements of a resource.
Renew Action An action by an authoritative agent renewing an existing credential assertion.
Revoke Action An action by an authoritative agent removing an credential assertion from the credential holder based on violations.
Rights Action An action asserting rights by an authoritative agent to possess, defend, transfer, license, and grant conditional access to a resource.

6. Concept Schemes (controlled vocabularies)

The CTDL uses concept scheme (controlled vocabularies) for values wherever possible to enhance data consistency. A number of such schemes have been created by CE for use with specific properties in CTDL and their documentation is readily available. With some properties, recommendations have been made on the use of concept schemes (or categories of concept schemes) that have been created by other entities such as classification codes for occupations (SOC and ESCO), industries (SIC), and instructional programs (CIP).

All of the concept schemes created by Credential Engine have been modeled in RDF using the W3C's Simple Knowledge Organization System [SKOS] to support unambiguous identification and semantics. Since each SKOS concept is identified by URI, they can be cross-walked to similar concepts in other vocabularies and otherwise used in Linked Data applications. For additional information on SKOS, See SKOS Simple Knowledge Organization System Primer [SKOSPRIMER] and SKOS Simple Knowledge Organization System Reference [SKOSREF]

While a few relevant vocabularies created by others have been modeled using RDF—e.g., the European Skills, Competencies, Qualifications and Occupations (ESCO)—most of the widely used vocabularies have not. The use of the CredentialAlignmentObject described in Section 4.1 supports description of both vocabularies modeled in RDF and those that currently have no RDF expression.

7. Competency Frameworks

Many classes in the CTDL model discussed above reference competencies including Credential and its subclasses, the LearningOpportunityProfile and the AssessmentProfile. To support interoperability on the web, competencies in a CTDL description set use a profile of the properties and classes defined in the Achievement Standards Network Description Framework (ASN). We identify this CTDL profile of the ASN here in the Guide as "CTDL-ASN". While the CTDL-ASN incorporates the ASN properties and classes into it’s own namespace (http://purl.org/ctdlasn/terms/), all properties and classes explicitly identify their equivalencies in the ASN.

The ASN, and thus the CTDL-ASN, are modeled using the W3C's Resource Description Framework (RDF) and support Linked Data referencing on the open Web. Each instance of an ASN class is identified by a HTTP-based URI. As a result, resolving these URI on the Web utilizes the same standard HTTP protocol that traverses linkages between current Web pages.

7.1. Competency Framework definitions & examples

A competency framework “description set” in CTDL-ASN is comprised of a single CompetencyFramework entity describing the framework as a whole and one or more logically related Competency entities. The figure below illustrates instances of these two classes and a few of the relationships between them.

These two classes of entities are define in the CTDL as follows:

These broad definitions are intended to encompass all statements —without exception— of learning or performance objectives and outcomes, knowledge, skills, acquired abilities and habits of mind. The relevant type or kind of competency as defined by the creators of the framework is captured in the data. All of the following examples would be considered competency frameworks.

1. Generally applicable competencies such as the Degree Qualification Profile (DQP)

Fig. 7.1a:Competency Framework & Competency Classes
Fig. 7.1a:Competency Framework & Competency Classes

2. Goals and outcomes

—In the context of a credential
—In the context of an course
—In the context of an assessment

7.2. Competency framework—RDF model & description set

In order to describe competency frameworks in as interoperable a manner as possible, Credential Engine based it's description language for competencies on the existing Achievement Standards Network Description Language (ASN-DL) that was developed by the U.S. National Science Foundation (NSF) between 1999-2013 for the description of logically related assertions of knowledge, skills and acquired abilities whether framed as goals, objectives or outcomes.

The ASN-DL was designed using the W3C's Resource Description Framework (RDF) for describing Linked Data on the open Web. The Credential Engine Profile of the ASN-DL adopts and builds on its properties and classes and has judiciously extended that set through: (1) property and class refinements, and, (2) the addition of new properties and classes defined in CE's own namespace.

A relatively comprehensive set of properties provide the means for richly describing instances of the Competency and CompetencyFramework entities.

7.2.1. Standard Document class

The StandardDocument class serves as a container object for a set if individual Statement entities describing competencies. As such, the Standard Document describes the context and the provenance of the competency framework. In addition to the fundamental attributes for discovery and identification such as title and publisher. Other attributes include properties for the language of the text, educationLevel, and rights. The following figure describes many, but not all, of the properties available for describing a competency framework as a whole.

Fig. 7.2.1a: Select properties of Standard Document
Fig. 7.2.1a: Select properties of Standard Document

7.2.2. Statement Class

Like the StandardDocument, Statement entities can also be richly described and related one to another. Provision is also made for semantically relating a Statement entity in one framework to a Statement defined in a different framework – wherever that framework might be located on the Web. It is possible to define the most common structural characteristics of competency relationships including their hierarchy or graph structure through properties such as hasChild and isChildOf as well as partitive relationships through isPartOf and hasPart. In addition to notions such as skillEmbodied, the CTDL-ASN provides the means to express degrees of similarity between Statement entities such as exactAlignment, broadAlignment, minorAlighment, and prerequisiteAlignment.

Fig. 7.2.2a: Select properties of Statement
Fig. 7.2.2a: Select properties of Statement

7.3. The Taxon (traveral) path and structural properties

The most common structural pattern of competency frameworks is the hierarchy. While this basic structure may sometimes be masked by how the framework is displayed in the 2-dimensional space of a webpage or a PDF document, as a data model, the tree structure has proven adequate across the modeling of thousands of such frameworks. In addition to this core hierarchical structure, other relationships between competencies in a single framework or across frameworks results in an overall graph structure.

There are three ASN properties that provide the structural relationships between the StandardDocument entity and its member Competency entities and between individual Competency entities: gemq:hasChild, gemq:isChildOf and dct:isPartOf. The following figure demonstrates how gemq:isChildOf and gemq:hasChild define the hierarchical structure while the partitive property isPartOf provides each competency with provenance by linking them back to the StandardDocument to which they belong and within which they are defined.

The figure below demonstrates the notion of a "taxon path" which traces a set of parent-child relationships from their root in the StandardDocument down one path to a leaf node competency. An aggregation of such taxon paths make up the hierarchical tree structure forming the spine the competency framework.

Fig. 7.3: Hierarchical Taxon Path
Fig. 7.3: Hierarchical Taxon Path
CTDL-ASN Classes Used CTDL-ASN Properties Used

Nothing in the ASN data model precludes polyhierarchical structures with a Statement having more than one parent Statement or StandardDocument.

7.4. 3rd Party Derivative Statements

For some service providers consuming and using the CTDL-ASN expression of a competency framework, the level of granularity of leaf statements may not be sufficiently granular to meet all service purposes. The ASN makes it possible to increase the granularity of expression of a Statement entity by distinguishing between canonical (original) statements as promulgated by the creator of a StandardDocument and non-canonical (derived) statements added by 3rd parties.

Derived 3rd party statements “refine” original statements by making more specific, granular assertions. Since derived statements are treated as first-class entities on the Web, they are assigned URIs by their creators in the same manner as original statements and clearly identified as DerivedStatment entities. Of course, derived statements can be easily eliminate, not display, or treated in some manner as simple annotations by services consuming the competency frameworks.

As a result of this extensibility, any 3rd party may directly create more granular Statement entities without authorization in their own namespace and relate those statements to the canonical (original) statements using the structural relations in the CTDL-ASN model. While it has not yet been determined whether such 3rd party derived statements will or will not be included in the CE competency framework repository as StandardDocument entities, nothing precludes a service from creating its own namespace to handle its refinements of canonical CTDL-ASN statements and exposing those refinements (or not) to the Web community.

The following figure illustrates this 3rd party "annotation" processes.

Fig. 7.4: 3rd party derivative statements
Fig. 7.4: 3rd party derivative statements
Framework A:
Framework B:
CTDL-ASN Classes Used CTDL-ASN Properties Used

7.5. Competency Framework Examples

The following two figures illustrate a taxon path in two separate competency frameworks.

7.5.1. Degree Qualification Profile (DQP)

Fig. 7.5a: Single Taxon Path: Degree Qualification Profile (DQP)
Fig. 7.5a: Single Taxon Path: Degree Qualification Profile (DQP)
CTDL-ASN Classes Used CTDL-ASN Properties Used

7.5.2. Certified Environmental, Safety and Health Trainer (CET) certification (BCSP)

Fig. 7.5b: Board of Certified Safety Professionals: Certified
Environmental, Safety and Health Trainer (CET) - Partial Exam Blueprint
Fig. 7.5b: Board of Certified Safety Professionals: Certified Environmental, Safety and Health Trainer (CET) - Partial Exam Blueprint
CTDL-ASN Classes Used CTDL-ASN Properties Used

7.6. Alignment of competencies in different frameworks

The creators of a competency framework may want to reference someone else's framework and may even be required to do so. Such references may be at the level of the StandardDocument or at the level of individual Statement nodes within that framework. Such references may express various kinds of relationships between a framework or competencies within it. The most prevalent kinds of relationships expressed are those of:

The following figure illustrates the use of existing CTDL-ASN properties to express degrees of similarity between competency nodes in two separate competency frameworks.

Fig. 7.6: Relating competencies in two different competency frameworks
Fig. 7.6: Relating competencies in two different competency frameworks
Framework A:
Framework B:
CTDL-ASN Classes Used CTDL-ASN Properties Used

8. Connections by 3rd Parties

So far, this Handbook has focused on the description of key entities within the CTDL model described by those closest to those entities—either their creators or parties working under the authority of the creators. Those descriptions include the identification of inter-Credential connections. The following figures illustrate such inter-Credential mappings by first and second parties.

Fig. 8.1: First party, inter-Credential assertion of advanced standing
Fig. 8.1: First party, inter-Credential assertion of advanced standing
Fig. 8.2: Reciprocal inter-Credential assertion by Parties "A" and "B"
Fig. 8.2: Reciprocal inter-Credential assertion by Parties "A" and "B"

8.1. Alignment Maps

In this section of the Handbook, we shift the focus from the connections defined by 1st and 2nd parties to connections by 3rd parties that played no role in defining the original entities. The following figure illustrates a 3rd party assertion of an advanced standing relationship between two Credentials created and owned by others.

Fig. 8.3: Assertion of advanced standing relationship by a 3rd party
Fig. 8.3: Assertion of advanced standing relationship by a 3rd party

Such 3rd party assertions are prevalent throughout the credentialing ecosystem. For example, the following figure is of an Illinois mapping document defining advanced standing relationships between the Army 68Q Pharmacy Specialists classification and courses in the Vincennes University Pharmacy Technician degree program.

Fig. 8.4: Vincennes University Military Bridge Program Roadmap mapping military experience to courses
Fig. 8.4: Vincennes University Military Bridge Program Roadmap mapping military experience to courses

Such alignment mappings between already existing entities are handled in the CTDL by means of a class called AlignmentMap. AlignmentMap instances are owned by the 3rd parties that create them. They are comprised of a set of logically related instances of the Resource Description Framework’s (RDF) built-in Statement class (rdf:Statement)—each Statement identifying a mapping assertion. In the Vincennes University example above, each cell in the matrix intersecting Army rank and Vincennes course becomes an rdf:Statement in the AlignmentMap. The following figure illustrates one such rdf:Statement among many (at the intersection outlined in red) along with the AlignmentMap and it’s owner, the Indiana Commission for Higher Education.

Fig. 8.6: Indiana Commission for Higher Education assertion of advanced standing
Fig. 8.6: Indiana Commission for Higher Education assertion of advanced standing
CTDL-Classes Used CTDL-Properties Used

8.2. Connecting Other Resources

The rdf:subject or rdf:object properties of the AssociationMap are not constrained by range. As a result, an AssociationMap does not limit the kinds of things that can be connected in an AssociationMap. Thus it is possible to connect Credentials to Credentials, Learning Resources to Learning Opportunities, Assessment to Competencies, and Competencies to Occupations as well as any other relevant resource pairs.

9. CTDL Profiles

The CTDL is a large and expressive language of description. By itself, the CTDL does not dictate how it might be constrained and used in any particular context. Defining such constraints is a function of CTDL application profiles (“AP” or “profile”). At this time, there are three such APs existing or in planning. Information about each of these three are set out below.

9.1. Credential Engine Registry Profile

The Credential Engine Registry Profile defines a set of constraints on the properties and classes of resource descriptions ingested into the Credential Engine Registry (CER). While encompassing much of the CTDL, there are some classes and properties not used. For example, The CER does not permit descriptions of CredentialPerson. In addition it constrains the range of certain properties. For example, the range of ceterms:requires is limited to the ConditionProfile thus precluding direct requirement assertions between a Credential instance and an instance of LearnmingOpportunityProfile or ceterms:AssessmentProfile even though such assertions are enabled by the broader CTDL. In-depth details of the profile are available in the Credential Engine Registry section of the drop-down navigation. See also the CTDL Thin Profile in the following section for the properties and classes required for a minimal description in the CER.

9.2. CTDL Thin Profile

The CTDL Thin Profile defines a minimal set of properties and classes without which the utility of the description is generally questionable. This Thin Profile also defines the threshold properties and classes for a minimally viable description in the Credential Engine.

9.3. Schema.org

A W3C Community called the Educational and Occupational Credentials in Schema.org Community Group has been form to "show how educational and occupational credentials may be described with schema.org, and to propose any additional terms for schema.org that may be necessary". Interested people are invited to join this W3C Community here. To the extent possible, the work will build off the CTDL.


REFERENCES

[bNode]
In RDF, a blank node (also called bnode) is a node in an RDF graph representing a resource for which a URI or literal is not given; https://en.wikipedia.org/wiki/Blank_node.
[bNodeID]
For handling bNodes in json-ld, see https://json-ld.org/spec/latest/json-ld/#identifying-blank-nodes.
[ISO 8601]
Data elements and interchange formats – Information interchange – Representation of dates and times; https://en.wikipedia.org/wiki/ISO_8601
[PRIMER]
Latest "RDF Primer" versions; https://www.w3.org/TR/rdf-primer/
[RDF]
Resource Description Framework (RDF); https://www.w3.org/RDF/
[SKOS]
Simple Knowledge Organization System (SKOS); https://www.w3.org/2004/02/skos/
[SKOSPRIMER]
SKOS Simple Knowledge Organization System Primer; https://www.w3.org/TR/2009/NOTE-skos-primer-20090818/
[SKOSREF]
SKOS Simple Knowledge Organization System Reference; https://www.w3.org/TR/2009/REC-skos-reference-20090818/
[URN]
Uniform ResourceIdentifier; https://en.wikipedia.org/wiki/Uniform_Resource_Name
[UUID]
Universally Unique Identifier; https://en.wikipedia.org/wiki/Universally_unique_identifier