Credential Engine Schemas Handbook

Last Updated on 5/27/2021

About This Handbook

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.

Jeanne Kitchens, Chief Technology Services Officer, Credential Engine
Stuart A. Sutton, Emeritus Faculty, Information School, University of Washington
Phil Barker, Consultant, Cetis LLP

Important Background Information

The items in this section cover critical ideas, patterns, and contextual information that you will need to familiarize yourself with in order to get the most out of the CTDL family of specifications.

Frequently Used Terms

This handbook uses many technical terms that refer to notions like RDF, JSON-LD, Schemas, Graphs, Nodes, and so on, as well as references to various external specifications and standards. Some of these terms are described below. For more information, see the References section and the W3C Linked Data Glossary.


The CTDL family of specifications is intended to describe "things" such as a Credential, Organization, Assessment, Learning Opportunity, Competency, and so on. One of the most important aspects of describing "things" is to identify them. Identifiers in the CTDL family of specifications take on many forms, some of which can be used to reference the identified "thing" from anywhere else in the world via the Internet. The most common types of identifiers are:

  • URI: A URI is a string of characters that provides a name that is unique within a scheme and identifies either a resource or a term used to describe a resource (such as a property, class, or concept). In our context, URIs leverage namespaces and strict formatting rules that are described below.
  • URL: A URL is a specific subset of URIs (almost always beginning with either http:// or https://) which should lead to some kind of data, such as a webpage or JSON document. "URI" and "URL" are sometimes used interchangeably. Unless otherwise specified, any reference in this guide to a "URI" means a URL, often a Resource URI.
  • CTID: A Credential Transparency Identifier (CTID) is a string of characters made up of a UUIDv4 prefixed with ce-, for example: ce-2c2b00f7-bb83-4047-956b-cfc1135b8245.
  • Resource URI: In the Credential Registry context, a Resource URI is a URL that features a CTID appended to, for example: Such a Resource URI can be used to retrieve the data for a resource directly from the Registry. Many of the examples in this guide use res: as a shorthand for
  • Graph URI: In the Credential Registry context, a Graph URI is a URL that features a CTID appended to, for example: Such a Graph URI can be used to retrieve the data for a resource, as well as any blank nodes tied to that resource, directly from the Registry.
  • Blank Node Identifier: A blank node, or "BNode", is a special type of resource representation that is only identified, referenced, or retrievable in the context of some other object. Blank node identifiers have a special syntax that begins with _: followed by some string of characters that are unique within that context, such as _:resource1 or _:abc123, or most often, a UUID (e.g., _:734ca853-f178-4ffc-a102-88cb8eed6942).

Many other identifiers, such as DUNS, IPEDS ID, CIP Codes, etc., have specific properties assigned to them. For those that do not, CTDL provides the Identifier Value class to enable providing the textual identifier and its origin.

RDF and Linked Data

The CTDL family of specifications is built on the principles of the Resource Description Framework (RDF) approach to describing data.

The "triple" is the basic grammatical construct in making RDF data assertions about "things" and consists 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. A Credentialing Organization
  2. A Credential (Certificate)
  3. A required Learning Opportunity Profile
  4. A required Competency
  5. A Quality Assurance Organization

The table is followed by the same data as a directed graph (abstract syntax). Where relevant, the icons for the JSON-LD and Turtle concrete syntaxes appear below the figure.

Thing-1nameSanta Rosa Junior College
Thing-2nameDental Assisting
Thing-3nameApplied Dental Science
Thing-4competencyTextGraduates of the dental assisting program will be able to make ethical decisions, and demonstrate problem-solving abilities through independent and critical thinking.
Thing-5nameAmerican 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.

Namespaces and Borrowed Terms

URIs provide unambiguous identification through the use of names that are unique within their own naming schemes, or namespaces. Each namespace will have its own identifier, to which the name of a resource can be appended to create a unique identifier that is a combination of namespace+name. In the case of URLs, the namespace identifier will specify the protocol that may be used to retrieve a representation of the resource being identified, thus URLs that use the HTTP protocol begin http:. In order to assist readability it is common practice to provide an abbreviated prefix for the namespace part of the URI. These prefixes must be declared in the data where they are used, and so may vary from instance to instance, however it is conventional to use familiar prefixes suggested by the specifications that define the namespaces.

So, W3C Recommendation RDF Schema, which specifies a vocabulary for describing terms used in RDF, defines the namespace that is identified with the URI, and often abbreviated as rdfs:. The term within that namespace called label, is identified with the URI or the abbreviation rdfs:label.

The CTDL family of specifications defines the following namespaces for properties and classes, with suggested abbreviated prefixes:

Namespace URIAbbreviationComment to identify classes and properties in the CTDL vocabulary. Profile of ASN-DL (CTDL-ASN) Schema, see below. CTDL Quantitative Data schema (QData for short) is intended to describe aggregate / statistical data related to credentials and other such information. and classes used to aid in the management of schemas by the Credential Engine. Not intended for external implementation.

Other namespaces are used for concept schemes that form part of CTDL; see below.

Terms from many other specifications are used in defining CTDL, these are listed in the references section of the CTDL Schema.

CTDL allows the use of terms from other RDF specifications when describing resources. In some cases CTDL has been designed in the expectation that this will happen. So rather than having terms in CTDL for everything, the recommendation is that terms from some other specification should be used. For example, in the Education to Work context, Occupations and Jobs may be classified according to category; if they are, it is recommended that the W3C Simple Knowledge Organization System (SKOS) vocabulary is used to describe these categories. An introduction to SKOS is provided by the SKOS Primer.


RDF can be expressed in a number of formats, including triples, Turtle, and XML, but the most common format used for CTDL data is JSON-LD. JSON-LD is a specification that builds upon normal JSON to enable a standardized way to express RDF data.

In some cases, the JSON-LD specification offers multiple options for expressing data that are equally valid. This handbook (along with the other technical data on this site) and the data in the Credential Registry usually follows the following conventions:

  • Context Files: Records typically link to an external @context file, most often either or This reference is found at the outermost object in the data. See "Referencing a JSON-LD context"
  • Graphs: Examples on this page make use of the @graph feature of JSON-LD, which enables putting multiple related objects into the same array. Data in the Credential Registry is available using this feature if you use "graph" instead of "resources" in the URI for that data. See "Using @graph to explicitly express the default graph"
  • Namespace Prefixes: Examples on this page and data in the Credential Registry use namespaced properties (via shorthand URIs that can be expanded via the @context), even where only one namespace is used. This is done to provide absolute clarity as to the meaning of a given property, consistency of data when publishing or consuming, and to encourage good habits in terms of format, capitalization, and so on. For example: { "ceterms:ctid": "ce-c6bffa5f-be74-4f98-963f-1cc536328c73" } instead of { "ctid": "ce-c6bffa5f-be74-4f98-963f-1cc536328c73" }. See "Expansion within a Context"
  • Language Maps: Examples on this page and data in the Credential Registry uses the compact form of language maps where the value of language-dependent properties such as "name" or "description" is an object with one or more key-value pairs consisting of a BCP 47 language code key and a value that is either a string or an array of strings. For example: { "ceterms:name": { "en": "Credential Name" }, "ceterms:keyword": { "en": [ "keyword one", "keyword two" ] } }. See "Indexing language-tagged strings in JSON-LD"

Concept Schemes for Controlled Vocabularies

Where the value for a property is to be drawn from an enumeration of predefined terms (i.e. a controlled vocabulary) these terms are defined using the W3C Simple Knowledge Organization System (SKOS) vocabulary. SKOS allows Concepts to be identified with terms (such as words or alphanumeric codes), defined, labeled, related to each other and collected in schemes (i.e. Concept Schemes). CTDL defines many such enumerations or schemes, each in its own namespace. The URIs for CTDL concept scheme namespaces all begin, which is followed by a name for the concept scheme. The name of the term appended to the concept scheme URI gives a unique URI for the term that can be resolved to obtain all the encoded information about the term.

For historic reasons, a common pattern in CTDL is for properties that take a value from controlled vocabulary do so with that value provided as a CredentialAlignmentObject. This allows for a label, a definition and a source for the term to be provided even where the concept term is not defined using SKOS; however for a few properties the SKOS vocabulary is used to do the same.

Concept Scheme using SKOS

Primary and Secondary Classes

It is common in both Registry and non-Registry contexts to group the various CTDL classes into two basic categories:

  • "Primary" or "Top-Level" classes
  • "Secondary", "Support", or "Utility" classes

These designations are informal and occasionally inconsistent or context-dependent, but generally, "Primary" classes refer to classes with a CTID (and, by extension, a Registry URI) while "Secondary" classes are, in essence, everything else. The "Primary" classes tend to serve as entry points into a graph of data and are often the focus of the data itself, whereas the "Secondary" classes act to support or enhance the description of the data in the "Primary" classes. Additionally, "Secondary" classes often appear in more than one context, and the nature of that context usually depends on whatever property references that class.

For example, the "Primary" class of Certificate might have a set of requirements and a set of recommendations that are both described using the "Secondary" ConditionProfile class, but each instance of ConditionProfile is contextualized by the property that points to it (requires and recommends, respectively). This allows the Certificate to, for instance, require one set of competencies and recommend a second set using the same data structure.

Another common example is the CredentialAlignmentObject class, which serves the function of "referencing and/or identifying something else" in a wide variety of contexts (controlled vocabularies, competencies, external classifications, and so on).

Some classes occupy both designations depending on how they are used: For instance, a Competency has a CTID and a Registry URI just like a "Primary" class, but is often used as a "Secondary" class for the also "Primary" CompetencyFramework class. In the Registry, Competency Frameworks and their member Competencies are published in the same JSON-LD Graph, but each can be independently retrieved (and retrieving the Graph for the Competency Framework will return its Competencies as well). The same mixed designation and Registry behaviors follow for other "framework-like" collections of closely-related classes, such as Concept Schemes and their member Concepts, as well as Pathways and their member PathwayComponents.

Further blurring the line is the Registry's use of RDF Blank Nodes, which often represent would-be instances of "Primary" classes but have no assigned CTID or Registry URI. An example of such usage is described here. This highlights the informal nature of these designations. Nevertheless, they are useful conversational aides and worth being aware of.

The following diagram depicts common designations of a selection of "Primary" and "Secondary" classes, along with a partial list of connections between them to give a sense of how highly interconnected the CTDL schema is. Note that for readability, this graph also omits connections between "Primary" classes (such as an Organization owning a Credential), as well as connections between "Secondary" classes (such as a ConditionProfile using a CredentialAlignmentObject to indicate its audienceLevelType).

Data in the Wild vs Data in the Credential Registry

Credential Engine maintains a centralized repository of information that uses the CTDL family of specifications. This repository, and its related services, are called the Credential Registry.

Credential Engine puts a great deal of focus on using CTDL in and with the Credential Registry. However, the CTDL family of specifications is explicitly designed to function as an openly licensed, standalone set of schemas for use by anyone in any context in which it is deemed useful. Credential Engine encourages such use for the following reasons:

  • It increases interoperability across the credentialing ecosystem
  • It becomes easier to publish to and consume from any CTDL-conformant system (including Credential Engine's Credential Registry) when an organization's own systems are already using CTDL
  • Communication and data exchange between organizations becomes easier when those organizations are already using the same terms to describe their data
  • CTDL is designed to be compatible with major search engine crawlers, meaning that organizations that use CTDL embedded in their website data stand to benefit as search engines begin to recognize CTDL terms

In general, this handbook covers the CTDL family of specifications as a standalone set of schemas. Where information in this handbook is specific to the Credential Registry, it will be noted.

Application Profiles

Any implementation of CTDL is likely to need some additional constraints that are specific to that application. Collectively, these constraints make up an "Application Profile" of CTDL. Since these constraints are "local" to a specific application, they are deliberately not part of the CTDL itself. Examples of such constraints include:

  • Certain terms being required
  • Certain terms not being used at all
  • Determining which properties allow multiple values
  • Limits on the maximum or minimum number of values for a property, such as the maximum number of keywords or the minimum length of a description
  • Permitting only certain subsets of a property's range as valid values for that property
  • Extensions to the schema(s) that are specific to that application, such as properties and classes defined in its own or some 3rd party's namespace
  • Checks for valid values, such as working links or correctly-formatted email addresses
  • Determining when to embed data directly (such as a nested object in JSON) vs. when to reference it by a URI or blank node ID

As noted above, the Credential Registry uses the CTDL family of specifications. However, the Credential Registry implementation of CTDL has some additional constraints that are not part of these specifications. These constraints make up the Registry's "Application Profile" of CTDL. For a more detailed listing of the constraints in place for the Registry, consult the Policy Page.

For more information about constructing your own Application Profile, see the DCAP Process.

Credential Transparency Description Language (CTDL) Schema

The Credential Transparency Description Language (CTDL) is a vocabulary 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 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, Learning Opportunities, and a myriad of conceptual frameworks such as Competencies, 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 to others for generation of verifiable claims of a credential holder, full description of such claims is 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. [RDF 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's domainIncludes and rangeIncludes instead of RDF Schema's domain and range.


In CTDL, the notion of organizations fall under the umbrella of the Agent superclass, which is broadly defined as "The direct performer or driver of the action (animate or inanimate)." The Agent superclass is subclassed into CredentialPerson and Organization. The CredentialPerson class is intended to serve as a bridge between CTDL and other schemas that more directly deal with individuals, and is beyond the scope of this handbook. The Organization class covers any kind of organization and is equivalent to schema:Organization.

The example below shows an Organization playing the roles of an employer offering a job, the provider of a credential needed for that job, and the provider of an assessment needed to earn that credential.

Broad Organization Class
Broad Organization Class

More targeted subclasses have been defined for use in describing organizations playing key roles in the lifecycle of Credential development, maintenance, and application:

  1. Credential Organization
  2. QA Credential Organization

The figure below illustrates an instance of the Credential Organization subclass and includes a few of the available properties including the name of the organization, its webpage (subjectWebpage), a number of official identifiers (fein, opeID, and ipedsID), a reference to the organization's postal address (address), 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.

Figure 2.1.1A
Santa Rosa Junior College as Credential Organization

The example below shows an state board accrediting a school and approving of one of its credentials.

Quality Assurance Organization
Quality Assurance Organization


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. In the Credential Registry, one of the subclasses of Credential must be selected. References throughout this Guide to the Credential class are equally applicable to its subclasses.

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 (ceterms:creditValue), and the certificate's 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

For more on the LearningOpportunityProfile class, see Section this section. For more on the CredentialAlignmentObject class, see this section.

Credential Types

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

Recognition designed to be displayed as a marker of accomplishment, activity, achievement, skill, interest, association, or identity.
Digital Badge
Badge offered in digital form.
Open Badge
Visual symbol containing verifiable claims in accordance with the Open Badges specification and delivered digitally.
Credential that designates requisite knowledge and skills of an occupation, profession, or academic program.
Apprenticeship Certificate
Credential earned through work-based learning and earn-and-learn models that meet standards and are applicable to industry trades and professions.
Journeyman Certificate
Credential awarded to skilled workers on successful completion of an apprenticeship in industry trades and professions.
Master Certificate
Credential awarded upon demonstration through apprenticeship of the highest level of skills and performance in industry trades and professions.
Certificate of Completion
Credential that acknowledges completion of an assignment, training or other activity.
A record of the activity may or may not exist, and the credential may or may not be designed as preparation for another resource such as a credential, assessment, or learning opportunity.
Time-limited, revocable, renewable credential awarded by an authoritative body for demonstrating the knowledge, skills, and abilities to perform specific tasks or an occupation.
Certifications can typically be revoked if not renewed, for a violation of a code of ethics (if applicable) or proven incompetence after due process. Description of revocation criteria for a specific Certification should be defined using Revocation Profile.
Academic credential conferred upon completion of a program or course of study, typically over multiple years at a college or university.
Associate Degree
College/university award for students typically completing the first one to two years of post secondary school education.
Equivalent to an award at UNESCO ISCED 2011, Level 5.
Bachelor's Degree
College/university award for students typically completing three to five years of education where course work and activities advance skills beyond those of the first one to two years of college/university study.
Equivalent to an award at UNESCO ISCED 2011, Level 6.
Use for 5-year cooperative (work-study) programs. A cooperative plan provides for alternate class attendance and employment in business, industry, or government; thus, it allows students to combine actual work experience with their college studies. Also includes bachelor's degrees in which the normal 4 years of work are completed in 3 years.
Doctoral Degree
Highest credential award for students who have completed both a bachelor's degree and a master's degree or their equivalent as well as independent research and/or a significant project or paper.
Equivalent to UNESCO ISCED, Level 8.
Professional Doctorate
Doctoral degree conferred upon completion of a program providing the knowledge and skills for the recognition, credential, or license required for professional practice.
Equivalent to an award at UNESCO ISCED 2011, Level 8.
Research Doctorate
Doctoral degree conferred for advanced work beyond the master level, including the preparation and defense of a thesis or dissertation based on original research, or the planning and execution of an original project demonstrating substantial artistic or scholarly achievement.
Equivalent to an award at UNESCO ISCED 2011, Level 8.
Master's Degree
Credential awarded for a graduate level course of study where course work and activities advance skills beyond those of the bachelor's degree or its equivalent.
Equivalent to an award at UNESCO ISCED 2011, Level 7.
Credential awarded by educational institutions for successful completion of a course of study or its equivalent.
General Education Development (GED)
Credential awarded by examination that demonstrates that an individual has acquired secondary school-level academic skills.
Equivalent to a secondary school diploma, based on passing a state- or province-selected examination such as GED, HiSET, or TASC; or to an award at UNESCO ISCED 2011 Levels 2 or 3.
Secondary School Diploma
Diploma awarded by secondary education institutions for successful completion of a secondary school program of study.
Equivalent to an award at UNESCO ISCED 2011 Levels 2 or 3.
Credential awarded by a government agency that constitutes legal authority to do a specific job and/or utilize a specific item, system or infrastructure and are typically earned through some combination of degree or certificate attainment, certifications, assessments, work experience, and/or fees, and are time-limited and must be renewed periodically.
Credential that addresses a subset of field-specific knowledge, skills, or competencies; often developmental with relationships to other micro-credentials and field credentials.
Quality Assurance Credential
Credential assuring that an organization, program, or awarded credential meets prescribed requirements and may include development and administration of qualifying examinations.

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 describe 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 of a Learning Opportunity (Dance)

For more information on CredentialAlignmentObject, see this section.

Learning Opportunity Profile

A LearningOpportunityProfile is defined as a resource "describing an educational or training 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

Education to Work Classes

CTDL has a set of classes and properties that allow credentials, learning opportunities, assessments and competencies to be described in the context of employment, and vice versa. These mean that CTDL can be used to show that credential, learning opportunity, assessment or competency prepares a person for occupations, whether or not that occupation is described in an external classification scheme such as ONet, ESCO or military occupation systems. Furthermore, instead of a generic occupation, the credential, learning opportunity, assessment or competency can be related to specific jobs, work roles or tasks. Such information allows for greater transparency concerning the value of credentials with respect to career and employment opportunities. Individuals should be better able to take educational opportunities that further their careers; education and training providers should be better able to understand the needs of relevant employers; employers should be able to find credentials and programs that prepare for the jobs they offer.

The CTDL classes dedicated to describing Work are Occupation, Job, WorkRole and Task, which are described in detail below:

Profession, trade, or career field that may involve training and/or a formal qualification.
Set of responsibilities based on work roles within an occupation as defined by an employer.
Job describes an abstraction or template that specific job postings or openings could be instances of.
Work Role
Collection of tasks and competencies that embody a particular function in one or more jobs.
Specific activity, typically related to performing a function or achieving a goal.

The relationships between these and classes used to describe competencies, concepts, identifiers and agents are shown in the image below. Competencies are one of the key linkages between education and work, as they may be the learning outcomes of learning opportunities, required to pass assessments or to gain a credential and may also be associated with any of the four main classes describing Work. The choice for how to show the relationships between competency and the aspect of work being described will depend on context. For example for internal use an employer may define the competences required for particular tasks, and then group these tasks into work roles and jobs; on the other hand in a job posting the competencies required may be associated directly with the job.

Education to Work Classes

The example below illustrates relationships between Occupation, Work Role and Task and the Competencies that are embodied by the Task. For simplicity only one Work Role is shown for the Occupation, and one Task for that Work Role, though in reality there would be many Work Roles each with many Tasks.

NICE Framework
NICE Framework


An Occupation is defined as a profession, trade, or career field that may involve training and/or a formal qualification. An occupation does not have to have a direct correspondence to an entry in a formal classification scheme such as ONet, ESCO or military occupation systems, but if it does then this relationship can be shown. Some occupations are specializations of others. Occupations may be related to Jobs, Work Roles and Tasks, and embody certain competencies that are required of a person working in said occupation.


A Job is defined as a set of responsibilities based on work roles within an occupation as defined by an employer; it describes an abstraction or template of which specific job postings or openings could be instances. A job may correspond to an entry in a formal classification scheme of occupations or an occupation, or may be related to an occupation that is not described in such a scheme. Like an occupation, a job may be related to Jobs, Work Roles and Tasks, and embody certain competencies that are required of a person working in said occupation. A key difference between a Job and an Occupation is that a Job is offered by an Agent (an employer) that defines the specific scope in terms of Work Roles and Tasks.

An example description of a Job is given below, focusing on the relationship between a Job and a Credential. In this case the job requires a "license to Practice" that is recognized in the relevant Jurisdiction. No further information is provided about this Credential, which is a useful pattern when there might be several specific options that would fit the requirement. A full example could also include Work Roles and/or Tasks involved in this Job and the Competencies embodied by these tasks.

Job Requiring a License to Practice
Job Requiring a License to Practice

Work Role

A Work Role is defined as a collection of tasks and competencies that embody a particular function in one or more jobs. Work roles are related to tasks and may embody certain competencies that are required to complete these tasks.


A Task is defined as a specific activity, typically related to performing a function or achieving a goal. Tasks may be decomposed into sub tasks. A task may embody certain competencies that are required to complete it successfully.

The example below illustrates how a task can comprise a sequence of sub-tasks, note the use of listID to specify the ordering of the sub-tasks. This example also shows how a task can be classified against a Concept Scheme.

Navy Maintenance Tasks
Navy Maintenance Tasks

Pathway Classes

In the context of CTDL, a pathway consists of structured sets of objectives and qualifying conditions defining points (milestones) along a route to fulfillment of a job, occupation or career. Qualifying conditions include homogeneous or heterogeneous sets of prescribed, preferred or recommended evidentiary artifacts such as competencies attained (knowledge, skills, abilities), relevant awards, other forms of recognition such as credentials earned and relevant experience.

The Pathways ecosystem is composed of the following classes:

Resource composed of a structured set of PathwayComponents defining points along a route to fulfillment of a goal or objective.
Pathway Set
A roadmap of multiple related pathways that lead to one or more destinations.
Pathway Component
Resource that serves as a defined point along the route of a Pathway which describes an objective and its completion requirements through reference to one or more instances of ComponentCondition.
An instance of PathwayComponent may serve as the goal or destination node of a Pathway.
PathwayComponent is a super-type that represents a family of more precise sub-types. In pathway descriptions, always use the sub-type of PathwayComponent appropriate to your circumstances, e.g., AssessmentComponent, CocurricularComponent, CompetencyComponent, CourseComponent, CredentialComponent, ExtracurricularComponent, JobComponent, and WorkExperienceComponent. Use BasicComponent for types of entities not covered by the current set of sub-types.
Assessment Component
Resource that identifies a direct, indirect, formative, and summative evaluation or estimation of the nature, ability, or quality of a resource, performance, or outcome of an action.
Basic Component
Resource that identifies a resource not otherwise covered by the enumerated PathwayComponent subclasses.
Cocurricular Component
Resource that identifies an activity, program, or informal learning experience such as a civic or service activity that supplements and complements the curriculum.
Competency Component
Resource that identifies a measurable or observable knowledge, skill, or ability necessary to successful performance of a person in a given context.
Competency is broadly defined to include assertions of academic, professional, occupational, vocational and life goals, outcomes, and standards, however labeled.
Course Component
Resource that identifies a structured sequence of one or more learning activities that aims to develop a prescribed set of knowledge, skill, or ability of learners.
Credential Component
Resource that identifies another resource that describes qualification, achievement, personal or organizational quality, or aspect of an identity typically used to indicate suitability.
The ceterms:Credential class is broadly defined to encompass credentials used across domains and communities of practice. Subclasses of ceterms:Credential as defined by Credential Engine (or other communities) should be referenced.
Extracurricular Component
Resource that identifies an activity, program, or informal learning experience that may be offered or provided by a school, college, or other organization that is not connected to a curriculum.
Job Component
Resource that identifies a work position, employment, or occupation.
Selection Component
Component which provides a condition which references an array of other components from which components must be selected.
Work Experience Component
Resource describing an activity or training through which a person gains job experience.
Rule Set Profile
Resource defining the application of a RuleSet to a particular ComponentCondition.
Rule Set
Resource that identifies the rules or methods by which one or more PathwayComponent instances satisfy the requirements of a ComponentCondition.
In the future, there will likely be multiple formally recognized RuleSets.
Encode the rules using Description Logic.

These classes and the primary relationships between them are illustrated below:

For the remainder of this section, we'll illustrate each class using snippets of JSON-LD encoding of a pathway description based on the image below of a transfer pathway for an Associate of Science Degree in Computer Science from Bakersfield College to the California State University. The pathway moves from left to right covering the four terms of a 2-year community college program. The upper half of the image represents the "core" courses for the degree. The horizontal lines between courses represents the course prerequisite linking structure.

The bottom half of the figure represents general education courses. Unlike the top half, there is no apparent prerequisite structure beyond the fact that a particular Pathway Component is within a . Note that the bottom right node in the figure presents a set of alternative history and philosophy courses from which a student is expected to pick one. Note that several other general education components also present such alternatives. We'll address how these kinds of choices are handled below in the Component Condition section.

The Pathways model does not define any properties for the Agent class and assumes that appropriate agents defined within relevant contexts will be referenced from the Pathway entity via the ownedBy property of the Pathway. For example, an instance of the CTDL CredentialOrganization class could use a owns property to reference one of its pathways. In like fashion, that Pathway instance could reference its owner via ownedBy - as illustrated in the JSON-LD code snippet in the following section.

Pathway Expressions

A Pathway Expression is an informal notion of a machine actionable encoding of either a single Pathway or an aggregation of logically related Pathways (a PathwaySet) defining alternative paths that are bound together in a single expression.

As defined, the basic building blocks of a Pathway form an (RDF) directed graph as illustrated by the following figure where we see a Pathway pointing to a Pathway Component identified as the destination milestone or root node of the pathway (e.g., a bachelor degree in nursing) and a set of preceding Pathway Components defining earlier milestones back to an origin (e.g., a high school diploma).

However, a Pathway Expression may describe more complex circumstances such as alternative paths to the same destination, or a destination may be more diverse - e.g., a career cluster or a more general destination such as programming and software development. The following figure illustrates a pathway modeling of alternative paths to the same destination.

Pathways may also be logically aggregated into Pathway Sets (also known as roadmaps) as illustrated in the following figure:

Pathways support a variety of use cases, such as:

  • Education & Career Planning
    • Support students and workers search and plan for career pathways including pathway options through stackable and latticed credentials and career clusters.
  • Credential Discovery
    • Find one or more types of credentials that best meet a person’s career and/or education goals along career and education pathways that provide the:
      • Best transfer value for credentials they have already earned
      • Potential to stack and build on other credentials
  • Education & Career Transitions
    • Identify education and career paths or progressions based on:
      • Degree of transfer value
      • Potential to stack and build on other credentials
  • Competency Analysis
    • Identify education and career paths in terms of the competencies that they require
    • Represent current achievement of desired competencies based on competency alignments of held credentials
    • Discover relevant credentials for each competency on a pathway/job profile from multiple providers

Pathway Set

A pathway is resource defining points along a route to fulfillment of a goal or objective. However, some pathway expressions bundle multiple pathways into a PathwaySet. A pathway set may provide multiple routes from a single origin to a single destination, multiple routes from a single origin to multiple destinations or multiple origins to a single destination. A pathway set may also express multiple paths that cross-connect providing lateral movement as part of the journey from origin to destination.


The Pathway class describes the pathway as a whole, including (but not limited to), name and description of the pathway, reference to its owner, and identifies a root (destination) PathwayComponent where such a component is present (see discussion below in the Pathway Component section).

Pathway with no Components

Pathway Components

The PathwayComponent class is a superclass identifying a family of subclasses that define specific PathwayComponent subtypes. The PathwayComponent represents individual milestones along a pathway's journey. The PathwayComponents for a particular Pathway may be comprised of instances of a single subclass identified in the table below or a mix of the subclasses.

While all of the subclasses share basic descriptive properties, each has additional properties particular to the subclass. While a basic set of properties are set out in the Pathway Terms document, additional properties will be added as experience is gained describing existing pathways.

Relationships between PathwayComponents in a Pathway are of two types:

  1. Simple binary relationships expressed as simple assertions in RDF - e.g., PathwayComponent --prerequisite--> PathwayComponent
  2. Complex relationships expressed through use of the ComponentCondition class (see Component Condition) - e.g., where the required condition is to pick a specified number of PathwayComponents from an array of available choices.
Pathway Component

Component Condition

The ComponentCondition class describes "what must be done to complete one PathwayComponent, or part thereof, as determined by the issuer of the Pathway". An instance of ComponentCondition must reference an instance of RuleSet defining the 'algorithm' or process to be applied by the ComponentCondition - e.g., one RuleSet might define the constraints on picking a CourseComponent from an array of such components while another RuleSet might set a level of confidence (or other constraint) that must be met before a WorkExperienceComponent satisfies the conditions.

While a PathwayComponent may have more than one ComponentCondition, each ComponentCondition may be associated with only one RuleSet. Initially, we are using an extension of a simple, but widely applicable "count rule" ruleset (by Badgr/IMS CLR) that defines the constraints on picking a number of PathwayComponent instances that is less than or equal to an enumerated array of such components. Development of more complex RuleSets will occur as experience requires.

Component with a Conditional Requirement

Progression Model

A progression model formally defines points along a developmental progression such as increasing levels of competence, complexity, or achievement in a schema. For example, an assessment rubric may define a set of criteria that must be achieved while providing an array of levels denoting different degrees of accomplishment with accompanying scores for each level. Such descriptions are of the class Progression Model. The following figure illustrates a simple example of a progression model - "Beginner", "Intermediate", "Advanced", "Expert" - in an imaginary pathway roadmap.

Progression models themselves are being defined at various levels of complexity. The graphic above is a simple example of a progression model. However, not all progression models are simple. Below are two images of a progression model used in the European Commission's EntreComp (Entrepreneurship Competency Framework). The first image presents a slightly incomplete statement of the model circled in red in the context of the competency framework. The second image is of the complete progression model (note that the Commission calls it a "progression model").

Manifest Classes

While classes like ConditionProfile and CostProfile are useful for describing particular credentials, there are frequent circumstances where many credentials share the same data (in whole or in part) for these classes. As such, it would be redundant to repeat this data in the records for each credential, and incur a maintenance penalty any time the data (such as the tuition costs for a college program) changes. To help solve this problem, CTDL provides a set of "manifest" classes that enable multiple credentials to reference the same data for conditions and/or costs. These manifest classes have their own URI and contain their own profiles.

When consuming the data from a manifest class, it should be treated as though it were part of the relevant credential's data (with data in the actual credential record taking priority in the event that manifest data conflicts with credential data). In other words, you would, for example, combine the cost profiles described by a manifest (such as base tuition fees that apply across an institution) with the cost profiles that are part of a particular applicable credential (such as unique learning resource fees specific to that credential) in order to determine the full set of cost information for that credential.

Condition Manifest

The ConditionManifest class addresses the description of 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 ConditionManifest. While the College has its own ConditionManifest, 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:

  • unique conditions peculiar to itself
  • its College's conditions
  • its University's conditions
Figure 2.2.6A
Parent and sub-organization, each with condition manifests

Cost Manifest

The CostManifest class addresses the description of institution- or program-wide costs.

Figure 3.1.2A
Brandman University example of a cross-program Cost Manifest.

Transfer Value

Now more than ever, people need to be able combine education, training and learning from multiple sources in order to continuously re-skill and upskill in rapidly changing careers. CTDL has the advancedStandingFrom property to represent advanced standing, which can express that a credential, assessment or learning opportunity may provide someone with a "head start" on the way to another credential. However, advanceStandingFrom doesn't give a way of saying how much of a head start.

In order to specify a value and other details about how learning achievements from one context can be applied to other contexts in order to further education and career advancement CTDL has TransferValueProfile and associated classes. The most familiar scenario in which this happens is the transfer of credit earned in courses from one provider towards a credential offered by another organization, however the CTDL enables many other forms of "value" than traditional credits, and recognises that this value may come from learning experiences other than courses and formal education. In order to represent this potential transfer of value in CTDL several classes and properties previously described (such as CredentialOrganization, LearningOpportunityProfile, Assessment, Competency, Credential and others) are used along with classes that represent the value being transferred (the ValueProfile) and how this value may be transferred (the TransferValueProfile).

The following model shows the basic parts of a Transfer Value Profile. For a more detailed example, click here.

Figure 5.0A
Transfer Value Profile Simplified Domain Model

Transfer Value Profile

A TransferValueProfile represents how value can be transferred from one form of learning to be recognized in another context. As a description, a TransferValueProfile will be owned by an organization, which may be independent of the organizations offering the forms of learning between which the value is transferred. The properties of a TransferValueProfile are listed below, some of which are illustrated in this example.

Globally unique Credential Transparency Identifier (CTID) by which the creator, owner or provider of a resource recognizes it in transactions with the external environment (e.g., in verifiable claims involving the resource).
The CTID is the equivalent of a version identifier for the resource. Different versions of a resource are considered distinct expressions and each must be assigned its own CTID. Each version of a resource can have only one CTID assigned. However, a single version of a resource may have distinct identifier values for both the ctid property and the credentialId property. In such a case both identifiers will be recognized by the resource creator/owner/provider in transactions with the external environment.
Statement, characterization or account of the entity.
Development Process
Entity describing the process by which a credential, or aspects of it, were created.
End Date
Date some event or activity ends.
Alphanumeric token that identifies this resource and information about the token's originating context or scheme.
Where a specific property for the originating context or scheme exists, such as ceterms:opeID, ceterms:ncesID, ceterms:leiCode, etc., use that property instead of this one. Where the identifier has no nameable originating context or scheme other than that of the resource being identified, ceterms:codedNotation may be used.
Name or title of the resource.
Owned By
Organization or person with an enforceable claim or legal title to the resource.
Agent includes credentialing organizations, quality assurance organizations and persons. It does not not include credential holders.
Start Date
Date the validity or usefulness of the information in this resource begins.
Subject Webpage
Webpage that describes this entity.
The web page being referenced describes the entity. The value of subjectWebpage is an authoritative location for information about the subject but should not assumed to be a persistent identifier of the subject.
Transfer Value
An explicit amount of transfer value.
Transfer Value For
Resource for which the described transfer value is applicable.
Transfer Value From
Resource from which the described transfer value originates.

Value Profile

The amount of value or range of values being transferred is represented by the ValueProfile class. This will normally include the numerical value and, optionally, an indication of the creditUnitType and/or creditLevelType. CTDL provides a CreditUnit concept scheme that can be used to specify the creditUnitType, and reuses the AudienceLevel concept scheme to indicate the creditLevelType.

Value Profile

Sometimes the value being transferred is represented as a percentage of the value required for the form of learning to which it is being transferred; the most common use case for this is when the learning from which the value is transferred is worth 100% of what is required for the thing to which it is transferred. Where the value is only valid for a specific subject, this too can be noted. This example shows that the learning opportunity from which value may be transferred is worth 3 Degree Credits at the Lower Division Level for the subject of "principles of finance".

Action Classes

The CredentialingAction class enables Quality Assurance Organizations (QACredentialOrganization) to describe "actions" sufficiently to support verification. Different kinds of actions are expressed in the CTDL as distinct subclasses of CredentialingAction (see the list below). While simple, direct assertions of fact for most of these kinds of Credentialing Actions are available as RDF assertions (e.g., accredits, approves, revokes, etc.), these Credentialing Action subclasses support more detailed descriptions of actions taken where such detail is justified or verification is desirable.

NOTE: Since a Credentialing Action is an assertion by an organization that the organization has taken an action, creators of instances of the Credentialing Action subclasses (e.g., AccreditAction) should be limited to the agent performing 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.

The following figure illustrates a particular use of the AccreditAction subclass of CredentialingAction in which a Quality Assurance Organization (QACredentialOrganization) performed a January 23, 1971 (startDate) accredit action on the "Dental Assisting Program" 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 endDate, the accreditation is ongoing.

Figure 4.5B
Accredit Action

Credentialing Action and its subclasses are defined as follows:

Credentialing Action
Action taken by an agent affecting the status of an object entity.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Accredit Action
Action by an independent, neutral, and authoritative agent that certifies an entity as meeting a prescribed set of standards.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Advanced Standing Action
Claim by an agent asserting that the object credential of the action provides advanced standing for a credential under the asserting agent's authority.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Approve Action
Action by an independent, neutral, and authoritative agent that pronounces a favorable judgment of a credential.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Offer Action
Action by an authoritative agent offering access to a entity such as a credential, learning opportunity or assessment.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Recognize Action
Action by an independent, neutral, and authoritative agent acknowledging the validity of a resource.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Regulate Action
Action by an independent, neutral, and authoritative agent enforcing the legal requirements of a resource.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Renew Action
Action by an agent renewing an existing credential assertion.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Revoke Action
Action by an agent removing an awarded credential (credential assertion) from the credential holder based on violations or failure of the holder to renew.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.
Rights Action
Action asserting legal rights by an agent to possess, defend, transfer, license, and grant conditional access to a credential, learning opportunity, or assessment.
Since an instance of ceterms:CredentialingAction is a claim that a certain agent has taken the action being described, creation of such a ceterms:CredentialingAction should be reserved to the agent of that action.

CTDL Support Classes

The CTDL Schema maintains a number of classes that support and enhance the data contained in its primary classes. Such "support classes" often appear as the values for multiple properties in various contexts across the schema. This section describes these classes.

Aggregate Data Profile

CTDL provides Aggregate Data Profile to describe summary outcomes data for credentials via the aggregateData property. Aggregate Data Profile combines properties from (and is intended to replace) Holders Profile, Earnings Profile, and Employment Outcome Profile.

Aggregate Data Profile is for high-level summary information. To describe more detailed information, use its relevantDataSet property to reference one or more instances of DataSetProfile as described in the QData Overview.

The following diagram illustrates aggregate data for an Associate Degree in 2017, including the holders of the credential, number of jobs obtained, earnings for those jobs, the applicable jurisdiction and demographic information, as well as a reference to a DataSetProfile containing more detailed information.

Note that the Data Set Profile is also capable of referencing the credential directly via the about property. This is useful in cases where two different parties are responsible for the data (i.e., one for the Credential and one for the Data Set Profile).

Aggregate Data for a 2017 Associate Degree

Credential Alignment Object

The CredentialAlignmentObject class is used throughout the CTDL to provide and/or reference values that may or may not exist in structured data sources, such as:

  • Concepts in a concept scheme
  • Competencies in a competency framework
  • Educational subjects
  • Items from an external data source, such as NAICS codes or SOC codes
  • Anywhere else where such a value is necessary

Where an external data source, such as a concept, exists, the CredentialAlignmentObject should reference it by its URI via the targetNode property. When no such source exists, the targetNodeName, targetNodeDescription, and codedNotation properties can provide data to stand in for one. In some cases, it is useful to provide both kinds of information, as this can save time (and HTTP calls) when consuming the data. However, doing so will increase the total size of the data and incur a maintenance penalty if the source data changes.

Credential Alignment Object

Condition Profile

The conditions for awarding or renewing a credential may be quite complex, involving a number of tightly coupled sets of constraints or conditions that must be met. The ConditionProfile class is used to describe these conditions. Examples of the kind of data described by a ConditionProfile may include constraints on applicable audience, residency requirements, minimum age and experience requirements, credit hour requirements, and jurisdictional restrictions, as well as other resources that must be earned or completed first, such as a required assessment or learning opportunity.

In some cases, there are different means of earning the same credential (e.g., "have 3 years of experience and pass this test, or complete 4 training courses and pass a different test"). ConditionProfile handles these via the alternativeCondition property, which allows for constructing a branching hierarchy of ConditionProfiles to group different sets of requirements together.

ConditionProfiles in the same array for the requires property should be interpreted as having their conditions aggregated together, while ConditionProfiles in the same array for the alternativeCondition property should be considered as alternatives for one another (i.e., completing the conditions for just one of the ConditionProfiles is sufficient).

If a credential references one or more ConditionProfiles within a ConditionManifest (via commonConditions) as well as one or more ConditionProfiles via requires, then the collection of all of those ConditionProfiles should be interpreted as having their conditions aggregated together (with ConditionProfiles in the array of requires taking priority in the event of any conflicts).

Note: For readability, the diagram below omits the instances of CredentialAlignmentObject that would, in the Registry, exist between the Competencies and the objects that reference those Competencies.

Condition Profile Depicting Requirements for a Nursing Certificate

Condition Sets

The figure below illustrates a Certificate that requires a ConditionProfile which describes the conditions of "3.5 years of experience" and a minimum age (minimumAge) of "21", along with completion of referenced AssessmentProfile and LearningOpportunityProfile.

Figure 2.2A
Condition Profile describing a set of conditions

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.

Organization with multiple Contact Points

Cost Profile

The CTDL provides the ceterms:CostProfile class 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 the example 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 covered in this section.

Some costs are unique to a Credential, Assessment Profile or a Learning Opportunity Profile. These costs can be defined by their respective profiles via the Cost Profile class.

Figure 3.1.1A
Total tuition for a full-time, in-state student.

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. 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.

Identifier Value

As covered in the Identifiers section, identifiers come in many forms. For identifiers that do not have specific properties assigned to them, CTDL provides the IdentifierValue class and associated identifier property to reference it. This class contains properties designed to enable providing an otherwise-obscure textual identifier, such as 123.sys-abc along with references to where that identifier came from, such as a framework of identifiers or a source that issued it. This class should be considered an identifier of last resort where no property exists that would be appropriate to use instead.

Figure 4.3.3A
Local identifier definition and value.

Jurisdiction 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.

Revocation Profile

The RevocationProfile class 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.

Verification Service Profile

The VerificationServiceProfile class 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.

Process Profile

The ProcessProfile class 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
Process Profile for a Maintenance Process

The CTDL defines the following properties for referencing an instance of ProcessProfile from a Credential:

Administration Process
Entity describing the process by which a credential, assessment, organization, or aspects of it, are administered.
Processes described include the execution of events and the development of resources in the lifecycle of a credential or organization, such as the process for the proctoring of assessments.
Appeal Process
Formal process for objecting to decisions of the organization regarding credentials, assessments or processes.
Complaint Process
Process for handling complaints about a credential, or aspects of it including related learning opportunities and assessments.
Development Process
Entity describing the process by which a credential, or aspects of it, were created.
Maintenance Process
Entity describing the process by which the credential is maintained including review and updating.
Such maintenance does not include renewal of a credential by an individual holder.
Review Process
Entity that describes the process by which the credential, or aspects of it, are reviewed.
Revocation Process
Entity describing the process by which the credential is revoked.

Rule Set Profile

In the Pathway section, we defined a Ruleset as an entity that "identifies the rules by which other PathwayComponent instances may satisfy a PathwayComponent objective". While it is anticipated that there will be RuleSet libraries developed by Credential Engine and other parties for handling complex circumstances and choices, the Simple Count Rule has been deemed generally useful and is defined directly in the ComponentCondition. The Component Condition example illustrates use of this Simple Count Rule making it possible to define a required number of PathwayComponents to select from an array of PathwayComponents that satisfies the rule. With the exception of the Simple Rule Set integrated into ComponentCondition, other RuleSets are referenced from the ComponentCondition using the alternativeRuleSet property.

While it is anticipated that other forms of rules will arise as more Pathways are modeled using CTDL, the simple Count Rule is the only one currently embodied in the schema.

CTDL Profile of ASN-DL (CTDL-ASN) Schema

In order to describe competency frameworks in as interoperable a manner as possible, Credential Engine builds on an existing description language called Achievement Standards Network Description Language (ASN-DL) that was developed under funding from the U.S. National Science Foundation (NSF) between 1999-2013 for the description of logically related sets of knowledge, skill and ability assertions. The ASN-DL is designed using the W3C's Resource Description Framework (RDF) for describing Linked Data on the open Web. The CTDL-ASN Profile adopts most of the set of properties and classes defined in the ASN-DL and is judiciously extending that set through property and class refinements as well as the addition of new properties and classes defined in CE's own Credential Transparency Description Language (CTDL).

Basic CTDL-ASN Architecture

The ASN Description Language (ASN-DL) is made up of two fundamental entities: (1) the Standards Document - a competency framework as a whole, and (2) the Statement - the individual assertions of knowledge, skill, and abilities of which a Standards Document is comprised. These two entities - documents and statements - are modeled in terms of an entity-relationship model (ER) and embodied as a directed graph using W3C's Resource Description Language (RDF). An extensible set of structural and semantic relationships between the ASN's primary competency framework entities - the standards document entity and its atomic statement entities - have been defined.

Following that pattern, CTDL-ASN is made up of its own two fundamental entities: (1) the Competency Framework, which serves as a means of describing and referencing the entire framework as a whole, and (2) the Competency, which is an individual assertion of knowledge, skill, ability, behavior, attitude, or other attributes that would fall under the broad notion of a competency. These entities closely follow the ASN-DL's modeling as an entity-relationship model.

The following diagram illustrates example encodings of a competency in the Degree Qualification Profile (DQP) using CTDL-ASN:

Degree Qualification Profile Sample Expressed with CTDL-ASN

Note that each entity has been assigned a unique identifier in the form of a Uniform Resource Identifier (URI) using the HTTP protocol. This means that each resource is a "first class citizen" on the open Web and can be openly referenced and linked too.

Cross-Jurisdiction Mapping

Because every CTDL-ASN Competency Framework resource and every CTDL-ASN Competency resource is identified by URI, competency frameworks and their individual competencies can be mapped to each other regardless of where the frameworks are located on the open Web. The following figure asserts an exact match relationship between a competency in a Brandman University competency framework and a competency in the Degree Qualification Profile (DQP):

Competency to Competency Mapping Across Frameworks with CTDL-ASN

The ASN-DL offers a range of properties to express different degrees of similarity between competencies; additional mapping properties can be defined in the CTDL-ASN Profile as needs arise.

Extending the Granularity of a CTDL-ASN Taxon Path

For some uses of a particular ASN-modeled competency framework, the level of granularity of leaf competencies in the canonical version may not be sufficiently granular. For example, a specific competency may aggregate several skills that some 3rd party creator of assessment instruments may wish to handle separately. The ASN-DL model makes it possible to increase the granularity of expression of a competency by distinguishing between canonical (original) competencies as promulgated by the authors of the framework and non-canonical (derived) statements added by 3rd parties. Derived 3rd party ASN statements "refine" original statements by making more specific granular assertions. Since derived statements are treated as first-class entities in the ASN, they are assigned URIs in the same manner as original statements and clearly identified as "derived". Of course, derived statements can be easily eliminated, not display, or treated in some manner as simple annotations by services consuming the standards documents.

As a result of this extensibility, any 3rd party may create more granular statements without authorization in its own 3rd party namespace and relate those statements to the canonical (original) statements while identifying such competencies as "derived". Of course, since 3rd party statements are in different namespaces than the canonical version, 3rd party provenance is machine identifiable. The following figure illustrates this 3rd party "annotation" process.

Extending the Granularity of a Competency Framework with CTDL-ASN

Expressing "Strength of Fit" (Degrees of Similarity)

Frequently, it is useful to map from one resource to another to express the level of useful similarity between the two nodes. Such mappings may be from one competency framework node to another node in the same or another framework (i.e., competency-to-competency), or to map from a learning resource to a competency node (i.e., learning resource-to-competency). In ASN, the utility of that mapping is a function of its "strength of fit". The ASN ontology provides an array of properties that express this strength of fit relationship in competency-to-competency mappings (called "alignments" in ASN) and learning resource-to-competency mappings (called "correlations" in ASN).

The table below includes brief descriptions of the current competency-to-competency mapping predicates. For the full description of both the competency-to-competency mapping properties and the learning resource-to-competency mapping properties, see CTDL-ASN Profile.

Align To
A competency framework or competency to which this competency framework or competency is aligned.
An alignment is an assertion of some degree of equivalency between the subject and the object of the assertion.
Align From
A competency framework or competency from which this competency framework or competency is aligned.
An alignment is an assertion of some degree of equivalency between the subject and the object of the assertion.
Broad Alignment
The referenced competency covers all of the relevant concepts in this competency as well as relevant concepts not found in this competency.
Exact Alignment
The relevant concepts in this competency and the referenced competency are coextensive.
Major Alignment
Major overlap of relevant concepts between this competency and the referenced competency.
Minor Alignment
Minor overlap of relevant concepts between this competency and the referenced competency.
Narrow Alignment
This competency covers all of the relevant concepts in the referenced competency as well as relevant concepts not found in the referenced competency.
Prerequisite Alignment
The referenced resource is a prerequisite to this resource.

Competency Framework

The CompetencyFramework class embodies a set of related Competencies arranged in some meaningful structure. A framework of competencies may be as simple as a flat list or as complex as a deep hierarchy. In rare cases, a competency framework may even be a non-hierarchical graph of competencies. The exact nature of the connections between the competencies are described by the competencies themselves (see below); the competency framework class exists simply as a way to identify, describe, and reference its competencies as a single entity.

Competency Framework with two Competencies


The Competency class embodies a particular knowledge, skill, ability, behavior, attitude, etc. A competency may exist at a high level (e.g., "Can fly an airplane"), a very granular level (e.g. "Can correctly interpret an altitude gauge"), or anywhere in between (e.g. "Can maintain level flight in clear conditions"). The most important property of the competency class is the competencyText property, which provides the normative text of the competency itself. The competency class also provides a simple competencyLabel property to enable giving a competency a shorthand name, as well as a non-normative comment to better describe or disambiguate the competencyText.

This class also has a set of properties that enable connecting multiple instances of competency together in integral/structural and non-integral/alignment related ways. See the next section for details on how these properties are used.

Competency Framework and Competencies Together

CTDL-ASN inherits ASN-DL's "two object model" nature. This means that while the CompetencyFramework allows for describing the whole set of Competencies, it is up to the competencies themselves to describe their relationships to each other. CTDL-ASN provides the following properties to connect a framework to its competencies:

Has Top Child
Top-level child competency of a competency framework.
Is Top Child Of
Indicates that this competency is at the top of some arbitrary hierarchy.
Is Part Of
Competency framework that this competency is a part of.
This property does not indicate whether or not this statement is a top-level statement in the referenced competency framework; only that it is in some way a part of that framework. To indicate that this statement is a top-level statement, use both this property and the isChildOf property.

In addition to non-structural alignment properties, the competency class has two properties to enable connecting competencies together in an integral, structural fashion:

Has Child
The referenced resource is lower in some arbitrary hierarchy than this resource.
This property identifies a child node in the downward path in the chain of resources in a taxon path.
Is Child Of
The referenced resource is higher in some arbitrary hierarchy than this resource.
Is Top Child Of
Indicates that this competency is at the top of some arbitrary hierarchy.

As shown in the Competency Framework example above, these properties allow connecting competencies together into a meaningful structure.

Quantitative Data (QData) Schema

In describing a credential, full transparency requires not only descriptions of provenance, nature and purpose, but also of credential outcomes including aggregate quantitative data on: (a) the number of credential awardees, (b) the number of awardees employed, and (c) related earnings over one or more time periods. To handle such outcomes data, Credential Engine has created a separate Quantitative Data namespace (QData). While some of the outcomes data may result from self-reporting, most of it is provided in datasets created by other parties--public sector entities at both state and federal levels and from the private sector. While many of these datasets are currently updated on a predictable schedule (e.g., annual, quarterly etc.), the development of the QData namespace anticipates far less temporal predictability across multiple datasets as data collection and reporting mechanisms become increasingly automated, interlinked and less episodic.

The following sections provide diagrams of the combination of both CTDL and QData terms in describing aggregate earnings and employment data for both: (a) the Bachelor Degree in Psychology from the University of Texas-Austin as provided through the US Census Bureau Post-Secondary Employment Outcomes (PSEO) second quarter of 2019; and ((b) credential holders data from Anderson University, Indiana for the years 2015 through 2018 as reported by the National Council of the State Boards of Nursing.


To illustrate the use of the QData properties and classes, the following two subsections use the 2019 earnings and employment outcomes data for a degree program at the University of Texas-Austin. Subsequent sections break the data down into the three key component classes that make up the QData model - DataSetProfile, DataSetTimeFrame and DataProfile. The University of Texas-Austin examples also demonstrate the use of classes and properties from other namespaces: CTDL (ProcessProfile) and (MonetaryAmount, MonetaryAmountDistribution, and QuantitativeValue).

Employment Data

The QData model supports reporting on the University of Texas-Austin (UTA) aggregate employment data for the Psychology degree in two separate ways: (1) directly through a UTA dataset; or (2) indirectly by a 3rd party agent. In the following figure, UTA is reporting its aggregate employment data through the Psychology degree’s Aggregate Data Profile entity. The PSEO second quarter 2019 report includes employment data for UTA Psychology degree holders for three time periods - 1 year out from the confiring of the degree, 5 years out, and 10 years out. It also includes IPEDS data for the same time frames.

While UTA is reporting employment data from a single data source in this example, it could provide multiple DataSetProfile entities - each providing data from a different data set.

QData - Employment Outcome Data

Earnings Data

The figure below includes the PSEO earnings data for the same time frames as the employment data above. The structure of the top portion of the graph down to the DataProfile entity is fundamentally the same as the employment graph above.

QData - Earnings Data

Holders Data

The QData model supports reporting on the aggregate numbers of credential completers (holders) at specific points in time. The top portion of the figure below is fundamentally the same as the top portions of the figures above for both earning and employment data except that it reports on credential holders of a different institution, Anderson University. The number of years actually reported in the data set has been reduced in the diagram by half in order to save space.

QData - Holders Data

Data Set Profile

The DataSetProfile provides the entry point from Aggregate Data Profile into the QData graph for the UTA data and provides a general description of the data set and its data points including name, description, data provider, data suppression policy, data access URL, data set time periods included, administrative processes and the and other relevant data. The figure below illustrates this:

QData - Data Set Profile

Data Set Time Frame

The dataset generally described using DataSetProfile may have data covered by more than one time frame. For example, the aggregate earnings of credential holders may be reported for multiple post-award timeframes - e.g., 1 year out, 5 years out and 10 years out. The function of the DataSetTimeFrame class is to describe these timeframes by providing startDate and endDate properties. The dataAttributes property of the DataSetTimeFrame links the time frame to the DataProfile class where the attributes of the dataset will be described.

QData - Data Set Time Frame

Data Profile

The DataProfile class has a rich array of properties describing the characteristics of the dataset subjects. Each of those properties references one of the following classes: QuantitativeValue, MonetaryAmount, or MonetaryAmountDistribution.

QData - Data Profile

Detailed Examples

This section contains detailed examples from across the schemas that show how various use cases are handled.

Describing Requirements

The most common use of ConditionProfile is to describe the requirements to earn a credential. The following examples show various ways in which this occur.

Alternate Routes to Earn a Credential

A set of conditions represented by a ConditionProfile may have sub-sets of conditions defined by additional instances of the ConditionProfile class. In other words, a ConditionProfile 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 a targetAssessment.

Through use of the alternative condition (alternativeCondition) property, this Condition Profile branches to separate instances of the ConditionProfile 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:

  • Option 1:
    • Transcripts
    • Assessment
    • Master's Degree
  • Option 2:
    • Transcripts
    • Assessment
    • Bachelor's Degree
    • 2 Years Experience
Figure 2.2B
Credential with two Sub-Conditions

Referencing Competencies

One of the most pervasive uses in CTDL of the CredentialAlignmentObject class (see the Credential Alignment Object section for more details) is relating various entities in the CTDL model to CompetencyFrameworks and their member competencies Competencies.

The following examples illustrate how this works using a Competency node in the DQP Framework. The description properties for this Competency include:

Referencing Competencies from Credentials

The Credential classes can use a ConditionProfile to reference competencies via the targetCompetency property and a CredentialAlignmentObject. The intended meaning of the reference to the Competency is conveyed by the property that references the ConditionProfile. In the example below, the requires property is used to mean "This credential requires the following conditions, among which is the indicated targetCompetency."

Any class (including AssessmentProfile and LearningOpportunityProfile) that uses a ConditionProfile can follow this approach.

Figure 4.1A1
Credential that requires a Competency via a Condition Profile.

While the Credential Registry requires the use of a ConditionProfile in cases like the one above, CTDL allows properties like requires to bypass the ConditionProfile and directly use a CredentialAlignmentObject.

Figure 4.1A1A
Credential that requires a Competency directly.

Referencing Competencies from Assessment Profiles

In addition to the ConditionProfile-based approach described above, the AssessmentProfile class can more directly reference competencies via its assesses property and a CredentialAlignmentObject.

Figure 4.1A2
Assessment Profile that assesses a Competency.

Referencing Competencies from Learning Opportunity Profiles

In addition to the ConditionProfile-based approach described above, the LearningOpportunityProfile class can more directly reference competencies via its teaches property and a CredentialAlignmentObject.

Figure 4.1A3
Learning Opportunity Profile that teaches a Competency.

Referencing Concept Schemes (Controlled Vocabularies)

The following example follows the exact same pattern of use but adds the 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.

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 class in the manner illustrated below.

Figure 4.1D
Organization referencing a Concept.

Referencing External Concept Schemes

The following graphic illustrates the use of the CredentialAlignmentObject to assert that a certain instance of the Credential class has an occupationType of "Deaf-blind interpreter" as defined in the RDF-based European Skills/Competences, qualifications and Occupations (ESCO) and identified with the URI of

Figure 4.1B
Credential alignment object referencing ESCO occupation.

Describing Transfer Value

The figure below shows the transfer value provided by (transferValueFrom) a "Principles of Finance" course.

Figure 5.1
Transfer Value Profile

Degree with Concentrations

Degrees 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

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.

Figure 2.2D
Two required Conditions - Courses + Certifications

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


BCP 47:
Best Current Practice 47 - Language Tags
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.
bNode ID:
For handling bNodes in JSON-LD, see the relevant portion of the JSON-LD specification.
ISO 8601:
Data elements and interchange formats - Information interchange - Representation of dates and times:
JSON Linked Data Specification
Progression Model:
ASN Progression Model Specification
Resource Description Framework (RDF)
Latest "RDF Primer" versions
Simple Knowledge Organization System (SKOS)
SKOS (Simple Knowledge Organization System) Primer
SKOS (Simple Knowledge Organization System) Reference
Uniform Resource Locator
W3C LD Glossary:
World Wide Web Consortium Linked Data Glossary