Guide: Credential Transparency Description Language

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

Guide: Credential Transparency Description Language

About

This document is intended to introduce newcomers to the basics of 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-06-27

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 and their use
    1. Competency framework definitions & Examples
    2. Competency framework—RDF model & description set
      1. Standard Document class
      2. Statement class
    3. The Taxon (traversal) path and structural properties
    4. 3rd Party Derivative Statements
    5. Examples
    6. Alignment of competencies in different frameworks
  8. [TBD] CTDL Profiles
    1. [TBD] CTDL CER
    2. [TBD] CTDL "Thin"
    3. [TBD] Proposal for Schema.org extension for credentials

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 Language [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

Instances of all classes in the CTDL must be either identified by URI conforming to the HTTP protocol, or with nodeIDs if handled as blank nodes. In all cases the classes identified as "Primary" in Section 2 above as well as instances of Credentialing Actions in Section 5 below must be treated as RDF resources and identified by URI capable of returning the RDF data describing the entity. However, there is nothing prohibiting identification of all instances of CTDL classes as RDF resources and assigning URI. Where ever possible, concept schemes and concepts used as values should also be treated as RDF resources and identified by URI.

4.3.2. CTID

The Credential Transparency Identifier (CTID) is a globally unique product ID for instances of the Credential class and all and it's subclasses. It is an identifier created under the authority of the creator/owner/provider and identifies the credential in transactions with the external environment (e.g., in verifiable claims involving the credential).

Different versions of a credential are considered distinct expressions and each must be assigned its own CTID. Thus, the CTID lets you verify that you're getting exactly the right version of the credential.

The CTID is a URN (Uniform Resource Identifier) [URN] and is represented in the following Backus-Naur form:

<URN> ::= "urn:" <NID> ":" <NSS>

The NID (namespace identifier) is "ctdl" and the NSS (namespace-specific string) is a UUID [UUID]. The following identifier is a conforming CTID:

urn:ctdl:debab415-8fa6-4fe6-84dd-39e8930db7cc

The ctid property is used to reference the identifier value. The ctid property is a subproperty of the more inclusive credentialID property. Both serve the same purpose as product IDs for credentials.

A CTID registered with the CER resolves through the Credential Registry Service (CRS) of Credential Engine returning the Registry data describing the identified credential. The CTID, and instances of credentialID, are the equivalent of version identifiers for the credential. Different versions of a credential are considered distinct expressions and each must be assigned its own CTID or credentialID value.

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. There are properties to identify the type and value of such identifiers. 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 and their uses

Many classes in the CTDL model discussed above reference competencies including Credential and its subclasses, the LearningOpportunityProfile and the AssessmentProfile. The CTDL does not define a full set of properties and classes for describing such competency frameworks. Instead, to support wider interoperability, competencies in aCTDL 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".

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 is comprised of a single competency framework entity --called StandardDocument in CTDL-ASN -- and one or more logically related competencies --called Statement entities in CTDL-ASN.

Fig. 7.1a: Standard Document & Statement Classes
Fig. 7.1a: Standard Document & Statement Classes

The ASN defines a Statement as:

An assertion representing an expectation of what students should know, value, and be able to do at a target age or age range.

The CTDL-ASN refines this definition to mean:

An assertion of measurable or observable knowledge, skills, and abilities necessary to successful performance of a person in a given context.

A Standard Document is defined as:

A collection of Statements representing an expectation of what students should know, value, and be able to do at a target age or age range.

The CTDL-ASN refines this definition to mean:

An entity comprised of a logically related set of competencies.

These broad definitions are intended to encompass all statements —without exception— of learning or performance objectives and outcomes, knowledge, skills, 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.

In the context of the CTDL-ASN, the following are considered competency frameworks:

7.2. Competency framework—RDF model & description set

A relatively comprehensive set of properties provide the means for richly describing instances of the StandardDocument and Statement 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 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: Single taxon path traversal - From document to leaf competency
Fig. 7.3: Single taxon path traversal - From document to leaf competency
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

REFERENCES

[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